hex to binary (Vantage)

The easy way is use your PC's calculator > view > scientific.

Hextoi

We covered this just a couple of days ago in a different thread.

Look up HEXTOI in the help text. I think that's what you are looking for.

troberts wrote:

I am using a Vantage system to control my lighting. The AMX module does not seem to work for my application where Keypad IDs start at 65. So I am creating my own code for control. Vantage reports back keypad led information as a hex number. Does anyone know how to convert a hex number into binary. With binary I will be able to give client feedback for lighting...with hex I'm not sure how. Thanks for any help.

I'm guessing that you're getting ascii characters that are a hex representation of an integer.
If that's so, then the first thing you need to do is to get an integer and you can do this with the HEXTOI function. So, if the device returns the hex string 'AA' (decimal 170), you would have:

sStringFromVantage = 'AA'
nIntegerValue = HEXTOI(sStringFromVantage)

now that you have the integer, I'm assuming you need to extract the bit information and format it in some way. Not too long ago, someone posted a Word document that went into the Netlinx bitwise operations (find it by searching the forums for "bitwise") and this document explains how to get the bit values from an integer.

Or, you can just divide the integer by 2 repeatedly and the remainders will be the bit values.

If your bits are numbered 1 to 8 from right to left, you could do:

nIntegerValueTemp = nIntegerValue 
for (i = 1; i < 9; i++)
{
   nBit[i] = nIntegerValueTemp % 2
   nIntegerValueTemp  = nIntegerValueTemp  / 2
}

now, the integer array nBit[] holds the bit values.

Then

sBitString = "ITOA(nBit[8]),ITOA(nBit[7]),ITOA(nBit[6]),ITOA(nBit[5]),ITOA(nBit[4]),ITOA(nBit[3]),ITOA(nBit[2]),ITOA(nBit[1])"

That will result in:

sBitString = '10101010'

and 170 = $AA = 10101010b

That would give you an ASCII representation of the binary - is that really what you wanted? If you are trying to compare bits to check status, it is almost certainly more efficient to use bitwise operators, and no conversion is necessary, you can use them directly on the numeric value whatever form it is in.

troberts wrote:

I am looking for the actual binary value, not the ASCII representation. So...would I be able to use any of Harold's example?

I guess I'm not exactly sure what you are trying to do. The integer value doesn't actually change when you display it in different formats -- what you see is just various ways to represent an integer value in an interface.

If you need the status of a particular bit, that is stored in the variable nBit in the code sample that I posted before. You can also extract whatever information about the binary using the bitwise operators though if all you want to do is extract a bit's status, I find it easier on my brain to just do it with the modulus operator.

If you want to use these for feedback, an example using the IO ports might look like:

for (i = 1; i < 9, i++)
{
[dvIO,i] = nBit
}
assuming that channel 1 represents the least significant bit.

Oh, you could use Harold's example,it's just not the most efficient way of doing it. You are converting a number to a string, then you need to compare your values to various parts of that string character by character, each comparison using yet another set of string functions. In the end, it probably doesn't use enough processor time to matter, but my opinion in this particular case is you should use bitwise comparisons. It's just cleaner coding practice, and if you ever do wind up wiriting a monster program, you might need those saved processor cycles.

cwpartridge wrote:

decimal, hex, octal, binary...to the machine it's all the same. Those number systems were created to describe a number for people, and that is all. Machines deal in binary. People undestand decimal. Hex was made because of the way number are stored (8 bit multiples of widths).

The processor sees $126EC == 75500== 0223354 == 10010011011101100

They're all numnerical representation of the same number (hex, decimal, octal, binary)

This is true, but it's the ASCII that throws people all the time. It gets very confusing, becase a numeral 1 is just 1, but the ASCII 1 has a numerical of 49 ... yet we use the same glyph, "1," to represent both, and the context does not always make it clear which one is needed.

DHawthorne wrote:

This is true, but it's the ASCII that throws people all the time. It gets very confusing, becase a numeral 1 is just 1, but the ASCII 1 has a numerical of 49 ... yet we use the same glyph, "1," to represent both, and the context does not always make it clear which one is needed.

Yes, and I've seen a few protocols that require you to send ACSII characters representing hex values, for instance the string 'FF' which is different than the hexidecimal FF (255).

e.g.
SEND_STRING dev,"'ka 1 A',$0D";
SEND_STRING dev,"'ka 1 ',$0A,$0D"; // NOT THE SAME