Introduction

In a postscript to my last Blog:

https://www.element14.com/community/people/neilk/blog/2019/02/14/investigating-the-power-consumption-of-a-wemos-d1-mini-esp8266

I concluded that the power consumption of the Wemos ESP8266 during Deep Sleep was negligible - around 227 microAmps. This includes the current drawn by the USB-Serial interface and extra current drawn by the battery monitoring resistor chain.

This represents 22.7 mAh over 100 hours and is pretty negligible when set against a 2400 mAh battery. Therefore, anything that could be done to shorten the execution time of the sketch should be beneficial.

My only Wemos d1 mini is currently running a long term battery life test.However, I have a Witty ESP8266 which I can use to investigate whether I can shorten the execution time of the sketch.

Experiment 1 - Removal of Diagnostic Messages

The original sketch contained an abundance of diagnostic messages intended for output to Arduino IDE serial monitor. Obviously when the device is operating on battery, these messages are going nowhere but are presumably taking time to execute and, possibly, using extra power by driving the USB-serial interface.

I commented out all the diagnostic messages and uploaded the sketch to a Witty. My first attempt was a failure because the Wemos d1 and the Witty are not completely pin compatible and I picked the wrong Pin for the GPIO16 WakeUP to Reset pin jumper. After a bit of squinting to read the pin labels, I sorted that out and let the Witty run for 60 readings. Inspecting one of the log files, I could see that the time interval between readings was typically  59 seconds and sometimes 58 seconds. In fact,  60 readings took 58 minutes 48 seconds instead of 1 hour. This means that I need to shorten the Sleep Time correction factor by 1 second.

Experiment 2 - Stop listening to the Server Response

When the data has been posted to the server (or even if the posting fails), the Server replies with a substantial message, which the sketch was listening to and then copying to the serial interface for diagnostics. What happens if we stop listening to this message?

I commented out this section of the code and reduced the Sleep Time correction factor by 1 second - now 4 seconds - as in Experiment 1, above..

After running the Witty for only a few readings I could see that time interval was now around 56 seconds and the LED indicating that a reading was being taken was just a flash, not 4 seconds of continuous illumination. So I have shortened the execution time by ignoring the server response. This also reduces the length of time for which the LED is on - a further power saving?.

I removed the sleep time correction factor completely, recompiled and repeated the test. After running the Witty for 60 readings, I could see that the interval between readings was now frequently LESS than 1 minute and that 60 readings now took about 59 minutes 40 seconds!

Somewhat confused, I consulted Mr Google and soon discovered that the Sleep Timer is not very precise - not the best crystal. The suggestion was to trim the Sleep Time to achieve the desired value. However, before I get into that, I have one further software change to try.

Experiment 3 - Don't start the Serial Interface

The first thing the sketch does in setup() is:

  Serial.begin(9600);
  delay(100);

I think a delay after Serial.begin is fairly traditional!

Commenting these out will slightly shorten the execution time. I modified accordingly and ran a test.

After a few minutes I checked one of the log files and found that the time interval between readings appears to be slipping consistently by around 0.5 seconds per reading. I decided to let this run for 100 readings before calculating a correction factor and modifying the sketch accordingly. Over the period of 100 readings, the time lost was 41 seconds, so the correction factor should be 41 / 99 = 414 mSecs (this may be excessively precise!.)

I modified the sketch to incorporate this correction factor and ran another test for a much longer period - necessary since we are looking for a much smaller potential error in each interval. Over around 550 readings, the interval between readings is almost consistent at 60 seconds. Now and again a 61 second interval appears, usually, but not always, followed sometime later by a 59 second interval. Over the 550 readings, the total time slip is 4 seconds.

Further Thoughts

A more important consideration is what will happen to the actual time interval between readings if we set the sleep time to be 5 minutes? The sketch takes a finite time to execute - maybe a second or two - and yet a sleep time of 1 minute results in a time interval between readings of approximately 59.5 seconds, unless we include a correction factor. This implies that the real error in sleep time is actually greater, perhaps more than 1.5 seconds in 1 minute. So, setting the sleep time to 5 minutes could result in a much bigger error.

Modifying the sketch and setting the Witty off on another long term test which I will report on later.

Meanwhile, the final version of the sketch, as described above, will be uploaded to the Wemos d1 and another long term battery test set off. Again I will report on the results of this much later!

Watch this space......