<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Mark,<br>
<br>
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>
<br>
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>
<br>
Greg<br>
<br>
<br>
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:612BDA77-6649-4CFF-AC76-C80F7882555E@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
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><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">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>