CRC Parameter

chuck emmons 8 years ago in IQANdesign updated by Anders Båth 7 years ago 14 1 duplicate

Is there a way to calculate an 8 bit crc for all of the parameters in a frame?

Duplicates 1
The use of a checksum in the data field of the CAN message is a feature that could be used if e.g. J1939 is going to be used for some safety related communication, where the checksum built into CAN itself is not considered to be sufficent.

What you can do today is to read out all the 8 bytes of the JFIN as individual GPIN channels, as integers, and use this for your checksum.
You would then have to use math channels to read these GPIN channels and make the J1939 scaling and offset that is normally done in the JPIN. This way you do not get the benefit of the built in J1939 scaling in the JPIN channel, but it is doable.

This workaround could be ok if your checksum is quite simple, like a simple addition of all 8 bytes. But if the checksum is more complex, for example a CRC8, then a much nicer solution would be to have a built in function for making this check.

What we are thinking of as a solution, that would me more easy to use, is to add support for CRC check/generation for GFIN/GFOUT and JFIN/JFOUT, and have it as a propery on the GFIN/GFOUT and JFIN/JFOUT.

There is no built in function for this in version 4.05, but there will be one for JFIN/JFOUT that is planned in version 4.06

The APPOUT channel used for safe MC3-MC3 communication has it, and the there is the option to use the built in checksum in the TSC1 channel.


Moved to ideas since this will become a new feature.

Unfortunately we have to use GFIN and GFOUT. I was hoping there would be a way to create a crc using function blocks.


The CRC feature planned for IQANdesign 4.06 will also be available on GFIN and GFOUT. At first we will be supporting two CRC methods; SAE-J1850 CRC-8 and J1939 standard checksum.

SAE-J1850 CRC-8

SAE-J1850 uses an 8 bit CRC checksum. The checksum is calculated over the CAN address and data. The CRC algorithm uses an initial value of 0xFF and the polynom below. The result is then xor:ed with 0xFF.

Optionally a CVC counter is positioned before the CRC byte in the frame. When using a CVC counter it is also included in the calculation of the checksum. Set CVC length to 0 to exclude the CVC counter.

J1939 standard checksum

This checksum method is used for most standard J1939 messages that supports checksum (one exception is TSC1). The checksum includes a counter and is calculated according to:

Checksum = DataByte[0] + ... + DataByte[6] + CVC & 0x0F + CanId[0] + ... + CanId[3]
DataByte[7] = ((Checksum >> 4) + Checksum) & 0x0F + (CVC << 4)
CVC = Message counter (Cyclic Validation Counter)

This is good news. J1850 CRC 8 is exactly what I want. When will 4.06 be released?

4.06 is currently planned for release in December.

I would love to test the J1850 in a beta version. Do all the parameters in the GFIN or GFOUT have to be 8 bits?


This feature is now available in IQANdesign 4.06.

In 4.06 I do not see a value in the CRC channel when using Measure or Simulate. Do we have to look on the CAN bus?

The CRC value is not exposed as channel value since it is not useful in any calculations. Instead the CRC channel only works as a placeholder within the frame in/out channels.