[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