VOR ranges severely reduced in AIRAC 2109?

First let me commend Navigraph for picking up on the increased interest in old-fashioned VOR to VOR navigation, when I read the announcement I was full of joy (pretty much exclusively flying the DC-6 without GPS).

Having said that, since I upgraded to 2109 I found that a large number of VORs now have a greatly reduced range. Is this a coincidence, or were NAV ranges indeed reduced in the new cycle? I am using LNM for my VOR route planning, and in the past the VOR range info in LNM (usually either 40 nm or 130nm) was 100% in sync with the behavior in the Sim. Just today I came across 3 VORs that are supposed to have a 130nm range and two of those I only received from 80nm, and the other even just within 60nm.

Is this range reduction related to the new Navigraph cycle and done on purpose? I know I should have tested the same VORs with just stock MSFS data and wouldn’t have to speculate, I’ll do this when I find some time…

Thanks,
Dirk

Hi Dirk,
two questions/requests:

  1. any VOR example(s) is/are very helpful instead a global statement - it´s easier for us, to reproduce it and to cross-check it between the difference datasets (MSFS, LNM, …)
  2. you wrote you use LNM, you can set the AIRAC cycle from the MSFS or from Navigraph. Which one have you used?

Thank you,
Richard

Hi Richard,

Sure, will absolutely provide examples as soon as I get to it. Main intention of my post was to find out first if there were intentional VOR range reductions in the AIRAC cycle, or if what I was seeing is caused by something outside of Navigraph…

Yeah it’s also cycle 2109, I always update MSFS and all other tools (LNM, P2A etc) at the same time. In LNM I have “Use Navigraph for Navaids and Procedures” set

I’ll get you a list of example VORs.

Thanks!
Dirk

Hi Dirk,
when you plan a flight (VOR - VOR) in LNM, you shouldn´t use the Navigraph Navdata in LNM - you should use the MSFS data only because we have adjusted the ranges in MSFS to more or less real ranges. I don´t know which ranges LNM uses but I guess the FAA minimum standard ranges. There is and was no indicator in our data for this, only the type/power of the navaid.
LNM must convert these type/power flag into a specific range, but that´s not in our hand.

When you use the MSFS data, you will see the correct ranges and you can be sure, that you received the signals in this ranges in MSFS.

So, click on “Do not use Navigraph database” and select “Microsoft Flight Simulator 2020”. You will see the correct ranges than (of course, when you have re-build the scenery data in LNM).

Cheers,
Richard

Hi Richard,

ahh… I assumed that since I always update both MSFS and LNM to the same cycle this setting wouldn’t really matter and either setting would have the same result. So you are saying that because the current cycle has special modifications (to make VOR navigation more realistic) it actually does make a difference… I’ll try this out and let you know!

Thanks!

Dirk

Hi Richard,

I followed your suggestion and switched to ‘Do not use Navigraph database’ (after rebuilding the scenery data) - and now it’s actually worse :stuck_out_tongue_winking_eye:

The 3 VORs that previously showed a range of 130nm with Navigraph data now show up with a range of 195nm, so the error in planning would even be much greater.

Here are the VORs from my last flight plan that had the issue:

WRB (Warburg)
FUL (Fulda)
LBU (Luburg)

All three show up with 130nm with Navigraph data enabled, and show 195nm without. And the distances from which I actually received the VOR signals in the Sim were about 80nm for WRB, 100nm for FUL, and 60 nm for LBU. Can you check what the correct range for these VORs (from Navigraphs perspective) should be?

Another odd thing I noticed after I disabled the Navigraph data in LNM - now it seems all Nav procedures (STARs, SIDs, and approaches) are duplicated in LNM:

When I switch back to use Navigraph data everything is fine again.

Thanks!
Dirk

Guten Morgen Dirk,
as I wrote before, there is no real value for the ranges available in the ARINC424 source, only the type and power of the navaid. There are FAA minimum recommendation which we used till 2108 for the MSFS because the MSFS expect the ranges in nautical miles.

FAA minimum VHFNavaid ranges:

So, we have set 25,40 and 130 NM till AIRAC 2108. Due several requests and the fact that in real-world in some areas the ranges are extended, we have decided to use a real-world range-table from AIRAC 2109 on. That means in MSFS (and only in MSFS because no other addon uses these value) we have set the ranges more or less to realistic ranges. Therefore the increasing range from 130 to 195NM … 130NM is the minimum guarantee signal strength for a high-altitude VHFNavaid (see the FAA table), but in real, the signal can be receiving above the 130NM minumum range.

LNM doesn´t have this conversion table, LNM can only be used the SSV Designator to identify which type of navaid it is (terminal, low or high) and depending on this LNM will set the correct FAA minimum 5, 40 or 130NM. That´s the different.

You see this very clear in your examples, when you switch on/off our database:
WRB with Navigraph database, defined as high-altitude navaid (H) with 130NM
WRB without Navigraph database (using only the MSFS data), defined also as high-altitude navaid (H) but with a range of 195NM

Again, these values/ranges come from another real-world source and are not part of the ARINC424 so, LNM can´t show other ranges as the recommended from the FAA.

To your second question about the double procedures:
LNM doesn´t filter out the MSFS stock procedures, therefore you see both the procedure from the stock-data and the Navigraph data. When you look on airports, where no procedures are available in the stock data (ie. NZWR), you see the procedures only from our dataset:
image

comparing an airport, where stock data are available - you see the double entries:

So, this is more a LNM limitation then a navdata issue. In our dataset all procedures are only once …
Hope that helps,
Richard

These are exactly the “operational coverage ranges” as published in German AIP for these 3 facilities. See here
German AIP

Hervé

1 Like

Additional to Hervé´s answer, I have figured out the issue in LNM is, that LNM only shows the stock navaids instead our navaids with the correct range. You see this on the scenery-path when you select the navaid.

So, when you have set the MSFS 2020 and NO navigraph-data, you will also see these:
image

You see, the navaid will be loaded from the stock data and not from the navigraph-MSFS data. That seems also an LNM issue. That explain, why you don´t see the 80NM for the WRB navaid as an example, but you receive it in the MSFS within 80NM. Sorry.

Cheers,
Richard

Hi Richard,

thank you very much for your detailed explanation! It’s indeed a bit confusing, due to having stock-MSFS, Navigraph-MSFS, and Navigraph data all playing together :stuck_out_tongue_closed_eyes:

So just to make sure I understand everything right:

  1. the latest AIRAC cycle for MSFS modified two things - increasing the max ranges for the SSV designators from 130nm to 195nm, and at the same time adjusting the real reception range (as experienced in the Sim) for the VORs, which resulted in the case of the VORs in my example in the reduction of the ranges to 80nm, 100nm, and 60nm.

  2. LNM only displays the ranges that are mapped according to the SSV, not the actual ranges effective for fliying in the Sim. Previously, the mapping for High VORs was the same for MSFS stock data and Navigraph data - 130nm, and the actual reception range for flying was also 130nm. Now for MSFS-Navigraph data that mapping has changed, so when using Navigraph data in LNM (which is non-MSFS Navigraph) it still displays 130nm, but when turning Navigraph off then it displays 195nm. But that means it must take it from the new MSFS-Navigraph BGL file, right? Which would contradict what you were saying in your last post, and I guess that’s why I’m still a bit confused. Maybe I’m still not clear on how exactly the ‘real’ range (relevant to flying in the Sim) and the SSV to max range mapping really are connected in the BGL files…

In any case, is there any way for LNM to find the effective range (e.g. 80nm) from the Navigraph BGL files? If so I will report this issue to Alex and hopefully he can fix this, as it stands right now with the new data it’s practically impossible to do meaningful VOR route planning any more :frowning_face_with_open_mouth:

And even if this can be fixed (LNM displaying the adjusted real ranges), I hate to say this, but the well meant intention of making VOR navigation ‘more realistic’ also makes old fashioned VOR-VOR navigation even more difficult than it already was, but I guess we can’t have it all :cry:

Thanks,
Dirk

Hallo nochmals Dirk,
yes, indeed it wasn´t very clear from my side and the two posts where indeed a little bit confusing, therefore thanks for your summary. Here are mine (Navigraph MSFS Airac installed and Navigraph LNM data installed) :slight_smile:

In MSFS you have ONLY the real ranges from AIRAC 2109 on and not any “placeholder” which results from the FAA table. Therefore you have 80, 100, 60 NM and so on …

In LNM you will never seen these changes because LNM only shows you the stock (NavBlue) navaids and not the (Jeppesen) navaids which are in our packages, where the ranges are correct. Possible Alex knows an answer. And yes, you can read the ranges from the BGLs - LNM does the same with the stock (NavBlue) data (look at the screenshot) - so it´s also possible with our (Jeppesen) data.

So, the real question is:
Why LNM doesn´t show the MSFS (Jeppesen) navaids also (as the procedures, runways, ILS, …)

Sorry again for the confusion … :wink:
Richard

Hi Richard,

thanks for the clarification! I think I got it now… :wink:

It’s unfortunate that ‘making it more real’ also has the unintended consequence that it’ll now be harder to do pure VOR navigation (that’s assuming that overall the VOR range reductions outweigh any VOR range extensions or new VOR additions, if there are any at all). I still dream of a day where Navigraph will come out with a ‘Retro’ cycle edition that would include all the navaids of an earlier era :upside_down_face:

Hi Dirk,

But, as you mentioned, that’s real life :wink:
Very often, when you perform “off route” VOR to VOR navigation in real life (now and before), you may lose the first VOR reception (FROM) before acquiring the next (TO) one. It should not be so long unless you (unrealistically) use 2 very distant VORs. Keeping the aircraft last track (wind corrected heading) will nearly always do the job and it is a stimulating experience :ok_hand:

Oh yeah I know, have already been doing this for routes over areas with sparsely populated VORs… Guess I just have to get used to it more often now :wink:

Thanks Hervé!

Dirk

Alex doesn’t seem to have a solution. Over at the MSFS forum he said LNM cannot use any nav data replacements in MSFS, and he recommends to always use the Navigraph data within LNM because information is lost when going through the MSFS BGL files (Little Navmap 2.6.16 stable version released (update 15) - #891 by albar965 - Tools & Utilities - Microsoft Flight Simulator Forums)

So I guess in regards to VOR navigation planning we are now screwed when using LNM and Navigraph… :frowning_face:

Hi,
I will add the correct ranges in the LNM Navigraph dataset also, that all are in sync … should be done latest with the next AIRAC cycle 2110 or any revision between.

Cheers,
Richard

That would be awesome Richard, you are my hero! :smiling_face_with_three_hearts:

Thanks!
Dirk

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