User avatar
TickTock
Posts: 1701
Joined: Sat Jun 04, 2011 10:30 pm
Delivery Date: 31 May 2011
Leaf Number: 3626
Location: Queen Creek, Arizona
Contact: Website

Re: LEAF CANbus decoding. (Open discussion)

Mon Jul 28, 2014 6:16 am

JeremyW wrote: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).

markwj
Posts: 1
Joined: Mon Oct 14, 2013 6:20 pm
Delivery Date: 14 Oct 2013

Re: LEAF CANbus decoding. (Open discussion)

Tue Jul 29, 2014 9:14 am

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).

thorx
Posts: 36
Joined: Tue May 14, 2013 5:41 pm
Delivery Date: 05 May 2013
Location: Norway

Re: LEAF CANbus decoding. (Open discussion)

Tue Jul 29, 2014 10:09 am

markwj wrote: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?

User avatar
tomsax
Forum Supporter
Posts: 102
Joined: Wed Apr 21, 2010 2:33 pm
Delivery Date: 21 Sep 2011
Leaf Number: 8847
Location: Sammamish, WA

Re: LEAF CANbus decoding. (Open discussion)

Tue Jul 29, 2014 10:11 am

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%.
Tom Saxton
Sammamish, WA

User avatar
TickTock
Posts: 1701
Joined: Sat Jun 04, 2011 10:30 pm
Delivery Date: 31 May 2011
Leaf Number: 3626
Location: Queen Creek, Arizona
Contact: Website

Re: LEAF CANbus decoding. (Open discussion)

Tue Jul 29, 2014 10:47 am

tomsax wrote: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.

User avatar
JeremyW
Posts: 1514
Joined: Sun Nov 13, 2011 12:53 am
Delivery Date: 23 Jun 2012
Leaf Number: 19136
Location: San Gabriel, CA

Re: LEAF CANbus decoding. (Open discussion)

Tue Jul 29, 2014 11:28 am

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.
Former 2012 SL leasee 6/23/12 - 9/23/15
Now driving Honda Fit EV, License plate: CHADEMO
2000 Honda Insight for long trips

User avatar
TickTock
Posts: 1701
Joined: Sat Jun 04, 2011 10:30 pm
Delivery Date: 31 May 2011
Leaf Number: 3626
Location: Queen Creek, Arizona
Contact: Website

Re: LEAF CANbus decoding. (Open discussion)

Tue Aug 05, 2014 9:39 pm

markwj wrote: 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.

User avatar
JeremyW
Posts: 1514
Joined: Sun Nov 13, 2011 12:53 am
Delivery Date: 23 Jun 2012
Leaf Number: 19136
Location: San Gabriel, CA

Re: LEAF CANbus decoding. (Open discussion)

Wed Aug 06, 2014 3:20 pm

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! :)
Former 2012 SL leasee 6/23/12 - 9/23/15
Now driving Honda Fit EV, License plate: CHADEMO
2000 Honda Insight for long trips

User avatar
JeremyW
Posts: 1514
Joined: Sun Nov 13, 2011 12:53 am
Delivery Date: 23 Jun 2012
Leaf Number: 19136
Location: San Gabriel, CA

Re: LEAF CANbus decoding. (Open discussion)

Tue Aug 12, 2014 11:40 am

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* ;)
Former 2012 SL leasee 6/23/12 - 9/23/15
Now driving Honda Fit EV, License plate: CHADEMO
2000 Honda Insight for long trips

User avatar
TickTock
Posts: 1701
Joined: Sat Jun 04, 2011 10:30 pm
Delivery Date: 31 May 2011
Leaf Number: 3626
Location: Queen Creek, Arizona
Contact: Website

Re: LEAF CANbus decoding. (Open discussion)

Fri Aug 15, 2014 7:52 am

Nice work Jeremy! This is great stuff (and thanks for adding it to the spreadsheet).

Return to “LEAF CANBus”