Offset (ILS / LDA) Approach Issues

[CaptainRude91]

Problem

There are two big problems concerning ILS / LDA approaches, in short:

• Currently all approaches which are offset in real life are aligned with the runway course in MSFS, see my Innsbruck (LOWI) example below.
• Bearing pointer or RMI give bearings towards the localizer antenna, this is impossible in real life.

---

Innsbruck Example

If we take Innsbruck - LOWI airport as an example, there are two main navaids:

• The runway headings are 078 / 258 degrees.
• LOC / DME OEV is located at the airport and is used for the LOC / DME East approach to runway 26 which is offset in real life. This localizer should be aligned with the Innsbruck valley with a front course of 255 degrees, in MSFS however the localizer is aligned with the runway (258 degrees).
• LOC / DME OEJ is located approximately 10 nm off-airport and does not end up at any runway. This localizer should have a front course of 066 degrees and a back course reciprocal of 064 degrees. When following this LOC on approach you will pass the airport on the right at 7500 ft, you’ll then need to circle for either runway. Although this navaid is not related to any runway, both the front and back courses in MSFS are 078 deg, following it puts you in a dangerous location…

This blows my mind really, this is such an iconic airport and it is one of the “hand-crafted” ones. Its unbelievable that they got the primary navaids so wrong. Note the blue bearing pointers in the screenshot below pointing to both the localizer antennas. This is impossible in real life.

Turns out that if you fly the LOC DME east approach in MSFS you’ll end up flying parallel to the runway into the grass, as can be seen in the picture below:

This means that the geographic location of the localizer antenna is correct in MSFS. In real life the antenna is indeed located to the left of the runway into the grass but at an angle. The offset will cause you to end up over the runway threshold in real life before going into the grass when tracking the localizer. I have flown this very approach in real life down to pretty much minima, and you’ll definitely end up at the threshold eventually. You will see the lead-in lights on the left when breaking out of the clouds at minima, from that point you normally disconnect and visually line-up with the runway.

RMI pointing to localiser Antenna?!

I don’t know if anybody else noticed, it’s kind of funny in a way and sad at the same time considering Asobo don’t seem to understand how a localiser works. I was flying the TBM on arrival (base) with the ILS frequency tuned on both sets and bearing pointers set to NAV 1 and NAV 2. I noticed they were actually pointing towards the airport. I’m talking about the bearing pointers here (blue needles) and NOT the CDI. That is weird obviously as in the real world bearing pointer will never point to…

[HalberQuacky]

This is not a bug in the sense of being a programming error. This was a deliberate design choice by Asobo.

This problem is caused primarily by a 4 byte value contained in the specific airport’s APX BGL file. The bytes are a 32-bit integer value derived from the localizer’s identifier using a standard algorithm which can be found in various BGL documents at places like fsdeveloper.com

The presence of those 4 bytes forces the localizer to the runway heading, even if the nav data (which is contained in a separate BGL file) contains the correct localizer heading. There is no question in my mind that the developers at Asobo did this on purpose. I have no idea why. My theory is that (perhaps) out of “aviation naïveté” they may have mistakenly assumed that all localizers must be exactly aligned with the runway centerline, not realizing that many r/w localizers are deliberately offset for very good reasons (as at LOWI).

Asobo has also modified the localizer course contained in the default NavBlue data files (that control the placement of ILS facilities in-game) to set every single localizer to the exact runway heading, even when the real-world data is different. The NavBlue data is what controls the automatic course setting on the PFD when an ILS is tuned on Nav 1.

The Navigraph beta nav data, which overrides the default NavBlue core data, will give the correct published localizer course on the PFD, but the airport BGL also has to be edited to make it work properly.

If the 4 bytes in the APX file are changed to all zeros with a hex editor, then the offset localizer will work perfectly, provided that Navigraph nav data is also installed.

I have made this modification on my own system to fix the offset localizers at KJFK 22R, KDTW ILS-Y 04L and 22R, the two localizers at LOWI, and the 40 degree offset LDA approach for runway 19 at KDCA, and all work exactly as published. The aircraft will approach the runway at an angle, with the correct ground track, and cross the centerline at about the MDA point.

Unfortunately, whenever there is a new sim update released, it typically puts the modified airport BGL files back to defaults.

The Navigraph beta nav data automatically fixes all the incorrect course settings insofar as the Nav receiver is concerned, but it also requires doing the modification of the airport APX BGL file to actually make the offset and LDA localizers work correctly, and that is not something Navigraph can do.

Again, there is no question in my mind that Asobo has done this on purpose. I wish they would stop doing it.

The fact that the RMI will point at a localizer is a definite bug. That (I would think) would be an easy fix - just disable the RMI pointer when an ILS frequency is tuned on the Nav receiver, which is exactly what a real airplane does if equipped with a mechanical or electronic RMI.

[Norman999933]

Please fix this Asobo! In some locations it’s critical to being able to simulate IFR correctly.

I’ve said this in multiple threads, but I’ll say it again.

It’s becoming abundantly clear that Asobo have not invested sufficient resources into ensuring they possess, or have access to, aviation specific technical support/knowledge. They are making to many bad/ill informed decisions based on false assumptions or ideals.

[FlyingBear01]

Totally agree with the points made above:

• Offset approaches are common, and they are broken.
• The reason that happened is probably just ignorance. After all, if you don’t know, how could you know? It is not like IFR procedures are taught in high school, it is not common knowledge, unless you have been exposed to them or have had a reason to learn about them you won’t know about them.

It was rather telling when Jayne asked the question about LDA approaches in the latest Q&A and just got blank stares back.

The good news is that it seems like a trivially easy fix. Just fix the bad bits in the .bgl, and I am sure it would not be hard to bring on the necessary consultants to give some good input on real-life instrument procedures.

[N6722C]

@FlyingBear01

It was rather telling when Jayne asked the question about LDA approaches in the latest Q&A and just got blank stares back.

Yes, that must have been asked and dismissed in about 10 seconds !! So short that when I go and look at the video again, I cannot even find it by short skips … I know it’s there, I heard it …but finding it again … a needle in a haystack.

[marsman20208043]

Is there a way to query the BGL files and Navblue data find all localizers where this is the case?

The FAA and ICAO allow approaches up to 3-5 degrees of offset to still be called LOC or ILS. (The threshold is different around the world)

If we ask the devs about LDA approaches and they Google it they get a page that says there are only a handful of these in the world, but the reality is this is impacting 100s of approaches.

If we could generate a list of all of them, the large qty might get more attention.

[PZL104]

@marsman20208043

The FAA and ICAO allow approaches up to 3-5 degrees of offset to still be called LOC or ILS.

A very good point!

Hopefully Asobo fixes these approaches!

Being able to fly a LOC approach into LOWI would be nice

[N6722C]

Well, fixing 100 specified airports should not be too big a task, but maybe just fixing them all, with a blanket update, might be just as quick.

If Asobo really has set airports to use the runway heading for their ILS or LDA, because they are setting that heading intentionally into the field that FORCES an overide of the ILS heading, then maybe all they have to do is just re-generate the the airports with that fieled set to ZERO. (Or whatever it takes) … If it can be automated, instead of being done manually just on specific airports, it may well be quicker.

This would have the advantage of ALSO correctly setting the airports that only have an offset of a few degrees … they ALL get set correctly – and everyone is happy. – and going forward, this should never happen again, even if nav databases are updated.

[N6722C]

If during Alpha Testing, the Testers reported this … and I cannot see how some would not have done … its a pretty obvious bug … then Asobo must know about the issue …

So maybe the look of surprise when it was brought up in the Q&A , was not surprise, but just good acting ? I really hope it was - because otherwise , one has to conclude that there really was a lack of communication, when this was reported by the testers.

[Norman999933]

Reading the correct value from the navdata must be the correct long term solution for this.

[N6722C]

Well, I must admit I am not fully understand the data format etc, all I know is, as a Pilot, it’s wrong.

But if LittlenavMap can read the data from MSFS, to generate its maps, and the maps get drawn with the correct LDA, then the MSFS data must be correct ? and its just the way that MSFS is incorrectly reading its own database, and messing with the ILS headings, using the Runway heading instead of the ILS heading from the database to feed the Instrumentation. In that case, it should be a REALLY easy fix !!! ???

Is that correct, or am I missing another step that is wrong here ??

[marsman20208043]

I have heard there were 14,000 tickets generated during the Alpha/Beta, and most of them were not addressed. But that’s all under NDA so it’s just rumors.

[N6722C]

what a rumor … another rumor is that Alpha testers may not even have copies of their NDA, to check its conditions, and the NDA may well have Expired when MSFS was released. so many Rumours

[marsman20208043]

LittleNavMap, when reading from stock MSFS, also draws the ILS incorrectly, because Asobo have overwritten the ILS headings in the NAV data BGLs with the runway headings, in addition to setting bits in the scenery BGLs that forced the ILS to the runway heading (so they have broken it twice)

Only the paid Navigraph data + modified scenery BGLs fix it at this point.

To fix it Asobo would have to re generate the nav data BGLs and leave the correct ILS heading data from Navblue, and also un-set the bits in the scenery BGLs for the airports.

[N6722C]

Hold on – I look at LNM and it draws the LDA 19 @ KDAC Correctly …
Both of them LDA Y & LDA Z
and if you llok at Google Map, you can even see the Antenna array, at the same location in Google, as it is on LNM

[marsman20208043]

Do you have it set to use only the MSFS scenery data, or is it in the mode that uses a built in set of old Navigraph data to draw navaids?

[N6722C]

I need to check 'again" and remove any addon DCA scenery !!

[N6722C]

To use MSFS data …
Going to fire it up now, and re-load the LNM scenery files from MSFS
I’ve been up to many early ours, messing with this – just never makes any sense !!!

[N6722C]

@marsman20208043

Do you have it set to use only the MSFS scenery data, or is it in the mode that uses a built in set of old Navigraph data to draw navaids?

LNM - KDCA’s LDAs No MODS … Looks correct to me !!!

This would seem to indicate to me that the DATA is right, so it must be the MSFS 'engine" that is getting the heading data for the ILS/LDA that is using the runway heading, instead off the data for the LDA and suppling that, via SimConnect to the Instruments ??

When I “load user Airspace” I get the following error !!

212 CZFA:ZFA:FARO:FARO:CANADA:062:012:027:N:133:022:033:W:00717:62.208:-133.376
213 CZFM:ZFM:FORT MCPHERSON:FORT MCPHERSON:CANADA:067:024:028:N:134:051:037:W:00044:67.408:-134.860
214 DAAB:N/A:BLIDA:BLIDA:ALGERIA:036:030:013:N:002:048:051:E:00164:36.504:2.814

Lines 212, 213, 214 look OK to me … same # of fields etc

and that file has not chaged since Release day !!!

Just Opened another “Pandora’s Box” !!!

[CaptainRude91]

I did went through all my bug reports in Zendesk since release and there isn’t even one fixed so far…