Electronic – For UART, should I use parity on a board level

parityuart

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?

Best Answer

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.

Related Topic