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.
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
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.
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
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:
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.
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
Are there any news regarding that topic? Similar to correcting sceneries with
the new WorldHub
https://www.youtube.com/watch?v=0G512kRLPOQ&t;=2195s
there should also be the possibility to have a userfriendly editor to correct
the following items when it comes to Runways and Navdatas: Runway idents (SBGR
and SVMI did have their Idents upnumbered / got new RWYs as recent examples)
This is currently not reflected in the Navblue cycles since they are not
updated on a monthly basis on their effective date. When using Navigraph,
there is still the issue that the simulator drops SIDs and STARs since it
doesn`t recognize the upnumbered idents in the procedures and can not connect
it to the existing RWY and do the upnumbering / assignment automatically. That
should be either be changeable by Navigraph directly or the user should be
able to add or upmumber the RWYs to get proper assignments. Following items
should be editable when it comes to the Localizer in the NAX…bgls. (default
or custom) Localizer: Identifier, Name, Frequency, Course, MagVar (Course and
Magvar should be changed to True Course only so that there is only one
variable and not two as in real life), Elevation, Coordinates, Range, Width,
Backcourse Glideslope: Angle, Range, Elevation, Coordinates DME: Range,
Elevation, Coordinates Regards Jan-Paul
737NG Driver posted a video which details consequences of mismatching
Localizer, DME and Glideslope datas in MSFS. In his video he is focusing on
the Glideslope but the issues are the same with Localizers, DME and PAPIs.
https://youtu.be/kucERBQMVl4 Regards Jan-Paul
I ALSO 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
confusion and errors when using magnetic bearings, is that they change over
time, as Magvar changes with time. The FIXED GROUND INSTALLATION remains
literally “Cast in Concrete” and does Not move. Except when the Ground
Facility is retired … (then it does move – to the scrap yard)
Unfortunately, yet another source of confusion in both MSFS (and FSX) caused
by mixing up true & magnetic bearing.
An ARINC424 database with only primary records for localizer/glideslope only
contains the magnetic bearing and station declination, so the only way to get
a true bearing for the localizer is to derive it from those two fields. There
are simulation continuation records defined that contain the true bearing but
these may not be available from the source data, and for example the FAA CIFP
does not contain these records.
@tracernz Simulation continuation records are usually provided by Navblue,
Jeppesen or Lido for Simulation customers like Microsoft. However the best way
in case of non offset Localizers would be to just use the MSFS RWY true
bearing as the ARINC 424 records are not suitable for the use in MSFS.
Navigraph for example recalculates the magnetic and declination values and the
non-offset localizer coordinates to have at least the true bearing aligned
with MSFS as state source coordinates are not reliable enough for MSFS use.
There is no way around some algorithms that are based on the MSFS RWY
locations to get it right. Basically the same methods that ADE or the old
AFCAD tools use for the placement of non offset localizers / GP / DME need to
be used and applied to default and add on sceneries via some automation. Then
this problem would be solved for the majority of the cases. There might be
still edge cases that could then be handled via a small userfriendly editor
where the mentioned parameters could be edited.