The current release (ver. 0.3) JANUS CRC implementation is incorrect, truncating a 16-bit CRC to 8 bits. Half a 16-bit CRC does not an 8-bit CRC make!

Some preliminary testing by Giovanni Zappa has showed that the current CRC catches about 98.5% of errors in the 56-bit JANUS packet, which isnâ€™t so bad, but far from ideal. It means that 1.5% if damaged packets are passed as error-free, which in some applications could be serious. We should therefore replace the existing CRC routine asap. Note that decoding all previous JANUS packets will return the wrong CRC result with the replacement CRC routine.

Choosing a polynomial for the 8-bit CRC is easy if we use a criterion like the Hamming Distance. But this may not be the 'best' choice for bursty noise that is likely to introduce many error bits if any at all, and other considerations (like what people are familiar with and trust) may be more appropriate.

See the attached file for a short discussion of options I know of.

## Is the Hamming Distance the best measure of a good CRC for JANUS?

Some preliminary testing by Giovanni Zappa has showed that the current CRC catches about 98.5% of errors in the 56-bit JANUS packet, which isnâ€™t so bad, but far from ideal. It means that 1.5% if damaged packets are passed as error-free, which in some applications could be serious. We should therefore replace the existing CRC routine asap. Note that decoding all previous JANUS packets will return the wrong CRC result with the replacement CRC routine.

Choosing a polynomial for the 8-bit CRC is easy if we use a criterion like the Hamming Distance. But this may not be the 'best' choice for bursty noise that is likely to introduce many error bits if any at all, and other considerations (like what people are familiar with and trust) may be more appropriate.

See the attached file for a short discussion of options I know of.

Ciao

John.

Reads: 161657