Help with using for CRC-9 (not-byte-sized)

[smarek]

To start with, should this library be usable with CRC algorithms that operate on bits instead of bytes (eg. nor data nor result is byte-sized) ?

If so, i'd appreciate help with configuration for CRC-9 per ETSI DMR specification
Page 146, section B.3.10, https://www.etsi.org/deliver/etsi_ts/102300_102399/10236101/02.05.01_60/ts_10236101v020501p.pdf

Polynomial in normal form is 0x59 (bits 9,6,4,3,0 set is 0x259, removing MSB bit then 0x59)
From formula, the CRC result should be inverted, however same document (page 144, section B.3.8 CRC-16-CCITT) shows the inversion polynomial for CRC-16-CCITT, and in your config of the same no inversion is configured ( https://github.com/Nicoretti/crc/blob/master/crc.py#L387 )

I've tried to get it working by using this config, which produces incorrect result

CALC: CrcCalculator = CrcCalculator(
        configuration=Configuration(
            width=9,
            polynomial=0x59, 
            init_value=0x00,
            reverse_input=False,
            reverse_output=True,
            final_xor_value=0x00,
        ),
        table_based=True,
    )

Testing data are for example

bitarray('000000010000000000000000000000010000000100000000010011010000000001001101000000000100011100000000010101000000000000101110000000000000000')

This is 135 bits of data, resulting CRC9 should be either 409 or 102

[Nicoretti]

Hi @smarek,

generally the CRC output should be configureable on a bit size level. From my point of view at lest the bit sizes
[8, 64] should work fine as output widths.

Regarding the input data, I see a single byte as the smallest unit which is expected to be feed into the CRC calculation
(from the client code).
I personally don't plan to add support for feeding single bits into the CRC calculation from the client code.
If you have an idea (concept) or PR for this feature, I am open to discuss if and how we could add it.

best
Nico

P.S. happy holidays

[smarek]

Hi @Nicoretti

thank you for reaction, but I think you've missed my point, the CRC-9 is not 9-bit sized just when producing final output, but the input is also not byte sized (135 bits) and i've seen in your code, you assume that the number of operations is // 8 meaning you'll miss few bits, and I'm afraid there are more similar assumptions in your code.

Or should I understand it so that if I pad the input with zeroes it should not change the calculation output?

Anyway you're not supposed to change anything, I just wanted to get clarification, on whether you think your code should be able to handle odd sized payloads and produce odd sized crc result, or not.

Similar project, where eg. CRC-3/CRC-4/CRC-5 and other odd sized calculations are supported by default, is https://sourceforge.net/projects/crccheck/files/
But I don't think you should change anything, unless you want to support similar algorithms as well.
And if you'd want to, there is self-test (see configuration of properties _check_data and _check_output) in there, so it should be really easy to unit-test and gradually add support for some of the algorithms, https://sourceforge.net/p/crccheck/code/ci/default/tree/crccheck/crc.py#l280

Also wish you nice and pleasant holidays, cheers!

[Nicoretti]

Or should I understand it so that if I pad the input with zeroes it should not change the calculation output?

No wasn't meant that way. I wrote the crc processing/calculation code quite a long time ago.
I need to read up on it again, but you are definitely right about that only chunks of 8 bits (1 byte) are supported as input.

So this must hold true for the input: amount_of_bits(input) % 8 == 0

I thought though the supported output size should be "arbitrary", but not 100% sure without checking in detail.

In any case, I have created #26 to track the "arbitrary" bit width issue you pointed out. I must say though, that
I'm currently focusing on other things. So I don't think I will be able to address this issue any time soon.

best
Nico

[Nicoretti]

Status quo should hopefully got clarified in the discussion above, the missing support for all crc widths is tracked in #26