The ILS localizer range is too low for ILS31 at KSNS. The FAF is at about 16.5 nm, but the ILS glideslope doesn’t activate until 15 nm. In addition, the horizontal guidance range is less than the 22 nm of the DME arc which leads into it.
Hi,
hm, it looks that the sim doesn´t use the ranges what we update monthly. I have looked into our database and see that the LOC range is set to 30 nm and the GS range to 20 nm - so ideal values for this approach but as I wrote it looks that the ranges in the sim are hard coded, independent what we have set as range value.
Have you tried it with the stock data only? Because the stock data has a general default value of 27 nm for ILS and GS everywhere in the world. They haven´t included the real world values … would be interesting if it works with the stock data or not …
Cheers,
Richard
I tried the approach “Green Needles” with Navigraph removed and it worked fine. The LOC range is more than 22 nm and the glide slope range is 20 nm, so the approach can be flown by the book.
Hi again,
have tried the approach now wirh our data. Localizer is coming up at approx. 27 nm, glideslope at approx. 20 nm. Sorry, can’t reproduce it. It works exactly what we offer in our data.
Must be any other issue on your system.
Cheers
Richard
I tested again (in MSFS 2020) with Navigraph enabled.
I’m using iSNS 108.5 for the localizer. There is a signal at 22 nm out, but is the wrong one. It’s offset about 1 nm to the east using the expected 311 course. At exactly 20 nm, that snaps to the correct position, but has no glide slope. If you re-acquire the new position, and fly it in, the glide slop will appear at 15 nm and work correctly the rest of the way in.
The SNS VOR on 117.3 has plenty of range to fly the required arc, but the ILS doesn’t.
The foreflight track above was flown without using GPS mode. I used SNS for the DME arc, then when I switched to iSNS for the inbound leg, it was way east of where it should be. At 20nm iSNS has the right position, but no glide slope. That finally appears at 15nm.
Does the “Remove” function of the Navigraphi Data Center not remove everything?
BTW: I’m using the SR22 with the WT G1000 Nxi. One other odd thing about this approach is that if you configure the PFD to display the DME to the ILS, it just shows up as ‘–’
Here’s the same approach, flown the exact same way, with Navigraph removed.
The interesting thing is that the DME range still shows ‘–’ for the ILS.
The localizer works out to 22 nm, and the glide slope is available when needed.
If that airport is somehow corrupt in my install, how to I refresh it?
Edit: I did a remove and uninstall of Navigraph, then a “Repair” of my MSFS install as described here: https://flightsimulator.zendesk.com/hc/en-us/articles/360016107019-Microsoft-Store-version-How-to-repair-or-remove-and-do-a-clean-install-of-Microsoft-Flight-Simulator
After that I did a re-install of Navigraph and I still see the same bug.
Hi again,
ok, I have now looked deeper into it and I´m pretty sure the sim has a bug again …
But step by step - first of all this is only an ILS not an ILSDME, which explains why you don´t see any DME distances.
As I wrote in my previous answer: the LOC range is set to 30 nm and the GS range is set to 20 nm, which should be good and is correct, BUT … in my eyes, there is a bug in the sim with the ranges, or ASOBO has limited it, what is indeed wrong …
I assume following rules:
- The LOC max range is limited to 27 nm, the GS comes ALWAYS a few miles lower, independent what you set as GS range …
- If the GS range is lower then the LOC range, the GS range will be used … as in our example: we have set LOC 30 nm, GS 20 nm - which should be the limit but when you look the LOC comes within 20 nm (= GS range).
Here, what you see when the LOC range is set to 30 nm, and the GS range is set to 20 nm (which is implemented in the current AIRAC 2204):
5 miles less, GS is showing:
Now, the same situtation, when I set both ranges to 30 nm (LOC range and GS range):
at DME 28 / SNS - no LOC, no GS:
at DME 27 / SNS - LOC available, no GS (so LOC is limited to 27 miles max):
at DME 23 / SNS - LOC and GS is available (so GS is correlated to the LOC range - approx. 4-5 miles):
Therefore use ASOBO/WT the same ranges for LOC and GS because than you ever had one value. They use also a default value of 27 miles, means you get the LOC signal at 27 miles an at 23/24 miles you receive the GS also.
So, you see, this is clearly 100% an ASOBO issue - the ranges are limited to 27 miles and the GS range has any correlation to the LOC range, which is also nonsense.
Please report this to ASOBO … because in this case we can do nothing. Our ranges are correct so far, but the sim doesn´t use is correctly. The sim uses always the lower range of LOC and GS and therefore you receive the LOC too late.
Thank you,
Richard
It seems like you could get acceptable range in the interim, by adding 4 or 5 to the larger range and using that for both.
Doesn’t this mean that all ILS ranges are too low with Navigraph installed at present?
No, that doesn´t mean that but the GS ranges are normally 20 nm (10 nm + 10 nm extend) … as I wrote in my two previous answers. The LOC range is set to 30 nm (so enough to intercept the LOC), the GS range to 20 nm (also enough to catch the GS on time) but the sim takes only the smaller value (if not both values are equal), in this case 20 nm even we have set the LOC range to 30 nm.
Yes, for sure, we can set also both ranges to 27 nm as ASOBO/WT but that´s not our intention since over 20 years. We are offering real-world data from the largest data provider company in the world. So it´s for us and also for Jeppesen important to offer the data as they are and not a mix of payware-/freeware data (as ASOBO/WT does) with a mix of fictive and real values (also as ASOBO/WT does).
We help where we can and as you see, we try to analyze the issues so good as we can and try to explain what happened (also with screenshots). We can´t do more. According the technical details from ASOBO/WT, there are two ranges available and possible to set - one for the LOC and one for the GS and we do this. The logic behind is not in our hand … and here, we have described the bug …
- maximum range is 27 nm (even you have set more)
- when you have set different ranges for LOC and GS, the sim uses the lowest value for both
- the GS correlated with the LOC - means the GS is always 4-5 nm less than the value from #2
That´s very clear and can be reproduced … the stock data has fixed ranges from 27 nm for both LOC and GS therefore it looks “ok” - but it´s a bug or a not implemented feature - I don´t know … from the technical specs, it should work … it should, but it won´t - sorry.
Cheers,
Richard
Matt from Workiing Title (who I believe has access to the MSFS source) says the code in the simulator is very simple. The GS range is 75% of the LOC range, de-rated slightly by how far off the glideslope you are.
Is it possible the Navigraph GS/LOC values are swapped? That would explain the 20 nm range I’m seeing in this example, and perfectly explains the 15 nm GS as well.
Adding in here, since the thread is now closed.
I certainly appreciate you looking into this Richard. Thanks for the help. Matt looked at the MS sources and he thinks it’s right on their end, that’s why I asked if the two values might possibly be backwards in the Navigraph implementation.
Best Wishes,
Scott
PS. As a long-time software professional, I’m used to trying to keep bug reports all about the data, rather than the personal. I apologize if I came across as ungrateful. I was really just trying to help find the root-cause. All we know for sure at this point is that the simulator behaves as if the LOC range is 20nm for this approach, with Navigraph enabled. The GS range is computed as 75% of the LOC range, which confirms the 15 nm observed. I will file a Zendesk report stating that Navigraph ILS ranges are incorrect, and Matt may help get some attention for it. In practice, this seems to completely invalidate the “correct range” feature of Navigraph which is an advertised feature.
Are those correct for any ILS at this point with Navigraph installed?
Possible yes, but we will not do this, read my posting before again please. When the code is so simple, it should be no problem for WT to fix this in the next update.
I have spend now several hours in analyzing this. I have tried to explain the issue. Now, you have the confirmation, that this is a issue which we can’t fix on our own. We can’t do more …
One last word:
To sign a posting with your name, a “Hi” at the beginning or sometimes a “thanks” could sometimes result in a wonder.
Happy flying, have a nice day and thanks for contacting us
Richard
Yes, LOC ranges and GS ranges are accurate according the real-world. The limitation in the sim is only, that the sim takes in every situation the lower range of LOC and GS. So, no swapping or similar else - it´s their logic.
LOC range > GS range
LOC range = 30
GS range = 20
Sim takes GS range of 20 nm = LOC comes up at 20, GS comes up at approx. 16-17 nm
LOC range < GS range
LOC range = 20
GS range = 30
Sim takes LOC range of 20 nm = LOC comes up at 20, GS comes up at approx. 16-17 nm
LOC = GS (implemented in the stock data worldwide)
LOC range = 27
GS range = 27
Sim takes 27 nm = LOC comes up at 27, GS comes up at approx. 23-24 nm
Additional - there must be a maximum range implemented - I assume 27 miles. All above will not be recognized by the sim. So extended SSVs are implemented (as in the blog-post described) but can´t be used by the sim due this limitation of 27 miles.
I don´t have the possibility to look into the code as WT can do, so this values are based on my own analyzes.
Cheers,
Richard