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.
Hi!
Been lurking here for a while, I'm trying to hack a leaf OBD charger. I've come quite a way closer to charging. I've written a program which makes the charger think it's in the leaf. And it seems to work the charger is no longer sending "fault" signals by CAN. And I'm trying to make it charge by sending the same messages that the VCM sends to the leaf when charging, according to CAN captures by carrot. I still haven't been able to make it charge. Is it possible that the charger like the inverter saves DTC and refuses to start charging? If so what's my best option to remove stored DTCs?

If anyone wants my codes for the program or help with making the charger "think" its in a leaf just contact me!
 
celeron55 said:
Project update: I was unable to reverse the charger CAN protocol to an extent that would have made it do any... well, charging. I did get the DC-DC converter to operate, but that was it.

Basically I found out bit 0x04 in the 0x1f2 frame disables the converter (set low to enable, just spam 0x1f2 00 64 00 a0 00 00 00 00 or so every 10ms). You might also need 50b, 1d4 and maybe 55b (probably not). Anyway, that's worthless without the charging working.

I'm now in the process of developing the necessary hardware mods to get it to charge without any co-operation of Nissan's original software. This is actually going fairly well (I already have full control in a lab setup), but making this reproducible or to be something that I can use daily is more difficult.

EDIT: I've basically reverse-engineered enough of the connections to the Renesas R5F35MEEJFE chip that controls the PDM in order to write a new program from scratch for it to do regular charging and dc-dc conversion. Not sure if I'll do that, I'd need a E8a emulator ($150) and basically IAR Embedded Workbench for M16C ($2000? $4000?) to program it. Also, nobody sells these chips for a hobbyist if the one on board is somehow locked. I can find different ones with the same pinout though, eg. R5F35L2EJFE.

Hi celeron55,

Thank you for reporting the results of your work!! I recently started searching the forums again and found your work on reverse-engineering the Leaf.

I have been very happy with my 2011 Leaf until last month when I had to replace the 3.3kW onboard charger (OBC). Now I want to find a way to replace the OBC with an aftermarket charger.

You have gotten the charger working, have you recorded or looked at what is required to make the Leaf work with another charger?

I subscribed to this link to follow your work!
 
Hi!
Could someone please help me understand this:

So if I want to calculate the SOC of my leaf battery pack how would I do it?
I understand that ID 55B byte 0 and 1 is the data I should use right?
so the message is this and the SOC according to leafspy pro should be 65,3%.
ID: 55B
Data: A9 C0 AA 00 FF C0 10 D6

How should I calculate the SOC from this CAN message?
 
Never tried to decode that particular messsge, but 0xa9c0 divided by 0xffff (maximum 16 bit value) equals 66.3%, which is at least close.
 
I would like to give a short report on our work to create a Vehicle Control Unit that can communicate/control the Leaf inverter/motor assembly.

Now we have completed about 6 months of testing and revisions on our VCU, which controls a 2013 Leaf drivetrain in a converted Geo Metro.

Work started on this project by tapping into a functioning Leaf controller canbus and recording data in various drive modes. The spreadsheet with known canbus information from this forum helped us filter the data and understand useful messages. Member Celeron55 contributed critical data for calculating a checksum and cleared up a few interpretation issues.

We programmed our VCU hardware to send torque responses, and once we were able to test it on pavement, incrementally added multiple user friendly features. The following is a list of what we have so far. The Geo Metro runs very much like a production electric at this point.

- User configurable torque values: maximum, idle regeneration, brake regeneration
- User configurable Forward, Neutral, Reverse options using a SPDT switch and voltage divider
- User configurable minimum precharge voltage for main contactor closure. This ensures precharge is functioning
- User configurable maximum pack voltage during regenerative braking, with feathered torque commands to prevent pack overcharge
- Automatic throttle feathering at regeneration transitions, including floating zero torque position proportional to RPM
- User configuration values and various troubleshooting traces via Putty or Coolterm serial interface
- Torque based brake light activation during regenerative braking

The battery pack in the Geo started at 260 volts and is now at 400, comprised of modules from surplus packs taken from the 2008 MiniE (BMW) limited production. Total capacity now is about 35 KWH, which we estimate will provide between 140 to 180 miles range.

Here is a video made early in the ThunderStruck Motors project. Note the absence of the charger/DCDC module normally on top of the Gen2 inverter. The 3-point Leaf mounts required minor extensions for the Geo mount points. The half-shafts were cut and spliced between Geo and Leaf for the required lengths.

https://www.youtube.com/watch?v=BmwguyYcXm8

Many thanks to all of you who have contributed to information gathering for the Canbus Decoding project on this forum.
 
jbpalm said:
I would like to give a short report on our work to create a Vehicle Control Unit that can communicate/control the Leaf inverter/motor assembly.

Great work! I'm using one of these too. Here's mine working on the bench:

https://youtu.be/8xjG_AcFs70
 
Not sure if this was already discussed, but it looks like the "insulation resistance signal" is in message id 0x55b on the ev can bus. It's described in the service manual as a can-bus message for the VCM to know if there is a loss of galvanic isolation (caused by shorted wires, bad insulation, etc.)

I made the tests with the battery pack and 2nd gen BMS (~2013 model yr) outside of the car, and reading the can bus data that's being pushed from the BMS. Then I purposely took various large-value resistors to connect 12V ground with the HV battery pack. The other can bus messages (1db, 1dc, 59e, 5bc, and 5c0) had no noticeable patterns with a resistance change.

The insulation resistance signal appears to be scaled as an 10-bit integer with 0.5k ohm per LSB. Data is in byte 4 (bits 7:0) and byte 5 (bits 7:6). In byte 5, bits 6:0 are not changing and are always zero.

normal operation: ed 80 = 1110 1101 1000 0000 -> 10 bit: 950
392k ohm resistor: a1 00 = 1010 0001 0000 0000 -> 10 bit: 644
102k ohm resistor: 5b c0 = 0101 1011 1100 0000 -> 10 bit: 367
 
Hi all,
is there a location people are placing this data? If there isn't, I'm happy to manage a repo.

Cheers
Bret
 
Hello everyone, some of you might know I'm in the business of making range-extender batteries for the LEAF, I've been quite intensively working on electronics for the car in the past few months and have been making a lot of use of the canmsgs spreadsheet as well as adding some of my own findings into it. Not all of this is new, but I have a few additions to make:

- The VCM definitely is the originator for IDs 1D4. 1F2, 50A, 50B, 50C, 5A9, 5B9, 284 and nothing else
- 0x1DC byte 1 lower nibble is the maximum regenerative braking power, 0xF=max, 0x0 is no regen
- 0x1DC byte 2 and 3 (upper nibble) is commanded QC charging current in steps of 0.05A (i.e. 0x9C4=2500=125A).
- 0x5C0 byte 2 is the pack temperature as indicated on the dash, but highly nonlinear (I haven't figured out what it is, also I believe this has been discussed before but is not in the document)

These should be useful to people tinkering with the car. They sure were useful for me.

I'm currently in the process of decoding everything, and I'm doing that with a live EV-CAN logger board I've made plus some live decoding scripts in javascript. With almost everything automated, I expect to be able to interpret all the CAN data pretty quickly. Is it maybe possible for me to get editing privileges on the canmsgs document?
 
I'm doing a where's waldo/wally on the battery cell voltage information. I know FOR SURE they have to be in the EV-CAN messages somewhere, but for the life of me I can't figure it out just from looking at logs and decoding. I have the possibility to modify CAN data and see what happens, so that's the next step, but I'd rather figure it out before that. So, my thought process so far:

The BMS sends out, we know this for sure:

- 0x1DB which is fully decoded (voltage, current in the first 3 bytes, then 2 bytes that are always 0, a counter and a CRC)
- 0x1DC which has max. battery power, regen, commanded charge current in the first 4 bytes, then 3 unknown bytes* and a CRC
- 0x55B which has SoC, then a byte that is always 0xAA/0x55, an always-zero byte, HV isolation resistance, a counter and CRC
- 0x5BC has GIDs, state of charge in bars/SoH on a mux, two unknown stable bytes with a mux and then 3 very variable bytes**
- 0x5C0 has a mux, three temperature bytes, a linear ramping byte and a byte that alternates between 3 values according to the mux

All of the bytes in these messages have either been decoded or are too stable/uncorrelated to be voltages. The unknown bytes in 0x1DC are periodic and do not change with SoC. The 3 variable bytes in 0x5BC are a mystery to me, but they seem not to change according to SoC.

All I can figure is that the BMS somehow encodes the battery cell voltage data into message 0x5BC bytes 5-7, but how? There is no other place it can be, but the data doesn't seem to make much sense. It looks much more like battery balancing data. Or maybe it's muxed together with balancing status. Has anyone figured this out already?
 
There is no different traffic AFAICT during a leafspy query. The information should really be on the bus.
 
mux said:
All I can figure is that the BMS somehow encodes the battery cell voltage data into message 0x5BC bytes 5-7, but how? There is no other place it can be, but the data doesn't seem to make much sense. It looks much more like battery balancing data. Or maybe it's muxed together with balancing status. Has anyone figured this out already?

I'm just in the peanut gallery watching but doesn't LeafSpy have to know how to decode this information since it displays it?

And maybe the cell voltage data is given as a percentage of full or a delta from full or some oddball format like that.
 
Doh, of course, Turbo3 has already cracked this nut. I even remember a video of him directly connecting to a BMS and reading it with leafspy. Now if only I can find the thread where he's showing that...

Edit: oooooooooooooooooooooooohhhhhh... Oh. I see. Well, I'm off to trying out some stuff!
 
My research CAR-CAN tires
IMMO system
VCM LEAF 2011 (ZEO) Hitachi
VCM > id512 (03 AD FF FF ) > BCM (BODI CON.)
BCM > id342 (03 AD 00 00) > VCM
VCM > id512 (03 20 00 00) > BCM
BCM > id342 (03 23 00 00) > VCM
VCM > id512 (03 2C FF FF) >BCM
Time 2 sec.
IPDM >id625(00 00 FF 0E 20 00) > VCM
VCM IN READY ON
 
mux said:
There is no different traffic AFAICT during a leafspy query. The information should really be on the bus.
I'm certain that the BMS only sends out the data LeafSpy uses after it gets requested. I'm pretty certain that in normal operation (ie without leafspy) those requests aren't sent. The BMS does send a bunch of data without being requested but I haven't seen any decoding of it.
 
You're totally right, that previous comment is bogus. Requests are sent on CAN ID 79B and responses on 7BB. I'm well past this now, implementing this currently on my CAN logger device.
 
NiallDarwin said:
mux said:
There is no different traffic AFAICT during a leafspy query. The information should really be on the bus.
I'm certain that the BMS only sends out the data LeafSpy uses after it gets requested. I'm pretty certain that in normal operation (ie without leafspy) those requests aren't sent. The BMS does send a bunch of data without being requested but I haven't seen any decoding of it.

That's the most logical approach to any bus system design, i.e. why overload a bus with extraneous data and slow the access time
to a particular ECU and its data.
 
Back
Top