SBAA106A June 2020 – August 2021 ADS112C04 , ADS112U04 , ADS114S06 , ADS114S08 , ADS122C04 , ADS122U04 , ADS1235 , ADS1235-Q1 , ADS124S06 , ADS124S08 , ADS1259 , ADS1259-Q1 , ADS125H01 , ADS125H02 , ADS1260 , ADS1260-Q1 , ADS1261 , ADS1262 , ADS1263 , ADS127L01 , ADS131A02 , ADS131A04 , ADS131M04 , ADS131M06 , ADS131M08
All trademarks are the property of their respective owners.
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 I2C communication, this protocol will be used as an example. I2C uses 8-bit data transfers followed by a 9th 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 9th 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.
Method | Advantages | Disadvantages |
---|---|---|
Inverted Data | Easy and quick computation | Doubles the length of transmission; No error correction capability |
Parity | Easy and quick computation; Detects single-bit error in short data packets |
Prone to error due to many combinations resulting in the same
parity value; Useful for small data packets only; No error correction capability |
Checksum | Easy and quick computation; Detects single-bit error and some multi-bit error in short data packets |
Prone to error due to many combinations resulting in the same
checksum value; Useful for small data packets only; No error correction capability |
CRC | Fewer combinations of bit flips for the same CRC value resulting in a more comprehensive analysis | Lengthy computation times required or a LUT can be used but
increases memory usage; No error correction capability |
Hamming | Increased detection for multi-bit error; single-bit error correction |
Lengthy computation times required |
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.
Device | Interface | Data Direction | Data Integrity Method(s) Used | Polynomial | Data Integrity Computation |
---|---|---|---|---|---|
ADS122C04 | I2C | MSB first | Inverted Data; CRC-16-CCITT |
x16 +
x12 + x5 + 1; initial value FFFFh |
Register reads, the 24-bit conversion result and the data counter byte when enabled |
ADS122U04 | UART | LSB first | Inverted Data; CRC-16-CCITT |
x16 +
x12 + x5 + 1; initial value FFFFh |
Register reads, the 24-bit conversion result and the data counter byte when enabled |
ADS124S08 | SPI | MSB first | CRC-8-ATM (HEC) | x8 +
x2 + x + 1; initial value 00h |
24-bit conversion result and the STATUS byte when enabled |
ADS131A04 | SPI | MSB first | CRC-16-CCITT and/or Hamming |
x16 +
x12 + x5 + 1; initial value FFFFh |
Ingoing and outgoing transmissions; CRC and Hamming can both be enabled at the same time |
ADS1259 | SPI | MSB first | Checksum | N/A | 24-bit conversion data plus offset of 9Bh |
ADS1261 | SPI | MSB first | CRC-8-ATM (HEC) | x8 +
x2 + x + 1; initial value FFh |
Incoming commands, 24-bit conversion result and the STATUS byte when enabled |
ADS1262 | SPI | MSB first | Checksum or CRC-8-ATM (HEC) |
x8 +
x2 + x + 1; initial value 00h |
Checksum for 32-bit conversion data plus offset of 9Bh or when using CRC 32-bit conversion data only |
The checksum can be appended to conversion results on devices such as the ADS1259 and ADS1262. Checksum allows for error detection of single-bit error and some combinations of multi-bit error. The checksum byte is computed by adding the value for each of the conversion data bytes together along with the addition of a constant. For the mentioned devices the constant is 9Bh. As the checksum is a byte in length, any carry from the addition is ignored. In the case of the ADS1259, which is a 24-bit device, the MSB, Mid-Byte and LSB are added together with the constant. The result of the checksum is appended to and transmitted with the conversion data.
The checksum is easy to compute with minimal processing effort. However, if there are multiple bit errors present it is possible for the errors to go undetected since multiple combinations of different data added together will result in the same checksum value. For example, the addition of conversion data 12h, 34h, 56h and constant 9Bh results in a checksum of 37h. But the data could become corrupt in transmission. If instead the data are received as 12h, 35h, 55h and constant 9Bh, the addition of these bytes result in the same checksum of 37h.
Checksum can be useful when checking for 1 to 2 bit error in small data packets. With small data packets there is some potential for missing the error in the data, but as the data packet size increases so does the potential for missing the multiple bit errors. Using checksum alone is not the best method available for determining data integrity.
The following code example can be used for devices such as the ADS1259 and ADS1262 that have the checksum data integrity feature. The checksum can be computed by sending a pointer to the data along with the length of the data packet to be considered. The data bytes are summed together along with the constant to create the checksum byte. The computed checksum byte is then compared with the checksum transmitted with the data. The byte values should match otherwise an error occurred.
/**
* Computes a checksum for an array of data bytes.
*
* \details Computes a series of bytes pointed to
* by an array of data for a specified length. A constant 0x9B is also added.
*
* \param uint8_t *data, pointer to data array.
* \param uint32_t length, of data array.
*
* \returns uint8_t result.
*/
uint8_t calcChecksum(uint8_t* data, uint32_t length)
{
uint32_t result = 0;
uint32_t i;
for(i = 0; i < length; i++)
result += data[i]; // Add conversion data bytes together
result += 0x9B; // Add constant
return (uint8_t) result;
}
CRC is a polynomial based system and can vary in the number of bits used and the effectiveness of detecting an error for a given polynomial. Checksum differs from CRC in that checksum uses addition, whereas CRC uses division. The desired polynomial is divided into the data leaving a remainder to be transmitted following the data. The effectiveness of using any particular polynomial is indicated by the Hamming Distance (HD) which for the discussion of CRC is the boundary where an undetected bit error may occur. HD signifies the minimum number of bit errors that are undetectable. The number of bits when all errors are detected is one less than the HD. The HD can change relative to the length of the data and generally will decrease as the length of the number of data bits increases.
As a part of the CRC discussion, Hamming Weight (HW) refers to the number of undetectable bit errors for a polynomial for a given number of bit errors. The ideal HW is zero and when the HW is non-zero for a given number of bits then not all combinations of bit errors will be detected should an error occur. The HD relates to the first HW greater than 0. For example, if a polynomial has a HD of 4 , all combinations of 1, 2, and 3-bit error, also known as bit reversals or flips, are detected. If the HW is 11 for 4-bit errors with data lengths of 48 bits or more, then there are 11 combinations of undetectable 4-bit errors for the data packet.
Depending on the polynomial and the total number of bits in the data transfer, the HD might increase for up to a particular number of bits of data. Using the previous example, the HD may be increased from 4 to 5 for a data length less than 48 bits. Much data has been collected regarding the HD of various polynomials by independent research. The point of this discussion is to limit some confusion as to the effectiveness of various polynomials and show that undetected error may still occur when using CRC. Different polynomials are used by various ADCs and in most cases are fixed to a single polynomial. Thus, there may be little to no choice on which polynomial to use. The polynomials used for the ADC may not be the best polynomial to use in a given application, but is chosen due to familiarity or commonality of a particular polynomial. Another reason may be for the availability of hardware implementations on various microcontrollers. As many microcontrollers use 8-bit (byte) communication it becomes useful to use CRC polynomials that are oriented to 8-bits or multiples of 8-bits. This discussion will not focus on which polynomial to use, but rather focus on the actual polynomials used for devices such as the ADS124S08 family of devices (8-bit CRC) as well as the ADS122x04 family of devices (16-bit CRC).
As both the encoding and decoding of the CRC is similar the bit patterns of the remainder can be easily compared. If the bits match, then it is likely the transmission was valid for a given HD. However, if the bits do not match then an error occurred. From a software implementation, the polynomial is divided into the data word resulting in a remainder. From the ADC hardware perspective, these devices utilize some form of logic in relation to the output shift register to compute the CRC value regardless of the data length being transmitted. It is important that the data be analyzed in the same bit order as the initial CRC computation. So careful attention to Endianess (see Table 3-1) and byte order is needed.