Actually, I think we can get there, at least if my assumptions are correct.FS models three types of VORs...High, Low, and Terminal. Let's assume that the unattenuated signal strength at the station is a constant for each type (why wouldn't it be?)Then if we know the means to compute the signal strength for each type, all I have to do is compute the expected signal strength for each type of station, and then compare it to the value being reported by FS. That should give us the ability to determine what kind of station it is, and how to emulate a signal coming from it locally in the panel.The multiplexing will be needed anyway, maybe every 5 sec or so, just to make sure that the navaid on the freq being held is still the one we're emulating...necessary in areas of overlapping coverage where capture effect dictates which station is displayed.So what we'll need is the function for each of the three types of VORs in FS...then I'll bet I can make the rest work in software.RegardsBob ScottATP IMEL Gulfstream II-III-IV-VSantiago de Chile

>FS models three types of VORs...High, Low, and Terminal. Um... yeah, you're right. Didn't remember what the names of those types were (it's a couple of weeks back that I did the measurements) and I wanted to restrict myself to two types to keep the description simple... but I actually measured both Low and Terminal VORs (previously, I had been measuring only High VORs), and they are both different from High VORs. They are similar to each other, but not identical...>Let's assume that the unattenuated signal strength at the>station is a constant for each type (why wouldn't it>be?)>>Then if we know the means to compute the signal strength for>each type, all I have to do is compute the expected signal>strength for each type of station, and then compare it to the>value being reported by FS. That should give us the ability>to determine what kind of station it is, and how to emulate a>signal coming from it locally in the panel.Yes, that's a good idea! There will still be the small risk of encountering an ambiguous situation where the expected signal strength for two types of station is the same (or almost the same)... this can happen because the Terminal VOR, for example, starts out with a higher slope, then bottoms out earlier, while the High VOR starts out with a lower slope, but bottoms out higher... so at some point, they intersect...But the probability of encountering this situation should be fairly low...>The multiplexing will be needed anyway, maybe every 5 sec or>so, just to make sure that the navaid on the freq being held>is still the one we're emulating...necessary in areas of>overlapping coverage where capture effect dictates which>station is displayed.That's a good point... I had thought of this, too, but decided to ignore it (on the grounds that DME hold will usually be used in a terminal environment, where it isn't likely we'll be straying very far from the "held" VOR anyway -- a bad hack, I admit). Question is, if we're multiplexing anyway, why don't we just decide to be lazy and let that handle the signal strength issue as well? Not as intellectually pleasing, I admit... but it would take care of the problem of the mystery constant c, which is also still open.>So what we'll need is the function for each of the three types>of VORs in FS...then I'll bet I can make the rest work in>software.I'll see what I can come up with. Can't make any promises as to when I'll be able to work on this, though...Martin

Been doing some more work on this... I've changed course slightly and decided that I probably won't crack the question of how signal strength gets computed any time soon. Instead, I'm going to reimplement the VOR and ILS functionality, except for the signal strength computation... I can then have one NAV receiver cycling through all of the relevant frequencies, periodically checking their signal strengths and coordinates (in case we've come in range of a different VOR station on the same frequency).My plan is to have NAV1 doing this cycling -- I've done some tests, and MSFS seems to take about a second to update the NAV information when I change the frequency, so that would mean a four-second update cycle if I've got a DME hold on both NAV sets. I've got to do the cycling on NAV1 exclusively because I need NAV2 for doing audio idents of NAV stations.I've got the VOR and ILS code just about finished; there's just one small issue left to deal with, the localizer beam width -- see the discussion over on Pete Dowson's forum:http://forums.simflight.com/viewtopic.php?t=61197The problem is that different localizers have different beam widths, and that value can't be read via FSUIPC. Pete has identified a mystery two-byte field that may contain the beam width, but if that doesn't work, I have a Plan B: In principle, I can compute the beam width from the current localizer deviation (as reported by MSFS) and the angular deviation (which I compute myself), but that only works as long as the needle isn't pinned. And in the standard ILS interception scenario, the needle starts off pinned, and then when it does start moving, it starts moving pretty fast. With NAV1 taking about four seconds to cycle through the frequencies, it can be four seconds before I realize that the localizer has come alive. That's a bit too much... However, NAV2 can come to the rescue and monitor the localizer in this situation, since it's pretty unlikely that the ident feature will be in use during the interception. So that problem is pretty much covered, too.There is one open question, though: Does your panel use the standard autopilot functionality, or do you have custom autopilot code? If you're using the standard autopilot, then it's going to get seriously confused if I start cycling the NAV1 frequency around... so in that case, I would have to write some custom autopilot logic, too. Keeping my fingers crossed that you already have custom autopilot code in place...Cheers,Martin