ESP8266 Community Forum

- Fri Apr 22, 2016 12:16 pm #46007 Hi there:

I am working on some kind of sensor device with RTOS SDK, of cause, backed by battery power.
The device is designed to fall in deep sleep and wakeup every few seconds. In wakeup time, it only sends a broadcast packet (< 100bytes) and go back to deep sleep.

The time between wakeup and next sleep should be very short (< 20ms) in theory.
But, by measuring the time different between GPIO2 first rise and last fall, it takes about 250ms.

That's much longer than my expectation.
Does anyone know how to cut the additional 200+ ms or where does it come?

my program looks like this

Code: Select allvoid tm_func(void *arg)
{
    static int i=0;

    if(i == 1)
        send_mydata()
    if(i == 2)
        system_deep_sleep(1000*1000*5);
    i++;
}
void user_init(void)
{
    int i;
    os_timer_disarm(&tm);
    os_timer_setfn(&tm, (os_timer_func_t *)tm_func, NULL);
    os_timer_arm(&tm, 2, 1);
    os_printf("SDK version:%s\n", system_get_sdk_version());
    system_deep_sleep_set_option(0);
}



- Fri Apr 22, 2016 4:15 pm #46021 Hi, I did some testing for a project as to how long an external 'high' was needed on CH_PD to wake an ESP and run a bit of code for a GPIO to take over the 'high'. Not quite the same but it needed 325mS to boot and get to this point in the code below. So 200mS just wake (reboot) sounds about correct.

Code: Select all#include <ESP8266WiFi.h>
String apiKey = "<your_api_key>";  // your thingspeak API KEY
const char* ssid = "<your_router_SSID>";  // your routers SSID
const char* password = "<your_router_password>";  //your routers PASSWORD
const char* server = "api.thingspeak.com"; // thingspeak server
int holdPin = 0; // defines GPIO 0 as the hold pin (will hold CH_PD high untill we power down).
int pirPin = 2;  // defines GPIO 2 as the PIR read pin (reads the state of the PIR output).
int pir = 1;  // sets the PIR record (pir) to 1 (it must have been we woke up).
WiFiClient client;  // starts a WiFi client.

  void setup() {
  pinMode(holdPin, OUTPUT);  // sets GPIO 0 to output
  digitalWrite(holdPin, HIGH);  // sets GPIO 0 to high (this holds CH_PD high even if the PIR output goes low)


The project link is below - all you need is over by the end of page 2 - save you reading for ever.
viewtopic.php?f=11&t=4458

Two other things to try if you realy need to save the batteries:
Run the ESP @160Mhz - faster gets done quicker.
Drop the supply voltage to 2.8 to 3.0V - power = V squared / R (if R is constant - reducing V saves power).
Both have shown to work but you'll need to see were stable is for your application.

Last edited by Barnabybear on Fri Apr 22, 2016 4:40 pm, edited 3 times in total.

- Fri Apr 22, 2016 4:24 pm #46022 You don't say if you're using WiFi, but to wake up and connect WiFi in only 250ms would be impressive so i'm guessing maybe not - so try using system_deep_sleep_set_option(4) which is wake up with the WiFi radio disabled which makes wake up significantly faster.

- Fri Apr 22, 2016 10:44 pm #46026 Barnabybear:
Thanks your experience sharing and suggestion.
Doubling the working clock may be a viable way to accelerate the boot up speed. I prefer to treat it as the last sort to use due to the possible consequence of instability and more power consumption.

torntrousers:
Yes, I am using WiFi with AP mode. So, there would not have something like "time to connect to AP". With AP mode, I
think ES8266 can send a packet ASAP.
I try to use different values of system_deep_sleep_set_option(n). It shows 0,1,2 having a latency 250ms and 4 have 300ms.
Weirdly, disabling wifi takes more time than enabling it. Since this is not my case, I don't dig deep.


As I saw on some Google searches, the alleged "Wake up and transmit packets in < 2ms" is not positive answered by official forum. So, maybe this is the result under extremely optimized configuration.