DIY CO2 Monitor with Ultra Low Power Consumption

Last modified July 23, 2021

Would you like to have an ultra-low power CO2 monitor powered by alkaline or rechargeable batteries , with several weeks, or even months, of autonomy? In this article I am going to present you this portable CO2 monitor, its development, the tests carried out, its details and the reason for things.

After four months of R&D (research, testing and development), the ultra-low consumption CO2 meter is now a reality. This working for several weeks and it's working very well.

The meter is not finished yet to publish it. There are some functionalities and improvements left that I want to implement and, above all, more needs to be done regarding consumption optimizations to improve their autonomy.

At this time I estimate that the CO2 meter has an autonomy of three months with CO2 concentration updates every five minutes.

I said "I estimate" because there has been no material time to keep the meter working permanently for so long and I have only done small tests of five days maximum. My estimate of a month is by extrapolation (2850mAh 0.71v battery drop after running for 5 days measuring, displaying and reporting via radio (ESP Now) every minute) plus the energy consumption measures that you can see later.

Let's start with a little video in which I'm going to show you the meter:

Next, I'm going to tell you what it was the motivation to design and document the construction of this CO2 meter, why have I made the decisions I have made regarding their components and functionalities and what I hope is the future. I'm also going to tell you to who is it addressed this meter and what the monitor is not.

Motivation to design a DIY Ultra Low Power Consumption CO2 Monitor

In recent months, due to the Coronavirus pandemic, with the possibility of reduce the chances of transmitting Covid, improving ventilation and using the measurement of CO2 concentration as an indicator of how good or bad it is, there have been many people (hundreds in fact) who have come to the blog and have built their own CO monitor following the tutorial that I wrote.

Sure, with so many people building the meter (each with their own motivations) the requests for new features have been constant, and I have been publishing extensions and improvements to cover most of them.

One of the most demanded options was for the monitor to be battery operated, I created a tutorial, months ago, to provide it with this functionality using simple, cheap and easy to find components.

Of course, it is not the same, although the result can be very good, as has been the case, equipping a regular CO2 monitor with a rechargeable battery system ,, than to create a CO2 monitor designed from scratch to have great autonomy.

With the previous meter it had practically peaked, from a balance autonomy / simplicity of construction for the average hobbyist / cost / portability. Although I am still adding small improvements in that regard, a new design, starting from scratch, was more worth the effort.

I thought it made no sense to improve its autonomy by complicating its firmware system (that I think it is his greatest virtue, for the extremely easy which turns out for anyone who doesn't have a clue about all of this).

Either making the hardware more complex, using surface mount components (SMD) than the average hobbyist could not solder easily or what will you force to use a custom printed circuit board.

Could have been possible to increase autonomy with bigger batteries, at the costs of reducing its portability (and anyone willing to do it can do, with the existing design).

Nor by going to tremendously expensive components that skyrocketed the monitor's cost.

It was clear to me, this monitor does not come to replace the previous one, which is still perfectly valid and the very first choice for anyone, but to to complement it, to give a choice interesting and of high quality to those who need a good autonomy without compromises.

Requirements for the DIY Ultra Low Power Consumption CO2 Monitor

One of the first things I thought about, before starting with the new design, was to make a list with the requirements that the monitor should have. I was going to divide it into requirements essential, desirable and expendable.

This is the list that I ended up with, removing those things that are too technical or that, at some point, were on the list for a short time and I decided to quickly eliminate.

Essential requirements

  • Great autonomy: Although it can depend a lot on the configuration the user has for the monitor and the use he make of it, does not seem to me that we can call 24 or 48 hours a great autonomy (it's already possible with the regular CO2 meter), although it is the battery autonomy you can expect from most of the commercial meters with battery (and in one of my tutorials it is already documented how to do it, including detailed step-by-step video tutorial).
  • Low consumption screen: For a monitor of this kind and with its intended purposes and uses, I cannot think of any other option but an e-Ink display. We can not depend on a mobile or a computer to know the concentration of CO2 nor can we make it difficult to see at a glance (without the need to press buttons or wake up the monitor somehow). Nor is it a solution to have a simple colored led «all / medium / nothing«. Of course, having a screen should not be at odds with autonomy, so you have to choose the low-power screen well.
  • High-quality sensor: There may be cheaper options, but just like with the regular CO2 monitor,I was not willing to do without having high quality CO2 concentration measurements, which we could trust. The truth is that there are few CO2 sensors on the market that meet the quality levels that I wanted for this monitor.
  • Possibility for choosing different CO2 sensors: Not everyone has the same facility to get different CO2 sensors. This project has been designed so that from the first moment it can be carried out with the two most recommended ultra low power sensors at the moment, the Cubic's CM1106SL-NS and the Senseair S11 Sunrise (the same sensor that the manufacturer Aranet uses in its Aranet4 and Aranet4 PRO). In addition, it is easy to adapt other sensors.
  • Power management: The meter must have a good energy management system that allows things like use with a rechargeable battery or external USB power supply / charger of the user's choice, control and display of the battery level, and that allows charging and using it simultaneously.
  • Compact size: It is important that the meter be really portable, that we can easily take it from one place to another. As you will see, there are two versions of the meter with different thickness (depending on the battery used, and therefore its autonomy) but both are very compact.

Desirable requirements

  • Radio communication: Not everyone needs it, but, let's be serious, having radio communication of the measured data opens up a range of possibilities that, in my opinion, multiply the meter value x100. Yes, it must be done the right way. Radio communication is energy hungry by nature and I was not willing to loose great autonomy in exchange for providing it with radio communication.
  • Local data storage (data-logging): Yes. We do not always have the possibility of providing the monitor with radio communication, especially when it is operating in a portable way. In these situations, it can be extremely useful make the CO2 monitor able to record the measurements it takes locally, on their own memory or SD card, for example, to be able to download and work with them later.

Expendable requirements

  • Wi-Fi connection: Having a Wi-Fi connection can be interesting, but at what price? This technology clearly conditions consumption and autonomy of the meter.
  • Sending data by MQTT: Intimately linked to the previous one. Of course, many people will be able to live without it and the meter would still be very useful, but it opens up a huge universe of possibilities.
  • Sending data by HTTP: Opens the possibility to integrate the meter with all kinds of services.

There were other requirements that would determine the ease of access to the meter, such as its cost, the facility for sourcing the components and its ease of building.

Ultra Low Power Consumption DIY CO2 Monitor Features

We have already seen the requirements, their implementation, inclusion or compliance depends on whether more or less functionalities can be implemented ...

Which of the requirements that we have seen before have I left out? Easy, none. Everything is included, without conditions, a fully equipped CO2 monitor. This opens the door to the implementation of a large number of functionalities. Many of them are already available, others will be soon, and others I have left to be incorporated by other users in a collaborative way.

By the way, this time the firmware is written in the C ++ programming language (the Arduino dialect). This has meant much more programming work, but instead, the possibilities for expansion are unlimited not being tied to the rules and limitations of a «firmware framework» or packaging, as was the case with ESP Easy on the regular meter , (witch, on the other hand, does its job wonderfully and has been an excellent choice, hearing to their users).

Functionalities implemented in the CO2 monitor

These are some of the functionalities already implemented in the meter: [end of manual translation, sorry. From here on it is an automatic translation. Hope to finish the manual translation when I have some more time]

  • First thing: measure CO2 concentration and get it right
  • Configurable CO2 concentration measurement period
  • Sending data via radio, super efficient in consumption through ESP-NOW protocol
  • Possibility of sending MQTT and HTTP data through a satellite communications coprocessor or gateway (gateway) without affecting the meter's consumption
  • Possibility of sending MQTT data autonomously (with Wi-Fi, logically reducing its autonomy).
  • Manual calibration by push or MQTT command
  • Remote commands by MQTT to change the measurement period
  • Configurable display hysteresis to reduce consumption
  • Hysteresis of data sending via radio configurable to reduce consumption
  • "Single measurement" operating mode of the sensors that support it
  • Operating mode «low power» of the sensors that support it
  • "High performance" operating mode of the sensors that support it
  • Rolling average (rolling average) for configurable and deactivatable data smoothing
Maybe you are also interested in:  CO2 monitor with ESP8266 (NodeMCU) and Senseair S8 sensor

Features in process or what I think / want to add

  • Local data storage (data logger)
  • Possibility of autonomous HTTP data sending
  • Screens with historical graphs of measurements
  • Sending data via LoRa and LoRaWAN
  • Sending data via Bluetooth Low Energy (BLE)
  • Complete WEB interface for configuration, data visualization in real time, historical, etc.

Hardware components and design

I have tried to design the meter with components of relatively low cost and relatively easy to get, but no compromises in order to achieve a good result, with a good value for money, although, logically and due to the components that must be used and their price, the cost of this meter will be higher than the meter "normal", intended for everyone.

We are going to see the components one by one, with the necessary observations.

Ultra low consumption CO2 sensor

The choice of this component is review for two reasons:

  • It depends on him quality of measurements CO2 concentration
  • It depends, in large part, consumption and autonomy CO2 meter

It may also depend on the sensor to have a good result guaranteed on the first attempt or not have it.

I am not going to elaborate much on sensors because I am going to write a specific article comparing in depth the main low consumption sensors that we can find in the market.

I will only tell you that for this design I have used those that I think have the best value for money on the market. This is important since an important part of the cost of the meter will go into it.

In addition, the sensors that I propose have been tested by me personally long and hard and those of you who know me know that when I test sensors, I do it conscientiously, dedicating many days (sometimes months) to analyzing each sensor.

Of course, not all are the same, each chosen CO2 sensor has its advantages and disadvantages, its strengths and weaknesses.

The currently supported CO2 sensors are as follows:

  • Senseair Sunrise S11 NDIR Sensor (Completing Deployment)
  • Cubic CM1106SL-NS NDIR Sensor
  • Sensirion SCD41 Photoacoustic Sensor

I will add more sensors as I have them available (Are you a manufacturer or distributor and you want your sensor to be supported? contact me, if the sensor is good and passes the tests, I will implement it with pleasure).

Environmental data sensor

To collect environmental data, several sensors are supported (with the possibility of including other sensors easily).

Although I used the DHT22 sensor during component testing, I have finally decided not to use it in the prototype. I do not think this sensor is recommended for this project (except that, being somewhat cheaper, it is decisive to be able to do the project) because its measurements are not too precise, it has a very long reading time and a considerably higher consumption than others .

Finally, in the prototype, I have used the Si7021 temperature and humidity sensor.

Si7021 temperature and humidity sensor

The Si7021 sensor consumes very little and is quite fast, but at least the unit that I have measures the temperature a couple of degrees above the real one.

I have not done any serious test with the Si7021 because I am very busy with other things (you can imagine) but I will.

On paper it would be a perfect sensor for this project.

LilyGo T5 2.13 ″ plate

There have been several things that have made me decide on this board, including several of the necessary components on a single board (and one of the most important).

Some of the things have to do with each of its components and others refer to the plate itself «like an everything«.

If I tell you about the LilyGo TTGO T5 2.13 ″ plate «As a whole», I will tell you that it is a plate that greatly simplifies the project with very acceptable components, putting it within the reach of any maker amateur.

LilyGo T5 2.13 board with e-Ink display

Would the meter be better using other different components who does this badge bring to?

Maybe a little (very little) but in my head it was clear that it wasn't going to be worth the effort (neither mine nor yours, you are probably considering building it). It was going to make the assembly very difficult for most fans, greatly increasing the complexity, The number of cables and welds, the possibility of mistakes, he physical size busy and the fact that some of the best solutions are not available as «ready to use plate»But it would have to be built starting from its components (surface mount, SMD, in many cases).

I'm going to talk to you about each of the parts that are already included in this board, as if they were independent (and the truth is that it would not have varied much on what you would have chosen if this board didn't exist).

Before continuing, a notice and warning: there are many very similar plates that they look the same, but they are not. Even different revisions of the same plate model may have major differences that make the project not work (or it doesn't work as well as it should).

If you are going to build the ultra low consumption CO2 meter I suggest you, I recommend you and I ask you to use this same LilyGo TTGO T5 2.13 ″ plate, from the same link where I bought it. The same for trying to save a euro or two (or dollars) tempts you to buy it elsewhere and you end up with something that does not work. In my opinion it is not worth the risk of buying it elsewhere.

This is the link where I bought the LilyGo TTGO T5 2.13 ″ plate. Anyway, if you're only going to use it for this project, I suggest you don't buy it yet because I still have tests to do and there could be changes. If you want it for other things, perfect, go ahead, it's a good plate.

If you still decide to use another plate and get that apparently work well, tell me to find out, but, unless you have measuring instruments that normally amateurs do not usually have (such as adequate instruments to measure very small currents with a very wide dynamic range, no voltage drop by insertion -burden voltage- and oscilloscope) I am not going to recommend them for this project because there is a high possibility that something does not go well and that the result is not what is expected.

I hope that with the passage of time I can add other plates to the project (personally tested by me) so that you can use them with reasonable guarantees of success. Today this is the only one.

And I do not say it for say. I have tried with many different combinations of the components present on this board and this is the only one that has worked properly. Later I will give you more details of why.

Update: I have built two other prototypes with two more screens (one of TTGO of 2.3 ″ on an all-in-one board with ESP32 as shown above, and another with a loose ESP32 and a independent display 2.9 ″ Waveshare with good preliminary results).

Microcontroller used in the meter

I gave a lot of thought to which microcontroller to use for this project, although finally the decision was clear for many reasons: price, availability, user-friendliness, etc.

The microcontroller I was going to use would be the ESP32 from the manufacturer Espressif Systems.

This microcontroller has everything we need: a very good price, multitude of pins available, a acceptable consumption in its low-power modes, and best of all: ease of use and extensive knowledge by hobbyists.

Would a nRF52840 from the manufacturer Nordic Semiconductor?

From the point of view of consumption, surely yes, although not as much as it might seem at first glance, because as we will see later, the microcontroller is not what consumes the most, but there were powerful reasons not to do it with it:

  • It would have been more expensive
  • Incredibly harder to build the project for a hobbyist
  • Its programming is much more complex
  • There are less information available and less easy tutorials available
  • We probably would have needed a custom printed circuit board, from which I try to flee as long as possible
  • We would have had to give up wifi (and therefore to ESP-Now, which is an excellent solution for this type of application).

It is possible that in the future I will design other meters that use other microcontrollers (and the truth is that I really want the nRF52840), but for this project, and putting everything in the balance, the ESP32 is the right decision.

DEPG0213BN screen (display) used in the meter

The display is a very important part of the meter.

On one side, greatly affects consumption and autonomy that can be obtained from the meter. On the other hand, its resolution, readability, graphic capacity will have an important impact on the usability, the perception of the meter by the public (we all like our "gossip" to be liked and pleasing to the eye) and its expandability.

It was important to get a low power screen, good quality and visibility and ease of purchase and assembly for the average user.

I decided on a screen e-Ink (also called e-Paper or electronic ink) after many tests and analysis.

These screens have the great advantage that its consumption is practically nil when it is not being updated. In other words, it only consumes at the time of changing what it shows. You can even loosen all cables (including those for your power supply) and the screen will continue to show what you had at the time for months or years.

Another advantage of e-Ink displays is their extremely high display quality, mainly due to its huge contrast and viewing angle.

Finally, another reason for choosing e-Ink technology is the great variety of screens of this type that exist. We have them from many sizes and even in color. At this moment only one screen model is supported, but in the future it will be possible to include support for other screens to meet the needs or tastes of users.

In exchange for all these advantages, you also have some drawbacks. Mainly its slowness and the problem of "ghosting" (ghost images).

E-Inks are relatively slow, they take a long time to update what is displayed on the screen (in the order of two seconds in which I have chosen) and during this time the screen flashes several times. For what there is to be very careful in software design to optimize these times and that it is not annoying for the user.

Then you can see the different update modes of the e-Ink screens and the flickers I mean, to give you the idea.

You will see partial updates (when the screen flickers switching between black and white) and partial updates occur, which do not cause flickering.

Nothing prevents doing a "partial" update of the "whole" of the screen. It is a way to avoid flickering, although this has a limit and every x partial updates it is necessary to do a total update or the dreaded "ghosting" will appear.

Maybe you are also interested in:  Geiger Counter (Radioactivity Meter)

The "Ghosting" effect, which may appear, causes old images to remain softly marked on the screen for a while (or definitely, in case of misuse).

To solve the two previous problems, inherent to e-Ink screens, the chosen screen supports a mode of partial update. This allows us to update only one or more parts of the screen in a much faster way, with less current consumption and without flickering.

To avoid ghosting you have to keep doing a full screen update from time to time (with its two seconds duration and its blinks). I have designed the meter software so that this is user configurable.

By default the screen does a full update every 30 partial updates. If the measurement period is, for example, 5 minutes, it will only do one full update every two and a half hours.

For optimize this further, I have implemented in the firmware what I call «hysteresis display«. This allows the screen to be updated only if there are significant differences in the meter values with respect to those shown on the screen. We can configure the CO2 meter so that, for example, the screen is only updated if the change in CO2 concentration is greater than 50 ppm or the temperature greater than 0.5ºC. This is fully user configurable and it can greatly reduce consumption.

And if the e-Ink screens have so many peculiarities, why haven't I used another screen?

The simple answer is: because I think that e-Ink is the best for our goals if we take everything into account (price, consumption, quality, ease of use, ease of obtaining them, etc).

I could have used a "Memory Display" from the manufacturer Sharp. Consumes even less and is much faster. Unfortunately, it is much more difficult to use, because there is no hardware already prepared easy to use for the hobbyist and at an affordable price, and it would have been necessary to build a custom printed circuit board with quite a few components (not only the screen, but a controller integrated circuit, various capacitors, resistors, transistors, components for its power supply, etc. .).

Also the «Memory Display» are harder to get, More expensive and with less variety to choose.

Power management

The energy management of a project like this is not something trivial or easy to implement.

It is necessary to choose voltage regulators with very low internal consumption, that consume very little in rest, that allow the correct charging and supervision of the battery, in addition they must correctly implement a system of "Load sharing" or "power path" (very important) that allows power from battery or external power and charge the battery while using external power (the meter does not stop working at any time), all simultaneously and in the right way and safe.

The board that I have chosen takes care of all these points in a way quite efficient. Without a doubt, it can be improved, but a much higher cost and complexity, and in my opinion it is not worth it (for a project that anyone, non-specialist, can easily mount, let's not lose sight of the objectives and the target audience).

Another interesting detail of the chosen plate is that you have already connected the battery input to an ADC pin with its corresponding resistive divider. This is important, not only in order to know the voltage of the battery, but also to prevent the meter from operating below a determined voltage, since below that voltage the data obtained by the CO2 sensor may be incorrect.

In the following graph you can see how when the voltage (blue line) drops below a point (2.78V in this case) the measurements provided by the Cubic CM1106SL-NS (green line) are no longer correct. In this case we can see it when comparing them with the reference sensor (orange line), a Senseair S8.

Micro SD card reader - writer

An interesting option that I have not tried yet, but I will do it and tell because one of the things I want to implement in the meter is the recording of measurements in Micro SD (data logger).

I'll tell you ...

Buttons and switch

The plate has a switch that allows it to be turned off completely and two buttons on one of its sides, one of them to reset and the other freely available that, in the case of the meter, was used to start manual calibration.

It may seem silly, but it is very practical.

Board LEDs

The board has three LEDs.

  • One of them indicates that the hob is on
  • Other indicates that the battery is charging
  • I don't remember the third now ... I'll put it (or were there only two?)

It does not make sense, for a meter with low consumption and great autonomy to spend precious energy in keeping an LED consuming just to inform us that the meter is on, so that I have eliminated that LED (and with it its consumption) skinning it from the plate.

Tests and prototypes carried out

To get to get the CO2 meter with great autonomy, which I am talking about here, they have been necessary many tests with different sensors, components, configurations, firmware, strategies, etc.

In each of these tests it was necessary measure the consumption achieved, using specialized instruments for this type of measurements, because, although theoretically you can calculate which should be consumption, in practice, this it can vary a lot (and I assure you it does).

I am not going to go into the details of each of the tests and prototypes, because it would be a huge job to describe it, but if I am going to show you below some milestones or moments of development.

Prototype with ESP8266, Senseair Sunrise S11 sensor and ESP Easy firmware

This prototype meter used the same microcontroller as the meter «," Y the same firmware (ESP Easy).

The autonomy I got was not bad at all for not having a specially optimized firmware (about 14 days, with a 2850mAh 18650 battery, sending data via Wi-Fi via MQTT every minute).

It soon became clear that the chosen processor was too short for what it wanted to do due to the few pins it left available to connect the e-Ink display (which uses six pins) and something else.

Nor was the ESP Easy firmware ideal. It did not have support for the e-Ink displays that I wanted to use.

This meter also required communication via Wi-Fi (which is very slow while connecting to the network) instead of ESP-NOW. To give you the idea, I needed about 11 seconds awake (consuming to the maximum) to connect to the wifi, read the CO2 concentration and send it through MQTT, while the one that I am describing in this article takes about a second to do it ( and it sure will take less time when it is more optimized).

Prototype with ESP32 ‑ DevKitC board and Waveshare 2.9 ″ e-Ink display

Here you can see a prototype using an ESP32 ‑ DevKitC board as a microcontroller, a 2.9 "Waveshare e-Ink display with GxGDEW029T5, a Cubic CM1106SL-NS sensor for CO2 and a DHT22 temperature and humidity sensor.

This prototype had the following problems that had to be solved and / or improved:

  • I could not keep the screen consumption low without having to do a full update every time the meter came out of deep sleep (the low power mode) having to do a full update, with its blinking, which lasted about 3 seconds. Of course, in this way his consumption in deep sleep was of practically 0 µA
  • Aside from the relatively poor measurement accuracy of the DHT22 temperature and humidity sensor, it it is very slow measuring which forces you to have to keep the meter in high power mode for a longer time, while the sensor provides the measurement (or to do a little work, complicating the code further).

If you want to use this screen for another project and you do not need partial refreshment when you return from deep sleep, the 2.9 "Waveshare e-Ink display with GxGDEW029T5 It may be a good choice. It is very well priced and its display quality is very good.

Update: It seems that I have partially solved the problems with this screen and I have a prototype working with a Sensirion SCD41 sensor. There are still some ghosting issues to fix.

Prototype with ESP32 board and Waveshare 2.9 ″ e-Ink screen

Here's another prototype, in this case using a LilyGo TTGO T5 2.13 ″ plate with ESP32, with the same 2.9 "Waveshare e-Ink display with GxGDEW029T5, a Cubic CM1106 sensor for CO2 and a DHT22 temperature and humidity sensor.

Is T7 V1.5 Mini32 board with ESP32 ″ it's very interesting. It is the board with ESP32 with lowest consumption Of all the ones I have bought (although there are others on the market with lower consumption, but they are usually more expensive and difficult to find).

In addition, it includes a good energy management system that allows it to be powered by USB, externally at 5V, at 3.3V and by means of a rechargeable Li-Ion or Li-Po battery. It has a charger and load sharing capacity on the same board. (or "power path", as you like) so that it can be used and loaded at the same time.

Unfortunately I cannot find the consumption data of the tests I did, but I will repeat the measurements to include them here. I think I remember that its consumption in deep sleep was of the order of less than 100µAh. I'll do more tests on it and document it properly because it's worth it.

It is very likely that in future versions of the meter with other e-Ink displays (when you find others that work well) use this plate.

Consumption and optimization

Have been many the tests and measurements performed during the development of this meter and in fact you have several articles with details about some of the tests carried out, measurements, etc.

If you want to know the details, you can see them in these four posts:

ESP Easy and deep sleep mode (ESP8266 low power)

Experiments with ESP Easy (ESP8266) and low consumption - v1.0

Experiments with ESP Easy (ESP8266) and low consumption - v2.0

Experiments with ESP Easy (ESP8266) and low consumption - v3.0

When I publish the project I will take the opportunity to publish the consumption measurements of the finished project. For now I leave you some provisional measures.

At the time of including this, the sensor was working in continuous measurement mode, which means more consumption, sending CO2, temperature, humidity and battery level data every minute and showing it on the display.

As you can see, in this test, the meter has been working for sixty hours with a 2850mAh 0.22v battery drop, measuring, visualizing and reporting every minute.

Later, in another test that you can see below, the meter has been running for five days with a 2850mAh battery drop of 0.71v, measuring, displaying and reporting via radio (with ESP-Now) every minute.

Also the graph shows the CO2 measurements next to my Senseair S8 reference sensor and, as you can see, the measurements differ very little between the two sensors.

The meter can have different consumption profiles, depending on the sensor used, the CO2 measurement mode and the different configuration parameters.

Then i leave you different consumption profiles with different scenarios. I will be documenting and adding new profiles as you make new tests and advances.

Maybe you are also interested in:  CO2 meter on your mobile with ESP32 and Sensirion SCD30 sensor [BASIC VERSION]

All measurements and graphs below have been made with the Cubic CM1106SL-NS sensor. Later I will add measurements with other ultra low power sensors.

Note that the Y axis scale changes to adapt to the maximum extent.

Consumption profile of a CO2 measurement, transmission and display update

Here you have the meter consumption profile for a period of 1 minute.

Being the first consumer profile that I show you, I am going to explain to you how to interpret the graph, and the information you can obtain from it, in considerable detail.

In this graph you can see that, during that minute, the meter is "asleep" most of the time (in low power mode or "deep sleep"), wakes up briefly and returns to deep sleep until the next cycle.

During this minute the average consumption has been 7.39mAh (this is the total average consumption of the meter).

In 24 hours the consumption would be 7.39mA x 24h = 177.36mA which means that with a 2850mAh battery, like the one I'm using, the autonomy would be 2850mA / 177.36mA = 16.06 days.

If we configured the meter to measure every 3 minutes, the autonomy would be about a month and a half and with measurements every five minutes we would be in about 80 days of autonomy.

Consumption profile of a CO2 measurement, transmission and display update

CM1106SL-NS in continuous measurement mode for a period of 1 minute. Display update.

During the minute that I'm showing you, meter is only awake for 3.2 seconds.

During those 3.2 seconds you are awake, your consumption maximum becomes 374.40aAh, leaving the average consumption at 100.27mAh.

In this graph you can see in more detail what happens at the consumption level during those 3.2 seconds (come on, that's a zoom on the shaded part of the previous graph), in case you are curious to know the variations in consumption in detail:

Consumption profile of a CO2 measurement, transmission (without display update)

In this tutorial I have told you about the "display hysteresis" functionality that I have implemented to reduce consumption.

What this functionality seeks is that it does not the screen is refreshed if changes in measurements do not exceed a user-defined threshold (Normally we don't need to know that the CO2 concentration has gone from 540 ppm to 545 ppm, we don't care). Thus we can greatly reduce the time the meter remains «awake« (and therefore its consumption).

In the following graph you can see how when we don't need to update the screen we managed to reduce that time from 3.2 seconds in the previous graph to 1.76 seconds, almost half the time (and consumption).

As in the previous case, I put a graph with that enlarged area so that you can compare it:

Meter consumption profile in deep sleep

To finish I leave you the graph of consumption in deep sleep.

In it you can see how the meter remains asleep between measurements for 59.33 seconds with a average consumption of 2.15mA.

I hope to reduce this average consumption in deep sleep shortly, for which I need to solve two things:

  • On the one hand, that the Cubic technical support answer me, since the sensor is consuming in deep sleep more than it should.
  • On the other hand, to reduce the consumption of the display and its controller, since it is consuming around 1mA, when its consumption in deep sleep should be almost 0mA (less than 100µAh in the worst case).

Cubic CM1106SL-NS CO2 Sensor Consumption Profile

We have one last important detail left, to have a complete view of the consumption of the meter and that is to know how much the CM1106SL-NS sensor consumes. In this way we can subtract it from previous measurements to know, for example, how much the LilyGo plate with the screen consumes in deep sleep or what part of the meter's consumption awake corresponds to the CO2 sensor.

In the following graph you can see 1 minute of the sensor life.

As you see, during that minute the average consumption of the sensor is 139µA. This is slightly more than double what Cubic, its manufacturer, indicates in its technical documentation.

Here you can see an enlargement of his consumption during the 2.5 seconds that he is awake:

Although I have not put the graph, I will tell you that the consumption of the sensor during the time in which it is asleep, its consumption is of less than 5µA.

The communications coprocessor or gateway

Wi-Fi is great, useful, fast, capable, and best of all, pretty much everyone has and uses it.

The negative point is that it is a great energy hungry (At the moment, it seems that with Wifi-6 and its specification 802.11ah, designed for IoT devices, this will be solved to a large extent).

Unfortunately, and until 802.11ah is available, if we were to use Wi-Fi right now, the autonomy would be disastrous, as it happens to any battery-powered device that uses Wi-Fi.

To solve this problem, I have used the ESP-Now protocol.

This protocol, developed by Espressif, allows a very important energy saving, using the hardware for Wi-Fi that we already have in the ESP8266 and ESP32 chips. A process of sending data that with Wi-Fi can take about 10-12 seconds, with ESP-Now it is reduced to a few milliseconds.

Of course, the routers and Wi-Fi access points that we have at home do not support ESP-Now, which makes it necessary to include a «translator» or «bridge», something than an ESP-Easy and Wifi.

The good news is that this is very simple and cheap, since we only have to load the firmware that I have prepared in an ESP32 (I also have to adapt it to the ESP8266, so that whoever wants to can use it), so that the cost of this gateway is less than € 5, which is what an ESP32 board costs.

This gateway receives the data from the ultra-low consumption CO2 meter through ESP-Now and forwards it through wifi via MQTT (already available and working), HTTP or whatever we want.

What's more, I have tried to program this gateway in a very simple way, so that any hobbyist with a little programming idea can modify it to implement any other type of gateway.

Among the gateways that can be included in the gateway, we would have:

  • Direct recording of data in DB InfluxDB, MySQL, MariaDB and the like.
  • Sending notifications and alerts through email, Telegram, Pushover, etc.
  • Integration in any control system, home automation, building automation, PLC, etc.
  • Any other type of RF implementation, with the necessary RF hardware (LoRa, LoRaWan, BLE, BLE Mesh, Bluetooth Smart, etc.).

Here you can see, next to one of the meter prototypes, the gateway i'm using right now (a simple T7 V1.5 Mini32 board with ESP32 ″)

And here a dashboard that updates in near real time with the data generated by the sensor after making this trip Esp-Now> Wifi / MQTT> Node-red> InfluxDB> Grafana

For those of you who use ESP Easy, good news: I hope to release a version of the ESP Easy based gateway (when ESP-Now is available in ESP Easy, for which, from what the person in charge of the ESP Easy project has told me, it will not be necessary to wait long), so including anything supported by ESP Easy in the gateway will be as simple as you all know...

Status and availability of the new meter

As I have anticipated, the meter is already working, and working quite well.

I have already recorded a extensive video tutorial where do i explain step by step and with all kinds of details and advice the meter mounting (edit: so many things have changed since I recorded the video that I will surely have to record it again).

The process of video montage, going from about 20 hours of recordings to an edited video of a suitable length (let's say thirty minutes) without leaving anything important out and with the necessary diagrams for easy understanding.

What am I waiting for then to publish it?

Well there is some things that are not finished and others that you have to to get better and that I want them to be in the first version.

In these four months of R + P + D there have been many obstacles that I have been encountering, but it seems that little by little I have been overcoming them. Now the following remain:

  • I am working on a problem with the consumption of the Cubic CM1106SL-NS sensor, which causes it to consume more than it should. This point is important to solve before publishing the project since it can affect both the code and the tutorial, video, recommendations, etc. I am in discussions with Cubic, its manufacturer, to try to fix it.
  • There is still some pretty messy code that only I can understand. As it is an open source and collaborative project, in which I hope more people will participate, I am in the process of cleaning up the code, removing debugging code that I have included during development and that is no longer necessary, documenting it, applying best practices , etc.
  • Ultra-low-power sensors typically have two modes of operation. One called "continuous measurement" and another called "single measurement." In the first, the microcontroller configures how often it wants the sensor to measure and it takes care of "waking up" to measure and provide a measurement, following that configured time. In the second it is the microcontroller that takes care of everything: wake up the sensor, tell it to measure, if necessary tell it to save calibration data and turn the sensor off again.
    At the moment I have only implemented the continuous measurement mode. I want, before taking it out, to implement the single metering mode, which is supposed to have a lower consumption.
  • I want to improve the aesthetic appearance of the meter displays. Right now they are fully functional, but they are just test screens without any design. I don't want it to be just a good meter, but to look like it and have a good design and usability.
  • I would like to further reduce the consumption of the e-Ink screen in deep sleep.
  • I want, before releasing it, to optimize the partial updates of the screen to reduce consumption and avoid flickering. It is not something determining because it can be improved later by means of a simple update and the autonomy is now acceptable, but I would like very much to be able to improve it before taking it out.
  • I continue to work on two-way communications between the meter and the gateway to increase its reliability and flexibility.

Updated 6/29/2021

  • I spoke with Cubic regarding the issue with the consumption of the Cubic CM1106SL-NS sensor to try to fix it. It is now (partially) resolved .; It turns out that this sensor in continuous measurement mode does not allow its deactivation through the Enable pin. I have fixed it by implementing single measure mode.
  • The single measurement mode of the Cubic CM1106SL-NS is already implemented, which has achieved good energy savings. Using this method, it is the microcontroller that takes care of all the activity: wake up the sensor, tell it to measure, if necessary tell it to save calibration data and turn the sensor off again, which makes it possible to better optimize its consumption .

Leave a Comment