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.
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
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
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Ʃ
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
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Ʃ
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
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
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
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?
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
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
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.