plane icon Welcome to Microsoft Flight Simulator’s SDK Q&A Platform!

Save the date ! On February the 9th, at 10:30am, we will be happy to meet you again for a live SDK Q&A ! You can already ask all your questions here on the forum.

You have questions regarding the SDK? DevMode Tools? SimConnect? You would like to submit an idea for future improvements, seek help or exchange knowledge? You’re in the right place.

Please take a moment to read the platform’s guidelines before you get started!


question

jpschuchna avatar image
jpschuchna asked lonewulf47 edited

Localizer handling - should be based on TRUE only

Hi,

MSFS at the moment replicates how Localizers are stored in ARINC 424 files (True + Magvar + Magnetic Inbound CRS) with all its bad consequences for the MSFS environment.

To get a properly aligned Localizer on extended MSFS centerline, the combination of coded Magvar and Inbound CRS in the Localizer definition must always match the exact RWY true of MSFS.

The coded Inbound CRS is on top used for the Autotuning of the Inbound course.

If the calculated RWY Heading (True + Magdec.bgl) and the Autotuned course differ, it may result in negative consequences when it comes to Autoland behavior of several aircrafts as the Autopilot tries to correct against an imaginable crosswind which is not there. This is as well an issue in Real Life:

https://www.pprune.org/tech-log/477036-airbus-ils-course-3.html

This is also one of the reason why PMDG did is as follows when tuning the Inbound CRS for P3D:

"CORRECT LOC CRS TO P3D: When it comes to navigation data, P3D has an inherent weakness in that data related to ILS/LOC stations is hard coded into the simulator and is not updated to keep it current with the normal magnetic shift. The end result is that the localizer final approach course in the P3D world will sometimes vary from the real world. Since many users are also using real-world navigation charts, this can create some confusion and can also create problems if the LOC course is not correctly set to match the P3D hard-coded information. (The airplane cannot fly the localizer properly if the CRS on the CDU NAV RAD page is set incorrectly) To compensate for this, we recommend setting this option to ON, and we will read the appropriate P3D localizer course and adjust the setting for you, thus saving you time and frustration."

The best way would be, if Asobo would go back to the old FSX/P3D way and code Localizers only with the true value (same as currently RWY) and do the Magnetic Autotuning based on the True + Magdec.bgl value. (As PMDG does for P3D)

Then we might see again small differences to charts but those are negligible compared to bad autopilot behavior. The Magnetic value would then be the result of True + Magdec.bgl. Since that always is the most up to date value based on the newest available Magvar models
when updated by Asobo or via Herve Sors ( https://www.aero.sors.fr/navaids.html). State source AIPs would naturally differ by a few degrees (1-2 in most cases) depending on how well they are maintained.

At the moment there should not be any differences to charts since Asobo (Navblue) or Navigraph (Jeppesen) reflect Inbound Courses from ARINC files. As state source AIPs are notoriously unreliable in keeping the Inbound Courses harmonized to a single Magnetic Variation value (e.g RWY published with 100deg in combination with 23°W but ILS Charts still published with 099deg and 22°W and so on), The current ARINC 424 based approach now just copies those inconsistencies from state sources into the MSFS world and makes life harder for everyone.

Another Idea for improvement is to always automatically align non offset Localizers with the RWYs in MSFS. Only alignements for offset Localizers should still be taken out of ARINC 424 files. The low resolution coordinates that state source AIPs provide are sometimes not precise enough for the MSFS world. Non offset ocalizers should always be aligned to the MSFS extended centerline.


Jan-Paul


Navigational Database Engineer.




bug
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

FlyingRaccoon avatar image
FlyingRaccoon answered

Hello @jpschuchna and thank you for the detailed feedback.

There already is some kind of automated realignment process on LOC.
Unless we missed something, the info about whether it's an offset LOC or not is not explicitly provided so we try to guess based on a set of other infos.
But the racquet can have holes...

Do you have a list of approaches were the LOC is not correctly set up, that we could check in order to improve that automated alignment process?

Regards,
Sylvain

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

jpschuchna avatar image
jpschuchna answered jpschuchna edited

Hi Sylvain,

thanks for your answer. My primary concern would be the Magnetic vs. True Alignement handling. That should be fixed first by going back to using only True values for aligment of the Localizer antenna (same as currently for RWYs)

When that is done, one could think about ways to further improve the Localizer alignement for non offset Localizers.

The info wheter a Localizer is offset / non offset is stored in the ARINC 424 file that you get from NavBlue. Same applies to Jeppesen (Navigraph and Lido (Aerosoft). But depending on the resolution of the stored coordinate, the flag could be misleading so that a combination of multiple ARINC 424 fields need to be taken into account.

As a first step following ARINC 424 records could be used to figure out wheter Localizers are placed on the extended centerline or not:


"5.48 Localizer Position (LOC FR RW END) Azimuth/Back Azimuth Position (AZ/BAZ FR RW

END)


Definition/Description: The Localizer/Azimuth Position field defines the location of

the facility antenna relative to one end of the runway.

Source/Content: The field contains the official government source distance, in feet,

from the antenna to the runway end. The resolution is one foot.

Used On: ILS, MLS and MLS Continuation records

Length: 4 characters

Character Type: Numeric

Examples: 0950, 1000"


Distance values could be limited to a certain range e.g 5000ft beyond RWY end to narrow the search area.


"5.49 Localizer/Azimuth Position Reference (@,+,-)


Definition/Description: The Localizer/Azimuth Position Reference field indicates

whether the antenna is situated beyond the stop end of the runway, ahead of or

beyond the approach end of the runway. The Back Azimuth Position Reference field

indicates whether the antenna is situated ahead of the approach end of the runway,

ahead of or beyond the stop end of the runway.

Source/Content: For Localizer and Azimuth positions the field is blank (@) when the

antenna is situated beyond the stop end of the runway, it contains a plus (+) sign

when the antenna is situated ahead of the approach end of the runway or a minus

(-) sign when it is located off to one side of the runway. For Back Azimuth positions

the field is blank (@) when the antenna is situated ahead of the approach end of the

runway, it contains a plus (+) sign when the antenna is situated beyond the stop end

of the runway or a minus (-) sign when it is located off to one side of the runway.

Used On: ILS, MLS and MLS Continuation records

Length: 1 character

Character Type: Alpha"


Note: Due to low resolution coordinates this flag might be misleading. Further comparisons using RWY and Localizer True might needed to be done to verify if it is really a non offset or offset localizer.

As that might still not solve all edge cases, the user could also decide wheter he wants to align localizers at certain airports / RWYs after visual inspection of the situation using the satelite image.
That decision could then be stored in MSFS for future updates of the database, so that it remembers the correction.

Examples:

https://forum.navigraph.com/t/wmkp-ils-is-offset-from-centerline-its-localizer-coordinates-seem-wrong/4753

https://forum.navigraph.com/t/lfbo-ils-31r-slighlty-to-the-left-of-the-runway/5078/7

https://forum.navigraph.com/t/ils-no-aligned/6625/2

The placement and elevation of the GP antenna for the Glideslope might be as well affected by low resolution coordinates and wrong elevation values. Some states tend to publish the height of the antenna and not the elevation. Elevation could be compared and changed to MSFS elevation at that position and placement should be aligned to MSFS touch down zone. For edge cases user decision might be necessary as well.

Additional Note regarding encrypted airports:

Ground layout should be made readable by external add ons.
- Aprons, Parking Stands, Taxiways, RWYs, (Navaids if stored locally on airport level)

Some AddOns like FS2Crews RAAS or Aivlasofts EFB depend on those informations in order to work properly. Buildings itself could still remain encrypted.



10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

FlyingRaccoon avatar image
FlyingRaccoon answered

Hello @jpschuchna

The LOC true heading is not used because we found it was causing some alignment issues as well. The info we get appears to be sometimes generated from the Magnetic heading and outdated magvar and therefore false. That's why we went for the alignment post process.
The alignment post process is done considering true heading and then converted back to magnetic and magvar.

We were able to identify issues with the examples you provided.
In those cases, the LOC position provided by ARINC and AIP is false and that's not something we were looking for.
We can add a step in the alignment process to reposition the LOC in such cases so we can ensure non offset LOCs are correctly aligned with MSFS runways.
Note that this would only apply to the MSFS navdata, not the one provided with custom packages.
If Navigraph is writing heading and magvar as is in their MSFS navdata package, this will lead to similar problems.

Thanks for the tip about how to identify non offset LOC in ARINC, this will be useful.

Regards,
Sylvain


10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

jpschuchna avatar image
jpschuchna answered jpschuchna edited

Hi Silvan,

The issue is not the alignement itselt, it will alwas be more or less correct when relying on ARINC 424 data.

The issue is using magnetic heading and declination in combination for the construction of the localizer beam when you can get the same result by just using one single value (True)

Using True would make it much easier to implement corrections afterwards by editing it, since you only need to change one value and you don`t have to play around with two values to get the correct aligments of the antenna. Also aircrafts systems will have it much easier tuning the correct inbound course always matching the RWY Heading which is based on True + Magdec.bgl. Autopilot Localizer tracking depends on the fact that sim heading based on Magdec.bgl + True at current position and tuned course are always the same. No matter whether a Localizer is offset or not.


Magdec.bgl istself is of course updateable via the mentioned link and was recently updated by Asobo as well:

RELEASE NOTES 1.20.6.0

  • Updated the in-sim Magnetic Variation model


State sources as well rely on the same models, so that the Magnetic tracks will be as close as they can get automatically when this file is updated at least each five years.

The ARINC 424 Localizer generation in itself is already some sort of a workaround trying to translate Magnetic based source information into back into True since FMS systems were designed to use the Magnetic value for the CRS tuning and Charts for Pilots also show Magnetic in most parts of the world.

In real world, the localizer is attached the ground and its alignment is therefore based on True only. There is no Magnetic + Declination values to play with unlike with a VOR/DME for alignement. So the aircraft will track it perfectly fine and the tuning of the CRS could be adjusted if needed when wrong.

In MSFS, it would now just tune the wrong hard coded CRS which may differ for the sims own Magnetic Heading. That is where the issues start.

Therefore you should go back to align Localizers based on True values only, avoiding errors that could result of two variables. With True you would only have one variable that might needed to be adjusted in case of misplaced localizers.

In Areas with high Magnetic variation (Canada, Alaska, North Pole, South Pole) navigation and charts are based on True North. If MSFS continues to use Magnetic Values for Localizer alignements, this will create issues tracking Localizers in those areas as the Magnetic values change very fast.

For non offset Localizers, then the True value should be used to align the localizers as close as possible with the True RWY bearing. Those two values are always tied togheter always the same.
For MSFS centerline alignements a button could be implemented in some sort of advanced editing mode, so that it then would auto align whatever localizer by the press of a button in MSFS. (As it has been done in the beginning) Now this could be made optional as it is not easy to always get the calculation properly in certain edge cases.

For offset Localizers, the alignement will never be perfect, because that information is rarely published by state source. So there is no other way than to just rely on the ARNC 424 True value + coordinates. Corrections then need to be done by users / scenery developers anyway.

An Example:

SBGL RWY 15 / 33 has a True bearing of 125.681deg in MSFS and lets assume there would be no localizer present or it would needed to be corrected due to low resolution coordinates in ARINC 424.

In the old days I would just have added the localizer with the same value as the RWY at the end of it. Done.

Now you need to first get the Magnetic RWY heading from the sim based on Magdec.bgl file and then take into account the True bearing to calculate the required Magnetic declination of the Localizer so that the combination of the two values results in the True bearing of the RWY.

Magnetic (149) - True (125.681) = W 23.319deg.

Thats the easy calculation if you have a localizer attached to a RWY. Now imagine an offset localizer. Now the calculation gets even more tricky because you don`t have a reference where you can align to.

You see that this is a far more error prone way to place the localizer beam than just using the True value.

That is also the way how the aligement is calculated for the ARINC 424 files by the data providers, so you can actually rely on the True value that you have in the ARINC 424 (or calculated True as a result out of CRS and Declination) and just place the localizers using the True value only.



That is how BGSF Localizer (30 deg variation) looks like when alignement is based on Magnetic values and the ground layout and RWY is based on True values in Airport Design Editor:

bgsf-tmagnetic.jpg


and here with True values:

bgsf-true.jpg




Maybe we should meet to discuss that topic further, as it is very hard to describe all the different issues that can result out of it in written form. A live demo will help to grasp the issues.





bgsf-tmagnetic.jpg (100.9 KiB)
bgsf-true.jpg (120.8 KiB)
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

lonewulf47 avatar image
lonewulf47 answered lonewulf47 edited

I heartily agree to what Jan-Paul is pointing at. The main issue is that a LOC antenna is a FIXED GROUND INSTALLATION and therefore should NOT BE BASED ON ANY CALCULATIONS BUT STRICTLY ON A TRUE COURSE.

The second issue is that MSFS/ASobo does not use a straightforward priority system. The Nav-Database should always - no matter whether it is default or custom - be used in highest priority and thus overwrite/replace all add-ons.

As you might have noticed, Navigraph makes now (as from cycle 2112 if I remember well) use of that by placing their data folder (Navigraph navdata) at the end (=top priority) of the content.xml, thus eliminating all wrongly defined ILS'es by add-on developers. That's exactly the way it should be. ONLY ONE COMPLETE DATABASE should be used at a time.

Just as a sidenote: check out X-Plane 11! They did everthing right from the beginning. Only ONE database (default or custom) and NO ILS'es whatsoever in airport add-ons and of course true bearings used on LOCs...

Oskar

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 19.1 MiB each and 23.8 MiB total.