(*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.

**Parity bit **

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.

**Checksum **

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.

A CRC is generated through a calculation that’s done on the data and then transmitted with the data. The receiver can do the same calculation and then compare the CRCs. If the CRCs match, the data is most likely good. Many communication schemes use CRC because it’s easy to implement on the transmitting side and analyze on the receiving side.

In this example, we’ll use the LMP90100 to show how the CRC is generated. Data is sent out of the ADC on a serial bus in 24 bit pieces for each conversion of the ADC. An 8-bit CRC can be sent with the data when the LMP90100 is used in a noisy environment. The CRC transmission can also be turned off when it is not needed.

A generator polynomial is used to calculate the CRC. This polynomial is one bit longer than the resulting CRC. The LMP90100 uses a polynomial of x^{8} + x^{5} + x^{4} + 1. It has a degree of 8, which means the polynomial has 9 terms and the CRC will have 8 bits. Commonly used polynomials range from a degree of 1, (x + 1) which will give you a parity bit, to a degree of 64. [USB uses a polynomial with a degree of 5 (x^{5} + x^{2} + 1), Bluetooth uses a polynomial with a degree of 16 (x^{16} + x^{12} + x^{5} + 1), and Ethernet uses a 32 degree polynomial. ]

The polynomial can be represented in binary terms for the CRC calculation by listing its coefficients. If this is done to the LMP90100 polynomial we get 100110001 (the coefficient of x^{8} is 1, the coefficient of x^{7} is 0, and so on). The CRC is generated using the following method.

- The data is left-shifted by the same amount of bits as the size of the CRC, and 0s are added on the right side. For example, if the 24-bit ADC data from the LMP90100 is 010101011000100101001011

and the CRC from the LMP90100 is 8 bits, the data is shifted left 8 bits and 8 zeros are added on the right side. The data for the CRC calculation would be: 01010101100010010100101100000000.

- The polynomial in binary form is put underneath the modified data. The MSB of the polynomial is put under the left-most 1 of the data.

01010101100010010100101100000000 0

100110001

- A XOR (exclusive-OR) function is applied to the data and the polynomial. The remaining data to the right of the polynomial is brought down. The polynomial is once again put underneath the left-most 1 and the data is again XORed. This continues until the left-most 1 of the remainder is in the 8th or less bit position. Figure 1 shows the entire process for the three bytes of data we are using.

*Figure 1: Generation of a CRC *

*(click here to see enlarged image) * .

Once the CRC has been calculated, it can be sent with the conversion data. The LMP90100, however, does not send the actual CRC, it sends the one’s complement of the calculated CRC. This is done because if the data is 0x000000, the CRC will be 0x00. The resulting data thatm is sent is 0x00000000 (three bytes of data and CRC).

This could be cause for concern (especially if this data set of all zeros was repeatedly sent for a length of time) as perhaps something happened to the data line, such as a short to ground. The one’s complement of 0x00 is 0xFF, which means that the four bytes sent has become 0x000000FF. This lets the microcontroller know that the data line is good.

The ADC data in the LMP90100 is located in registers 0x1A, 0x1B and 0x1C. The CRC, in ones complement form, is located in register 0x1D. This makes it easy for the microcontroller to read this data because it starts at register 0x1A and simply reads a block of four bytes.

Once the microcontroller has the data and CRC, it can then do the same calculation on the data. If the CRCs match the data, it’s most likely good and can be used. If the CRCs do not match, the data can be discarded and the microcontroller can ask for the data again, or just wait for the next set of data.

**Conclusion **

When used in an industrial sensing application the integrity of the data is critically important. The LMP90100 sensor AFE gives the designer a proven method of checking that the microcontroller is receiving good data by using a CRC. This approach ensures data integrity and a more robust system, even when used in a noisy environment.

*About the Author *

** Mike Stout ** is an applications manager for Texas Instruments Precision Systems group, focused on precision signal chain products. Previously, Stout worked as an applications engineer in National Semiconductor’s CRT and Digital Television Products group. Stout received his Bachelor of Science degree in Electrical Engineering from Brigham Young University.

*Editor's note * *: Liked this? Want more? *

If you are interested in “analog” issues such as signal input/output (sensors and transducer, real-world I/O); interfacing (level shifting, drivers/receivers); the signal chain; signal processing (op amps, filters, ADCs and DACs); and signal integrity, then go to the *Planet Analog* home page **here** for the latest in design, technology, trends, products, and news. Also, sign up for our weekly *Planet Analog* Newsletter **here**.

## 0 comments on “Ensuring data integrity in a noisy world”