The SDK says that ADF_NEEDLE returns a "16 bit pseudodegrees"...What I am seeing is the raw value return as a range from -584 to -225What is the correct "formula" for calculating and displaying the ADF Bearing relative to the a/c's current position.I've seen plenty of XML examples, but having a clue what the C equivalent to "dnor" is, so the XML examples are pretty useless.Note to self: Next time you're in Redmond, remember to slap whoever thought "16 bit pseudodegrees" was a "good idea" silly!

ADF_NEEDLE * 360 / 65536As for where it came from... 16bit was the largest data size that would fit in a CPU register at the time this stuff was originally being written. They wanted to use register sized variables for speed.

>ADF_NEEDLE * 360 / 65536>>As for where it came from... 16bit was the largest data size>that would fit in a CPU register at the time this stuff was>originally being written. They wanted to use register sized>variables for speed.Thanks, but unfortunately that 'formula' yields -03 when the correct answer should be 133...Worse, when the correct answer should be 319, I see -02... Changing to ADF_NEEDLE * -360 / 65536 yields 003 and 002 respectively...

Sorry, I was explaining how to convert the pseudo degrees to normal values.However, I took a few minutes to examine the behavior of the value in FS...The ADF_NEEDLE as near as I can tell isn't providing pseudodegrees, rather it's providing an offset to determine the relative bearing from the plane's current position.As example I placed a plane on the active at KSEA and tuned the ODD NDB. The plane's heading was 340.. and the value of the ADF_NEEDLE was -180. 340 + -180 = 160. According to AFSD the bearing to the ADF is 161.Hope that helps.

>Sorry, I was explaining how to convert the pseudo degrees to>normal values.>>However, I took a few minutes to examine the behavior of the>value in FS...>>The ADF_NEEDLE as near as I can tell isn't providing>pseudodegrees, rather it's providing an offset to determine>the relative bearing from the plane's current position.>>As example I placed a plane on the active at KSEA and tuned>the ODD NDB. The plane's heading was 340.. and the value of>the ADF_NEEDLE was -180. 340 + -180 = 160. According to AFSD>the bearing to the ADF is 161.Funny you see that... the raw value return here will range from -584 to -225 (which coincidentally is precisely 359 degrees...Using the raw variable return with a "needle" isn't an issue. That works just fine.However, I need to display the DIGITAL value, and that's where the problems are arising. FLOAT64 adfdir = 0; MODULE_VAR mvadfdir = { ADF_NEEDLE }; lookup_var(&mvadfdir); adfdir = mvadfdir.var_value.n;adfdir is the variable name that reports -354 when the actual bearing to the ADF is 320... No amount of math I've tried will convert that consistently to the correct bearing. Note the plane's current heading is 313, which is the approach for rwny 31...Usually, when I have a "problem" with the C token variables, I can get what I need from the XML variables. However in this case,execute_calculator_code("(A:ADF1 RADIAL,degrees)",&adfdir,NULL,NULL);sets adfdir to precisely -354 under the same test conditions... The test gauge on the left is using the fetched XML variable ADF1 RADIAL, and the RTU's display on the right is using the C variable.http://img46.imageshack.us/img46/3234/rtuxls0000027lo.jpg

Yep, definitely something odd going on.Ok, I tuned 3 separate NDBs around KSEA: ODD, RNT, and SZ.I used AFSD to see what the bearing was to them.ODDAFSD To HDG: 161ADF_NEEDLE: -180Plane Heading: 340(360 + ADF_NEEDLE) = 180;(Plane Heading + 180) = 520;(520 - 360) = 160;RNTAFSD To HDG: 024ADF_NEEDLE: -316Plane Heading: 340(360 + ADF_NEEDLE) = 44;(Plane Heading + 44) = 384;(384 - 360) = 24;SZAFSD To HDG: 340ADF_NEEDLE: -360Plane Heading: 340(360 + ADF_NEEDLE) = 0;(Plane Heading + 0) = 340;Three separate NDBs from KSEA area... three valid results. Try it yourself is all I can offer... perhaps there's something wrong with the NDB you're using? Wouldn't be the first navaid that was 'wrong' in MSFS.

Thank you! With a bit of faffing about, I finally found the correct formula:lookup_var(&mvheading);heading = mvheading.var_value.n; //heading is the acft's current headinglookup_var(&mvadfdir);adfdir = mvadfdir.var_value.n; //adfdir is the ADF_NEEDLE variable //calculate the corrected offset from acft's current heading:adfdir = (360 + adfdir + heading) ;//now, correct for excursions outside the range 0 to 360 degrees:if (adfdir > 359) { adfdir = adfdir - 360 ; }if (adfdir < 0) { adfdir = adfdir + 360; }

Ok... so I dug deeper.HEADINGvar.var_value.n = 270AFSD To HDG: 025ADF_NEEDLE: -605adf_hdg = (ADF_NEEDLEvar.var_value.n && 0x1ff) // adf_hdg = 419adf_hdg = (adf_hdg * 360) / 512; // adf_hdg = 294.6Now, that's relative to your heading... so... rounding up... and..295-270 = 25;The key is... you have to strip all bits past the 256-bit mark... the 0x1ff will accomplish that. Once done... multiply the value by 360 degrees... divide by 512 possible values... viola!

Amazing! That proves once again that there's more than one way to skin a cat... ;)Thanks for digging...

No problem.Wanna show me how to take an EG gauge and turn it into a GDI+ gauge?*runs off laughing maniacally*

"adfdir = (360 + adfdir + heading);"Couldn't the resulting adfdir be greater than 720 if the original adfdir > 180 and heading > 180? In which case, more reliable code would be:while (adfdir > 359) adfdir = afdir - 360;or even:while (adfdir > 359) adfdir -= 360;

>"adfdir = (360 + adfdir + heading);">>Couldn't the resulting adfdir be greater than 720 if the>original adfdir > 180 and heading > 180? In which case, more>reliable code would be:If adfdir were ever a positive value, that would indeed occur. However adfdir is always <= 0

lookup_var(&mvadfndl);adfndl = mvadfndl.var_value.n;adfdir = (360 + adfndl + heading) ;if (adfdir > 359) { adfdir = adfdir - 360 ; }if (adfdir < 0) { adfdir = adfdir + 360; }

>"adfdir = (360 + adfdir + heading);">>Couldn't the resulting adfdir be greater than 720 if the>original adfdir > 180 and heading > 180? In which case, more>reliable code would be:>>while (adfdir > 359)> adfdir = afdir - 360;>>or even:>>while (adfdir > 359)> adfdir -= 360;>>Unlikely. The ADF_NEEDLE value is a relative heading, so it will never exceed 360 degrees in any manner possible. After all, there's only 360 degrees on a compass.Check my response after Bill's and hopefully that'll explain it better.