Modbus CRC-16 Check: Calculate the CRC and Verify an RTU Frame
Calculate a Modbus CRC-16 for an RTU read request, compare 0BC4 with C4 0B, and check a captured frame without adding a second checksum.
Modbus CRC-16 Check: Calculate the CRC and Verify an RTU Frame
A CRC calculator can show 0BC4 while a serial log ends the same RTU request with C4 0B. Both can be correct. One is the checksum written as a 16-bit number; the other lists its bytes in transmission order. Before treating a mismatch as a calculation error, check that distinction—and check exactly which bytes went into the calculation.
Consider an FC03 request to device 01, reading two registers from offset 0000:
| Part of the calculation | Bytes or value |
|---|---|
| Six bytes covered by the CRC | 01 03 00 00 00 02 |
| CRC as a 16-bit number | 0BC4 |
| CRC bytes sent after the request fields | C4 0B |
| Complete request, including CRC | 01 03 00 00 00 02 C4 0B |
Choose the input before comparing results
Enter 01 03 00 00 00 02 in the RTU CRC calculator. Its result is C4 0B, ready to append in that order.
The calculation covers every frame byte before the CRC. That includes device address 01 and function code 03. Register data alone is not enough, nor is a PDU that leaves out the device address. If you copied a complete frame from a log, separate its existing two CRC bytes first. If you are assembling a new request, use the bytes you have prepared so far, before adding the checksum.
Spaces separate the hexadecimal byte values; timestamps, TX: labels and other log columns are not part of the frame. Keep the original capture while cleaning up the input so you can spot a dropped byte or a request accidentally joined to its response. Any change to the device address, starting offset or quantity calls for a fresh CRC calculation.
Reading 0BC4 as two transmitted bytes
In the number 0BC4, 0B is the high byte and C4 is the low byte. RTU sends the low CRC byte first, which puts C4 0B at the end of the frame. The Serial Line Guide, section 2.5.1.2, specifies this order. It applies to the CRC field; it is not a reason to swap every pair of bytes in the request.
When two tools appear to disagree, look at their output conventions. A hexadecimal number on one screen and a pair of transmission-order bytes on another can represent the same checksum.
For an arithmetic check, start the CRC register at FFFF and XOR each input byte into it. Process eight right shifts per byte, XORing with the reflected polynomial A001 whenever the outgoing least significant bit is one. After the six input bytes above, the register contains 0BC4. The full procedure is in the Serial Line Guide, section 6.2.2.
Checking a frame that already has a CRC
Paste the complete 01 03 00 00 00 02 C4 0B into the RTU frame parser to inspect the request fields alongside the checksum result. To compare by hand, calculate the CRC of the first six bytes, put the result in transmission order, and compare it with the trailing C4 0B.
Running all eight bytes through the same CRC algorithm produces a remainder of 0000, or 00 00 when displayed as two bytes. That is useful for a deliberate whole-frame remainder check. Appending those zeros, however, would turn this eight-byte request into ten bytes. The calculator processes the bytes it receives; checking a checksum does not by itself check the frame length or field structure.
A matching CRC also says nothing about whether you chose the intended register. A request for the wrong address can have a perfectly matching checksum. Confirm the function, offset and quantity against the device manual; the register address guide explains how reference numbers such as 40001 relate to the offset in a request. If the response passes its CRC check but the decoded value looks wrong, first match it to its request, then check the data type, word order, scaling and units. The RTU walkthrough works through those checks using a read-only example.