[Ovmsdev] Poor wifi performance
Michael Balzer
dexter at expeedo.de
Mon Jul 9 06:14:51 HKT 2018
Sorry, no user feedback up to now on the wifi issues. As I don't have them myself, I need to wait for feedback. But no news means it's at least not worse than
before ;)
Anyway, I've pushed the changes and esp-idf update.
@all: you need to update your esp-idf to build the current version:
* cd $IDF_PATH
* git pull
* git submodule update --recursive
Regards,
Michael
Am 08.07.2018 um 10:59 schrieb Mark Webb-Johnson:
>> I even have some more free IRAM now, it used to be down to ~1K and is now ~7K.
>
> 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.
>
> Any noticeable improvement to the wifi issues?
>
> Regards, Mark.
>
>> On 8 Jul 2018, at 4:49 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>> The new esp-idf works good, I think I'll push the changes this evening.
>>
>> I even have some more free IRAM now, it used to be down to ~1K and is now ~7K.
>>
>> Remaining crashes recorded up to now:
>>
>> * 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 ,
>>
>> * 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
>> →
>> Using elf file: tmp/3.1.008-32-g2fa3ab8-dirty-elf/ovms3.elf
>> 0x401165fc is in _vfprintf_r (../../../.././newlib/libc/stdio/vfprintf.c:1855).
>> 0x40106001 is in _siprintf_r (../../../.././newlib/libc/stdio/siprintf.c:124).
>> 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).
>> 210 basic_string<_CharT, _Traits, _Alloc>::
>> 211 _M_construct(_InIterator __beg, _InIterator __end,
>> 212 std::forward_iterator_tag)
>> 213 {
>> 214 // NB: Not required, but considered best practice.
>> 215 if (__gnu_cxx::__is_null_pointer(__beg) && __beg != __end)
>> 216 std::__throw_logic_error(__N("basic_string::"
>> 217 "_M_construct null not valid"));
>> 218
>> 219 size_type __dnew = static_cast<size_type>(std::distance(__beg, __end));
>> 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).
>> 292 return;
>> 293 if (CheckFilter(bus, type))
>> 294 {
>> 295 CAN_LogMsg_t msg;
>> 296 msg.timestamp = esp_log_timestamp();
>> 297 msg.bus = bus;
>> 298 msg.type = type;
>> 299 msg.status = *status;
>> 300 m_msgcount++;
>> 301 if (xQueueSend(m_queue, &msg, 0) != pdTRUE)
>>
>> * 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
>> → watchdog timeout, no more info
>>
>> Regards,
>> Michael
>>
>>
>> Am 06.07.2018 um 22:07 schrieb Michael Balzer:
>>> 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.
>>>
>>> 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…
>>>
>>> #define _SOC_SPI_PERIPH_H_ // don't include spi_periph.h (type conflict)
>>>
>>> …in components/spinodma/spi_master_nodma.h before #include "driver/spi_common.h".
>>>
>>> If you don't want to compile, the new build (with CSI enabled) is also on my server:
>>>
>>> http://ovms.dexters-web.de/firmware/ota/v3.1/edge/
>>>
>>> …and now being installed by my beta testers.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> Am 06.07.2018 um 16:28 schrieb Mark Webb-Johnson:
>>>> My 2c:
>>>>
>>>> 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).
>>>>
>>>> I also don’t use APCLIENT, and only use SCLIENT mode. I’ve found APCLIENT to be buggy as hell.
>>>>
>>>> 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.
>>>>
>>>> The only thing I am wary of is that our current code does this:
>>>>
>>>> esp_wifi_set_config…
>>>> esp_wifi_start…
>>>> esp_wifi_connect...
>>>>
>>>>
>>>> But the Espressif examples have:
>>>>
>>>> esp_wifi_set_config…
>>>> esp_wifi_start…
>>>> Wait for SYSTEM_EVENT_STA_START
>>>>
>>>> esp_wifi_connect...
>>>>
>>>>
>>>> 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.
>>>>
>>>> Regards, Mark.
>>>>
>>>>> On 6 Jul 2018, at 9:04 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>>>
>>>>> 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
>>>>> user has just 1-2 bars AP wifi signal with the module placed ~ 50 cm away from the phone.
>>>>>
>>>>> 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
>>>>> complete blank / null, and there is no crash report on the USB output for these before reboot.
>>>>>
>>>>> 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
>>>>> successive scans worked.
>>>>>
>>>>> 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
>>>>> connecting & disconnecting another client to the AP.
>>>>>
>>>>> I already had a look at the wifi tx power configuration, it's at 100% by default.
>>>>>
>>>>> This all feels like a) we need to change something about the antenna, and b) there are quite some bugs in the wifi blob.
>>>>>
>>>>> Looking at https://github.com/espressif/esp32-wifi-lib/commits/master it seems there have been numerous wifi blob fixes lately. Last time I checked I
>>>>> still was
>>>>> out of memory with the current esp-idf, I'll check again.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> Am 06.07.2018 um 01:48 schrieb Stephen Casner:
>>>>>> I find the wifi performance of OVMS v3 to be poor, and I'm wondering
>>>>>> how it might be improved. I have a mix of thoughts here.
>>>>>>
>>>>>> For both my own unit and that of Timothy Rodgers, wifi reception in
>>>>>> our garages was unusable. You can blame that on too much distance
>>>>>> from the access point, but my iPhone and MacBook both access the wifi
>>>>>> just fine from my garage. The wifi antenna in the OVMS is probably
>>>>>> smaller and its location within the metal framework around the car's
>>>>>> firewall may impede radio transmission. Perhaps it would be feasible
>>>>>> to switch to an ESP32-WROVER-I with an external antenna to improve
>>>>>> performance, but that would be a big deal. If there is a transmit
>>>>>> power adjustment, perhaps that could be increased?
>>>>>>
>>>>>> When Timothy parks his car next to his house, which is about 50 feet
>>>>>> closer than the garage, then the wifi reception was good enough for
>>>>>> the update to 3.1.008 to succeed. But when he tries to connect with
>>>>>> the browser, page updates often time out, so it is close to unusable.
>>>>>> Perhaps we could improve usability by increasing the timeout in our
>>>>>> javascript to allow more time for TCP to retransmit?
>>>>>>
>>>>>> For my own unit, I switched from AP+client to just client mode and at
>>>>>> first it seemed that had improved the client performance. But still
>>>>>> the next day I had no access from the iPhone app. When I connected to
>>>>>> the console to find out why I saw that server v2 was repeatedly trying
>>>>>> to connect and failing. I'm presuming that the cause was poor wifi
>>>>>> connectivity since I was also not able to reach the web server on the
>>>>>> client address, although I have not proven that. But since the client
>>>>>> wifi was associated with the home AP and had an address, the OVMS
>>>>>> network routing preferred the wifi and did not try to use the modem.
>>>>>> For now I have resorted to turning off wifi. I suggest that the
>>>>>> network routing algorithm be enhanced to back off to use the modem if
>>>>>> some number of attempts to connect to the server over wifi have
>>>>>> failed. The iPhone will do this for itself (there is a setting to
>>>>>> enable this called Wi-Fi Assist).
>>>>>>
>>>>>> The behavior of repeated connection attempts and failures by server v2
>>>>>> seems to induce a more serious failure after a while, perhaps due to
>>>>>> some resource starvation. At that point there is a failure message
>>>>>> "mg_connect(api.openvehicles.com:6867 <http://api.openvehicles.com:6867/>) failed: cannot parse address"
>>>>>> every time server v2 tries to connect. I expect that is a bug that
>>>>>> could be fixed.
>>>>>>
>>>>>> Lastly, since we may encounter situations where network communication
>>>>>> is not working, we should facilitate access to the console. When I
>>>>>> was trying to help Timothy change a location radius setting remotely
>>>>>> by phone and the web browser was timing out, I suggested that he find
>>>>>> a micro-USB cable so he could connect to the console. But then I
>>>>>> realized he would not have any application on his laptop that would
>>>>>> allow him to connect to the console. Developers use "make monitor" in
>>>>>> the software development cycle, but users won't have that tool. I
>>>>>> have my own program on the MacBook that I use as an alternative when I
>>>>>> don't want to induce a reset when I connect. But is there a simple
>>>>>> program for Windows suitable for non-developer users that can connect
>>>>>> to the OVMS console?
>>>>>>
>>>>>> -- Steve
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>
>>>>> --
>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>> --
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> --
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180709/2b8b6d31/attachment.htm>
More information about the OvmsDev
mailing list