There might be a wrong Turn Direction parameter for IBUTI, EDDW approach ILS 09 via transitions EKR09, GIB09, PIX09, VE09A and VE09B.
This causes an overshoot at the previous waypoint to meet the false Turn Direction requirement.
Little Navmap (airac 2202):
ND of MSFS FBW A32NX:
I can´t really explain this issue but it´s not from our data. The DW420 waypoint has no turn direction it´s a “TF” leg, also this waypoint is a “fly-to” and not as “overfly” waypoint. We have both set exactly in the LNM dastabase and the MSFS dataset.
When you look on the details in LNM you will see, there is no direction and no overfly information at DW420:
So it looks there is a logic behind what we don´t know sorry.
thank you for the quick response.
As I wrote, the issue is not DW420, but the turn direction of IBUTI.
The issue at DW420 is only the result of the turn direction at IBUTI.
If you remove the turn direction of IBUTI, the approach is correct and no overshoot happens at DW420.
There is no turn direction in this approach in our data. All waypoints has no turn directions nor overflys in our data. All are TF legs … So, we can’t remove what we don’t have sorry.
This must be any other issue somewhere but the data are correct.
Sorry, but you showed it already to me:
And I tested my assumption already in LNM before, not to waste your time.
I removed the IBUTI turn direction from the data (only for validating and testing) and checked the track in LNM. It was ok then, no overshoot at DW420.
Again, as I have weitten before there are NO!!! turn directions in our data for this procedure. I can’t say where this turn direction comes from but it’s not from our data.
I can’t remove it what we not have.
I’m really confused now, because I use the navdata for LNM and MSFS. Both show the same failure.
I double checked it now. I opend the latest exported sqlite db file ‘little_navmap_msfs.sqlite’ from Navigraph FMS data manager for LNM and looked for the approach. It shows the turn direction at IBUTI:
If it is not in your database, maybe it is an issue with the export tool?
… but this “turn direction” is correct so far. You see the leg-type CF here, which means “course to fix” and this CF leg depends on the previous TF (track to a fix) leg. A TF leg needs normally no turn direction, only when the turn is more than 135 degrees (I guess) because then you must know if you fly left or right to this next fix. In this case it´s a clear “track to a fix”
Try to follow the path:
Line 1: inital fix PIXUR
Line 2: track to fix DW410
Line 3: track to fix DW412
Line 4: track to fix DW420
Line 5: turn right hdg 086 to IBUTI
It´s not meaning turn right AFTER passing IBUTI.
If you say it is correct, I’m fine with it.
Yes Sebastian, I can now confirm - the coding is correct. The leg sequences are defined as “fly to” and not as “fly after”, means the next leg is the imported one and not the previous.
It’s “current” to “next”, according the standard ARINC rules.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.