Wrong CRC implementation?

[decontamin4t0R]

Hello,

after testing the block transfer, it seems like the CRC-Checksum is calculated in a wrong way.
You use crc_hqx for calculating the checksum, which uses x16 + x12 + x5 + 1 as the polynom. However, in my CiA 301 specification, in section 9.2.2.2.16, the polynom is x^16 + x^15 + x^5 + 1... This complete CRC stuff is pretty messy. If you would want a true CRC-CCITT implementation, you would need to initialize _crc with 0xFFFF and not 0.
My "bought" CAN-Nodes to which I communicate all use the CRC-16-ARC (as on https://crccalc.com/)...

[christiansandberg]

Maybe they changed it? CANopenNode uses the same:
https://github.com/CANopenNode/CANopenNode/blob/master/stack/crc16-ccitt.c

[decontamin4t0R]

The current specification from www.can-cia.org actually uses the CRC-CCITT version, but my documentation is Draft from 2000 :D...
So not an issue on this end, more that my nodes use an outdated protocol specification.

[christiansandberg]

I have given up on keeping the code clean from manufacturer specific hacks. If you have some suggestion on how to handle these nodes I’m all ears. Maybe a possibility to disable CRC or bring-your-own-algorithm.

[decontamin4t0R]

I was thinking about adding a prop to SDOClient with the preferred crc implementation. However, afaik python itself only supports the ccitt version, so anything else would require a new dependency like crccheck...

[christiansandberg]

Due to pip dependency handling I try to avoid adding dependencies if possible. I did a solution in #157 though where I recreated the CrcXmodem class API from crccheck and made it possible to replace it with some other class from that package if needed.

[decontamin4t0R]

Very nice!