Checksum, radio communication errors, and statistics

Erik Friesen

I have a command that I am using between xtream radio's. The payload is 192 bytes, and there is a 16 bit checksum calculated as the sum of the all bytes. We have had some radio interference problems (from too many repeaters, and other issues) and I have found that I have had one of these packets corrupted. This packet is only sent and received when the user desires it, so there are very few of these packets that have gone out.

What is the overall chance of interference lining up like that?

Do any others have some communication experience like that?

localroger

It doesn't take much to line the checksum up, just a 1 to 0 error and a 0 to 1 error in the same bit position in two different bytes. More complex schemes exist to make this less likely but if you have the communication overhead it might make more sense to just send the packet twice and to a bytewise comparison; it's extremely unlikely that any amount of noise would manage to corrupt two packets in exactly the same way.

Phil Pilgrim (PhiPi)

There are better methods for detecting (and correcting) errors than simple checksums. Google terms like "CRC" and "FEC" for examples. If the communication is strictly one-way (i.e. if the receiver can't say "oops, try again"), error-correcting codes will be your best bet.

-Phil

Erik Friesen

Yes, I know crc is best, but still, this is not a bit here or there, this has to be a complete talk over, then quit, and my checksum bytes lining up on byte 193 and 194. The competing system communicates using only from ascii-0 to ascii-F (0x30 to 0x46) plus a start delimiter of M

Mike Green

You're asking a very general question about interference.· To answer that, you have to know what kind of signalling environment you have.· For a start, you'd have to:

1) Record information over a period of hours or days about the signals in your area (around the receiver mostly).· This will give you some statistical information about the patterns of interference, whether it's uniform over time or clusters during certain periods in the day (or even seasonally).

2) Set up a beacon (automatic transmitter) that sends known variable data, possibly pseudo-random, regularly during a period of days.· The data (and its timing) expected should be known to the receiving end, either because it's known ahead of time or there's another (reliable) control link.· Record the received information including the time received, raw data received, and whether it was received correctly.

Alternatively, you can set up communications that assumes an unreliable link and includes CRC type error detection, possibly multi-bit error correction (since communications is one-way).· You could use transceivers like xBee that do their own error detection and retry.

Communications in a noisy environment is all about risk management ... How unreliable is the communications link?· How much are you willing to invest in reliable communications?· How long are you willing to wait for a "good" message.

For one-way messaging you need some kind of checking.· You could send the same message multiple times and compare them, only accept the message if you've received it 3 or 5 or 20 times the same.· You have to number the messages so you don't think you've missed one and think you've got an extra which you've interpreted as the first of a new set.· That can get confusing.· You can send one message with multi-bit error correction techniques depending on the characteristics of the noise or interference.· Some solid state disk drives and hard disk drives do this sort of thing so they don't have to go back and reread the data or mark the sector as totally bad.


Post Edited (Mike Green) : 6/21/2010 10:43:57 PM GMT

localroger

If you have the bandwidth, the simplest way to do this is to send the message twice but with only one delimiter:

{192 chars}{192 chars}CR

When you receive the CR (or whatever can safely delimit your message) all you have to check is:

1. Did I get the right number of characters total (192 * 2) ?
2. Is the second half of the message the same as the first? This is a lot easier to do than CRC on most microcontrollers.

It is very, very unlikely that a message totally stomped by interference will give a false pass of this simple test. You don't have to worry about numbering your messages, extras, etc. because only every other message has the delimiter.

If comms are two-way you can have an ack which is sent the same way, but only on a successful receive. If the original sender doesn't get the ack in a fairly short time it can retransmit. It doesn't matter whether the original message or the ack got stomped, you're guaranteeing receipt. When you send and get an ack you're golden.

Then you send it often enough to stomp the other guy's transmissions so they pick another channel

Erik Friesen

I should clarify - This is two way communication with retries. The xtream have built in crc, but only within a given packet. We are not running api mode in this system, so the packets are not controlled by the software.

My system has two modes it operates in, the one uses xtend's api mode, in which you have comlete control over the packet. The other mode is for transparent rs232 (any radio style), thus the 16 bit checksum.

There is nothing like trying to debug something 500 miles away, either. I live in Indiana, and have to debug by hearsay, what happens in Alabama. The farm they are working on has a real jumbled up mess of a radio system, with some pacific crest radio's repeating through more radios.

The other confession I should make, is that I am not completely certain it is interference. When software gets complex enough, there are little gotchas, unless you are a perfect programmer.

An overview - aercon.net/

Erik Friesen

Here is part of the micro coding of the packet

        localtx[noparse][[/noparse]0]=0x7E;//start delimiter
    localtx=QT>>8;//high byte length
    localtx=QT&0xFF;//low byte length
    localtx=PICsettings.MY_ID>>8;//DT high byte
    localtx=PICsettings.MY_ID&0xFF;//DT low byte
    localtx=DT>>8;//DT high byte
    localtx[noparse][[/noparse]6]=DT&0xFF;//DT low byte
    localtx[noparse][[/noparse]7]=0x7F;//start delimiter
    checksum=checksum+localtx[noparse][[/noparse]7]+localtx[noparse][[/noparse]6]+localtx+localtx+localtx;
    for (a=0;a<qt;a++)
        {
        localtx[noparse][[/noparse]a+8]=TP[noparse][[/noparse]a];//copy buffer
        checksum+=(unsigned char)TP[noparse][[/noparse]a];//figure checksum
        } //   
//    checksum=checksum+localtx[noparse][[/noparse]7]+localtx[noparse][[/noparse]6]+localtx+localtx+localtx;
    checksum=0xFFFFL-checksum;
    localtx[noparse][[/noparse]QT+3]=(checksum>>8)&0xFF;
    localtx[noparse][[/noparse]QT+4]=checksum&0xFF;
    txcnt=QT+5;

localtx is sent out the serial port
PICsettings.MY_ID - is the id of the machine sending the message
DT - is who it is addressed to.

If you can figure out the C code bashing by this forum software.

Post Edited (Erik Friesen) : 6/21/2010 11:14:31 PM GMT

Erik Friesen

I have been doing some work with crc here. There seems to be some discrepancy between lfsr www.microchip.com/forums/tm.aspx?m=332944&high=dma+crc and software implementation

lfsr 16 bit ccitt with no zeros ascii "123456789" = 0xBEEF
lfsr 16 bit ccitt with no zeros ascii "123456" = 0xE2BF

16 bit ccitt with ? zeros ascii "123456789" = 0x31C3
16 bit ccitt with ? zeros ascii "123456" = 0x20E4

seeded with zero, poly 0x1021,

So far, I haven't come up with a way to replicate the numbers on top in software.