What kind of checksum is this?

[Bill Franke]

I am trying to decode a communication snippet between a piece of industrial equipment and it's software. I've been listening in using Sysinternal's "Portmon" and have the following communications:

In Hex:
5A 0F 05 03 71 23 3A 1F 02 01 00 00 00 00 01 F8 8B
5A 0F 05 03 02 01 00 04 00 01 01 1E 1E 05 01 01 04
5A 0F 05 03 02 01 00 04 01 02 08 01 A4 00 00 00 AF
5A 0F 05 03 02 01 00 04 02 00 00 00 C8 02 58 01 90
5A 0F 05 03 02 01 00 04 03 F4 00 00 C8 02 58 01 65
5A 0F 05 03 02 01 00 09 02 42 01 02 02 02 02 02 4F
5A 0F 05 03 02 01 00 04 01 02 08 01 24 00 00 00 2F
5A 0F 05 03 02 01 00 09 02 42 02 0A 0A 0A 0A 0A 44
5A 0F 05 03 71 23 2B 1F 02 63 00 00 00 00 01 F8 F8

I am fairly confident that the last hex byte is the checksum. If one of the data elements is incremented or decremented, this byte does so also. I am trying to figure out what kind of checksum this is, however. I can't seem to get any combination or partial combination of bytes to figure. I've tried 1's and 2's compliment, but no success.

Above are all write snippets. Here are some read snippets:
5A 0C 05 10 20 00 01 08 01 E4 01 F4 82 AE
5A 0C 05 10 20 00 01 08 01 E1 01 0E 82 51
5A 0C 05 10 20 00 01 08 01 C4 00 C8 82 B3

The idle state read ping is:
5A 04 06 10 00 16

Any help would be appreciated.

[Dominic Sexton]

Perhaps it is similar to the NMEA checksum that XORs the bytes. In that there is a $ at the start and a * at the end before the checksum which are not included in the checksum calculations.

Yours may be similar in that part of the data may be ignored or it may all be used.

There is some VB.NET code here that shows the NMEA process:

http://www.codepedia.com/1/Taking+Out+the+Garbage:+NMEA+Checksums

I hope that is of some help.

[Eric Pearson]

> If one of the data elements is incremented or decremented,
> this byte does so also.

If you mean that literally, then the checksum is probably a sum. Add the hex values of the bytes together, and roll over to zero after FF. Off the top of my head...

lCheckSum& = 0
For lCharacter& = 1 To LEN(TheString$)
    lCheckSum& = lCheckSum& + ASC(TheString$,lCharacter&)
Next
lCheckSum& = lCheckSum& MOD &h100

-- Eric

[Michael Mattias]

Sometimes the "checksum" is a "check digit."

eg with some bar codes the check digit is the 'MOD 9' of the sum of the preceding bytes. (That's character data, all numeric digits, which this is clearly not).

[Bill Franke]

In my initial tests, I thought the checksum followed the data polarity-wise, but further tests show it switches direction. In the following, you can see where I changed the address (reflected in the 10th hex byte.) I started with an address of 1 and worked up to 5. Notice how the checksum begins to decrement then jumps.

5A 0F 05 03 71 23 2B 1F 02 01 00 00 00 00 01 F8 9A
5A 0F 05 03 71 23 2B 1F 02 02 00 00 00 00 01 F8 99
5A 0F 05 03 71 23 2B 1F 02 03 00 00 00 00 01 F8 98
5A 0F 05 03 71 23 2B 1F 02 04 00 00 00 00 01 F8 9F
5A 0F 05 03 71 23 2B 1F 02 05 00 00 00 00 01 F8 9E

Here is a different device using address 1 to 5:

5A 0F 05 03 71 23 3A 1F 02 01 00 00 00 00 01 F8 8B
5A 0F 05 03 71 23 3A 1F 02 02 00 00 00 00 01 F8 88
5A 0F 05 03 71 23 3A 1F 02 03 00 00 00 00 01 F8 89
5A 0F 05 03 71 23 3A 1F 02 04 00 00 00 00 01 F8 8E
5A 0F 05 03 71 23 3A 1F 02 05 00 00 00 00 01 F8 8F

Here the checksum seems to mostly increment. Any other ideas?

[Steven Murray]

If you XOR all of the bytes together, then with 55h, you get the correct checksum. I think you will find that is the algorithm. Nice and simple really.

[Michael Mattias]

> ...If you XOR all of the bytes together, then with 55h...

Darned. I was going to try that next.

[Bill Franke]

If you XOR all of the bytes together, then with 55h, you get the correct checksum. I think you will find that is the algorithm. Nice and simple really.

Steven,

Man, how did you ever figure that out? Thanks alot. Maybe I can ask you another question since you seem to know what is going on?

There is a serial number associated with this hexadecimal code that has me perplexed. Unfortunately, at this time I only have four of them to work with:

5A 0D 05 10 71 23 3A 1F 00 02 71 23 3A 01 09 = 03081803-058
5A 0D 05 10 71 23 2B 1F 00 02 71 23 2B 01 09 = 03081803-043
5A 0D 05 10 98 83 02 1F 00 02 98 83 02 63 6B = 03081903-081
5A 0D 05 10 C7 72 D9 1F 00 02 C7 72 D9 30 38 = 06032302-217

Some of this is easy. Bytes 14 & 15 are the address and the checksum and bytes 7 and 13 pertains to the last three digits after the hyphen. Bytes 5 to 7 repeat at bytes 11 to 13. I assume the first four bytes are an opcode. Using the last string as an example, somehow, &HC7 &H72 translates into 06032302. Any ideas here?

[Steven Murray]

I make electronic gadgets that sit at the end of wires and connect back to hosts, so I have looked at a few protocols over the years. Nothing really jumps out at me about the serial number, but I would guess that:
5A = the packet header
0D = count of bytes in the rest of the packet
05 = "from remote node" rather than "from host"
10 = opcode
with the node address starting after that, but is it 3 bytes or 4 bytes long? Maybe someone else can match the node address to the serial number.