KAAO ILS18 missing HUKAM as IAF choice in MSFS for GNS 530 or G1000

WT believes there could be a Navigraph issue when only one IF/IAF is available. I tested the default MSFS nav correctly shows HUKAM as an option to start the approach.

thanks for your report and thanks for “transfer” your question from Discord to our forum here … much appreciated.

I have checked the KAAO ILS18 approach and no, this is not a navdata issue (possible an FAA issue, yes). HUKAM must not be coded as own transition and is also not be coded as own approach transition. Not with our data, nor with the FAA data. The “rule”, that a IAF is equal a transition is not correct as you also see in the FAA data.

Here directly from the FAA data:

You see, there are only two approach-transitions HUT and ICT (red line). Also, when you look on the yellow marker, you see the “A” at HUKAM waypoints, which means that this waypoint is defined as IAF. We have the same in our data, HUKAM is defined as IAF.

Again, the assumption/logic that a IAF waypoint is automatically a transition, is according the ARINC424 standard rules, not correct … and as you see, also the FAA doesn´t have this transition coded.


Thanks Richard, not quite sure what to think now. I tested the Garmin trainers and they all allow HUKAM as an IAF that can be loaded up. Even if the FAA does not have this coded correctly, shouldn’t navigraph match the real garmin and MSFS default gns units?

Ah when you wrote that you have tested it in the Garmin trainer than it’s the logic in the Garmin’s, that the Garmin’s use a IAF as transition.

The problem in the MSFS looks now, that the Garmin doesn"t have this logic and needs the data for this. That would also explain why the HUKAM transition is included in the stock data even when it’s not in the FAA data because WT add each IAF as a transition.

We offer real world data for all devices and addons, not only for the Garmins. Our Jeppesen data are 1:1 what an airliner uses too without merging data or tailor data. The MSFS data are a mix of NavBlue and FAA due the bad coverage in the US and now plus some adjustmans to fix the internal logic.

As I have figured out now is, that the data are correct and thats important for us, because we don’t only support the MSFS database. We must look, that all developer gets the same source and the same quality of data.

Sorry, in this case, we can’t do more. There is no transition offering from the FAA and therefore also no offering in our datasets.


… it is not correct according the ARINC424 rules (and also according all different databases), but when the implementation needs it.

I will add this as a feature request in our backlog for future development.


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.