<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="">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><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="">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 wrap="" class="">_______________________________________________
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 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>