User avatar
Dala
Posts: 353
Joined: Sun Oct 28, 2018 11:24 am
Delivery Date: 01 Jan 2015
Leaf Number: 316851
Location: Finland
Contact: Website

Re: LEAF CANbus decoding. (Open discussion)

Mon Jan 04, 2021 2:03 am

49thdiver wrote:
Mon Jan 04, 2021 12:10 am
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
Posts: 323
Joined: Sat Jan 13, 2018 3:52 am
Delivery Date: 13 Oct 2011
Leaf Number: 6177

Re: LEAF CANbus decoding. (Open discussion)

Mon Jan 04, 2021 3:29 am

49thdiver wrote:
Sat Jan 02, 2021 12:41 pm
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.

User avatar
49thdiver
Forum Supporter
Posts: 66
Joined: Fri Feb 07, 2020 10:14 pm
Delivery Date: 15 Jan 2020
Leaf Number: 305065
Location: CANADA's westcoast
Contact: Website

Re: LEAF CANbus decoding. (Open discussion)

Mon Jan 04, 2021 1:33 pm

Dala wrote:
Mon Jan 04, 2021 2:03 am
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.
Peter
Dangerous if left unattended.
1985 Grumman Olsen Kubvan, 2002 Rav4 EV, 2000 Ford Ranger EV, 2015 Nissan leaf, Biktrix LJ

User avatar
49thdiver
Forum Supporter
Posts: 66
Joined: Fri Feb 07, 2020 10:14 pm
Delivery Date: 15 Jan 2020
Leaf Number: 305065
Location: CANADA's westcoast
Contact: Website

Re: LEAF CANbus decoding. (Open discussion)

Mon Jan 04, 2021 2:10 pm

mux wrote:
Mon Jan 04, 2021 3:29 am
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.
mux wrote:
Mon Jan 04, 2021 3:29 am
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.
Peter
Dangerous if left unattended.
1985 Grumman Olsen Kubvan, 2002 Rav4 EV, 2000 Ford Ranger EV, 2015 Nissan leaf, Biktrix LJ

User avatar
Dala
Posts: 353
Joined: Sun Oct 28, 2018 11:24 am
Delivery Date: 01 Jan 2015
Leaf Number: 316851
Location: Finland
Contact: Website

Re: LEAF CANbus decoding. (Open discussion)

Tue Jan 05, 2021 1:14 am

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)

User avatar
49thdiver
Forum Supporter
Posts: 66
Joined: Fri Feb 07, 2020 10:14 pm
Delivery Date: 15 Jan 2020
Leaf Number: 305065
Location: CANADA's westcoast
Contact: Website

Re: LEAF CANbus decoding. (Open discussion)

Wed Jan 06, 2021 9:32 am

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;
Peter
Dangerous if left unattended.
1985 Grumman Olsen Kubvan, 2002 Rav4 EV, 2000 Ford Ranger EV, 2015 Nissan leaf, Biktrix LJ

User avatar
Dala
Posts: 353
Joined: Sun Oct 28, 2018 11:24 am
Delivery Date: 01 Jan 2015
Leaf Number: 316851
Location: Finland
Contact: Website

Re: LEAF CANbus decoding. (Open discussion)

Wed Jan 06, 2021 10:28 am

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
Posts: 460
Joined: Mon Jun 05, 2017 10:21 pm
Delivery Date: 06 Jun 2017

Re: LEAF CANbus decoding. (Open discussion)

Wed Jan 06, 2021 6:19 pm

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

User avatar
49thdiver
Forum Supporter
Posts: 66
Joined: Fri Feb 07, 2020 10:14 pm
Delivery Date: 15 Jan 2020
Leaf Number: 305065
Location: CANADA's westcoast
Contact: Website

Re: LEAF CANbus decoding. (Open discussion)

Thu Jan 07, 2021 12:13 am

That really helps thanks !!! Appreciate you taking the time to create a quality video.
Peter
Dangerous if left unattended.
1985 Grumman Olsen Kubvan, 2002 Rav4 EV, 2000 Ford Ranger EV, 2015 Nissan leaf, Biktrix LJ

User avatar
Dala
Posts: 353
Joined: Sun Oct 28, 2018 11:24 am
Delivery Date: 01 Jan 2015
Leaf Number: 316851
Location: Finland
Contact: Website

Re: LEAF CANbus decoding. (Open discussion)

Fri Jan 08, 2021 12:02 pm

49thdiver wrote:
Thu Jan 07, 2021 12:13 am
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

Return to “LEAF CANBus”