Contenidos
Conseguir un bajo consumo de nuestro ESP8266 para utilizarlo con batería es el objetivo que queremos conseguir, y en este artículo vamos a continuar los experimentos.
Vamos a tratar de optimizar el tiempo que nuestro medidor está «despierto» y para eso necesitamos saber, lo primero, de qué tiempos de funcionamiento estamos hablando.
El experimento anterior
En el artículo anterior conseguimos que nuestro medidor de CO2 funcionara con una batería 18650 durante 12 días, reportando valores mediante MQTT cada minuto, mediante un experimento sencillo.
Estas son las reglas que utilizamos para el experimento anterior (podría haber alguna diferencia porque, por desgracia, no las guardé):
On [Sunrise#PPM] do
publish,%sysname%/Sunrise/PPM,[Sunrise#PPM] //publish CO2
publish,%sysname%/Battery,[Battery#Volts]
publish,%sys
If [SleepEnable#State]=1
deepsleep,60 //go to deepsleep for 60 seconds (even if deep sleep value is not configured in the config menu)
EndIf
Endon
On MQTT#Connected Do //when the broker is connected
If [SleepEnable#State]=1
publish,%sysname%/status,"Deepsleep Enabled" //publish information
timerSet,1,1
Else
publish,%sysname%/status,"Deepsleep Disabled" //publish information
EndIf
EndOn
On Rules#Timer=1 Do
deepsleep,60 //go to deepsleep for 60 seconds (even if deep sleep value is not configured in the config menu)
EndOn
On System#Wake Do
publish,%sysname%/status,"Wake" //publish information
EndOn
On System#Boot Do
publish,%sysname%/status,"Boot" //publish information
EndOn
On System#Sleep Do
publish,%sysname%/status,"Sleep" //publish information
EndOn
Y aquí puedes ver el tiempo que nuestro microcontrolador estaba encendido y su consumo (1mV=1mA de consumo con un offset de 8mV aprox.):
Te explico, con detalle, como interpretar este gráfico para que puedas interpretar tú mismo este gráfico y los siguientes. Hay mucha información útil en el gráfico y, dependiendo de tu capacidad de observación, puede que detectes bastantes más cosas de las que estoy describiendo en este artículo, ya que la cantidad de información que contiene es analógica (infinita):
En la escala vertical tienes unos números, como 0,004, -0,016, -0,036, etc. esos números representan el consumo del medidor al completo en cada momento. Como verás cada división horizontal está separada por 20 milivoltios, que representan 20 miliamperios de consumo (1mV=1mA).
Estos valores tienen un offset (desviación) de 8mA, provocada por los instrumentos de medida.
Si en un momento determinado en la escala ves -0.026V, quiere decir que el consumo, en ese instante, era de 26mA.
En la escala horizontal tienes el tiempo en segundos. Cada división en la escala horizontal es de 1.12 segundos.
Los tiempos están referidos al momento en el que empieza la captura de datos (antes de que el medidor esté encendido).
Verás, por ejemplo, que el medidor se pone en marcha en el segundo 4,35 y que comienza con un pequeño pico de consumo de unos 30mA seguido de otro de unos 40mA y otro de 118mA para posteriormente bajar hasta unos 26mA y quedarse ahí durante unos segundos.
Como ves el medidor está encendido un total de 10,186 segundos.
Línea base (punto de partida del consumo)
Como estos experimentos los estoy haciendo con ESP Easy, lo primero que voy a hacer, antes de empezar a comunicarnos con el sensor de CO2, hacer envíos de datos por wifi, MQTT y cosas así, es hacer un primer análisis en el que pondré una regla en ESP Easy (en System#Boot) que vuelva a poner el microcontrolador en modo deep sleep, sin hacer nada más.
Esto me servirá para comprobar cuál es el tiempo mínimo que ESP Easy me permite tener el microprocesador despierto.
ESP Easy es como un sistema operativo. Tiene su procedimiento de arranque en el que realiza sus propios asuntos, inicialización, creación de sus estructuras de datos, búsqueda de plugins disponibles, etc. y esto lleva un tiempo.
Partimos de la base de que no podemos pretender tener el mismo control sobre el microcontrolador que tendríamos programándolo directamente, en C++, por ejemplo, en el que somos los dueños de cada microsegundo que utiliza el microcontrolador. Es el precio que hay que pagar por un sistema tan sencillo como ESP Easy, que no necesita programación.
Aunque lo primero que hagamos, cuando ESP Easy arranque y tengamos el control, sea volver a poner el microcontrolador en modo deep sleep (ejecutando una regla en System#Boot), esto llevará un tiempo y ese tiempo será esa línea base o tiempo mínimo, sobre el que empezaremos a añadir otras cosas que consumirán tiempo (comunicaciones con el sensor de CO2, conexión a la red wifi, envío de datos, etc.).
En este caso, he añadido la siguiente regla:
On System#Boot Do
If [SleepEnable#State]=1
deepsleep,30 //go to deepsleep
EndIf
EndOn
Esta regla se ejecuta en cuanto ESP Easy arranca (o despierta desde deep sleep) y comprueba si SleepEnable#State es igual a 1 (esto es un switch que tengo puesto en uno de los pines para poder activar y desactivar el modo deep sleep a voluntad). Si SleepEnable#State es igual a 1 vuelve al modo deep sleep durante 30 segundos.
Este es el resultado:
Como veis el microcontrolador está despierto durante 2,133 segundos. Este es el tiempo mínimo que tarda en arrancar ESP Easy, ejecutar la regla y volver al estado de deep sleep sin hacer nada más.
¿Queda espacio para la optimización de esta parte? Podría ser. Tendré que hacer más pruebas, jugando con algunos valores de la configuración de ESP Easy e incluso compilando una versión a medida que no incluya soporte para ningún sensor que no sea imprescindible.
Leyendo el sensor de CO2
La siguiente prueba que voy a realizar será comprobar cuanto tiempo más tarda sí añado la medida del sensor de CO2.
Aquí tengo varias opciones, y voy a probar algunas…
La primera prueba consistirá en habilitar el dispositivo correspondiente al sensor Senseair Sunrise que estoy utilizando en la pestaña Devices, con sus valores por defecto, y forzar desde la regla la lectura del sensor.
Durante esta prueba voy a mantener el sensor encendido y habilitado permanentemente para que esté listo para proporcionar la medida y evitar el tiempo de espera mientras que el sensor arranca y proporciona la medida (el pin ENable del Senseair Sunrise conectado a +5V). Probablemente este tiempo será mínimo, pero no quiero que influya.
Esta es la regla que voy a utilizar:
On System#Boot Do
If [SleepEnable#State]=1
taskrun,1
deepsleep,30 //go to deepsleep
EndIf
EndOn
Esta regla es igual que la que he utilizado en el ejemplo anterior, pero fíjate que incluyo la línea «taskrun,1«. Este comando, por si no lo conoces, indica a ESP Easy que lea las medidas del sensor número 1 de la pestaña de Devices (en este caso el sensor número 1 de la pestaña es el Senseair Sunrise, ESP Easy los enumera como «Task» -Tarea-):
Y este es el resultado:
hmmm… esto realmente ha cambiado mucho… ¿lo ves?
Para empezar donde antes teníamos una línea de consumo casi plana, ahora tenemos una línea de consumo llena de picos periódicos (el consumo del sensor) y, sobre todo, ahora nuestro ESP8266 está despierto durante mucho más tiempo…
Te he marcado, con círculos rojos, dos datos que quiero que veas:
El primero arriba a la derecha es el tiempo que el ESP8266 ha estado despierto 8,533 segundos (antes fueron 2,133 segundos). Este tiempo es el transcurrido entre la primera línea vertical verde (marcada «a») y la segunda línea vertical verde (marcada «b»).
El segundo, en la parte central, es el consumo que suponen esos picos del Senseair Sunrise, 6mA. Es la diferencia entre las dos líneas verdes horizontales (que limitan la parte superior e inferior de esos picos).
Por cierto, por si no lo sabes y como «culturilla general del cacharreo», esas líneas verdes, que muestran los osciloscopios para ayudar a medir diferencias, valores, etc. se llaman cursores.
El incremento en tiempo por leer el sensor ha sido de 6,4 segundos, inaceptable. Habrá que hacer más pruebas para ver si es posible reducir ese tiempo.
Leer el sensor de CO2 y enviar la medida
Los ejemplos anteriores estaban bien porque nos permitían establecer una línea base sobre la que empezar, pero eran bastante inútiles, desde un punto de vista de funcionalidad.
El ESP8266 despertaba, leía el sensor, se volvía a dormir y así una y otra vez (sin hacer absolutamente nada con esas medidas, que se perdían como lágrimas en la lluvia).
En este experimento vamos a enviar las medidas por wifi a un servidor utilizando el protocolo MQTT.
Recordemos que esto implica activar el controlador MQTT de ESY Easy, lo que le obligará a conectarse al broker MQTT, y esto lleva su tiempo.
Estas son la regla que voy a utilizar para este experimento:
On MQTT#Connected Do //when the broker is connected
If [SleepEnable#State]=1
publish,%sysname%/status,"Deepsleep Enabled" //publish information
publish,%sysname%/Sunrise/PPM,[Sunrise#PPM] //publish CO2
deepsleep,30 //go to deepsleep
EndIf
EndOn
Esta regla es ejecutada cuando se produce el evento «MQTT#Connected», que genera automáticamente ESP Easy cuando se conecta al servidor MQTT (¿para qué hacer algo antes de este momento?), y lo que hace es enviar dos mensajes por MQTT y volver al modo de deep sleep durante otros 30 segundos.
Una vez activado el controlador MQTT el consumo es el siguiente:
Como ves he separado el ciclo con dos cursores para que puedas diferenciar el tiempo que está en alto consumo (que corresponde al máximo de actividad wifi) que es el que más impacto tiene en la batería. En el borde derecho de la imagen puedes ver que el incremento de tiempo entre el cursor «b» y el cursor «c», que corresponde a la zona de máximo consumo, es de 3,578 segundos.
A continuación, puedes ver dos ciclos completos, donde nuestro medidor despierta, lee el sensor, envía los datos por MQTT, vuelve a deep sleep, despertar, leer, enviar, y de nuevo deep sleep. Esto te permitirá ver cuánto dura el tiempo en estado de deep sleep y su consumo:
Como verás he colocado cursores en el osciloscopio al principio y final de cada «despertar« para que puedas comprobar esos tiempos (en el borde derecho puedes ver los incrementos de tiempo entre ellos, por ejemplo, que el tiempo de deep sleep entre los dos «despertares» es de 20,067 segundos).
Continuará…
Osciloscopio USB Loto Instruments OSC482
Aprovecho para comentaros:
El osciloscopio utilizado en esta ocasión (al que corresponden las capturas de pantalla) no es mi osciloscopio habitual de sobremesa Rigol DS1054Z, sino que he utilizado un osciloscopio USB Loto Instruments OSC482 y quiero deciros que estoy encantado con él (lo comento, sobre todo, porque algunos me habéis preguntado por este asunto).
He tenido (y tengo) varios osciloscopios USB y la verdad es que eran aparatos muy limitados y muy lejos de lo que es un osciloscopio de verdad. Pensaba que todos los osciloscopios USB eran así, pero mi experiencia y mi opinión ha cambiado completamente con este OSC482.
Si queréis un osciloscopio USB que de verdad funcione, os lo recomiendo sin reparos.
Cuesta poco más de 60 euros y podéis encontrarlo aquí: Osciloscopio USB Loto Instruments OSC482
El modelo concreto que yo he comprado es el OSC482L, que incluye analizador lógico de 4 canales.
Es muy probable que escriba un artículo completo sobre él porque, en las pocas semanas que hace que lo tengo se ha convertido en uno de los instrumentos que más utilizo a diario. Me es superfácil comprobar lo que hace un microprocesador, si una alimentación es estable, si un sensor se está comunicando bien, y un sin fin de cosas más…
¿TE HA RESULTADO INTERESANTE?
¡NO TE PIERDAS FUTUROS EXPERIMENTOS!
SUSCRÍBETE A LA NEWSLETTER Y ENTRA EN EL GRUPO DE TELEGRAM Y NO TE PIERDAS NADA DE LO MEJOR.