Modbus ASCII - Probability of LRC Errors Going Undetected

T

Thread Starter

Ted Bunnell

Modbus ASCII uses LRC error checking. I beleive it is possible for a message to have a valid LRC error check but the bits inside the message have actually been changed. Is this possible and if so, what is the probability that this can happen? Also, assuming Modbus RTU with CRC error checking can be used, how much better would the error checking be? The CRC calculation is much more in depth. The application behind this question is a spread spectrum radio based SCADA system where the radio signals are not the best in certain areas and many messages become garbled.
 
Modbus ASCII has an LRC suffix for error checking, which is 2-bytes sent immediately before the CR-LF bytes at the end of a Message.

Each byte is a digit of the one-byte LRC total calculated, then converted to ASCII.
So each LRC byte only has 16 possible values, hex 30 to 39 for digits 0-9, and hex 41-46 for digits A-F

Therefore, there are only 16 X 16 = 256 possible LRC combinations.
And the probability of randomly getting the right LRC is 1/256 or 0.39%

Modbus RTU used 2 full bytes for the CRC (each byte can have 256 possible values)
So the probability of randomly getting the right CRC is 1/(256x256) or 0.0015%

So, yes, CRC error checking is better than LRC.
 
J

Jerry Miille

Without a doubt, use Modbus RTU with CRC error checking. I do not have the numbers to quote in front of me (but they are out there on the net) but CRC is orders of magnitude better than a simple LRC error check. Use Modbus RTU if at all possible.

Jerry Miille
 
C

Curt Wuollet

It should also be said that if you are seeing either LRC or CRC errors it may be a bad place to use radio.

To put your question in context, there is a certainty of undetected errors if your error rate is high and you use the link enough. With either CRC or LRC.

Regards
cww
 
L

Lynn August Linse

Do keep in mind that the radio probably is 'packet-based' and probably includes either a 16-bit or 32-bit CRC. So in truth your error estimate is some multiple of the radio-system error and 1/256 mentioned above.

If you wish to force someone to support Modbus/RTU, the LRC weakness is a nice whip. However, it is probably a moot point with a modern error-detecting (& possibly correcting) radio system.
 
B

bob peterson

> Modbus ASCII has an LRC suffix for error checking, which is 2-bytes sent
> immediately before the CR-LF bytes at the end of a Message.

> Each byte is a digit of the one-byte LRC total calculated, then converted to ASCII.
> So each LRC byte only has 16 possible values, hex 30 to 39 for digits 0-9, and hex 41-46 for digits A-F

> Therefore, there are only 16 X 16 = 256 possible LRC combinations.
> And the probability of randomly getting the right LRC is 1/256 or 0.39%
>
> Modbus RTU used 2 full bytes for the CRC (each byte can have 256 possible values)
> So the probability of randomly getting the right CRC is 1/(256x256) or 0.0015%

> So, yes, CRC error checking is better than LRC.

really?

Think about it. There are only 256 possible combinations of LRC that indicate a correct checksum. However, there are still 256X256 possible combinations of the 2 character LRC. To get an LRC that was wrong but both a valid LRC, AND have the actual data randomly corrupted in such a way as to have the wrong LRC indicate the corrupt data was actually correct, is a very remote thing.

I will grant CRC is better, but both will catch just about every error.

Keep in mind as well that in Modbus ASCII, only 16 valid ASCII characters are accepted as data in the packet within each byte. If an error causes an invalid character to appear, the emssage will be rejected.
 
I agree there are still 65536 possible combinations of the 2 bytes in the LRC, if there is an error in the bits of the LRC itself. If the error is elsewhere in the message, then there are only 256 possible combinations of a valid 2 character LRC.

The LRC is calculated from the total sum of all the bytes in the message. Since the LRC is only 2 ASCII characters calculated from the two's complement of the total, the total must only be one byte. Therefore, the total to use in the calculation is determined by dividing the gross total by 256 and using only the one-byte remainder.

If there are errors in the message bits, the one-byte total would appear correct if the sum of all the errors add up to exactly 256. Then the remainder from dividing the total by 256 would be the same, and the LRC calculated would be the same.

So an error in just one message bit could not coincidentally calculate a correct LRC. This could only happen with multiple errors where the sum of the errors is exactly one-byte. Its even more remote for incorrect bits in the LRC itself to coincidentally match up with incorrect bits in the message.

In Summary, It is very remote that an incorrect message would contain the correct LRC in Modbus ASCII. And even more remote for an CRC in Modbus RTU. I agree, both will catch pretty much every error.
 
T
It's been 25 years since my college probability class... This SCADA system is continuously polling 24x7x365. Considering each site is polled approximately 2 times per minute, we average just over a million polls per site per year. If we have an error rate of just 0.001%, we have 10 errors per year. This could explain what we are seeing in the field. I am not sure if the radio system will even support RTU due to its strict timing requirements, but if the probability of error is magnitudes greater, I think it is worth a try. This is much easier (cost and labor) than trying to replace/redesign the radio system. Your feedback is appreciated. Comments?
 
I'm not an error-checking-and-correcting expert, but I do know there is much more to error checking than the number of possible check values.

Error mitigation includes knowing the failure modes and providing the best coverage. The move to CRC from LRC (aka checksum) was done to the XMODEM protocol many moons ago, for the reliability reasons. (see Wikipedia entry for XMODEM)

For Example: Notice with LRC, it just takes a second incorrect high bit to make a single high bit error disappear.
 
L

Lynn August Linse

Another thing to consider - a serious 'flaw' in use of Modbus RTU or ASCII for a packet radio system is that it is not possible to aboslutely match a response to a request, therefore it is possible to mis-apply data, which can look like a bad LRC/CRC was missed.

Simple example:
1) poll slave #1 for 20 regs (expect 40-byte response)
2) time-out request #1
3) poll slave #1 again, but for 20 DIFFERENT regs
4) receive a response from slave #1 with 40-bytes of data.

At this point it is impossible to know if those 40 bytes are an abnormally delayed response to poll #1, or a fresh response to poll #2. Packet radios - especial ones doing auto-mesh/routing - can cause weird delays in message delivery.

The only trick I've seen is to make sure all blocks polled from the same slave are different sizes, so in the above example, poll #1 could be 20 regs, but force the 2nd poll to same device to be 21 regs. This way the response would be either 40 bytes or 42 bytes.

However, this only works if the host aggressively detects the size mismatch - some host ignore if more data than expected is seen.
 
Top