What is the Modbus CRC polynomial?

Modbus RTU uses a 16-bit CRC with the polynomial 0xA001, which is the reflected form of 0x8005. The initial value is 0xFFFF and the low byte is transmitted first on the wire.

Why is the CRC byte order reversed in Modbus RTU?

Modbus sends the low byte of the CRC first and the high byte second. That means if your computed CRC is 0x4B37, the frame ends with 0x37 0x4B. Many validation failures come from sending the bytes in the wrong order.

Can I calculate Modbus CRC with software?

Yes. Most master libraries do it automatically, but you can also calculate it in Python, C, or any other language. A correct implementation must use the 0xA001 polynomial, a 0xFFFF starting value, and bitwise shifts with XOR operations.

What happens if the CRC is wrong?

The slave discards the frame. You usually get no response at all, which looks like a timeout. In practice, CRC errors on Modbus RTU are one of the main reasons for silent communication failures.

Does Modbus TCP use CRC?

No. Modbus TCP does not use the RTU CRC because TCP already provides error checking at the transport layer. The MBAP header replaces the RTU framing, so CRC calculation only applies to RTU and ASCII-style serial frames.

Can ModbusSimulator help test CRC problems?

Yes. If your RTU master is misconfigured, ModbusSimulator helps you isolate whether the issue is address handling, serial settings, or frame integrity. Once the simulator responds correctly, you know the basic frame format is valid.

Modbus CRC Calculation — Step by Step with Examples (2026)

Quick answer: Modbus RTU uses a CRC16 with polynomial 0xA001, initial value 0xFFFF, and low byte first transmission. If your checksum is wrong, the slave usually ignores the frame completely.

Why Modbus uses CRC

Modbus RTU runs over serial links such as RS-485 and RS-232. Those links can be noisy, especially on long cables or poorly terminated buses. CRC adds error detection so the receiving device can reject corrupted frames instead of acting on bad data.

Unlike Modbus TCP, RTU does not have TCP/IP transport checksums protecting the Modbus payload. The CRC is therefore essential. Without it, a single flipped bit could turn a valid register read into the wrong address or the wrong value.

The Modbus CRC rules

Length: 16 bits.
Polynomial: 0xA001 reflected form.
Initial value: 0xFFFF.
Transmission order: low byte first, then high byte.
Scope: all bytes from slave address through the last data byte, excluding the CRC bytes themselves.

How the algorithm works

The algorithm starts with 0xFFFF in the CRC register. It XORs each byte of the frame into the low byte of the CRC, then processes each bit. If the least significant bit is set, the register shifts right and XORs with 0xA001. If not, it just shifts right. That repeated bitwise process is what produces the final 16-bit checksum.

Worked example

Take a simple RTU request: slave 01, function 03, starting address 0000, quantity 0001. The frame bytes before the CRC are:

01 03 00 00 00 01

When the CRC is computed correctly, the final two bytes for this frame are commonly shown as 84 0A or as the 16-bit value 0x0A84 depending on how the result is displayed. The key point is the byte order: the low byte is sent first.

Important: Many tools display the CRC as a single 16-bit hex value. On the wire, Modbus RTU transmits the low byte first. If you swap the bytes, the slave will treat the frame as invalid.

Python example

Here is a straightforward CRC implementation that matches the Modbus RTU rules:

def modbus_crc(data: bytes) -> int:
    crc = 0xFFFF
    for byte in data:
        crc ^= byte
        for _ in range(8):
            if crc & 0x0001:
                crc = (crc >> 1) ^ 0xA001
            else:
                crc >>= 1
    return crc & 0xFFFF

frame = bytes.fromhex("01 03 00 00 00 01")
crc = modbus_crc(frame)
print(hex(crc))

To append the CRC to the RTU frame, send crc & 0xFF first, then (crc >> 8) & 0xFF.

How to check a bad frame

If you suspect a CRC problem, do this:

Capture the raw bytes from the master.
Remove the final two CRC bytes.
Run the remaining bytes through a known-good CRC routine.
Compare the expected CRC to the transmitted CRC.
If they differ, check byte order first and then the actual data bytes.

Common CRC mistakes

Mistake	What happens	What to check
Using the wrong polynomial	All frames fail validation	Confirm `0xA001` reflected form
Wrong initial value	CRC never matches vendor examples	Start with `0xFFFF`
High byte sent first	Slave discards the frame	Transmit low byte first
Including the CRC bytes in the calculation	Checksum is always wrong	Only compute over the payload bytes
Using TCP rules on RTU	Protocol mismatch	Remember that Modbus TCP does not use the RTU CRC

CRC vs timeout: how to tell the difference

A bad CRC usually produces no response from the slave. That looks exactly like a timeout at the application level. The difference is in the wire capture: with a CRC problem, the master sent bytes, but the slave intentionally ignored them because they failed validation.

If you see a timeout, do not assume the address is wrong immediately. Check the CRC, serial settings, and termination first. A valid-looking register read with a bad CRC is still a bad frame.

Testing with a simulator

ModbusSimulator helps here in two ways. First, you can verify that your master is building a valid RTU request and getting a proper response. Second, you can compare the raw frame bytes against a known-good simulator response so you know the stack works before introducing field wiring noise.

Stop guessing at RTU frames

Use ModbusSimulator to verify your polling workflow and isolate whether the issue is CRC, wiring, or register mapping.

Download ModbusSimulator

Frequently Asked Questions

Is Modbus CRC the same as CRC-16/IBM?

Modbus uses the reflected CRC-16/IBM style algorithm with polynomial 0xA001 and initial value 0xFFFF. In practice, Modbus RTU implementations refer to it as Modbus CRC16.

Why does the low byte come first?

That is part of the Modbus RTU framing convention. The checksum is stored little-endian on the wire even though people often display it as a 16-bit hex value.

Does Modbus ASCII use the same CRC?

No. Modbus ASCII uses a longitudinal redundancy check (LRC), not the RTU CRC16.

Can I use a library to avoid writing CRC code?

Yes. Most serial Modbus libraries calculate CRC automatically. But understanding the algorithm helps when debugging vendor examples, packet captures, or custom firmware.

What is the fastest way to debug CRC failures?

Capture the raw frame, compute the expected CRC with a trusted routine, and compare the two bytes at the end of the packet. Then check byte order before looking for deeper protocol issues.

Can ModbusSimulator validate my CRC?

Yes. If your master communicates successfully with the simulator, the request framing and CRC are likely correct. If it fails only on the field device, the issue may be noise or device-specific serial settings.

Modbus CRC Calculation: How the RTU Checksum Works