English is currently available.
Modbus DISCUSSION
I am writing a Modbus RTU master on a microcontroller. For the request 01 03 00 00 00 0A an online calculator shows 0xCDC5 for "CRC-16/MODBUS", but the slave only answers when I append the bytes as C5 CD. Another calculator labelled just "CRC-16" gives a completely different number.
What exactly are the parameters of the Modbus CRC, and why is the byte order the opposite of the register data in the same frame?
The Modbus RTU CRC is a 16-bit CRC with these parameters: polynomial x^16 + x^15 + x^2 + 1 (0x8005), processed least significant bit first, which is why code uses the reflected constant 0xA001; initial value 0xFFFF; no final XOR. It is calculated over every byte of the frame from the slave address to the last data byte.
"CRC-16" on its own names a family. CRC-16/ARC uses the same polynomial with an initial value of 0x0000, and the CCITT variants use polynomial 0x1021, so they give different results for the same bytes. Pick the entry explicitly labelled MODBUS.
The bitwise algorithm is short. Start with crc = 0xFFFF. For each byte: crc ^= byte, then repeat eight times: if the lowest bit of crc is 1, shift right by one and XOR with 0xA001, otherwise just shift right by one. After the last byte, crc holds the result.
For your frame 01 03 00 00 00 0A that gives 0xCDC5. A second value to test against: 01 03 00 00 00 02 gives 0x0BC4, transmitted as C4 0B.
The byte order is simply defined that way: the CRC is appended low byte first, then high byte, while 16-bit register addresses and values in the frame are sent high byte first. So 0xCDC5 goes out as C5 CD.
It looks inconsistent, but it fits the LSB-first CRC arithmetic and has a useful consequence: if the receiver runs the same CRC over the whole frame including the two CRC bytes, the result is 0x0000 for an intact frame. That gives a simple check without separating the CRC from the data first.
On a small microcontroller the bitwise loop costs eight iterations per byte, which is fine at 9600 baud but adds up at higher rates or with long frames. The usual alternative is a lookup table of 256 16-bit entries (512 bytes of flash), and the update becomes crc = (crc >> 8) ^ table[(crc ^ byte) & 0xFF]. Both methods must give identical results, so test the table version against the known frames above.
Check the CRC of a received frame only once the frame is complete, and discard the frame silently on a mismatch; a slave must not reply to a corrupted request.
