Design of an ultra-low consumption CO2 meter

Would you like to have a CO2 meter powered by batteries ultra-low power consumption and with an autonomy of several weeks or even months.? In this article I am going to introduce you to this portable CO2 meter, its development, the tests carried out, its details and the reasons why.

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

The meter is not yet ready for publication. There are still some functionalities and improvements that I want to implement and, above all, more needs to be done. consumption optimisations to improve their autonomy.

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

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

Let's start with a short video in which I will show you the meter:

I'll tell you what happened next the motivation to design and document the construction of this CO2 meterwhy I have taken the decisions I have taken regarding their components and functionalities and which I hope will be its future. I will also tell you to whom it is addressed this meter and what is not.

Motivation for creating an Ultra Low Power Home CO2 Meter

In the last few months, due to the Coronavirus pandemic, and the possibility of reduce the possibility of Covid transmissionThe CO2 concentration measurement is used as an indicator of how well or poorly it is doing, there have been many people (hundreds) who have come to the blog and created their own meter following the tutorial I wrote.

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

One of the most sought-after options was the that the meter could be battery operated, y create a tutorialmonths ago, to provide it with this functionality by using simple, cheap and easy to find components.

Of course, it is not the same, even if the result can be very good, as it has been the case, to equip a CO2 meter with a rechargeable battery system. normalthan creating a CO2 meter designed from the outset to be highly autonomous.

With the previous meter, I had almost reached the ceiling, from the point of view of balance autonomy/simplicity of construction for the average hobbyist/cost/portability. Although I am still adding small improvements in this regard, It was more worthwhile to devote the effort to a new design, starting from scratch.

It seemed to me that there was no point in improving its autonomy by complicating its firmware system. (which is its greatest strengthand therefore extremely easy (which is a bit of a mouthful for anyone who doesn't have a clue).

Nor complicate your hardwareusing surface mount components (SMD) that the average hobbyist could not weld or who needed custom printed circuit boards.

It could increase autonomy with larger batteries, impairing their portability (and whoever wants to can do so, with the existing design).

Nor by going to tremendously expensive components that would drive up the cost of the meter.

It was clear to me, this meter is not intended to replace the previous onewhich is still perfectly valid and the first choice for anyone, if not to complement itgive a choice interesting and quality to those in need of a good autonomy without compromise.

Ultra Low Power Home CO2 Meter Requirements

One of the first things I thought about, before I started with the design, was to make a list of requirements to be met by the meter. I was going to divide it into requirements indispensable, desirable and dispensable.

This is the list I ended up with, removing those things that are too technical or that, at some point, were on the list ephemerally and I decided to remove them quickly.

Essential requirements

• Large autonomy: Although this may depend very much on the configuration made by the user. and the use of the meter, I don't think that we can call 24 or 48 hours a long autonomy (that is is already achieved with the normal CO2 meter.(although it is not as common for commercial battery-powered meters to achieve this, and one of my tutorials documents how to do this, including a detailed step-by-step video).
• Low-power display: For a meter of this type and for its intended purpose and use, I can think of no other option. We cannot relying on a mobile phone or a computer to know CO2 concentration nor can we make it difficult to be seen at a glance (without the need to press buttons or wake him up in some way). Nor is it a solution to have a simple coloured LED "all/medium/nothing". However, having a screen should not be incompatible with autonomy, and so the right choice of energy-saving display must be made.
• High-quality sensor: There may be cheaper options, but, as with the "CO2" meter, it is possible that the sensor can be used in the same way as the "normal"I was not going to do without having high quality CO2 concentration measurementsthat we could trust. The truth is that there are not many CO2 sensors on the market that meet the quality standards I wanted for this meter.
• Possibility to choose different CO2 sensors: Not everyone has the same facility for get different CO2 sensors. This project has been designed so that it can be carried out from the very beginning with the two most recommended ultra-low power sensors at the moment, Cubic's CM1106SL-NS and the Senseair S11 Sunrise (the same sensor used by the manufacturer Aranet in its Aranet4 and Aranet4 PRO). In addition, it is easy to adapt other sensors.
• Energy management: The meter must be equipped with a good energy management system allowing such things as use with rechargeable battery or external USB power supply/charger of the user's choice, control and display of battery level, and that allows simultaneous charging and use.
• Compact size: It is important that the meter be truly portableWe 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 measured data opens up a range of possibilities which, in my opinion, I think, is very useful, multiplies the meter value x100. However, it is well achieved. Radio communication is energy guzzler The new, long-range meter was not going to be allowed to lose its autonomy in exchange for radio communication.
• Local data storage (data-logging): Yes. It is not always possible to provide the meter with radio communication, especially when it is operating in portable mode. In these cases, it can be very interesting if the meter is in the form of a record the measurements you make locally, on your own memory or SD cardfor example, so that you can download them and work with them later.

Expendable requirements

• Wi-Fi connection: Wi-Fi connection can be interesting, but at what price? This technology clearly affects consumption and autonomy of the meter.
• Sending data by MQTTClosely 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 HTTPAnother of those functionalities to integrate the meter with all kinds of services.

There remained other requirements that would determine the ease of access to the meter, for example, its costthe ease of to get the components and its ease of construction.

Functionalities of the ultra-low power home CO2 meter

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

Which of the requirements we have seen above have I left out? Simple, none. Everything is included, no strings attached, one meter full equipe. This opens the door to the implementation of a a wide range of functionalities. Many of them are already available, others will be available 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 workbut, in return, the possibilities for expansion are unlimited by not being bound by the rules and limitations of a firmware framework, or packagingas was the case with ESP Easy in the meter. normal (where, on the other hand, it does its job very well and has been an excellent choice).

Functionalities implemented in the CO2 meter

These are some of the functionalities already implemented in the meter:

• The first thing: measure CO2 concentration and get it right.
• CO2 concentration measurement period configurable
• Super energy-efficient radio data transmission via ESP-NOW protocol
• Possibility to send MQTT and HTTP data via satellite communication co-processor or gateway without affecting the meter's consumption
• Possibility of sending MQTT data autonomously (with wifi, logically reducing its autonomy).
• Manual calibration via push button or MQTT command
• Remote commands by MQTT for measurement period change
• Configurable display hysteresis to reduce power consumption
• Configurable radio data transmission hysteresis to reduce power consumption
• Single measurement mode of operation of sensors supporting it
• Low power" operating mode for sensors that support it
• High performance" operating mode of the sensors supporting it
• Rolling average for data smoothing configurable and deactivatable

Functionalities in process or that I plan/want to add

• Local data storage (data logger)
• Stand-alone HTTP data sending capability
• Displays with historical graphs of measurements
• Data transmission via LoRa and LoRaWAN
• Data transmission via Bluetooth Low Energy (BLE)
• Complete WEB interface for configuration, real time data visualisation, historical data, etc.

Design and hardware components

I have tried to design the meter with relatively low cost components. low cost and relatively readily availablebut without compromise to achieve a good result, with the aim of good value for moneyHowever, logically, due to the components to be used and their price, the cost of this meter will be higher than the meter "normal"for everyone.

We will look at the components one by one, with any necessary observations.

Ultra-low power CO2 sensor

The choice of this component is criticism for two reasons:

• On him depends the quality of measurements of CO2 concentration
• Much depends on him, consumption and autonomy of the CO2 meter

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

I won't dwell too much on the sensors because I'm going to write a specific article comparing in depth the main low-power sensors that we can find on the market.

I'll just tell you that for this design I've used the ones that I think have the best value for money on the market. This is important as it will account for a significant part of the cost of the meter.

In addition, the sensors I propose have been tested by me personally Those of you who know me know that when I test sensors, I do it thoroughly, dedicating many days (sometimes months) to the analysis of each sensor.

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

The following CO2 sensors are currently supported:

• Senseair Sunrise S11 NDIR sensor (finalising implementation)
• Cubic NDIR Sensor CM1106SL-NS
• Sensirion SCD41 photoacoustic sensor

I will be adding more sensors as they become available (are you a manufacturer or distributor and want your sensor to be supported? contact me, if the sensor is good and passes the tests, I will gladly implement it.).

Environmental data sensor

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

Although I used the DHT22 sensor during the component tests, I finally decided not to use it in the prototype. I do not recommend this sensor for this project (unless, being somewhat cheaper, it is decisive for the project) because its measurements are not very accurate, it has a very long reading time and a much higher power consumption than others.

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

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

I haven't done any serious testing with the Si7021 because I'm too 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″ LilyGo T5 2.13″ board

There were a number of things that made me decide to go for this board, including several of the necessary components on a single board (and the most important).

Some of the things have to do with each of its components and others are related to the board itself "as a whole".

If I talk about the LilyGo TTGO T5 2.13″ LilyGo TTGO T5 2.13″ board If I talk to you about the "as a whole", I will tell you that it is a board that greatly simplifies the project with very acceptable components, putting it within the reach of any maker amateur.

Would the meter be better using other different components to the ones this board comes with?

Maybe a little (very little) but in my head it was clear that it was not going to be worth the effort (neither mine nor yours, which you are probably considering building). It would make assembly too complicated for most hobbyists, greatly increasing complexitythe number of cables and solderingthe possibility of errorsthe physical size busy and the fact that some of the best solutions are not available as a "best practice".ready-to-use board"but that it would have to be built starting from its components (surface mounted, SMD, in many cases).

I'm going to tell you about each of the parties which are already included on this board, as if they were independent (and they are indeed would not have changed much on what I would have chosen if this board did not exist).

Before we continue, a notice and warningThere are many very similar boards that they look the same, but they are not. Even different revisions of the same model of board may have different major differences that make the project not work (or does not work as well as it should).

If you are going to build the ultra-low-power CO2 meter I suggest, I recommend and I ask you to use this same LilyGo TTGO T5 2.13″ LilyGo TTGO T5 2.13″ board from the same link where I bought it. You might be tempted to buy it somewhere else because you are trying to save a euro or two (or dollars) and end up with something that doesn't work. In my opinion not worth the risk of buying it elsewhere..

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

If you still decide to use another board and you get it to apparently to work wellIf you do, let me know, but unless you have measuring instruments that amateurs don't normally have (such as instruments suitable for measuring very small currents with a very wide dynamic range, without voltage drop I am not going to recommend them for this project because there is a high possibility that something will go wrong and the result will not be as expected.

I hope that over time I will be able to add to this over time other boards to the project (personally tested by me) so that you can use them with reasonable guarantees of success. This is currently the only.

And I'm not just saying that. I have tried with many different combinations of the components present on this board and this is the only one that has worked properly. I will give you more details on why later.

Update: I have built two more prototypes with two more displays (one with a 2.3″ TTGO on an all-in-one board with ESP32 as shown above, and one with a single ESP32 and a stand-alone screen Waveshare 2.9″ with good preliminary results).

Microcontroller used in the meter

I thought long and hard about which microcontroller to use for this project, even though finally the decision was clear for several reasons: price, availability, user-friendliness, etc.

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

This microcontroller has everything we need: a very good price, a multitude of available pinsa acceptable consumption in its low-power modes, and best of all: ease of use and wide knowledge among amateurs.

Would it have been better to have a nRF52840 from the manufacturer Nordic Semiconductor?

From the point of view of consumption, 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
• Unbelievable more difficult to build the project for an amateur
• Its programming is much more complex
• There is less information available and fewer simple tutorials available
• We probably would have needed a custom printed circuit boardI try to run away from it as long as possible.
• We would have had to giving up wifi (and therefore to ESP-Nowwhich is an excellent solution for this type of application).

I may design other meters using other microcontrollers in the future (and I'm really looking forward to the nRF52840), but I'm not sure if I'll be able to do this in the future. for this project, and all things considered, the ESP32 is the right choice..

DEPG0213BN screen (display) used on the meter

The display is a very important part of the meter.

On the one hand, it greatly affects consumption and autonomy that can be obtained from the meter. On the other hand, its resolution, readability, graphic capability will have a significant impact on the usabilitythe public's perception of the meter (we all like our "gizmos" to be liked and pleasing to the eye) and their potential for expansion.

It was important to get an energy-efficient display, 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 e-Paper or electronic ink) after much testing 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 moment of changing what it displays.. You can even detach all the cables (including the power supply) and the display will continue to show what was on the screen at the time for months or years..

Another advantage of e-Ink displays is their very high display qualitymainly due to its huge contrast and viewing angle.

Lastly, another reason for choosing e-Ink technology is the large variety of such displays that exist. We have them in many sizes and even in colour. At this moment only one display model is supported, but in the future it will be possible to include support for other displays to meet users' needs or tastes.

In exchange for all these advantages, you also have some disadvantages. Mainly its slowness and the problem of ghosting.

e-Ink displays are relatively slowIt takes a long time to update the display (in the order of two seconds for the one I chose) and during this time the screen flickers several times. So you have to be very careful in the design of the software to optimise these times so that it is not annoying for the user.

Below, you can see the different update modes of the e-Ink screens and the flickering I'm referring to, to give you an idea.

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

Nothing prevents a "partial" update of the "whole" screen. This 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.

The ghosting effect, which can occur, means that old images can get stuck in the background. smoothly marked on the screen for a period of time (or permanently, in case of misuse).

To solve both of the above problems inherent in e-Ink displays, the display of choice supports a partial update. This allows us to update only one or several parts of the screen in a much faster way, with less power consumption and no flickering.

In order to avoid ghosting, it is necessary to continue to make a full screen refresh from time to time (with its two-second duration and flashes). I have designed the meter software to make this user-configurable.

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

For optimise this furtherI have implemented in the firmware what I call "display hysteresis". This allows the display update to be performed only if the following occur significant differences in the meter values with respect to those shown on the display. We can configure the CO2 meter so that, for example, the display is only updated if the change in CO2 concentration is greater than 50 ppm or the temperature by more than 0.5ºC. This is fully user-configurable and can greatly reduce consumption.

And if e-Ink displays have so many peculiarities, why haven't I used another display?

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

He could have used a "Memory Display" from Sharp. It consumes even less and is much faster. Unfortunately, it is much more difficult to use, because it no off-the-shelf hardware The display would have been easy to use for the hobbyist 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 display, but also a driver integrated circuit, various capacitors, resistors, transistors, power supply components, etc.).

Memory Displays are also more difficult to achieve, more expensive and with less variety to choose from.

Energy management

The energy management of such a project is neither trivial nor simple to implement.

It is necessary to choose voltage regulators with very low internal consumptionThe battery should have a low standby power consumption, allow for proper charging and monitoring of the battery, and be properly implemented with a "load sharing or power path (very important) that allows power supply from battery or external power and charging the battery while using external power (the meter does not stop working at any time)all at the same time and in the correct form and safe.

The board I have chosen takes care of all these points in one way quite efficient. There is certainly room for improvement, but at at a significantly higher cost and complexityIn my opinion, it is not worth it (for a project that can be easily set up by any non-specialist, let's not lose sight of the objectives and the target audience).

Another interesting detail of the chosen plaque is that it has already connected the battery input to an ADC pin with its corresponding resistive divider.. This is important, not only to know the battery voltage, but also to know how much power is left in the battery. prevent the meter from operating below a certain value. determined voltageThe CO2 sensor may not be able to measure the CO2 value, as below this 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 this by comparing them with the reference sensor (orange line), a Senseair S8.

Micro SD card reader - writer

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

I'll let you know...

Buttons and switch

The board has a switch to turn it off completely and two buttons on one side, one of them for resetting and the other for free disposal which, in the case of the meter, was used for start manual calibration.

It may seem silly, but it is very practical.

LEDs on the board

The board has three LEDS.

• One of them indicates that the board is switched on.
• Another indicates that the battery is charging
• I can't remember the third one now... I'll put it up (or was there only two?).

It makes no sense, for a meter with low power consumption and high autonomy, to dedicate precious energy to keep an LED consuming just to inform us that the meter is on, so that it is not necessary to have the meter on. I have deleted that LED (and thus its consumption) by unsoldering it from the board.

Tests and prototypes carried out

In order to achieve the CO2 meter with great autonomy, which I am talking about here, it has been necessary to many tests with different sensors, components, configurations, firmware, strategiesetc.

In each of these tests it was necessary to measure the consumption achievedusing specialised instrumentation for this type of measurement, because, even though theoretically you can calculate which one should be consumption, in practice, this can vary quite 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 them, but I will 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 "M" meter.normal" y the same firmware (ESP Easy).

The battery life I got was not bad for not having a specially optimised firmware (about 14 days, with a 2850mAh 18650 battery, sending data via wifi via MQTT every minute).

It soon became clear that the chosen processor was too short for what I wanted to do because of the few pins it left available for connecting the e-Ink display (which uses six pins) and a few other things.

The ESP Easy firmware was not ideal either. It had no support for the e-Ink displays I wanted to use.

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

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

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

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

• I did not manage to keep the screen power consumption low without having to do a full refresh every time the meter came out of deep sleep (the low power mode), having to do a full refresh, with its flashes, which lasted about 3 seconds. However, in this mode, its consumption in deep sleep was of practically 0 µA
• Apart from the relatively low measurement accuracy of the DHT22 temperature and humidity sensor, the DHT22 has a relatively high accuracy. is very slow at measuring which forces you to keep the meter in high power mode for a longer period of time while the sensor provides the measurement (or to make a workaround, complicating the code further).

If you want to use this screen for another project and you don't need a partial refresh when returning from deep sleep, the 2.9" Waveshare e-Ink display with GxGDEW029T5 can be a good choice. It is very good value for money and its display quality is very good.

Update: I seem to have partially solved the problems with this display and I have a working prototype with a Sensirion SCD41 sensor. There are still some ghosting problems to be solved.

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

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

This T7 V1.5 Mini32 board with ESP32″. is very interesting. It is the board with ESP32 with the lowest consumption of all the ones I have bought (although there are others on the market with lower consumption, but they tend to be more expensive and difficult to find).

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

Unfortunately, I can't locate the consumption data from the tests I did, but I will repeat the measurements to include them here. I seem to remember that their consumption in deep sleep was in the order of less than 100µAh. I will do more tests with it and document them properly because it is worth it.

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

Consumption and optimisation

They have been many the tests and measurements carried out during the development of this meter and in fact you have several articles with details on 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 consumption)

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

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

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

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

At the time of including this, the sensor was working. in continuous measurement modeThe system sends data on CO2, temperature, humidity and battery level every minute and shows it on the display.

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

Subsequently, in another test which 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.

Furthermore, the graph shows the CO2 measurements together with 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.

Below, I leave you different consumption profiles with different scenarios. I will be documenting and adding new profiles as further testing and progress is made.

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

Please note that the scale of the Y-axis is changing to fit the maximum size.

Consumption profile of a CO2 measurement, transmission and display update

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

As this is the first consumer profile I show you, I am going to explain how to interpret the graph, and the information you can get from it, in some detail.

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

During this minute the average consumption has been 7.39mA.h (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 am using, the autonomy would be 2850mA / 177.36mA = 16.06 days.

If we were to set the meter to measure every 3 minutes, the autonomy would be about one and a half months, and with measurements every five minutes we would be at about 80 days of autonomy..

Consumption profile of a CO2 measurement, transmission and display update

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

During those 3.2 seconds when he is awake, the consumption maximum is up to 374.40aAhThe average consumption at 100.27mAh.

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

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

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

The purpose of this functionality is to prevent the display is updated if the 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). In this way we can significantly reduce the time that the meter remains "awake" (and therefore their consumption).

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

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

Meter consumption profile in deep sleep

Finally, here is the graph of the 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 be able to reduce this average consumption in deep sleep soon, for which I need to solve two things:

• On the one hand, I would like Cubic's technical support to get back to me, as the sensor is consuming more in deep sleep than it should.
• On the other hand, to be able to reduce the consumption of the display and its controller, as it is consuming around 1mA, when its consumption in deep sleep should be almost 0mA (less than 100µAh in the worst case).

Consumption profile of the CO2 sensor Cubic CM1106SL-NS

There is one last important detail left to get a complete overview of the consumption of the meter and that is to know how much the CM1106SL-NS sensor consumes. This way we can subtract it from previous measurements to know, for example, how much deep sleep is consumed by the LilyGo board with the display or what part of the meter's consumption is consumed by the sensor. awake corresponds to the CO2 sensor.

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

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

Here you can see an enlargement of its consumption during the 2.5 seconds it is awake:

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

The communications co-processor or gateway

The wifi connection is fantastic, useful, fast, capable and, best of all, practically everyone has it and uses it.

The negative point is that it is a big energy guzzler (For the time being, it seems that with Wifi-6 and its 802.11ah specification, intended for IoT devices, this will largely be solved).

Unfortunately, until 802.11ah is available, if we were to use wifi right now, battery life would be disastrous, as it is for any device with a battery that uses wifi.

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

This protocol, developed by Espressif, enables significant power savings by using the existing wifi hardware in the ESP8266 and ESP32 chipsets. A data sending process that with wifi can take 10-12 seconds, with ESP-Now is reduced to a few milliseconds.

Of course, the routers and wifi access points we have at home do not support ESP-Now, which makes it necessary to include a "translator" or "bridge", which is 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 I have prepared on an ESP32. (I have to adapt it also to the ESP8266, so that whoever wants can use it), so the cost of this gateway is less than 5€, which is the cost of an ESP32 board.

This gateway receives the data from the ultra-low-energy CO2 meter via ESP-Now and forwards them via wifi via MQTT (already up and running), HTTP or whatever we want.

In addition, I have tried to programme this gateway in a very simple way.The new gateway is a simple, easy to use, and easy to use interface, so that any hobbyist with a little bit of programming idea can modify it to implement any other type of gateway.

Among the gateways that it is possible to include in the gateway, we would have:

• Direct recording of data in databases InfluxDB, MySQL, MariaDB and the like.
• Sending notifications and alerts by email, Telegram, Pushoveretc.
• Integration into any control system, home automation, building automation, PLCetc.
• Any other type of RF implementation, with the necessary RF hardware (LoRa, LoRaWan, BLE, BLE Mesh, Bluetooth Smartetc.).

Here you can see, next to one of the prototype meters, the gateway I am using at the moment (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-network > InfluxDB > Grafana

For those of you who use ESP Easy, good news: I hope to release a version of ESP Easy in the near future. gateway based on ESP Easy (when ESP-Now is available in ESP Easy, which, from what I've been told by the ESP Easy project manager, won't take 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 already mentioned, the meter is already working, and working quite well.

I have already recorded a extensive video tutorial where I explain step-by-step and with all kinds of details and advice the meter assembly (edit: so much has changed since I recorded the video that I'll probably have to re-record it).

There remains the process of video montageThe video was edited from about 20 hours of recordings to an edited video of a suitable length (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 are some things that are not finished and others that need to be improve and that I want them to be in the first version.

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

• I'm working on a problem with the power consumption of the Cubic CM1106SL-NS sensor, which makes it consume more than it should. It is important to solve this issue before publishing the project as it can affect the code as well as the tutorial, video, recommendations, etc. I am in talks with Cubic, its manufacturer, to try to solve it.
• There is still some pretty messy code that only I can understand. As this 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 needed, documenting it, applying best practices, etc.
• Ultra-low power sensors typically have two modes of operation. One is called "continuous measurement" and the other is called "single measurement". In the former, the microcontroller configures how often it wants the sensor to measure and it takes care of "waking up", measuring and providing a measurement, following the configured time. In the second, it is the microcontroller that takes care of everything: waking up the sensor, telling it to measure, if necessary telling it to save calibration data and turning the sensor off again.
  At the moment I have only implemented the continuous metering mode. Before I release it, I want to implement the single metering mode, which is supposed to have a lower power 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, I want it to look like a good meter and I want it to have a good design and usability.
• I would like to further reduce the power consumption of the e-Ink display in deep sleep.
• Before releasing it, I want to optimise the partial screen updates to reduce consumption and avoid flickering. It is not something determinant because it can be improved later by a simple update and the autonomy is now acceptable, but I would really like to improve it before releasing it.
• I continue to work on bi-directional communications between the meter and the gateway to increase reliability and flexibility.

Update 29/6/2021

• I spoke to Cubic about the problem with the consumption of the Cubic CM1106SL-NS sensor to try to solve it. It is now (partially) solved; it turns out that this sensor in continuous measurement mode does not allow its deactivation by means of the Enable pin. I have solved it by implementing the single measurement mode.
• The single measurement mode of the Cubic CM1106SL-NS is now implemented, which has resulted in good power savings. Using this method, it is the microcontroller that takes care of all the activity: waking up the sensor, telling it to measure, if necessary telling it to save calibration data and turning the sensor off again, which makes it possible to better optimise its consumption.