Sign in to follow this  
martinboehme

DME HOLD

Recommended Posts

Today, I tried using the DME HOLD function, but without success (this is with V 1.1). I tuned the frequency of the VOR/DME I wanted to hold on NAV1, and the DME readout was displayed in the HSI. I then switched the switch at the bottom left of NAV1 to DME HOLD, and the green light came on. I now tuned a different frequency, expecting the DME display to be held, but the DME display went blank.All of this was with the switch on the right hand side of NAV1 set to "NORM". I tried the same thing with the switch set to "OVRD" (what is this switch supposed to do, by the way?), but this did not make any difference.Am I doing something wrong, or is this feature just not implemented?Cheers,Martin

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Martin; Right now DME hold is a dummy function because MSFS only models two nav receivers. I have an idea or two on how I could make the function work in FS, but it's going to take doing a bunch of floating-point math in the background to implement another VOR outside of FS. It's on my "interesting sidebar projects" list, but no promises...CheersBob ScottATP IMEL Gulfstream II-III-IV-V L-300Santiago de Chile

Share this post


Link to post
Share on other sites

Bob,thanks! No problem, just wanted to know if I was doing something wrong (which is the usual reason for something not working the way I expect it to ;-) ).Martin

Share this post


Link to post
Share on other sites

Bob,I don't suppose you could get any of the guys who did the Flight1 ATR to give you a hand? That has DME hold that I think does what is being talked about here.

Share this post


Link to post
Share on other sites

Bob,I've decided to have a go at your "interesting sidebar project"... ;-)I'm attaching the source file for a gauge that does its own DME calculation based on the latitude, longitude and elevation of the DME station, as reported by FSUIPC. (This is just the one relevant source file; let me know if you need the whole project.) At the moment, I don't compute speed or time to go; as far as I can tell, the 732 doesn't display them (or does it?).Points to note:- I haven't found a way to query the maximum reception range of a DME station. One would thus have to use a fixed maximum range (maybe something around 70 nm) and inhibit the display beyond that range.- The distances I compute are about 0.3% greater than those reported by MSFS. I'm not sure why this is -- maybe MSFS uses less precision in its WGS 84 ellipsoid calculations? Anyhow, 0.3% is probably below the error tolerance for DME receivers, so one could argue that this is not a bug, but a feature... ;-)- Interestingly, FSUIPC reports the elevation for DME2 but not DME1; thus, for the case where NAV1 is a "raw" DME without a VOR signal, I have to assume the elevation of the DME is the same as that of the ground below the aircraft (see the code for details).I realize you're currently hard at work on other stuff, but maybe you can find a bit of time at some point to integrate this into the Tinmouse...? ;-) If there's anything else I can do to help, please let me know!Cheers,Martin

Share this post


Link to post
Share on other sites

FS appears to use the navaid range coded into the scenery BGL to compute a signal strength, which is available in FSUIPC. I want to try and decipher how that value is computed...then I'll have a way of taking a known distance and signal strength and using that to "back-in" (compute) the navaid range.The FSUIPC SDK shows the DME1 elevation to be a (2-byte) short value...the DME2 elevation is a (4-byte) integer value. Did you try reading a 4-byte value at the DME1 offset, perhaps?RegardsBob ScottATP IMEL Gulfstream II-III-IV-VSantiago de Chile

Share this post


Link to post
Share on other sites

>FS appears to use the navaid range coded into the scenery BGL>to compute a signal strength, which is available in FSUIPC. I>want to try and decipher how that value is computed...then>I'll have a way of taking a known distance and signal strength>and using that to "back-in" (compute) the navaid range.That's a good idea... if you like, I could try and take this on...?>The FSUIPC SDK shows the DME1 elevation to be a (2-byte) short>value...the DME2 elevation is a (4-byte) integer value. Did>you try reading a 4-byte value at the DME1 offset, perhaps?I made that mistake at first... then had another look at the documentation and changed the code to read a 2-byte value. I was still getting a nonsensical value, though (something around 50000 for a DME that should be almost at sea level), and the value seemed to be constant no matter what I tuned the NAV radio to. So it seems that this offset just doesn't work... I'll recheck to make sure, though...Cheers,Martin

Share this post


Link to post
Share on other sites

If you can figure the signal strength methodology out, I can certainly use it.On the DME offset, best to ask Pete Dowson in his forum I think.CheersBob ScottATP IMEL Gulfstream II-III-IV-VSantiago de Chile

Share this post


Link to post
Share on other sites

> If you can figure the signal strength methodology out, I can certainly use it.I'll try and see what I can come up with... I would expect signal strength to be inversely proportional to the square of the distance, with the proportionality factor reflecting the strength of the transmitter, but who knows what surprises MSFS has in store for us... ;-)> On the DME offset, best to ask Pete Dowson in his forum I think.Yep, probably best to go "straight to the source"... ;-)Martin

Share this post


Link to post
Share on other sites

Bob,I've been working on the signal strength issue, and I've got it almost nailed, but there is a slight random variation that seems to defy explanation -- which is kind of frustrating. Anyway, I thought I'd share what I've got so far in hopes that maybe you or someone else can come up with an idea.The good news is that the algorithm is less involved than I had originally feared. The three variables that enter into the calculation are the station's "innate" signal strength s (or transmission power), the horizontal distance d along the ground from the station to the aircraft's current position, and the height h of the aircraft above ground.The strength s_recv of the signal received by the aircraft can then be computed as follows:s_recv = f(s/d, h)where f is a function that attenuates the strength of the signal the closer the aircraft gets to the ground:f(x, h) = if h <= 218+c ft: x*0.0004*(h+261+c) if 218+c < h <= 4887+c ft: x*0.000173*(h+890+c) if h > 4887+c ft: xThe constants are derived from linear regressions that I ran on several sets of test data. The regressions fit the observed data beautifully -- the residual error is in the range of one or two units of signal strength, for signal strengths that range in the thousands.Unfortunately, however, the equations contain a constant c, which I have to set to a different value for every set of data (where a set of data is the signal strengths recorded at the same position for different heights above ground). The values for c that I have observed are not large -- they range between -86 feet and 88 feet -- but they are large enough to make an accurate estimation of the "innate" signal strength of the station impossible when the aircraft is close to the ground.The obvious question is: Why am I so sure that h has to be height above ground? Unfortunately, I have been able to disprove the two obvious alternative hypotheses that come to mind:Alternative hypothesis 1: h is not the height above ground at the aircraft's position, but height above the elevation of the station. I disproved this hypothesis by taking measurements at two different positions, at the same distance from the station, but over different ground elevations (around 1000 ft in one case, and 4000 ft in the other). If h was really measured relative to the station's elevation, I should have observed the same signal strengths at the same altitudes in both cases -- but the signal strengths were wildly different. The formula above explained the data much better, albeit with a variation in the constant c of about 170 feet between the two locations.Alternative hypothesis 2: h is aircraft altitude. This is disproved by the same data mentioned above because, again, the observed signal strengths should be the same at the same altitudes, which they were not.As I say, the model fits the data beautifully as long as an appropriate value for c is chosen for any given location. This is why I am pretty much convinced that the signal strength depends on some form of height or altitude, and not some angle or other alternative value. And the fact that c remains within +/- 100 feet seems to indicate that the ground elevation is involved in some form. By the way, c does not appear to depend in any systematic manner on distance from the station or on the ground elevation itself.The only explanation I can come up with at the moment is that, internally, FS2004 uses some coarser form of the "ground elevation" value than the one that is made available externally. My hope at one stage was that there could be a difference between the FSUIPC ground elevation value at 0020 (which I was using initially) and the one reported at 0B4C (which is an alternative, less precise variable), but again, this turned out not to be the case. The radio altimeter value at 31E4 was a third candidate, but this also turned out to be consistent with 0020 and 0B4C.So I'm kind of stumped here... I'm not ready to let this thing go just yet, but I'm out of ideas at the moment. Any suggestions?MartinEdit: The part of the message after the "code" sections came out in a smaller font, but I can't work out why... oh well... changed it back to use a proportional font throughout, since that seems to be more readable.

Share this post


Link to post
Share on other sites

An update: The DME1 elevation issue was due to a bug in my code. I checked the values at that offset using FSInterrogate, and it worked perfectly. So that problem's resolved.Also, I've collected a couple more data sets, and the interesting thing is that for two data sets that I collected while the aircraft was over water, the values for c match almost exactly (to within about 1.5 ft). Of course, water is completely flat... so maybe MSFS really is using a slightly different way of calculating ground elevation internally, which doesn't show up when the aircraft is over perfectly flat terrain (in this case water)?Martin

Share this post


Link to post
Share on other sites

OK Martin...thanks.I'll have a look at the DME hold with this in mind.CheersBob ScottATP IMEL Gulfstream II-III-IV-VSantiago de Chile

Share this post


Link to post
Share on other sites

Bob,didn't intend to imply that I was "dumping this in your lap" (if that's how it came across)... I hope to research this to a point where I can give you working code to work with... the elevation issue seems to be a bit of a stumper, but I hope with some more research that I'll be able to crack it...Cheers,Martin

Share this post


Link to post
Share on other sites

Martin; I've been working on the 'mouse panel again for the last few weeks. Was looking at DME hold yesterday. So the signal strength varies with the inverse of the distance, (rather than the square of the distance) in FS? What are the units for the distance d and the other variables?CheersBob ScottATP IMEL Gulfstream II-III-IV-VSantiago de Chile

Share this post


Link to post
Share on other sites

Bob,yep, it's the inverse of the distance, not the square of the distance. h and c are in feet, and d is in nautical miles.Unfortunately, though, all of this may be moot... I've made some more measurements in the meantime, intending to unravel the mystery of the constant c. I found out something else in the process, though...All my measurements up to that point had, by coincidence, been on enroute VORs. I then made a few measurements on short-range terminal VORs, and it turns out that they have different slopes in the function f and a different "cutoff" height (i.e. the height after which the signal becomes constant). That cutoff height is around 1000 feet for terminal VORs, compared to 5000 feet for enroute VORs.This pretty much kills our prospects of being able to work out the "innate" signal strength of the station. Say we're at 3000 feet and measure a certain observed signal strength. Depending on whether we have a terminal VOR or an enroute VOR, we would have to use a different formula (i.e. a different case in the formula for f(x, h)) to work out the "innate" signal strength. But we don't know whether the VOR is enroute or terminal... so we're stuck.The only possibility I see of really solving this problem is to use a "multiplexing" approach on one of the VOR receivers: Every second or so, we tune to the frequency of the "held" VOR to check its signal strength, then tune back to the station we're really supposed to be receiving. Of course, that will cause us to lose reception of the "non-held" VOR station for a certain amount of time, which is probably not acceptable if we're flying an ILS approach. So we'll have to implement a function that takes the GPS coordinates of the VOR station and computes the VOR radial or ILS localizer and glideslope deviation so we can have that information available all the time, even when we're tuned over to the "held" VOR to check its signal strength. That sounds like a bit of work... ;-)If I find some spare time at some point, I'd like to look into implementing such a system (and probably making it available as a library for others to use), but I probably won't get round to it anytime soon...So it looks as if you'll have to put off the DME hold functionality for the moment or implement it using a fixed reception range...Cheers,Martin

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this