Hex Command to ASCII
danlee20
Posts: 31
IM trying to send an NEC projector a HEX string for lamp hours. How wold I convert that into am ascii string? Any help is greatly appreciated.
0
Comments
Just do something like...
SEND_STRING dv_myDevice , " $05,$AF,$32"
Or whatever the string.
A string coming back is going to be a series of hex/decimal values that might mean something in ASCII or not. If its raw hex/decimal/integer data you need then no conversion is necessary.
But if it is a human-type string ( example: "PWR ON" ) then you'd handle the data as a charactor, not an integer.
Im trying to convert a hex number for lamp hours on an nec. Could I use HEXTOI? I see that you can use HEXTOI. I'm not near my computer otherwise I would try this before asking. I greatly appreciate the help
It gets complicated as there is no easy way to do this. If your hex number was in ascii format like 'BEEFBABE' then hextoi would work since it takes a character array and gives you an integer. But it sounds like you have a hex number and need a integer so you actually have to change bases. So you end up having to add each hex number up to get the decimal equivalent.
IE:
1E5DF
F = 15 in decimal so (15*16^0) = 15
D = 13 in decimal so (13*16^1) = 208
5 = 5 in decimal so (5*16^2) = 1280
E = 14 in decimal so (14*16^3) = 57344
1 = 1 in decimal so (1*16^4) = 65536
Adding all of the numbers together to get the decimal number for HEX number 1E5DF:
15 + 208 + 1280 + 57344 + 65536 = 124383
So HEX 1E5DF = Decimal 124383
Paul
Therefore, the following declarations/initializations are identical in effect:
integer dummy1 = $1E5D
integer dummy2 = 7773
You can see this for yourself if you run debug and examine values and note that you can select how the integers are displayed to you.
In other words, there is no need to do any conversion at all to change an integer value from hex to decimal or back -- they are already the exact same thing.
If you have something that came back from an NEC projector that is an ascii hex representation of an integer, then in all probability hextoi() will do what you need done.
"$23,$8C,$01,$10,$10" followed by four data bytes which contain the lamp hour information. Actually, lamp time in seconds.
So, in order to get your lamp hour string, you would need to capture those four bytes which contain the information you want. There are many ways to do this. (eg: mid_string(sString,6,4))
Then what you have is a 4 byte string of integers that you have to decode. Probably they are in reverse order with the least significant byte first. Here is one way to do this assuming that you have captured the lamp hours to a 4 byte string with least significant byte first:
That is, convert the integer bytes that are returned from the NEC to their ascii hex equivalents while reversing the byte order. Then, use hextoi to convert to one long_integer. In the case of the pa600x (and some other NEC projectors) lamp time is in seconds. You need to use long (32 bit) integers and if you want hours, divide by 3600. Then, use itoa to get hours as ascii decimal to send to your touch panel.
I don't think you get an ascii hex representation from NEC projectors for lamp hours but I could be mistaken about that. I think what comes back if you use 281 as an example, is a hex number of $01$19. The hex number $01$19 is 281 in decimal but using your code you would get 401.
Paul
What you are going to get back from the NEC is a string of 8-bit bytes. In your example, you have a 2 byte string:
sLampHourString = "$01,$19"
Probably the easiest way to convert that string into the integer it is supposed to represent is to use the bitwise LSHIFT operator:
nLampHours = sLampHourString[1]<<8 + sLampHourString[2] //281 in decimal
if the string were (as in your previous example) three bytes:
sLampHourString = "$01,$e5,$df"
then
nLampHours = sLampHourString[1]<<16 + sLampHourString[2]<<8 + sLampHourString[3] //124383 in decimal format
edited to add:
My previous suggestion about using itohex and hextoi is pretty boneheaded, though it does work.
This has been covered before, probably more than once. Here is an example with respect to one of those insufferable Barco projectors which seem to code lamp time in a similar format to what NEC does:
http://www.amxforums.com/showthread.php?8232-Barco-Hex-Conversion
Just have to make sure whether the bytes are most significant or least significant first.
Yes a string is all you can get in a data event, but I prefer to not think of the bytes as strings but instead simply a bitstream that can represent characters, numbers, images, etc. I think the confusion occurs when people think that because its a string, its a bunch of characters, which it really isn't in this case, since its an integer in base 16. 0x119 is not equivalent to "$01,$19" even though they both look like hex, which I think is where people get confused and that was the point I was trying to make with my summing algorithm. You can implement the summing algorithm by bitshifting left as you mentioned, although it wouldn't surprise me if the compiler optimizes any multiplication by a power of 2 behind the scenes anyway so either bitshifting or multiplying by powers of 2 (0x10, 0x100, 0x1000) would result in the same machine code. You have to worry about truncation too so it can get ugly.
Paul