Wrong (not existing) approach transitions

[MSFS 2020] Bug Reports Aircraft
1

There are a lot of wrong/not existing approach transitions included in the stock navdata.

Example:

  • Airport-ICAO code: KLAX
  • Approach: ILS06L
  • Transition: FIM

FAA chart to this example:

image
image1213Ă—1231 244 KB

FAA data source (AIRAC 2403):

SUSAP KLAXK2FI06L  ACLVVR 010CLVVRK2PC0E  A    IF                                 + 04000     18000                 0 NS   324001705
SUSAP KLAXK2FI06L  ACLVVR 020NATHNK2EA0EE B    CF IUWUK2      2510012707100050PI  + 03600                           0 NS   324011705
SUSAP KLAXK2FI06L  AEXERT 010EXERTK2EA0E  A    IF                                             18000                 0 NS   324021107
SUSAP KLAXK2FI06L  AEXERT 020         0        VI                     0500        + 03600                           0 NS   324032313
SUSAP KLAXK2FI06L  AEXERT 030NATHNK2EA0EE B    CF IUWUK2      2510012707100057PI  + 03600                           0 NS   324041705
SUSAP KLAXK2FI06L  AFIM   010FIM  K2D 0V       IF                                             18000                 0 PS   324051612
SUSAP KLAXK2FI06L  AFIM   020WAKERK2EA0E  A 020TF                                   06000          210              0-PS   324061705
SUSAP KLAXK2FI06L  AFIM   030KILIEK2PC0E    010TF                                 + 05600                           0 PS   324071705
SUSAP KLAXK2FI06L  AFIM   040NATHNK2EA0EE B 010TF IUWUK2      25100127        PI  + 03600                           0 PS   324082105
SUSAP KLAXK2FI06L  I      010NATHNK2EA0E  I    IF IUWUK2      25100127        PI  J 036000180018000                 0 NS   324091705
SUSAP KLAXK2FI06L  I      020ALISNK2PC0E  F    CF IUWUK2      2510006707100059PI  H 0180001800            LAX   K2D 0 NS   324102105
SUSAP KLAXK2FI06L  I      030RW06LK2PG0GY M    CF IUWUK2      2510001607100051PI    00168             -300          0 NS   324111602
SUSAP KLAXK2FI06L  I      040         0  M     CA                     0710        + 00600                           0 NS   324121412
SUSAP KLAXK2FI06L  I      050AMTRAK2EA0EY      CF LAX K2      0460017304600160D   + 03000                           0 NS   324131203
SUSAP KLAXK2FI06L  I      060AMTRAK2EA0EE  R   HM                     0460T010    + 03000                           0 NS   324141107

Description:
According the charts and the FAA data (see above), there are three (3) approach-transition available:

  • CLVVR
  • EXERT
  • FIM

But in the stock data exists four (4) approach-transitions:

  • CLVVR
  • EXERT
  • WAKER
  • FIM

It looks like, that you add all IAFs as transitions and thats not correct because as you see, there are only three available in real-life. The Garmin device add all IAFs as own transition, so in the Garmin devices you have really four (4) transitions

  • CLVVR (iaf)
  • EXERT (iaf)
  • WAKER (iaf)
  • FIM

… but thats a Garmin specificum only, which will be done by the Garmin device ifself (I have checked the Garmin data - no WAKER transition included in the Garmin data cycle 2403). Airliners (Boeing and Airbus FMC/S) don´t have this “feature” - they don´t “add” the IAFs as transition.

I have checked the stock data now and have seen, that this logic (IAFs = transition) is not reflected in the Garmin device, but through the data. The result of this logic (to add a “custom” transition in the stock data only to fit it for the Garmins) is, that you also see this “additional” transition in the airliner FMC/S - and thats not correct.

Here from the Garmin (stock data installed) - correct so far:

image
image531Ă—788 69 KB

… but you see the WAKER transition also in the airliner FMC (here from the stock 787):

image
image477Ă—784 65.4 KB

Again, there is no WAKER transition existing in real-life (see the FAA data and the FAA charts). This transition should ONLY be visible in the Garmin devices, because here - it´s correct.

Hope that helps to fix this issue,
Richard

3 Likes
2

WAKER is an IAF according to the chart and as a pilot, I’d expect it to be selectable as a “transition” in any navigator. The fact it’s not in the AIRAC is the only puzzling part.

But, procedure nomenclature-wise, the only official “transition” segment here (feeder transition from enroute to approach) is from FIM, all the others are IAFs and their subsequent legs are initial approach segments, despite all being named as “transitions” in the usual nomenclature of the navigator units. In short, all four should be available to select.

The chart says one thing (there is a “transition”), but the data say another.

3

Not sure, if this is now the official statement from Asobo or not but three things to clarify:

  1. In general according ARINC424 rules/coding an IAF is NOT!! equal a transition - so you shouldn´t expect for each IAF a own transition

  2. As I have written: the four transitions are correct for the Garmin device. Garmin lists IAF waypoints automatically as transition, even when they are embedded in an existing transition. That´s correct. But that doesn´t reflect in the data (means, you don´t have a own WAKER transition in the Garmin data - the Garmin device itself reads the IAF waypoints and put it into the transition list). There are no additional records (as in the MSFS stock data) for that logic in the data - all this will be handled by the Garmin device itself. A typical example for that is the new TDS GTNXi, where you can see this four transitions but the data contains only the three transitions as the FAA offers.

  3. the four transitions in airliners are NOT correct - there are only three transition listed. Airliners follow exactly the ARINC424 data (excl. possible tailored records per airline) and here (as I have shown in the FAA data) WAKER is not coded as transition

I have compared the stock data with the FAA data and there are a lot, lot more transitions added comparing the original FAA data. Personally, I can´t really believe that the FAA had “forgotten” to code so many transitions. I assume, that this additional “transitions” are added for the Garmins, that the Garmin devices are reflecting the reality.

Last, possible I´m completely wrong - but what is the reason, that the FAA (and also Jeppesen & Lido) doesn´t code embedded IAFs in transition as own transition then?

Cheers,
Richard

1 Like
4

Interesting. I’m not super familiar with the particulars of the AIRINC coding/data rules, so I’m approaching what you’re stating from the perspective of an instrument rated pilot and instrument ground instructor. My apologies if I’m misunderstanding something, but that’s why I’m here to discuss - your conundrum caught my eye and from an operational standpoint, point 1 doesn’t make sense. But I get what you’re saying in point 2.

Bottom line, if I see an IAF printed on an approach chart, I absolutely, 100% expect it to be selectable as a transition in a Garmin unit (or any other navigator). I’ve never seen an IAF behave otherwise. If it was only meant to be an intermediate fix as part of the FIM transition, then FIM would be the IAF and WAKER would just be an IF, and as such, unselectable as a transition.

FWIW, I can also select WAKER as a transition in ForeFlight, with current nav data (the transitions are listed exactly how your picture of the sim Garmin is showing it). I’m not sitting in front of the G1000 in the actual plane I fly right now, but I suspect if I were, I could select WAKER. It sounds like you’re saying this is typical, intentional behavior from a Garmin, as it automatically recognizes IAFs (per your point 2).

With regard to your point 3, I’d be surprised if airliners didn’t include each IAF, but I don’t fly airliners and that would be a learning experience for me if true. My gut suspicion is the data aren’t in alignment somewhere, but that’s a theory based on my real-world experience with Garmins, which, as you say, behave differently.

But I definitely am on the same page with you now as to the nomenclature you’re using - I just saw it differently due to the rules and nomenclature we’re interpreting and have experience with. Bottom line, if I couldn’t select WAKER, I’d be calling someone to report it.

Very curious to see the outcome of this.

1 Like
5

Also, I’m trying to look this up in AIRINC and PANS-OPS to get a better understanding.

Either way, per FAA regulations, the approach must begin at an IAF (or in some rare cases an IF), so if the IAF was not selectable, or a feeder route masquerading as an IAF was the only thing selectable, it would be a clear hazard to navigation or violation of regs, airliner or otherwise. That’s what’s ringing my alarm bells.

1 Like
6

The sim navdata contract is such that all IAFs should be broken out as individual transitions even if not strictly defined as such in the AIRAC data, for a number of reasons:

  • Some avionics may want to select and use those IAFs as transitions. Because the way the sim flight planning system and ATC work, these transitions are referred to by their index in the array of available transitions.
  • There is not a way of defining a “synthetic” transition and synchronizing it with the sim systems. You could select the transition index that includes the IAF you want, but then ATC and sim systems would include fixes not strictly in the plan you’ve chosen.
  • The world map must have a superset of all selectable transitions that could be used by any avionics system, or else it is possible that users would not be able to select transitions that they otherwise could in the destination avionics.

Avionics that do not want to use those IAF transitions are free to ignore those by filtering based on duplicated legs or other metadata/data.

Thanks,
Matt

7

Interesting anwer, but expected.

Funny “solution” leaving the standard (see the FAA data) and expecting from 3rd party addon devs to develop something to get back the standard :rofl:

But now, we know that the in-game data structure doesn’t really follow the real world data structure.

Thanks for the answer & Happy Easter
Richard

8

I don’t particularly see what’s funny about it.

Each avionics system deviates from the standard as it sees fit; more avionics than just Garmins allow for IAFs as selectable transitions even if not explicitly called out in the AIRAC or even in the 424 spec. So, we just decided it was the most practical to codify the superset of all possible choices to make for the most flexible system we could provide for both developers and users, and furthermore doesn’t require very advanced processing of the source data to do so (even us simpletons managed to do it pretty easily).

We understand that for those folks who might not be thinking from a consumer or developer standpoint, they may see the data itself as being the standard, but the data is just the data, and should be formatted best for the most global usage possible in all possible avionics systems, since the sim does not have the luxury (unlike your custom format downstream developer consumers do) of tailoring to a specific system choice.

Hope that helps,
Matt

9

So “By Design”, with the design decisions now being made public.

So the question now may be, will Navigarph conform to the MSFS design rules for nav data for MSFS, or stick with a strict FAA data spec
(or do multiple versions ! )

10

Hi Geoff,

AIRAC 2403 revision 3 is out now.

From this revision on, we add now all “embedded IAFs” as own transition in the data too.

Here are a few examples, made with AIRAC 2403 revision 3:

EUROPEAN area:

ESPA_ILS32
ESPA_ILS32385Ă—745 280 KB

LFMO_ILS14
LFMO_ILS14385Ă—745 253 KB

LEMG_VOR31
LEMG_VOR31391Ă—759 290 KB

LOWG_ILS34C
LOWG_ILS34C388Ă—733 259 KB

ELLX_ILS24-Z
ELLX_ILS24-Z390Ă—744 285 KB

US area:

KLAX_ILS06L
KLAX_ILS06L327Ă—748 288 KB

KRBL_RNAV33
KRBL_RNAV33376Ă—747 275 KB

KABI_ILS35R
KABI_ILS35R394Ă—742 278 KB

Hope that helps
Richard

1 Like
11

Quick question - I haven’t ever really looked too closely at state codes in the Garmin to know whether this is normal behavior. I see CA is correct, but shouldn’t Abilene be TX? Or is it just cutting it off after the first two letters of the full spelling of the state?

12

Right, Abilene is Texas and also we have TX in our data source but this information is from the MSFS itself and don’t come from our data.

Cheers
Richard

13

Oh wow. That’s really not good. You could see the confusion if one were to pull up an airport in Las Vegas: If I’m understanding this correctly, Las Vegas, NV (KLAS) and Las Vegas, NM (KLVS) would both show as Las Vegas, NE, which the state code for Nebraska. To add to the confusion, Nellis AFB is KLSV, which is way too similar to KLVS to make this trivial. Either way, part of checking whether I’ve got the right airport is the state code.

Surely I can’t be the first to notice this (and I don’t know if it’s newly introduced or an old thing). But if it’s in their data, where do I file a bug report?

14

As a follow on to my last question, would you be so kind as to isolate and show where this is in the data so that I can make a bug report that points right to the relevant data? I don’t want to waste your time, but this is a really bad look.

Personally, I can’t believe this is even a thing.