Handling serial parity errors

Sorry if this isn’t the correct subforum.

Arduino 1.0.2 gives me the option to use parity error detection on serial connections. Does anyone know if I need to manually handle parity errors, or does the Arduino automatically request retransmission?


Would really depend on your sketch, wouldn't it? I am betting manually, not all sending devices would be capable of resending. The protocol you are using would define what happens when parity error is detected. The data may have error correction built in for example, allowing the receiver to correct the error.

Thanks for the quick reply!

I don't suppose you know if there's a function I can call to determine if a parity error has been detected? I'm using SERIAL_8E1 (8 data bits, even parity, 1 stop bit) if that makes any difference.

I've not used anything except Serial.begin() library, no experience with parity detecting code. What's your environment that you expect parity errors to occur?

Sorry for the confusion. As of Arduino 1.0.2, Serial.begin() takes an extra (optional) parameter that defines the configuration of the serial connection.

Since it's so new, the only information I could find on it was some discussion on Google Code, and the Serial/Begin page.

I also tried snooping around the HardwareSerial code, but it's mostly over my head.

I'm not expecting parity errors, but if they happen I'd like to be able to handle them gracefully.

You're right, not much documented as to what happens when there is an incoming error. Have to get one of the real programmers involved.

What's the best way to get in contact with them?

Try a PM to someone like Coding Badly

I think what you will find is that you will have to study the datasheet for the AVR chip and learn how the various options for parity checking are enabled and how actual received parity errors are detected and signaled. Once you do understand how the underlining hardware functions, then you have to see how you will go about either modifying the existing hardware serial library to integrate this new 'feature' or write your own custom serial library. The fact that the existing hardware serial library utilizes buffered interrupt driven on received characters makes this not so simple a feature to implement.

First you have to ask yourself what you want to happen if and when a character is received that has bad parity detected? Your choices are fairly limited, either just throw the character away or via a protocol you work out with the sender of the characters, send them a signal that you received a bad character and to resend the character or the complete message. So you see it can get quite complex quite quickly and it is very much just a part of the overall serial protocol you wish to utilize between the sender and receiver of serial data.

Good luck;


The '328p datasheet (here: http://www.atmel.com/Images/doc8161.pdf), section 19, page 176, is the place to start in understanding parity support in the hardware.

It looks like it both generates the parity bit on output and checks it on input. See 19.7.4 for Receiver Error flags.

One issue with the Arduino buffered serial input (since you're not managing it yourself) will be knowing which character was in error when the error flag lights up.

Good luck with your project.


I do not know about parity errors. When I have tried to transfer data from Arduino to WindowsXP computer with as high speed as possible, it is quite seldom that the received character is wrong. Rather, there are more omissions of one or more characters the higher speed I try (up to about 1 megabaud).

Those omission errors should be detected also. A lot of work!

Thanks for all your help guys!

I've decided to chicken out and implement a checksum-based error detection protocol instead of trying to do it with serial parity checking. I suspect that the new Serial.begin() function was implemented so that the Arduino could easily be connected to devices with fixed data & parity settings, (instead of people having to roll their own HardwareSerial library to support a particular device).

I know that is an old post, but I have similar doubt, seach and find some usefull information about it at https://bit.ly/35HY6vs .

"Status and Fault Bits:

Now that we have our communication up and running we need to be able to monitor its status and any faults. This is done by Register A (UCSRA or UCSRnA)

The RXC(RXCn) bit (Receive Complete) will be set to HIGH(1) when data has been received and is available in the UDR (UDR0) buffer.

The TXC(TXCn) bit (Transmission Complete) is set to HIGH(1) when a transmission is completed and there is no other data to send.

The UDRE(UDREn) is set to HIGH(1) when the buffer (UDR/UDRn) is empty, and therefore ready to be written.

The FE(FE0) bit (Frame Error) is set HIGH(1) if the next bit in the receive buffer has a Frame Error. If the recieve buffer is read the FE(FE0) bit is cleared.

The DOR(DORn) bit (Data OverRun) is set HIGH(1) if the receive buffer is full (2 characters). The bit is cleared LOW(0) if the UDR(UDRn) is read.

The UPE(UPEn) bit (Parity Error) is set HIGH(1) if the next character in the receive buffer has a parity error. The bit is cleared LOW(0) if the UDR(UDRn) is read."

It seems that UPEn bit is a error parity flag. Someone could explain how to manipulate this flag? It seems as soon as the data arrives at the RX buffer, the flag is set (if there is an error) and remain until RX buffer is read. Seems we got it, using "Receive Complete" interrupt and read UPE flag each data received. May be?

(See also: https://sites.google.com/site/qeewiki/books/3d-printing-guide/how-to-fix-first-layer-problems )

Hi junior700,

maybe I can talk you out of it.

Nobody uses parity checking. It sucks. It's a relic from the 1970's. There are much better ways to accomplish error checking.

Parity lets errors slip 50% of the time, and if there are an even number of errored bits, it's wrong 100% of the time. Also if you make your code use hardware parity checking, it's married to the hardware you wrote it for, no longer portable to anything else.

Parity stopped getting used in the 1980's in favor of CRC's. Cyclic Redundancy Check. It's sort of like a checksum, but is rigged to catch a higher percentage errors at a cost of fewer bits.

It's simple, you pass your bytes into a function, and you get a 16 or 32 bit return value (your choice). The sender sends the CRC as part of the message and the receiver verifies that the message received matches the CRC received.

Use 32 bit CRC if your time and space isn't scarce. Also, you could just do a simple checksum.

Even though the last poster called it "chickening out", it's more than good enough for plenty.

Unless there's significant distance or a low quality connection (like analog modem landline), "bit errors" in the middle of packets sent at only a few thousand bits per second are just exceedingly rare.

Hi reswobslc

Thanks for the advice. It was very informative for me. Thank you. And I hope you're making it through the invite19 unscathed, It´s very hard but he dont catch me.


I am also a relic from the 1970's and back then a parity error meant you sent a "NAK" to the sender so they would re-transmit that message. If the new copy also had a parity error, you counted the errors and when, perhaps, 3 re-transmissions all had parity errors, you stopped the whole communication process as being unrecoverable.

Unless you are prepared to program the entire protocol using ACK and NAK to acknowledge each message, it's best to go on to something more productive.