Checksum

[jodicalhon]

I want to add a checksum to my 433MHz transmissions, but am clueless as to the best way to go about it.

I know Dr_Acula posted some nice stuff in response to a request from (I think) BendanP a while ago, but I'm unable to find the post.

Does some kind soul know where I might find it, or have some ideas for a simple checksum approach.

Ta muchly.

 

[hippy]

A simple checksum approach would be to add all the bytes you've sent together while ignoring overflow and send the result as a checksum.

You can Exclusively OR the bytes together or 'add them in' using any number of other means. You can also invert, negate and otherwise manipulate the actual checksum value before you send it.

Simple checksums have the problem that one error may be easily cancelled out by another error so a packet with two errors looks like it is okay. More advanced checksums ( CRC - Cyclic Redundancy Check ) are designed so there is a much lower chance that multiple errors result in the packet appearing to be okay when it isn't.

The size of the checksum will also affect reliability. For a byte checksum there's a one in 256 chance that an error in the checksum results in a valid packet when it wasn't. Using a word, drops that to a one in 65536 chance.

Sometimes the simplest thing is to send the data twice and check they match, sometimes the data is sent as it should be, then sent inverted the second time.

Take a look at my following page which will lead you to some examples for creating CRC checksums and show how they can be used with wireless interfacing ...

http://www.hippy.freeserve.co.uk/picaxeqa.htm 9 <A href='http://www.hippy.freeserve.co.uk/picaxeqa.htm' Target=_Blank>External Web Link</a> )

 

[Jeremy Leach]

Well, the 'checksum' I've used is simply to add up all the byte values and store the result in a byte. Lots of overflow in the calculation, but the point of the checksum is to see if the data is corrupted, not to tell you the sum of the byte values. Crude but reasonably effective. I'm sure people will point out some flaws in this approach.

At the receiving end you add up the bytes and then compare to the transmitted checksum value.

 

[jodicalhon]

Thanks Hippy and Jeremy. That's very helpful.

 

[manuka]

(Ahem -gentle reminder Hippy that some info at your page info above is now rather dated! Ex.<i> &quot;When will the PICAXE-08M be available ? </i> &quot;

Acrylic: Welcome to the &quot;did they get the message correctly&quot; club,membership of which has tormented mankind since the beginning of time. I said &quot;bring home a sabre tooth tiger,NOT a mammoth&quot; !

Most Picaxe 433MHz datacomms is simplex (one way) so even rugged schemes will still only error detect rather that error correct. Aside from checksums,CRC, double sending,Manchester coding etc perhaps the most effective Picaxe reliability technique involves slowing down ones datacomms rate. Yeah- it's a pain at 300bps compared with say 54 Mbps WiFi, but reliability is often greatly enhanced over regular 2400bps. You can even underclock the Picaxes for datacomms rates that approach slow Morse code-the byte can almost be read by ear! Radio hams have tinkered to good effect with dead slow data rates (~1bps !)in ultra noisy conditions in fact. Tell us more hence about your link - Stan

 

[jodicalhon]

Thanks Stan, it's basically some info gathering at the moment.

I'm building a remote controller for a small robot I'm making for my kid. I just want to ensure that when he wants it to turn left it turns left, etc.

I'm just wanting to make it as bulletproof as I can, so any error checking ideas are gratefully accepted.