<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>