[Ovmsdev] Leaf EV CAN messages

Wed Jul 30 00:36:43 HKT 2014

I’ve posted on mynissanleaf a laundry-list of what we need for the Leaf. Hopefully we can get some help there, as well as validation that we are doing is the correct approach.

Regards, Mark.

http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&p=380402#p380402

markwj	
 Post subject: Re: LEAF CANbus decoding. (Open discussion)Posted: Wed Jul 30, 2014 1: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).

On 26 Jul, 2014, at 11:37 pm, Mark Webb-Johnson <mark at webb-johnson.net> wrote:

> Jeremy,
> 
> Fantastic. Thanks for sharing.
> 
> I checked what you wrote against the EVCAN bus dumps we took, and they seem to match well.
> 
> For example, a carwings HVAC on shows:
> 
> 1405412687.875 R11 56e 46
> 1405413246.983 R11 56e 4E
> 1405454415.582 R11 56e 46
> 1405472495.666 R11 56e 86
> 
> and HVAC off shows:
> 
> 1405800125.677 R11 56e 86
> 1405801551.786 R11 56e 46
> 1405810295.435 R11 56e 56
> 1405827846.735 R11 56e 46
> 1405842751.818 R11 56e 86
> 
> These were on a 2012 leaf (I think), so I’m not seeing any 68C messages from carwings - although I did see the 68C 00 message when the car was switched on.
> 
> Makes me glad that we recently decided to switch to using the EV-CAN bus.
> 
> For the hardware mod necessary for 2011/2012 Leafs, any ideas how this could be done? Anyone got the 2012 service manual that they can send to me? We have a bunch of 5V TTL level outputs in the OVMS module that could be used as the basis for this.
> 
> Regards, Mark.
> 
> On 26 Jul, 2014, at 3:46 pm, Jeremy Whaling <jeremy.whaling at gmail.com> wrote:
> 
>> Hi All-
>> 
>> Over the last few days a few of us on the mynissanleaf forum have been working on getting the TCU (telematics module) CAN messages for the various modes of operation (remote CC, status, charge). Here's what we know now:
>> 
>> To wake up the VCM (Main controller), the TCU sends a msgID of 68C on the EV CAN bus with one byte of 00. On 2013 and newer models wake up solely on the CAN message.  
>> 
>> For 2011 or 2012 models the TCU will bring a logic line high that connects to the VCM briefly as well to wake it up. Page 64 of the "AV" section of the 2012 service manual shows the pinout of the TCU. You will need to splice into Pin 11 (light green? wire) on the large connector going to the TCU and make an appropriate circuit to pull it high briefly when the OVMS module sends the 68C message. When doing non "remote charge" testing you might be able to hit the charge override button (which uses another line to wake the VCM) then send 68C. I think that might work for testing. :-)
>> 
>> Once the VCM is awake it looks to the TCU status message to see what's up. The status message has a msgID of 56E and the first byte determines the status (the 6 other bytes are FF). The 56E message repeats every 100ms whenever the EV CAN bus is active. The various modes are:
>> hex   binary   state
>> 46   01000110   status
>> 86   10000110   idle
>> 4E   01001110   cc on
>> 56   01010110   cc off
>> 66   01100111   remote charge
>> 
>> That's all we have so far. Haven't tried pulling the TCU yet and duplicating it's messages but I'm reasonably confident this is all there is to it as far as remote activation.
>> 
>> For more info, see this Google Doc with the Leaf's CAN message info here
>> For the latest developments Leaf CAN wise, check out the thread on MNL here
>> 
>> Take care,
>> 
>> Jeremy
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140730/cf7df815/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icon_post_target.gif
Type: image/gif
Size: 122 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140730/cf7df815/attachment-0002.gif>