What and What Not to Report as of v1.33?

[Torbinator]

Hi @tkyler & @Litjan,

If I understand correctly, the V1.33 update included the ability for the CDU to display potential block altitudes at fixes. However, I do notice quite often that when I load STARs in the FMC, the altitude's depicted over fixes on charts don't always match up with what is being displayed on the CDU.

My question is, would you like us to post those occurrences here similar to the way we've been posting Gizmo errors?

The latest example I can give was a flight with planned cruise of FL320 into KLAS. I set up the SITEE4 arrival out of GGAPP, which the chart lists as at or above 23000 (FL230), but the CDU displayed my cruise at FL330.

Another occasional occurrence has been missing data at fixes along a STAR before reaching the runway (i.e., ABCDE ---/-----). I know when all the fixes lack data it's because the FMC was not loaded correctly/completely, but the example I'm describing shows the fixes before and after with the calculated VNAV data.

Last scenario for now, should we report erroneous lateral RNAV course depictions? Many times it depicts curved lateral paths as charted, other times not. Example: I flew into KMSO on the RNAV runway 30 out of PIXIE, which takes us straight to ROKNY then WAMIS, then a curved path to TUFFY. This depicted a straight path between WAMIS and TUFFY instead of curved.  However, when flying into runway 32 at KMFR via the RNAV out of SAMIE, it did a very nice job depicting the curved path from RURTE all the way to FILPU.

Should we report these?

Thanks.

Edited October 16, 2020 by Torbinator

[Litjan]

Hi Torbinator,

in general the first thing we do when we get these report is check the underlying nav data that is being used. We would need to know the provider (Aerosoft or Navigraph) and the navdata cycle.

Quite often the data is not correct in the dataset - or the user is looking at outdated charts, or updated charts with outdated navdata ;-) You can often see this yourself if you look for the corresponding .xml file in the navdataset and then do a textsearch for SITEE4. You can probably read the xml and see if the altitude of 230 or above is encoded there.

This is what it looks like in Navigraph data:

</Star_Waypoint>
      <Star_Transition Name="GGAPP">
        <StarTr_Waypoint ID="1">
          <Name>GGAPP</Name>
          <Type>Normal</Type>
          <Latitude>37.533222</Latitude>
          <Longitude>-112.134619</Longitude>
          <Speed>0</Speed>
          <Altitude>23000</Altitude>
          <AltitudeCons>0</AltitudeCons>
          <AltitudeRestriction>above</AltitudeRestriction>
          <Flytype>Fly-by</Flytype>
          <BankLimit>25</BankLimit>
          <Sp_Turn>Auto</Sp_Turn>
        </StarTr_Waypoint>

I can see that the 230A is present (also in Aerosoft) and I can confirm that it is not depicted in our FMS when I load the STAR, so it is probably a bug in our software. This will receive close scrutiny in the VNAV rewrite, so it is probably not necessary to report these problems now.

 

The curved approach problem depends on the RNAV capability of the (old) 737-300 Classic. It is not capable of RF approaches (radius-to-fix) - which defines the circle to be flown. Therefore when you see these letters on an approach chart: RNP AR APCH, RF required - it can not be flown with our aircraft- in fact I can not even fly ith with our modern A320s, we can not fly AR (authorization required) approaches, but we can fly RF, of course.

I think for now there are normally alternative RNP procedures provided, because many older planes can´t fly RF.

I will talk to Tom, maybe we can add that capability to keep our plane abreast of modern development, I am not sure if the real Classics still flying are capable of those approaches, though.

Cheers, Jan

[tkyler]

Also, a clarification between depicting the published restrictions vs. honoring those in our VNAV calculations is warranted.  Previously, we did not even show the restrictions correctly on the LEGS page....and that is a separate issue from a VNAV calculation where you have to assess those restrictions with other paramaters and ultimately calculate the altitude for a waypoint.  As Jan says, the VNAV rewrite we're doing will address the issue.

-tkyler

[Torbinator]

Thanks guys.  I'm curious if you could clarify something that I think I remember reading. If I understood correctly from a previous post, there is a plan to improve the vnav functionality in an upcoming update, and then further in a complete rewrite?

Also, was hoping you might be able to clarify the following based on the above... I feel as though as recent as version 1.30 through 1.32 I was able to reprogram the altitude over a fix on a STAR from what was on the chart to what ATC (PilotEdge/Vatsim) asked for, and see the depicted T/D did shift accordingly. Sometimes the aircraft followed the reprogrammed VNAV (about 50% of the time estimated), other times not. Yet with the v1.33, the reprogramming amended restrictions never relocates the T/D and the aircraft VNAV only follows the path as originally calculated. Can you share if this functionality will be restored with the VNAV update or VNAV complete rewrite? Assuming my interpretation that there are two separate phases on this is correct.

Thanks @tkylerand @Litjan !

[tkyler]

Actually I've been rethinking the 'complete rewrite'....but I should mention there there are two significant rewrites planned.  1). the VNAV algorithms and 2) the XP1100 Navdata integration.  Originally, the idea was the XP1100 navdata is of a format that would make LNAV route building a bit less painful (being only one format instead of 2, i.e. Navigraph and Aerosoft)....and a reliable lateral route is required for a successful vnav calculation.....hence combining both heavy rewrite tasks into one activity; however,   we've seen enough success with the recent LNAV route building....that we feel it will serve as a sound basis for moving forward with the VNAV rewrite now.   So we are moving forward with the VNAV work, and will get to the XP1100 navadata some time in the future.  Both Navigraph and Aerosoft formats are not going anywhere, even into X-Plane 12.  Our internal format for handling route calculations is independent of any datasource...so when we do get around to working with the XP1100 data exclusively, we'll still be coercing that data into our own internal format.  

-tkyler

Edited October 30, 2020 by tkyler

[Torbinator]

Hi Guys, I just wanted to share a recent example that was explained above, since it happens relatively frequently. I chose this example since there were several fixes involved. Let me know if the issue was user error, and if I should keep posting these if they will help with future VNAV improvements.

v1.33

Navigraph AIRAC 2013

Route: KDCA - Depart RWY 19 - DOCTR4 AGARD J42 LAURN J222 JFK ROBUC3 - ILS RWY 4 from GOSHI - KBOS

Attached CDU images labeled based on page order

Edited December 14, 2020 by Torbinator