Unsigned Long Integer
I extracted this info. from an ECM and is an Odometer for the vehicle: 245 128 92 40 195 01 09 The '245 128' states that it's for the engine info pertaining to odometer, the 92 40 195 01 is the odometer value, and the 09 is the Two's complement checksum. I have most of it figured out except for the 92 40 195 01 (odometer number) My protocol book for the ECM states that it is an 'Unsigned Long Integer' and it is ordered by LSB to MSB (least significant byte to most significant byte)
I don't know how to calculate the Unsigned Long Integer from LSB to MSB.
Here's a example of 2 characters from my book: for this sequence - 128 158 29 1 196 where 29 1 is the data - Book reads: "Due to the specification there are two characters of data and they should be treated like an unsigned integer (16 bits where the bits are grouped into 8 bits and sent in reverse order). The interpretation of the data bytes 29 and 1 as an unsigned integer is (1 * 2^8) + (29 * 2^0) = 285. The result must then be scaled by the bit resolution..."
Any help?
I don't know how to calculate the Unsigned Long Integer from LSB to MSB.
Here's a example of 2 characters from my book: for this sequence - 128 158 29 1 196 where 29 1 is the data - Book reads: "Due to the specification there are two characters of data and they should be treated like an unsigned integer (16 bits where the bits are grouped into 8 bits and sent in reverse order). The interpretation of the data bytes 29 and 1 as an unsigned integer is (1 * 2^8) + (29 * 2^0) = 285. The result must then be scaled by the bit resolution..."
Any help?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
for ease, i would use the function defined in the following api call:
Public Declare Function ntohl Lib "ws2_32.dll" (ByVal netlong As Long) As Long
pass the value to the function and it will reverse the byte order.. If it turns out to be not-quite-right you could try the inverse function:
Public Declare Function htonl Lib "ws2_32.dll" (ByVal hostlong As Long) As Long
Public Declare Function ntohl Lib "ws2_32.dll" (ByVal netlong As Long) As Long
pass the value to the function and it will reverse the byte order.. If it turns out to be not-quite-right you could try the inverse function:
Public Declare Function htonl Lib "ws2_32.dll" (ByVal hostlong As Long) As Long
Is your book example in your second paragraph the same as this one?
http://db.s2.chalmers.se/download/masters/master_013_2003.pdf
If so, its talking about only 2 characters, and its probably confusing you more than helping you 'cos you have 4 characters:
92 40 195 01
Now, I'm guessing that we're talking about four bytes here, but I don't know what they're being represented in. Does your ECM protocol book confirm this?
The reason I ask is that if I assume that they're in decimal, then the ordering from least to most means that the result (ie the odometer reading) would be the sum of:
(92*2^0) + (40*2^1) + (195*2^2) + (1*2^3)
= 92 + 80 + 780 + 8
= 960
In binary, that's 1111000000
To find the 2's complement, invert the bits then add 1.
Unfortunately, the 2's complement of 960 is
00001000000 = 64, not 09!
So I need some more info - are you sure that "92 40 195 01 is the odometer value", and if it is, are those decimal representations of a 4 byte integer?
http://db.s2.chalmers.se/download/masters/master_013_2003.pdf
If so, its talking about only 2 characters, and its probably confusing you more than helping you 'cos you have 4 characters:
92 40 195 01
Now, I'm guessing that we're talking about four bytes here, but I don't know what they're being represented in. Does your ECM protocol book confirm this?
The reason I ask is that if I assume that they're in decimal, then the ordering from least to most means that the result (ie the odometer reading) would be the sum of:
(92*2^0) + (40*2^1) + (195*2^2) + (1*2^3)
= 92 + 80 + 780 + 8
= 960
In binary, that's 1111000000
To find the 2's complement, invert the bits then add 1.
Unfortunately, the 2's complement of 960 is
00001000000 = 64, not 09!
So I need some more info - are you sure that "92 40 195 01 is the odometer value", and if it is, are those decimal representations of a 4 byte integer?
let do this; what mileage is 92 40 195 01 equal to in integer terms? 29567068? 1546175233?
ASKER
Figured it out from some other data extracted from the ECM. Data: 128 84 0 91 0 245 4 49 81 10 0 76
In this sequence of data 49 81 10 0 is the odometer or 31 51 0A 00 in hex. Put this in reverse order(LSB)- 000A5131 and convert it back to decimal = 676145. The bit resolution is 0.1mi, so the odometer is 67614.5 miles. This matches exactly what the actual odometer reads.
With this Hex conversion, I don't have to know all about Unsigned Long Integers, but nevertheless I've learned what they are and how they work.
Thanks for the answers!
In this sequence of data 49 81 10 0 is the odometer or 31 51 0A 00 in hex. Put this in reverse order(LSB)- 000A5131 and convert it back to decimal = 676145. The bit resolution is 0.1mi, so the odometer is 67614.5 miles. This matches exactly what the actual odometer reads.
With this Hex conversion, I don't have to know all about Unsigned Long Integers, but nevertheless I've learned what they are and how they work.
Thanks for the answers!
no problem.. Good luck!
quick question though: so 92 40 195 01 = 29567068 right?
ASKER
Yes, I put 92 40 195 01 through the same equation and it does equal 29567068. Which one of your function's made that work?
ASKER
I tried that function...I must not have the "ws2_32.dll" file?
actually neither of the api calls would do it: I have another function i wrote that looks something like:
dim x as long, lPoint as long, sRes as long
x = 1
for lpoint = endingpos to startingpos step -1
next lpoint
dim x as long, lPoint as long, sRes as long
x = 1
for lpoint = endingpos to startingpos step -1
next lpoint
dim x as long, lPoint as long, lRes as long
x = 1
for lpoint = endingpos to startingpos step -1
lres = lres + (itematposition(lpoint) * x)
x=x*256
next lpoint
is how i have done it in the past where lRes is tha answer.. I just wanted to first verify which direction i was going...
x = 1
for lpoint = endingpos to startingpos step -1
lres = lres + (itematposition(lpoint) * x)
x=x*256
next lpoint
is how i have done it in the past where lRes is tha answer.. I just wanted to first verify which direction i was going...
actually now that i reread it it would be:
dim x as long, lPoint as long, lRes as long
x = 1
for lpoint = startingpos to endingpos
lres = lres + (itematposition(lpoint) * x)
x=x*256
next lpoint
dim x as long, lPoint as long, lRes as long
x = 1
for lpoint = startingpos to endingpos
lres = lres + (itematposition(lpoint) * x)
x=x*256
next lpoint
Public Declare Function ntohl Lib "ws2_32.dll" (ByVal netlong As Long) As Long
pass the value to the function and it will reverse the byte order.. If it turns out to be not-quite-right you could try the inverse function:
Public Declare Function htonl Lib "ws2_32.dll" (ByVal hostlong As Long) As Long