• A CRC check divides the frame by a generator polynomial and appends the remainder; the receiver repeats the division and expects zero.
  • For the same two bytes of overhead, a CRC-16 detects burst errors that a byte sum passes through undetected.
  • Parity catches a single flipped bit per character and misses any even number of flips inside it.
  • Modbus RTU frames carry a 16-bit CRC defined by the Modbus over Serial Line specification, transmitted low byte first.
  • Two nodes agree when polynomial, initial value, input reflection, output reflection and final XOR all match.

1. What Is a CRC Check?

A CRC check is an error-detection method that treats a data block as a polynomial, divides it by a generator polynomial, and appends the remainder.

The cyclic redundancy check (CRC) operates on the bit stream rather than on byte values. A transmitter appends the remainder it computes; a receiver recomputes the same remainder and compares the two.

Core characteristics

  • Polynomial arithmetic, not addition: division runs in GF(2), where addition is XOR, so a flipped bit changes the remainder.
  • Fixed overhead: the remainder is 8, 16 or 32 bits, so a CRC-16 adds two bytes to each frame.
  • Built for burst errors: a polynomial of width n detects every burst error up to n bits long.
  • Detection, not repair: a failing CRC reports damage; recovery still depends on a timeout and a retransmission.
  • Parameter-dependent: the same polynomial with a different initial value or reflection gives a different remainder.

2. How Does a CRC Check Work?

A CRC check runs the same arithmetic at both ends of a link, so the sequence fits either software or a hardware peripheral.

  1. The message becomes a polynomial. Each bit is a coefficient, with the first transmitted byte at the high-order end; byte order across the frame is part of the definition.
  2. Both ends agree on a generator polynomial. The Modbus over Serial Line specification defines a 16-bit CRC using the polynomial x^16 + x^15 + x^2 + 1.
  3. Zero bits are appended and division runs modulo 2. There is no carry and no borrow: at each step the leading term is cancelled by XOR, and every earlier bit influences the result.
  4. The remainder is appended and transmitted. On a Modbus RTU frame the CRC follows the data, low byte first, per the Modbus over Serial Line specification.
  5. The receiver repeats the division. A zero remainder accepts the frame; a non-zero remainder means a bit changed in transit and the frame must be sent again.

All five parameters must match between the two nodes: polynomial, initial value, input reflection, output reflection and final XOR. Two datasheets that both say "CRC-16" may describe different functions, and the symptom is a link that rejects every frame.

3. What Are Checksums and Parity?

A checksum adds the bytes of a frame, and parity adds one bit that makes the number of set bits odd or even.

Both cost less than a CRC, and both accept a pair of faults that cancels arithmetically.

Core characteristics

  • Checksum, arithmetic over byte values: bytes are added with carries, or XORed, and a check byte is appended to the frame.
  • Parity, one bit per character: the bit is set so the count of ones is odd or even; 8-N-1, the usual Modbus RTU setting, disables it.
  • Layer: parity lives in the UART character frame and is checked per byte; a checksum lives in the protocol frame and is checked per message.
  • What they miss: compensating error pairs, byte-order swaps, and lost or duplicated bytes that preserve the sum.

4. CRC vs Checksum and Parity: What Is the Difference?

All three append redundancy to detect corruption, but they differ in what they detect and in what that costs.

Dimension CRC check Simple checksum and parity
Method and cost Polynomial division over the frame; two bytes of overhead for a CRC-16 Byte addition or XOR, or one bit per character; cheapest in code size and cycles
Error patterns detected well All single-bit errors, every burst up to the polynomial width, and all odd numbers of bit errors Single-bit errors within one character, and byte-value errors that do not cancel
Error patterns missed Rare residual patterns beyond the designed Hamming distance; odds near 2^-n Error pairs that cancel arithmetically, byte swaps, and lost or duplicated bytes
Typical use in IoT protocols Modbus RTU and proprietary serial or radio frames carrying commands Legacy ASCII protocols, simple sensor strings, and the UART parity bit
Implementation effort A table-driven routine plus tests against published vectors A few lines of code; the risk is assuming more protection than it gives
Behaviour under burst noise A burst shorter than the polynomial width is caught, as with contactor arcing An even number of flipped bits in one character defeats parity

The decision rule: use a CRC check where a damaged frame could trigger the wrong action or corrupt stored data, and keep a checksum or parity where the payload is short and the link already retries.

5. CRC Check Configuration and Key Parameters

A CRC-protected link fails in the field for a small set of parameter reasons, and each has a distinct symptom.

  • CRC width: 8, 16 and 32 bits are the common choices, with CRC-16 on Modbus RTU frames. A width mismatch rejects every frame.
  • Modbus RTU CRC field: 16 bits over all preceding bytes, transmitted low byte first per the Modbus over Serial Line specification; a high-byte-first sender is rejected.
  • Byte order on the wire: low byte first on Modbus RTU. Swapped CRC bytes leave the arithmetic correct but the frame discarded, so the device looks dead.
  • Reflected or non-reflected: reflection reverses the bit order of the inputs and the output. Pairing one of each rejects every frame, a quick bench test.
  • Parity and stop bits: 8-N-1 is the usual Modbus RTU setting; a parity mismatch floods the UART with framing errors before the CRC runs.
  • Framing and length checks: a CRC covers the bytes captured, no more. A late direction switch truncates the frame, so the length is wrong rather than the CRC.
  • Retry and timeout policy: the master timeout must exceed frame time plus radio round trip, or a late retry duplicates an answered frame.
  • Radio FEC versus host CRC: forward error correction in the modem repairs a limited number of damaged bits in flight, while a host-level CRC verifies the bytes handed to the application.

6. When to Use a CRC Check and When Not To

A CRC check belongs wherever an undetected bit change causes a wrong action, and is unnecessary where the payload is short and a bad frame is free.

Good fit for a CRC check

  • Command and control frames, where a corrupted register write changes an output state.
  • Modbus RTU links, where the frame format reserves two bytes for a CRC.
  • Radio paths carrying serial data, where a marginal link delivers damaged frames.
  • Multidrop RS485 segments in noisy plants, where short bursts dominate.

Poor fit for a CRC check

  • Very short periodic telemetry, where implausible values are discarded and the retry is free.
  • Inside one enclosure over a few centimetres of trace, where connector faults dominate.
  • Fixed real-time loops of a few milliseconds with the routine in software.
  • Links whose real fault is timing or wiring, which no stronger check recovers.

7. Real-World Applications

In industrial automation, energy monitoring and telemetry, error detection is layered rather than chosen once. A Modbus RTU device validates each frame with the CRC field the protocol defines before acting on a register write.

Ebyte Modbus RTU modules follow that pattern. The MA01-AACX2220 is an EMC and RoHS compliant RS485 2DI + 2AI + 2DO I/O network module with a serial port for a PLC or touch display, so every command reaching it over RS485 carries the protocol's own check. For bridging, the ME31-AAAX4220 offers two relay outputs, two analog 0-20 mA / 4-20 mA inputs and four dry-contact inputs, and the ME31-AXXX8000 provides eight dry-contact inputs with RJ45 and RS485 interfaces; on the RTU side of both, the CRC stays in place.

Radio links add a second layer. The E150-400T30S is a LoRa module on 410.125-493.125 MHz with 30 dBm output, an IPEX antenna and Modbus RTU support, so frames cross a radio hop before the CRC check at the far end. The E22-400T22D-V2, an SX1268 LoRa UART module with 22 dBm output and TTL levels compatible with 3.3 V and 5 V, extends a serial link directly. Where the modem corrects errors itself, the E70-433T14S2 based on the TI CC1310F64RSM includes hardware FEC, the E34-2G4H27D applies an FEC algorithm that can correct interfered data packets automatically, and the E22-900T22D-V2 is optimised with forward error correction. That mechanism repairs damaged bits in flight and does not replace the frame check above.

Antenna quality is consistently underestimated: a quoted range assumes a clear feed line and correct mounting, and a marginal link produces the damaged frames a CRC check exists to catch.

8. FAQ: CRC in Practice

Q1: What is a CRC check and how does it work?

A CRC check divides the message, treated as a binary polynomial, by an agreed generator polynomial and appends the remainder. The receiver repeats that division over the received bytes and expects a zero result. A non-zero result means a bit changed in transit.

Q2: CRC vs checksum: which is stronger for serial data?

A CRC is stronger for the same overhead on most serial links, because a polynomial catches error bursts that a byte sum misses. A checksum lets pairs of compensating faults pass. Use a CRC where a corrupted frame would trigger a wrong action, and a checksum where the payload is short.

Q3: Why does my Modbus RTU CRC check fail?

Failures usually come from a configuration or wiring fault, not from the CRC arithmetic:

  • Garbled values on every read → confirm 8-N-1 and matching baud rates.
  • One device rejects frames on a shared bus → capture the trunk and locate the failing frame by slave address.
  • Errors after a cable change → verify 120 ohm termination and short stubs.

Q4: What is the difference between FEC and a CRC check?

Forward error correction and a CRC solve different problems. FEC adds redundancy that lets a receiver reconstruct damaged bits, so a packet can survive without a retransmission. A CRC detects damage but cannot repair it, so the link must ask again. Radio modules may advertise FEC in the modem layer, separate from a host-level frame check.

Q5: How do I check a CRC implementation when two nodes disagree?

Compare the five CRC parameters first; a routine that rejects every frame is usually mismatched:

  • Accepted locally, rejected in the field → check polynomial, initial value, input and output reflection, final XOR.
  • CRC bytes reversed on a scope → confirm the wire byte order.
  • Short frames pass, long frames fail → check that the length covers both CRC bytes.

9. Pre-Flight Checks Before Trusting a CRC Check

  1. Confirm the variant, not the width. Ask for polynomial, initial value, input reflection, output reflection and final XOR, then test against a known check vector.
  2. Verify the wire order of the CRC bytes. Modbus RTU sends the low byte first, and a swapped pair leaves a link that looks dead.
  3. Separate framing faults from CRC faults. Log parity, framing and overrun errors beside CRC failures; rising parity points to baud rate or interference.
  4. Locate the bad frame by address. On a shared bus, capture the trunk and identify the slave producing the failing frame.
  5. Budget for recovery. Set the master timeout above frame time plus radio round trip, and fix the retry count.