[Ovmsdev] Leaf Update

Tom Parker tom at carrott.org
Sat May 14 16:38:35 HKT 2016


Hi,

I've sent a pull request with some change to the Leaf vehicle. Nothing 
particularly exciting. I improved the state decoding when the car is 
plugged in but waiting for the charge timer and I disabled the polling 
for VIN and Speed as these don't work on my car and cause a relay to 
click. While learning about both the OVMS code and the Leaf CAN bus I 
tried to simplify and document or make self-documenting the CAN message 
decoding and OVMS state logic. Hopefully I've succeeded.

I got remote climate control and remote charging working on my Gen 1 Leaf!

I added a FET driving a reed relay glued to the top of the circuit board 
and connected +12v through the relay to the Ring Indicate pin on the 
DIAG connector. I went  through one of the DB9 connector's supporting 
holes to access the bottom of the circuit board without having to go 
around the edge and foul the case. Ring Indicate seems like a good pin 
to use because it's an output from the DCE and we're literally saying 
"hey something is happening pay attention". RS232 has +12v logic so 
that's all good.

I unplugged the TCU and connected my new signal to pin 11 of the plug 
(see Page 160 of 
https://carmanuals2.com/nissan/leaf-2012-audio-visual-system-section-av-47811 
). This successfully activates the system and the car will respond to 
climate control and remote charging messages. So far the car hasn't 
complained that the TCU is unplugged. I didn't unplug the connection to 
the AV system head unit or the antenna, and I haven't looked at the AV 
system diagnostic to see if it has noticed.

Something in the OVMS startup briefly activates the car. net.c sets 
TRISC to set the output pins to outputs but doesn't set the initial 
values of the outputs. The data sheet says in "INITIALIZATION CONDITIONS 
FOR ALL REGISTERS" that the initial state is undefined on power up and 
doesn't change on reset.

Would anyone object to setting the initial value of output_gpo[0-3] low 
before switching them to outputs so the behavior is consistent?

Something got upset and caused the OVMS crash very often. I think this 
is related to running out of credit with my cell phone provider but 
unfortunately I didn't log the comms with the modem to confirm. I think 
my cell phone provider may sometimes allow packet data for a short time 
after startup even when you've run out of credit, and I think something 
in the "no you've can't talk anymore" caused the OVMS to crash. This 
wouldn't have been a problem except it took a while to work out what was 
wrong because it would work for a few hours or minutes and then stop. 
When it eventually stopped sending any data to the server at all and the 
OVMS stopped crashing too.

Whatever the cause was, this ran the 12v battery flat overnight twice.

Semi related story, my battery is very weak due to leaving the interior 
light on all day and when I received the  SMS from the OVMS that battery 
was dead (nice feature, but the threshold was too low) there was a 
misunderstanding and the car was turned on but not on enough to charge 
the battery -- it was plugged in so refused to activate the EV system 
and so the DCDC didn't start. When I got home the battery was at 6 
volts. This is related because I turned on the light to program the OVMS 
one morning and forgot to turn it off before going to work.

I'm going to document the GEN 1 modification and tidy up the climate 
control code and send a pull request. I've put changing the SOC 
calculations on hold for now as I want to get the climate control stuff 
in first.



More information about the OvmsDev mailing list