Used On: ILS, MLS and MLS Continuation recordsĭistance values could be limited to a certain range e.g 5000ft beyond RWY end to narrow the search area. Source/Content: The field contains the official government source distance, in feet,įrom the antenna to the runway end. The facility antenna relative to one end of the runway. "5.48 Localizer Position (LOC FR RW END) Azimuth/Back Azimuth Position (AZ/BAZ FR RWĭefinition/Description: The Localizer/Azimuth Position field defines the location of 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.Īs a first step following ARINC 424 records could be used to figure out wheter Localizers are placed on the extended centerline or not: Same applies to Jeppesen (Navigraph and Lido (Aerosoft). The info wheter a Localizer is offset / non offset is stored in the ARINC 424 file that you get from NavBlue. When that is done, one could think about ways to further improve the Localizer alignement for non offset Localizers. ![]() That should be fixed first by going back to using only True values for aligment of the Localizer antenna (same as currently for RWYs) My primary concern would be the Magnetic vs. ![]() Non offset ocalizers should always be aligned to the MSFS extended centerline. The low resolution coordinates that state source AIPs provide are sometimes not precise enough for the MSFS world. Only alignements for offset Localizers should still be taken out of ARINC 424 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.Īnother Idea for improvement is to always automatically align non offset Localizers with the RWYs in MSFS. State source AIPs would naturally differ by a few degrees (1-2 in most cases) depending on how well they are maintained.Īt the moment there should not be any differences to charts since Asobo (Navblue) or Navigraph (Jeppesen) reflect Inbound Courses from ARINC files. When updated by Asobo or via Herve Sors ( Since that always is the most up to date value based on the newest available Magvar models The Magnetic value would then be the result of True + Magdec.bgl. Then we might see again small differences to charts but those are negligible compared to bad autopilot behavior. 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. (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." 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 end result is that the localizer final approach course in the P3D world will sometimes vary from the real world. "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. This is also one of the reason why PMDG did is as follows when tuning the Inbound CRS for P3D: 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. ![]() The coded Inbound CRS is on top used for the Autotuning of the Inbound course. 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. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |