Anybody mess with the CAN Commanded Torque Message ID 0x1D4?

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

TheEvKid

Member
Joined
Mar 19, 2012
Messages
6
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!

Thanks!
 
No. I only observed it and guessed that it was filtered motor amps. How were you able to identify it as Commanded Torque? Do you have definitions of any of the others?
 
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 trying to break this CRC algorithm.

Any suggestions???

TY!
 
CRCs aren't used to encrypt, but whatever :p

Can you provide a sample data packet (preferably several) to look at?
=Smidge=
 
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 :

F7 07 00 00 07 44 00 D0
F7 07 00 00 47 44 00 17
F7 07 00 00 87 44 00 DB
F7 07 00 00 C7 44 00 1C

F7 07 00 00 07 44 30 70
F7 07 00 00 47 44 30 B7
F7 07 00 00 87 44 30 7B
F7 07 00 00 C7 44 30 BC

Any suggestions regarding the calculations of the last byte?

Does anyone have a binary image of either the VCM, or the motor controller with a communication log involving the controller image?
 
The 3-CAN Logs of a "short Drive" show 29,000 sequential EV:1D4 commands (original LEAF firmware).

While moving, the D8 byte values "splatter" over essentially all 0x00 to 0xFF values.

Note that 1DA and 1DB have similar "Security" bytes in D8.

See: http://www.wwwsite.com/puzzles/cando/" onclick="window.open(this.href);return false;
 
TheEvKid said:
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 :

F7 07 00 00 07 44 00 D0
F7 07 00 00 47 44 00 17
F7 07 00 00 87 44 00 DB
F7 07 00 00 C7 44 00 1C

F7 07 00 00 07 44 30 70
F7 07 00 00 47 44 30 B7
F7 07 00 00 87 44 30 7B
F7 07 00 00 C7 44 30 BC

Any suggestions regarding the calculations of the last byte?

Does anyone have a binary image of either the VCM, or the motor controller with a communication log involving the controller image?

Before spending a lot of time trying to crack the algorithm, did you try to see if you are even able to insert a message and get a response? You can just record a message at some torque setting, then send the exact same message later to see if you launch the car into you garage wall. I suspect even if successful, it will only be for a ms or two before the VCM sends it's next update.
 
I know next to nothing about CAN messages, but those don't look like full messages to me... and doesn't a full message already have a checksum field? Why would they waste data bandwidth adding an 8-bit checksum to a message that already has a 16-bit checksum?

Plus, looking at those numbers, I see some fun patterns (Just the last 4 bytes shown);

00000111 01000100 00000000 11010000
01000111 01000100 00000000 00010111
10000111 01000100 00000000 11011011
11000111 01000100 00000000 00011100

00000111 01000100 00110000 01110000
01000111 01000100 00110000 10110111
10000111 01000100 00110000 01111011
11000111 01000100 00110000 10111100

Doni't ask me what it means, though! :lol:
=Smidge=
 
In case anyone still cares about the 8-bit CRC in the Leaf's ID 0x1D4 CAN packets, my colleague Coulomb and I have reverse-engineered it. We used the excellent method described in New Zealander Greg Ewing's awesome paper, "Reverse-Engineering a CRC Algorithm".
http://www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html

The polynomial is 0x85 using left shifts. It takes the bytes in little-endian order [Edit: in the order transmitted] and the initial value and final XOR are both zero. The only place that I can find that this polynomial has been used before is in a Nintendo game controller.

We'd be very interested to know if anyone has any evidence that this actually contains a torque command from VCM to TMI. It looks to us like telemetry going the other way. We'd also be interested if anyone has any theories about what ID packet does contain the torque command.
 
weber said:
In case anyone still cares about the 8-bit CRC in the Leaf's ID 0x1D4 CAN packets, my colleague Coulomb and I have reverse-engineered it. We used the excellent method described in New Zealander Greg Ewing's awesome paper, "Reverse-Engineering a CRC Algorithm".
http://www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html

The polynomial is 0x85 using left shifts. It takes the bytes in little-endian order and the initial value and final XOR are both zero. The only place that I can find that this polynomial has been used before is in a Nintendo game controller.

We'd be very interested to know if anyone has any evidence that this actually contains a torque command from VCM to TMI. It looks to us like telemetry going the other way. We'd also be interested if anyone has any theories about what ID packet does contain the torque command.

Thank you so much for this. Seriously. I'm going to use it to "tune" my leaf. Oh yes. :)
 
If we have enough information to make an inverter go to regen mode, then one could buy a used Leaf motor and inverter drive it with an ICE engine to quick charge at up to 30kW. I have seen motor/inverter for around $1500, with small ICE engine at $500 it would possible to have emegency/portable quick charge for under $3000. A connection to the HV lines will be needed on that Leaf, plus a way to trick the Leaf into believing it is OK to regen.
 
Back
Top