PEACLS error detection (and correction?)

I added error detection, it was in fact very simple and it seems to work very well.

I started playing with it, for example adding one bit of noise on the channel (in bold, scroll the listing).

Init=1 In=0000000000000000 Scr:10-0000000000000000 Sc2:10-0000000000000000  Out=0000000000000000 OK=U  
Init=0 In=0000000000000000 Scr:00-0000000000000001 Sc2:00-0000001000000001  Out=0000001000000000 OK=1  
Init=0 In=0000000000000000 Scr:00-0000000000000001 Sc2:00-0000000000000001  Out=0000000000000000 OK=1  
Init=0 In=0000000000000000 Scr:00-0000000000000010 Sc2:00-0000000000000010  Out=1111111000000000 OK=0
Init=0 In=0000000000000000 Scr:00-0000000000000011 Sc2:00-0000000000000011  Out=1111110111111111 OK=0
Init=0 In=0000000000000000 Scr:00-0000000000000101 Sc2:00-0000000000000101  Out=1111110111111111 OK=0
Init=0 In=0000000000000000 Scr:00-0000000000001000 Sc2:00-0000000000001000  Out=1111110111111111 OK=0  
Init=0 In=0000000000000000 Scr:00-0000000000001101 Sc2:00-0000000000001101  Out=1111110111111111 OK=0
Init=0 In=0000000000000000 Scr:00-0000000000010101 Sc2:00-0000000000010101  Out=1111110111111111 OK=0
Init=0 In=0000000000000000 Scr:00-0000000000100010 Sc2:00-0000000000100010  Out=1111110111111111 OK=0

The error is not detected immediately but the OK flag is consistently stuck to 0 afterwards.

What this means is : the epilogue of a packet should have 2 padding words to ensure the last data word has been correctly transmitted.

Another interesting aspect is the efficiency of the 2 prefix bits : even though they are not flipped during transmission, the reconstructed bits mismatch anyway ! So it does not matter so much that the prefix does not use the whole coding range, error detection occurs anyway and the carries help prevent all-0 words.

Even more interesting is the bit pattern of the altered reconstructed word: after 3 words, the output contains the inverse of the alteration ! Is this an opportunity for error correction ?

Further wiggling shows that it's a corner case, but finishing the packet with 2 blank words certainly detects multiple errors. Get the source code here.

Discussions

Thibaut wrote 10/28/2024 at 14:24

Maybe I had some confusion with PEAC w4 : it remains HD=1 when a "full one word" of 4bits comes : 1111... I don't know why, because double calculation with first or last word works well with Hamming Distance HD=2 except with 1111 words...

If you can clarify this border effect ? ( the carry with 0001+1111 gives the same CRC as for 00001111, with only 1bit toggle)

Great job nevertheless !

Are you sure? yes | no

Thibaut wrote 10/28/2024 at 09:01

Hi,

I remarked, playing with a PEACw4 that the Hamming distance (error unveiled) is HD=1 (notbbetter than a simple "parity bit")...

I found also, that at end stage of Log 64 (peac16x2), if you do the loop again for the last "word" (it coud be the first or an other), it seems, the hamming distance is greater !!

May be included in your error detection ?

Maybe i'm wrong (i'm not informatician), but if you can try with last calculated byte 00100001, it should have the same Checksum as if you take last byte 00110000 (with the sames bytes "before" in both case)... And doing 2 times the last calculation remove this behaviour !

Be kind to reply if you tested this, and if you can calculate the hamming distance on an example (for ex. 60bits length for this PEACw4) it could help some other people...

Have a good day;-)

Are you sure? yes | no

Line encoding with PEAC: it's alive.

TODO: scans

Discussions

Become a Hackaday.io Member