Has anyone messed around with the CAN ID 0x1D4? This message contains the commanded torques request.I have a desire to command specific torque request from a laptop to see what is the actual torque at the wheels.The problem is that darn CRC checksum!!

Has anyone determined, or even got a clue of what CRC algorithm is used? I sure would like to hack this message just for grins!

Using CAN utils I have observed the torque request under normal operating conditions.Now I would like to create my own torque requests using the CAN utility.The problem is the checksum algorithm. I have not reversed engineered that CRC algorithm yet.

My suspension is Nissan uses this CRC checksum to encript the message. They may also use this type of algorithm in other messages. I have not checked.

I am guessing you are guessing that the last byte is the crc. I assume you're tried basic summing and summing after applying an XOR? Beyond that, the next level usually involves a rolling lfsr but given the high error rate of the can bus (due to collisions) I really doubt they would go there. The main reason for the crc is to prevent accidental wrong messages due to the same collisions.

What made you think it is a torque command rather than just a torque message?

I have logged the CAN traffic while applying a load to the vehicle, and wide open throttle. I watched the torque command increase to the maximum as long as there was a heavy load. When the load decreased, the torques command decreased as well. I have reverse engineered most of this command (0x1D4). But I cannot solve the byte 8 (last byte). I know there is a rolling counter, and with nothing else changing, as the counter steps, the checksum(CRC)...the last byte changes too.

Here is some examples(torque not determined), the only changes are the counter(0,1,2,3) which is located in the two MSBs of lower nibble :