For the iFly MAX8 and the current cycle:
Rwy 31L: Coding for waypoint EMRUD (CATH1.31L.2) is not correct.
Changed Leg to DF and added TurnDirection=R and departure was drawn per the chart.
Thanks for the fix.
Jim
iFly Support
Needs to look like this:
[CATH1.31L.2]
Leg=DF
Name=EMRUD
Latitude=33.794086
Longitude=-116.251575
CrossThisPoint=1
TurnDirection=R
Hi Jim,
We can’t make this change. We will ask Jeppesen if the coding is correct, but it’s not what we have in our hands, sorry.
Cheers
Richard
Hi Richard,
The chart demonstrates my fix is correct, and, more importantly, the procedure draws correctly on the ND.
Without that leg type, the turn is drawn to the left vice right.
Best,
Jim
Yes, again, we can’t do this on our own. We must report this to Jeppesen. This is a process, and no fast fix here is possible. Sorry.
Cheers
Richard
While I am not familiar with the format used by the iFly, I am generally curious about that sort of thing so I decided to check the whole procedure to see if I could make sense of it.
Going through each leg and comparing it with the “X-Plane Custom Data” format (a.k.a. GNS430) that I am reasonably familiar with.
First leg, from runway threshold, fly heading 310 until intercepting PSP 268 radial
[CATH1.31L.0]
Leg=VR
Heading=310.0
Frequency=PSP
NavBear=268.0
VR,0,PSP,268.0,310.0,0,0,0,0,0,0,0,0
Second leg, when reaching termination of the previous leg, turn right direct to PSP VOR
[CATH1.31L.1]
Leg=DF
Name=PSP
Latitude=33.870014
Longitude=-116.429772
TurnDirection=R
DF,PSP,33.870014,-116.429772,2, ,0.0,0.0,0,0,0,0,0,0,0,0
Third leg, it’s a simple track to fix from PSP to EMRUD (with an instruction to overlfy EMRUD)
[CATH1.31L.2]
Leg=TF
Name=EMRUD
Latitude=33.794086
Longitude=-116.251575
CrossThisPoint=1
TF,EMRUD,33.794086,-116.251575,0, ,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1
Given the leg that comes before it, you will be arriving on PSP roughly from the north/northwest on a heading of roughly 130 degrees to join the (~104) track from PSP to EMRUD:
(I’ve extended the tracks a bit to better demonstrate the actual turn direction)
Making this leg into a DF with a right turn appears nonsensical/wrong, IMO; the fact that it fixes drawing on the iFly suggests perhaps a bug in the way the aircraft parses the data?
Fourth leg, governs the path from EMRUD back to the PSP VOR; this is the DF leg and includes the turn direction to the right.
[CATH1.31L.3]
Leg=DF
Name=PSP
Latitude=33.870014
Longitude=-116.429772
TurnDirection=R
DF,PSP,33.870014,-116.429772,2, ,0.0,0.0,0,0,0,0,0,0,0,0
Regards,
Tim
Hi Jim,
After following Tim´s posting, I have also analyzed the procedure and I think the DF leg is really wrong. Tim’s explanation/comparison is excellent (thanks for that, @Rodeo314).
According to the ARINC424 leg definitions, a DF (Direct to a Fix) leg “defines an unspecific track starting from an undefined position to a specific database fix.” That´s not the case here because the starting point is the PSP VOR, so it is not “undefined”. Therefore, as Tim mentioned, the leg type DF is wrong here and makes no sense.
It´s a clear track from PSP → EMRUD, and therefore, the TF (Track to Fix) (definition: Great cycle track over ground between two known database fixes) is correctly coded here.
Cheers,
Richard
Hi Richard,
I don’t have access to those definitions. All I know is:
- The turn direction instruction for that leg is missing from the navdata
- Adding the turn direction does not fix the issue – a left turn is drawn.
- Turn directions with the two other SID waypoints with DF legs are drawn correctly, as is the first VR leg.
Is the implication a right turn should be drawn with a TF leg and no turn direction entry for the leg?
Best,
Jim
Hi Jim,
A TF leg typically has no turn direction (according to the ARINC specs, the turn direction is “optional” but not “mandatory”). You fly from a specific position to a fix—no turn is needed here; the aircraft automatically follows the track from PSP to the fix EMRUD through this leg type.
The turn direction is only necessary when the turn is over 180 degrees because then you must specify whether the a/c should make a right or left turn to reach the fix for such TF leg. In this case, it´s a straightforward, not a 180-degree turn - it´s more a turn between 110-111° degrees inbound PSP and 104-106° degrees inbound EMRUD.
Normally, I don´t compare addons, but in this case, here is a correct drawn path from the PMDG ND with the same leg path types:
You see, the legs
- PSP268 (VR leg)
- right turn to PSP (DF leg)
- track to fix EMRUD (TF leg)
- right turn back to PSP (DF leg)
Sorry, Jim, but the procedure is correctly coded according to the standard ARINC424 rules and leg-path types. It´s a data interpretation mistake on your side.
Cheers,
Richard
Hi Richard,
Certainly if it’s our problem it will be fixed. Normally, absent a turn direction, the aircraft will turn according to the shortest distance to the next waypoint.
Best,
Jim
That is correct. It will be set in the data if you exclude when you want (or when the a/c) needs to turn in the other direction.
Thank you very much for your feedback Jim!
Cheers,
Richard
This topic was automatically closed after 7 days. New replies are no longer allowed.