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?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Commented:
can you use currency data type?

ie

Dim s As Currency

s = &H81 * 2 ^ 24 + &HFF * 2 ^ 16 + &HFF * 2 ^ 8 + &HFF
0

Experts Exchange Solution brought to you by

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Commented:
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
0
Commented:
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
0
IT ManagerCommented:
Is your book example in your second paragraph the same as this one?

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?
0
Commented:
let do this; what mileage is 92 40 195 01 equal to in integer terms? 29567068? 1546175233?
0
IT Business Architect - Supply ChainAuthor Commented:
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.
0
Commented:
no problem..  Good luck!
0
Commented:
quick question though:  so 92 40 195 01 = 29567068 right?
0
IT Business Architect - Supply ChainAuthor Commented:
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?
0
IT Business Architect - Supply ChainAuthor Commented:
I tried that function...I must not have the "ws2_32.dll" file?
0
Commented:
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
0
Commented:
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...
0
Commented:
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
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic.NET

From novice to tech pro — start learning today.