Author Topic: CRC  (Read 8223 times)

Offline tkane

  • PLUS+1 Developer
  • ***
  • Posts: 15
  • Karma: +2/-0
« on: October 27, 2011, 02:39:14 PM »

Has anyone idea how to calculate a CRC? I tried to implement parameter checing between display and controller.

Offline Marbek_Elektronik

  • PLUS+1 Guru
  • *****
  • Posts: 352
  • Karma: +8/-0
    • Marbek Elektronik
« Reply #1 on: November 20, 2012, 11:15:26 AM »
why do you want to do this?
CAN networking has hamming distance 4!
The data are checked allready!
Best regards,
Marbek Elektronik, Dipl.-Ing. Bernd Konrad
Dienstleistung, Entwicklung, Herstellung

Offline tkane

  • PLUS+1 Developer
  • ***
  • Posts: 15
  • Karma: +2/-0
« Reply #2 on: December 14, 2012, 02:34:23 PM »
Because I store same parameters on the display and contollers.
I have to do version checking for parameters if CAN communication lose when I change parameters or if someone change controller.

I just want to calculate the checksum of parameters, but I do not know what would be the best way to do it


  • Guest
« Reply #3 on: December 14, 2012, 05:35:14 PM »
If you are certain a CRC is what you need, then read the Wikipedia article.
Specifically, the section which shows a basic computation of a CRC with a given piece of data and a specific CRC polynomial:
As for picking the polynomial, page 6 of this paper has a summary table, with good choices for certain data lengths:

However, as far as I know, the CAN communication in SDF products has a CRC in place to detect bit transmission errors.
So, the error types you'd be left with are:
1. Sending many bytes, so that you need to use more than a single CAN message in your GUIDE program.
The CAN wire comes loose, or is disconnected in the time between two or more messages.
2. Somebody replaces the controller with another one.
As I see it, #2 would have a fresh controller with the 'wrong' values.
Probably default values from your program, or whatever was stored in non-volatile memory.
Assuming you have a working CRC, all you'll get is a detection of the error.
(Recall that CRCs do not have any way of correcting the error, only detecting it.)
So, you'd still have to retransmit the 'good' values from the display.
It would be less work to not implement the CRC, and just have the controller talk to the display upon being booted up, and see if it has values in the ranges appropriate to your application.
For example, in a program I made, the CPU would get a paving depth from the display, in the range 20-50 mm, and ignored any values outside that range.
Error #1 is similar: you'd be able to detect that some of the values were not transmitted, but not be able to correct them, and wouldn't know which ones were missed.
However, if you're using a separate CAN message ID for each set of values, you'd know instantly which values were not sent:
Each message has a unique ID, and you'd be able to detect if message X hasn't been received within the last couple seconds.
(This is what I did, since you can use either 11-bit or 27-bit IDs for your messages, and this is enough IDs for thousands of different messages.)

So, I don't think a CRC is what you need.
Some simple timers and logic on each end would detect missed or bad data, and then you'd be able to retransmit accordingly.
Another piece you can add, is to simply retransmit whatever data you need, every couple seconds.
I did this a lot, and it works fine.
You can work out the math yourself, but if you're sending an 8-byte-of-data CAN message every five seconds, and your CAN bus is transmitting at 250k baud (I'm pretty sure this is the default in GUIDE), you'll have a very small increase in traffic load.