<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Mark remembers correctly. In practice I found that having OBD2ECU
control when to turn on/off the external 12v supply required it to
make assumptions on what sort of OBDII device was attached, and when
that sort of device needed to have power. A normal HUD would be
turned on with the car being "on", and off when "off", for example,
but if I had my SyncUpDrive dongle attached it was better when it
was triggered from Awake and Asleep (because that tracks with the 12
accessory outlet in the car), and a telemetry dongle would probably
want to just stay on. Since these are simple 1-line event scripts,
I decided it's best to just do it that way. I believe it's
documented as such in the the OBD2ECU chapter.<br>
<br>
The ideal situation from a race perspective is to have OBD2ECU
started before the Ext12v is enabled, so ext12v would be last in the
sequence. But this is only important for the initial power-up
event, so that the device is working before (and without) the event
scripts kicking in for the best out-of-box experience. So whether
we get it right or wrong in Auto, the first time the car hits the
script events (assuming they get installed), the scripts become
responsible for controlling external 12v power.<br>
<br>
Bottom line, if having external 12v power enabled before starting
OBD2ECU in the auto init processing makes the OVMS module itself
more reliable or supportable, that is probably more important than
guaranteeing there's no race condition with the obdii device
powering up too soon. <br>
<br>
Greg<br>
<br>
<br>
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:C3B2FFB5-EFA9-41BD-A6C7-204112A4F0F5@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
I seem to remember Greg and I discussing having an option to bring
up the ext12v when obd2ecu started, or when car was on/off, etc. I
think we decided it wouldn’t be hard to do, but perhaps better
left to scripts?
<div class=""><br class="">
</div>
<div class="">We would still have to deal with the case of ext12v
being used for something other than obd2ecu, so having it _also_
as auto init capable seems fine.</div>
<div class=""><br class="">
</div>
<div class="">P.S. One other point on auto init is that I think
the pcp base object can be used. Perhaps a power mode (like off,
on, etc), or just a standard virtual AutoInit function. The only
auto init module not currently using pcp is vehicle, but that
would be trivial to fix.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 28 Aug 2018, at 2:51 PM, Michael Balzer
<<a href="mailto:dexter@expeedo.de" class=""
moz-do-not-send="true">dexter@expeedo.de</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> In case an
obd2ecu device has that race condition, wouldn't it be
better to let the obd2ecu startup code control the
ext12v power?<br class="">
<br class="">
I.e. leave the general auto init config to user control,
and add a "late ext12v enable" option to obd2ecu.<br
class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 28.08.2018 um 08:45
schrieb Mark Webb-Johnson:<br class="">
</div>
<blockquote type="cite"
cite="mid:5EBCB16E-FAB0-4F0E-BE4D-35AA26AFDAEB@webb-johnson.net"
class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
Greg, Michael,
<div class=""><br class="">
</div>
<div class="">I was trying to keep the ext12v close to
obd2ecu for that reason. Don’t want to power it up
too early, as we need obd2ecu up and running for the
external hud to talk to.</div>
<div class=""><br class="">
</div>
<div class="">No fixed ideas on the use of ext12v. The
obvious use case is some sort of external display -
and that could communicate over any one of a number
of methods (but most likely bluetooth or can bus).</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 28 Aug 2018, at 2:37 PM,
Michael Balzer <<a
href="mailto:dexter@expeedo.de" class=""
moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
As enabling the external 12V has near zero
crash potential it doesn't hurt doing that
in step 1.<br class="">
<br class="">
That also allows to power e.g. a mobile wifi
router from that line (just an idea, haven't
tried that).<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 28.08.2018
um 08:25 schrieb Greg D.:<br class="">
</div>
<blockquote type="cite"
cite="mid:11163a60-e8c5-9528-ad7e-66a723ee51b6@gmail.com"
class="">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8"
class="">
Hi Mark,<br class="">
<br class="">
One thing to consider is that you've got a
small race condition with the external
device powering up before the code that
services it is ready. Most devices retry,
and the OBD2ECU code starts quickly, but
some devices will drop into alternative
modes if that initial handshake fails.
Typically not fatal (using extended mode
instead of standard, for example), but
it's a race none the less.<br class="">
<br class="">
What sort of devices were you thinking of
for driving with the external 12v power?
Any plans for a service other than OBD2ECU
to drive the external CAN bus in support
of it? OBD2ECU is certainly not the only
option.<br class="">
<br class="">
Greg<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Mark
Webb-Johnson wrote:<br class="">
</div>
<blockquote type="cite"
cite="mid:612BDA77-6649-4CFF-AC76-C80F7882555E@webb-johnson.net"
class="">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8"
class="">
The order I suggested was loosely based
on trying to maintain connectivity (even
if a module is causing a crash). I’ve
put the least used modules (or those not
related to connectivity) at the bottom
of the list, and the most critical
modules (but hopefully most reliable) at
the top.
<div class=""><br class="">
</div>
<div class="">Currently, Server V3
should be at the bottom, but I am
hoping it will improve in reliability.
Perhaps it should be after SIMCOM for
the moment.</div>
<div class=""><br class="">
</div>
<div class="">The idea behind putting
external 12v reasonable high (before
vehicle) was (a) it is highly unlikely
to cause us any issues, and (b)
external displays may provide status
and other indications useful to
identify problems. It could probably
swap with ‘vehicle’, without much
impact.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 28 Aug 2018, at
1:45 AM, Greg D. <<a
href="mailto:gregd2350@gmail.com"
class=""
moz-do-not-send="true">gregd2350@gmail.com</a>>
wrote:</div>
<br
class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type"
content="text/html;
charset=UTF-8" class="">
<div text="#000000"
bgcolor="#FFFFFF" class=""> Hi
Mark,<br class="">
<br class="">
The new proposal sounds like a
good idea (in spite of putting
OBD2ECU at the bottom {sniff}
). If we someday get the
ability to configure the
module from the Modem, would
it be a good idea to move
SIMCOM up in the priority
chain, to allow for remote
repair if either of the
servers is causing the
trouble? The V2 server has
been pretty stable for a long
time, but I wonder about V3.<br
class="">
<br class="">
Curious why you put External
12v above OBD2ECU. I'd move
12v to the bottom, so you
don't turn on the external
device until the server is
running. What else is
dependent on the external 12v
supply?<br class="">
<br class="">
Greg<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Mark
Webb-Johnson wrote:<br
class="">
</div>
<blockquote type="cite"
cite="mid:83CF5C1A-C18D-4791-961F-529144DD4A31@webb-johnson.net"
class="">
<meta
http-equiv="Content-Type"
content="text/html;
charset=UTF-8" class="">
Last week’s 3.1.009 issue
with Tesla Roadsters was
interesting. Looking at the
car I saw with the problem,
it was booting, crashing
when the vehicle module
received a certain CAN bus
message (triggering the
issue), and rebooting. It
would do this 5 times, until
it his
the AUTO_INIT_INHIBIT_CRASHCOUNT
count, and then AutoInit
inhibit would kick in, and
it would end up sitting idle
with nothing loaded (and no
network connection). The
approach worked very well,
and prevented an endless
reboot loop.
<div class=""><br class="">
<div class="">However, we
ended up with a car
unable to connect to the
network, and requiring a
console cable and laptop
to recover. I’ve been
thinking about bluetooth
(which is intended to
provide a smartphone
connection irrespective
of wifi configuration),
how that might work with
a completely
unconfigured module (for
initial configuration),
and I can suggest a
workaround to try to
improve this…</div>
</div>
<div class=""><br class="">
</div>
<div class="">At the moment,
the order of autoinit is:</div>
<div class=""><br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">External
12V</li>
<li class="">Wifi</li>
<li class="">Modem
SIMCOM</li>
<li class="">Vehicle</li>
<li class="">OBD2ECU</li>
<li class="">Server V2</li>
<li class="">Server V3</li>
</ol>
</div>
<div class=""><br class="">
</div>
<div class="">None of those
run if the early crash
count >
AUTO_INIT_INHIBIT_CRASHCOUNT
(coded as a constant 5).</div>
<div class=""><br class="">
</div>
<div class="">My suggestion
is to change this as
follows:</div>
<div class=""><br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">Wifi</li>
<li class="">Bluetooth</li>
<li class="">Server V2</li>
<li class="">Server V3</li>
<li class="">Modem
SIMCOM</li>
<li class="">External
12V</li>
<li class="">Vehicle</li>
<li class="">ODB2ECU</li>
</ol>
</div>
<div class=""><br class="">
</div>
<div class="">But also to
change that logic that:</div>
<div class="">
<ul class="MailOutline">
<li class="">#8 will
start if early crash
count >
AUTO_INIT_INHIBIT_CRASHCOUNT</li>
<li class="">#7 will
start if early crash
count >
AUTO_INIT_INHIBIT_CRASHCOUNT+1</li>
<li class="">#6 will
start if early crash
count >
AUTO_INIT_INHIBIT_CRASHCOUNT+2</li>
<li class="">etc.</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">This will mean
that once we hit the
AUTO_INIT_INHIBIT_CRASHCOUNT
limit, we turn off the
least required module
(OBD2ECU), then continue
to see if that solves the
problem. If not (ie; we
crash and reboot), then we
try turning off the
Vehicle module and
OBD2ECU, then continue to
see if that solves the
problem. etc.</div>
<div class=""><br class="">
</div>
<div class="">In the example
case of the Tesla Roadster
vehicle module causing the
issue, this revised
approach would leave us up
and running with Wifi and
a Server Connection (but
no vehicle data). Checking
the module would identify
the problem quite quickly
(and remotely). Starting
the vehicle module
manually would presumably
result in a crash and we
would pretty quickly get
an idea of the cause
(especially if we added a
command to show the status
of AutoInit, what was
started, and what wasn’t
because it is causing a
crash). I think we could
even issue an Alert
notification in the case
where autoinit recovered
after inhibiting certain
modules (but not all).</div>
<div class=""><br class="">
</div>
<div class="">The
disadvantage is that we
would crash more (up to 13
times, vs 5) in the case
the system is badly messed
up.</div>
<div class=""><br class="">
</div>
<div class="">What do people
think? Does this make
sense?</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
</div>
<br class="">
<fieldset
class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
</div>
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a
href="mailto:OvmsDev@lists.openvehicles.com"
class=""
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a
href="mailto:OvmsDev@lists.openvehicles.com"
class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br
class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com" class=""
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</body>
</html>