<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Steve,<br>
    <br>
    thanks, that's perfect. The failure handling works as designed in
    your case.<br>
    <br>
    Regarding your question: <br>
    <blockquote type="cite">
      <div>It does prompt me to ask a question that I had - On the i3,
        if you do something like send a lock from the key or the
        Connected Drive APP then the OBD-II comes alive but goes asleep
        again in less than a minute.</div>
      <div><br>
      </div>
      <div>if I have a PID that I poll infrequently - say every 120
        seconds.  What happens in this case?  Would they be seen as
        "overdue" when the bus comes alive and polled immediately, or is
        it a matter of luck if the 120th tick arrives at a time when the
        bus is alive?<br>
      </div>
      <div><br>
      </div>
      <div>If the latter I need to poll even things like the VIN every
        10 seconds to make sure I get it before the bus goes to sleep
        again.</div>
    </blockquote>
    <br>
    With the old handling, the queued frames would have get sent as soon
    as the bus got awake again. That's nasty, as the frames may have
    been for a specific task (e.g. some protocol part), and should not
    be sent to a just woken up car. That could produce any sort of
    problem up to queued OBD writes corrupting the car memory. It was
    also nasty the driver would then send the whole TX queue at once,
    flooding the bus. A vehicle could see that as a malicious activity
    and block access.<br>
    <br>
    The new handling will abort the transmission as soon as the CAN
    controller runs into the retransmission limit (128 tries, formally
    CAN error-passive mode).<br>
    <br>
    So you now need to "ping" the car with some simple read or session
    state request, and check if a response comes in to determine if the
    bus is online. If using the poller, you'll get a respective
    Incoming…() callback. If you don't use the poller, you can set the
    TX callback pointer on the frame you send. The TX callback is called
    with a success indicator, so you can know a frame has been sent even
    if you don't get a response from the device.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 08.01.21 um 09:33 schrieb Steve
      Davies:<br>
    </div>
    <blockquote type="cite"
cite="mid:CABFTEGXQDiknKXzP0fFV++3RVNCmbd=wfP9SnJUShzeS_t1bkQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Hi Michael,
        <div><br>
        </div>
        <div>Here's the log from a test on my car with your branch</div>
        <div><br>
        </div>
        <div>I started the car, left it for a while, then shut it down
          and waited until the OBD-II first went to "not getting replies
          to my requests" and then to "not sending anything at all".</div>
        <div><br>
        </div>
        <div>Hope its helpful.</div>
        <div><br>
        </div>
        <div><a
href="https://drive.google.com/file/d/1AavD41HCykYrn-BxQXNufu2dT_UVCXYU/view?usp=sharing"
            moz-do-not-send="true">https://drive.google.com/file/d/1AavD41HCykYrn-BxQXNufu2dT_UVCXYU/view?usp=sharing</a><br>
        </div>
        <div><br>
        </div>
        <div>Steve</div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Fri, 8 Jan 2021 at 08:22,
          Steve Davies <<a href="mailto:steve@telviva.co.za"
            moz-do-not-send="true">steve@telviva.co.za</a>> wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div dir="ltr">Hi Michael,
            <div><br>
            </div>
            <div>The change looks helpful, thanks.  I'll try it during
              the course of the day.</div>
            <div><br>
            </div>
            <div>It does prompt me to ask a question that I had - On the
              i3, if you do something like send a lock from the key or
              the Connected Drive APP then the OBD-II comes alive but
              goes asleep again in less than a minute.</div>
            <div><br>
            </div>
            <div>if I have a PID that I poll infrequently - say every
              120 seconds.  What happens in this case?  Would they be
              seen as "overdue" when the bus comes alive and polled
              immediately, or is it a matter of luck if the 120th tick
              arrives at a time when the bus is alive?<br>
            </div>
            <div><br>
            </div>
            <div>If the latter I need to poll even things like the VIN
              every 10 seconds to make sure I get it before the bus goes
              to sleep again.</div>
            <div><br>
            </div>
            <div>Thanks,</div>
            <div>Steve</div>
            <div><br>
            </div>
          </div>
          <br>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">On Thu, 7 Jan 2021 at
              18:22, Michael Balzer <<a
                href="mailto:dexter@expeedo.de" target="_blank"
                moz-do-not-send="true">dexter@expeedo.de</a>> wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div> Everyone,<br>
                <br>
                please pull & test the new "can-txfail-fix" branch.
                It's up to date and includes the BMW i3 code already.<br>
                <br>
                I need to get feedback from users of both can1
                (esp32can) & can2/3/4 (mcp2515), as changes had to
                be made to both drivers.<br>
                <br>
                I'll quote from my commit: <br>
                <a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/c94592a11ad2c989e65313d23a8876cf38787d70"
                  target="_blank" moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/c94592a11ad2c989e65313d23a8876cf38787d70</a><br>
                <br>
                <div
style="box-sizing:border-box;display:block;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe
                  UI",Helvetica,Arial,sans-serif,"Apple Color
                  Emoji","Segoe UI
Emoji";font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">
                  <pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace;font-size:13px;margin-top:10px;margin-bottom:0px;max-width:100%;line-height:1.45;white-space:pre-wrap;overflow:visible">Design goals:
- any TX can either fail or succeed, the result state is terminal
- the respective TX callback is called exactly once
- transmissions fail on reaching the error-passive bus state
  and on message/bus errors while in error-passive state
- a failed TX will be aborted (no retries after bus recovery),
  i.e. will be retried at most 128 times (in error-active phase)
- reduce excessive CAN error logging
- reduce excessive interrupt load with switched-off buses

This results in the application being able to reliably detect a
switched-off vehicle bus by the TX callback's success indicator.
It also results in frames no longer being held in the TX buffer
or added to the TX queue when the bus is switched off. The
application can now rely on getting a clean bus state on every
reconnect, without any queued old frames to be sent automatically.

Secondary benefit from aborting the transmission is, the module
doesn't need to handle the load from the continuously triggered
CAN error interrupts by retransmission attempts in error-passive
state.</pre>
                </div>
                <br>
                Reason for this was a) Steve's question on aborting
                transmissions / flushing the queue and b) my new car now
                also switching off the bus, with the annoying effect of
                a frozen can1 every 2-3 days, needing to reboot the
                module. I'm not sure yet if the freeze issue is solved,
                but I haven't had it since running these changes on my
                module.<br>
                <br>
                The other issue of the transceivers resending frames
                queued long ago may have caused all sorts of strange
                & unrepeatable issues. I remember the VW crew having
                problems that fell into this category.<br>
                <br>
                I've verified the new MCP2515 implementation only on my
                workbench (with an Arduino as the CAN tester), so real
                life tests are necessary.<br>
                <br>
                Thanks,<br>
                Michael<br>
                <br>
                <pre cols="72">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
              </div>
              _______________________________________________<br>
              OvmsDev mailing list<br>
              <a href="mailto:OvmsDev@lists.openvehicles.com"
                target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
              <a
                href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
                rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
            </blockquote>
          </div>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-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>
    <pre class="moz-signature" cols="72">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
  </body>
</html>