X-Plane localizer range

I know, this has been asked a few times and I read here, that the localizer range was fixed to 18 NM. Since I couldn’t find anything about such a restriction in the X-Plane documentation, I did a quick test and edited Navigraph’s earth_nav.dat to extend the localizer 26R in EDDM.
I was able to intercept the LOC at 80 NM (I set it to 90 NM for this test), so as it seems, there is no hard restriction (at least in XP12).

Would it be possible to increase the default range to at least 25 NM? This would especially be helpful for online flying. I’m controlling on Vatsim and in EDDM the operational range is 25 NM, within 22 NM we are allowed to reduce radar separation if aircraft on both localizers are established (which obviously doesn’t work with 18 NM range).

Test was done with the default G1000 C172, the GS was received at about 50 NM (likely a matter of altitude).



That would be great for online flying!

Hi gentlemen,
thanks for the request but we must follow the “rule” of XP and his converter. We can´t manually set the ranges for the ILSes, sorry. Possible @PhilippM can change it in one of the next converter updates but we have no chance todo this, sorry.


That would be amazing.
Just to give an example why the 18 NM range is problematic:

In EDDM, we can work with two feeder positions, one working the low final (4000/5000 feet), the other one working the high final (6000 feet).
The high final starts the descent out of 6000 feet roughly at 14 NM final. The aircraft must be allowed for a 2 NM straight and level segment before the final descent, so it must be established on the localizer latest at 16 NM.
That leaves a small window of only 2 miles to vector aircraft onto the approach - take the different skill levels of vATC and vPilots and this becomes pretty much impossible in an online environment.

I’m sure, EDDM is not alone with this. 25 NM (or 27 to make it equal to MSFS) would be a great improvement to allow us to apply RW procedures.

What is interesting: In the current data set, the DME part is set to 25 NM, only LOC and GS are at 18 NM despite the X-Plane developer manual (https://developer.x-plane.com/wp-content/uploads/2016/10/XP-NAV1200-Spec.pdf) stating that the default value for LOC (row 4) and GS (row 6) is 25 NM (same for the XP11 file description, btw).

Again, it’s not what we have in our hands but possible that the X-Plane devs will change it.

Thank you

I got your point, don’t worry. I wrote that, hoping that @PhilippM is following here.

Changing the number in the file won’t have the effect that you are looking for, as it does not directly translate into the actual radio reception range of localizers/glideslopes. Unlike with VORs (terminal/low/high) there are no different categories of localizers in ARINC424, it’s all just one class.

The actual reception range is way bigger than 18nm anyway: the effective range where you can pick up the localizer is about 39 nautical miles if you are high enough (VHF line-of-sight). This works with the unmodified file (18nm in the file) so you can pick up the localizer at 39nm out of the box anyway, without tinkering with the file. Start the sim in EDNS and head east toward EDDM, you will pick up IMNE (109.5) with a reliable signal about when you pass over ETSL (roughly 40 miles out), at least if you are flying above 4000ft.
The localizer starts flickering actually a few miles even before that.
That’s the standard in 12.06 with the stock file.

X-Plane 12.07 introduces beam forms, where the localizer range is larger along it’s front beam and back beam axis, and lower outside these directions, looking something like this: https://i.stack.imgur.com/Gh65J.png
(image source https://nint.us/q/207489/)
this way, you can receive the localizer much further out, but ONLY if you are actually close to the course you are trying to intercept. That is much better than simply blowing up the range indiscriminately in all directions, which is what happens if you change the range in the file.

If you simply increased the range in all directions there are probably areas where you’d have interference, i.e. be in the “range” of more than one signal on the same frequency at the same time. If however that “range extension” is focused along the axis it needs to be, this is much less likely to cause problems.



Hi Philipp,
thanks for the explanation.

Would also thanks @PhilippM … let me know when I should do something, possible in the future :wink:


The file format remains unchanged. No change to navdata is necessary to support the beamforms that will be introduced with 12.07.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.