[Ovmsdev] Poor wifi performance
Michael Balzer
dexter at expeedo.de
Sun Jul 8 16:49:10 HKT 2018
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180708/1c237a4b/attachment.htm>
More information about the OvmsDev
mailing list