After 1.0.6 update WiFi won't connect to other network // connection time increased #4980
Comments
|
can you enable debug to Verbose and post the log? WiFi is working fine on my end |
|
Sure: 1.0.5 log: And here is 1.0.6 and only AP working ok: |
|
I think you should wait a bit longer than 2 seconds :) logs does not show that connect failes |
Fair enough but why I NEVER had any problems with 2s waiting time? Never ever had any issue and I do it this FW for over a year. Now with 1.0.6 it NEVER connects within this 2s period. What you changed in the code it lost its performance? I think this is worth finding out to be honest. I am happy to run some tests if you want. Changing to 3000 "solved" issue but I call it a bodge as performance loss of 1s is big thing don't you think? I ran some benchmarks and on 1.0.6 I got between 2200-2420ms On 1.0.5 on other hand I have 220ms - 1100ms (while most being around 260-330ms!) What is the reason behind this huge performance loss? I will stay on 1.0.5 till this is resolved. |
handmade0octopus
changed the title
|
ecocurious2/MultiGeiger#408 we also encounter wifi issues with 1.0.6. |
|
1.0.6 also broke my code, not much to report at this point, but I'll keep you posted.
All the above working fine before upgrade. Looks like WiFi is causing a pulse in GPIO39 and this is an issue for certain boards that rely on this pin. |
|
Same issue here using WiFiMulti; upgrading to 1.0.6 has broke my WiFi connection code as well with all the same issues listed above. It feels like the overall connection process in 1.0.6 is taking significantly longer than 1.0.5 which has caused a lot of people's timeouts to trigger. Wifi connections under 1.0.5 was working 99.5% of the time with the 0.5% usually attributable to external factors. I'll revert to 1.0.5 for now but keen to see this issue solved as there are other upgrades to the ESP32 library that has improved, e.g. SD_MMC library. |
|
I just wanted to chime in with my own experiences. I've had code running on a esp32 (Adafruit's Huzzah32) for more than 6 months before breaking my device last night with all the latest versions recently updated in the Arduino interface. After finding this thread, I did some quick tests rolling back from 1.0.6 to 1.0.5 (from February) and then to 1.0.4 (from October).
I duplicated these results using the stock WiFi example code, using "Simple Time" as a baseline against "WiFiMulti" example code (only adding serial print commands with millis() for showing time before and after connect), and the WiFiMulti connection was slower with 1.0.5 and 1.0.6 quite consistently, with similar times as listed above. Note, I was using just 2 sets of credentials for WiFiMulti in all of these tests, with only 1 of the 2 ssids within range. |
|
[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions. |
|
If nobody fixed this, there is no reason for a stupid stale bot closing this. |
|
[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future. |
|
Hello, any updates on this? recently updated all the way from 1.0.4 to 2.0.0, and wifi connection time became 10 times slower. I'm not using "WiFiMulti", just the regular "WiFi" Here are some logs: First time, doesn't work. Second time, it works. Before updating, i was using v1.0.4, everything worked fine. Sometimes i get a succesfull connection on first try, and sometimes on second try. |
|
Hi, |
|
I have the same issue. Connection times got slower. |
|
2.0.2 with all the latest updates on the site on 23.01.2022 nothing has been fixed((( |
VojtechBartoska
moved this from Todo
to Under investigation
in Arduino ESP32 Core Project Roadmap
|
Hello, there has been a recent update of the Arduino-ESP32 core to 2.0.3-RC1 and on my side, it seems that connection time got back to previous values similar to pre-1.0.6 |
|
Hi, it was not possible to compile any example, G:!ya!arduino\arduino\arduino-builder -dump-prefs -logger=machine -hardware G:!ya!arduino\arduino\hardware -hardware C:\Users\papa\AppData\Local\Arduino15\packages -tools G:!ya!arduino\arduino\tools-builder -tools G:!ya!arduino\arduino\hardware\tools\avr -tools C:\Users\papa\AppData\Local\Arduino15\packages -libraries C:\Users\papa\Documents\Arduino\libraries -fqbn=esp32:esp32:esp32:PSRAM=disabled,PartitionScheme=default,CPUFreq=240,FlashMode=qio,FlashFreq=80,FlashSize=4M,UploadSpeed=921600,LoopCore=1,EventsCore=1,DebugLevel=none -ide-version=10816 -build-path t:\Temp\arduino_build_483212 -warnings=all -build-cache t:\Temp\arduino_cache_610823 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.riscv32-esp-elf-gcc.path=C:\Users\papa\AppData\Local\Arduino15\packages\esp32\tools\riscv32-esp-elf-gcc\gcc8_4_0-esp-2021r2-patch3 -prefs=runtime.tools.riscv32-esp-elf-gcc-gcc8_4_0-esp-2021r2-patch3.path=C:\Users\papa\AppData\Local\Arduino15\packages\esp32\tools\riscv32-esp-elf-gcc\gcc8_4_0-esp-2021r2-patch3 -prefs=runtime.tools.xtensa-esp32-elf-gcc.path=C:\Users\papa\AppData\Local\Arduino15\packages\esp32\tools\xtensa-esp32-elf-gcc\gcc8_4_0-esp-2021r2-patch3 -prefs=runtime.tools.xtensa-esp32-elf-gcc-gcc8_4_0-esp-2021r2-patch3.path=C:\Users\papa\AppData\Local\Arduino15\packages\esp32\tools\xtensa-esp32-elf-gcc\gcc8_4_0-esp-2021r2-patch3 -prefs=runtime.tools.xtensa-esp32s2-elf-gcc.path=C:\Users\papa\AppData\Local\Arduino15\packages\esp32\tools\xtensa-esp32s2-elf-gcc\gcc8_4_0-esp-2021r2-patch3 -prefs=runtime.tools.xtensa-esp32s2-elf-gcc-gcc8_4_0-esp-2021r2-patch3.path=C:\Users\papa\AppData\Local\Arduino15\packages\esp32\tools\xtensa-esp32s2-elf-gcc\gcc8_4_0-esp-2021r2-patch3 -prefs=runtime.tools.mkspiffs.path=C:\Users\papa\AppData\Local\Arduino15\packages\esp32\tools\mkspiffs\0.2.3 -prefs=runtime.tools.mkspiffs-0.2.3.path=C:\Users\papa\AppData\Local\Arduino15\packages\esp32\tools\mkspiffs\0.2.3 -prefs=runtime.tools.mklittlefs.path=C:\Users\papa\AppData\Local\Arduino15\packages\esp32\tools\mklittlefs\3.0.0-gnu12-dc7f933 -prefs=runtime.tools.mklittlefs-3.0.0-gnu12-dc7f933.path=C:\Users\papa\AppData\Local\Arduino15\packages\esp32\tools\mklittlefs\3.0.0-gnu12-dc7f933 -prefs=runtime.tools.xtensa-esp32s3-elf-gcc.path=C:\Users\papa\AppData\Local\Arduino15\packages\esp32\tools\xtensa-esp32s3-elf-gcc\gcc8_4_0-esp-2021r2-patch3 -prefs=runtime.tools.xtensa-esp32s3-elf-gcc-gcc8_4_0-esp-2021r2-patch3.path=C:\Users\papa\AppData\Local\Arduino15\packages\esp32\tools\xtensa-esp32s3-elf-gcc\gcc8_4_0-esp-2021r2-patch3 -prefs=runtime.tools.esptool_py.path=C:\Users\papa\AppData\Local\Arduino15\packages\esp32\tools\esptool_py\3.3.0 -prefs=runtime.tools.esptool_py-3.3.0.path=C:\Users\papa\AppData\Local\Arduino15\packages\esp32\tools\esptool_py\3.3.0 -verbose C:\Users\papa\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.3-RC1\libraries\WiFi\examples\WiFiClientBasic\WiFiClientBasic.ino |
|
Hi, that is strange. Can you please describe how did you update it? |
|
Updated through the IDE, it turned out to install only on a clean win10. |
|
I still get "slow" connects and sometimes "exceedingly slow" connects with 2.0.3-RC1. When it works, connection times are between those I got for version 1.0.4 (~2.3-2.5 seconds) and version 1.0.5 (~6.5 seconds). However, I also often get errors, which extend connection times over 30-60 seconds.
I often see errors when I power up the board from scratch or I hit the on-board Reset (which includes the first run right after flashing the device with new code). It tends to not have errors if I do a WiFi.disconnect() followed by esp_restart() (but this isn't guaranteed). This seems to indicate that when it simply disappears from the network that it leaves the AP in a bad state, but... I never see these errors, nor long connect times with the same code compiled against version 1.0.4. The error output starts with My test code is based on the sample code for WiFiMulti. I've been gradually modifying it to refine the output. I have added a delay after starting Serial (for getting the serial monitor open after flashing the device), added a printf statement with ARDUINO_ESP32_GIT_DESC and use esp_timer_get_time() for timing the connection from start to end. My main loop calls wifiMulti.run() and also checks for serial input which triggers a software reset (so I can test WiFi.disconnect() with esp_restart() results vs using the hardware Reset button). |
VojtechBartoska
moved this from Under investigation
to In Review
in Arduino ESP32 Core Project Roadmap
|
Hi @zencow, is this behavior consistent across various routers/APs and various distances from them? |
|
@PilnyTomas My tests have mainly been against the one AP that I have (Ubiquiti UniFi), using several different dev boards... all with the WROOM-32E chip (Adafruit's Huzzah32 Feather and their breakout board version). I think I had originally tested against my phone's hotspot (the reason I'm using WifiMulti), with similar results, but I haven't done that recently. Maybe I'll do a quick test now to see if that still yields similar results. |
|
@PilnyTomas I just did some tests against my Mobile HotSpot and I do see similar connect time patterns as with my primary AP for versions tested (1.0.4, 1.0.5, 1.0.6, 2.0.3-RC1), but it's also a lot less reliable with the HotSpot regardless of version. Here's how I'm doing the timing measurement: On a hardware reset of the device, the connecting time measurement (for both my UniFi AP and the mobile HotSpot) are calculated to be about:
The rest of this observation doesn't directly relate to this issue, but here's what I noticed with the HotSpot reliability: The Mobile HotSpot seems to drop the devices often (maybe because they're not really passing any traffic?). The devices running 1.0.4 don't seem to notice that they have been dropped by the HotSpot. I suspect this is because 1.0.4 doesn't have the same callback system and will (re)determine its connection status when the device actually needs to use the connection. The devices running 2.0.3-RC1 detect the connection drop every ~10-30 seconds and reconnect, which seems to take ~7 seconds from the first "STA_DISCONNECTED" message to the "STA_CONNECTED" and "STA_GOT_IP" messages, mostly (~6 seconds) between the "STA_DISCONNECTED" message and "SCAN_DONE" (I trimmed out the scan results and such, keeping the event messages and codes): ... |
|
Hmmm... I just noticed that my 1.0.4 device was still connected solidly all the time I was writing up the last message, and it was listed in the HotSpot's "Connected devices" and was not dropping it, like the 2.0.3-RC1 device. To see if this was the version or the devices themselves, I re-flashed the 2 test devices I'm using today, swapping the version running on them. Again... whichever device is running 1.0.4 stays solidly connected to the HotSpot, while the 2.0.3-RC1 device frequently disconnects and re-connects, regardless of the physical device. Maybe this is due to lack of traffic and attempts to save power? I dunno, but those delays taking 5+ seconds to get reconnected are not ideal. In case there were conflicts, I powered off the 1.0.4 device and still see the frequent connection drops in the 2.0.3-RC1 device (with this test code, that isn't actually using the connection once established). |
|
The connection times I've listed previously are for Connect times with
|
|
The same problem on esp8266, on the version after |
VojtechBartoska
moved this from In Review
to Under investigation
in Arduino ESP32 Core Project Roadmap
|
Can you test with latest master? @me-no-dev recently pushed some changes about this. |
|
It didn't compile for me. To install the latest version, I followed instructions at: ...but instead of using GitGUI, I used I then ran get.exe by double-clicking it in the Explorer and after it was done, I started the Arduino IDE, chose my board from the list in Let me know if you need debug output and I'll copy the gobs of that info, but this is the standard. |
|
Above, I was using Arduino version |
|
Hello folks, please retest this with 2.0.3.-stable. This is supposed to be solved. Thanks! |
|
@zencow if you have problems with installation, please open a new issue. This one is about WiFi connection time. |
|
I have been connected for longer than in 1.0.4, but it always connects, this is already good, I often didn't connect at all before. It seems that he goes through all the ssids in turn until he gets to my settings. There were problems with reading files from SD, but this is another topic |
|
@PilnyTomas Thanks... I'm not experienced enough to know if it was an installation issue or an issue with the "cutting edge update" from the repository that I was asked to try out. I just reported my negative results with that test, and tried to include enough info on what I did, so that experienced folks could use that to evaluate those results. I typically try to keep to release versions, since they're packaged and don't require many error-prone manual steps to install. The error message |
|
Yes, dual antenna is new code, and may have a mismatch on the struct elements. @VojtechBartoska was referring to this when he said he thought this was fixed in 2.0.3rc1 |
|
Ok... does I just updated to |
|
@zencow It was removed from 2.0.3 milestone because we weren't able to test this properly but it's still supposed to be fixed. Due to that, this issue was moved to 2.0.4 and @PilnyTomas is going to test this in next 2 weeks. Up to that, we will set up next steps. |
|
My measurements suggest an improvement on 2.0.3 from the previous 2.0.2. |
|
@PilnyTomas Since 1.0.5 I tested on 2.0.3 and I believe it's back on the track now. Seems to be fixed! |
VojtechBartoska
added
Status: Solved
and removed
Status: Test needed
Hello.
Using ESP32 with arduino.
Below snippet was working ok on all previous versions. I updated today to 1.0.6 and now it won't connect to my home network, always creates Access Point instead.
Reverted back to 1.0.5 and 1.0.6, power cycled device many times and nothing helps. Once I use 1.0.5 everything works as it should.
The text was updated successfully, but these errors were encountered: