<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=""><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class="">I even have some more free IRAM now, it used to be down to ~1K and is now ~7K.</div></blockquote><div class=""><br class=""></div>That is very very good news. Using RELEASE build (rather than DEBUG), I got mine down to a usable level, but this should give us some breathing room.<div class=""><br class=""></div><div class="">Any noticeable improvement to the wifi issues?</div><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 8 Jul 2018, at 4:49 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="">
    The new esp-idf works good, I think I'll push the changes this
    evening.<br class="">
    <br class="">
    I even have some more free IRAM now, it used to be down to ~1K and
    is now ~7K.<br class="">
    <br class="">
    Remaining crashes recorded up to now:<br class="">
    <ul class="">
      <li class=""><tt class="">3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf
          v3.2-dev-168-g0fb2019f Jul 6 2018
          20:49:00),7,Crash,8,14,1,0,IllegalInstruction,0,0x00000000
          0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
          0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
          0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
          0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
          0x00000000 0x00000000 0x00000000 ,</tt><tt class=""><br class="">
        </tt><tt class=""><br class="">
        </tt></li>
      <li class=""><tt class="">3.1.008-32-g2fa3ab8-dirty/ota_0/edge (build idf
          v3.2-dev-168-g0fb2019f Jul 6 2018
          20:49:00),98,Crash,8,14,1,0,LoadProhibited,1,0x401165fc
          0x00060230 0x80106004 0x3fff0d40 0x3ffc4794 0x00000000
          0x3f4020ac 0x3fff1080 0x3fff1060 0x00000008 0x3ffed634
          0x00000000 0x00000001 0x3ffc41f5 0x000000ff 0x0000ff00
          0x00ff0000 0xff000000 0x00000004 0x0000001c 0x00000064
          0x4009ee01 0x4009ee11 0xffffffff ,0x401165fc 0x40106001
          0x400d3f9b 0x400d3ab5</tt><tt class=""><br class="">
        </tt><tt class="">→<br class="">
        </tt><tt class="">Using elf file:
          tmp/3.1.008-32-g2fa3ab8-dirty-elf/ovms3.elf</tt><tt class=""><br class="">
        </tt><tt class="">0x401165fc is in _vfprintf_r
          (../../../.././newlib/libc/stdio/vfprintf.c:1855).</tt><tt class=""><br class="">
        </tt><tt class="">0x40106001 is in _siprintf_r
          (../../../.././newlib/libc/stdio/siprintf.c:124).</tt><tt class=""><br class="">
        </tt><tt class="">0x400d3f9b is in std::__cxx11::basic_string<char,
          std::char_traits<char>, std::allocator<char>
          >::_M_construct<char*>(char*, char*,
          std::forward_iterator_tag)
(/home/balzer/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:215).</tt><tt class=""><br class="">
        </tt><tt class="">210          basic_string<_CharT, _Traits,
          _Alloc>::</tt><tt class=""><br class="">
        </tt><tt class="">211          _M_construct(_InIterator __beg,
          _InIterator __end,</tt><tt class=""><br class="">
        </tt><tt class="">212               std::forward_iterator_tag)</tt><tt class=""><br class="">
        </tt><tt class="">213          {</tt><tt class=""><br class="">
        </tt><tt class="">214        // NB: Not required, but considered best
          practice.</tt><tt class=""><br class="">
        </tt><tt class="">215        if (__gnu_cxx::__is_null_pointer(__beg)
          && __beg != __end)</tt><tt class=""><br class="">
        </tt><tt class="">216         
          std::__throw_logic_error(__N("basic_string::"</tt><tt class=""><br class="">
        </tt><tt class="">217                           "_M_construct null not
          valid"));</tt><tt class=""><br class="">
        </tt><tt class="">218    </tt><tt class=""><br class="">
        </tt><tt class="">219        size_type __dnew =
          static_cast<size_type>(std::distance(__beg, __end));</tt><tt class=""><br class="">
        </tt><tt class="">0x400d3ab5 is in canlog::LogStatus(canbus*,
          CAN_LogEntry_t, CAN_status_t const*)
(/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/can/src/canlog.cpp:297).</tt><tt class=""><br class="">
        </tt><tt class="">292        return;</tt><tt class=""><br class="">
        </tt><tt class="">293      if (CheckFilter(bus, type))</tt><tt class=""><br class="">
        </tt><tt class="">294        {</tt><tt class=""><br class="">
        </tt><tt class="">295        CAN_LogMsg_t msg;</tt><tt class=""><br class="">
        </tt><tt class="">296        msg.timestamp = esp_log_timestamp();</tt><tt class=""><br class="">
        </tt><tt class="">297        msg.bus = bus;</tt><tt class=""><br class="">
        </tt><tt class="">298        msg.type = type;</tt><tt class=""><br class="">
        </tt><tt class="">299        msg.status = *status;</tt><tt class=""><br class="">
        </tt><tt class="">300        m_msgcount++;</tt><tt class=""><br class="">
        </tt><tt class="">301        if (xQueueSend(m_queue, &msg, 0) !=
          pdTRUE)</tt><tt class=""><br class="">
          <br class="">
        </tt></li>
      <li class=""><tt class="">3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf
          v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),11,Crash,12,12,3,0,abort(),0,,0x40095e74
          0x4009606f 0x400ddaf7 0x40084e15 0x401e271d<br class="">
          → watchdog timeout, no more info<br class="">
        </tt></li>
    </ul>
    Regards,<br class="">
    Michael<br class="">
    <br class="">
    <br class="">
    <div class="moz-cite-prefix">Am 06.07.2018 um 22:07 schrieb Michael
      Balzer:<br class="">
    </div>
    <blockquote type="cite" cite="mid:27d5eae3-8bfe-ea5b-565b-d3f1b02206c3@expeedo.de" class="">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
      I've been using APCLIENT all the time and only had one crash that
      looked like a wifi problem. This really is a very specific
      problem. I also have a very good wifi signal, I can perfectly use
      my module's web UI while the car is in my garage two floors below.
      But I live in an uncrowded area, not much wifi competition.<br class="">
      <br class="">
      I have updated my esp-idf to the latest upstream master (it's v3.2
      now) and could build without any memory issues. The wifi driver
      now, besided loads of bug fixes, also supports CSI. Our code only
      needs a minor adjustment if you'd like to compile yourself, add…<br class="">
      <br class="">
      <tt class="">#define _SOC_SPI_PERIPH_H_ // don't include spi_periph.h (type
        conflict)</tt><br class="">
      <br class="">
      …in <tt class="">components/spinodma/spi_master_nodma.h</tt> before <tt class="">#include
        "driver/spi_common.h"</tt>.<br class="">
      <br class="">
      If you don't want to compile, the new build (with CSI enabled) is
      also on my server:<br class="">
      <br class="">
      <a class="moz-txt-link-freetext" href="http://ovms.dexters-web.de/firmware/ota/v3.1/edge/" moz-do-not-send="true">http://ovms.dexters-web.de/firmware/ota/v3.1/edge/</a><br class="">
      <br class="">
      …and now being installed by my beta testers.<br class="">
      <br class="">
      Regards,<br class="">
      Michael<br class="">
      <br class="">
      <br class="">
      <div class="moz-cite-prefix">Am 06.07.2018 um 16:28 schrieb Mark
        Webb-Johnson:<br class="">
      </div>
      <blockquote type="cite" cite="mid:62B5183F-67C4-4F40-898F-75DB5165B162@webb-johnson.net" class="">
        <meta http-equiv="Content-Type" content="text/html;
          charset=utf-8" class="">
        <div class="">My 2c:</div>
        <div class=""><br class="">
        </div>
        For the access points I normally use, it works 100% of the time
        for me. The only issue I had was when the SSID password was
        wrong on one of my access points (sharing the same SSID) and
        that was randomly causing me connection issues (every time the
        ESP32 picked it).
        <div class=""><br class="">
        </div>
        <div class="">
          <div class="">I also don’t use APCLIENT, and only use SCLIENT mode.
            I’ve found APCLIENT to be buggy as hell.</div>
        </div>
        <div class=""><br class="">
        </div>
        <div class="">But, I do have problems connecting to some access
          points. In particular phone hotspots. I suspect either bugs in
          the wifi stack, or some issue with channels.</div>
        <div class=""><br class="">
        </div>
        <div class="">The only thing I am wary of is that our current
          code does this:</div>
        <div class=""><br class="">
        </div>
        <blockquote style="margin: 0 0 0 40px; border: none; padding:
          0px;" class="">
          <div class="">esp_wifi_set_config…</div>
          <div class="">esp_wifi_start…</div>
          <div class="">esp_wifi_connect...</div>
        </blockquote>
        <div class="">
          <div class=""><br class="">
          </div>
          <div class="">But the Espressif examples have:</div>
          <div class=""><br class="">
          </div>
        </div>
        <blockquote style="margin: 0 0 0 40px; border: none; padding:
          0px;" class="">
          <div class="">
            <div class="">
              <div class="">esp_wifi_set_config…</div>
              <div class="">esp_wifi_start…</div>
              <div class="">Wait for SYSTEM_EVENT_STA_START</div>
            </div>
          </div>
        </blockquote>
        <blockquote style="margin: 0 0 0 40px; border: none; padding:
          0px;" class="">
          <blockquote style="margin: 0 0 0 40px; border: none; padding:
            0px;" class="">
            <div class="">
              <div class="">
                <div class="">esp_wifi_connect...</div>
              </div>
            </div>
          </blockquote>
        </blockquote>
        <div class="">
          <div class=""><br class="">
          </div>
          <div class="">I had that working the Espressif way in my big wifi
            refactor that never made it to production. But our current
            code doesn’t wait for the SYSTEM_EVENT_STA_START before
            calling esp_wifi_connect.</div>
          <div class=""><br class="">
          </div>
          <div class="">Regards, Mark.</div>
          <div class=""><br class="">
            <blockquote type="cite" class="">
              <div class="">On 6 Jul 2018, at 9:04 PM, Michael Balzer
                <<a href="mailto:dexter@expeedo.de" class="" moz-do-not-send="true">dexter@expeedo.de</a>>
                wrote:</div>
              <br class="Apple-interchange-newline">
              <div class="">
                <div class="">I've had similar reports regarding poor
                  wifi connectivity, and this seems to affect some
                  modules more than others (or may be channel/frequency
                  dependant?). One<br class="">
                  user has just 1-2 bars AP wifi signal with the module
                  placed ~ 50 cm away from the phone.<br class="">
                  <br class="">
                  I also still get reports of spurious strange crashes,
                  that mostly seem to be related to situations with poor
                  wifi signal. Some crash backtraces just are<br class="">
                  complete blank / null, and there is no crash report on
                  the USB output for these before reboot.<br class="">
                  <br class="">
                  Yesterday, Frank tried to perform some wifi scans. The
                  first scan went fine, the second never returned, he
                  had to power off the module. After reboot, all<br class="">
                  successive scans worked.<br class="">
                  <br class="">
                  Two users reported they occasionally cannot auth to
                  the OVMS AP with the correct password, and they can
                  then reconnect just by retrying for some minutes or by<br class="">
                  connecting & disconnecting another client to the
                  AP.<br class="">
                  <br class="">
                  I already had a look at the wifi tx power
                  configuration, it's at 100% by default.<br class="">
                  <br class="">
                  This all feels like a) we need to change something
                  about the antenna, and b) there are quite some bugs in
                  the wifi blob.<br class="">
                  <br class="">
                  Looking at <a href="https://github.com/espressif/esp32-wifi-lib/commits/master" class="" moz-do-not-send="true">https://github.com/espressif/esp32-wifi-lib/commits/master</a>
                  it seems there have been numerous wifi blob fixes
                  lately. Last time I checked I still was<br class="">
                  out of memory with the current esp-idf, I'll check
                  again.<br class="">
                  <br class="">
                  Regards,<br class="">
                  Michael<br class="">
                  <br class="">
                  <br class="">
                  Am 06.07.2018 um 01:48 schrieb Stephen Casner:<br class="">
                  <blockquote type="cite" class="">I find the wifi
                    performance of OVMS v3 to be poor, and I'm wondering<br class="">
                    how it might be improved.  I have a mix of thoughts
                    here.<br class="">
                    <br class="">
                    For both my own unit and that of Timothy Rodgers,
                    wifi reception in<br class="">
                    our garages was unusable.  You can blame that on too
                    much distance<br class="">
                    from the access point, but my iPhone and MacBook
                    both access the wifi<br class="">
                    just fine from my garage.  The wifi antenna in the
                    OVMS is probably<br class="">
                    smaller and its location within the metal framework
                    around the car's<br class="">
                    firewall may impede radio transmission.  Perhaps it
                    would be feasible<br class="">
                    to switch to an ESP32-WROVER-I with an external
                    antenna to improve<br class="">
                    performance, but that would be a big deal.  If there
                    is a transmit<br class="">
                    power adjustment, perhaps that could be increased?<br class="">
                    <br class="">
                    When Timothy parks his car next to his house, which
                    is about 50 feet<br class="">
                    closer than the garage, then the wifi reception was
                    good enough for<br class="">
                    the update to 3.1.008 to succeed.  But when he tries
                    to connect with<br class="">
                    the browser, page updates often time out, so it is
                    close to unusable.<br class="">
                    Perhaps we could improve usability by increasing the
                    timeout in our<br class="">
                    javascript to allow more time for TCP to retransmit?<br class="">
                    <br class="">
                    For my own unit, I switched from AP+client to just
                    client mode and at<br class="">
                    first it seemed that had improved the client
                    performance.  But still<br class="">
                    the next day I had no access from the iPhone app.
                     When I connected to<br class="">
                    the console to find out why I saw that server v2 was
                    repeatedly trying<br class="">
                    to connect and failing.  I'm presuming that the
                    cause was poor wifi<br class="">
                    connectivity since I was also not able to reach the
                    web server on the<br class="">
                    client address, although I have not proven that.
                     But since the client<br class="">
                    wifi was associated with the home AP and had an
                    address, the OVMS<br class="">
                    network routing preferred the wifi and did not try
                    to use the modem.<br class="">
                    For now I have resorted to turning off wifi.  I
                    suggest that the<br class="">
                    network routing algorithm be enhanced to back off to
                    use the modem if<br class="">
                    some number of attempts to connect to the server
                    over wifi have<br class="">
                    failed.  The iPhone will do this for itself (there
                    is a setting to<br class="">
                    enable this called Wi-Fi Assist).<br class="">
                    <br class="">
                    The behavior of repeated connection attempts and
                    failures by server v2<br class="">
                    seems to induce a more serious failure after a
                    while, perhaps due to<br class="">
                    some resource starvation.  At that point there is a
                    failure message<br class="">
                    "mg_connect(<a href="http://api.openvehicles.com:6867/" class="" moz-do-not-send="true">api.openvehicles.com:6867</a>)
                    failed: cannot parse address"<br class="">
                    every time server v2 tries to connect.  I expect
                    that is a bug that<br class="">
                    could be fixed.<br class="">
                    <br class="">
                    Lastly, since we may encounter situations where
                    network communication<br class="">
                    is not working, we should facilitate access to the
                    console.  When I<br class="">
                    was trying to help Timothy change a location radius
                    setting remotely<br class="">
                    by phone and the web browser was timing out, I
                    suggested that he find<br class="">
                    a micro-USB cable so he could connect to the
                    console.  But then I<br class="">
                    realized he would not have any application on his
                    laptop that would<br class="">
                    allow him to connect to the console.  Developers use
                    "make monitor" in<br class="">
                    the software development cycle, but users won't have
                    that tool.  I<br class="">
                    have my own program on the MacBook that I use as an
                    alternative when I<br class="">
                    don't want to induce a reset when I connect.  But is
                    there a simple<br class="">
                    program for Windows suitable for non-developer users
                    that can connect<br class="">
                    to the OVMS console?<br class="">
                    <br class="">
                                                       -- Steve<br class="">
                    _______________________________________________<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="">
                  </blockquote>
                  <br class="">
                  -- <br class="">
                  Michael Balzer * Helkenberger Weg 9 * D-58256
                  Ennepetal<br class="">
                  Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<br class="">
                  <br class="">
                  <br class="">
                  _______________________________________________<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>
              </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="">
      <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
      <!--'"--><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>