(Editor's note: No matter how good or well-matched your analog/digital converter is to the application or sensor, its performance can be diminished or even misleading if noise corrupts the digital side of the converter and converter/processor link. The problem is especially challenging if the analog front end is placed close to the sensor—as it usually should be—and thus further from the processor which is accepting signals from the ADC.)
Noise from the ambient environment can introduce errors into the data during digital data transmissions. This noise can come from many different sources, including electromagnetic interference (EMI) from equipment and motors, radio transmissions, or 50Hz or 60Hz AC lines. Ambient noise can randomly change a “1” to a “0” or a “0” to a “1”.
This article will describe what noise can do to digital data when going from a sensor analog front end (AFE) to a microcontroller. Four primary methods have been developed to detect noise induced errors in data. These include:
•adding a parity bit,
•calculating a checksum,
•comparing all data transmitted,
•and, calculating a cyclic redundancy check (CRC).
Each approach is described along with their advantages and disadvantages. One example will describe how the LMP90100 determines the CRC for ensuring correct data reception.
The LMP90100, developed by Texas Instruments, is a high-precision sensor AFE with a 24-bit analog-to-digital converter (ADC). When used in an industrial application where ambient noise is high, it is recommended that the LMP90100 be placed close to the sensor. This protects the integrity of the analog signal going from the sensor to the LMP90100. However, this could create long serial lines between the LMP90100 and the microcontroller, which increases the chance of the ambient noise changing some of the digital data being sent to the controller.
Noise induced errors can be found anywhere in the data being transmitted. For example, if data of 10000000b (0x80) is transmitted in a noisy environment, it can be just as easy for the data to be changed to 00000000b (0x00) as it is changing it to 100000001b (0x81). The second case would probably not cause too much of a problem, but the first case (00000000b (0x00)) is drastically different from the original data.
Let’s suppose the LMP90100 is connected to a thermocouple, and it sends out 24 bits of data for every conversion of the ADC. If one of the MSBs of the 24 bits of data is changed, the controller will think that whatever is being measured has suddenly changed temperature and some type of action is needed. What is needed is a way to ensure that the data has not been corrupted by ambient noise.
The number of 1s in the byte are counted before the data is transmitted and then a ninth bit (called a parity bit) is added. There are two types of parity bits used: even parity and odd parity. If even parity is used, the ninth bit is made either a 0 or 1 so the total number of 1s in the byte is even. In odd parity, the ninth bit is made 0 or 1 so the total number of 1s are odd.
Table 1 shows some examples. The first data row has a byte that contains four 1s. Even parity will add a 0 to the data to keep an even number of 1s, while odd parity will add another 1 to the data.
Table 1: Parity bit examples
(click here to see enlarged image).
Using a parity bit is simple and has low overhead as only a single bit is being added to each byte. It will detect simple errors such as one bit being flipped. However, it will not detect an error of two bits being flipped.
A checksum can be used on data of more than one byte. The checksum is calculated by adding a group of bytes together, removing the overflow bits, taking the two’s complement and transmitting this result as an additional byte along with the data. Once the receiver has the data, it adds the transmitted bytes and the checksum together and discards the overflow bit.
If the result is not all zeros, the data has an error. The receiver can then ask to have the data retransmitted. This method is also easy to implement although it has a little more overhead than a parity bit since more information is being transmitted.
Checksums are not able to detect if the data has been swapped or if null bytes have been removed or added. Table 2 shows how the checksum is calculated. The middle column shows how the sum of incorrectly transmitted data and the checksum do not add up to zero. The two columns on the right of Table 2 show some of the errors a checksum will not detect.
Table 2: Checksum examples
(click here to see enlarged image).
Read back of data or multiple data transmissions
The most reliable data transmission is when the actual transmitted data is compared. This can be done in two ways. The first way is for the transmitter to send the data and the receiver to send the data back to the transmitter. If the data is the same, no errors have occurred.
The second way is for the transmitter to send the data two or more times. The receiver can compare the data transmissions and if they are the same, the data is good. In either case, if the data is bad the receiver can ask the transmitter to send the data again. Sending data multiple times is the most reliable way to transmit data, however it has high overhead as the data is sent two or more times.