What Is the Modbus LRC Checksum?

Back to Blog

How the LRC Is Formed

In Modbus ASCII the LRC is a single byte computed by adding up the message bytes and taking the two's complement of the sum, so the check byte plus the running total wraps to zero. It is placed just before the carriage-return line-feed that ends the ASCII frame and, like everything in ASCII mode, is transmitted as two printable hex characters. The receiver recomputes the sum and verifies the result, discarding the message if it does not check out.

Because ASCII frames are delimited by an explicit colon start and CR-LF end rather than by timing, the LRC only has to protect content, not framing, which is handled by those delimiters. The overall structure of an ASCII frame and how it differs from RTU is laid out in the Modbus RTU vs ASCII transmission mode reference.

LRC Versus CRC and Where You Meet It

A longitudinal redundancy check is a sum-based check, and a sum is a weaker error detector than a cyclic redundancy check: some combinations of bit errors cancel out in a sum and slip through, whereas the CRC-16 catches burst errors far more reliably. This is the central technical reason RTU, which uses the CRC covered in the Modbus CRC-16 checksum reference, is considered more robust than ASCII on noisy links.

In practice you meet the LRC only on the legacy or specialized equipment that still uses ASCII mode, which is a small fraction of serial Modbus today. When troubleshooting such a link, remember that the LRC gives less assurance against undetected corruption than a CRC would, so persistent oddities on a marginal ASCII line deserve extra scrutiny. Neither checksum appears on TCP, which relies on the network as the Modbus TCP vs RTU comparison notes.

A Worked LRC Example

Take the common request to read ten holding registers starting at address zero from unit 1. The message bytes before ASCII encoding are the unit address 0x01, the function code 0x03, the starting address as two bytes 0x00 0x00, and the quantity as two bytes 0x00 0x0A. Summing them gives 0x01 + 0x03 + 0x00 + 0x00 + 0x00 + 0x0A = 0x0E. The LRC is the two's complement of that sum: invert 0x0E and add one, or equivalently subtract it from 0x100, giving 0xF2. The transmitted frame therefore carries the characters F and 2 just before the closing carriage-return line-feed.

The receiver's check is the mirror image: it adds every message byte including the LRC itself and keeps only the low eight bits. Here 0x0E plus 0xF2 is 0x100, which truncates to 0x00, so the frame passes. Any single corrupted byte changes the sum and the wrap-to-zero test fails. Working one example by hand like this is worth doing once, because it makes captures of ASCII traffic far easier to sanity-check when a link is misbehaving.

Checking the LRC in a Captured Frame

To verify a frame from a serial capture, take the printable characters between the leading colon and the closing carriage-return line-feed, pair them up into bytes, and set the final pair aside as the received LRC. Sum the remaining bytes, keep the low eight bits, take the two's complement, and compare against that final pair. If you do this often, a short script pays for itself, but the arithmetic is simple enough to do by hand for a single suspect frame.

Three mistakes account for almost every did-not-match result. First, summing the ASCII character codes instead of the byte values they encode - the LRC is computed over the underlying bytes, not the characters that carry them. Second, including the colon or the line ending in the sum; the delimiters sit outside the checksum. Third, forgetting to truncate the running total to eight bits before taking the complement. It also helps to remember that ASCII mode uses seven data bits on the wire per the Modbus specification, so an analyzer configured for eight-bit RTU will mangle the characters before you ever get to the arithmetic. How the pieces of a frame fit together is covered in the ADU and PDU structure reference.

What LRC Errors Tell You About the Link

A device that silently discards frames with bad LRCs looks, from the master's side, like a timeout: the request went out and nothing came back. So a rising timeout count on an ASCII link is often really a checksum problem in disguise, and the general approach to fixing a Modbus timeout applies, with the extra step of inspecting captured frames for check failures before blaming the device.

The pattern of failures narrows the cause. Occasional bad frames on an otherwise working link point to electrical noise, marginal wiring, or a baud rate at the edge of what the cable run supports - the same physical-layer suspects behind CRC errors on an RTU link. Every frame failing points instead at configuration: one end set to RTU and the other to ASCII, or mismatched parity and data bits, either of which turns every message into garbage no checksum can pass. And because a sum is a weak detector, a marginal ASCII link that mostly works deserves less trust than the same symptom on RTU - some corrupted frames will slip through undetected, so fix the physical problem rather than tolerating the error rate.

Frequently Asked Questions