What the CRC proves—and what it cannot
A Modbus RTU application data unit contains one unit-address byte, a function/PDU, and two CRC bytes. CRC-16/Modbus begins at FFFF, XORs each payload byte, shifts right with polynomial A001, and transmits the final low byte before the high byte. The algorithm and wire order follow the Modbus Organization’s Serial Line Protocol and Implementation Guide V1.02.
A matching CRC only establishes internal frame integrity under that algorithm. It does not prove the capture has the correct boundary, address, baud/parity, register map, byte/word order, engineering scale, permission, or safe command. “Repair CRC” replaces only the final two bytes; it cannot repair corrupted payload data. Compare every request with the device manual.
Addresses and common functions
Protocol addresses are unsigned zero-based values from 0 to 65535. Some documentation labels the first coil as 00001, first discrete input as 10001, first input register as 30001, and first holding register as 40001. Thus holding-register reference 40108 conventionally maps to PDU address 107 (006B), but vendors use inconsistent notation. The builder always shows the transmitted PDU address.
Functions 01/02 read packed bits; 03/04 read 16-bit registers; 05/06 write one coil/register; 0F/10 write multiple coils/registers. Multi-byte PDU fields use big-endian order. Coil bits are packed least-significant bit first. Values spanning registers—including 32-bit integers, floats, and strings—have device-specific register/byte ordering and are deliberately not guessed. See the official Application Protocol Specification V1.1b3.
Requests, responses, and exceptions
Read requests contain starting address and quantity. Read responses contain a byte count followed by values. Single writes normally echo address and value; multiple-write responses echo starting address and quantity. An exception response sets the original function’s high bit and follows with an exception code, such as 02 for Illegal Data Address. The inspector checks these common shapes without claiming the server accepted a command.
Unit 0 is broadcast on serial line. Servers do not respond to broadcasts, and the guided builder restricts them to write functions. Addresses 248–255 are reserved. The raw inspector still displays captures using those addresses because diagnosis should not hide bytes.
RTU silence and line format
The serial guide defines a frame as a continuous stream separated by at least 3.5 character times; a gap longer than 1.5 character times within a frame makes it incomplete. Character duration includes start, data, parity when used, and stop bits. At baud rates above 19,200, the guide recommends fixed 750 μs t1.5 and 1.750 ms t3.5 values. The timing panel shows those recommended intervals and the raw character calculation.
The calculator does not open a serial port, detect RS-485 direction control, measure turnaround delay, or choose timeouts. RTU, Modbus ASCII, and Modbus TCP have different envelopes: do not append an RTU CRC to a TCP MBAP frame.
Frequently asked questions
Should CRC appear as high byte or low byte first?
The numeric CRC may be written as a 16-bit value, but Modbus RTU transmits its low-order byte first, then its high-order byte. The calculator shows both the value and wire bytes.
Why does register 40001 become address 0?
40001 is a conventional human reference for the first holding register. The protocol carries zero-based address 0. Some manuals already list zero-based offsets, so never subtract automatically without identifying the manual’s convention.
Can I send the displayed hex string from a text terminal?
Only if the program has a hexadecimal/binary send mode. RTU sends byte 0x11 as one binary byte, not ASCII characters “1” and “1”. Configure identical baud, data bits, parity, and stop bits.
Does this support every Modbus function?
The CRC lab accepts any valid-sized raw RTU frame. Structured decoding and the guided builder focus on eight common public functions and standard exceptions. Vendor-specific functions remain raw data.