What Is the Modbus CRC-16 Checksum?

Back to Blog

What the CRC Covers and How It Is Checked

In Modbus RTU the CRC-16 is the last two bytes of the frame. The transmitter runs a cyclic redundancy calculation over every byte before it, the slave address, the function code, and all the data, and appends the resulting sixteen-bit value, low byte first, which is a quirk worth remembering since most Modbus multi-byte fields are high byte first. The receiver runs the identical calculation over the bytes it received and compares its result to the CRC it was sent.

If the two match, the frame is accepted as intact; if they differ, the receiver concludes the frame was corrupted in transit and discards it silently. There is no negative acknowledgment, which is important: a CRC failure looks to the master exactly like no reply at all. This is why line-noise problems present as timeouts rather than explicit errors, a symptom pattern that overlaps with the timing issues in the Modbus serial response delay reference.

Why the CRC Exists and Where It Does Not

The CRC exists because a serial line is an unprotected channel where electrical noise, reflections from bad termination, or a marginal transceiver can flip bits. A two-byte CRC catches the burst errors typical of such faults far more reliably than a simple checksum would, which is why RTU uses a CRC while the older ASCII mode uses a weaker longitudinal redundancy check, a contrast drawn in the Modbus RTU vs ASCII transmission mode reference.

Modbus TCP has no CRC at all. The MBAP-headered TCP frame relies on TCP's own checksums and reliable delivery, so a Modbus-level CRC would be redundant, as the Modbus TCP vs RTU comparison explains. The CRC is therefore a serial-RTU-only feature, and its absence is one of the quick tells that distinguishes an RTU capture from a TCP one.

The Algorithm Parameters, Fixed by the Specification

You rarely need to implement the CRC yourself, but knowing its fixed parameters helps when a library or a protocol analyzer gives a result you did not expect. The Modbus RTU CRC uses the generator polynomial x^16 + x^15 + x^2 + 1, written 0x8005, and virtually every implementation processes it in reflected form using the constant 0xA001. The register is seeded with 0xFFFF, there is no final XOR, and the result goes onto the wire low byte first. All of this is fixed by the Modbus over serial line specification, so any two conforming implementations must produce identical values for the same bytes - if yours disagrees with a known-good tool, one of these parameters is set wrong.

Parameter	Value in Modbus RTU
Polynomial	x^16 + x^15 + x^2 + 1 (0x8005)
Working constant (reflected form)	0xA001
Initial register value	0xFFFF
Final XOR	None
Byte order in the frame	Low byte first
Coverage	Address through the last data byte

Checking a Frame by Hand: A Worked Example

Suppose a capture shows a request of six bytes followed by two more: address, function code, starting-address high and low, quantity high and low, then two trailing bytes. To verify it, feed the first six bytes to any Modbus CRC-16 routine or calculator configured per the table above and compare the sixteen-bit result to the trailing pair. Remember the order: the first trailing byte on the wire is the low byte of the computed value and the second is the high byte. If your computed value matches only when you swap the two bytes, nothing is corrupted - your tool is printing the value high byte first while the wire carries it low byte first, which is the single most common source of false alarm when checking frames manually.

If the value does not match in either order, there are two possibilities: the frame really was corrupted, or your capture stitched together bytes from two different frames. The second case happens when the silent interval between frames shrinks below the specification's 3.5 character times and the capture tool, or the receiver itself, can no longer tell where one frame ends and the next begins. A frame boundary error and a corrupted frame look identical from the CRC's point of view, so when hand-checks keep failing on frames that devices are apparently accepting, suspect your capture setup before the wire.

Diagnosing a Line That Fails CRC Repeatedly

Occasional CRC failures on a long serial run in an electrically noisy plant are unremarkable; a rising or constant failure rate is a wiring problem wearing a protocol costume. Work through the physical layer in a fixed order rather than jumping to conclusions:

1. Confirm both ends of the RS-485 segment are terminated, and that no mid-span device has its termination resistor switched in.
2. Check biasing so the line idles in a defined state - an undefined idle produces garbage bytes at frame boundaries that fail CRC.
3. Verify every device agrees on baud rate, parity, and stop bits; a settings mismatch corrupts every frame, not just some of them.
4. Inspect shield grounding and reroute cable away from variable frequency drives and power conductors.
5. Swap or reseat suspect transceivers and connectors last, once the cabling checks clean.

Because a failed CRC is discarded silently, the master's statistics are your instrument: watch the timeout and retry counters per device. One device failing while its neighbors stay clean points at that drop's stub, connector, or transceiver; every device failing points at the trunk, the master's own port, or shared timing. A gateway that polls the serial network and publishes data upstream will usually expose these counters, which is worth checking before dispatching anyone to site, as covered in the guide to connecting Modbus devices to cloud SCADA.

What the CRC Does and Does Not Guarantee

The CRC tells you the bytes arrived as sent; it does not tell you they came from the right device or that they mean what you think. If two devices are misconfigured onto the same address, both replies carry perfectly valid CRCs while the data is wrong. A frame with a valid CRC can still be rejected at the application layer with a Modbus exception code if its function or address is invalid. And like any sixteen-bit check, the CRC is probabilistic: it is extremely good at catching the burst errors serial lines actually produce, but it is a detection mechanism, not a mathematical guarantee. That residual uncertainty is one reason important write commands should be confirmed by reading the value back rather than trusting a clean exchange alone.

Frequently Asked Questions