Serial String Checksum?

I am reading a serial string into a Red Lion DSP.

The string has a 2 character check sum at the end of the string to confirm that the string is not corrupt.
I need to understand how they go about getting the value so I can error check the string.
I also want send commands to the device but I need to send the proper check sum based on the command I send.

I contacted the manufacturer of the device (Sullair Compressors) and they do not remember how they calculated the check sum?

I've googled quite a few possible solutions but I am just as confused now as when I started. I know this will not be easy but I am willing to learn...


Below are real world captures from the device. (Sullair Compressor)

According to the manual, the last two numbers are the checksum based on all the previous numbers listed here. So in the first string, 50 is the check sum.

Does anyone know how to calculate this?
Let me know what else I could provide to help you help me.


03M50
01N0,110,3781,B,A89
03N461,111,3775,t,AE6
03M50
01N0,110,3781,B,A89
03N456,111,3775,t,AE2

Thanks
Curtis

do not remember how they calculated the check sum

Click to expand...

You're kidding, right? And this is a company still in business?

Yeah, these are fairly new machines as well.

Do you have a link to this manual?

There are only about 42 bazillion different methods, so you could try some of the more common ones to see what happens:

http://en.wikipedia.org/wiki/Checksum

If you figure it out, maybe you can hold it for ransom from the Sullair people.

Also, I found this which may be useful for testing:
http://www.fileguru.com/File-Checksum-Tool/info

"They don't remember" ?

My first guess is that the numerals are treated as values, while the letters are treated as the ASCII equivalent. The checksum is then expressed as a hexadecimal value in ASCII.

Uppercase "M" in ASCII is a value of 77 (decimal), for example. So

"03M" is 0 + 3 + 77 = 80 (decimal) = 50 (hex)

But that only works for the first example.

Are these from a User Manual you could share, or do they come from a protocol analyzer ?

Another online tool I use for cyclic redundancy check calculations:

http://www.lammertbies.nl/comm/info/crc-calculation.html

The examples given are from a protocol analyzer(red lion data station plus.) These are real world captures.

I have a manual that I would rather not post for copyright reasons, but it basically says that the last two in the string is:
xx - two character checksum, based on all characters after STX
With no further information given about the checksum.

Ken Roach said:

"03M" is 0 + 3 + 77 = 80 (decimal) = 50 (hex)

Click to expand...

Yeah, I was real excited when I tried that on the first string, but thoroughly disappointed when I tried the next...

STX is the "Start of Transmission" or "Start of Text" character, which is always 02 (hex). It's not printable as ASCII.

I don't see any spaces or squares where the STX character might be, nor any ASCII "02". Does the Data Station Plus have a driver for Sullair, or is there some kind of "serial monitor" feature it has ?

Examine two similar command lines:

03N461,111,3775,t,AE6
03N456,111,3775,t,AE2

The difference between the values in the first segment is 5, and the difference between E6 and E2 is only 4. This suggests that the Checksum is not strictly additive.

I omitted the STX for clairity:

HyperTerminal

03M50
01N413,111,4193,t,AF0
03N211,111,4196,t,AEF

Looking for trends?
==========================
01N298,112,4193,t,AE4
01N288,112,4193,t,AE5
==========================
03N221,111,4196,t,AEE
03N211,111,4196,t,AEF
==========================
03N206,112,4196,t,AEA
03N211,111,4196,t,AEF
==========================
01N288,112,4193,t,AE5
01N312,110,4193,t,AF3

I think I figured it out. It's a type of Longitudinal Redundancy Check, also called a Block Character Check.

As described in the Wikipedia article (hangs head in shame for resorting to it)

1. Convert each character from ASCII to decimal.
2. Sum all the byte values.
3. XOR the result with 0xFF (hex) to cut off any bits over 8.
4. Add 1.
5. AND the result with 0xFF (hex) in case the result was over 8 bits,
6. Convert the result to ASCII.

The first string in the most recent example sums up to 1052 (decimal) = 0x041C (hex) = 10000011100 (binary).

10000011100

00011111111  XOR

-----------------

   11100011

          1  ADD

-----------------

   11100100

   11111111  AND

-----------------

   11100100 (binary)

That's 0xE4 (hex), so that's the checksum.

I ran a couple of these in a spreadsheet and they all work out correctly.

Ken would you be interested in sharing those spreadsheets?

Bernie Sullair doesn't even tell their field support guys this info. I did a job for them about 5 years ago and after working with their communication engineer I gave up on any further jobs with them.

All I did was use the spreadsheet to convert ASCII to decimal using the CODE(cell) function, then SUM the column. I couldn't figure out how to do bitwise XOR or AND so I did those by hand.

Every compressor maker seems compelled to build a custom serial protocol, it seems !

Step 3 above should be "because XOR 0xFF is how LRC calculations do their thing".

Those damn Xor and And are what I was having trouble with. I hate having to hand calculate anything When we have PC infront of us.

Interesting. I was thinking at first glance the end calculation after the addition was

(100h - (added result && FFh)) && FFh

The boundary instances (0, 1, FFh) work fine with this also.