[Ovmsdev] Leaf EV CAN messages

Fri Aug 8 05:29:45 HKT 2014

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140807/a731b32d/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/20140807/a731b32d/attachment-0002.gif>