checksum calculation

[freddayz33]

I am trying to calculate a checksum using the following methodology...

"Each message shall contain an 8-bit checksum. The checksum shall be computed on the entire message including command, data length, dat and checksum itself."

How the heck can this be calculated?

Example:

05FA, where 05 is command and FA is check sum

06F9, where 06 is command and F9 is checksum

THX

[RavensFan]

Try 255 (FF) minus the command.

For more bytes, it would be the sum of all the bytes.  But I don't think you can legitimately calculate the checksum that includes the checksum.

[chilly_charly]

The basic idea is to "sum" the header and data bytes to calculate and chain an additionnal byte -the checksum byte- such as as the "sum" of all bytes, including the  checksum byte, gives zero. Obviously, the cheksum byte cannot be calculated including itself !

The sentence should be rephrased as "Each message shall contain an 8-bit checksum. The checksum shall be computed on the entire message including command, data length, dat and checksum byte itself."

Summation can be replaced by other functions. See here

[Ray.R]

I've never heard of a checksum that includes itself.

CC, maybe I misunderstood your post. I'm just trying to figure out how the checksum could be included in the checksum.... 

Maybe it's too early for me..  So let's see..

Example...  if everything excluding the checksum (already the brain goes tilt) gives 0x4C so the checksum +checksum (what???) gives 0x98.  Would that be the checksum that should be sent? But what happened to the 0x4C?  What useful information would you get from adding the checksum to the checksum? 

I need some cafeine...  😉

[GregFreeman]

---

@freddayz33 wrote:

"Each message shall contain an 8-bit checksum. The checksum shall be computed on the entire message including command, data length, dat and checksum itself."

---

that sounds fairly impossible. If you change the checksum based on the checksum, wouldn't that then change the checksum? Sounds like an infinite loop to me!

[Darin.K]

I am even less caffeinated here on the West Coast, but let me give a stab at rephrasing.

The sanity check you are performing on the data is summation of the bytes modulo 256 (think U8).  That last byte is thrown in there to make that sum 255 (or zero or whatever you choose).  When doing the check you perform the summation on all data including the checksum byte and see if you get the intended result.

No recursion necessary here.

[Ray.R]

Darin,

Which is what CC explained, right? 

Don't you need at least one reincursion?  Maybe I'm still missing something..

Can you write up an example?  not in LabVIEW, just HEX.  

example(all hex)

01 02 03 04 05 F6 A3

checksum = A8 (no complements)

then if you add the checksum to the checksum, it's twice the checksum.

which gives 0x50

So if the checksum 0x50?  or 0xB0?

Or do I need to go back to school?  😉  << probably >>

[RavensFan]

I think CC actually explained it correctly in his first sentence, but the rephrasing of the sentence in his second sentence was not correct.

It makes no sense to add a checksum to a checksum.  Please someone show me a real world example if they find one that is otherwise.

Here is my understanding of what needs to be done based on the simple one byte examples the OP posted and not on anyone's written description.  From what I see, the key value is FF not 00.

[Darin.K]

CC used zero, I think this case the desired sum is 255, but fundamentally all I did was what I call "English to English translation".  Sometimes a single word or phrase causes the confusion so I hoped to help, but I guess not.

Example (all Hex):

Data Stream: 0A EF 3C

Sum Modulo 100 is 35

If I add the byte FF-35=CA as the "checksum" then I get: 0A EF 3C CA and I know the sum is the desired value of FF by construction.

When I receive those four bytes, I check the sum to make sure no errors occured, then chuck the final byte to get the real data.

In checksums involving bit parity of hashes there would be a non-convergent cycle, in this case not.  Here the terminology is probably an issue.  Normally we think of performing an operation and getting the checksum and then comparing it.  In this case, one could argue that the checksum is inferred to be FF (or zero, or whatever).  The operation we perform is the summation modulo 0x100 and the checksum is FF.  Instead of calling the last byte the checksum, we should think of it as the analog to the parity bit.  A good term escapes me now.

[Ray.R]

Ah..  okay...  that's a totally different description because the "checksum" is not actually part of the final euh.. (let's call it) paraty bit.

So in my example, the parity bit would have been 0x57.

Okay.  That makes sense.  THe way I was reading it, you would tack the sum to the rest and then calculate the checksum, which made no sense..