<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Regarding CAN timing, our ESP32CAN/SJA1000 configuration is mostly
    according to the SAE/CiA recommendations, with one exception: we
    generally enable multi (triple) sampling, regardless of the bus
    speed:<br>
    <br>
    <font face="monospace">esp32can::InitController():<br>
      […]<br>
        /* Set sampling<br>
         * 1 -> triple; the bus is sampled three times; recommended
      for low/medium speed buses     (class A and B) where filtering
      spikes on the bus line is beneficial<br>
         * 0 -> single; the bus is sampled once; recommended for high
      speed buses (SAE class C)*/<br>
        MODULE_ESP32CAN->BTR1.B.SAM=0x1;</font><br>
    <br>
    SAE defines "high speed" (class C) as speeds >= 125 kbit/s. See
    SAE J2284-1, -2 & -3, section 6.10.8 Data Sample Mode: "The data
    sampling shall always be set to single sample mode."<br>
    <br>
    If setting SAM=0 for 500 kbit/s, our timing setup is exactly as
    recommended by two tested SJA1000 timing calculators on the web.<br>
    <br>
    Maybe we should give that a try? I.e.<br>
    <br>
    <font face="monospace">  MODULE_ESP32CAN->BTR1.B.SAM =
      (MyESP32can->m_speed < CAN_SPEED_125KBPS) ? 1 : 0;</font><br>
    <br>
    Simon, can you try if that helps?<br>
    <br>
    But as you also use can2, I wouldn't rule out a timing issue with
    the MCP2515 configuration. At which speed do you have can2, and did
    you have some indication from the vehicle error codes regarding a
    specific bus?<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 17.01.25 um 17:49 schrieb Michael
      Balzer via OvmsDev:<br>
    </div>
    <blockquote type="cite"
      cite="mid:6b478377-d2f1-4e41-8f2d-bbb1bb1c5e37@expeedo.de">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      OK, I've got a new idea: CAN timing.<br>
      <br>
      Comparing our esp32can bit timing to the esp-idf driver's, there
      seem to be some differences:<br>
      <a class="moz-txt-link-freetext"
href="https://github.com/espressif/esp-idf/blob/master/components/hal/include/hal/twai_types_deprecated.h#L75"
        moz-do-not-send="true">https://github.com/espressif/esp-idf/blob/master/components/hal/include/hal/twai_types_deprecated.h#L75</a><br>
      <br>
      Transceivers are normally tolerant to small timing offsets. Maybe
      being off a little bit has no effect under normal conditions, but
      it has when the transceiver has to cope with a filled RX queue.
      That could be causing the transceiver to slide just out of sync.
      If the timing gets garbled, the transceiver would signal errors in
      the packets to the bus, possibly so many the vehicle ECUs decide
      to raise an error condition.<br>
      <br>
      Is that plausible?<br>
      <br>
      On why the new poller could be causing this (in combination with
      too slow processing by the vehicle): as mentioned, the standard
      CAN listener mechanism doesn't care about queue overflows. The
      poller does. `OvmsPollers::Queue_PollerFrame()` does a log call
      when Tx/Rx tracing is enabled, that could even block, but tracing
      is optional and only meant for debugging. Not optional is the
      overflow counting using an atomic uint32.<br>
      <br>
      The atomic types are said to be fast, but I never checked their
      actual implementation on the ESP32. Maybe they can block as well?<br>
      <br>
      @Simon: it would be an option to try commenting out the overflow
      counting, to see if that's causing the issue.<br>
      <br>
      Regards,<br>
      Michael<br>
      <br>
      <br>
      <div class="moz-cite-prefix">Am 17.01.25 um 15:37 schrieb Chris
        Box via OvmsDev:<br>
      </div>
      <blockquote type="cite"
cite="mid:010b019474b30c0d-45366923-5cdc-4a4b-a59d-cedf24ac5d5d-000000@eu-west-2.amazonses.com">
        <meta http-equiv="Content-Type"
          content="text/html; charset=UTF-8">
        <p>Yes, I can confirm I've had one experience of the Leaf
          switching to Neutral while driving, with a yellow warning
          symbol on the dash. It refused to reselect Drive until I had
          switched the car off and back on. Derek wasn't so lucky and he
          need to clear fault codes before the car would work.</p>
        <p>On returning home, I found OVMS was not accessible over a
          network. I didn't try a USB cable. Unplugging and reinserting
          the OBD cable caused OVMS to rejoin Wi-Fi. However the SD logs
          showed nothing from the time of the event. CAN writes are
          enabled, so it can perform SOC limiting.</p>
        <p>My car has been using this firmware since 21st November,
          based on the git master of that day. As a relatively new user
          of OVMS (only since October) I don't have much experience of
          older firmware.</p>
        <p>Perhaps a safeguard should be implemented before releasing a
          new stable firmware that will be automatically downloaded by
          Leaf owners. But I don't have the expertise to know what that
          safeguard should be. Derek's suggestion of 'only CAN write
          when parked' appears to be a good idea.</p>
        <p>Chris</p>
        <p><br>
        </p>
        <p id="reply-intro">On 2025-01-15 18:18, Derek Caudwell via
          OvmsDev wrote:</p>
        <blockquote type="cite"
style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
          <div id="replybody1">
            <div dir="auto">Since the following email I have high
              confidence the issue on the Leaf is related/caused by the
              poller as there has been no further occurrence and Chris
              has also experienced the car going to neutral on the new
              poller firmware. 
              <div dir="auto"><br>
                <div dir="auto">....</div>
                <div dir="auto">I haven't ruled out it being a fault
                  with my car yet. Shortly after it faulted the car was
                  run into so has been off the road for sometime, my
                  first step was to replace 12V battery. The ovms unit
                  is now unplugged and if it does not fault over the
                  next month while driving I'll be reasonably confident
                  it's ovms related.</div>
                <div dir="auto"> </div>
                <div dir="auto">Not sure which firmware version the
                  poller updates were included in but it was only after
                  upgrading to it that the errors occurred (which could
                  be coincidental however it has faulted twice more both
                  on version 3.3.004-141-gf729d82c). For periods where I
                  reverted to 3.3.003 it was fine.</div>
                <div dir="auto"> </div>
                <div dir="auto">It might be useful to have an extra
                  option on the enable can write to only enable it when
                  the car is parked/charging.</div>
              </div>
            </div>
            <br>
            <div class="v1gmail_quote v1gmail_quote_container"> </div>
          </div>
        </blockquote>
        <p><br>
        </p>
        <br>
        <fieldset class="moz-mime-attachment-header"></fieldset>
        <pre wrap="" class="moz-quote-pre">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
        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>
      <pre class="moz-signature" cols="72">-- 
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre wrap="" class="moz-quote-pre">_______________________________________________
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 * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
  </body>
</html>