For UART, should I use parity on a board level?

Question

I am considering whether to use parity or not with my UART. It is a board level high speed (upwards of 115,200 baud) signal. The traces are very short (less than 2 cm), MCU to DSP, but they could pick up noise. During a logic analysing session using my logic sniffer I noticed one byte was captured incorrectly, it was just a single error. I couldn't replicate it. Now I'm wondering whether I should include parity.

My application is somewhat safety critical in that a failure would lead to a graphical error on a HUD/OSD which could provide incorrect information to someone piloting a model aircraft. However, the HUD is updated at 30 frames per second, so any glitch would be temporary. One problem that could happen is it could send a command which put the OSD into an incorrect state where it did not display anything, leaving the pilot blind about 25 km away from home... which is not good.

Will including parity protect me against common glitches or will it just make the protocol slower? Why is it that most UART protocols do not have parity? And is there a reason to select odd or even parity over each other?

Answer 1

In my experience, almost all the equipment and systems I've ever worked with skip parity, and just use message checksums or CRC's to detect errors.

Answer 2

If you have the capability of interrupting a message, a parity error can be used to kill a bad transmission faster than a CRC check, especially for large packet sizes. Otherwise, a CRC check will catch anything a parity check will, and more. If you are really concerned, you can use additional software detection methods, such as context checking and message mirroring. Timeouts can be used to prevent the OSD from falling into an incorrect state permanently.

Answer 3

Odd vs Even Parity

This will depend slightly on what communication you are using. I know you said you are using UART, but I am going to answer a bit broader. If you do decide to go with parity, select the option that will cause your "idle" state to require the parity bit to switch.

If you have an active high system, then all 0's is idle. So make it odd parity so that the parity bit will have to change state from idle.

In an active low system you should look at how many bits the parity will be over. If it is 8 bits, then even parity will result in a 0 parity bit, which follows the idea of forcing a change in state for the parity.

Should you use Parity?

Well this is a bit of a difficult questions. In general we like to model the noise as Gaussian noise which means that the bit errors will be completely random. In actuality noise that has an effect on our system is not always random. The reason for this is things that can cause errors on a PCB are radiators from something else. If you think about it, in order for a trace that short to have enough noise to cause bit error then it had to be something rather extreme. When you have a noise source like this, there is a decent chance that you will flip more then one bit. Parity is useless against an even number of bit errors. With out diving into the math, parity will help, but doesn't help tons. If you can't afford to do much processing then parity may be the best that you can do..

Why use a CRC?

First of all, you say you have a built in CRC generator, this means it should be very easy for you to compute. CRCs are much better at catching multiple bit errors. In an environment where you want a very low chance of getting any errors, you really want to use a CRC. In fact, go with the biggest CRC you can afford in your system. One little trick that I know works for atleast crc16 if not others is if you CRC the message you received with the CRC on it you should get 0 as your answer. If you have hardware to compute the CRC then this is a very efficient way of both generating CRC and checking CRC.

Answer 4

I would work on shielding this wire first of all.

Put ground planes around it (and/or) burry it into inner layers between ground planes. Then rely on CRC. Use parity if it's free.

Answer 5

If you use parity think about how you will manage the error in you code. If you do not have a graceful way of managing the error detecting it will not help much.

Answer 6

Parity is useless, in my opinion.

With short chip-to-chip connections on a single board like this, as long as you properly drive the lines, it should be practically noise-free -- at least compared to, say, your DRAM. Some people expect one soft bit error, per day, per gigabyte of DRAM. How do you know the error you saw wasn't caused by such a soft bit error, rather than noise on the communication wires? If you have induced noise big enough to flip a bit on a properly-driven PCB trace, you probably have other bigger problems to worry about. (By "properly driven", I mean either actively drive each line all the time, or use a pull-up resistor or pull-down resistor to set the state between messages).

With longer-range off-board connections, it's often unavoidable to occasionally have floating wires that present an input pin with more-or-less continuous random noise, and even when you are transmitting a message you often get bit errors. In this case, parity is better than nothing. As bt2 mentioned, you'll want to use CRC so you can catch many errors that parity completely misses, and once you have CRC, adding parity to it doesn't help significantly.

If it's possible to put your system in a "bad state", try to design things such that it returns to a good state in a reasonable amount of time. Use communication timeouts and watchdog timers as markrages and bt2 mentioned. Periodically re-transmit the initialization commands so that no matter what weird state the receiver is in, it gets reset to the correct state.

"Static in the satellite affected its computer which read the noise as a command to shut down. To overcome the problem, controllers sent a continuous stream of ON commands to the satellite to keep it turned on." -- Amateur Radio Satellites: OSCAR-6

Answer 7

You don't want parity. You want a more reliable communication.

The reason parity is little used is that it's expensive in terms of data throughput. It starts by making a frame almost 10% longer: start bit + 8 data bits + parity + stop bit = 11 bits instead of 10. But it's far worse than that. If you have a way to tell if you received the data correctly you have the duty to do something with that. Simply ignoring the erroneous communication won't do; the transmitter has to send it again. So it needs to know whether it was received well. You'll have to send an acknowledge (ACK/NAK) after each byte, and the transmitter can't send the next byte before it has received the ACK. If you use ASCII codes that's 11 return bits. So this halves the thoughput, and we already lost 10%, so we're now at a 36% payload efficiency, from 80%. And that's the reason why nobody is really fond of parity.

Notes:
1. You don't need to acknowledge the receipt of an acknowledge; the Hamming distance between the ASCII codes for ACK and NAK is 3 (with parity even 4), so an error in the reception of ACK/NAK can be not only detected, but also corrected.
2. Many UARTs can work with data lengths down to 5 bits, and it's possible to switch to 5 bits for sending the ACK, but this is mere window-dressing, and it only complicates communication.

A better solution can be to use a CRC at the end of each block. CRCs are better than parity bits at capturing multiple errors (yet they still can't correct them). Improved efficiency can only be obtained for long blocks; if a block consists of only 2 bytes it's no use to add an 8-bit CRC.
Another disadvantage would be that you still have to acknowledge correct reception. So that's probably not it either.

How about self-correcting codes? Hamming codes add little overhead, and allow you to correct 1 erroneous bit yourself; no longer need for acknowledging. Like CRCs Hamming codes are more efficient on longer blocks; the number of additional bits is defined as

\$N + H < 2^H\$

where N = number of data bits, and H = number of Hamming bits. So to correct 1 bit in an 8-bit communication you need to add 4 Hamming bits; a fifth Hamming bit is only required from 12 data bits. This is the most efficient way of error detection/correction on short messages (a few bytes), though it requires some juggling with your data: the Hamming bits have to be inserted at specific positions between your data bits.

Now before you add Hamming error correction codes it's worth looking into your setup. You can expect errors on a 100m line running between heavy machinery, but you shouldn't have errors on a 2cm line. If it picks up noise it may be too high impedance. Are the drivers push/pull? If so they should be able to give you fast edges, except if you "cable" is capacitive, which it won't be at this short distance. Are there high current traces running parallel to the data lines? They could induce noise. Do you really need this high speed, and do clocks on both sides match closely enough? Slowing down to 57600 bits per second may solve the problem.

Answer 8

Despite the plethora of answers I'll add my piece. Parity will work on a byte level, and a CRC works (generally) on a packet level. Packets schemes are in my opinion superior to raw byte-type communications. If your hardware rejects a single byte based on parity, that's great for a raw bytestream, but not so good for a packet. All of a sudden, boom, you've missed a byte in the middle of a packet - that screws up your parsing. In the best case, your whole packet is gone, but if your packet finding algorithm isn't good, you could potentially lose more (and I've seen some brain-dead packet detection algorithms used in real products). Use packets and CRCs like was suggested.

Answer 9

Parity is generally useless with "normal" async-style communication, but it may be useful in some other contexts. For example, some differential coding schemes require that every character have an even number of line transitions so that the final state of the line will match the initial state. Code 39 barcodes use parity, sort of(*), to validate individual characters, and generally eliminate the need for a checksum character.

If single-bit errors were much more common and multi-bit errors or framing errors, per-byte parity checking could be a useful adjunct to a checksum or CRC, since locating a byte with an error would allow the error to be corrected. In most practical situations involving UARTs, however, many line glitches cause framing errors, making data recovery in many cases impossible with or without per-byte parity.

(*) A valid Code 39 character must have an odd number of wide spaces (1 or 3) and an even number of wide bars (0 or 2).