[Ovmsdev] Leaf EV CAN messages

Fri Aug 22 01:32:58 HKT 2014

Any updates to OVMS for the leaf?

On Thu, Aug 7, 2014 at 2:29 PM, Dave Davies <dodegkr at gmail.com> wrote:

> Based in Reigate Surrey October 2013 car , happy to help..
>
>
> On 7 August 2014 20:21, Jeremy Whaling <jeremy.whaling at gmail.com> wrote:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20140821/c35b7be2/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/20140821/c35b7be2/attachment-0002.gif>