Contents
Getting a low consumption of our ESP8266 for use with battery is the goal we want to achieve, and in this article we will continue the experiments.
We will try to optimise time that our meter is "awake" and for that we need to know, first of all, what operating times we are talking about.
The previous experiment
In the previous article, we got our CO2 meter to work with one 18650 battery for 12 daysreporting values via MQTT every minuteThe first step is a simple experiment.
These are the rules we used for the previous experiment (there might be some difference because, unfortunately, I didn't save them):
On [Sunrise#PPM] do
publish,%sysname%/Sunrise/PPM,[Sunrise#PPM] //publish CO2
publish,%sysname%/Battery,[Battery#Volts] do publish,%sysname%/Battery,[Battery#Volts] //publish CO2
publish,%sys
If [SleepEnable#State]=1
deepsleep,60 //go to deepsleep for 60 seconds (even if deep sleep value is not configured in the config menu)
EndIf
Endon
On MQTT#Connected Do //when the broker is connected
If [SleepEnable#State]=1
publish,%sysname%/status, "Deepsleep Enabled" //publish information
timerSet,1,1
Else
publish,%sysname%/status, "Deepsleep Disabled" //publish information
EndIf
EndOn
On Rules#Timer=1 Do
deepsleep,60 //go to deepsleep for 60 seconds (even if deep sleep value is not configured in the config menu)
EndOn
On System#Wake Do
publish,%sysname%/status, "Wake" //publish information
EndOn
On System#Boot Do
publish,%sysname%/status, "Boot" //publish information
EndOn
On System#Sleep Do
publish,%sysname%/status, "Sleep" //publish information
EndOn
And here you can see the time our microcontroller was on and its power consumption. (1mV=1mA consumption with an offset of approx. 8mV):
Let me explain, in detail, how to interpret this graph so that you can interpret this graph and the following graphs yourself. There is a lot of useful information in the graph and, depending on your powers of observation, you may detect a lot more than I am describing in this article, as the amount of information it contains is analogue (infinite):
In the vertical scale you have some numbers, such as 0.004, -0.016, -0.036, etc. These numbers represent the consumption of the entire meter at any given moment. As you can see, each horizontal division is separated by 20 millivolts, which represents 20 milliamps of consumption (1mV=1mA).
These values have an offset (deviation) of 8mA, caused by the measuring instruments.
If at a given moment on the scale you see -0.026V, this means that the consumption at that moment was 26mA.
In the horizontal scale you have the time in seconds. Each division on the horizontal scale is 1.12 seconds.
The times refer to the moment at which the data capture (before the meter is switched on).
You will see, for example, that the meter starts up at second 4.35 and starts with a small consumption peak of about 30mA followed by another peak of about 40mA and another peak of 118mA and then goes down to about 26mA and stays there for a few seconds.
As you can see the meter is on a total of 10,186 seconds.
Baseline (starting point of consumption)
As I am doing these experiments with ESP EasyThe first thing I am going to do, before we start communicating with the CO2 sensor, sending data via wifi, MQTT and so on, is to do a first analysis in which I will put a rule in ESP Easy (in System#Boot) that will put the microcontroller back into deep sleep mode, without doing anything else.
This will help me to check which is the minimum time that ESP Easy allows me to keep the microprocessor awake.
ESP Easy is like an operating system. It has its own start-up procedure in which it does its own business, initialisation, creation of its data structures, searching for available plugins, etc. and this takes some time.
We assume that we cannot claim to have the same control over the microcontroller as we would have by programming it directly, in C++.for example, where we own every microsecond that the microcontroller uses. That is the price to pay for a system as simple as ESP Easy, which no programming required.
Although the first thing we do, when ESP Easy starts and we have control, is to put the microcontroller back into deep sleep mode (running a rule in System#Boot), this will take some time and that time will be that baseline or minimum time, over which we will start to add other things that will consume time (communications with the CO2 sensor, connection to the wifi network, sending data, etc.).
In this case, I have added the following rule:
On System#Boot Do
If [SleepEnable#State]=1
deepsleep,30 //go to deepsleep
EndIf
EndOn
This rule is executed as soon as ESP Easy starts up (or wakes up from deep sleep) and checks if SleepEnable#State is equal to 1 (this is a switch I have placed on one of the pins to enable and disable deep sleep mode at will). If SleepEnable#State is equal to 1 returns to deep sleep mode for 30 seconds.
This is the result:
As you can see, the microcontroller is awake during 2,133 seconds. This is the minimum time time it takes to start ESP Easy, run the rule and return to deep sleep state without doing anything else.
Is there room for optimisation of this part? There might be. I'll have to do some more testing, playing with some values in the ESP Easy configuration and even compiling a custom version that doesn't include support for any sensors that are not essential.
Reading the CO2 sensor
The next test I am going to perform is to see how much longer it takes to I do add the measurement of the CO2 sensor.
I have several options here, and I'm going to try some of them...
The first test will consist of enabling the device corresponding to the Senseair Sunrise sensor I am using in the Devices tab, with its default values, and force the sensor reading from the rule.
During this test I am going to keep the sensor on and permanently enabled so that it is ready to provide the measurement and avoid the waiting time while the sensor starts up and provides the measurement (the ENable pin of the Senseair Sunrise connected to +5V). This time will probably be minimal, but I don't want it to influence.
This is the rule I am going to use:
On System#Boot Do
If [SleepEnable#State]=1
taskrun,1
deepsleep,30 //go to deepsleep
EndIf
EndOn
This rule is the same as the one I used in the previous example, but note that I include the line "taskrun,1". This command, in case you are not familiar with it, tells ESP Easy to read the measurements from sensor number 1 in the Devices tab (in this case sensor number 1 in the tab is the Senseair Sunrise, ESP Easy lists them as "Task"):
And this is the result:
hmmm... this has really changed a lot... see?
To start with, where before we had an almost flat consumption line, now we have a consumption line full of periodic peaks (the sensor consumption) and, above all, now our ESP8266 is awake for much longer...
I have marked, with red circles, two pieces of information that I want you to see:
The first one on the upper right is the time that ESP8266 has been awake 8,533 seconds (previously it was 2.133 seconds). This time is the time elapsed between the first green vertical line (marked "a") and the second green vertical line (marked "b").
The second one, in the central part, is the consumption of these peaks of the Senseair Sunrise, 6mA. It is the difference between the two horizontal green lines (which limit the top and bottom of these peaks).
By the way, in case you don't know and as a "general gadgetry culture", those green lines, which oscilloscopes show to help measure differences, values, etc., are the ones you can see in the oscilloscope. are called cursors.
The increase in time for reading the sensor has been of 6.4 seconds, unacceptable. Further tests will have to be done to see if it is possible to reduce this time.
Read CO2 sensor and send measurement
The above examples were good because they allowed us to establish a baseline from which to start, but they were quite uselessfrom a functionality point of view.
The ESP8266 would wake up, read the sensor, go back to sleep, and so on and so forth (without doing anything at all). nothing with these measures, which were lost like tears in the rain).
In this experiment we will send measurements by wifi to a server using the MQTT.
Remember that this involves activating the ESY Easy MQTT driver, which will force you to connect to the MQTT broker, and this takes time.
These are the rules I will use for this experiment:
On MQTT#Connected Do //when the broker is connected
If [SleepEnable#State]=1
publish,%sysname%/status, "Deepsleep Enabled" //publish information
publish,%sysname%/Sunrise/PPM,[Sunrise#PPM] //publish CO2
deepsleep,30 //go to deepsleep
EndIf
EndOn
This rule is executed when the event occurs. "MQTT#Connected".which generates automatically ESP Easy when connecting to the MQTT server (why do anything before this point?), and what it does is to send two MQTT messages and return to deep sleep mode for another 30 seconds.
Once the MQTT controller is activated, the consumption is as follows:
As you can see, I have separated the cycle with two cursors so that you can differentiate the time in high consumption (which corresponds to the maximum wifi activity), which has the greatest impact on the battery. On the right edge of the image you can see that the increase in time between cursor "b" and cursor "c", which corresponds to the area of maximum consumption, is 3.578 seconds.
Below, you can see two complete cycleswhere our meter wakes up, reads the sensor, sends the data via MQTT, goes back to deep sleep, wakes up, reads, sends, and goes back to deep sleep. This will allow you to see how long the deep sleep state lasts and its consumption:
As you will see I have placed cursors on the oscilloscope at the beginning and end of every "wake up" so that you can check these times (on the right edge you can see the time increments between them, e.g. that the deep sleep time between the two "awakenings"is 20.067 seconds).
To be continued...
Loto Instruments OSC482 USB Oscilloscope
I would like to take this opportunity to comment:
The oscilloscope used on this occasion (to which the screenshots correspond) is not my usual Rigol DS1054Z bench-top oscilloscope, but rather I used a USB oscilloscope Loto Instruments OSC482 and I want to tell you that I am delighted with it. (I mention this mainly because some of you have asked me about this issue).
I have owned (and still own) several USB oscilloscopes and the truth is that they were very limited and far from what a real oscilloscope is. I thought that all USB oscilloscopes were like that, but my experience and my opinion has changed completely with this OSC482.
If you want a USB oscilloscope that really works, I highly recommend it.
Cuesta just over 60 euros and you can find it here: Loto Instruments OSC482 USB Oscilloscope
The particular model that I have purchased is the OSC482L, which includes 4-channel logic analyser.
I'm likely to write a whole article about it because, in the few weeks I've had it, it's become one of the instruments I use the most on a daily basis. It is super easy for me to check what a microprocessor is doing, if a power supply is stable, if a sensor is communicating well, and many other things...
DID YOU FIND IT INTERESTING?
DON'T MISS OUT ON FUTURE EXPERIMENTS!
SUBSCRIBE TO THE NEWSLETTER AND JOIN THE TELEGRAM GROUP AND DON'T MISS ANY OF THE BEST.