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@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
