PMDG 777 navdata issue affecting turn behavior

So some people have commented that the PMDG 777 exhibits some strange behaviour in turns, especially in RF segments. It appears that this is related to the magnetic course parameter in the PMDG 777 nav database. For example, take the RNAV RNP 13L approach at KJFK. There is no chart for this approach, but it is there in the nav database. At JEVNI, the magnetic course parameter is 133 in the database, while the final approach course for 13L is 134. Changing the magnetic course at JENVI to 133 makes the turn smoother all throughout the arc and there is no “snap to level” behavior.

This is just one example, but it happens with many other approaches, especially ones with RF legs.

So basically, if a waypoint has a path terminator of “RF” in the database, its magnetic course should be the same as the waypoint immediately following it.

Thanks for the report, but I’m not sure what we should do here, or what do you expect from us now?

Cheers
Richard

If a waypoint has a path terminator of “RF” in the database, its magnetic course should be the same as the waypoint immediately following it, such as the example I gave with JEVNI → RW13L. JEVNI currently has a magnetic course of 133 in the database, but it should have a magnetic course of 134 to match that of RW13L.

Currently, the magnetic course of some waypoints in RF segments have a magnetic course parameter that differs from that of the following waypoint by anywhere from 1-2 degrees.

Is this an ARINC424 coding rule or your own interpretation? When its a coding rule, please can you tell me the rule that I can send it to our data provider. Thank you

Cheers
Richard

PS: I will also check what procedure that is - I can’t verify it … all procedures to 13LR ends in an visual part …

I am not sure if this is a rule that is documented anywhere, but someone brought it up on another forum and said that altering the magnetic course in the way i described made RF turns smoother for them. I tried it myself and I had a similar experience. So it is worth looking into.

The approach is simply called “RNV13L.” It’s an RNP approach with the waypoints COVIR → ASALT → ZADUD → WIRKO → JEVNI

As i said, this is one example, but i noticed that there are other approaches where there is a difference in magnetic course between the outbound waypoint of an RF segment and the following waypoint.

There is no real issue there as far as I have seen now after doing some tests.

In ARINC 424, RF-Legs are actually overspecified. You can define them either by the WPT coordinates or the Theta / Mag course and radius values. Its up to the avionics which one to use.

In the PMDG file Mag course values and radius values seem to be ignored as removing them has no negative side effects and proves that they probably went with the coordinate implementation. Thats actually the better implementiation as source values can be off by a few degrees compared to MSFS real values based on Magdec.bgl

On APCHs there are also sometimes hard coded tracks on TF legs present which is not even possible or forseen by ARINC 424. On SIDs and STARs those are blank as it should be.

So maybe there could be a bit of some cleanup work done together with PMDG to remove superflous values from the output.

… additional to @jpschuchna comment to this (which is absolutely correct and that what I mean with my question in my first posting) - we will report that this procedure is far outdated and not existing in our eyes.

I have figured out that this approach R13L is a procedure from cycle 1813 and I assume (comparing with all other information what we have), that this procedure doesn´t exist any longer.

Cheers
Richard

Another thing to keep in mind with RF-Legs. They are sometimes not as precisely constructed as they seem. The coordinates / radius are sometimes off a bit and therefore you may see the aircraft reacting to those little “offsets” at the beginning or the end of it do to design issues which only the authorities can fix.

Also it is important to watch your speed. Sometimes authorities don`t publish speed limits and you have to set one that is reasonable manually on the legs page.

If not then the aircraft is having a hard time and then it does some wings level action during longer RF-Legs. Speed invervent doesn`t help as the aircraft still calculates with the faster speeds on legs page. That one is known to PMDG and they are looking wheter speed intervent should work too.

Try out GAXUN 1B at SPZO for example. Don`t forget the speed limit at ZO804.

RNAV RNP 13L is still used today. It’s an airline specific approach, but several domestic and international airlines have access to it. I heard it requested just a couple of weeks ago on live ATC.

We have asked our data provider … we don’t offer airline specific procedure, only standard procedures. So when it’s really airline specific, it should not be included …

Cheers
Richard

Hi again,
we had asked our data provider, why the chart for the RNP 13L into JFK isn´t available. There are two major reasons:

  1. It´s FAA Special IAP and therefore this procedure needs special aircraft and aircrew requirements (which was mentioned before)

  2. Due #1 - not all pilots/operator will have a chart to go with the NavData coding. Possession of a chart is what determines whether or not a crew can fly the Special - regardless of whether or not it´s in their databases.

This is the reason why there are no Jeppesen or FAA charts for this procedure available. But as @B737dm mentioned in his previous posting - the procedure is still valid …

Hope that info helps …
Richard