Some VORs showing and functioning as low altitude after update

[thomsany]

Hi, I am using the latest Navigraph navdata update for MSFS2020 and now I see lots of VORs are being reported by my latest version of the PMS GTN750 as low altitude VORs.
For example, TBG, GCM used to be High altitude VORs now they show as low altitude VORs and work like a low altitude VOR with low reception range, contrary to what it was before.
I removed the Navdata and reinstalled it, problem remains the same. How can I fix this so the VORs are recognize as they are IRL? Example image attached from the PMS GTN 750 latest version.

[NAVDataOld]

Hi,
both examples are classified as “undefined” in the data-source, that means it´s unknown if this is a low, high or terminal navaid. The navaid-type “undefined” can´t be set in the MSFS data and therefore we set all “undefined” navaids to LOW. This category will be offered by the countries and it seems, that they don´t offer it, sorry.

By the way, I have checked all cycles till 2211 and in all cycles these examples are “undefined” - so, that has nothing todo with a cycle change. That so since years now …

Again, we don´t get this kind on information for TBG and GCM and therefore we set all these “undefined” types to “LOW”.

Cheers,
Richard

[thomsany]

Hi Richard, then I activated the Navigraph Navdata at some point instead of keeping the default ASOBO one that had the correct one.

Removing your Navdata fixed the issue.

Thanks!!

Teo

[hervesors]

Hi all,

According to Cayman Islands AIP, GCM VORDME coverage is 135 NM, so it is probably a high power VOR (even if reported as undefined).
Considering TBG VORDME is part of many high airways, the same is probably true for it with an estimated coverage of at least 150 NM (Panama AIP is not available online)
Hope it will help

Hervé

[NAVDataOld]

Thats possible all true Herve, but we must set a default value for MSFS when the navaid is “undefined” and we have only two options, set it to LOW or HIGH … We don’t have the ranges in our source (using A424v18) so we must use the navaid-class to identify it … and here it’s classified as “undefined”.

Sometimes low is correct, sometimes high … It is not correct everywhere but there is no other way to identify the naivaid class.

Hope that helps too
Richard

[hervesors]

Hi Richard,

Thanks for the clarification
But, does it affect effective range reception in MSFS on VOR and DME receivers after Navigraph navdata are installed?
If it is the case, those “undefined” VOR will only provide information within 40 NM
Probably a better “conservative” choice would then to define these VORs as HIGH since I believe most of them have a higher coverage

Kind regards

Hervé

[Rodeo314]

I have to agree that defaulting to high for ‘undefined’ becomes high makes more sense. The current default seemingly results some navaids that would be usable IRL actually not usable in the sim, making the sim more restrictive than real life, where defaulting to being more permissive would be more convenient and/or less annoying.

Regards,

Tim

[NAVDataOld]

I will set the default to HIGH in one of the next cycles. It’s funny that this setting is valid for 4 years and now it seems an “issue” and everyone means to know it better. But I will set it to HIGH …

Cheers
Richard

[Rodeo314]

I suspect most people (myself included) rarely if ever use radio-based navigation enroute, which would reduce the number of complaints (although the forum itself found 3-4 other threads about this issue, AFAICT, which does seem like a lot considering the majority of simmers likely fly RNAV).

I stumbled on this topic by accident; to me it just makes common sense, that, when precise information is not available in the source, it might be considered “better” to be a bit more permissive than IRL, as opposed to more restrictive.

Regards,

Tim

[Rodeo314]

Also, one of the related topics found by the forum shows you seemingly came to the same conclusion in 2021 but perhaps never got around to implementing it?

VOR range data

Hi, thanks for this report - Indeed (and that means I can confirm) it´s a little bit strange all the different values from one and the same database I have tried to find out why this happen now because I was also curious. This VORDME (MGA) what you have found is really special because the range/power is “unknown” and therefore everyone define it in another way. We define VHF navaids, which have no official classification (=unknown) as LOW VHFNavaids with 125Nm. The LNM developer define…

We will change this in the near future for MSFS. In the near future, all “unknown” VHF navaids will be “HIGH” with a range up to 130Nm.

Regards,

Tim

[NAVDataOld]

Again, we don’t have the range information in our source therefore I can only use the navaid class to identify the navaid range.

I have here three tickets which report exactly the opposite (AIRAC 2101). According our remarks in github, that was exactly the reason why we change the “undefined” navaids to LOW.

I will set the “undefined” now to HIGH and will reference to this topic. Undefined is undefined and no one from you knows if its a HIGH or a LOW navaid because when it’s so clear, the countries will report this more accurate.

Cheers
Richard