TROUBLESHOOTINGJULY 2026 · 6 MIN READ

Modbus CRC check failed: the 5 real causes — and how to tell them apart

A CRC failure is a specific kind of bad news: the frame arrived, its structure even parses, but the math at the end doesn't agree. That narrows the suspects considerably — if you know what each one's fingerprint looks like.

01 03 14 00 E6 00 E7 01 90 00 FA 04 DC 00 03 09 C4 00 00 00 01 00 2A 3B 91
received CRC 3B 91 · computed 3A 91 — a single flipped bit, twenty bytes in

1 · Electrical noise

The most common culprit on a factory floor. A contactor pulls in, a VFD switches, a cable run shares a tray with three-phase power — and one bit flips mid-frame.

Fingerprint: sporadic failures on otherwise perfectly structured frames, often correlated with something mechanical happening. Received and computed CRCs differ by a small hamming distance.

Fix: shielded twisted pair with the shield grounded at one end, route away from power cables, ferrites on the worst offenders.

2 · Missing or wrong termination

An unterminated 485 line rings. Reflections superimpose on the signal and corrupt edges — mildly at 9600 baud on short runs, brutally at 115200 on long ones.

Fingerprint: error rate scales with baud rate and cable length. Everything works on the bench, falls apart at the far cabinet.

Fix: 120 Ω across A/B at both physical ends of the trunk (not on stubs, not on every device), plus bias resistors so the idle line has a defined state.

3 · Marginal clock mismatch

UARTs tolerate a few percent of baud error. Cheap slaves with RC oscillators drift with temperature — and sampling error accumulates along the frame.

Fingerprint: long frames fail more than short ones, and the corruption clusters toward the tail. Gets worse as the cabinet heats up through the shift.

Fix: drop the baud rate and see if it vanishes. If it does, the slave's clock is the problem, not your wiring.

4 · Your own tool split the frame wrong

The dirty secret of RTU: the spec separates frames by 3.5 character times of silence, but a PC operating system can't observe serial timing that precisely. If your tool splits purely on timing, it will occasionally glue two frames together or cut one in half — then compute a CRC over the wrong span and blame the wire.

Fingerprint: "failed" frames whose hex looks like a response with the start of the next request stuck to the end, or a frame of suspiciously wrong length. The devices are innocent.

Fix: use a tool that reframes with a CRC sliding window instead of trusting timestamps. (This failure mode is exactly why Fieldbench splits RTU frames with a hybrid silence + CRC-scan strategy.)

5 · Two masters on the bus

Someone left the SCADA polling while you debug, or a gateway retries behind your back. Two transmitters collide, bytes interleave, checksums die.

Fingerprint: bursts of garbage at a rhythm that isn't yours — usually the other master's poll interval. Frames from slave addresses you never asked for.

Fix: monitor the bus passively before transmitting anything. If traffic is already there, find its owner first.

The 5-minute triage

Listen first, talk second — passive monitoring reveals cause 5 instantly.
Halve the baud rate — if errors vanish, it's cause 2 or 3; check termination before blaming clocks.
Compare error timing with the plant — correlation with machinery says cause 1.
Read the failed hex — if it looks like two frames welded together, it's cause 4 and your tool owes you an apology.

Or select the frame and let the AI run this triage for you — it reads the received-vs-computed CRC distance, the frame structure and the surrounding traffic, then ranks the causes above with a checklist.