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.
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.
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.
@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.
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.