Connect to Wifi network take almost 3 seconds. I am using static IP and BSSID and channel. On ESP8266, the same code connected within 100ms. What I am doing wrong #1675
Comments
|
With DEBUG, I have this: Connecting wifi... Connected to AP in 3205ms. IP: 192.168.1.115 |
|
we are going to investigate this. Will keep you posted :) |
me-no-dev
added
Type: Feature request
|
Had the same problem and checked everything over and over.. Created a post on the forum too. Just after an hour, created an AP from my ubuntu pc and tried to connect.. Voila.. In just 900 ms and connected to my tcp server + sent data + went back to sleep.. Strangely i had 4 esp8266 modules on the same wifi router with no speed problem at that same moment.. only my 2 of my wroom32s havin difficulty.. Btw if i change security to Open or WEP connection time is only 300ms+ but WPA types were about 3~4 secs. |
|
are you sure it's slow only on WPA? |
So it's about 0.7 secs difference between WPA & Open networks For ESP32, which cannot be observed on ESP8266. I'm using Wroom32 Modules. Tried with 3 different APs. A Huawei wireless router/modem, A ubiquiti, and an Asus. Huawei had the worst results. Ubi was the best..
Edit : This connection time problems also observed on IDF too, not only arduino. |
|
Hi, interresting. It really seems, that the cause of this issue is the WPA2 security. I have disabled the security on my router, so my network is open. And in that case, my code will join the network within 160 ms: ets Jun 8 2016 00:22:57 rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) Connected to AP in 167ms. IP: 192.168.1.115 |
|
I have updated now the latest IDF and latest development release and with that, the connection time is even slower - almost 4 seconds. |
|
Here is the trace debug with WPA2: Wakeup was not caused by deep sleep Connected to AP in 4159ms. IP: 192.168.1.50 It run the code bellow: long st = millis(); |
|
I am facing same issue with my Esp32 (Doit dev board) which was working fine with older IDF few month ago. I don't use this board very often as its mostly my breadboarding kit. My code is waiting for 5 seconds before deciding it could not connect. Every time I started getting Looking at the output it looks like it loops from Code debug output.. along with time stamps printed in event handler |
|
@robertgregor I think this issue title is too long. You might want to edit the issue and re-title it to say something smaller with same meaning.. |
|
@me-no-dev I can confirm that the previous version of Arduino-esp32 (one released under board manager json) is working fine.. with But with latest pull and executing get.exe (mkspiffs-0.2.3-arduino-esp32-win32.zip) |
|
I did a hard reset of the esp32-arduino to last known good version |
|
Same problem for me: Connecting with an ESP8266 to my AP in WPA security is taking about 450ms. |
|
Yes only with WPA there is an issue. Wep or open network is ok. |
|
Today I pulled latest beta release and I can confirm that it is now connecting to WPA network in reasonable time..
|
|
That's worse than my tests; I was already at 1200ms for a WPA on ESP32. |
|
02:30:37.966 -> ets Jun 8 2016 00:22:57 02:32:36.696 -> Guru Meditation Error: Core 1 panic'ed (Interrupt wdt timeout on CPU1) |
|
it's taking several minutes to connect to a wifi network for me... is this normal? void setup()
{
Serial.begin(115200);
delay(10);
// We start by connecting to a WiFi network
Serial.println();
Serial.println();
Serial.print("Connecting to ");
Serial.println(ssid);
WiFi.begin(ssid, password);
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println("");
Serial.println("WiFi connected");
Serial.println("IP address: ");
Serial.println(WiFi.localIP());
} |
|
Hello @ChuckJonas. You can find more about this problem in here: esp8266 forum and in here esp32 forum |
|
@kifantidis esp32. Took me FOREVER to figure out but it appears it was an issue with my router configuration. Using a netgear RT-N56U. Basically I had to reboot my router to get it to connect and the any subsequent connections attempts would fail with a status code of Tried a million different code tweaks to Also, even when it did connect, any HTTP requests outside of local host would come back I turned off 🤷 |
|
I noticed recently that my connection times with the ESP32 grew to more than 2s for the pure Wifi connection after recompiling a sketch for a new device that I use in production for existing devices. I used to have much lower connection times before (completing voltage and input pin measurement, Wifi connection, and MQTT reporting all within approx. 1.3s). I tested a lot and ultimately found that the problem starts with Release 1.0.5 of and I can connect typically within 0.21s using persistence (using Release 1.0.6 also is as slow as 1.0.5. I tested both with a regular router and with esp32_nat_router, the results are the same for both connection types. It would be great if the problem that was apparently introduced between 1.0.4 and 1.0.5 could be fixed in a new release. As a work-around to get fast connection times, revert to release 1.0.4 and use persistent connection (which overwrites the information in the flash only if things change, so this should generally not be a problem). |
|
I am really struggling with this issue. Static IP and also happens if I connect to a test, dummy AP with nothing else. Around 3300% of my time is now spent connecting to wifi :) Is there something else we can do with this? |
|
This is still a problem. Using static IP and supplying the network bssid and channel still takes over 2 seconds to connect, and over 2.5 seconds on wroom-32d chips. Changing the persistence makes absolutely no difference in connection time. Verbose debugging does not show any network scans (which is the expected behavior when supplying bssid and chan) so I have no what could be causing the delay. The same method on ESP8266 modules consistently connects in 1 second. |
|
I will try this this evening. That would be brilliant if we're down to those times.! |
|
I've only just started with the ESP32 and using the latest 2.0.0 release I'm also getting very slow WiFi connect times of 2.1 seconds with a static IP, or 2.6 seconds with DHCP. I've tried setting channels 11 and 13 on my router (that has a strong signal and is in the same room), supplying the channel+BSSID or not in Reverting to the old 1.0.4 release suggested by @tobiasisenberg, I'm getting MUCH faster connect times of 0.21 seconds average (0.18 to 0.26s). That is with static IP and WPA2. This is obviously a serious problem for some battery-based projects, and for my own project 2.0.0 is unusable. 2.0.0 verbose logging: 1.0.4 verbose logging: |
|
@sheffieldnick So you do not get fast connection with 2.0.0 and with persistence enabled? Btw, my connection times of 0.21s for 1.0.4 and 0.09s for 2.0.0 did not use static IPs (on the side of the ESP32), just regular DHCP (where the MAC address, in my case, is always assigned a specific IP address on the router side) and WPA2. Static IPs (on the side of the ESP32) do not seem to be necessary. |
I haven't experimented with persistence yet, so all my tests had
Hmm. I imagine that is down to the specific DHCP server and settings for IP address lease time, etc? Apparently some servers can take several seconds as they check that nothing else is using the IP address they are about to assign. |
|
@sheffieldnick No, you do not need specific DHCP settings. I do not think that the DHCP settings matter at all (or much) on most routers. I simply wanted to point out that a static IP (on the side of the ESP sketch) should not be needed. And please test persistence with 2.0.0, I measured my low timing values only for a sketch that uses persistence (for both 1.0.4 and 2.0.0). This means that you should try with a simple |
|
I did some extensive testing with the latest build for the ESP32 and found the following regarding timing for esp_wifi_connect (this includes DHCP getting an IP address and an AP in close proximity):
As for NVS with CONFIG_ESP32_WIFI_NVS_ENABLED set, esp_wifi_init sets nvs.net80211 ap.sndChan which doesn't seem to change so will not be written to Flash (except the very first time). So it would appear that one should always be using CONFIG_ESP32_WIFI_NVS_ENABLED unless one knows they will frequently be switching between different APs. One should probably use WIFI_ALL_CHANNEL_SCAN with WIFI_CONNECT_AP_BY_SIGNAL on a new installation such as when setting the SSID from a user or from a power on reset (as a way for a user to force a best RSSI scan) or perhaps periodically such as once a day (but not frequently); otherwise one should use the default scan method (WIFI_FAST_SCAN). If you don't use an all channel scan initially, then the first matching AP found will be used and it may have poor signal strength (low RSSI). Unfortunately, it looks like the libnet80211.a sources are not available so I can't investigate further what is going on with the esp_wifi_connect function. |
|
Glad to have found this thread. I was using plain IDF and everything worked just fine. My app reads some sensors and sends a UDP packet to a server. The whole activity takes about 500-600ms. The wifi connection takes 70-150ms. My initial issue is that I see on the AP there are DHCP requests from the esp32 client for each packet, and I expected none. The DHCP exchange is rather quick so it does not explain the excessively long connection time, but it still should not happen (updated: the IDF version does not show DHCP requests). I then copied the full wifi part from the IDF project into the Arduino IDE sketch and it ran as slowly as the native Arduino sketch. Basically the same code. I suspect there is something fundamental in the Arduino environment that acts differently to the IDF. laterI checked-in a simple Arduino sketch I use to test the timing (wifi_test) and a similar IDF project (wifi-v4.3), here. important noteTested the Arduino using board version 2.0.0 - slow. Using version 1.0.6 - slow. Using version 1.0.5 - fast as expected. So there is a regression there. HTH |
|
Anyone looking into that? |
1.0.6 changed scanning method to WIFI_ALL_CHANNEL_SCAN. Try to comment line 179 in WiFiSTA.cpp to check if that makes it as fast as 1.0.5 |
|
Two things @obaterspok
HTH |
|
With the above patch you can do an initial slow connect in order to find the best possible channel. When we get the IP we save the channel in RTC_DATA and use it for fast connect after wakeup. RTC_DATA_ATTR int32_t my_wifi_channel = 0; void setup() WiFi.onEvent(WiFiGotIP, WiFiEvent_t::ARDUINO_EVENT_WIFI_STA_GOT_IP); Serial.printf("Starting wifi using channel %d!\n", my_wifi_channel); |
|
The above suggestion should work, but it means that all sketches that worked fast before, now need to be modified to work fast. |
|
Newer ESP-IDF code (v4.4-dev-3703) is now taking only 1.5 seconds for a full scan (with CONFIG_ESP32_WIFI_NVS_ENABLED set) so this has improved from the 2.1 seconds I previously reported. This is using direct ESP-IDF code, not Arduino. |
|
@RichFalk . 1.5s is much slower than the 200-300ms it takes to go with WIFI_FAST_SCAN, and for my app that takes less than 500ms wakeup-to-sleep, running on battery, it is a major issue. |
|
@eyaleb If you are waking up to do Wi-Fi frequently in a battery-powered device then yes, using the fast scan will save power. However, it doesn't come free because many environments have multiple APs sharing the same SSID in order to have automatic roaming so you want to get the strongest signal from the closest AP. So at a minimum you have to do a full scan at some point, such as from a power up (not a deep sleep restart) but even then if you lock in to the strongest signal that might still be relatively weak, then you'll have to tell users that if they add another AP or an extender to improve the signal that they would need to power cycle your device. Otherwise you will get "stuck" always connecting to the original AP with its (now) weaker signal compared to the new AP. So while you are saving power, you may be sacrificing the user experience if they try to improve RSSI by adding a new closer AP. |
|
Appreciated @RichFalk . For me, and anyone with a simple setup (only one AP, with hard-coded config), the old fast scan was good. |
|
Fascinating discussion. Does anyone have a complete code sample for the 8266? I still get a connection time of around 4 seconds, using a static IP, regardless of the persistence setting. I am trying to implement a MQTT WiFi button. The MQTT part is super fast, but the network connection seems slow. Authentication is WPA2-PSK. I do recall having gotten this to work faster in the distant past, but I think that was before 'upgrading' my WiFi network. // the following doesn't seem to make any difference WiFi.mode(WIFI_STA); for (int i=0; i<200; i++) { If someone could share a known-good snippet for an 8266-01, that'd be terrific. Thanks p.s.: The above statement is true for both an ESP-01 and a Wemos D1 mini module. I am using the Arduino IDE 1.8.13 with the ESP8266 Community version 3.0.2 |
|
@langrock That worked for me (~200ms for full connection) on ESP01: The getWifiChannel performs a full scan via WiFi.scanNetworks() and graps the channel from the SSID. Static IP is most probably not required as mentioned above. First connection is slow but further connections from deep sleep are fast. If you change details in the wifi setup you are doomed and you have to change the hardcoded WiFi string back and forth. There is probably a better way ... For ESP32 the solution provided by #5975 works perfect. Around 150ms for a full connection. |
|
@danielchiaradia Thanks. This is essentially the same that I've been using except for specifying the BSSID, which I think is the MAC address of the router, correct? I also don't recall if I ever added the channel information ... Anyhow, what confuses me a bit is the statement that you see different connection speeds depending on whether power was initially applied or the chip wakes from deep sleep. I was under the impression that waking from deep sleep (i.e. going through a full reset), is identical to completely removing and re-establishing power to the device. Is that not correct? If not, and deep sleep is indeed much faster, I will rethink the approach for some of the applications I am considering. Thanks again. |
|
@langrock Yes, the BSSID is the router MAC. The slow WiFi connection is as per my understanding caused by the channel scan. If you provide the channel in WiFi.begin(... then the channel scan will be skipped. However, your router might change the channel automatically depending on your router settings. So, be sure your program on the ESP8266 can deal with it (e.g. scan the channel again when the connection cannot be established within the timeout). |
|
@langrock, a reset is not the same as deep-sleep wake-up. Read on power modes to see the details, but basically deep-sleep keeps an RTC running and keeps RTC memory content while a reset clears everything. Separately, some wifi info supplied on first reset can be saved and used after reset and after wake-up. |
VojtechBartoska
added
Status: Solved
and removed
Status: To be implemented
|
I do not use a static IP, BSSID or channel. even with that it takes an average of about 220ms(!) overall elapsed time between keypress (wakeup) to status (received from remote machine) espressif must have done lots of improvements since then. cheers |
|
Hi, I've read this thread and tried various fixes that was posted, but still I only manage to make it go on average of 2.2s to connect to wifi. Does anybody have any update regarding this? |
|
@denielsenp Setting the BSSID (AP MAC address) in addition to channel in Obvious caveats:
|
and others
Hi, I am migrating the code of ESP8266 for battery powerred device. But seems, I have a problem to have reasonable time to connect to wifi. It takes at least 3 secods always. Here is the code:
#include <FS.h>
#include <AsyncTCP.h>
#include <ESPAsyncWebServer.h>
#include <SPIFFS.h>
// SKETCH BEGIN
AsyncWebServer server(80);
const char* ssid = "Bob";
const char* pwd = "xxx";
byte ip[] = {192,168,1,115};
byte gw[] = {192,168,1,1};
byte mask[] = {255,255,255,0};
byte dns[] = {194,41,3,193};
byte bssid[] = {0xF8, 0xD1, 0x11, 0x24, 0xB3, 0x84};
byte chnl = 4;
IPAddress getIpAddrFromArr(byte ipAddr[]) {
return IPAddress(ipAddr[0], ipAddr[1], ipAddr[2], ipAddr[3]);
}
void connectToWifi(String ssid, String pwd, byte ip[], byte gw[], byte mask[], byte dns[], byte bssid[], byte chnl ) {
if (WiFi.status() == WL_CONNECTED) return;
Serial.println(F("Connecting wifi..."));
long st = millis();
WiFi.enableSTA(true);
WiFi.mode(WIFI_STA);
if (ip[0] != 0) WiFi.config(getIpAddrFromArr(ip), getIpAddrFromArr(gw), getIpAddrFromArr(mask),getIpAddrFromArr(dns));
if ((ssid.length() != 0) && (pwd.length() == 0)) {
WiFi.begin(ssid.c_str());
} else if ((ssid.length() != 0) && (pwd.length() != 0)) {
if (bssid[0] == 0) {
WiFi.begin(ssid.c_str(), pwd.c_str());
} else {
WiFi.begin(ssid.c_str(), pwd.c_str(), chnl, bssid);
}
WiFi.setAutoConnect(true);
}
int attempts = 0;
while (WiFi.status() != WL_CONNECTED) {
if (++attempts < 300) {
Serial.print(".");
delay(50);
} else break;
}
if (WiFi.status() == WL_CONNECTED) {
long tm = millis() - st;
Serial.print(F("\nConnected to AP in "));
Serial.print(tm, DEC);
Serial.print(F("ms. IP: "));
for (byte thisByte = 0; thisByte < 4; thisByte++) {
Serial.print(String(WiFi.localIP()[thisByte], DEC));
if (thisByte != 3) Serial.print(".");
}
Serial.println();
}
}
void setup(){
Serial.begin(115200);
Serial.setDebugOutput(true);
Serial.println(F("Connecting wifi..."));
long st = millis();
connectToWifi(ssid, pwd, ip, gw, mask, dns, bssid, chnl);
SPIFFS.begin();
server.on("/heap", HTTP_GET, [](AsyncWebServerRequest *request){
request->send(200, "text/plain", String(ESP.getFreeHeap()));
});
server.serveStatic("/", SPIFFS, "/").setDefaultFile("index.html");
server.onNotFound([](AsyncWebServerRequest *request){
request->send(404);
});
server.onFileUpload([](AsyncWebServerRequest *request, const String& filename, size_t index, uint8_t *data, size_t len, bool final) {
request->send(403);
});
server.begin();
}
void loop(){
}
So as is seen, I will do:
WiFi.enableSTA(true);
WiFi.mode(WIFI_STA);
WiFi.config(getIpAddrFromArr(ip), getIpAddrFromArr(gw), getIpAddrFromArr(mask),getIpAddrFromArr(dns));
WiFi.begin(ssid.c_str(), pwd.c_str(), chnl, bssid);
But this tahes around 3.2 seconds always:
Connecting wifi...
...............................................................
Connected to AP in 3201ms. IP: 192.168.1.115
On my ESP8266, this worked much much faster, I was connected in less than 100 ms always...
Anyone has an idea, why it take so long?????
Robert
The text was updated successfully, but these errors were encountered: