Diseño de un medidor de CO2 de ultra bajo consumo

Última modificación hace 3 años

¿Te gustaría tener un medidor de CO2 alimentado por pilas o baterías de un consumo ultra bajo y con una autonomía de varias semanas, o incluso meses? En este artículo te voy a hacer la presentación de este medidor de CO2 portátil, su desarrollo, las pruebas realizadas, sus detalles y el porqué de las cosas.

Tras cuatro meses de I+P+D (investigación, pruebas y desarrollo), el medidor de CO2 de ultra bajo consumo es ya una realidad. Está funcionando desde hace varias semanas y está funcionando muy bien.

El medidor todavía no está terminado para publicarlo. Quedan algunas funcionalidades y mejoras que quiero implementar y, sobre todo, es necesario realizar más optimizaciones de consumo para mejorar su autonomía.

En este momento estimo que el medidor de CO2 tiene una autonomía de tres meses con actualizaciones de concentración de CO2 cada cinco minutos.

Digo estimo porque no ha habido tiempo material para mantener el medidor funcionando permanentemente durante tanto tiempo y solo he hecho pequeñas pruebas de cinco días máximo. Mi estimación de un mes es por extrapolación (caída en la batería de 2850mAh de 0.71v tras funcionar durante 5 días midiendo, visualizando y reportando vía radio (ESP Now) cada minuto) más las medidas de consumo que podrás ver más adelante.

Empecemos con un pequeño video en el que te voy a enseñar el medidor:

A continuación, te voy a contar cual ha sido la motivación para diseñar y documentar la construcción de este medidor de CO2, por qué he tomado las decisiones que he tomado respecto a sus componentes y funcionalidades y cual espero que sea su futuro. También te voy a decir a quién va dirigido este medidor y lo que no es.

Motivación para crear un Medidor de CO2 casero de ultra bajo consumo

En los últimos meses, debido a la pandemia de Coronavirus, y a la posibilidad de reducir la posibilidad de transmisión de Covid, mejorando la ventilación y utilizando la medición de la concentración de CO2 como indicador de lo bien o mal que está, han sido muchas personas (cientos) las que han venido al blog y han creado su medidor siguiendo el tutorial que escribí.

Un medidor de CO2 casero con Wifi contra el coronavirus: El CO2 Easy

Claro, con tantas personas construyendo el medidor (cada una con sus propias motivaciones) las peticiones de nuevas funcionalidades han sido constantes, y he ido publicando ampliaciones y mejoras para cubrir la mayor parte de ellas.

Una de las opciones más demandadas, fue la de que el medidor pudiera funcionar con batería, y cree un tutorial, hace ya meses, para dotarle de esta funcionalidad utilizando componentes sencillos, baratos y fáciles de encontrar.

https://viejo.emariete.com/medidor-co2-con-bateria-bien-hecho/

Claro, no es lo mismo, aunque el resultado pueda ser muy bueno, como ha sido el caso, dotar de un sistema de batería recargable a un medidor de CO2 normal, que crear un medidor de CO2 diseñado desde el primer momento para tener gran autonomía.

Con el medidor anterior prácticamente había tocado techo, desde un punto de vista de equilibrio autonomía/sencillez de construcción para el aficionado medio/coste/portabilidad. Aunque todavía voy añadiendo pequeñas mejoras en ese sentido, merecía más la pena dedicar los esfuerzos a un nuevo diseño, partiendo de cero.

Me pareció que no tenía sentido mejorar su autonomía complicando su sistema de firmware (que es su mayor virtud, por lo extremadamente fácil que resulta para cualquiera que no tenga ni idea de todo esto).

Tampoco complicar su hardware, utilizando componentes de montaje superficial (SMD) que el aficionado medio no pudiera soldar o que necesitara placas de circuito impreso a medida.

Podría aumentar la autonomía con baterías más grandes, perjudicando su portabilidad (y quien quiera hacerlo puede, con el diseño existente).

Tampoco yéndonos a componentes tremendamente costosos que disparasen el coste del medidor.

Lo tenía claro, este medidor no viene para sustituir al anterior, que sigue siendo perfectamente válido y la primera opción para cualquiera, sino para complementarlo, dar una opción interesante y de calidad a aquellos que necesitan una buena autonomía sin compromisos.

Requisitos del medidor de CO2 casero de ultra bajo consumo

Una de las primeras cosas que me plantee, antes de empezar con el diseño, fue hacer un listado con los requisitos que debía tener el medidor. Lo iba a dividir en requisitos imprescindibles, deseables y prescindibles.

Este es el listado con el que acabé, quitando aquellas cosas que son demasiado técnicas o que, en algún momento, estuvieron en la lista de forma efímera y decidí eliminar rápidamente.

Requisitos imprescindibles

• Gran autonomía: Aunque esta puede depender mucho de la configuración que haga el usuario y del uso que haga del medidor, no me parece que podamos llamar gran autonomía a 24 o 48 horas (eso ya se consigue con el medidor de CO2 normal, aunque no es tan frecuente que los medidores comerciales con batería la alcancen, y en uno de mis tutoriales está documentado cómo hacerlo, incluyendo video detallado paso a paso).
• Pantalla de bajo consumo: Para un medidor de este tipo y con sus finalidades y usos previstos no se me ocurre otra opción. No podemos depender de un móvil o un ordenador para saber la concentración de CO2 ni podemos dificultar que se pueda ver con un simple vistazo (sin necesidad de apretar botones o despertarlo de algún modo). Tampoco es solución tener un simple led de colores «todo/medio/nada«. Eso sí, tener pantalla no debe estar reñido con la autonomía, por lo que hay que elegir bien la pantalla de bajo consumo.
• Sensor de alta calidad: Puede que haya opciones más económicas, pero, al igual que en el medidor de CO2 «normal» no iba a prescindir de tener mediciones de concentración de CO2 de alta calidad, en las que pudiéramos confiar. Lo cierto es que no hay muchos sensores de CO2 en el mercado que cumplan los niveles de calidad que quería para este medidor.
• Posibilidad de elegir diferentes sensores de CO2: No todo el mundo tiene la misma facilidad para conseguir diferentes sensores de CO2. Este proyecto ha sido diseñado para que desde el primer momento se pueda realizar con los dos sensores de ultra bajo consumo más recomendados en este momento, el Cubic’s CM1106SL-NS y el Senseair S11 Sunrise (el mismo sensor que utiliza el fabricante Aranet en sus Aranet4 y Aranet4 PRO). Además, es fácil adaptar otros sensores.
• Gestión de energía: El medidor debe contar con un buen sistema de gestión de energía que permita cosas como utilizarlo con batería recargable o alimentador/cargador USB externo a elección del usuario, control y visualización del nivel de batería, y que permita cargarlo y usarlo simultáneamente.
• Tamaño compacto: Es importante que el medidor sea realmente portátil, que podamos llevarlo fácilmente de un sitio a otro. Como verás, hay dos versiones del medidor con diferente grosor (dependiendo de la batería utilizada, y por tanto de su autonomía) pero las dos son muy compactas.

Requisitos deseables

• Comunicación vía radio: No todo el mundo lo necesita, pero, seamos serios, disponer de comunicación vía radio de los datos medidos abre un abanico de posibilidades que, en mi opinión, multiplica el valor del medidor x100. Eso sí, bien conseguida. La comunicación vía radio es devoradora de energía por naturaleza y no iba a permitir que el medidor de gran autonomía la perdiera a cambio de dotarle de comunicación vía radio.
• Guardado de datos local (data-logging): Si. No siempre tenemos la posibilidad de dotar de comunicación vía radio al medidor, sobre todo cuando está funcionando de forma portátil. En estos casos puede ser muy interesante que el medidor tenga forma de grabar las mediciones que realiza localmente, en su propia memoria o tarjeta SD, por ejemplo, para poderlas descargar y trabajar con ellas después.

Requisitos prescindibles

• Conexión wifi: Disponer de conexión wifi puede ser interesante, pero ¿a qué precio? Esta tecnología condiciona claramente el consumo y la autonomía del medidor.
• Envío de datos mediante MQTT: Íntimamente ligada a la anterior. Desde luego, mucha gente podrá vivir sin ello y el medidor seguiría siendo muy útil, pero abre un enorme universo de posibilidades.
• Envío de datos mediante HTTP: Otra de esas funcionalidades para integrar el medidor con todo tipo de servicios.

Quedaban otros requisitos que determinarían la facilidad de acceso al medidor como, por ejemplo, su coste, la facilidad para conseguir los componentes y su facilidad de construcción.

Funcionalidades del medidor de CO2 casero de ultra bajo consumo

Ya hemos visto los requisitos, de su implementación, inclusión o cumplimiento depende que se puedan implementar más o menos funcionalidades…

¿Cuáles de los requisitos que hemos visto antes he dejado fuera? Sencillo, ninguno. Todo está incluido, sin condiciones, un medidor full equipe. Esto abre la puerta a la implementación de una gran cantidad de funcionalidades. Muchas de ellas ya están disponibles, otras lo estarán en breve, y otras las he dejado para ser incorporadas por otros usuarios de forma colaborativa.

Por cierto, esta vez el firmware está escrito en el lenguaje de programación C++ (el dialecto de Arduino). Esto ha supuesto mucho más trabajo de programación, pero, a cambio, las posibilidades de ampliación son ilimitadas al no estar atados a las reglas y limitaciones de un «firmware framework» o empaquetado, como era el caso de ESP Easy en el medidor normal (donde, por otro lado, cumple su función estupendamente y ha sido una excelente elección).

Funcionalidades implementadas en el medidor de CO2

Estas son algunas de las funcionalidades ya implementadas en el medidor:

• Lo primero: medir concentración de CO2 y hacerlo bien
• Periodo de medición de la concentración de CO2 configurable
• Envío de datos vía radio super eficiente en consumo mediante protocolo ESP-NOW
• Posibilidad de envío de datos MQTT y HTTP mediante coprocesador de comunicaciones satélite o pasarela (gateway) sin afectar al consumo del medidor
• Posibilidad de envío de datos MQTT autónoma (con wifi, reduciendo, lógicamente, su autonomía).
• Calibración manual mediante pulsación o comando MQTT
• Comandos remotos por MQTT para cambio del periodo de medición
• Histéresis de visualización configurable para reducir el consumo
• Histéresis de envío de datos via radio configurable para reducir el consumo
• Modo de funcionamiento «single measurement» de los sensores que lo soporten
• Modo de funcionamiento «low power» de los sensores que lo soporten
• Modo de funcionamiento de «altas prestaciones» de los sensores que lo soporten
• Media móvil (rolling average) para suavización de datos configurable y desactivable

Funcionalidades en proceso o que pienso/quiero añadir

• Almacenamiento de datos en local (data logger)
• Posibilidad de envío de datos HTTP autónoma
• Pantallas con gráficos históricos de las mediciones
• Envío de datos vía LoRa y LoRaWAN
• Envío de datos vía Bluetooth Low Energy (BLE)
• Completo interface WEB para configuración, visualización de datos en tiempo real, históricos, etc

Diseño y componentes hardware

He tratado de diseñar el medidor con componentes de relativamente bajo coste y relativamente fáciles de conseguir, pero sin compromisos de cara a conseguir un buen resultado, con una buena relación calidad-precio, aunque, lógicamente y debido a los componentes que hay que utilizar y su precio, el coste de este medidor será mayor que el medidor «normal», destinado a todo el mundo.

Vamos a ir viendo los componentes uno por uno, con las observaciones que sean necesarias.

Sensor de CO2 de ultra bajo consumo

La elección de este componente es crítica por dos motivos:

• De él depende la calidad de las medidas de concentración de CO2
• De él depende, en gran parte, el consumo y la autonomía del medidor de CO2

También puede depender del sensor tener un buen resultado asegurado al primer intento o no tenerlo.

No me voy a extender mucho sobre los sensores porque voy a escribir un artículo específico comparando en profundidad los principales sensores de bajo consumo que podemos encontrar en el mercado.

Solo te diré que para este diseño he utilizado los que creo que tienen la mejor relación calidad-precio del mercado. Esto es importante ya que en él se va a ir una parte importante del coste del medidor.

Además, los sensores que propongo han sido probados por mí personalmente largo y tendido y los que me conocéis sabéis que cuando pruebo sensores, lo hago a conciencia, dedicando muchos días (a veces meses) al análisis de cada sensor.

Desde luego, no todos son iguales, cada sensor de CO2 elegido tienes sus ventajas y sus inconvenientes, sus puntos fuertes y sus puntos débiles.

Los sensores de CO2 soportados en este momento son los siguientes:

• Sensor NDIR Senseair Sunrise S11 (terminando la implementación)
• Sensor NDIR Cubic CM1106SL-NS
• Sensor fotoacústico Sensirion SCD41

Iré añadiendo más sensores según los tenga disponibles (¿eres fabricante o distribuidor y quieres que tu sensor esté soportado? contacta conmigo, si el sensor es bueno y pasa las pruebas, lo implementaré con mucho gusto).

Sensor de datos ambientales

Para recoger los datos ambientales se soportan varios sensores (con la posibilidad de incluir otros sensores fácilmente).

Aunque durante las pruebas de componentes utilicé el sensor DHT22, finalmente he decidido no utilizarlo en el prototipo. Este sensor no me parece recomendable para este proyecto (salvo que, al ser algo más barato, sea determinante para poder hacer el proyecto) porque sus medidas no son demasiado precisas, tiene un tiempo de lectura muy largo y un consumo bastante más alto que otros.

Finalmente, en el prototipo, he utilizado el sensor de temperatura y humedad Si7021.

El sensor Si7021 consume muy poco y es bastante rápido, pero, al menos la unidad que yo tengo mide la temperatura un par de grados por encima de la real.

No he hecho ninguna prueba seria con el Si7021 porque estoy muy ocupado con otras cosas (ya te imaginas) pero las haré.

Sobre el papel sería un sensor perfecto para este proyecto.

Placa LilyGo T5 2.13″

Ha habido varias cosas que me han hecho decidirme por esta placa, que incluye varios de los componentes necesarios en una sola placa (y de los más importantes).

Algunas de las cosas tienen que ver con cada uno de sus componentes y otras son referentes a la placa en sí misma «como un todo«.

Si te hablo de la [TTGO-DEPG0213BN] «como un todo», te diré que es una placa que simplifica mucho el proyecto con unos componentes muy aceptables, poniéndolo al alcance de cualquier maker aficionado.

¿Sería mejor el medidor utilizando otros componentes diferentes a los que trae esta placa?

Puede que un poco (muy poco) pero en mi cabeza tenía claro que no iba a merecer la pena el esfuerzo (ni el mío ni el tuyo, que probablemente te estás planteando construirlo). Iba a complicar mucho el montaje para la mayoría de los aficionados, incrementando mucho la complejidad, el número de cables y soldaduras, la posibilidad de errores, el tamaño físico ocupado y el hecho de que algunas de las mejores soluciones no están disponibles como «placa lista para usar» sino que habría que construirla partiendo de sus componentes (de montaje superficial, SMD, en muchos casos).

Te voy a hablar de cada una de las partes que vienen ya incluidas en esta placa, como si fueran independientes (y lo cierto es que no hubiera variado mucho en lo que habría elegido si esta placa no existiera).

Antes de continuar, un aviso y advertencia: hay muchas placas muy similares que parecen iguales, pero no lo son. Incluso diferentes revisiones del mismo modelo de placa pueden tener diferencias importantes que hagan que el proyecto no funcione (o no funcione tan bien como debería).

Si vas a construir el medidor de CO2 de ultra bajo consumo te sugiero, te recomiendo y te pido que utilices esta misma [TTGO-DEPG0213BN], del mismo enlace donde yo la he comprado. Lo mismo por intentar ahorrar un euro o dos (o dólares) te tienta comprarla en otro sitio y acabas con algo que no funciona. En mi opinión no merece la pena el riesgo de comprarla en otro sitio.

Este es el enlace donde he comprado la [TTGO-DEPG0213BN]. De todas formas, si solo la vas a utilizar para este proyecto, te sugiero que no la compres todavía porque me quedan pruebas por hacer y podría haber cambios. Si la quieres para otras cosas, perfecto, adelante, es una buena placa.

Si aun así decides utilizar otra placa y consigues que aparentemente funcione bien, dímelo para saberlo, pero, a no ser que tengas instrumentos de medida de los que normalmente los aficionados no suelen tener (como instrumental adecuado para medir corrientes muy pequeñas con un muy amplio rango dinámico, sin caída de voltaje por inserción -burden voltage- y osciloscopio) no las voy a recomendar para este proyecto porque hay una alta posibilidad de que algo no vaya bien y que el resultado no sea el esperado.

Espero que con el paso del tiempo pueda ir añadiendo otras placas al proyecto (probadas personalmente por mi) para que podáis utilizarlas con garantías de éxito razonables. Hoy por hoy esta es la única.

Y no lo digo por decir. He probado con muchas combinaciones diferentes de los componentes presentes en esta placa y esta es la única que ha funcionado correctamente. Más adelante os iré dando más detalles de por qué.

Actualizo: He construido otros dos prototipos con dos pantallas más (una de TTGO de 2.3″ en una placa «todo en uno» con ESP32 como la enseñada anteriormente, y otro con un ESP32 suelto y una pantalla independiente Waveshare de 2.9″ con buenos resultados preliminares).

Microcontrolador utilizado en el medidor

Le di muchas vueltas a qué microcontrolador utilizar para este proyecto, aunque finalmente la decisión estaba clara por varios motivos: precio, disponibilidad, facilidad para el usuario, etc.

El microcontrolador que iba a utilizar sería el ESP32 del fabricante Espressif Systems.

Este microcontrolador tiene todo lo que necesitamos: un muy buen precio, multitud de pines disponibles, un consumo aceptable en sus modos de bajo consumo, y lo mejor de todo: facilidad de uso y amplio conocimiento por parte de los aficionados.

¿Hubiera sido mejor un nRF52840 del fabricante Nordic Semiconductor?

Desde el punto de vista de consumo seguro que sí, aunque no tanto como pudiera parecer a primera vista, porque como veremos después el microcontrolador no es lo que más consume, pero había poderosos motivos para no hacerlo con él:

• Hubiera sido más caro
• Increíblemente más difícil de construir el proyecto para un aficionado
• Su programación es mucho más compleja
• Hay menos información disponible y menos tutoriales sencillos disponibles
• Probablemente hubiéramos necesitado una placa de circuito impreso a medida, de lo que intento huir mientras sea posible
• Hubiéramos tenido que renunciar al wifi (y por tanto a ESP-Now, que es una excelente solución para este tipo de aplicación).

Es posible que en el futuro diseñe otros medidores que utilicen otros microcontroladores (y la verdad es que le tengo muchas ganas al nRF52840), pero para este proyecto, y poniéndolo todo en la balanza, el ESP32 es la decisión correcta.

Pantalla DEPG0213BN (display) utilizada en el medidor

La pantalla es una parte muy importante del medidor.

Por una parte, afecta muchísimo al consumo y a la autonomía que se puede obtener del medidor. Por otro lado, su resolución, legibilidad, capacidad gráfica van a tener un impacto importante en la usabilidad, la percepción del medidor por el público (a todos nos gusta que nuestros «chismes» gusten y sean agradables a la vista) y sus posibilidades de ampliación.

Era importante conseguir una pantalla de bajo consumo, buena calidad y visibilidad y facilidad de compra y montaje para el usuario medio.

Me decidí por una pantalla e-Ink (también llamada e-Paper o tinta electrónica) después de muchas pruebas y análisis.

Estas pantallas tienen la gran ventaja de que su consumo es prácticamente nulo cuando no se está actualizando. Dicho de otra forma, solo consume en el momento de cambiar lo que muestra. Puedes incluso soltar todos los cables (incluidos los de su alimentación) y la pantalla seguirá mostrando lo que tenía en ese momento durante meses o años.

Otra ventaja de las pantallas e-Ink es su altísima calidad de visualización, debido principalmente a su enorme contraste y ángulo de visión.

Por último, otro de los motivos para escoger la tecnología e-Ink es la gran variedad de pantallas de este tipo que existen. Las tenemos de muchos tamaños e incluso en color. En este momento solamente está soportado un modelo de pantalla, pero en el futuro será posible ir incluyendo soporte para otras pantallas para cubrir las necesidades o gustos de los usuarios.

A cambio de todas estas ventajas, también tiene algunos inconvenientes. Principalmente su lentitud y el problema del «ghosting» (imágenes fantasma).

Las e-Ink son pantallas relativamente lentas, tardan mucho en actualizar lo que muestra en pantalla (del orden de dos segundos en la que he escogido) y durante este tiempo la pantalla parpadea varias veces. Por lo que hay que ser muy cuidadoso en el diseño del software para optimizar estos tiempos y que no resulte molesto para el usuario.

A continuación, puedes ver los diferentes modos de actualización de las pantallas e-Ink y los parpadeos a los que me refiero, para que te hagas a la idea.

Verás que se producen actualizaciones parciales (cuando la pantalla parpadea cambiando entre blanco y negro) y actualizaciones parciales, que no provocan parpadeo.

Nada evita hacer una actualización «parcial» de la «totalidad» de la pantalla. Es una forma de evitar el parpadeo, aunque esto tiene un límite y cada x actualizaciones parciales es necesario hacer una actualización total o aparecerá el temido «ghosting».

El efecto «Ghosting», que puede aparecer, provoca que las imágenes antiguas puedan llegar a quedarse suavemente marcadas en la pantalla durante un tiempo (o definitivamente, en caso de mal uso).

Para solucionar los dos problemas anteriores, inherentes a las pantallas e-Ink, la pantalla elegida soporta un modo de actualización parcial. Esto nos permite actualizar solo una o varias partes de la pantalla de una forma mucho más rápida, con menor consumo de corriente y sin parpadeo.

Para evitar el ghosting hay que seguir haciendo una actualización completa de la pantalla de vez en cuando (con sus dos segundos de duración y sus parpadeos). He diseñado el software del medidor para que esto sea configurable por el usuario.

Por defecto la pantalla hace una actualización completa cada 30 actualizaciones parciales. Si el periodo de medición es de, por ejemplo, 5 minutos, solamente hará una actualización completa cada dos horas y media.

Para optimizar esto aún más, he implementado en el firmware lo que llamo «display histéresis«. Esto permite que solamente se realice la actualización de la pantalla si se producen diferencias significativas en los valores medidor respecto a las mostradas en la pantalla. Podemos configurar el medidor de CO2 para que, por ejemplo, solamente se actualice la pantalla si el cambio en la concentración de CO2 es superior a 50 ppm o la temperatura en más de 0.5ºC. Esto es completamente configurable por el usuario y puede reducir mucho el consumo.

¿Y si las pantallas e-Ink tienen tantas peculiaridades, por qué no he utilizado otra pantalla?

La respuesta sencilla es: porque pienso que la e-Ink es la mejor para nuestros objetivos si lo tenemos todo en cuenta (precio, consumo, calidad, facilidad de uso, facilidad para conseguirlas, etc).

Podría haber utilizado una «Memory Display» del fabricante Sharp. Consume aún menos y es mucho más rápida. Desgraciadamente, es mucho más difícil de utilizar, porque no hay hardware ya preparado de fácil uso para el aficionado y a precio asequible, y hubiera sido necesario construir una placa de circuito impreso a medida con bastantes componentes (no solo la pantalla, sino un circuito integrado controlador, varios condensadores, resistencias, transistores, componentes para su alimentación, etc.).

También las «Memory Display» son más difíciles de conseguir, más caras y con menos variedad para escoger.

Gestión de energía

La gestión de energía de un proyecto como este no es algo trivial ni sencillo de implementar.

Es necesario escoger reguladores de voltage con muy bajo consumo interno, que consuman muy poco en reposo, que permitan la carga correcta y supervisión de la batería, además deben implementar correctamente un sistema de «load sharing» o «power path» (muy importante) que permita la alimentación desde batería o alimentación externa y cargar la batería mientras se utiliza alimentación externa (el medidor no deja de funcionar en ningún momento), todo de forma simultánea y de la forma correcta y segura.

La placa que he escogido se encarga de todos estos puntos de una forma bastante eficiente. Sin duda, es mejorable, pero a un coste y con una complejidad bastante mayores, y en mi opinión no merece la pena (para un proyecto que pueda montar cualquier persona, no especialista, fácilmente, no perdamos de vista los objetivos y el público al que va dirigido).

Otro detalle interesante de la placa elegida es que tiene ya conectada la entrada de batería a un pin ADC con su pertinente divisor resistivo. Esto es importante, no solo de cara a conocer el voltage de la batería, sino a evitar que el medidor funcione por debajo de un determinado voltaje, ya que por debajo de ese voltaje los datos obtenidos por el sensor de CO2 pueden ser incorrectos.

En el siguiente gráfico puedes ver como cuando el voltaje (línea azul) baja por debajo de un punto (2.78V en este caso) las medidas proporcionadas por el Cubic CM1106SL-NS (línea verde) dejan de ser correctas. En este caso lo podemos ver al compararlas con el sensor de referencia (línea naranja), un Senseair S8.

Lector – grabador de tarjetas Micro SD

Una opción interesante que todavía no he probado, pero lo haré y contaré porque una de las cosas que quiero implementar en el medidor es la grabación de medidas en Micro SD (data logger).

Ya os contaré…

Botones e interruptor

La placa cuenta con un interruptor que permite apagarla por completo y dos botones en uno de sus laterales, uno de ellos para hacer reset y otro de libre disposición que, en el caso del medidor, los utilizó para iniciar la calibración manual.

Puede parecer una tontería, pero es algo muy práctico.

LEDs de la placa

La placa cuenta con tres LEDS.

• Uno de ellos indica que la placa está encendida
• Otro indica que la batería se está cargando
• Del tercero no me acuerdo ahora… ya lo pondré (¿o solo había dos?)

No tiene sentido, para un medidor de bajo consumo y gran autonomía dedicar una energía preciosa en mantener un LED consumiendo solo para informarnos de que el medidor está encendido, de manera que he eliminado ese LED (y con ello su consumo) desoldándolo de la placa.

Las pruebas y los prototipos realizados

Para llegar a conseguir el medidor de CO2 con gran autonomía, del que aquí te hablo, han sido necesarias muchas pruebas con diferentes sensores, componentes, configuraciones, firmware, estrategias, etc.

En cada una de estas pruebas era necesario medir el consumo conseguido, utilizando instrumental especializado para este tipo de mediciones, porque, aunque teóricamente puedes calcular cuál debería ser el consumo, en la práctica, esto puede variar bastante (y te aseguro que lo hace).

No voy a entrar el detalle de cada una de las pruebas y prototipos, porque sería un trabajo enorme describirlo, pero si te voy a mostrar a continuación algunos hitos o momentos del desarrollo.

Prototipo con ESP8266, sensor Senseair Sunrise S11 y firmware ESP Easy

Este prototipo de medidor utilizaba el mismo microcontrolador que el medidor «normal» y el mismo firmware (ESP Easy).

La autonomía que conseguí no estaba nada mal para no tener un firmware especialmente optimizado (unos 14 días, con una batería 18650 de 2850mAh, enviando datos vía wifi mediante MQTT cada minuto).

Pronto quedó claro que el procesador elegido se quedaba muy corto para lo que quería hacer debido a los pocos pines que dejaba disponibles para conectar la pantalla e-Ink (que usa seis pines) y alguna cosa más.

Tampoco el firmware ESP Easy era el ideal. No tenía soporte para las pantallas e-Ink que quería utilizar.

Este medidor, además, obligaba a comunicar mediante wifi (que es muy lento mientras hace la conexión a la red) en lugar de ESP-NOW. Para que te hagas a la idea, necesitaba unos 11 segundos despierto (consumiendo al máximo) para conectarse al wifi, leer la concentración de CO2 y enviarla mediante MQTT, mientras que el que te estoy describiendo en este artículo tarda aproximadamente un segundo en hacerlo (y seguro tardará menos cuando esté más optimizado).

Prototipo con placa ESP32‑DevKitC y pantalla e-Ink de 2.9″ de Waveshare

Aquí puedes ver un prototipo utilizando una placa ESP32‑DevKitC como microcontrolador, una [Waveshare-GxGDEW029T5], un sensor Cubic CM1106SL-NS para CO2 y un sensor de temperatura y humedad DHT22.

Este prototipo tenía los siguientes problemas que había que solucionar y/o mejorar:

• No conseguí mantener un bajo consumo de la pantalla sin tener que hacer una actualización completa cada vez que el medidor salía de deep sleep (el modo de bajo consumo) teniendo que hacer una actualización completa, con sus parpadeos, que duraba unos 3 segundos aproximadamente. Eso sí, de este modo su consumo en deep sleep era de prácticamente 0 µA
• Aparte de la relativa baja precisión de las medidas del sensor de temperatura y humedad DHT22, éste es muy lento midiendo lo que obliga a tener que mantener el medidor en el modo de alto consumo durante más tiempo, mientras el sensor proporciona la medida (o hacer un apaño, complicando más el código).

Si quieres usar esta pantalla para otro proyecto y no necesitas refresco parcial al volver de deep sleep, la [Waveshare-GxGDEW029T5] puede ser una buena opción. Está muy bien de precio y su calidad de visualización es muy buena.

Actualizo: Parece que he conseguido solucionar parcialmente los problemas con esta pantalla y tengo un prototipo funcionando con un sensor Sensirion SCD41. Todavía quedan algunos problemas de ghosting por solucionar.

Prototipo con placa ESP32 y pantalla e-Ink de 2.9″ de Waveshare

Aquí tienes otro un prototipo, en este caso utilizando una [TTGO-DEPG0213BN] con ESP32, con la misma [Waveshare-GxGDEW029T5], un sensor Cubic CM1106 para CO2 y un sensor de temperatura y humedad DHT22.

Esta [AliExpress-ESP32-T7-Mini] es muy interesante. Es la placa con ESP32 con el consumo más bajo de todas las que he comprado (aunque existen otras en el mercado con menor consumo, pero suelen ser más caras y difíciles de encontrar).

Además, incluye un buen sistema gestor de energía que le permite ser alimentada por USB, externamente a 5V, a 3.3V y mediante batería recargable Li-Ion o Li-Po. Tiene en la misma placa cargador y capacidad «load sharing» (o «power path», como quieras) para poderla utilizar y cargar a la vez.

Desgraciadamente no localizo los datos de consumo de las pruebas que hice, pero repetiré las mediciones para incluirlas aquí. Creo recordar que su consumo en deep sleep era del orden de menos de 100µAh. Haré más pruebas con ella y las documentaré adecuadamente porque merece la pena.

Es muy probable que en futuras versiones del medidor con otras pantallas e-Ink (cuando encuentre otras que funcionen bien) utilice esta placa.

Consumo y optimización

Han sido muchas las pruebas y mediciones realizadas durante el desarrollo de este medidor y de hecho tienes varios artículos con detalles sobre algunas de las pruebas realizadas, medidas, etc.

Si quieres conocer los detalles, puedes verlos en estos cuatro posts:

ESP Easy y el modo deep sleep (ESP8266 bajo consumo)

Experimentos con ESP Easy (ESP8266) y bajo consumo – v1.0

Experimentos con ESP Easy (ESP8266) y bajo consumo – v2.0

Experimentos con ESP Easy (ESP8266) y bajo consumo – v3.0

Cuando publique el proyecto aprovecharé para publicar las medidas de consumo del proyecto terminado. De momento te dejo algunas medidas provisionales.

En el momento de incluir esto, el sensor estaba funcionando en modo de medición continua, lo que supone más consumo, enviando datos de CO2, temperatura, humedad y nivel de batería cada minuto y mostrándolo en el display.

Como ves, en esta prueba, el medidor ha estado funcionando durante sesenta horas con una caída en la batería de 2850mAh de 0.22v, midiendo, visualizando y reportando cada minuto.

Posteriormente, en otra prueba que puedes ver debajo, el medidor ha estado funcionando durante cinco días con una caída en la batería de 2850mAh de 0.71v, midiendo, visualizando y reportando vía radio (con ESP-Now) cada minuto.

Además la gráfica muestra las medidas de CO2 junto a mi sensor de referencia Senseair S8 y, como puedes ver, las medidas difieren muy poco entre los dos sensores.

El medidor puede tener diferentes perfiles de consumo, dependiendo del sensor utilizado, el modo de medición de CO2 y los diferentes parámetros de configuración.

A continuación, te dejo diferentes perfiles de consumo con distintos escenarios. Iré documentando y añadiendo nuevos perfiles a medida que haga nuevas pruebas y avances.

Todas las medidas y gráficos que aparecen a continuación han hechas con el sensor Cubic CM1106SL-NS. Más adelante añadiré mediciones con otros sensores de ultra bajo consumo.

Ten en cuenta que la escala del eje Y va cambiando para adaptarse a la máxima medida.

Perfil de consumo de una medida de CO2, transmisión y actualización del display

Aquí tienes el perfil de consumo del medidor durante un periodo de 1 minuto.

Al ser el primer perfil de consumo que te muestro, te voy a explicar cómo interpretar el gráfico, y la información que puedes obtener de él, con bastante detalle.

En el este grafico puedes ver que, durante ese minuto, el medidor está «dormido» la mayor parte del tiempo (en modo de bajo consumo o «deep sleep»), se despierta brevemente y vuelve al estado de deep sleep hasta el siguiente ciclo.

Durante este minuto el consumo medio ha sido de 7.39mAh (este es el consumo medio total del medidor).

En 24 horas el consumo sería de 7.39mA x 24h = 177.36mA lo que supone que con una batería de 2850mAh, como la que estoy utilizando, la autonomía sería de 2850mA / 177.36mA = 16,06 días.

Si configuráramos el medidor para que midiera cada 3 minutos, la autonomía sería de cerca de mes y medio y con medidas cada cinco minutos estaríamos en unos 80 días de autonomía.

Perfil de consumo de una medida de CO2, transmisión y actualización del display

Durante el minuto que te estoy mostrando, el medidor solamente está despierto durante 3.2 segundos.

Durante esos 3.2 segundos en que está despierto, el consumo máximo llega a ser de 374.40aAh, quedando el consumo medio en 100.27mAh.

En este gráfico puedes ver con más detalle lo que sucede a nivel de consumo durante esos 3.2 segundos (vamos, que es un zoom sobre la parte sombreada del gráfico anterior), por si tienes curiosidad en conocer las variaciones de consumo al detalle:

Perfil de consumo de una medida de CO2, transmisión (sin actualización del display)

En este tutorial te ha hablado de la funcionalidad de «display histéresis» que he implementado para reducir el consumo.

Esta funcionalidad lo que persigue es que no se actualice la pantalla si los cambios en las medidas no superan un umbral definido por el usuario (normalmente no necesitamos saber que la concentración de CO2 ha pasado de 540 ppm a 545 ppm, nos da igual). De esta forma podemos reducir bastante el tiempo que el medidor permanece «despierto« (y por tanto su consumo).

En el siguiente grafico puedes ver como cuando no necesitamos actualizar la pantalla conseguimos reducir ese tiempo de los 3.2 segundos del gráfico anterior hasta los 1.76 segundos, casi la mitad de tiempo (y consumo).

Como en el caso anterior, te pongo un gráfico con esa zona ampliada para que puedas compararla:

Perfil de consumo del medidor en deep sleep

Para finalizar te dejo el gráfico del consumo en deep sleep.

En él puedes ver como el medidor permanece dormido entre medidas durante 59.33 segundos con un consumo medio de 2.15mA.

Este consumo medio en deep sleep espero poderlo reducir en breve, para lo que necesito solucionar dos cosas:

• Por un lado, que el soporte técnico de Cubic me responda, ya que el sensor está consumiendo en deep sleep más de lo que debería.
• Por otro poder reducir el consumo del display y su controlador, ya que está consumiendo del orden de 1mA, cuando su consumo en deep sleep debería ser de casi 0mA (menos de 100µAh en el peor caso).

Perfil de consumo del sensor de CO2 Cubic CM1106SL-NS

Nos queda un último detalle importante, para tener una visión completa del consumo del medidor y es saber cuánto consume el sensor CM1106SL-NS. De esta forma podremos restarlo de medidas anteriores para saber, por ejemplo, cuanto consumen en deep sleep la placa LilyGo con la pantalla o qué parte del consumo del medidor despierto corresponde al sensor de CO2.

En el siguiente gráfico puedes ver 1 minuto de la vida del sensor.

Como ves, durante ese minuto el consumo medio del sensor es de 139µA. Esto es algo más del doble de lo que Cubic, su fabricante, indica en su documentación técnica.

Aquí puedes ver una ampliación de su consumo durante los 2.5 segundos en que está despierto:

Aunque no he puesto el gráfico, te diré que el consumo del sensor durante el tiempo en el que está dormido su consumo es de menos de 5µA.

El coprocesador de comunicaciones o gateway

La conexión wifi es fantástica, útil, rápida, capaz y, lo mejor, es que prácticamente todo el mundo la tiene y la usa.

El punto negativo es que es una gran devoradora de energía (de momento, parece que con Wifi-6 y su especificación 802.11ah, pensada para dispositivos IoT, esto se solucionará en gran medida).

Desgraciadamente, y hasta que 802.11ah esté disponible, si utilizáramos wifi ahora mismo, la autonomía sería desastrosa, como le ocurre a cualquier dispositivo con batería que utilice wifi.

Para solventar este problema, he utilizado el protocolo ESP-Now.

Este protocolo, desarrollado por Espressif, permite un ahorro de energía muy importante, utilizando el hardware para wifi que ya tenemos en los chips ESP8266 y ESP32. Un proceso de envío de datos que con wifi puede durar unos 10-12 segundos, con ESP-Now queda reducido a unos pocos milisegundos.

Claro, los routers y puntos de acceso wifi que tenemos en casa no soportan ESP-Now, lo que hace necesario incluir un «traductor» o «puente», algo que una ESP-Easy y Wifi.

La bueno es que eso es muy sencillo y barato, ya que solamente tenemos que cargar el firmware que he preparado en un ESP32 (tengo pendiente adaptarlo también al ESP8266, para que quién quiera pueda utilizarlo), de manera que el coste de este gateway es de menos de 5€, que es lo que cuesta una placa ESP32.

Este gateway, recibe los datos del medidor de CO2 de ultra bajo consumo mediante ESP-Now y los reenvía a través de wifi mediante MQTT (ya disponible y funcionando), HTTP o lo que queramos.

Además, he tratado de programar este gateway de una forma muy sencilla, para que cualquier aficionado con un poquito de idea de programación pueda modificarlo para implementar cualquier otro tipo de pasarela.

Entre las pasarelas que es posible incluir en el gateway, tendríamos:

• Grabación directa de datos en BBDD InfluxDB, MySQL, MariaDB y similares.
• Envío de notificaciones y alertas mediante email, Telegram, Pushover, etc.
• Integración en cualquier sistema de control, domótica, inmótica, PLC, etc.
• Cualquier otro tipo de implementación RF, con el hardware RF necesario (LoRa, LoRaWan, BLE, BLE Mesh, Bluetooth Smart, etc.).

Aquí puedes ver, junto a uno de los prototipos de medidor, el gateway que estoy utilizando en estos momentos (una simple [AliExpress-ESP32-T7-Mini])

Y aquí un panel que se actualiza en tiempo casi real con los datos generados por el sensor después de hacer este viaje Esp-Now > Wifi/MQTT > Node-red > InfluxDB > Grafana

Para los que utilizáis ESP Easy, una buena noticia: Espero sacar una versión del gateway basada en ESP Easy (cuando esté disponible ESP-Now en ESP Easy, para lo que, por lo que me ha dicho el responsable del proyecto ESP Easy, no será necesario esperar mucho), de manera que incluir cualquier cosa soportada por ESP Easy en el gateway será tan sencillo como ya sabéis todos…

Estado y disponibilidad del nuevo medidor

Como os he adelantado, el medidor ya está funcionando, y funcionando bastante bien.

Tengo ya grabado un extenso video tutorial donde explico paso a paso y con todo tipo de detalles y consejos el montaje del medidor (edito: han cambiado tantas cosas desde que grabé el video que seguramente lo tenga que grabar de nuevo).

Queda el proceso de montaje del video, pasando de unas 20 horas de grabaciones a un video editado de una longitud adecuada (digamos treinta minutos) sin dejar nada importante fuera y con los diagramas necesarios para su fácil comprensión.

¿Qué a qué estoy esperando entonces para publicarlo?

Bueno, hay algunas cosas que no están terminadas y otras que hay que mejorar y que quiero que estén en la primera versión.

En estos cuatro meses de I+P+D han sido muchos los obstáculos que he ido encontrando, pero parece que poco a poco los he ido superando. Ahora quedan los siguientes:

• Estoy trabajando en un problema con el consumo del sensor Cubic CM1106SL-NS, que hace que consume más de lo que debiera. Este punto es importante solucionarlo antes de publicar el proyecto ya que puede afectar tanto al código como a tutorial, video, recomendaciones, etc. Estoy en conversaciones con Cubic, su fabricante, para tratar de solucionarlo.
• Todavía existe código bastante lioso, que solo yo puedo entender. Al tratarse de un proyecto open source y colaborativo, en el que espero que participe más gente, estoy en el proceso de limpiar el código, quitar código de depuración que he incluido durante el desarrollo y que ya no es necesario, documentarlo, aplicar mejores prácticas, etc.
• Los sensores de ultra bajo consumo suelen tener dos modos de funcionamiento. Uno llamado de «medición continua» y otro llamado «de medición única». En el primero, el microcontrolador configura cada cuanto tiempo quiere que el sensor mida y él se ocupa de «despertarse» medir y proporcionar una medida, siguiendo ese tiempo configurado. En el segundo es el microcontrolador el que se ocupa de todo: despertar el sensor, decirle que mida, si es necesario decirle que guarde datos de calibración y volver a apagar el sensor.
  De momento solo he implementado el modo de medición continua. Quiero, antes de sacarlo, implementar el modo de medición única, que se supone que tiene un menor consumo.
• Quiero mejorar el aspecto estético de las pantallas del medidor. Ahora mismo son plenamente funcionales, pero son solo pantallas de prueba sin ningún diseño. No quiero que sea solo un buen medidor, sino que lo parezca y que tenga un buen diseño y usabilidad.
• Me gustaría reducir aún más el consumo de la pantalla e-Ink en deep sleep.
• Quiero, antes de liberarlo, optimizar las actualizaciones parciales de la pantalla para reducir el consumo y evitar parpadeos. No es algo determinando porque se puede mejorar después mediante una simple actualización y la autonomía ahora es aceptable, pero me gustaría mucho poderla mejorar antes de sacarlo.
• Sigo trabajando en las comunicaciones bidireccionales entre el medidor y la pasarela para aumentar su fiabilidad y flexibilidad.

Actualización 29/6/2021

• Hablé con Cubic respecto al problema con el consumo del sensor Cubic CM1106SL-NS para tratar de solucionarlo. Ya está resuelto (parcialmente).; resulta que este sensor en modo de medida continua no permite su desactivación mediante el pin Enable. Lo he solucionado implementando el modo de medida única.
• Ya está implementado el modo de medida única del Cubic CM1106SL-NS, con lo que se ha conseguido un buen ahorro de energía. Utilizando este método, es el microcontrolador el que se ocupa de toda la actividad: despertar el sensor, decirle que mida, si es necesario decirle que guarde datos de calibración y volver a apagar el sensor, lo que hace que se pueda optimizar mejor su consumo.