serial checksum not matching

[BarkBark]

I'm setting up a VI to communicate with an air data device. It communicates via RS-232 with a string output that contains all the relevant data followed by a checksum, carriage return, and line feed. An example of the output string is below. 

094904104, 111115, 0000.00, +00.00, +00.00, +00106, 100051, 0100051, 33<CR><LF>

The documentation for the device only has the following to say about the checksum calculation. "The checksum calculation shall include all characters and spaces except the carriage return/line feed characters and the checksum itself." The way I decided to calculate the checksum was to convert the output string to a byte array and islolate the first 69 bytes which is every character up to the checksum (Including the space preceding it) and then add the array elements.  This does not get me a checksum that matches the reported one. I'm not sure if I'm making a mistake in how I'm converting the string or if the checksum calculation is more complicated. This is my first real attempt at serial communication so I'm hoping I'm just making some stupid mistake.  I'm guessing there's some nuance to how one calculates a checksum that I must be missing. 

I've attached a simple vi that just takes the message string and performs my checksum calculation on it. 

[deceased]

You really need to know what the checksum calculation is, it might be a 1 byte XOR type LRC or something entirely different.

Deceased

[Sam_Sharp]

You definitely need some more information about the type of checksum being used. There will probably be another chapter in the documentation that details the checksum - it could be something like the XOR of the message bytes or it could be a CRC-16 type checksum (or any other type of checksum...there are many to choose from!).

How long is the checksum? In your example, you seem to include everything - including the '33' which I would have expected to be the checksum? You also need to be careful about how the data is sent/received - it seems to be ASCII strings? If the checksum is a single byte, is it sent as a decimal number, or is it also converted to an ASCII string of 1-3 characters e.g. '100'.

[BarkBark]

Thanks for the replys.  Unfortunately I've pored over the interface documentation for the device and the only mention of the checksum calculation was what I included in my original message. I've reached out to the manufacturer for more information but I haven't heard back from them. The checksum appears to be a single byte long and is expressed as a hex with two ASCII characters. I'm basing this on the fact that the documentation specifies that the data string is 74 Bytes and if you count up every ASCII character it comes out to 73 characters. The 33 is indeed the checksum for that message. 

[crossrulz]

---

@BarkBark wrote:

The checksum appears to be a single byte long and is expressed as a hex with two ASCII characters.

---

Or it could be a 16-bit checksum whose value just happens to be 0x3333, which will show up as "33" in ASCII.

But we are all drawing the same conclusion: you need more information from the manufacturer.

[BarkBark]

Thats a good point crossrulz, had not thought of that.  I guess I'll just keep trying to get the information from the manufacturer. 

thanks for the help!

[BarkBark]

So after looking at Sam_Sharp's comment I tried calculating the checksum using the alternatives he'd mentioned.  Turns out the checksum was infact one byte and that they are calculating it by XORing the bytes.  Things check out now.

thanks for the help! 

[deceased · Accepted solution]

Its is a 1 byte XOR checksum as I suspected. The 33 is the checksum in HEX (51 decimal).

The beauty of this method is a simple device like a microcontroller can:

1) receieve the entire string, including the XOR checksum. 

2) XOR all the bytes together, including the checksum.

3) Check that this caculation = 0

If it is equal to zero the packet is good since anything xored with itself = 0.

On a side note, LRC schemes like this can have multiple bits incorrect and still generate the correct checksum, so CRCs are usually better, but anyway, LRC is better than nothing.

Deceased.