I’ve seen it discussed often over the years, but I’ve never actually seen anything from Asobo on the topic that I can recall. Hoping someone has either pieced together the whole picture, or they’ve said something about it that I’ve missed.
Why is almost every ILS in MSFS so wonky? ILS at a default airport, ILS at a handcrafted airport, ILS at most 3rd party payware airport sceneries, you get below 500’ and it almost feels like the beam moves. It feels relatively normal, you’re two white two red, then suddenly it starts to feel like it drops out from under you, comes back up, goes back down, and if you’re following the glideslope you cross the threshold at 100-150’ and four white, or two red and two white with the GPWS going off, vs the usual 50’.
Now, of course, before I get well ackshooally’d, I know there are many ILSes in the world that are not coincident with the ALS/VASI/PAPI, etc., but it should not be so universal and so drastic.
I guess what my question is – who is it on to fix? I have Navigraph, should it fix this? Does it still use the default sim’s ILS placement? Is this universally an Asobo problem? Some sceneries seem to have had the ILSes carefully checked and placed and behave consistently, but not all, so I assume many are using whatever the underlying ILS source is.
Thank you for your post! Your topic has been moved to a sub-category of the User Support Hub
The General Discussion category is meant for discussions that fall outside of our other sub-categories.
If you would like other users to help you with an issue you are experiencing in the sim, consider these User Support Hub categories for your future post:
Navigraph and NavBlue have the same AIRAC baseline, where they have common global coverage. AIRAC is only as good as the data being reported to ICAO by nation-state aviation agencies.
All airports are defined first by the terrain maps in Bing (aerial’s) then specificied in Airport BGL files (many to one relationship). This includes precision Approach aids.
Payware makers override the default Asobo airport BGL file entry, which includes precision Approach aids.
In short, there are many contributing factors. To be able to point to a systemic flaw isn’t really feasible. That’s the price paid for Big Data.
You’re right about the “well, actually” but those real-world (in)harmonizations between an electronic glideslope and those of a visual glide slope indicator (VGSI) usually only account for a slight deviation from one or the other. Maybe a few feet differential in threshold crossing height (TCH) and/or one light difference on a four-box PAPI.
However, unless an airport has been modded in one way or another (to include third-party, bespoke, and World Hub), VGSI in the sim are placed in a default location that is not coincident with reality on many runways, leading to wildly inaccurate TCH, especially on shorter runways. I’ve been fixing this in the World Hub and it’s a consistent issue on all but the largest runways.
There’s one aspect to this I haven’t investigated and that’s whether the set VGSI angle in the sim is coincident with the reference plane (level ground) or if it is added to the positive or negative slope of the runway. It should always be the former, IAW AC150/5340-30J. If it’s the latter, set to the local slope at the VGSI site or maybe the average slope of the runway, it could lead to major errors. More investigation is needed there.
As far as the GPWS, I’ve also seen some approach plane terrain artifacts and instructions that don’t necessarily conform to reality, either. Again, World Hub is designed to fix all of this.
I’d be doing nothing but fixing VGSI in the World Hub, but the OCD part of me gets hung up on correcting every dang parking spot…
I understand where you’re coming from, but this doesn’t strike me as a full or satisfying answer seeing as other sims have historically been able to get it right very consistently. I don’t remember any problem like this being widespread in FSX, P3D, or XP over years and years of use. Those platforms obviously benefit from longer windows of time to improve, but if you look at XP, LR is a much smaller outfit and they were able to get that data and make that part of the base sim’s navdata accurate.
It feels like there is something fundamentally flawed in how this sim approaches this part of the Navdata that should be on them to fix and not on individual users correcting airports in the world hub, etc.
I don’t think there was ever such an attempt to get that many airports in FSX built and available. With size comes scope, and getting Data Integrity right is an ever ending battle. Just look at OSM for structure heights in the sim. There’s no singular authoritative and defect free data source. Same case here for PAs.
Fixed distance. I haven’t measured it exactly, but it’s somewhere around 1000’. Reality is VGSI are anywhere from a few hundred feet to 1200’ down the runway, depending.
That said, the default location isn’t far from the siting of most glideslope antennas (usually found on the aforementioned larger runways), so the VGSI shouldn’t be that far off when compared to an electronic glideslope.
I’m going to do some world hub editing this evening, so I’ll break out the ruler.
I’m going to have to agree with that notion. I’d want to see evidence that they’re all sited correctly. It is a fairly Herculean task at the moment to fix them as there is no data for this - it’s all based on overhead pics. I can’t imagine tens of thousands of airports were manually interpreted and fixed in FSX. That said, I will say the VASI placement of yore leaned more toward a narrower default range, had larger beam width (and transition zone), and as such were less dependent on precise longitudinal siting for ballpark-accurate TCH than PAPI are today.
But if you do some trigonometry, you’ll find that the beam width of each individual PAPI light box doesn’t provide much wiggle room as you get close to the runway, maybe just a few feet for each color change. I made a table somewhere, I’ll have to find it.
This could be in part due to the perceived pitch over-sensitivity in the sim, when coupled with controllers that have no force feedback. The one thing I notice when I go flying irl compared to the sim is how much more stable and easier to control real planes are in the pitch axis. Whereas in the sim I’m changing deck angles a lot, which, especially on longer planes, can change the pilot’s eye height (and thus reception/interpretation of the VGSI) dramatically compared to the CG of the aircraft.
So it seems like there’s two issues that are making this worse at the same time:
VASI/PAPI lights are being procedurally generated in the wrong spot at the majority of runways
ILS placement is often times also very wrong because even if you ignore the PAPIs and follow the slope exactly you usually are crossing the threshold at 100-150’ feet or more vs the usual ~50’. Assume this is coming from the same root cause, ILS locations being procedurally generated in a default/fixed position?
Do we know if TDZ markers are usually in the right place?
TDZ markers at US airports in the sim are always 500’ intervals out to 3000’, including the aimpoint/fixed-distance markers at 1000’. I think there’s a way to override that, but procedurally, that’s what it’s at, which is accurate to reality.
What’s not accurate is the 500’ markers, which are one thin stripe per side in the sim. They should be three per side. That drives me a little nuts.
As far as glideslope placement, I’m not sure. I haven’t really looked into that. One easy way to check is to go out to a known distance from the runway and compare it to what’s on the approach plate. Or check the TCH at the threshold. Keep in mind that GS receiver antenna placement plays a part in this. The question is what are you using to measure TCH - wheel height, pilot eye height, GS receiver antenna height, baro altitude, or radio altimeter height? We need to standardize the measurement method to compare.
Definitely fair to note discrepancies due to things like antenna position but the discrepancies I see in regular use are far greater than you would see from that – like I said, it’s routine to be on the glideslope but cross the threshold at 100-150’ RA vs the 50’ (or so) that you’d regularly expect.
Can you slew around and check? You should be able to get a pretty good idea where the GS antenna is longitudinally and check it against the position on the aerial imagery.
Any time I started down the path of noticing discrepancies, I’d start cataloging them to see if it was an aberration or widespread. But it’s hard for devs to ignore it if you bring receipts, and easier for them to fix if you can show consistent data that leads to a fix.
One other question - have you checked to see whether the threshold has been moved in real life? It could be that the sim’s depiction of the runway is old and the GS has since been moved?
I’ve referenced this video before, but Emanuel (sp?) does a pretty good investigative report on discrepancies among PAPI’s, G/S indicator, and radio altitude @ the threshold.
