Yep!
If you’re going to look at Navigraph information about navaids but using the default MS/Asobo nav data, you’re definitely going to see disconnects between them as far as type of navaid, ranges, and even their existence! Hopefully that’s the disconnects you’re seeing.
Hope that’s all it is!
Regards
1 Like
Let me understand: I install Navigraph hub, it creates a new navaids database in MSFS. I then refresh the LNM database and I have the correct VORs on LNM also?
Thx.
There are two separate programs. One will update the navdata for MSFS. The other program can update other applications such as LNM. When it has updated the LNM navdata you need to load the new data.
In this case, the simulation is very simple.
In the navdata BGL, each individual station has a range field specified in meters. This is the range used, no matter the category of VOR (terminal, low alt, or high alt). Then, during the radio sim update loop the slant distance to the station is obtained. Finally, a range scalar depending on alt is obtained from an in-code table based on FAR and AIM charts to scale the range based on alt for the VOR categories. The slant distance is compared to the scaled range to obtain whether or not the distance exceeds the range.
Terminal VORs reach full range by 1000ft AGL and keep full range until 20K, falling off to no range by 25K. Low alt VORs reach full range by 1000ft AGL and stay until 40K, reaching no range at 45K. High alt VORs reach full range at 5000ft and stay until 60K, reaching no range at 65K.
The radio is either in range or not, there is no simulation of a transitional area, and it’s unclear how such a feature would work from a sim perspective. As such, the primary driver of the received range is the individual facility range field, which, for the NavBlue/FAA combined data comes from the source data if available.
I think LNM is using the category to display a range estimate, which I think may have been accurate for FSX, but I can’t say for certain where they are getting their station ranges from, as they don’t seem to exactly match the underlying BGL station range in meters.
3 Likes
Thanks so much for the information!!
Regards!
I hear you, but unfortunately this is an inaccurate method. As I explained above, the nominal ranges in the SSVs are often exceeded on airways, so basing them solely on that (source data) classification is going to leave large gaps in some places, before we even address the lack of transition/reception on the periphery of the SSV.
Unfortunately we have no better data to go on. I’m not sure what alternative is being suggested here.
Folks like Navigraph or other modders can change the range of any station if the sim’s range data isn’t giving the desired results.
I’m not sure what alternative can be offered, other than manual editing, because I don’t think the source data specify the nominal range, just the SSV classification.
Just a quick example: J156 between EKR and ILC is 321nm. Both are VORTAC (VH), which are nominally 130nm range in the SSV. So with the methodology in the sim, that’s going to leave a 61nm (prior to slant range) coverage gap.
For those in the room that are curious, those SSVs were designed to “protect” a certain radius around a navaid, in which you were guaranteed off-route coverage. Back in the day, there were almost twice as many VORs (especially in the eastern US), so your range wasn’t just limited by line of sight and transmitter power, but by interference from other VORs using the same frequency. With the reduction of VORs and subsequent MON program, some of those actually useful (not “off-airway guaranteed” SSV) ranges have been extended by nature of removing competing VORs.
The sim almost needs to run these as a simulation within the sim of LOS and power. Otherwise it’s either adding a slush range to the existing ones or manually editing the ones that call for it.
1 Like
This comes back to the same problem, though. Were does the power data for each station come from? How do you determine which stations have what power while also keeping the ability to make stations have individual ranges and not just range by class?
That’s just it, I don’t think there’s a publicly-available source. I’ve seen things quoted from 100 to 200W for a (H) VOR.
Here’s a study done in 1978 showing a fairly wide range of transmitter power: https://www.tc.faa.gov/its/worldpac/techrpt/rd77-106.pdf
I don’t expect that to be accurate 45+ years later, but it goes to show the scope of the issue.
But at the end of the day, we need to close those gaps. Hopefully folks in the right places are aware of the issue and have a process to mitigate it.
Well, we’re those folks. 
But, unfortunately, I’m not seeing a reliable process to mitigate this issue, other than just slapping an extra 25-40% range to VORs, which seems like it might close a few gaps but also make even more stations reachable far beyond what they should be. There just isn’t available data nor any physical modeling process that is a magic bullet here.
Maybe someone is seeing a potential solution that I’m not, but I’m having trouble conceiving of a technical solution to this problem that doesn’t require a manual survey and range adjustment of each VOR connection in context, which simply is beyond any reasonable resource requirement to pull off, especially for a form of nav that is rapidly being deprecated worldwide.
2 Likes
Yeah, there isn’t a magic bullet, not a publicly available one at least. I checked the NASR data and it only gives output power for NDBs. It’ll likely be down to manual manipulation based on maximum airway segment length between stations and/or COPs. Be that as it is, looking at the NASR data I can immediately identify several routes that require this. Just using the COP column alone will identify several (if they are farther than 130nm).
I’m sure you already know that some localizers also have very extended service volumes, so they run into this same default categorization issue as well.
Point of order that you can actually derive maximum distance between stations on airway segments using the NASR data. That might be a quick and dirty way to see which ones need manual manipulation.
What about just simply giving easy access for users to edit the range data they perceive to be wrong in a similar vain to the new scenery gateway there could be a nav data gateway. That opens up a big resource pool for manual corrections.
Glad to see this is still being intermittently discussed. I hope '24 addresses this.