Execution time, Deep Sleep esp8266

ldb · September 22, 2018, 8:43am

Hi,

I didn’t really try to search it and decided to test it myself. Have you ever wondered what is the Execution time in order to calculate your battery life? Well… I did.

This is far from a scientific, highly accurate method but I found the findings interesting enough to share.

Conditions were:

Private server;
Wemos D1 mini Pro;
Ping average higher than 300ms;
DeepSleep for 55 seconds;
RSSI ~ -70dBm;
SHT31 temperature and humidity sensor;

Average = 4.15sec

I also found this IoT Battery Life Calculator that may be helpful.

Next step is to build a proper PCB based on WROOM-02 and check the current draw.

Just a side note, I did something similar with Azure (MQTT) and averaged 8 sec. On this case I didn’t spend a lot of time as the their Provisioning option has too many clicks in my opinion.

PeteKnight · September 22, 2018, 9:46am

Why? If you have. local server then I’d expect this to be much lower.

There are actually quite a few topics about deep sleep and connection times. It’s not something I’ve tried yet, but it is something that interest me for a potential future project.
It seems that the Blynk library used to contain a line that forced a 5 second delay prior to connection, as discussed here:

If you’re getting sub 5 second results from waking up to sleeping then I guess this has now been removed from the library.

If you’re not too worried about having the ‘last seen’ time available for your device then I think you’d probably get quicker results if you used the API to update the server, rather than doing the full Blynk connect thing.

“the guy with the Swiss accecent” has quite a few videos on his YouTube channel dedicated to deep sleep, which are well worth watching (and it’s worth reading the comments too). Here’s one of his early ones:

In his later videos he’s done some in-depth comparisons of various ESP-32 boards that give some very interesting results.

Pete.

ldb · September 22, 2018, 5:50pm

Thanks for your inputs.

I said private, not local

I believe this is more a “5 seconds delay between connection” ie to reconnect. But I agree with you and I’m getting below 5 anyway.

I’ll try the API only and see if I can improve it.

I do follow him and saw some of his videos, if I remember it right he also had the same experience as I had with MQQT around 8 seconds.

I also considered using TPL5010 in order to reduce the sleeping current but not sure if it’s worth.

ldb · September 23, 2018, 12:03am

Over a day:

ldb · September 23, 2018, 1:07am

Interestingly enough, HTTP API using the example is giving me 5+ secs:

void PUT_HTTP(String value, String vx)
{
  String response;

    String putData = String("[\"") + value + "\"]";
    if (httpRequest(String("PUT /") + configStore.cloudToken + "/update/" + vx, putData, response)){
        if (response.length() != 0){
        Serial.print("WARNING: ");
        Serial.println(response);
        }
    }
}

rl␀l��|␀�l�|␂␌␌␌�␌l�␌b|��␂�␒�r�b�␌b��nn�lnn���␌b␜p��lrlrlp�n�␐␂␌␌�␌l␌��␌␌␌b␌n�|␂l�␌␌�b��nn�␀l��l`␂�␒␒nn␌l`␂␎␂nr���n␌␌b␌�␎l␎r��n␌␌b␌�␎l��l␌���p��l`␂��n�␂
Temp: 19.4, Humidity: 57.4 Vcc: 3.02
Going to sleep after: 5.07
rl␀l��|␀�l�|␂␌␌␌�␌l�␌b|��␂�␒�r�b�␌b��nn�lnn���␌b␜p��lrlrlp�n�␐␂␌␌�␌l␌��␌␌␌b␌n�|␂l�␌␌�b��nn�␀l��l`␂�␒␒nn␌l`␂␎␂nr���n␌␌b␌�␎l␎r��n␌␌b␌�␎l��l␌���p��l`␂��n�␂
Temp: 19.7, Humidity: 56.3 Vcc: 3.02
Going to sleep after: 5.22
rl␀l��|␀�l�|␂␌␌␌�␌l�␌b|��␂�␒�r�b�␌b��nn�lnn���␌b␜p��lrlrlp�n�␐␂␌␌�␌l␌��␌␌␌b␌n�|␂l�␌␌�b��nn�␀l��l`␂�␒␒nn␌l`␂␎␂nr���n␌␌b␌�␎l␎r��n␌␌b␌�␎l��l␌���p��l`␂��n�␂
Temp: 19.7, Humidity: 56.4 Vcc: 3.02
Going to sleep after: 5.01
rl␀l��|␀�l�|␂␌␌␌�␌l�␌b|��␂�␒�r�b�␌b��nn�lnn���␌b␜p��lrlrlp�n�␐␂␌␌�␌l␌��␌␌␌b␌n�|␂l�␌␌�b��nn�␀l��l`␂�␒␒nn␌l`␂␎␂nr���n␌␌b␌�␎l␎r��n␌␌b␌�␎l��l␌���p��l`␂��n�␂
Temp: 19.6, Humidity: 56.6 Vcc: 3.02
Going to sleep after: 5.00
rl␀l��|␀�l�|␂␌␌␌�␌l�␌b|��␂�␒�r�b�␌b��nn�lnn���␌b␜p��lrlrlp�n�␐␂␌␌�␌l␌��␌␌␌b␌n�|␂l�␌␌�b��nn�␀l��l`␂�␒␒nn␌l`␂␎␂nr���n␌␌b␌�␎l␎r��n␌␌b␌�␎l��l␌���p��l`␂��n�␂
Temp: 19.5, Humidity: 56.5 Vcc: 3.02
Going to sleep after: 5.19
rl␀l��|␀�l�|␂␌␌␌�␌l�␌b|��␂�␒�r�b�␌b��nn�lnn���␌b␜p��lrlrlp�n�␐␂␌␌�␌l␌��␌␌␌b␌n�|␂l�␌␌�b��nn�␀l��l`␂�␒␒nn␌l`␂␎␂nr���n␌␌b␌�␎l␎r��n␌␌b␌�␎l��l␌���p��l`␂��n�␂
Temp: 19.5, Humidity: 56.6 Vcc: 3.02
Going to sleep after: 5.20

PeteKnight · September 23, 2018, 8:39am

Are you using a normal ESP8266WiFi library with static IP for your device, instead of the Blynk.connect/begin routines?
It might be worth adding-in a few serial prints at various points along the way to break-down how long the initialisation, Wi-Fi connect, and HTTP elements of the code are taking.

It seems to be generally recommended that you use the GET command rather than PUT for writing data to the Blynk server.

Pete.

ldb · September 23, 2018, 9:03am

Yes, but IP is DHCP.

I’ll probably do it eventually.

I’ll try that and share the results. Not my preferred one though as it’s a more throw and run.

unnamed

PeteKnight · September 23, 2018, 9:37am

I think a static IP address for your device should give faster connection times.

Pete.

ldb · September 23, 2018, 8:17pm

Static IP won’t be an option for me. I’m kind of exploring a commercial application.

void GET_HTTP(String value, String vx)
{
  String response;

  if (httpRequest(String("GET /") + configStore.cloudToken + "/update/"
                                    + vx + "?value=" + value, "", response)) {
  DEBUG_PRINT("Value from server: ");
  DEBUG_PRINT(response);
  }
}

Gives me initially >5.6sec :

rl␀l��|␀�l�|␂␌␌␌�␌l�␌b|��␂�␒�r�b�␌b��nn�lnn���␌b␜p�lrlrlp�n
Temp: 20.0, Humidity: 53.6 Vcc: 3.02
Going to sleep after: 5.66

rl␀l��|␀�l�|␂␌␌␌�␌l�␌b|��␂�␒�r�b�␌b��nn�lnn���␌b␜p��lrlrlp�
Temp: 20.2, Humidity: 53.0 Vcc: 3.02
Going to sleep after: 5.69

rl␀l��|␀�l�|␂␌␌␌�␌l�␌b|��␂�␒�r�b�␌b��nn�lnn���␌b␜p��lrlrlp�
Temp: 20.0, Humidity: 53.3 Vcc: 3.02
Going to sleep after: 5.79

rl␀l��|␀�l�|␂␌␌␌�␌l�␌b|��␂�␒�r�b�␌b��nn�lnn���␌b␜p��lrlrlp�
Temp: 19.9, Humidity: 53.8 Vcc: 3.02
Going to sleep after: 5.70

ldb · September 24, 2018, 10:18pm

Latest update:

@vshymanskyy do you have something similar with GSM? I’ll get a NB-IoT SIM7020e and try.