Quantcast
Channel: MCS Electronics Forum
Viewing all articles
Browse latest Browse all 20606

BASCOM-AVR : RS 232 Data validation On wireless transmision : REPLY

$
0
0
Hi snow, You seem to mix up CRC with an encryption. But it not like that at all. There is no way the recalculate the actual information from the checksum. A checksum is generated, and then appended to your message. Lets say your message is four bytes long: Startbyte, transmitter number, temperature, endbyte. (Just a simple example, yours might differ!) What you do is fill an array with the bytes: Msg(1)=startbyte Msg(2)=transmitter mumber and so on. The cecksum calculates cs=CRC8 (msg(1),4) (Check syntax in the help, i am writing from my iphone) Now send the four bytes of the message and append the checksum as the fifth byte. (Cs=msg(5), send msg(1) to msg(5). Depending on your 4 bytes, the cs will be a value from 0 to 255. On the receiver, do the same: calculate a cs over bytes 1 to 4. then you compare the receiver calculated cs with the received cs. Are the NOT equal? Then there shure an transmitting error occured. They ARE equal? Then you can be quite shure the transmission has been ok. Quite shure means, there is a little chance to get a "false true" result. That occures if more than one bit is transmitted false, and accidently the checksum calculates equal to an errorless checksum. The more bytes you calculate the checksum on, the less relaible the "ok" result is. To compensate that effect, split large messages into smaller parts an build cs over the parts. Or use CRC16, or CRC32. The number tells you how many bits the checksum is long. The more bits, the less chance to get false true results. Check the help to see what bascom supports, I do not know by heart. Hope I made it clearer rather than putting more confusion into it.

Viewing all articles
Browse latest Browse all 20606

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>