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.
JeremyW said:
TT did you notice the power bubbles go from "all to none" or was there some gradual drop off on this run?
I gradually lost one then two and then suddenly dropped most of them (all but two IIRC) as soon as I hit turtle. My guess would be 6counts/bubble w/ hysteresis and each count is 1kW just like for the AR. So a value of 10 would have left two power bubbles lit (due to the hysteresis, the threshold for dropping the 2nd to the last is 6).
 
We've made some progress getting OVMS working on the Leaf, thanks to some hard work at the recent #hackaleaf day in UK. We're now using a custom cable which delivers the single EV-CAN bus to the OVMS module. The cable also brings out the CAR-CAN bus, but we only have one CAN controller in the v2 OVMS module so are hoping to be able to do what we need with just the EV-CAN bus (with active polling through to the CAR-CAN bus for the few things we need there).

Below are the items we are looking for, and our current approach. Apologies for the long-post - just want to put it down in one place. Any advise/recommendation appreciated. What mentioning CAN ID numbers, we mean 11bit can messages with the ID in 0x... hex format, and the Dx data byte indexes are D1..D8 (starting at 1 not 0).

car_type

It would be nice to be able to identify the car type (2011, 2012, 2013, etc). Presumably this can be retrieved from the VIN, but we've done nothing for this, yet.

car_vin

This is the alpha-numeric VIN number. It is supposedly available by active polling on the CAR-CAN bus, via the EV-CAN we are on. We did some basic work on this, using standard OBDII PIDs and poll types, but couldn't get anything. One poster on the active-polling thread mentioned they have managed to get it using the leaf-style 0x21 poll type, but we haven't had a chance to try yet.

car_gpslock, car_stale_gps, car_latitude, car_longitude, car_direction, car_altitude

OVMS has a built-in GPS, so we're just going to use that and ignore anything the car has on this.

car_stale_tpms, car_tpms_t (0..3), car_tpms_p (0..3)

TPMS values (stale, temperatures and pressures) would be nice to have, but we've done nothing on this yet. These are nice-to-have, but not essential.

car_doors1 [bit7]

Set if the car ignition is ON. At the moment we're using 0x56e D1=0x86 for car is driving, else not.

car_speed

We don't have this at the moment. We see some wheel speeds on the EV-CAN bus, but no direct speedometer reading. This could be retrieved via GPS, but it would be good to be able to get this from the car.

car_trip, car_odometer

We haven't found either of these on the EV-CAN bus. They are nice-to-have, but not essential.

car_stale_ambient, car_ambient_temp, car_stale_temps, car_tpem, car_tmotor, car_tbattery

These are the ambient, PEM (AC-DC and DC-AC electronics), Motor, and Battery temperatures. We don't have any of these, but haven't started looking yet.

Door status (front-left, front-right, bonnet, trunk, rear-left, rear-right), Handbrake status, Headlight status, lock/unlock status, alarm status

We haven't start looking yet. Presumably these are on the CAR-CAN bus, and will require active polling to retrieve.

Vehicle awake/sleep status

This is trivial to get via activity (or lack of activity) on the EV-CAN bus.

car_time, car_parktime

We will generate these timers internally based on cellular network time and an internal clock.

car_SOC

We're currently getting these from 0x5bc, derived from the GIDs. We realise there are several competing ways of calculating SOC from GIDs and will offer a configuration setting to support them all.

car_idealrange

This is the ideal range of the car, based on current SOC. It should be based on the standard testing cycle figure for the car. So if, for example, the testing cycle says 84 miles, then at 50% SOC the ideal range is 42 miles. At the moment, we're just using a simple SOC% x ideal range for this.

car_estrange

This is the estimated range of the car, based on current SOC and current/recent driving behaviour. We can either show here what the car is showing, or derive our own. We haven't done this yet.

car_cac100

This is some indication of the overall health of the battery. The meaning changes with each supported vehicle. For the Tesla Roadster, 160 is a new battery, and after 3 1/2 years my car is 152.28 today. For the Nissan Leaf, we can probably use GIDS/281 at full charge (or something like that) - but open to suggestions.

Charging Status - pilot signal

We need an indication that there is a pilot signal (i.e.; the charge cable has been connected and the EVSE is offering power). At the moment we are using 0x5bf D3 != 0 AND D4 != 0. It seems to work ok.

Charging Status - car is charging, charge limit, line voltage, charge current

We need an indication of if the charging is in progress, and if it is what voltage and current are being provided by the wall.

Currently, for charge status (charging or not), we are using the same as the pilot signal (0x5bf D3 != 0 AND D4 != 0). For charge completion, as well as looking for EV-CAN bus data to tell us the charge has completed, we're also looking at a timeout of 10 seconds with no EV-CAN bus activity (car has gone to sleep, so charging must have completed).

For charge limit (the current limit that the EVSE advertises), we are using 0x5bf D3/5 (in Amps). We tried this at various different values, and it seemed to match what the EVSE was offering quite well. The only issue is that it seemed to be capped at D3=0x5A (which would be 18A). Values we've seen for D3 are 0x00, 0x27, 0x28, 0x32, 0x33, and 0x5A.

We haven't managed to find the line voltage and charge current data at all. We can see current/voltage of the battery, but not from the wall. This is very useful, and we are still looking for this.

Charge duration

We need the car_chargeduration (in minutes), but we can calculate this ourselves. We also need the car_chargekwh (which is the amount of kWh put into the battery / taken from the wall during the charge session) - which we would normally calculate ourselves based on line voltage and charge current over time.

car_chargefull_minsremaining

This would be nice to have, but we haven't found it yet.

car_stale_timer, car_timermode, car_timerstart

These are the car charge timer values. We haven't started looking yet.

Commands for pre-cool, pre-heat, lock, unlock, etc.

We haven't started on this yet, but it looks promising based on what is shown here. The only issue may be co-existing with the on-board telemetry unit. The OVMS module has some digital I/O pins available, so we can most likely offer a hardware tap for wakeup on pre-2013 cars.

Other stuff

We'd really like to expose all the other stuff on the car (like GIDs, etc). For that, we're going to use custom-metrics tags so we can send them to the apps directly, as well as do logging in a similar way to the way it was done on the Renault Twizy.

The above is really a laundry-list of everything we _want_. What we _need_ now is the VIN (active polling messages), speed, estimated range, cac100 (battery health), charging line voltage and current drawn. Any suggestions you guys have for these would be most appreciated. It would also be helpful if you could check our working for 0x5bf D3/5 (as EVSE pilot signal advertised current), as that seems to make sense for us but we are not sure if the calculation is correct or not (not enough data to be certain).
 
markwj said:
car_stale_timer, car_timermode, car_timerstart

These are the car charge timer values. We haven't started looking yet.

Commands for pre-cool, pre-heat, lock, unlock, etc.

We haven't started on this yet, but it looks promising based on what is shown here. The only issue may be co-existing with the on-board telemetry unit. The OVMS module has some digital I/O pins available, so we can most likely offer a hardware tap for wakeup on pre-2013 cars.

Very nice update. would be great to be able to have a switch on/off which could have the charge timer set to either 80/100%
I have tried the timer that one sets via the LCD system of the leaf, but using the charging timer button on the left of the steering wheel you will have to set every time you have to charge. would be much better to have a button that is solid on 80% or 100% setting. or just having the 80%/100% charging timer set via ovms-app :)

The preheat: Do one need the on-board telemetry unit? I have a imported USA car where carwings does not work because the car is in Europa. Maby I can just pull out the telemetry unit? will OVMS still work?
 
For car_cac100, we should use the Ah value, which is indeed the car's calculated amp-hour capacity (CAC). Unlike 100% charge Gids, we can use the Ah value even for Leafs that never charge to 100%. Hopefully, it's either available on the EV-CAN bus or we can get it from the CAR-CAN bus through polling.

If needed, we can approximate car_chargefull_minsremaining based on SOC and CAC. We will need to know whether the current charge is targeting 80% or 100%.
 
tomsax said:
For car_cac100, we should use the Ah value, which is indeed the car's calculated amp-hour capacity (CAC). Unlike 100% charge Gids, we can use the Ah value even for Leafs that never charge to 100%. Hopefully, it's either available on the EV-CAN bus or we can get it from the CAR-CAN bus through polling.

If needed, we can approximate car_chargefull_minsremaining based on SOC and CAC. We will need to know whether the current charge is targeting 80% or 100%.
AH is available through polling (on either bus). We haven't found a message available yet that directly displays it passively (without polling), but the SOH value (carcan 5b3:d1>>1) is proportional to AH/65.6 (possibly AH/66) within +/-1% so you can compute AH to reasonable accuracy from this.
 
Just sent a message to thorx, but I will also offer it to anyone who has imported a leaf to Europe. I could use one TCU module to dissect and verify operation. $100 plus shipping to USA.

I'm at a confrence then vacation right after so I probably won't be able to contribute to the laundry list till next week. I really feel sympathy to those who don't have car wings (or hate it's drawbacks) and I hope OVMS can be a faster, more detailed implementation. :)

Also if there are any 2013+ SV/SL owners in the Pasadena area reading this, please contact me as I really need to get some logs of things done through the navigation unit.
 
markwj said:
What we _need_ now is the VIN (active polling messages), speed, estimated range, cac100 (battery health), charging line voltage and current drawn. Any suggestions you guys have for these would be most appreciated.
For speed, I've been using carcan(0x176.2<<8+0x176.3)/110 to get mph (empirically determined to match the Leaf speedometer).

For estimated range, I display three values based on 1) last 10 minutes efficiency, 2) best round trip efficiency and 3) worst round trip efficiency. My wife particularly likes this since she can tell easily if she needs to be worried. If she needs to go less than the green number (worst case range) then she can drive as enthusiastically as she wants. I don't have access to GPS so I do something goofy to determine round trip (assume any time I start a trip after 2am and after a charge means I am back at home). With GPS, you could just record a Home position.

cac100 is 0x5b3.1>>1 in %
odometer is 0x5c5.1<<16+0x5x5.2<<8+0x5x5.3

These are all documented on the shared doc along with at least guesses for many of the others you are looking for.
 
As always, reference this spreadsheet. :)

All values (bytes go from 0-7) below on EV can bus unless otherwise noted:
car_ambient_temp
54C byte 6 is the relay to VCM to the CAR can bus for the "eyebrow" temp display. This is a value with some strong hysteresis in it. In US cars (degrees Fahrenheit), this is 1 degree per bit with an offset of +56.
56F byte 6 appears to tack ambient as well, and probably does not have the hysteresis in it.

car_tpem
There are 5 temperature sensors in the inverter (at least in the 2011/2012 cars), with three available on the ev bus. Unfortunately we don't exactly know where they are (the service manual gives no clues whatsoever) but one tracks my external temperature sensor connected to my Brusa exactly. My sensor sits on the top of the inverter cover, so I'm 99% sure this one is on the communications board of the inverter.
55a byte 1. Comm board. 0.5c/bit
55a byte 4. IGBT driver board? 0.5c/bit
55a byte 2. IGBT heatsink? 0.5c/bit

car_tmotor
55a byte 5. 0.5c/bit
car_tbattery
must query BMS for this, see see this thread
Ah is also discussed in that thread.

car_speed
There are speed sensors being relayed from the ABS module through the VCM for the "eshift" module so that it doesn't change "gears" when going above 7mph. This is message 284 with 3 different 16 bit rpm measurements (L/R/rear, not exactly sure).

car_doors1
Set if the car ignition is ON. At the moment we're using 0x56e D1=0x86 for car is driving, else not.
This isn't valid since you can do carwings commands while the car is on and driving (they'll be ignored but the state will change). You could look for message 11A which is not present when the car is not driving/in ready(?).

A lot of the "doors open" "unlock" "lights" etc etc etc are on the car can bus where the "body control module" is located. You'll have to query for those things (and easy on the querying when the car is off! You'll get relay clicking which isn't damaging but is undesirable).

I have a lot to do for the charger on the 2011/2012's.... unfortunately the 13+ chargers are different and have different CAN messages. I could really use a log of a 2013+ charging.

More to come! :)
 
I looked at brad370's spreadsheet which is a bit more up to date than the 370z tab on our can spreadsheet. I've since updated a few things since the car CAN and the 370z can are similar. There were a few "motor speeds" I changed to vehicle speeds, and 284/285 on car CAN now has which wheel is which. Also 292 on car can has 12v battery voltage as seen by the ABS module at 0.1V/bit. *Twirls finger in air* ;)
 
Not exactly CAN related, but related to the "eyebrow" temperature readout I found today in the service manual:

Ambient temperature correction said:
The A/C auto amp. internally processes the ambient temperature data is two data types: data for A/C control
and data for ambient temperature display.
The A/C auto amp. inputs the temperature detected with the ambient sensor as the ambient temperature.
When the vehicle speed is 30 km/h or less, if the effects of radiator heat and other factors result in a sudden increase in detected ambient temperature, the A/C auto amp. performs delay correction so that the recognized temperature rises slowly. Correction is performed so that the change is recognized quickly when the ambient temperature drops.

Also interior:
Interior air temperature correction said:
In order to prevent effects from uneven temperatures inside the vehicle and from external disruptions, the A/C auto amp. performs correction so that the recognized interior air temperature changes slowly. The A/C auto amp. performs the correction so that the recognized interior temperature changes according to the difference between the detected interior temperature and the recognized interior temperature. If the difference is large, the changes occur quickly, and becomes slower as the difference becomes smaller.
 
54C byte 5 appears to be climate control fan voltage at 0.05 V/bit. Fan speed is proportional to voltage and there's a handy chart in HAC, Pg 19 that I'm not about to copy here. 4.0-12.5 Volts

54C byte 0 is evaporator temp (we've known that for a while), but I'm not sure of the scale... I think it's 0.1 or 0.2 C/bit.

54F byte 0 appears to track interior temperature, but I can't figure out scale or offset.
 
Here's a big one: available power

We found msg 260 on car CAN contained available power/regen to the "bubbles" display in the instrument cluster. Well now I think I found where *part* of the message is originating from on the EV CAN bus. Thanks to Turbo3 for isolating a LBC module, we know that msg 1DC is from the LBC along with 0x1DB, 0x55B, 0x59E, 0x5BC, 0x5C0 (although I've never seen msg 59E in my logs??).

I've plotted 1DC byte 0 (red) and 260 byte 0 (blue) on the graph below from TickTock's last 16 gids to turtle run:

car260ev1dc.png

Note there are some points at the end where 260 returns to "full" but this is just a characteristic of what happens after the contactor opens (all the bubbles come back).
There's some points where something else is limiting maximum power. Perhaps climate control or something else? Normally 1DC byte 0 is 0x6E or 110 kW. Msg 260's highest is 0x5A (94kW). Lowest observed during TT's run was 0x31 or 51 kW. There might be other messages that control output when you are down that low BUT I also note that the 1DC value is low (0x65 or 101 kW) at 16 GIDs.

I encourage others who have logs of say 100 gids to turtle (or even VLBW) to examine message 1DC to see where the BMS starts limiting output current (byte 0 going below 6E).

I also think the available charge power is also on this message but I need to look through some more charging logs. I'm about 95% sure it's on byte 2 but that byte does kinda weird things during drive. On the consult tool there are separate fields for "available regen power" and "available charge power".
 
Hmmm. Try plotting 1D5:D1[7:5]-D0 (Applied Regen). Since available regen is reduced when you apply traction power, maybe available power is reduced when you apply regen.
 
Has anybody found a Stop-Charging message yet?

Set up to do logging of the EV-CAN bus from the OBD connector.
During charging, use Carwings to Stop charging, and try to find
a CAN message that stops the charging process.

Similarly, while doing the J1772 charging, press the button
to unlock the J1772 plug-handle, and again see if there is
a Stop-Charging message.

Once identified, if it exists, it is likely that I could modify the GID-Meter
to have a stop-charging function, which the user could set
at almost any SOC level. Anything over 95% would probably
be a normal full charge.

Or, it is likely that Leaf Spy Pro could be have that function added.
 
garygid said:
Has anybody found a Stop-Charging message yet?
No. And several of us have made concerted efforts to find one (We have been trying to implement the feature you describe for some time). See this most recent (and most promising) post from Jim and followon analysis by Jeremy.

Does CarWings have an option to stop charge? I didn't think it did.
 
CarWings does not have a stop charging message. As far as I can tell, the command from the telematics (EV bus message 56E) is pretty simple and made up of a few bit flags.
Code:
hex	binary	state
86	10000110	idle
46	01000110	status
4E	01001110	cc on
56	01010110	cc off
66	01100110	remote charge
From the highest bit: idle, VCM wake-up logic line status, remote charge, cc off, cc on, unknown, unknown, 0. The unknowns could be 12v supply voltage voltage ok and "within cell coverage"

Since that time I've never seen anything other than these states. You could unplug the TCU and try sending some other things like 0x67: 01100111 and see if that turns it off. However, I doubt Nissan would have left this functionality on the table. The only thing that I think they might have left on the table is the code to change the remote turn on temperature. In the 2013+ models this is a command from the AV unit to the climate control computer. I haven't isolated the message on a 2013 but I suspect it *might* work on a 2011 or 2012.

You might look at EV bus message 1F2. I suspect commanded charge power is in here.
 
Similarly, while doing the J1772 charging, press the button to unlock the J1772 plug-handle, and again see if there is a Stop-Charging message.

At least in the 2011-2012 models, proximity is handled by the onboard charger itself. It will report that it has gone to 0 current (and it might change another bit indicating proximity has changed) but the rest of the leafs systems will continue to run (pumps, DC/DC, etc) until the cord is pulled out. As far as I can tell, under all conditions, the VCM (master computer) is the "conductor of the orchestra" and has the final say as to what state the car is in. You will probably have to send a request to the VCM to stop charging.
 
Not sure if this is true for 2013+ leafs, but it appears that msg 380 shows a few QC parameters.

Byte 0: 02 drive, 12 L1/L2, 82 start qc, 83 end qc (82/83 might have bit flags for the qc contactors), 86 qc

Byte 1: 04 not qc, 84 qc in progress

Byte 2: 10 drive, 13 qc, 22 end qc, 18 L1/L2

Byte 3 is QC Voltage

Byte 4 is QC commanded amperage

Not sure the scale for bytes 4/5.

Byte 7 looks like mains (AC) voltage is on here?
 
Message 1DA looks like it has the individual phase currents of the motor... or the current through each IGBT. Byte 6 has 4 mux channels (0-3) with the MSB of that byte indicating negative (2's complement) or positive with byte 7 being the data. The data looks periodic in nature, but I haven't had a chance to really study it.
 
Back
Top