J1850 CRC8 Generating incorrect checksum

I created the CRC calculation myself, I get the correct CRC, BUT no matter what i do, it comes out on the next massage.  so data and CRC don't match.   No matter what i do with the calculation order.  

If you make your own CRC calculation, you cannot pick the values from the GPOUT/JPOUT channels, these are updated when the GFOUT/JFOUT are triggered. 

You'd need to calculate from the math channels going to the CAN parameter channels to have parameters and calculation match. 

I also had this issue once, changed the bit length of the CVC into 3 bit instead of 4 bit, kept the same start bit, then it worked for the assigment below

Maybe this will help.

I have done some more investigation of this.   It appears when the PGN is part of the checksum the incorrect checksum is generated.   I setup a simple can loop with all zero data and only changed include PGN or not.    with out PGN included the checksum is correct.    The example below generates CRC of 57 (0x39)  The PGN is 0xFFA1

If  I plug this data to any online CRC8_SAE_J1850 D1  seed =0XFF XOR = 0xFF calculator I get the correct checksum of 0xC3  which agrees with what i expect on the receiving end. Oddly when i read this with the loopback it passes with good checksum of 0xC3  as you can see in the example code  does passing as good bad data.  What am I doing wrong in my example?

Correction my my post: ( i cant find a way to edit the post)

"If I plug this data to any online CRC8_SAE_J1850 D1 seed =0XFF XOR = 0xFF calculator I get the correct checksum of 0xC3 which agrees with what i expect on the receiving end. Oddly when i read this with the loopback it passes with good checksum of 0xC3 as you can see in the example code does passing as good bad data. What am I doing wrong in my example?"

Should read:

"If I plug this data to any online CRC8_SAE_J1850 D1 seed =0XFF XOR = 0xFF calculator I get the correct checksum of 0xC3 which agrees with what I expect on the receiving end. Oddly when I read this massage with the loopback, it passes with checksum of 0x39  as you can see in the example code, and the CAN trace. So it its passing data with incorrect checksum. What am I doing wrong in my example?

In the printscreen from the online calculator, it looks like you have entered the PGN along with the data.

The CRC channel has a property for either including the complete identifier, or only using the data field.

If you need the PGN included, you could use the seed for this. But since the PGN is two bytes, you'll need to make an offline calculation first. 

Gustav,

I have selected to use the identifier in my example code. My target is looking for the PGN as part of the calculation.

What does the Algorithm do when that is set to YES? 

Does it use the entire "18FFA121"  or just the PGN  "FFA1"  identifier?

I tried adding the entire identifier  in the online CRC calculator and I was not getting the same checksum as the IQAN algorithm with my example code.

Is this documented somewhere?

thanks

"Include identifier" means the full identifier, four bytes in the case of a 29-bit identifier. 

As you only need the PGN, you can use an offline calculation to calculate CRC over these two-bytes. Use the seed you should use (0xFF), but omit the final XOR from this calculation. 

In your case, that should give you 0x75 as the seed, enter this as seed for the CRC channel in IQANdesign, and choose no on include identifier. 

Fore anyone else reading the post, here is a link to the CRC calculator mentioned in the post.