Jump to content
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

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


Bob Scott | President and CEO, AVSIM Inc
ATP Gulfstream II-III-IV-V

System1 (P3Dv5/v4): i9-13900KS @ 6.0GHz, water 2x360mm, ASUS Z790 Hero, 32GB GSkill 7800MHz CAS36, ASUS RTX4090
Samsung 55" JS8500 4K TV@30Hz,
3x 2TB WD SN850X 1x 4TB Crucial P3 M.2 NVME SSD, EVGA 1600T2 PSU, 1.2Gbps internet
Fiber link to Yamaha RX-V467 Home Theater Receiver, Polk/Klipsch 6" bookshelf speakers, Polk 12" subwoofer, 12.9" iPad Pro
PFC yoke/throttle quad/pedals with custom Hall sensor retrofit, Thermaltake View 71 case, Stream Deck XL button box

Sys2 (MSFS/XPlane): i9-10900K @ 5.1GHz, 32GB 3600/15, nVidia RTX4090FE, Alienware AW3821DW 38" 21:9 GSync, EVGA 1000P2
Thrustmaster TCA Boeing Yoke, TCA Airbus Sidestick, 2x TCA Airbus Throttle quads, PFC Cirrus Pedals, Coolermaster HAF932 case

Portable Sys3 (P3Dv4/FSX/DCS): i9-9900K @ 5.0 Ghz, Noctua NH-D15, 32GB 3200/16, EVGA RTX3090, Dell S2417DG 24" GSync
Corsair RM850x PSU, TM TCA Officer Pack, Saitek combat pedals, TM Warthog HOTAS, Coolermaster HAF XB case

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


Bob Scott | President and CEO, AVSIM Inc
ATP Gulfstream II-III-IV-V

System1 (P3Dv5/v4): i9-13900KS @ 6.0GHz, water 2x360mm, ASUS Z790 Hero, 32GB GSkill 7800MHz CAS36, ASUS RTX4090
Samsung 55" JS8500 4K TV@30Hz,
3x 2TB WD SN850X 1x 4TB Crucial P3 M.2 NVME SSD, EVGA 1600T2 PSU, 1.2Gbps internet
Fiber link to Yamaha RX-V467 Home Theater Receiver, Polk/Klipsch 6" bookshelf speakers, Polk 12" subwoofer, 12.9" iPad Pro
PFC yoke/throttle quad/pedals with custom Hall sensor retrofit, Thermaltake View 71 case, Stream Deck XL button box

Sys2 (MSFS/XPlane): i9-10900K @ 5.1GHz, 32GB 3600/15, nVidia RTX4090FE, Alienware AW3821DW 38" 21:9 GSync, EVGA 1000P2
Thrustmaster TCA Boeing Yoke, TCA Airbus Sidestick, 2x TCA Airbus Throttle quads, PFC Cirrus Pedals, Coolermaster HAF932 case

Portable Sys3 (P3Dv4/FSX/DCS): i9-9900K @ 5.0 Ghz, Noctua NH-D15, 32GB 3200/16, EVGA RTX3090, Dell S2417DG 24" GSync
Corsair RM850x PSU, TM TCA Officer Pack, Saitek combat pedals, TM Warthog HOTAS, Coolermaster HAF XB case

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


Bob Scott | President and CEO, AVSIM Inc
ATP Gulfstream II-III-IV-V

System1 (P3Dv5/v4): i9-13900KS @ 6.0GHz, water 2x360mm, ASUS Z790 Hero, 32GB GSkill 7800MHz CAS36, ASUS RTX4090
Samsung 55" JS8500 4K TV@30Hz,
3x 2TB WD SN850X 1x 4TB Crucial P3 M.2 NVME SSD, EVGA 1600T2 PSU, 1.2Gbps internet
Fiber link to Yamaha RX-V467 Home Theater Receiver, Polk/Klipsch 6" bookshelf speakers, Polk 12" subwoofer, 12.9" iPad Pro
PFC yoke/throttle quad/pedals with custom Hall sensor retrofit, Thermaltake View 71 case, Stream Deck XL button box

Sys2 (MSFS/XPlane): i9-10900K @ 5.1GHz, 32GB 3600/15, nVidia RTX4090FE, Alienware AW3821DW 38" 21:9 GSync, EVGA 1000P2
Thrustmaster TCA Boeing Yoke, TCA Airbus Sidestick, 2x TCA Airbus Throttle quads, PFC Cirrus Pedals, Coolermaster HAF932 case

Portable Sys3 (P3Dv4/FSX/DCS): i9-9900K @ 5.0 Ghz, Noctua NH-D15, 32GB 3200/16, EVGA RTX3090, Dell S2417DG 24" GSync
Corsair RM850x PSU, TM TCA Officer Pack, Saitek combat pedals, TM Warthog HOTAS, Coolermaster HAF XB case

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


Bob Scott | President and CEO, AVSIM Inc
ATP Gulfstream II-III-IV-V

System1 (P3Dv5/v4): i9-13900KS @ 6.0GHz, water 2x360mm, ASUS Z790 Hero, 32GB GSkill 7800MHz CAS36, ASUS RTX4090
Samsung 55" JS8500 4K TV@30Hz,
3x 2TB WD SN850X 1x 4TB Crucial P3 M.2 NVME SSD, EVGA 1600T2 PSU, 1.2Gbps internet
Fiber link to Yamaha RX-V467 Home Theater Receiver, Polk/Klipsch 6" bookshelf speakers, Polk 12" subwoofer, 12.9" iPad Pro
PFC yoke/throttle quad/pedals with custom Hall sensor retrofit, Thermaltake View 71 case, Stream Deck XL button box

Sys2 (MSFS/XPlane): i9-10900K @ 5.1GHz, 32GB 3600/15, nVidia RTX4090FE, Alienware AW3821DW 38" 21:9 GSync, EVGA 1000P2
Thrustmaster TCA Boeing Yoke, TCA Airbus Sidestick, 2x TCA Airbus Throttle quads, PFC Cirrus Pedals, Coolermaster HAF932 case

Portable Sys3 (P3Dv4/FSX/DCS): i9-9900K @ 5.0 Ghz, Noctua NH-D15, 32GB 3200/16, EVGA RTX3090, Dell S2417DG 24" GSync
Corsair RM850x PSU, TM TCA Officer Pack, Saitek combat pedals, TM Warthog HOTAS, Coolermaster HAF XB case

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


Bob Scott | President and CEO, AVSIM Inc
ATP Gulfstream II-III-IV-V

System1 (P3Dv5/v4): i9-13900KS @ 6.0GHz, water 2x360mm, ASUS Z790 Hero, 32GB GSkill 7800MHz CAS36, ASUS RTX4090
Samsung 55" JS8500 4K TV@30Hz,
3x 2TB WD SN850X 1x 4TB Crucial P3 M.2 NVME SSD, EVGA 1600T2 PSU, 1.2Gbps internet
Fiber link to Yamaha RX-V467 Home Theater Receiver, Polk/Klipsch 6" bookshelf speakers, Polk 12" subwoofer, 12.9" iPad Pro
PFC yoke/throttle quad/pedals with custom Hall sensor retrofit, Thermaltake View 71 case, Stream Deck XL button box

Sys2 (MSFS/XPlane): i9-10900K @ 5.1GHz, 32GB 3600/15, nVidia RTX4090FE, Alienware AW3821DW 38" 21:9 GSync, EVGA 1000P2
Thrustmaster TCA Boeing Yoke, TCA Airbus Sidestick, 2x TCA Airbus Throttle quads, PFC Cirrus Pedals, Coolermaster HAF932 case

Portable Sys3 (P3Dv4/FSX/DCS): i9-9900K @ 5.0 Ghz, Noctua NH-D15, 32GB 3200/16, EVGA RTX3090, Dell S2417DG 24" GSync
Corsair RM850x PSU, TM TCA Officer Pack, Saitek combat pedals, TM Warthog HOTAS, Coolermaster HAF XB case

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

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  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...