I think you misunderstood what I was trying to explain.
My assumption is that this Nav Receiver bug has been fixed with SU4, and is using the ILS course/offset from the scenery. If Asobo fixed those offsets in the scenery is a completely different topic (for me Navigraph is used anyway).
My fix ils script is removing the link bytes you mentioned, and after SU4 it does not matter if the ILS is referenced from the runway section in the bgl or not, the Nav is always following the ILS course from the scenery.
Only exception I could find is LFMN, which is why I think there is something weird in that scenery itself, which has nothing to do with the Nav Receiver.
The thing is that this behavior is not a âbugâ. Asobo deliberately coded the Nav receiver to work this way, as evidenced by the fact that all localizer courses in the default scenery have been deliberately set to the exact runway headings so that they will match what the Nav receiver is going to âdoâ when tracking the localizer.
They either instructed NavBlue to do this, or more likely, edit the localizers themselves before publishing the nav database updates to the sim. Navigraph, of course, sets all localizers to the exact published headings in the government source data.
As you know, in the default MSFS Garmin Gxxxx units in the sim, the ILS course cannot be adjusted. When a localizer is being received, the course on the CDI locks to the localizer course in the nav data, and turning the course setting knob has no effect.
This is not necessarily a âbadâ thing - many r/w FMS-equipped airliners will auto-tune the Nav receiver to the ILS frequency of the loaded approach, and auto set the inbound course - but the course can still be adjusted if need be in such aircraft.
I can see why Asobo might have thought implementing such a system would be a good idea. They were certainly aware that MSFS would draw a large contingent of customers completely new to flight simulation - people with no previous experience with flying simulated ILS approaches, and many not using r/w charts, or unaware of how to obtain such charts. This system was probably a simplification for the benefit of ânewbiesâ.
Setting the localizers to the exact runway heading is fine for the vast majority of ILS approaches where the localizers are indeed aligned with the runway heading. Being ânewâ to flight simulation themselves, Asobo might not (originally) have even been aware that some r/w localizers are offset, and did not foresee what the result would be when using the correct r/w lat/lon coordinates for the offset localizer transmitters, but the incorrect r/w headings.
I think they found out after the sim was released that this was a big problem when MSFS pilots started flying the LDA 19 approach on Vatsim, because the incorrect localizer course would force aircraft to fly right through the prohibited airspace in central DC that the LDA approach was specifically designed to avoid. It appears their âfixâ was to put the correct 149 degree localizer course in the nav data, and disable the routine in the Nav receiver code that looks for the ILS/runway link bytes âif airport == KDCA then skip localizer adjustmentâ.
The receiver readjustment code probably has a list of airport ICAO identifiers where the readjustment will not be applied - certainly KDCA is one such - there are probably others.
I assume the code in the Nav receiver goes something like this:
ââââââââââââââââââ
Scan selected approach from Garmin or FMS
Set frequency from nav data
Set CDI to nav data course (from NAX file)
IF (ILS/runway link bytes exist in APX) THEN set localizer in scenery to runway heading
ââââââââââââââââââââ-
Since your script removes the ILS/Runway link bytes, the last part of the above code will not execute, the localizer will be âleft unmodifiedâ, and (when used in conjunction with Navigraph) all offset localizers will be flown correctly.
The big question is: did Asobo indeed âdo awayâ with the above (assumed) âreadjustment codeâ in the Nav receiver in SU4?
It would be great if they did, but I have reason to think it is still active. If they did remove the âreadjustmentâ code in the Nav receiver, then they should also have set the localizer headings in the default nav data files to the correct r/w values - (as Navigraph does). But, the new nav data released with SU4 still has all localizers set to exact runway headings - even when they should be offset - with the exception of âknownâ fixed approaches like the KDCA LDA 19.
This may have been a simple oversight that will be fixed in the next nav data update in June but if the readjustment routine is still active, then of course they would not have changed the nav data.
I am shortly going to fly two known offset approaches in the default G1000 C172 that have never worked properly in the past even with Navigraph installed - the KJFK ILS 22R, and the KDTW ILS-Y 04R.
If the C172 does now fly these approaches correctly, I would take that as solid proof that the Nav receiver âreadjustment codeâ has indeed been removed - meaning your script is no longer necessary. In that case, all Asobo needs to do is fix the default nav database and the problem is fixed for good.
BUT if it still flies them incorrectly, I would take that as equally solid proof that the readjustment code still exists in the Nav receiver.
I will report back with my findings.
1 Like
No! The LOC course is fixed and canât be modified or adjusted in the aircraft.
Regardless of the set course, the FD/AP will always show the correct LOC deviation and track the correct LOC course.
That would be exciting, when Asobo release charts also - because then everyone will ask, why the published course on the charts is not the same as in the data. Ok, possible that they re-draw the charts also 
Cheers,
Richard
1 Like
You misunderstood. Yes, the deviation of the localizer needle depends solely on the aircraftâs spatial position in relation to the localizer beam. Setting the LOC course in the HSI has absolutely no effect on the ability of the autopilot to capture or track the localizer.
Setting the actual localizer course in the HSI is only for the pilotâs situational awareness so that he will see the localizer in the correct orientation in relation to the aircraftâs current heading. Even if you were to set the localizer course in the HSI at a right angle to the correct course, it would still capture and track with no problems.
My point is that even in aircraft that preset the course in the HSI from the nav data, the LOC course can still be rotated in the HSI with the CRS knob. For aircraft that do not have a couse preset function based on the nav data , setting the localizer couse in the HSI to the published heading on the chart is part of the pilotâs routine when setting up for the ILS.
My observation is simply that in default Asobo aircraft, once an ILS has been tuned and received, the course knob becomes inoperative. Rotating the course knob has no effect on the CDI pointer. I have never seen a real-world aircraft that does that. In fact, one of the avionics functional tests in the r/w CRJ is to set up the autopilot to capture a localizer (using an external ILS signal simulator), and then rotate the course knob through 360 degrees of rotation and insure that the captured localizer does not unlock.
1 Like
Confirmed! With Navigraph installed, both the ILS22R at KJFK and the ILS-Y 04L at KDTW are flown correctly with the default G-1000 C172.
Apparently, Asobo has indeed finally removed the âlocalizer readjustmentâ code from the Nav radio. Good news!
But - they still need to fix the default NavBlue navdata - where all localizers are still set to exact runway heading (including those which are actually offset) - otherwise those who do not use Navigraph are still going to have incorrect offset localizer tracking. Now the aircraft tracks the actual localizer course, but with default nav data, the localizer course itself is still wrong. It will cause the same âoff runwayâ landing, but for the opposite reason as before.
Hopefully, it was simply a case that there was not enough time to fix the default nav data in time for the release of SU4. I guess we will see if there is a change when the next AIRAC update comes out on June 17th.
Or⊠they could simply cede the core MSFS nav data market to Navigraph. That would be my preferred solution. 
Not only is the locked CDI nonsense, the autotune function is as well unrealistic in aircraft without FMC, and even then it would only work with an active flightplan.
Btw. The AP in the CRJ 100 was so stupid that it actually started to turn away from the LOC if you changed the course on the CDI!!!
I assume that both of these âfeaturesâ are in the category of âmake things easier for new usersâ category. No big deal, but it would be nice if they made it optional.
Thanks for confirming. I think that also confirms that something is off with the LFMN scenery, tried also with the optional LFMN package from Asobo uninstalled and same result (which was to be expected as the optional package does not seem to touch anything nav related).
I was inspired to re-try the offset ILS at one of the airports I mod in light of the info being shared in this thread.
Every previous attempt to make the ILS match the real world offset failed and aircraft instrumentation always forced the default runway heading on the instrumentationâŠeven though LNM showed up the correct ILS I had supposedly set the sim to use.
After rebuilding the modified airport bgl today I am delighted to see that the offset ILS is indeed working and is accurately shown in the cockpit and followed by autopilot.
This is such a great step forwards!
Iâm a little bit confused about this ILS problem. I was flying in China a lot, and almost every airport I tried to land at I ended up next to the runway if I kept following the ILS.
Then I pulled up the chart of the MSFS data in Litte Nav Map, where I could see one of my many botched landings.
You can clearly see the green ILS line running next to the runway. This seems to be a problem in a lot of airports there.
But from all I have been reading on this forum I understand this âoffsetâ might be true IRL? Or are people talking about different offsets?
I was the black dashed line, trying to correct last minute⊠that didnât end so wellâŠ
So frankly, Iâm getting a bit upset with this promise I could go anywhere in the world if I now have to check every airport I want to fly to, to see if the ILS is actually on the runway or notâŠ
Or is this simply on me and can the ILS indeed be this far off IRL?
Which airport/approach is shown in your example above? Iâll have a look at the RE chart for you to check.
The example was Chendu⊠ZUUU.
But looking at for instance ZUCK, even worse⊠completely misaligned.
Then thereâs ZUGY, which has two ILS tracks (so letâs say 4 beams) but only one runway.
Almost every airport in China which I checked was âoffsetâ (or misaligned).
Clearly some are in error, but if this âoffsetâ thing is real, I canât determine that per airport with only the MSFS data.
I was also wondering if it is âfixableâ by looking at the airport files? Assuming itâs all error⊠can we hack this stuff ourselves and shift the ILS data? Not that Iâm looking forward to such an exercise⊠probably all lost again with updatesâŠ
I just checked all 3 airports you mentioned, and the Jeppesen charts indicate all ILS signals should be exactly runway aligned, for all runways.
Seems there is a problem with incorrectly positioned ILS antennas, separate from the incorrectly working offset ILS/LDA issue.
As for ZUGY, it has 2 runways in the real world, hence the 4 ILS signals. If the MSFS version only has one runway, this is probably due to outdated data be used initially to âbuildâ the airport, than updated NAVDATA being applied on top.
1 Like
Okay, thank you. Thatâs helpful to know.
I guess if I want to land there I need to train my manual skills a bit. Little Nav Map at least helps to predict itâs gonna be a bumpy landing 
But quite annoying, so many wrongâŠ
With a true (intentional) offset localizer the localizer will guide the aircraft to the runway at an angle. If the localizer is exactly parallel with the runway, that is a sign that the localizer antenna is misplaced in the scenery.
2 Likes
Concerning the approach that âdidnât end so wellâ.
Thatâs the reason why the minimum is higher with an offset LOC, at least 300ft.
In case of ZUUU itâs in MSFS obvious that itâs not an offset, but simply a misplaced LOC antenna.
As previously explained, an offset ILS means that the LOC course is different from the runway heading.
IRL the LOC intersects the centerline of the runway latest over the threshold.
Usually a few hundred meters before the threshold.
That way you only need to make a single shallow turn to align with the runway centerline.
With the misplaced LOC in MSFS you need to make 2 turns.
Since MSFS canât simulate very bad visibility (CAT II, or III) you should have enough time for the correction.
IRL with an offset LOC you are starting the alignment as early as possible, e.g. at 500 or even 1000ft.
The further away from the threshold, the easier the alignment turn(s).
Latest at the minimum (300ft) of course.
2 Likes
The question then becomes, why are so many ILS antennas misplaced, parallel to the runway? Especially as this seems like an extremely common issue.
Surely the ILS position is accurately recorded within the relevant source NAVDATA, so why are so many in the wrong place?
@ememPilot That is because China is weird, they donât use the WGS84 geodetic system like the rest of the world and have an intentional offset on things like street maps. So I think the problem is with Bing maps being offset from where things really are.
I donât know it it is still the case but I remember that when flying in certain countries (China included) GPS updating needs to be switched off as those coordinates are using a different geodetic system compared to NAVSTAR GPS.
Maybe MSFS or NAV BLUE have converted coordinates of everything into WGS84 so might not be a problem⊠But anyway, not something which will be fixed anytime soon.
2 Likes