Speaking of oddities in FS's XML Math, I've run across a very, V E R Y strange problem that's been vexing me for several days......or more accurately more like two months!I have an "old school" COM radio that uses mechanical "drums" for the display. They all work perfectly except for the "tenths digit," and it only misbehaves whenever the base frequency is at or above 128.000, and even then only when the 100'ths and 1000'ths fractions are "00."IOW, if they are .025, .050, or .075 the 10'ths digit behaves itself. If they are .000 however, whenever .800 is selected, the 10'ths digit will roll back to .700, even though the actual frequency remains 128.800!!!!!!!!!!BTW, the above happens during an "update routine" that is necessary to allow for "remote tuning" either by keyboard entry, add-on Com radio (such as a GNS530/430, or -and most importantly - FSX's own "auto-tune" function when one uses the ATC window to change frequencies.I have tried two separate methods for "extracting" the 10'ths digit from the sim's (A:COM ACTIVE FREQUENCY,Mhz) variable, and both yield precisely identical results:Method #1

(A:COM1 ACTIVE FREQUENCY,Mhz) 10 * 99999.999 min 0 max 10 % flr (>L:T38_Com_10ths_TUNE,enum)

Method #2*

  <Macro Name="ExtDigit">    @1 sp0    @3 0 >    if{ l0 10 @3 pow * sp0 }    l0 int 10 @2 pow % 10 @2 1 - 0 max pow / int  </Macro>@ExtDigit((A:COM1 ACTIVE FREQUENCY,Mhz),3,3) (>L:T38_Com_10ths_TUNE,enum)

The @Macro method is the cleanest script wise, the 2nd and 3rd parameters specifying 3 decimals, 3rd from the last, which is of course the 10'ths digit.As the screenshot clearly shows, the "raw" COM1 frequency is 136.800, but the extracted 10'ths digit is being "calculated" as 7! (BTW, the popup tooltip also displays 136.800)* Note: http://www.fsdeveloper.com/wiki/index.php?title=XML:_Macros_-_Extracting_Digits

...but wait! It get's stranger still.I've now noticed that at >128.00, the .2, .3, .7, and .8 selections are "rolling back."At <128.00, it's the numbers .2, .4, .7, and .9 selections "rolling back!"A R R R G G H H H ! :(

Bill, Just took a look at it and found something that may work.. When (A:COM1 ACTIVE FREQUENCY, Mhz) is used it basically takes the raw value and multiplies it by 0.000001. If You use (A:COM1 ACTIVE FREQUENCY,number) for instance, 136.800 would equal 136800000, maybe try to find the "Hundred Thousands" instead. The following works, tested in FS9.. Also confirmed your problem in FS9, so this should do it. IIRC Binary math crunchers donot like to deal with numbers less than 1. While the code clearly deals with that, the raw value still will have portions of it less than 1 when "Mhz" is used. 128 and above using bytes become negative.Roman

<Macro Name="ExtDigit">    @1 sp0    @3 0 >    if{ l0 10 @3 pow * sp0 }    l0 int 10 @2 pow % 10 @2 1 - 0 max pow / int  </Macro><Update>@ExtDigit((A:COM1 ACTIVE FREQUENCY,Number),6,0) (>L:Test, number)</Update> <String>%TEST %((L:Test, number))%!d!%</String>

Thanks for the test results, Roman."Flying Officer Jevans" posted another solution at FS-Developer. Simply ask for KHz instead of MHz.

(A:COM1 ACTIVE FREQUENCY,Khz) 100 / 10 % int

My logical analysis of this is that by asking FS to do the conversion internally before sending the value, it's using "C math" instead of me trying to use the flakey and unreliable "XML math." At least that makes sense to me. :( My initial attempt was to multipy the MHz value returned by 1000, and thus shifting the decimal, but apparently that simply carried forward the "XML rounding problem" into the domain of supposedly whole numbers, in other words:128.799 simply became 128799.0... ...even though it was being displayed as 128800.0 :( CONFIRMED:

@ExtDigit((A:COM1 ACTIVE FREQUENCY,Khz),3,0) (>L:T38_Com_10ths_TUNE,enum)

This works 100% accurately! :(