-
Notifications
You must be signed in to change notification settings - Fork 13.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WiFi dropouts unless using WiFi.setSleepMode(WIFI_NONE_SLEEP) #5998
Comments
Issue moved across from platformio/platform-espressif8266#135 |
Can you try that and report back wether it is sufficient without |
I've implemented this as a SimpleTimer via:
SimpleTimer then triggers every ~5000ms for that task. I can see the following on the network via tcpdump:
I've also disabled the |
Setting WIFI_LIGHT_SLEEP and sending GARP's - and it doesn't seem to fix the issue. I don't have any of the ESP8266 units with over an hour uptime according to the AP. I even tried setting one to 802.11g mode, no real difference. |
Have you tried with latest git which uses a more stable espressif firmware ? |
Embarrassingly, I can't quite remember what to feed into PlatformIO to try this. Currently, I have the following in platformio.ini:
I'm pretty sure none of these are directly from this repo. I'm pretty sure I've done this before - but I can't find my notes that mention it. Any hints on being able to get this to reflect here instead? |
This entry use latest ESP8266 dev version: |
That doesn't map up with whats in this repo though.... From https://github.com/platformio/platform-espressif8266/tree/feature/stage (in your browser): The commit list here has: I'm not sure the two compare... |
You have to force platformio to update! |
Ah! That's what I was missing....
Let me start testing again. |
Woah, this seems to lead to hard hangs if I set I hit the reset button to bring it back to life after each of the disconnection timeouts below. Setting Version string is now:
MQTT logs for timing:
|
Make sure you do a clean build and build again after updating the core library, when using PlatformIO. Apart from that, I've seen similar issues. What I'm seeing is that the node does reduce power somehow (you can measure its power consumption) and then starts to miss packets until it receives some ping requests (or other repeated network requests) Even when setting the wifi to none sleep, the power consumption may drop after a while and then it starts to miss packets. Now the really strange part.... |
When do you call the function Gratuitous ARP, during the loop correct? |
@TD-er How can we use Gratuitous ARP. Is there any temporay solution to this problem. I went through few threads related to this on this repo as well as EspEasy's repo, i saw that you have worked on it a lot. Did you find some temporary or permanent solution to this problem ? |
I do send Gratuitous ARP packets when just connected and when I encounter failed connect attempts (also DNS lookup) Another approach can be to send ping packets to the node, since ICMP packets are somehow treated differently. Not sure if it is only on the ESP, or also in the AP what makes it act different. I am not (yet) using it on the ESP32 and you can clearly see a difference in how well it does react on web requests or the UDP packets sent among ESPeasy nodes. |
I fixed it by doing: Without that, it still seems to drop out. Of course, you need to be able to tolerate the extra power draw... |
Not tested on ESP32, but on an ESP8266 I've notice this is no guarantee it will keep the wifi radio on. There is something in the background messing with the power settings. |
@TD-er Thank you for this. I checked usage of sendGratuitousARP in espeasy repo. And i implemented the same in my code.
And i am calling this function as soon as node connects to the wifi. And after that calling it every 5 seconds. However, there is something wrong with this. Device is crashing sometimes when calling this function right after getting connected with wifi. (I tried giving a delay of 100ms also, not helping). I am using Lwip 2 higher bandwidth version. This is my exception stack
|
Yep, you have to wait a while after setup of the WiFi. But in general, if you observe the rules I mention in the last post I linked, you should be fine. |
@TD-er I tried delay(200) also. And i am getting IP also, after that only i am starting sendGratuitousARP(). I checked the ESPEasy's code again after your recent updates.
I have tried lwip 2 lower memory also, using latest esp core from github. But its same, now its triggering hardware watch dog. I am not sure if its working with ESPEasy. I'll try and verify that also today. EDIT: Calling sendGratuitousARP() function is triggering wdt reset. |
It would be great to know if you found what exactly triggers the WDT reboot. What mode is active when you run the gratuitous ARP? How long is the delay between receiving the IP address and start sending the ARP requests? |
See this PR: xoseperez/espurna#1877 and discussion here: esp8266/Arduino#5998 (comment) Fixes letscontrolit#2374
For what it is worth, I have been tinkering with the ESP8266 for years now, and drop out appears to be an ongoing issue. I agree with TD-er, this (none_sleep) is no guarantee, and frequently advanced users refer to power issues. But I also agree with CRCinAU, that to date, for me, the WiFi.setSleepMode(WIFI_NONE_SLEEP); gives the most reliable/consistent connection. I think for many less advanced hobbyists, this information is helpful. If ever, anyone has an Arduino C++ WiFi set up for the ESP8266 that is drop out free, please share. |
@Spackstor My suspicion is that the dropouts were fixed by #6484. I've been running a whole bumch of modules for several weeks now on latest git after that fix without any dropouts, and I don't use sleep none. |
I'll load the new libraries and see what happens. I'm an MQTT red-node/Raspberry fan. Adding ESP8266 reliability is a boon. Thanks for the info. |
I've set Will monitor further, but it'll be great if that fixes the issue. I've had to disable sleep in everything for so long.... |
Just curious, what was your average connection lost interval with that setup before? |
What is |
|
Are you able to try with git version ? There's also an alpha release that I just updated |
I'm using platformio, so I changed the platform to:
New
I enabled LIGHT_SLEEP again as follows:
Is that the correct version for what you're wanting? |
It is better, though not ideal, because either:
Do you have P-io instructions on how to update the stage source directory ? |
I've been using these docs: My platformio.ini contains:
|
Good! Try with it then |
Ok - have flashed and connected back up... For my records, 23:57 was the reconnect time on the latest compile with the above settings. Will leave it run and check tomorrow so I'll have ~20 hours of data to see what the result is. |
@CRCinAU I use this to set the git version:
|
Results of using WIFI_NONE_SLEEP after ~14 hours shows zero dropouts... Flashed at about 12:20am - solid connection ever since. For some reason screenshot uploads are failing - will attach later. Am currently testing with WIFI_MODEM_SLEEP instead of NONE / LIGHT... Will report back later... EDIT: I've been observing power draw on the D1 mini in different modes... |
After testing with WIFI_MODEM_SLEEP, I haven't had a single drop in 24h. There's also a massive power saving using WIFI_MODEM_SLEEP instead of WIFI_NONE_SLEEP - so this may be a good workaround for the moment... |
What I usually do is have the image (the pixels, not the file) in my clipboard and just paste it in the comment field. About the sleep handling. |
@CRCinAU with which IDE do you compile? If you use PlatformIO you will have wifi disconnects because PlatformIO still uses Xtensa Build chain 2.4. which does not work reliable with latest Arduino Esp versions (wifi disconnects). You have to use build chain 2.5.0.4 which is standard in Arduino IDE. |
Yeah - I can't paste or attach a file - no idea why... Oh well... WIFI_NONE_SLEEP / MODEM_SLEEP / LIGHT_SLEEP are all automatic. The only real action you need to do is turn it on when init'ing wifi. ie:
|
Current versioning in PIO:
I'm curious how the MODEM_SLEEP works fine, but LIGHT_SLEEP doesn't based on compiler? |
Old build channel, you will have always wifi disconnects. |
Any chance you can link to the PIO issue # here? EDIT: Ah, I think you're talking about this? EDIT2: Ok, I've downloaded 2.5.0-4 manually and set it up using the following script:
I then added I built, then flashed - lets see what happens over time. |
Building with Xtensa Build chain 2.5.0-4 makes no difference when using WIFI_LIGHT_SLEEP - I still see regular dropouts. The best results seem to be with using WIFI_MODEM_SLEEP for power consumption. This option gives a rock solid connection with no dropouts and much lower power usage than WIFI_NONE_SLEEP. |
Until we can update the Arduino core 2.6.0 (which is hopefully soon) with the newer xtensa toolchain, it seems the best bet is to reduce wifi sleeping. Also high transmit power can interfere with the flash reading which can cause instability. esp8266/Arduino#5998 (comment) esp8266/Arduino#6471
I never really got back on this one - however using WIFI_MODEM_SLEEP is fine. WIFI_LIGHT_SLEEP is broken and continues to have dropouts. See below picture of using WIFI_MODEM_SLEEP. Idle power draw shows on my meter as 0.01A - it doesn't have a higher resolution than that. As you can see, no dropouts. |
CC @Tech-TX do these dropouts make sense to you? |
In WIFI_LIGHT_SLEEP (Automatic Light Sleep), yes. The CPU is usually asleep between TIM beacons, and might miss traffic unless it happens at the DTIM (listen) interval. In WIFI_MODEM_SLEEP (Automatic Modem Sleep), no, it shouldn't miss packets, as the CPU never sleeps. It only turns off the modem between TIM beacons if it can (if there's a delay() it can use). The receiver is still working, it's just the transmitter that it sleeps. If you don't do anything with the power modes, you get Automatic Modem Sleep. There should be no difference between WIFI_NONE_SLEEP and WIFI_MODEM_SLEEP (the default) on packet loss, only on power. In that last capture (WIFI_LIGHT_SLEEP) I'm running DTIM = 3, so only one listen interval per 3 TIM beacons. There's a delay() loop hitting every 5.5 beacons that also wakes it up. Those two are the 'modem sleep' areas at 18mA where the CPU is fully awake. Any time it's near that bottom division, the CPU isn't responding, and can miss packets unless they happen at the DTIM interval when it's briefly awake. If you look closely, the area where I've marked LIGHT SLEEP there are 4 beacons without a Modem Sleep wake-up, so it would have lost a packet there if the AP was sending during a time it expected the STA to be awake. Espressif doesn't say anywhere that Light Sleep won't miss packets, and looking at that capture I see what looks like potential lost data. It's inside the blob, nothing we can do to fix it. If you're in a network where you can't afford lost data, then WIFI_MODEM_SLEEP will save ~45mA worth of power if you spend a long time in delay() without data loss. If you can afford to lose packets then WIFI_LIGHT_SLEEP will save an additional ~10mA depending on traffic. In a high-traffic environment, neither of the automatic modes will save any power, as the SDK keeps the modem on almost continuously. It's only during low-traffic and delay() that it sleeps. In high traffic, it looks like WIFI_NONE_SLEEP. |
Closing per previous comment. |
I've noticed lately that multiple devices I have have started dropping off WiFi and reconnecting (causing MQTT dropouts etc) unless I specify
WiFi.setSleepMode(WIFI_NONE_SLEEP)
when setting up the WiFi adapter.ESP.getFullVersion() output:
WiFi setup code in setup():
And the functions:
update_status is a global string that is included on the web page interface.
If I comment out the setSleepMode line, I get regular wifi disconnections.
The text was updated successfully, but these errors were encountered: