LEAF CANbus decoding. (Open discussion)

[Dala]

Made a fresh recording and found the following:
....
0X390: 8;04;00;00;03;00;80;00;C7
0X390: 8;04;00;00;03;00;80;00;D8
0X390: 8;04;00;00;03;00;80;00;E9
0X390: 8;04;00;00;03;00;80;00;FA
Byte 7 does not appear to be a checksum as noted in Kvaser db.
0x393: 8;00;20;00;00;20;00;00;03
0x393: 8;00;20;00;00;20;00;00;14
0x393: 8;00;20;00;00;20;00;00;25
0x393: 8;00;20;00;00;20;00;00;36
Byte 7 also does not appear to be a checksum as noted in Kvaser db.
....

Great findings, the CRC is actually a PRUN message, so two bits on both the 0x390 and 0x393 message are counters that go from 0->3 and repeat. These are very important for error code free transmission, so make sure you are generating these correctyl.

I revisited the database files, and made some changes to 0x393 and 0x390 for AZE0/ZE1
https://github.com/dalathegreat/leaf_ca ... 257868aa5f

[mux]

Excellent information, I am especially excited about using the Chademo discharge you mention. This is on my list to do as well. I am presently using a bank of lights, it gets bright and warm.

I am working on a GEN2 pack and running it standalone. It works and runs the car just fine. I use 1DB to manage cut off of charging at this point.

I am manually turning on the relays thru the relay block connector and I have the 12volt and ignition connections as noted.

I then use both the regular CAN data (0x1DB for current voltage/current, 0x1DC for allowable discharge current, 0x5BC/0x55B for remaining GIDs/SOC) and the engineering data (0x79B group 2 for cell voltages) to manage cutoff criteria.

I am using the 1DB and it provides live data during charge and discharge all the time. I have not looked at "allowable discharge". I am however reading 0x5BC/0x55B for remaining GIDs/SOC but it remains static at the value read when started up via ignition on. I have to cycle the ignition to get a fresh value.
The 79B commands capture data for cell voltage, shunts and temperature. I am also using the Group 3 commands for min/max/avg but these also do not refresh when running. I want to use these group 3 commands to determine battery discharge cut off and assist with charging as noted above currently using the 1DB command.

I note that the Leafspy pro app appears to exhibit the same behavior when connected to the pack only.

I need to make a fresh recording of the data exchange between the full car, the leafspy and the pack.

I added 11A (heartbeat) into my code last night using all 4 variations thinking that it might trigger a refresh.
0x11A 8 0 80 0 AA C0 0 0 67
0x11A 8 0 80 0 55 00 0 1 71 // commands from recording Al's Car
0x11A 8 0 80 0 55 40 0 2 BC
0x11A 8 0 80 0 AA 80 0 3 AA
I will test this today ... if it stops raining ... or at least slows down. The rainfall here is at least double the seasonal averages and the car is outside, have a a small river running down my drive way.

Thanks for the tip on the wake up, that of course makes sense, I will try that next and let you know.

P.S. I am planning to return to work on the Standalone OBC/PD charger this week if I can solve this issue.
Thanks for your continued support.

There's a pretty good chance the pack is in sleep mode then. You can check this on 0x55B byte 6[5:4]=10 (LB_REFUSE=ReadyToSleep). To get the pack out of sleep mode, you have to send VCM control state messages (0x1F2) byte 5. This byte essentially is a state machine with bits dedicated to certain drivetrain states. I don't know exactly what everything means yet, but you can at least get the pack in IDLE mode by setting 0x1F2 byte 5 to 0x1E. My hypothesis is that probably the 0x04 position (bit 2) enables the battery pack.

Make sure you generate the correct CRC and PRUN for this message as well.

[49thdiver]

the CRC is actually a PRUN message, so two bits on both the 0x390 and 0x393 message are counters that go from 0->3 and repeat. These are very important for error code free transmission, so make sure you are generating these correcty.

I do not understand PRUN & CRC. Are the counters in each nibble of byte 7 and summed with the CRC ?
I am not actually calculating the CRC with the leaf messages I am just using copying messages from recordings and assume the CRC is correct. ie
0x11A: 8;01;40;14;55;00;00;01;91
0X390: 8;04;00;00;03;00;80;00;E9
0x393: 8;00;20;00;00;20;00;00;03

The CRC calculation I am using on the RAV4 side of my system is simply :
Framedata would be set to "8;00;20;00;00;20;00;00"
for(i = 1; i < 8; i++)
{crc ^= framedata;}
Serial.print(" CRC = ");Serial.println(crc);

It does not create the same CRC as the 0x393 data above I have tried it with and without the length byte.
I would prefer not have to calculate a new CRC if I did not have to.

[49thdiver]

There's a pretty good chance the pack is in sleep mode then. You can check this on 0x55B byte 6[5:4]=10 (LB_REFUSE=ReadyToSleep).

I note on the Gen2 AZEO that PRUN data is on 0x55B byte 6[6:5] and the bits seems to toggle between 10 and 00 in all samples.

To get the pack out of sleep mode, you have to send VCM control state messages................ you can at least get the pack in IDLE mode by setting 0x1F2 byte 5 to 0x1E. My hypothesis is that probably the 0x04 position (bit 2) enables the battery pack.

I will try this hypothesis, I may have to sort out the CRC PRUN.
In the absence of understand the CRC I am inclined to send this frame captured from earlier car recordings.
0x1F2 8 64 64 64 A0 0 2C 1 81 it has bit 2 set in byte 5

I will see what I can come up with and report back.

[Dala]

I will make a quick youtube video on this subject. You actually have to keep in mind both MPRUN, CRC and CHECKSUM values. I will clean up the database files with my new findings soon (+ the video)

[49thdiver]

Thanks Dala, if you are updating the database You may want to add this.
However I do note that the 79B commands and answers are not part of the data set.
Is this information complied somewhere else other than the can spreadsheet.
This is my best guess, it does seem to work, but will need more run time analysis to confirm.

Minimum, Maximum and average cell data with the code showing the bit offset for clarity:

16 bits Group three, Line 1 byte 7 + Line1 byte5 = min ;;CellMin= (float)((line21byte7<<8)+line21byte5)/1000;
16 bits Group three, Line 1 Byte7 + Line 2 byte1 = max;CellMax= (float)((line22byte1<<8)+line22byte2)/1000;
16 bits Group three, line 2 Byte 2 + Line 2 byte 3 = avg; CellAvg= (float)((line22byte3<<8)+line22byte4)/1000;

[Dala]

Here is the video, it should explain MPRUN/CSUM/CRC enough for people to continue with reverse engineer cool builds:
https://www.youtube.com/watch?v=oENNNfy5GSM

I'll update the CAN database tomorrow, the reason 7## messages aren't there is because these .dbc files aren't designed for polling, only passive listening.

[nlspace]

Great video, thank you for sharing the definitions and the kittens.

[49thdiver]

That really helps thanks !!! Appreciate you taking the time to create a quality video.

[Dala]

That really helps thanks !!! Appreciate you taking the time to create a quality video.

Regarding 0x393, the CSUM is a bit different in this one. I looked at some logs, and it seems like it is calculated like this:
0x393 0x00 53 00 00 20 00 00 09
CSUM = (5+3+2)-1=9
Another example
0x393 0x00 20 00 00 20 00 00;03
CSUM = (2+2)-1=3

So this means all nibbles summed - 1 = CSUM_393. Not that this info matters much if you are just re-transmitting known stuff.

I updated the database file: https://github.com/dalathegreat/leaf_ca ... 6ad2ec3f36