Go Down

Topic: serial errors and detection by Arduino (Read 1 time) previous topic - next topic

arctan

With a 16 MHz oscillator, all commonly used baud rates above 2400 have a non-zero error rate -- see the 16 MHz table at http://www.wormfood.net/avrbaudcalc.php .

For my own programs, how can I ensure that the Arudino (16 MHz) reliably receives the messages I send it over the serial port?  http://arduino.cc/en/Reference/Serial doesn't have any mention of parity bits, and it seems like the default is 8,n,1, i.e. no parity.  I could implement a checksum and acknowledge protocol between sender and Arudino, but I was wondering if there was a simpler way.


gardner

With asynchronous signaling the synchronization between sender and receiver is re-set on every start bit -- once per word and, depending on your other settings, once every 8 to 13 bit times.  An error of 1/2 bit time accumulating over 12 bit times -- something like 4% -- is tolerable.  This means that the sender can be 2% fast and the receiver 2% slow and it should still work okay.

graynomad

Quote
I was wondering if there was a simpler way.

No.

Quote
I could implement a checksum and acknowledge protocol between sender and Arudino

Yes. That's the sort of thing you need to do.

Serial comms is by nature not reliable (more or less depending on speeds and distances).

How important is the data? Does it matter if a reading is missed? What speed and distance is involved?

______
Rob


Rob Gray aka the GRAYnomad www.robgray.com

skyjumper

My app reads data at 19200 from a device that sends packets with checksums, so I can verify the data is recieved corrctly. I have run this app for many many consecutive hours. Unless there is a known issue in my code, I get error free reception for as many as 15 hours now. I have not tested beyond that time yet.

That said, you should build a protocol with error checking. A simple checksum is easy to implement. Just XOR the payload bytes together and add the result as the last byte. On the receiving end, once you have the data, do it again and compare the result to the result you received.


arctan

Thanks for the replies. 

@gardner: Ah, I see I misread the table.  I thought the "% of error" reported in the table were the error rates in bit transmission (I skimmed).  At first I did not understand your response, but looking again at the table, I realize that "% of error" is the percent mismatch in clock speed.

@Graynomad: Distances are short in all cases (tethered to a PC via FTDI serial-to-USB cable).  For the simple test app I am doing now, it is not critical.  But I had a previous project where the baud rate was set to 115200 for a data logging application (at high sampling rate) and the Arduino's serial output was being corrupted once in a while.  I am planning a future app where the message reception would be critical (i.e. no missed messages allowed), so I will have to implement a protocol...

@skyjumper: thanks for the info and suggestion on a simple protocol.


graynomad

For simple stuff the checksum skyjumper suggests is good, if it's important a CRC is better and the polynomial used needs looking at because AFAIK some work better than others for various data lengths.

I'm designing a protocol at present that uses a "frame sequence number" so missing frames are detected, a data length field rather than a delimiter, and a code field. All these have to be right for a frame to be accepted so I think that's the sort of thing you have to do to get good reliability.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

Go Up