[Ovmsdev] Leaf EV CAN messages

Fri Aug 8 03:21:01 HKT 2014

I posted a response on the MNL forum, see here:
http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=407

I should be able to provide some more data Friday. I eventually need to do
some logging on a "gen II" 2013 or newer car....

On Tue, Jul 29, 2014 at 9:36 AM, Mark Webb-Johnson <mark at webb-johnson.net>
wrote:

>
> 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)
> <http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&p=380402#p380402>
> [image: Post] <http://www.mynissanleaf.com/viewtopic.php?p=380402#p380402>
> *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
> <http://www.myelectriccarforums.com/electric-vehicle-charger/> 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
> <http://www.myelectriccarforums.com/electric-vehicle-charger/> advertises),
> we are using 0x5bf D3/5 (in Amps). We tried this at various different
> values, and it seemed to match what the EVSE
> <http://www.myelectriccarforums.com/electric-vehicle-charger/> 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
> <http://www.myelectriccarforums.com/electric-vehicle-charger/> 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
> <https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1ON2xZSzlMUXc&usp=sharing>
> For the latest developments Leaf CAN wise, check out the thread on MNL
> here <http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=390>
>
> 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
>
>
>
> _______________________________________________
> 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.teslaclub.hk/pipermail/ovmsdev/attachments/20140807/59ccc5bf/attachment-0001.html>
-------------- 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.teslaclub.hk/pipermail/ovmsdev/attachments/20140807/59ccc5bf/attachment-0001.gif>