I am trying to communicate with the canbus but the calculated CRC does not seem to conform to the Bosch Can 2.0 standard (http://esd.cs.ucr.edu/webres/can20.pdf).
Notes:
I can read all messages from velbus without problems (ignoring CRC)
I can also send messages and receive them in my own hardware modules (using standard CRC)
I cannot sent messages to velbus devices (USB interface)!
Used components PICHJ128 family (Microchip) with integrated ECAN module + MCP2551 transceiver.
I am not really sending to the Velbus USB module. I am actually sending normal Canbus frames directly on the velbus (just as any velbus module does). I am just using the USB module for easy logging (VelbusLink).
I just looked at the protocol description and the document describes a CRC that uses a two’s complement. The standard canBus CRC should be, to my knowledge, a polynominal calculation. Does that mean that velbus is NOT following standard canBus 2.0 standard?
Velbus follows the CAN bus standard except for error counters (they get increased faster than the standard defines it). Now, I’m unsure why the CRC is not what you expect it to be, I’ll have to pass this along to the hardware engineers.
The document I’ve linked does not operate on CRC level, but rather on a higher level, and is intended for use with a USB module. I’ve linked this because you’ve mentioned ‘I cannot sent messages to velbus devices (USB interface)’
I finally found out that my problem was not caused by a CRC error, but by a small deviation from the 16K6 bitrate (only somewhere around 1% !). This seems odd because canBus was build to be quite tolerant about that (bit stuffing guarantees a slope every 5 bits allowing resync). Maybe the ‘synchronization jump width’ is set to 0 or not implemented on the velbus modules?
Anyway, this will force me to abandon the PIC internal RC clock oscillator on my hardware and switch to an xtal based oscillator. On the Velbus USB module an xTal of 20MHz is used. From 20MHz it seems impossible to get at exactly 16K6 canBus bitrate. Am I right about this, and is the exact bitrate 16K666 or am I still missing something? (I know this is only about 0.4% deviation but without in frame resync …)