>
>
>So with a minor cost to ram, code, and transmission time, a virtually
>bulletproof checksum can be generated. Use a 4 byte checksum buffer cleared
>to all zeros. Keep a count of which checksum byte to xor next. As you read
>bytes xor to the current checksum byte then advance (of course wrapping around
>when you get to the 4th one). Then end the packet by sending the 4 checksum
>bytes in order starting with the current checksum byte.
>
>Upon receipt (and xoring) of the 4 checksum bytes, the checksum should be 0.
>
>It's still cheap and virtually foolproof.
>
>BAJ

Putting on my best humility suit in case I (too?) have missed the obvious
(Byron's

paranoia is catching. ;-)

..

But here goes...

Wouldn't any  packet of any length > 1 with either the LSb or MSb (for
example)
incorrectly set or reset on each byte have a 50% chance of failing to be
detected
by your "virtually foolproof" checksum?

-And-

How many combinations of  your 4 byte Xor result will Xor together and give
a Zero
result?

(I didn't get past Year 10 Math at school but my first guess would be
16777216.)

Your "virtually foolproof" system appears to me to be "virtually useless"
in the case of
serial comms as it has a good chance of missing a very common failure mode
(Framing
error, and the checksum itself is subject to this error when it is
transmitted.)

Even in the case of random errors it still has a 1/256 chance of being
wrong does it
not?

Also, getting back to the suggestion of both summing and Xoring. Are not these
the facts?

Both can miss the same error.
Both can detect an error that the other missed.
Therefore using both will detect more errors than either alone.

If a "virtually foolproof" checksum could be had by either Xoring or
Summing then why would anyone bother with far more robust CRC
algorithms?

Maybe I have missed something? I have been known to do that occasionally.

Regards,

Jim Robertson
NEWFOUND ELECTRONICS

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.