<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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="">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">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 wrap="" class="">_______________________________________________
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 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="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>