Hello,
I was flying into KPSP today, in the PMDG 737-700, and noticed that the RNAV (RNP) Y RWY 31L approach is incorrectly ‘drawn’ on the map. Between the waypoints HIXOV and TEVUC there is supposed to be one clean turn between the points. Navigraph has depicted the approach as having two separate turns where the aircraft wants to turn before HIXOV, go straight to TEVUC and then lead the turn to the final approach course.
Navigraph is currently up-to-date. The center application was running in the background. I have tested this both with AXONOS KPSP and Default.
Please reference the images attached of how the approach should be and how Navigraph data has drawn the approach.
Yes, and that looks also correct. The reason is because on the charts is drawn as fly-over waypoint but there both are no fly-over waypoints and therefore you see another path on the ND. This is “only” a drawing issue - the limits when you fly these approach are absolutely the same.
Also, please be aware that it depends on the bank-angle which can be differ between the aircrafts. So you shouldn´t really compare the graphs between the charts and the ND. It could be differ as in this case.
I also have compared the coding against the FAA database and it´s exactly the same - no fly-over so the turns starts always BEFORE the waypoints and that´s what you see on the ND. Last, the current PMDG version can´t fly really RF-legs - so there is a internal workaround for that.
Last, it is also depending on the airspeed, when you fly with max 210 kts you have another radius as when you fly with 180 kts.
Hope that helps but I can´t see any coding issue here - more a drawing “issue” on the ND.
Hi Richard,
I appreciate your quick response. While I understand that speed and bank angle determine radius and HIXOV is not a fly-over point, I would still like to point out that the approach was incorrectly flown - by the PMDG plane. That arc is a published part of the approach and no matter the speed of the aircraft the plane needs to fly that arc - even though HOXOV is technically not a flyover point. Referencing FlightAware, I can see that when planes shoot the approach from the PSP iaf they fly it exactly how the chart depicts it. Even ForeFlight depicts the arc. I guess going off of your response, you have properly coded the arc but PMDG just hasn’t properly coded in approaches like that?
Hi again,
the problem are not in the data nor directly in the PMDG. With the current data-format what PMDG currently use, you can´t code RF-legs 100% correctly because the syntax of the data-format doesn´t support it. Additional to this the waypoint TEVUC is a “connection” between the BALDI transition and the final approach. Means the transition ends at TEVUC and the final approach starts at TEVUC.
Here the coding in the PMDG-format:
APPROACH RNV31LY FIX TEVUC AT OR ABOVE 4000 FIX JISOP 2900 RNW 31L TRK 309 UNTIL 1800 TURN RIGHT DIRECT FIX OVERFLY TRM AT OR ABOVE 4000 SPEED 210 HOLD AT FIX TRM RIGHT TURN INBOUNDCOURSE 310 SPEED 210 LEGDIST 4
TRANSITION BALDI FIX BALDI AT OR BELOW 12000 FIX CUPOL AT OR BELOW 8000 AT OR ABOVE 7000 SPEED 210 FIX RF019 FIX RF020 FIX RF021 FIX HIXOV AT OR BELOW 6500 AT OR ABOVE 6000 SPEED 210
You see the “workaround” RFxxx waypoints between CUPOL and HIXOV, which will be generated from our parser but you also see that HIXOV is the last waypoint in the transition and not TEVUC as we have it in the database.
With the current data-format (syntax) - I must remove one of the points to avoid double waypoints in the FMCs. The “rule” of this workaround is to disable the last waypoint in the transition, means I miss the last RF leg to TEVUC and therefore the direct to TEVUC leg and therefore the not so perfect drawing path on the ND.
Since a few months we are working with PMDG on an new, more modern data-format which will be replaced this more than 10 years old data-format. With this format, it is possible not to loose any information and to draw this ARC (RF-leg) absolute correctly.
I know, at the moment not so helpful, but we can´t do more at the moment and it´s better to let all such procedures included in the data as to remove it due the syntax-limitation.
Hope that brings more light in this case
Cheers,
Richard
This now makes a lot more sense! Thank you for taking the time to explain, in detail, the situation. Hopefully, sometime soon we can see that new data format.
