Hi,
I came across a very nice tutorial on the Arduino RF module Arduino RF link using 433MHz Transmitter / Receiver modules. Everything seems pretty clear, though I cannot understand one part of the code.
void writeUInt(unsigned int val)
{
byte checksum = (val/256) ^ (val&0xFF);
Serial.write(0xF0); // This gets reciever in sync with transmitter
Serial.write(g_network_sig, NETWORK_SIG_SIZE);
Serial.write((byte*)&val, VAL_SIZE);
Serial.write(checksum); //CHECKSUM_SIZE
}
What is unlcear to me is the checksum. If I understand it correctly, taking the val I want to send over the network and using the operation val/256, is just a bit shift operation >>8. Now, if the value is say 5 in decimal, by making a bitshift >>8, I would get 0 right?
On the contrary, the operation val&0xFF would alway give me the same thing, isn't that so? If the binary of 0xFF is 11111111, then using a bit shift AND seems just useless.
I probably just don't understand the code correctly, but I really don't see how doign a XOR of these two can give me a usable checksum for my value.
I am also not sure of how Serial.write((byte*)&val, VAL_SIZE) works.
Thanks for any help.
John
There are numerous checksum calculation routines. You'll have to ask the person who wrote it, why he chose this algorithm.
Serial.write((byte*)&val, VAL_SIZE);
This writes the number of bytes defined by VAL_SIZE. Presumably VAL_SIZE is defined to be 2, which is the size of an int on most Arduinos. This is why the checksum incorporates the high and low bytes of 'val'.
Pete
P.S.
or VAL_SIZE could simply be defined like this:
#define VAL_SIZE (sizeof(int))
Pete
jan019:
What is unlcear to me is the checksum. If I understand it correctly, taking the val I want to send over the network and using the operation val/256, is just a bit shift operation >>8. Now, if the value is say 5 in decimal, by making a bitshift >>8, I would get 0 right?
val/256 shifts the upper byte of the 2-byte int down. So if val was equal to 256, the result is 1. If you never store anything bigger than 255 in val, then this part of the checksum calculation will always be zero.
void writeUInt(unsigned int val)
{
byte checksum = (val/256) ^ (val&0xFF);
The writeUInt function always writes the two bytes of the 'val' argument. The high and low bytes of 'val' are combined into a checksum. If val is 5, the checksum will be 5. If, for example, val is 2049 the checksum will be 9:
(val/256) is 8
val&0xff is 1
so 8^1 is 9.
Pete
This particular "checksum" doesn't seem very useful, but it is better than nothing.
It is a common one in which all the bytes in a message are exclusively ORed together. In this case there are only two bytes in the message. As you say, "better than nothing" but that's all it has going for it 
Pete
Hi,
thank you for the replies! After your explanation I see what's going on. But seems like it's useless to me, sice I am going to be sending a max value of 255, so only one byte. I'll have a look at some checksum algortithms and hopefully come up with something more usefull ! Thanks for the info!
John
If the message payload is only one byte then the "checksum" can just be a second copy of the message. If both bytes match then the message passes the check.
This scheme will do poorly if the interference is consistent. Something that makes the receiver see all ones or all zeroes will make it incorrectly accept errors. One solution is to invert the second copy. Then an XOR of the two bytes (the ^ operator) will be all ones if the message is correct.
That scheme will be bad if the interference is intentional. But you probably don't need encryption or digital signatures.
I'll have a look at some checksum algortithms and hopefully come up with something more usefull !
What would be useful to you? Sending multiple copies of the same message, as mentioned above, works fine. Send the byte three times or more and compare at the receiver.
The checksum you describe only tells you that the message might be intact (it cannot detect many types of errors). If not intact, there is no chance of data recovery.
If you can send only one copy of a message, then Hamming codes (among other possibilities) allow limited "forward error correction", i.e. reconstructing a corrupted message from its components.