I was browsing the sources for the RTOS port you guys just posted, and I saw some nice functions I have a couple of questions on:

About system_rtc_mem_read and system_rtc_mem_write: I presume this is meant to store data over a reset cycle, so you can save stuff when going to deep sleep without having to put it in flash? If so, how much memory is available? I also assume the main memory isn't kept over a deep sleep cycle?

I see there's a wifi_station_disconnect there. Does this disable the WiFi hardware when the module is in STA mode?

I'm asking this because I'm thinking about a sensor that runs on batteries. What I'd like to do is to have it wake up say every 30 seconds or so, take a sample, store it in RTC memory, then go to sleep again. Every 5 minutes, it will enable the WiFi stack and send the collected data. I would not want the sensor to have to start the WiFi electronics every 30 seconds, because that'd mean a fairly big drain on the batteries. Is such an use case possible?

And another question: As far as I can see, a return from sleep mode now involves a complete reset, which means the device has to do a scan, associate and dhcp request in order to get the network working; I measured that to take about 5 seconds, which at 70mA average (assumed) is quite long if you have a thing running from a battery. When you sleep only 5 minutes or so, a lot of the variables detected (access point channel, association data, IP address) will be the same as on the previous startup. Is there a possibility to store these in RTC RAM and reload them on wakeup in order to cut out the scanning etc and get a speedier wake-up process?

I'm going to kick this once more, I really hope the Espressif people can give some answers; getting this to work a bit better would make the ESP way more usable as a low-power sensor thing. At the moment, I measure the ESP coming up, sending an HTTP request and going to sleep takes about 5 seconds. Of these 5 seconds, it seems that:- 0.3 seem to be general chip read and init stuff.- 1.8 are used to scan for the access point. After scanning, connecting with it happens instantaneous- 1.0 is used to get a DHCP lease- 1.5-1.9 is used to send the actual HTTP request and receive data.

In general, all operations seem to average about 70mA of power, but the scan and DHCP lease bit seem to pull more than the HTTP thing. See the attached scope image.

My idea is, if there's a way we can read and set the specific access point settings and DHCP lease info to RTC ram and restore them when the chip wakes up again, we can save more than half the time the thing is awake. Because it pulls way less power when doing the HTTP request, I think devices running on battery will get about 3 times as much lifetime than when just rebooting.

My question is: Espressif guys/gals, is there a plan to implement this kind of sleep/wakeup behaviour? If there isn't, can you implement an API to get/set the access point details, so scanning for them on wakeup becomes superfluous? We can implement the DHCP and save/load-from-RTC-ram bit ourselves if needed. (As a final alternative: any chance the phy etc libraries can be open-sourced?)

. If a full reset is involved, I would prefer storing in Flash rather than RTC ram.. Success of speeding up connecting and DHCP lease might depend on access point behavior/settings.. Power consumption might be optimized with .. TX power. Already asked for API... ESP8266 system clock frequency... Flash clock frequency... GPIO pullup (UART).

@Espressif_Faye:Deep sleep is a great feature that enables battery applications. This is particularly helpful when sensor data is transferred with long time interval like 10 minutes.

But how can we reduce regular power consumption when NOT in deep sleep? For applications that need to check switches or short-interval sensors, a low power mode could prove useful. Can we achieve that by reducing wake-up time and reconnecting time, by reducing clock frequencies (system and flash) and by reducing/modifying transmission power?

Lars R. wrote:@Espressif_Faye:Deep sleep is a great feature that enables battery applications. This is particularly helpful when sensor data is transferred with long time interval like 10 minutes.

But how can we reduce regular power consumption when NOT in deep sleep? For applications that need to check switches or short-interval sensors, a low power mode could prove useful. Can we achieve that by reducing wake-up time and reconnecting time, by reducing clock frequencies (system and flash) and by reducing/modifying transmission power?

Best regardsLars

ESP8266 have three low power modes:1. Modem sleep, average current is 15mA;2. Light sleep, average current is 0.9mA;3. Deep sleep, average current is 10uA.

Espressif_Faye: Thank you very much! Now all we need is an interface to load and save the WiFi parameters (channel, ssid, DHCP address etc) so we can just load those on startup and be up and running within 2 seconds.

Jackon: How do you use those sleep modes? I've seen the new wifi_set_sleep_type call in the 0.9.4 SDK but I don't really see any difference in behaviour after I call them: system_deep_sleep still takes as long as it did, and when I leave the system running I still get an average power use of 50mA. Is there a wifi_sleep() call or something I'm missing?

@Sprite_tm , it seems that you have many questions about how to use our APIs, please contact sales@espressif.com to sign NDA, then you can get our documents about APIs and else. interface to load and save the WiFi parameters: wifi_softap_get_config and wifi_softap_set_config wifi_set_sleep_type to set sleep type for power saving. Set NONE_SLEEP_T to disable power saving. Default to be Modem sleep. Power saving is only enabled in station mode,because softap can not sleep.Thanks for your interest in ESP8266 !

Documentation

About Us

Espressif Systems is a fabless semiconductor company providing cutting-edge low power WiFi SoCs and wireless solutions for wireless communications and Internet of Things applications. We are the manufacturer of ESP8266EX.