Microsoft Store version Are you using Developer Mode or made changes in it? No
Brief description of the issue: Stock ILS localizer default range is 27 nm, in-game range is much less at 15 nm.
Provide Screenshot(s)/video(s) of the issue encountered: Any ILS with IF/IAF waypoints beyond 15 nm unflyable.
Detail steps to reproduce the issue encountered: For example, KGPI ILS 02 IF/IAF GOGGS is included in stock approach, and is as published; however, ILS localizer is not received at 21 nm and aircraft will fly by the approach.
Did you submit this to Zendesk? If so, what is your ticket #? 122794
This limitation has global effect, no approaches with waypoints beyond 15 nm can be flown.
This isn’t really that far off. The normal range for a real world ILS localizer is 18nm though there are some that are certified for a longer range. You also have to consider that the localizer antenna is at the far end of the runway so runway length has to be considered. In your example, Rwy 2 is 9001 feet long. Let’s call it 1.5 nm to keep the math simple. It’s 15.1 nm from JOLEK to the runway threshold. That’s 16.6 nm total when you add in the runway length. GOOGS is an RNAV waypoint and not a localizer waypoint.
However, your point is taken that the default range for a localizer specified in the SDK, if no other range is defined, is 27 nm. Things may be different in other parts of the world, but in the US using 27 nm for the default range would be incorrect.
KGSO 23L comes in right at 27 miles for me. You left out whether you have anything in your Community folder. I’m guessing you do. If so, move it to your desktop and try again.
GOGGS is indeed an ILS waypoint, defined in the ILS approach. A “normal” range for an ILS actually depends on the design of the approach and the results of the flight test. I base this on 23 years USAF ground electronics experience including NAVAIDS, and four decades of active flying.
If an approach is TERPED for a 21 nm waypoint to act as IAF then flight check is going to verify the localizer accuracy and signal strength at 21 nm plus a wide margin for safety.
You’re spot on. I removed the Navigraph add-on and now receive the localizer at GOGGS as expected. Oops… I know better too. Oh well, time to complain to Navigraph.
I beg to differ. Look at the symbol for GOGGS and compare it to the symbol for JOLEK. JOLEK is a triangle. That indicates it’s based on the localizer. The symbol for GOGGS is a star. That symbol indicates that it is an RNAV waypoint and not based on he localizer. Just because it’s on the extended centerline doesn’t mean it’s identifiable with the localizer signal.
Yes, when you fly to GOGGS. But how would you get from GOGGS to JOLEK? By picking up the localizer at GOGGS, and if you cannot do that the approach is broken.
It most certainly is identified with the localizer, while I agree it is defined by FAA with lat/lon rather than radial/dme information nonetheless it is still an ILS IAF and while the notes on the chart indicated DME required (probably for the missed approach holding fix) and RNAV-1 or RADAR is required for the procedure entry (the procedure turn), no such requirement exists to fly from either of the IAF’s FIKAB, OLIBY o SKOTT (all of which are defined with dme/radial information) where no procedure turn is required. It is absurd to think the localizer doesn’t extend to GOGGS. There is no requirement to have RADAR or GPS when entering from those IAF’s.
The more I thought about the RNAV-1 requirement for procedure turn entry I think I got it: The RF definition for GOGGS would include the localizer at the intersection of FCAr217 and think about it. The FAA defines the course width for the localizer to be 4.0 deg, which at 21 nm is going to be about a 3 nm wide localizer and then try to define that with a VOR radial at 20 nm where the radial has a permissible error of +/- 4 deg and you get the reason the holding pattern course reversal is based on a GPS waypoint. The errors using RF would be just too great. That doesn’t mean there is no localizer, it only means the localizer is pretty wide way out there and TERPS approach design requires more stringent error margins.
Please tag your post with #pc and/or #xbox. pcxbox
Are you on Steam or Microsoft Store version?
MS Store
Are you using Developer Mode or made changes in it?
No
Brief description of the issue:
Localizers do not have enough coverage in certain cases.
Provide Screenshot(s)/video(s) of the issue encountered:
One example. KORD ILS RWY 10C. Doesn’t become active until just outside PEPAW (~16.6 DME). The localizer in real life extends at least out to BAIRY (25.8 DME). There are numerous other examples at major airports with extended localizers.
Detail steps to reproduce the issue encountered:
Go to virtually any major airport and compare the ILS chart to where the localizer becomes displayed in the cockpit.
PC specs and/or peripheral set up of relevant:
N/A
Build Version # when you first started experiencing this issue:
All
Please note that for most of the localizers in the world, a standard volume is fine, but larger airports (class B and C in the US) usually have numerous localizer courses with what’s known as an “Extended Service Volume”, flight checked to be accurate out to a potentially great distance.
Certain exceptions should be allowed for specific localizer courses to better display localizer course (and associated DME) information accurately.
I understand that the localizer may become unreliable past 18 miles, but for it to completely lose reception? C’mon. Please consider upping the range of the localizer and glideslope.
The VOR and NDB rages are also very unrealistically limited in range.
There is a BIG difference between the longer Reception range, the range that the flag operates, and the range that the VOR is certified to be Certified to operate at.work at.
Its probbaly a total waste of time to even discuss this here, until Asobo recognises, and is ready to address the issue.
When they are, there is not shortage of Aviation Professionals that can talk to get get the real world information they will need to correct the current dumbed down, “ex FSX” operation of these ground Nav systems
The navigraph data should be the “Certified” range of these facilities, not the actual range that the instruments in the plane can give an INDICATION of navigational data.
MSFS does a half way decent job in calculating the signal strength from Ground based station, based on their TX Power, range, plane’s elevation etc, and this seems to be used to control any FLAGS – but the trouble is, when the signal is below Flag Threshold, there is still “unreliable” data being received by the plane, but MSFS acts as if that signal is non existent, when it is more than sufficient to be detectable and operate the Nav instruments in a limited way, and hence without a flag.
Any audio on that nav signal should also reflect that signal strength, and become NOISY with increasing range, but still be audible in the noise, when the flag fails to register an acceptable “Certifiable” signal strength.
Then there is the whole matter of what data is nav radio derived, and what data is GPS database generated, and how that is displayed to the pilot.
Are you using Developer Mode or made changes in it?
No
Brief description of the issue:
With Navigraph loaded, the ILS 31 signal at KSNS only has a range of 20 nm, and the glideslope has a range of 15 nm. Those are insufficient to fly the approach. Richard from Navigraph and Matt from Working Title have both spent a fair amount of time looking into this issue but the root cause is not yet clear. Navigraph believes they’re providing the correct localizer and glideslope ranges. Matt confirmed that the simulator currently computes the glideslope range as around 75% of the localizer range. Richard thinks the sim is using the smaller of the two provided values as the localizer range.
With Navigraph disabled, the LOC range is 27 nm, making the GS range about 20 nm which works fine to fly the approach.
Is it possible the simulator is not correctly loading the range values provided by Navigraph?
Provide Screenshot(s)/video(s) of the issue encountered:
Detailed steps to reproduce the issue encountered:
Enable Navigraph, fly the KSNS ILS31 approach using VOR and ILS only. The ILS will not be correct until hitting 20nm from the airport, and the glideslope until 15 nm. Both of those are less than required for the approach.
PC specs and/or peripheral set up if relevant:
High-end PC.
Build Version # when you first started experiencing this issue:
All
For anyone who wants to contribute on this issue, Click on the button below to use this template:
Do you have the same issue if you follow the OP’s steps to reproduce it?
Provide extra information to complete the original description of the issue:
If relevant, provide additional screenshots/video:
For anyone who wants to contribute on this issue, Click on the button below to use this template: