Talk:Longitudinal redundancy check

Is the alogrithm correct on this page?

I think it should be (based upon http://www.automatas.org/modbus/crc7.html)

  lrc=0x00
  
  foreach char in string
  do
     lrc = 0xFF & (lrc + char)
  done
  
  lrc = 0xFF - lrc + 0xFF

Good question. Alas, there seems to be some confusion in terminology -- 2 groups of people using the same term "longitudinal redundancy check" to mean 2 slightly different things. Both groups agree that one starts with a long sequence of bytes, and from them generates a byte that is (typically) appended to the end of the transmission.

Arithmetic sum of all bytes (keeping only the least-significant byte):

Modbus : Add all the bytes into the sum, then LRC = 0xFF & ( -sum ).
MODBUS
ASCII Modbus: Add all bytes into the sum, then LRC = 0xFF & ( -sum ).
Modbus
Modbus
S.N.A.P. Scaleable Node Address Protocol "all bytes ... summed together ... the 8 bit result is the checksum byte. This is sometimes referred as Longitudinal Redundancy Check (LRC)

XOR of all bytes:

The people who form a 2D grid of bits, and do both transverse redundancy check and longitudinal redundancy check, so they can *correct* single-bit errors (and some 2-bit errors). (At least, I understand how this works with XOR -- I don't understand how it is possible to do this with arithmetic sum).
the Perl String-LRC "The Longitudinal Redundancy Check (LRC) is a one byte character, commonly used ... in STX-ETX bounded strings sent in financial protocols." Uses XOR (here spelled "^").
tech encylopedia: LRC "LRC (Longitudinal Redundancy Check) An error checking method that generates a parity bit from a specified string of bits on a longitudinal track. In a row and column format, such as on magnetic tape, LRC is often used with VRC, which creates a parity bit for each character."
[1] "Longitudinal Redundancy Check (LRC) is an error checking method that generates a parity bit from a specified string of bits on a longitudinal track. In a row and column format, such as on magnetic tape, LRC is often used with VRC, which creates a parity bit for each character."

Ambiguous:

our Modbus article mentions that "the ASCII format uses a longitudinal redundancy check checksum", but doesn't give any details as to whether this is "arithmetic" or "XOR".
"BasicCard 101(Part 1): Program Your First Smartcard " "the ISO/IEC 7816-3 standard. ... protocol includes longitudinal redundancy check (LRC) error checking."

Something completely different:

United States Patent 6832315, [2] "Multiply N by a numerical factor, in the present example the integer 19. This factor is known as the longitudinal redundancy check factor, or LRC. "

I wish most of these references leaned one way or the other. Then I could take the most common one and call it correct, and ignore the minority as a simple misunderstanding.

Does the NPOV policy require us to document both of the 2 common kinds of LRC? And then, to avoid confusion, update every article that refers to LRC to specify which kind of LRC is intended? --68.0.120.35 19:55, 6 April 2007 (UTC)[reply]

My theory is that the XOR algorithm is the 'true' algorithm. XOR is used to generate information to recover from data lost; see Standard_RAID_levels#RAID_5_parity_handling for example. On the other hand, the 2's complement summation, equivalent to repeated subtraction, is given as the simplest and extremely weak example on the Checksum article. I think this is a result of one, a Modicon documentation error, and two, widespread use of the Modbus protocol based upon said documentation. I recommend adding a sub section to this article to cover the Modbus version, and any history / explanation on the confusion. --Eet 1024 00:00, 30 August 2007 (UTC)[reply]

I have thought about it some more. When used on a 2D array of data, horizontally and vertically, either algorithm will allow you to 1, identify a corrupt byte, and if it's the only corrupt byte in either the column or row, easily correct it. If there are other corrupt data in same row and column, you might be able to use Algorithmics of sudoku to correct the errors. --Eet 1024 16:31, 30 August 2007 (UTC)[reply]

What is the "true" algorithm for LRC? The XOR one? You were talking about a different variation of LRC using arithmetic sum, wouldn't that be called LRC-Modbus or something? --Polarina (talk) 15:07, 31 December 2007 (UTC)[reply]

Both, IMO. Either can be used to catch some classes of errors in a 1 dimensional sting of bytes. Either can be combined with TRC to correct multiple errors. I don't know which one provides more information; I suspect both are equal for 2D. --Eet 1024 (talk) 01:16, 26 January 2008 (UTC)[reply]

11 years later and this article is still misleading. Shouldn't the various algorithms be presented instead of claiming to be authoritative? 72.75.205.29 (talk) 04:18, 21 November 2019 (UTC)[reply]

As of 21 November 2019 (and 31 January 2020), both algorithms are presented, and referenced. ISO 1155 and IEC 62056-21. "Pseudocode" and "Other Forms". And, I agree. It is unclear to the point of meaninglessness. And the statement about the " independence of the bit streams" is entirely opaque unless you already know what it means. If there was a technical error, I might try to correct it. Since we are talking about impenetrable prose, I have nothing to offer. — Preceding unsigned comment added by 203.206.162.148 (talk) 07:48, 31 January 2020 (UTC)[reply]

Removal of the Java implementation

I'm removing the Java implementation from this article for numerous of reasons. A pseudo-code of the algorithm is already provided, the algorithm is trivial for software implementation and because the implementation is original research. --Polarina (talk) 13:45, 28 March 2008 (UTC)[reply]

Other Theory.

/// 2012.06.11 /// C# Code. /// from Edwards TurboPump Controller SCU-1600: Serial Communication LRC Logic. /// ex) Data (6bytes hexa): 02 30 30 31 23 03 /// LRC (1byte hexa): EC

public byte MakeLRC ( byte[] bytes ) { byte LRC = 0xff; for ( int i = 0 ; i < bytes.Length ; i++ ) { LRC ^= bytes[i]; } return LRC; }

LRC and ISO 1155

I'm a bit confused by the pseudo-code purported to come from ISO 1155, but ISO 1155 seems to specify the XOR version (not the arithmetic sum + complement version) of LRC. Am I missing something?--GrafZahl (talk) 21:14, 8 December 2021 (UTC)[reply]

Yeah, looks like the pseudo-code was changed in this edit. I think this is simply wrong.--GrafZahl (talk) 21:48, 8 December 2021 (UTC)[reply]