Temperature to unsigned

[JudgeMental]

Hi,

The attached LV2017 VI converts an U32 to Temperature in degrees C.

I am trying to reverse the process (degrees C to U32).

Can someone help?

[pincpanter]

Your "Value in" contain a high 14th bit which is spurious (real value is 13 bit wide, as you state). If we mask this bit (or equivalently subtract 8192 from Value in), we still get the correct temperature, moreover it is possible to reverse the formula dividing by 128 first and then right-shifting 3 times (equivalent to binary division by 8), like in the attached example.

[JudgeMental]

Hi pincpanter,

Thanks for the quick reply.

The upper portion of the .vi block diagram (Value in to Temp out) works perfectly.

In the lower portion, your solution of converting (Temp in x 16) to I16 then rotating -3 doesn't give the correct answer. For example entering 16000 in Value in gives a correct value of -24 for Temp out. However, entering -24 into Temp in gives an incorrect 8144 for Value out.

Thanks again.

[pincpanter]

Sorry, the multiplication factor in the lower portion must be 128 (16*8) instead of 16.

However you did not mask the extra bit as I suggested. If you input 16000-8192 = 7808, calculations will be correct.

[JudgeMental]

Hello again pincpanter,

Please forgive my ignorance.

The upper calculation works perfectly as is ("Value in" to "Temp out"). No changes needed.

I am only trying to reverse the process in the lower calculation ("Temp in" to "Value out"). For instance, in the upper calculation, if "Value in" = 16000, "Temp out" will = -24. Good.

I would like the lower calculation to reverse this process, so if "Temp in" = -24, "Value out" will be = 16000. Can you please show me how to mask the extra bit?

Thank you for your time.

[Minions]

Your actual roll-over for your code occurs at a Value In of 4096 and repeats that every 8192.  That is why your 12288 number didn't seem quite correct as the initial rollover.  The reconstruction for Temp In should not give you a Value out of over 8192 as shown by pincpanter.

[pincpanter · Accepted solution]

To get the original value, add 8192 to the final value in the lower part.

[Bob_Schor]

One problem is that (as noted) there seem to be extra "stuck bits" in the original example.  Your code notes that this acts as a 13-bit 2's complement binary.  13 bits means that the "real" values that matter to us are in the range of 0 .. 8191, so a value of 12288 (representing -256) is outside this range, having bit 13 (8192) "stuck" on -- the "real" (unsigned) number is 4096, or 2^12.  To get its signed value, we need to "extend the sign bit" (bit 12) -- the easiest way to do this is to test if the number is >= 4096 (i.e. has the sign bit set) and "extend" it by subtracting 2^13 (8192).

The "forward" algorithm thus is this:

Inverting this is straight-forward, except for handling the apparently "stuck" bit 13, which we can do at the very end:

The "false" cases above are just straight-through wires.

Wow, it's been a long time since I dealt with "offset-binary" and two's complement numbers.

Bob Schor