I was landing at RW36 at LIML, and the localizer guided to a point next to the runway,
so i took a closer look at the chart:
Is this false localizer phenomen simulated or did i just ran into a glitch in the navdata?
I was landing at RW36 at LIML, and the localizer guided to a point next to the runway,
so i took a closer look at the chart:
Is this false localizer phenomen simulated or did i just ran into a glitch in the navdata?
Is this using default MSFS navdata? Or did you install Navigraph Navdata? Do you also install the payware LIML airport addon as well?
I flew to the payware LIML airport a couple of weeks ago, so I reviewed my YouTube recording of that flight to see if there’s anything similar happened. But then I realised that my approach was an RNP approach towards RWY18, not RWY36. So that doesn’t exactly help your issue.
I’ve captured LOC at extreme angles outside of the “rule of thumb” 33 degrees and successfully tracked to T/D, so I would say not.
Its default scenery and navdata, however it really seems to be something wrong with that ILS, would have been really cool otherwise
Btw the volocopter is perfect to reseach stuff like this
If you are using littlenavmap, you can see the ILS in the default NAV database is problematic as it’s crossing the threshold of the runway at an offset to the left.
However interesting find, in the real life nav briefing for LIML, there is indeed an issue there!:
“A local anomaly in the earth magnetic field on the ground has been reported and measured on the area close to TDZ RWY 36. In this area local magnetic North indication may vary considerably and may affect onboard settings. Some problems have been reported by MD80 ACFT equipped with AHRS (Attitude Heading Reference System”
Some localizers do have an offset compared to the runway orientation. It might prevent any Cat III approach as it increases the minima, but it’s sometimes necessary to avoid obstacles. It’s not the case in LIML.
The false localizers (or glide slopes) are a known electromagnetic phenomenon (that you could compare to double rainbows, for example). They are sometimes exagerated by the reflexion of guidance signals against obstacles. That’s why, once established on the ILS, you must check your heading coherence with what’s expected (same thing with your variometer for the glide slope). But I highly doubt this phenomenon to be reproduced in MSFS.
False glide-slope | Article about false glide-slope by The Free Dictionary
Nothing to do with local magnetic field anomalies either.
So, to sum up : it’s certainly a glitch.
Do you remember what you programmed your NAV frequency to in your screenshot?
Over lunch today, I tried out LIML in the TBM-930 with the G3000 Working Title mod. Default scenery. Via the world map, I selected the ILS 36-Y approach. The TBM NAV1 frequency was programmed at 109.55 MHz. It was preset when I looked, I didn’t set it myself.
Little Navmap also shows the ILS frequency as ILNT - 109.55 MHz, but it shows the ILS feather “offset” slightly to the west.
Confusingly, the approach charts I found online show Runway 36 ILS as LNT - 110.3 MHz. Maybe the online charts I found are out of date.
Anyway, when I flew the approach, I enabled LOC1 (NAV1 = 109.55 MHz) and it captured the localizer and vertical guidance and flew me straight into RW36 and not down the offset feather shown in Little Navmap. I’ll attach two pictures.
At my approach were i noticed thats someting is up with that ILS the MCDU of my airbus picket the frequency itself from the flightplan, when i testet it later with the volocopter i dialed the 109.55 i got from little navmap as well.
Here you can see the correction i had to make with the airbus, the ILS would have landed me on the gras, no way i would have made it to the TDZ if followed the ILS (my
initial intention was to do an autoland).
Its not simulated, neither is it a full localizer running parallel to the actual localizer, its just bending or reflection of the signal which causes the autopilot to temporarily follow and capture it.
I doubt this has anything to do with the false localizer capture.
It doesn’t increase the minima, its just not possible to have a offset CAT II/III approach, CAT II and CAT III approaches are NEVER offset.
Makes sense, so it really is a glitch, coincidental at a place with magnetic anomalys and a warning about false localizer catches on the chart.
As amateur one could really think it is by design in this case.
Also doesn’t help because its a RNP approach . Nice video! Only the default ATC makes me puke, its not even called RNAV approach in radiotelephony anymore, its a RNP approach.
Magnetic anomalies are not uncommon, I fly to multiple airports warning for magnetic anomalies, it causes the magnetic heading to split between left and right instruments sometimes and needs some extra time during taxiing to settle, no big deal. It does not cause the false localizer. The false localizer is most probably a reflection. The localizer DME east approach in Innsbruck also has false localizers for example due to terrain.
It’s also worth noting that the default MSFS NavData has a lot of misaligned Localiser. If you fly to major chinese airports like Shanghai Pudong, or Beijing Capital, and quite a number of others. Almost all of them are misaligned. And this has been going on since launch. So I think what’s happening to you is just that same issue.
It’s the reason why I subscribe to Navigraph NavData updates, it fixes a lot of the misaligned localisers for me on default auto-gen airports.
Yes agree. False capture is usually due to signal reflection on terrain or structures, or beam bends. Just found this interesting and thought to share.
Jepp, some SID/STARS also seem to not making much sense, i dont understand it, i thought the default navblue data is the same that gets installed in real life airbus mcdu’s.
The general nav data such as, navaids, waypoints and airports might be the same, the procedures definitely aren’t. SIDs with a track to altitude path terminator are screwed up, the STAR always connects to the final approach (intermediate approach segment) with a huge arc, its quite a mess.
Maybe that could be a problem of the default flight planer, which makes up it’s own waypoints (USR) and this strange arks, i dont know. Recently i tried to fly UNOK4G into EDDF, it is impossible with the default flightplaner, after installed the development version of the FBW airbus which bring it’s own it worked well.
But that still doesn’t explain how an ILS can be misaligned, maybe the ILS are correct and the runways are wrong.
Weren’t here some government restrictions that prevented the scenery to be accurate there? Maybe the navdata is correct and the scenery is shifted.