• 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 Fixing MSFS LDA information in APX data files

jaxx_ said:
For the last days I've tested with all ILSs patched and haven't encountered any bad side effects.
The only thing is that the navigraph data is not really precise enough as they seem to set the localizer heading and magvar only to a precision of 1° and from my tests it would probably have to be at least 0.1° to be reliable.
I've posted this in their forums, hopefully they have more precise raw data. Otherwise if Asobo patches this issue the Navigraph data would not accurate enough for many ILSs.
Click to expand...
Why the need for sub 1 deg accuracy. ? I have always been lead to believe that as the mag var varies, approach plates are only updated for magVar variation, when the error exceeds 5 degrees !!

Take KOSH (Oshkosh -- the site of the Big yearly (but not 2020) AIrshow in the USA) .. ILS runway 36. This has been off for many many years, and last time I checked A FEW YEARS AGO, BY MORE THAN 5 DEGRRES.
I even talked to the KOSH tower controller about it -- they know, but the FAA division that deals with the updates , at that time, were so overloaded, that it was on "Backlog" as not being a High Priority.

Well, flying the 36 ILS into KOSH is a strange experience, with current charts. It feels like there must be a major crosswind, to stay on the ILS , if you fly the ILS as depicted on the charts.
 
There is no variation in a real ILS localizer in any case. The indications of the CDI needle are based solely on the aircraft’s spatial position in relation to the transmitted beam, and the position of the beam in relation to the runway is determined solely by the position and alignment of the antenna array.

Things get complicated in the sim because it is all an emulation of a physical system.
 
Hi Jaxx

Please help me --- what am i doing wrong ? I still cannot fly both LDA 19's KDCA in MSFS.

I have

  1. Purchased NaviGraph and installed it
  2. Updated MSFS to use the NaviGraph data ? (Not sure if I may have missed something here)
  3. When I installed Navigraph, it updated LNM.
  4. --------------
  5. I installed PYTHON
  6. Modified your script to my MS Store correct path to "Official" & "Community"
  7. Ran ils_fix.py --all and it indicated that it processed all the airports
  8. ------------------
  9. Updated LNM to read the current (Updated ? ) MSFS Nav data

So, now in LNM, I can either select updated ? MSFS or 2014 NaviGraph Data.

But if I select LNM to view MSFS data, I still see one of the LDA, alligned with the 19 heading,

If I fly it, it does not fly the correct LDA, but instead brings me in from Due North (Right over the White House !!)



What did I miss ? Maybe something about a Beta for NaviGraph for MSFS ???

===========


Update: OK, so I did miss a step -- the NaviGraph beta for MSFS,,

Got that and ran it .. It updated MSFS.

Updated LNM with the new MSFS data.
Now, when in LNM, Both MSFS & Navigraph databases show the correct LDAs

I can fly the Localizer on both LDA's correctly !!! :)

BUT

Now it has lost lost the Glideslope on the LDA Y that use to have the GS before all these changes :(
(Both now do NOT have glideslopes)

Also, I see both LDA frequencies have changed from the original MSFS ones ...

-------- Y -------- Z
OLD 111.80 110.50
NEW 109.90 108.50

But LDA Y 19 is now missing Glideslope (LDA Z has not one in MSFS or RW -- so that's OK )​
Click to expand...

Two steps forward, one step backwards

But Glideslopes at other airports are still OK .. (Thank Goodness)

Do you, after your updates with your script, see a GS on either of the two LDAs @ KDCA
 
Last edited:
Geoff_D said:
Hi Jaxx

Please help me --- what am i doing wrong ? I still cannot fly both LDA 19's KDCA in MSFS.

I have

  1. Purchased NaviGraph and installed it
  2. Updated MSFS to use the NaviGraph data ? (Not sure if I may have missed something here)
  3. When I installed Navigraph, it updated LNM.
  4. --------------
  5. I installed PYTHON
  6. Modified your script to my MS Store correct path to "Official" & "Community"
  7. Ran ils_fix.py --all and it indicated that it processed all the airports
  8. ------------------
  9. Updated LNM to read the current (Updated ? ) MSFS Nav data

So, now in LNM, I can either select updated ? MSFS or 2014 NaviGraph Data.

But if I select LNM to view MSFS data, I still see one of the LDA, alligned with the 19 heading,

If I fly it, it does not fly the correct LDA, but instead brings me in from Due North (Right over the White House !!)



What did I miss ? Maybe something about a Beta for NaviGraph for MSFS ???

===========


Update: OK, so I did miss a step -- the NaviGraph beta for MSFS,,

Got that and ran it .. It updated MSFS.

Updated LNM with the new MSFS data.
Now, when in LNM, Both MSFS & Navigraph databases show the correct LDAs

I can fly the Localizer on both LDA's correctly !!! :)

BUT

Now it has lost lost the Glideslope on the LDA Y that use to have the GS before all these changes :(
(Both now do NOT have glideslopes)

Also, I see both LDA frequencies have changed from the original MSFS ones ...

-------- Y -------- Z
OLD 111.80 110.50
NEW 109.90 108.50



Two steps forward, one step backwards

But Glideslopes at other airports are still OK .. (Thank Goodness)

Do you, after your updates with your script, see a GS on either of the two LDAs @ KDCA
Click to expand...
The LDA-Y glideslope was removed in 2017.

https://www.flyreagan.com/sites/def...ting_13_meeting_summary_final_25may2017_0.pdf

Read paragraph 3C “IFP Gateway Procedures” for the discussion by the DCA airport planning commission.

The localizer frequencies were changed at the same time. The ones shown in Navigraph are correct: 109.9 for the LDA-Y and 108.5 for the LDA-Z. Another illustration of why the default NavBlue database in MSFS is so horridly bad - yet another case of data that is years out of date
 
Geoff_D said:
Hi Jaxx

Please help me --- what am i doing wrong ? I still cannot fly both LDA 19's KDCA in MSFS.

I have

  1. Purchased NaviGraph and installed it
  2. Updated MSFS to use the NaviGraph data ? (Not sure if I may have missed something here)
  3. When I installed Navigraph, it updated LNM.
  4. --------------
  5. I installed PYTHON
  6. Modified your script to my MS Store correct path to "Official" & "Community"
  7. Ran ils_fix.py --all and it indicated that it processed all the airports
  8. ------------------
  9. Updated LNM to read the current (Updated ? ) MSFS Nav data

So, now in LNM, I can either select updated ? MSFS or 2014 NaviGraph Data.

But if I select LNM to view MSFS data, I still see one of the LDA, alligned with the 19 heading,

If I fly it, it does not fly the correct LDA, but instead brings me in from Due North (Right over the White House !!)



What did I miss ? Maybe something about a Beta for NaviGraph for MSFS ???

===========


Update: OK, so I did miss a step -- the NaviGraph beta for MSFS,,

Got that and ran it .. It updated MSFS.

Updated LNM with the new MSFS data.
Now, when in LNM, Both MSFS & Navigraph databases show the correct LDAs

I can fly the Localizer on both LDA's correctly !!! :)

BUT

Now it has lost lost the Glideslope on the LDA Y that use to have the GS before all these changes :(
(Both now do NOT have glideslopes)

Also, I see both LDA frequencies have changed from the original MSFS ones ...

-------- Y -------- Z
OLD 111.80 110.50
NEW 109.90 108.50



Two steps forward, one step backwards

But Glideslopes at other airports are still OK .. (Thank Goodness)

Do you, after your updates with your script, see a GS on either of the two LDAs @ KDCA
Click to expand...

As @JRBarrett already stated there are no glideslopes for LDA Y and Z on RW 19 and the frequencies are the current ones.
If you are using the Navigraph data and you think something might be wrong in the sim it is a good idea to check the real world charts (e.g. Navigraph Charts app) as well to see how it should be in real life.
For this situation you can see in the charts that those approaches don't have a GS and the correct frequencies. Compared to e.g. the ILS approaches on RW01, you can see there is no "GS" entry at the top and no visual representation of a GS in the vertical cross-section of the approach at the bottom of the approach charts for LDA Y/Z at RW19.
 
I am looking at the LDA Y RWY 19 Plate ... 31 Dec 2020 to 28 Jan 2021 (on Skyvector_)

So yes, Thanks for the Link.. talking about removing the GS from LDA Y so why does the Plate still clearly shows a GS as depicted in the Bottom right corner.

The LDA Z RWY 19 Plate shows there is NOT a GS.

and ILS 1 (CAT II) shows a Glideslope ???

Maybe I am reading the Approach Plates incorrectly -- I had always throught that is the Vertical Approach Diagram depicted a Filled In GS (light Grey), it meant there was a GS. ??

========
OK, got it now .. I am now able to read the plate correctly, and neither have a GS. (needs the X at the GS Intercept to have an actual GS signal)

Still do not know the significance of the GS being depicted as Filled on, or not ... ?????
 
Last edited:
Geoff_D said:
I am looking at the LDA Y RWY 19 Plate ... 31 Dec 2020 to 28 Jan 2021 (on Skyvector_)

So yes, Thanks for the Link.. talking about removing the GS from LDA Y so why does the Plate still clearly shows a GS as depicted in the Bottom right corner.

The LDA Z RWY 19 Plate shows there is NOT a GS.

and ILS 1 (CAT II) shows a Glideslope ???

Maybe I am reading the Approach Plates incorrectly -- I had always throught that is the Vertical Approach Diagram depicted a Filled In GS (light Grey), it meant there was a GS. ??

========
OK, got it now .. I am now able to read the plate correctly, and neither have a GS. (needs the X at the GS Intercept to have an actual GS signal)

Still do not know the significance of the GS being depicted as Filled on, or not ... ?????
Click to expand...
Yes, the gray path shown on the vertical profile does depict the glideslope that used to exist for this approach.

If you look at the lower left corner of the NOS LDA-Y approach chart for DCA, (available at Skyvector and multiple other aviation web sites), you’ll see it is dated 29 March of 2018. The government NOS plates are completely free and readily available, but they are not always 100 percent reliable - which is why you will almost never see any commercial flight operation (airline or corporate) using government NOS charts. A case of “you get what you pay for”. This is actually something which should be reported to the NOS charting office.

The current Jeppesen plate for the LDA-Y clearly shows no glideslope.
 
JRBarrett said:
Yes, the gray path shown on the vertical profile does depict the glideslope that used to exist for this approach.

If you look at the lower left corner of the NOS LDA-Y approach chart for DCA, (available at Skyvector and multiple other aviation web sites), you’ll see it is dated 29 March of 2018. The government NOS plates are completely free and readily available, but they are not always 100 percent reliable - which is why you will almost never see any commercial flight operation (airline or corporate) using government NOS charts. A case of “you get what you pay for”. This is actually something which should be reported to the NOS charting office.

The current Jeppesen plate for the LDA-Y clearly shows no glideslope.
Click to expand...
and that the issue .. the Jeppesen Plates are correct, the Governemnt NOS plates (that most simmers use) are out-of-date and in error !!!

Thanks for all the help & advice (and the Python script for MSFS airport files ..), I am now set up and everything is working as expected .... THANKS :)
 
Geoff_D said:
and that the issue .. the Jeppesen Plates are correct, the Governemnt NOS plates (that most simmers use) are out-of-date and in error !!!

Thanks for all the help & advice (and the Python script for MSFS airport files ..), I am now set up and everything is working as expected .... THANKS :)
Click to expand...
Sometimes it’s just the government in general being slow. Most NOS plates are good - but sometimes updates take a long time. I think the majority of arriving aircraft that are RNP capable will use the RNP RNAV 19 approach in lieu of the LDAs or the River Visual 19 if the weather is VFR. I think any pilot flying to DCA would much prefer the ILS 01 if the wind allows.

For years, the published ILS 06 approach for my local airport KELM, commenced with a teardrop turn beginning at the Elmira VOR (ULW). The problem with that is that the VOR has been out of service since late 2017 for azimuth below 10,000 feet, so the published procedure is invalid. Yet, for two years, it continued to show the teardrop entry. As long as approach control is online to provide radar vectors it doesn’t matter, because in that case arrivals would be vectored to the localizer directly.

The FAA finally just this month, implemented a new published entry for the ILS06 based on a holding pattern that does not depend on the non-functional VOR.

“Your tax dollars at work”
 
Thanks JJ .. ,ad everyone else here who have helped me get this sorted out, both on my MSFS sim, as well as in my head.
I now feel inspired to go and check out OSHKOSH KOSH ILS 36, to see now that now works out in MSFS with the ILS no longer forced to aligh with the runway, and with the current NOS Plates, that are probaly just as wrong as they were a few years ago,

In fact, I seem to remember when I last looked a few years ago, the error was past 5 degrees, but it was just about to start decreasing, with future changes of MagVar, so, if the FAA wait long enough, some tings actually improve !!
Wonder if there will be an OSHKOSH 2021 ? With as crowded as it gets, I don;t think I would choose to attend this year, even if it was to run.
 
I’ve never flown into KOSH in any sim, but the localizer for runway 36 is not offset. This is one ILS that should be aligned directly with the runway. The localizer course and runway heading are both 004 degrees. The localizer antenna is directly beyond the threshold of the runway 18 end, right on the centerline - you can see it in the aerial shot of the airport in the Apple Maps app.

Perhaps the runway itself in the MSFS scenery is misaligned? Or, perhaps they have the wrong coordinates for the localizer antenna in the scenery...
 
JRBarrett said:
Perhaps the runway itself in the MSFS scenery is misaligned? Or, perhaps they have the wrong coordinates for the localizer antenna in the scenery...
Click to expand...
Nothing to do with MSFS. I was referring to Real World (a few years ago)>
Finally, they updated the chart to account for MagVar, and now the current Approach Plate for 36 has the correct magnetic heading for the physical runay extended centerline.
 
Hi to all. Some days ago i tried to fix the OEJ LOC in LOWI. Only this because i want to touch less possible.

But i think to wrong something.
I installed Python
download the script, open with notepad, change the path but i think this is the error:

i need to change with (i made this): C:\Users\[Your User Name]\AppData\Local\Packages\ Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages\

or:
C:\Users\[Your User Name]\AppData\Local\Packages\ Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages\Official

because then when i run the script from the CMD and with "ils_fix.py --airport LOWI --ident OEJ" it give me an error.

Thanks!
Simone
 
I think you only need the root directory .. ie

C:\Users\[Your User Name]\AppData\Local\Packages\ Microsoft.FlightSimulator_8wekyb3d8bbwe

I run it with --all fixes EVERYTHING !!!
 
This is what appare..

C:\Users\Simone\Desktop>ils_fix.py --airport LOWI --ident OEJ
File "C:\Users\Simone\Desktop\ils_fix.py", line 8
path_msfs_root = os.path.normpath('C:\Users\Simone\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe')
^
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 2-3: truncated \UXXXXXXXX escape


Screenshot (1229).png
 
simoxmino said:
This is what appare..

C:\Users\Simone\Desktop>ils_fix.py --airport LOWI --ident OEJ
File "C:\Users\Simone\Desktop\ils_fix.py", line 8
path_msfs_root = os.path.normpath('C:\Users\Simone\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe')
^
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 2-3: truncated \UXXXXXXXX escape
Click to expand...
Don't use single '\' in the path, instead use '/' or escape it as '\\', like: os.path.normpath('C:/Users/Simone/AppData/Local/Packages/Microsoft.FlightSimulator_8wekyb3d8bbwe')
 
Great!! I just tried a LOC DME with circle to land rwy08!! It works PERFECTLY.
With next update it will be repristinate to the ASOBO data?
 
simoxmino said:
With next update it will be repristinate to the ASOBO data?
Click to expand...
Usually when the base data is updated the alterations to the files will be reset so you have to execute the fix again. But the fix will also not change anything when it is already applied to the entry.
 
Could it be that this is finally fixed since the last sim update?
Just took the offset localizer at EDHK and the flight path was correct. Did not apply my patch after the SU and confirmed the ILS entry at EDHK is not nulled, so it seems to me the logic has been fixed.
Anyone else can confirm this?
 
You must log in or register to reply here.
Back
Top