1 Introduction

In just about every aspect of life there is a digital transmission. The transmission can vary in length, distance and speed. Digital streams are common in satellite TV and smartphone data. In many cases an error in transmission is nothing more than a nuisance such as a momentary distortion in a picture signal or a click or pop in the audio. However, in critical systems an error is problematic and even life threatening. Some examples of critical systems are autonomous vehicles and aircraft flight control systems. A non-life threatening example requiring a high degree of data integrity occurs when saving data to storage media on a computer.

There are many possible causes for a disruption of a digital stream of data. Ideally the best method for maintaining data integrity is to prevent any occurrence of a disruption in the first place. But even when using best practice in system design there is still the possibility for an unforeseen occurrence that can alter the transmission of digital data.

When designing a system, first analyze the affect of a disruption. If the disruption is within a critical system, such as used in flight control, then it is important to know when the event takes place and have a mechanism to alert or handle the data corruption when it happens. To ascertain whether there is a digital transmission error, or fault, a method of data analysis is used to determine if data corruption occurred. To better understand a fault condition it is important to know what type of error can exist in the data.

Using the example of a simple go or no go, and sometimes called ACK or NACK, within a communication packet helps in understanding the necessity of data validation. As many are familiar with I²C communication, this protocol will be used as an example. I²C uses 8-bit data transfers followed by a 9^th bit indicating if the data transfer is valid (ACK) or invalid (NACK) by the receiving device. If the receiving device holds the data line (SDA) low at the 9^th clock (SCL), the transmitting device understands that the communication is acknowledged (ACK) and the communication was received. However, with this type of system there is no clear indication if the data are truly valid only that data is received (ACK) or not received (NACK) as expected. There is no mechanism in this approach to determine if the data are valid from the transfer from device to device.

Another common method of digital communication is by universal asynchronous receiver transmitter (UART). Depending on the implementation, the data transfer uses a method called parity to check the integrity of the data. Each byte of data is framed with a START bit and STOP bit(s). The data bits are contained between the START and STOP frame. Parity is used as a method to determine whether an ASCII character was transmitted as expected. The data contains a 7-bit ASCII character along with a PARITY bit for a total of 8 bits of data. In binary terms, a "1" is counted for each of the 7 bits of the character transmitted. For example, the ASCII character "A" has the value 41h or 1000001b containing two "1"s. The terminology of EVEN and ODD parity communicates to the end user whether the value of the parity bit relates to an even number of "1" values or an odd number of "1" values when including the parity bit. Using parity allows for some acknowledgment that data are valid or invalid. But as this simple parity is useful it is possible for multiple bit flips within the communication to appear as valid data that may actually be invalid. As communication evolves with increasing data length and speed, data integrity is a greater issue as more and larger packets of data are transmitted. This requires more comprehensive methods for validating data transfers.

When binary data transmission became commonplace through the use of modems to connect computers, servers and the internet, data integrity verification techniques improved. Just as modem speeds increased, so did the need for better methods of error detection within the digital transmission. Not only is data integrity a point to point issue, but is also a major concern with both wired and wireless networks and the streaming of data to multiple end points.

Similar issues with data integrity can be found within an embedded system where there are many possible options to ensure data integrity. One simple option is to send data, then verify the data by having the receiver return the data back to the sender for comparison. Other systems may employ methods that invert the data for comparison or use a checksum of the data. A more complex method uses a polynomial based cyclic redundancy check (CRC). Each of these methods have differing degrees of difficulty for integration and differing results with respect to determining data integrity.

Not all analog-to-digital converters (ADCs) have a built-in hardware method for determining communication error. For these types of devices, anything written to the device should be verified with a read. For the conversion data, the result should be read multiple times comparing the results received. The ADC device datasheet will indicate if a hardware method is available for data integrity checks and whether or not the device is both ingoing and outgoing data integrity or just outgoing. When choosing an ADC for a particular application consider the criticality of the system with regards to the method of data integrity supported by the ADC.

Checksum and CRC are common hardware methods used by ADCs to append a coded value to the end of a data message transfer. The appended information is used to determine if an error occurred in transmission. For devices using checksum, such as the ADS1259, the conversion data are followed by a checksum byte. The checksum is the addition of the three data bytes, from the 24-bit conversion result, and a constant of 9Bh. The constant applies an offset to the data reducing the probability of the same checksum occurring multiple times. When adding the bytes together, any overflow is ignored in the computation. The result of the computed checksum is compared to the transmitted checksum. If the comparison of the computed checksum is equal to the checksum byte then the validation passes.

When the data integrity implementation is CRC, such as with the ADS124S08, the receiver must verify the data following the completed transmission. The message portion of the transmitted data is computed and compared to the transmitted CRC value. If the computed CRC value does not match the transmitted CRC value, an error in transmission has occurred. In this way the comparison is similar to using checksum, but the computation is much different. The CRC has a higher degree of data validation compared to the checksum, but requires more processing effort since the CRC uses polynomial division instead of simple addition of the checksum.

Some hardware methods that are offered by the ADS122U04 and ADS122C04 families in addition to CRC also support less complicated approaches to verifying data integrity. The feature employed in these devices is by transmitting the data twice. The first transmission is the non-inverted data, and the second transmission is a bitwise inversion of the original data. Using an exclusive 'OR '(XOR) of the two transmitted data should result in all "1"s and no "0"s if the communication was successful.

Regarding this application note, one focus covers the use of checksum and CRC. Included within the discussion are the computations and functions for use within an embedded processor using "C" firmware. It is possible to use other methods of computation. This would include the use of internal hardware peripherals within the processor. However a hardware CRC peripheral of a processor, depending on polynomials used, may not have the same exact polynomial implementation used by the ADC.

Most of the information and examples can also be adapted for use by other ADCs such as the ADS124S08, ADS1261 and ADS1262 family of devices. Additionally this application note includes a discussion on the use of Hamming code as a data integrity feature supported by the ADS131A04 family of devices. The ADS131A04 is a device that can be configured for use in critical applications. For the ADS131A04 the data integrity can be validated on both incoming and outgoing communication. The Hamming code option allows for single-bit error detection and correction. Within the Hamming byte is a simple 2-bit checksum to help in determining some multi-bit error. CRC can also be added to the transmission in addition to the Hamming/checksum to uncover most multi-bit error.