[Ovmsdev] Keeping OBD-II alive

Steve Davies steve at telviva.co.za
Sat Dec 26 22:35:08 HKT 2020

Hi all,

Merry Christmas if you celebrate - beautiful hot weather here in Cape Town
but surely a different story for most of you!

(Michael: Thanks for the help with that "BC".)

My car's OBD currently goes off after a while whenever it's not READY (to
drive) (whether charging or not),

This obviously affects the usability on my car, especially when
charging since you can't follow the charging process properly.

I did find that if you use the remote key it will wake things up; if you
use BMW Connected drive app to lock/unlock then that also wakes things up.

I see that the MGEV seems similar - the docs for that car say:

The car is accessible over the OBD port when it is running (ignition on)
and for around
40 seconds after it is turned off or the car is "tweaked" (lock button
pushed, etc).

The OBD port may be kept awake by using the "tester present" message to the
gateway ECU.
This keeps a lot of systems awake and draws roughly 5A on the 12V bus, so
it's not a good
idea to do.

If the car is unlocked, the gateway can be woken if the car is unlocked by
pinging the
"tester present" message continuously every 100ms until it responds. If the
car is
locked this simply causes the gateway to go into some kind of zombie proxy
mode that isn't
very useful. If the car is locked, the gateway may be woken by sending a
session 2
command every 250ms to the gateway.

I'm looking at the MGEV code to see how it's done - can see the gist of it.

It looks like Chris Staite was the author of the MGEV support - Chris are
you on the list?  Can you answer some questions for me or give me an
outline as to how it goes?

My logic would be that if the car is charging it doesn't do much harm to
try to keep the OBD-II responsive.  I suppose it diverts a little power
from charging, but when you are on a long trip and fast charging somewhere
you want to know if charging stops!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201226/55ba1304/attachment-0001.htm>

More information about the OvmsDev mailing list