-
Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:
- Tag FS2020 specific questions with the MSFS2020 tag.
- Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
- Questions about aircraft design can be posted in the Aircraft design forum
- Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
- Questions about terrain design can be posted in the FS2020 terrain design forum.
- Questions about SimConnect can be posted in the SimConnect forum.
Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.
By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.
MSFS20 ILS still out of wack.
- Thread starter Microdude
- Start date
- Messages
- 34,981
- Country
Are you using Alpha 21 HF4? http://scruffyduck.org.uk/ade_2020_help/InstrumentLandingSystemILS.html
- Messages
- 34,981
- Country
Are you saying that the physical position of the localizer is wrong relative to the runway or the localizer heading is wrong and so the localizer is not pointing down the runway. As mentioned before localizer headings in MSFS appear to be magnetic while runway headings are true. I am not sure what the impact is of this on the aircraft instruments but you may need to change the heading. If you used ADE to add an ILS then it uses magnetic for the localizer heading unless you choose to use true. The link I showed above talks about this I think
- Messages
- 34,981
- Country
Then you can reposition the localizer and change the heading until you get what you need
Lagaffe
Resource contributor
- Messages
- 992
- Country
Hello,
I seems that I have a PB similar on CYMX (personal project) : I have used ADE before ADE 21 HF4 to modify a FSX version of my stuff and then compile it for MSFS.(*)
The problem manifests itself in the following way:
- on ADE, the 2 runways and the 3 ILS have the right heading, the magnetic declination is given at the airport and is 15° (image 1)
- on LittleNavMap, the ILS seem to be offset from the runway axis (image 2).
- The PB isn't on FSX, all is OK !
The ADE version I used (*) was the one of January/February 2021 so before the last release of this month.
I noticed that in addition to the magnetic declination information at the airport, this declination also appeared on the ILS.
I did a test by setting this declination to 0° on the ILS and recompiling but with the HF4 version => on LittleNavMap, the problem disappears, ILS are in the same direction than the runway.
My question: should I put this declination of 15° on each ILS and recompile with the HF4 or a declination of 0° on the ILS is sufficient considering that the general properties of the airport already have this declination of 15°?
I seems that I have a PB similar on CYMX (personal project) : I have used ADE before ADE 21 HF4 to modify a FSX version of my stuff and then compile it for MSFS.(*)
The problem manifests itself in the following way:
- on ADE, the 2 runways and the 3 ILS have the right heading, the magnetic declination is given at the airport and is 15° (image 1)
- on LittleNavMap, the ILS seem to be offset from the runway axis (image 2).
- The PB isn't on FSX, all is OK !
The ADE version I used (*) was the one of January/February 2021 so before the last release of this month.
I noticed that in addition to the magnetic declination information at the airport, this declination also appeared on the ILS.
I did a test by setting this declination to 0° on the ILS and recompiling but with the HF4 version => on LittleNavMap, the problem disappears, ILS are in the same direction than the runway.
My question: should I put this declination of 15° on each ILS and recompile with the HF4 or a declination of 0° on the ILS is sufficient considering that the general properties of the airport already have this declination of 15°?
Attachments
- Messages
- 134
I am not familiar with LittleNavMap; however, I am familiar with the messy way Asobo has applied the bearing parameters for runway and localizer and unbelievably they use magnetic for runway and true for localizer and I assume that the magvar parameter in the ILS container is just eye candy. Not surprisingly, their SDK documentation doesn't specify either and one just has to try different things to figure it out.
- Messages
- 34,981
- Country
I have talked to Asobo about this they cannot tell me why they changed the heading attribute for localizers from true (aligned with the runway) to magnetic. [I can only whisper that the dev who did this may have left Asobo so the logic is gone into the wind] As far as I can tell runways are specified as true but I am sufficiently bemused by this that I can only talk about it when lying down in a darkened room.
Of course mag heading is true + magnetic variation.
I have also failed to get a clear answer from developers as to what they do to handle this
I have also failed to get something (that I understand) related to the effect of changing this on aircraft instrumentation. The only answer I am left with (as Dan says) is that you have to mess around until it works and the aircraft on instruments does follow the localizer onto the runway.
If you create an ILS in ADE then it will set the localizer heading
Of course mag heading is true + magnetic variation.
I have also failed to get a clear answer from developers as to what they do to handle this
I have also failed to get something (that I understand) related to the effect of changing this on aircraft instrumentation. The only answer I am left with (as Dan says) is that you have to mess around until it works and the aircraft on instruments does follow the localizer onto the runway.
If you create an ILS in ADE then it will set the localizer heading
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. (That is also the reason why it currently looks odd in ADE)
Using rounded MSFS Full degree RWY BRG values for the Inbound CRS makes it easier to calculated the needed Magvar for ADE in combination with the RWY true.
The coded Inbound CRS is on top used by MSFS for the Autotuning of the NAV1 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 AddOns, as the Autopilot tries to correct against an imaginable crosswind which is not there. This is as well an issue in Real Life:
and also the reason why PMDG did it as follows for P3D:
Aircraft Introduction Manuals:
The best way would be, if developers could convince Asobo to go back to the old 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), Asobo now just copies those inconsistencies from state sources into the MSFS world and makes life harder for everyone.
Another bad Idea is to take the Localizer coordinates for non offset Localizers out of the ARINC 424 file, instead of aligning the non offset Localizers to the MSFS centerline. The low resolution coordinates that state source AIPs provide sometimes are not precise enough for the MSFS world. Non offset ocalizers should always be aligned to the MSFS extended centerline (Just the way as ADE does when creating a new Localizer)
The only advantage is, that Navaids and Airports are now seperated and in theory one wouldn`t need to code seperate Localizers (especially when using a Navigraph or Aerosoft Navdata subscribtion) but due to the messed up implementation in combination with bad state sources, there might be still some need to do so in order to correct the worst misalignements until Asobo switches back to the old True + Magdec.bgl system in combination with aligning only non offset localizers to the MSFS centerline. At least for default airports missaligned non offset Localizers would then be a thing of the past.
Jan-Paul
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. (That is also the reason why it currently looks odd in ADE)
Using rounded MSFS Full degree RWY BRG values for the Inbound CRS makes it easier to calculated the needed Magvar for ADE in combination with the RWY true.
The coded Inbound CRS is on top used by MSFS for the Autotuning of the NAV1 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 AddOns, as the Autopilot tries to correct against an imaginable crosswind which is not there. This is as well an issue in Real Life:
Airbus ILS course - PPRuNe Forums
Tech Log - Airbus ILS course - Thanks a lot, Sabenaboy for a very lucid explanation. You're lucky to have such a good source for information. And so are we, through you.
www.pprune.org
and also the reason why PMDG did it as follows for P3D:
Aircraft Introduction Manuals:
The best way would be, if developers could convince Asobo to go back to the old 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), Asobo now just copies those inconsistencies from state sources into the MSFS world and makes life harder for everyone.
Another bad Idea is to take the Localizer coordinates for non offset Localizers out of the ARINC 424 file, instead of aligning the non offset Localizers to the MSFS centerline. The low resolution coordinates that state source AIPs provide sometimes are not precise enough for the MSFS world. Non offset ocalizers should always be aligned to the MSFS extended centerline (Just the way as ADE does when creating a new Localizer)
The only advantage is, that Navaids and Airports are now seperated and in theory one wouldn`t need to code seperate Localizers (especially when using a Navigraph or Aerosoft Navdata subscribtion) but due to the messed up implementation in combination with bad state sources, there might be still some need to do so in order to correct the worst misalignements until Asobo switches back to the old True + Magdec.bgl system in combination with aligning only non offset localizers to the MSFS centerline. At least for default airports missaligned non offset Localizers would then be a thing of the past.
Jan-Paul
Last edited:
- Messages
- 34,981
- Country
That is very helpful. Thank you very much. I have told Asobo they messed up and it would be better to have stayed with the FSX arrangement but it is too late now I think