LEAF CANbus decoding. (Open discussion)

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.
gorgo said:
Hi Dala! I loved your 'very boring' video :D
At the beginning I wondered "Wth? How did he get passive CAN messages from the Leaf 2018?", then you reveal that the sender had probably got access to the internal wires. Seems fair.
I'm curious now how you usually proceed from raw bytes to ECU meaningful values without Nissan's instructions.

I also read on OVMS Leaf 2018 issue (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/323) what caederus-ovms reported about HVBATT data even if I'm not fully understanding every variables there. Anyone knows, for example, what's the insulation value or flash or mode?

Thanks,
To get further, one would need access to the vehicle. Start charging it, modify some stuff by changing input voltage, activating loads while charging, observe the data that moves on the bus etc. Basically try to change what the vehicle senses, and see if the communication responds. An easy example of this on CAR-CAN would be to open the passenger door, and see which bit on the bus gets triggered. Tools from VECTOR are much more suited to this than freeware tools sadly.

No clue about the 2018 Leaf, since I've never actually had one in my shop yet.
 
here you have and introduction of how to reverse can communication
http://opengarages.org/handbook/

btw the web is full of examples and videos

cheers

gorgo said:
Hi Dala! I loved your 'very boring' video :D
At the beginning I wondered "Wth? How did he get passive CAN messages from the Leaf 2018?", then you reveal that the sender had probably got access to the internal wires. Seems fair.
I'm curious now how you usually proceed from raw bytes to ECU meaningful values without Nissan's instructions.

I also read on OVMS Leaf 2018 issue (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/323) what caederus-ovms reported about HVBATT data even if I'm not fully understanding every variables there. Anyone knows, for example, what's the insulation value or flash or mode?
 
I'm interested in monitoring the power flow on the Leaf's low voltage (12V) system. Does anyone know where to look for the DCDC converter's can bus voltage and current messages? Cheers
 
Drc38 said:
I'm interested in monitoring the power flow on the Leaf's low voltage (12V) system. Does anyone know where to look for the DCDC converter's can bus voltage and current messages? Cheers

CAR-CAN message ID 0x292 has LeadAcidBatteryVoltage in it, maybe the current one is in the same message?
 
Dala said:
CAR-CAN message ID 0x292 has LeadAcidBatteryVoltage in it, maybe the current one is in the same message?
On my 2016 Leaf this seems to be static at 7F so it doesn't appear to be an actual voltage reading, I think I would need something on the EV-CAN bus ideally.
 
Drc38 said:
Dala said:
CAR-CAN message ID 0x292 has LeadAcidBatteryVoltage in it, maybe the current one is in the same message?
On my 2016 Leaf this seems to be static at 7F so it doesn't appear to be an actual voltage reading, I think I would need something on the EV-CAN bus ideally.

Afaik there is nothing on the EV-CAN for 12V battery stats. I will add the comment to the database that it seems static on your vehicle!
 
Is there a 79B command or other command that can be used to refresh the data from the BMS.
I have done quite a bit of work already reading data from the pack using 1DB,1DC,5BC & 55B broadcast commands based on the kvaser database (THANKS) and 79B query command.
I am using the battery pack stand alone in another vehicle and am finding that SOC, KW, GIDS and BAR data do not update in real time.
I have to cycle the ignition and power to get a fresh update.

The only data that is live is HV Battery, Auxiliary Battery & HV current. Temperature & cell voltages are accessible thru the 79B command and are also live.
Perhaps I am doing something wrong but that does not seem obvious to me.
Help appreciated.
All the best to everyone for the New year.
 
You *should* get actual power. Maybe you're not engaging the main relays? Not using IGN and BAT?

I've made a direct battery-to-chademo interface (with a CAN bridge) to discharge a battery into a SETEC V2H module, and it works flawlessly. My connections are:

- BAT and IGN on +12V
- All grounds commoned
- RLY1 and RLY2 on a MOSFET
- CAN connected (obviously)

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.

This is on a gen1 battery.

I haven't tested this on a gen2+, it is possible that newer batteries need one of the wake-up messages (0x603, 0x605, 0x607, 0x679, 0x68C) to start actualizing their data. All of those wake-up messages are just that CAN ID, DLC=1, data=0.
 
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, I 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.
 
Made a fresh recording and found the following:
Gen 2 are slightly different 11A commands originating from the VCM:
0x11A: 8;01;40;14;AA;C0;00;00;87
0x11A: 8;01;40;14;55;00;00;01;91
0x11A: 8;01;40;14;55;40;00;02;5C
0x11A: 8;01;40;14;AA;80;00;03;4A

Also noted are 0x390 and 0x393 commands when the car is running and pack connected to car.
0x390 and 0x393 originate from the charger and use PRUN as described below by Dala.

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

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


The following sequence runs like clock work followed by 0x1DB, 0x1DC and 0x1D4 reporting from the BMC.
0x11A: 8;01;40;14;AA;80;00;03;4A
0X390: 8;04;00;00;03;00;80;00;D8
0x393: 8;00;20;00;00;20;00;00;14
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
There are no 0x603,0x605,0x607,0x679 OR 0x68C commands observed during the recording.
I rewrote my code adding 0x11A commands to match the above added 0x390 and 0x393 commands and prioritized processing of 7BB responses and the 79B next data byte commands.
There naturally are couple of bugs in my edits which need to be corrected before determining if the changes have enabled frequent BMS data updates other than at ignition cycling.
More to follow.
 
49thdiver said:
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_can_bus_messages/commit/baeb78f32d6016220856d765d4d90f257868aa5f
 
49thdiver said:
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.
 
Dala said:
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.
 
mux said:
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 said:
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.
 
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)
 
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;
 
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.
 
49thdiver said:
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_can_bus_messages/commit/346d755e599cf1984182f01a59ee846ad2ec3f36
 
Back
Top