Sensor de calidad del aire conectado a Internet
Grado en Ingenier´ıa Inform ´atica TFG - Sistemas empotrados
Estudiante
Javier Rafael Gisbert Garz ´ on
Consultor
Jordi B ´ecares Ferr ´es
6 de enero de 2022
Esta obra est ´a bajo una licencia Creative Commons ((Atribuci´on- NoComercial-CompartirIgual 4.0 Internacional)).
FICHA DEL TRABAJO FINAL
T´ıtulo del trabajo Sensor de calidad del aire conectado a Internet Nombre del autor Javier Rafael Gisbert Garz ´on
Nombre del consultor Jordi B ´ecares Ferr ´es Nombre del PRA Pere Tuset Peir ´o Fecha de entrega 06/01/2022
Titulaci ´on Grado en Ingenier´ıa Inform ´atica Area del Trabajo Final´ Sistemas empotrados
Idioma del trabajo Castellano
Palabras clave IoT, Contaminaci ´on, CO2
Resumen del trabajo
Este proyecto plantea la creaci ´on de un dispositivo de medida de de la calidad del aire, buscando que sea sencillo y de bajo coste, pero sin renunciar a ninguna capacidad y maximizando las capacidades de conectividad para aprovechar la interacci ´on con dispositivos m ´oviles.
Para implementar el sistema empotrado que realiza esta tarea se utiliza un microcon- trolador Espressif ESP32, ya que tiene integrados perif ´ericos de radiofrecuencia Wi-Fi y Bluetooth en un ´unico paquete.
El sensor utilizado para la calidad del aire es el Bosch BME680, que incluye en el mismo hardware cuatro sensores diferentes: Temperatura, presi ´on atmosf ´erica, hu- medad y concentraci ´on de gases nocivos.
Con estos dos elementos el sistema realiza lecturas peri ´odicamente y las env´ıa me- diante el protocolo MQTT a un servicio remoto que almacene y permita visualizar los datos. Estas lecturas tambi ´en se deben poder leer directamente del dispositivo me- diante el protocolo Bluetooth Low Energy con un tel ´efono inteligente.
Adem ´as, el dispositivo ha de ser capaz de funcionar tambi ´en de forma aut ´onoma con una bater´ıa en caso de p ´erdida de alimentaci ´on.
Por ´ultimo, se realiza un dise ˜no de placa de circuito integrado que integra todos los elementos de manera que se obtiene un prototipo de un producto t ´ecnica y comer- cialmente viable.
Abstract
This project proposes the creation of a device air quality measurement, attempting to keep it simple and low-cost, but without giving up any feature and maximizing connec- tivity capabilities to take advantage of interaction with mobile devices.
An Espressif ESP32 microcontroller is used to implement the embedded system that performs this task, as it has integrated Wi-Fi and Bluetooth radio frequency peripherals in a single package.
The sensor used for air quality measurement is Bosch BME680, which includes four different sensors on the same hardware: Temperature, atmospheric pressure, humidity and harmful gases concentration.
With these two elements, the system performs readings periodically and sends them through MQTT protocol to a remote service that stores and allows the data to be visua- lized. These readings must also be readable directly from the device using Bluetooth Low Energy through a smartphone.
Furthermore, the device must also be able to operate autonomously with a battery in the event of a power failure.
Finally, a printed circuit board design is made that integrates all the elements in such a way that the prototype of a technically and commercially viable product is obtained.
´Indice
´Indice de figuras 5
´Indice de tablas 7
1. Introducci ´on 8
1.1. Contexto y justificaci ´on del trabajo . . . 8
1.2. Descripci ´on del trabajo . . . 9
1.3. Objetivos . . . 11
1.4. Enfoque y m ´etodo seguido . . . 11
1.5. Planificaci ´on del trabajo . . . 11
1.5.1. Fases de desarrollo . . . 11
1.5.2. Listado de tareas . . . 13
1.5.3. Diagramas de Gantt . . . 14
1.5.4. Cambios de planificaci ´on . . . 17
1.6. Recursos empleados . . . 18
1.6.1. Recursos software . . . 18
1.6.1.1. ESP-IDF . . . 18
1.6.1.2. BSEC . . . 18
1.6.1.3. Visual Studio Code . . . 18
1.6.1.4. KiCAD . . . 18
1.6.1.5. Docker . . . 19
1.6.2. Recursos hardware . . . 19
1.6.2.1. Olimex ESP32-DevKit-LiPo . . . 19
1.6.2.2. Adafruit BME680 . . . 19
1.6.2.3. Bater´ıa Li-Po . . . 20
1.6.2.4. Otros recursos . . . 20
1.7. Productos obtenidos . . . 21
1.8. Breve descripci ´on de los otros cap´ıtulos de la memoria . . . 23
2. Antecedentes 24 2.1. Estado del arte . . . 24
2.2. Estudio de mercado . . . 25
3. Descripci ´on funcional 26 3.1. Sistema de monitorizaci ´on de la calidad del aire . . . 26
3.1.1. Requisitos del sistema . . . 26
3.1.1.1. Monitorizacion de las magnitudes del sensor BME680 . . . 26
3.1.1.2. Conexi ´on a Internet por Wi-Fi . . . 26
3.1.1.3. Sincronizaci ´on horaria del dispositivo . . . 26
3.1.1.4. Servidor de demostraci ´on para recepci ´on, almacenamiento y re- presentaci ´on de datos del sensor . . . 26
3.1.1.5. Env´ıo de datos del sensor por MQTT . . . 27
3.1.1.6. Configuraci ´on de par ´ametros de conexi ´on Wi-Fi mediante smartpho- ne . . . 27
3.1.1.7. Soporte de cambios de configuraci ´on de par ´ametros del dispo- sitivo . . . 27
3.1.1.8. Configuraci ´on de par ´ametros de env´ıo de datos del dispositivo v´ıa web . . . 27
3.1.1.9. Funcionamiento aut ´onomo mediante bater´ıa . . . 27
3.1.1.10. Modo de bajo consumo . . . 28
3.1.1.11. Soporte de TLS para el env´ıo de datos por MQTT . . . 28
3.1.1.12. Configuraci ´on de par ´ametros de env´ıo y lectura de datos directa
mediante smartphone . . . 28
3.1.1.13. Dise ˜no, fabricaci ´on y montaje de placa de circuito integrado . . 28
3.1.2. Dise ˜no, y prototipado de caja de pl ´astico del dispositivo . . . 29
3.1.3. Diagrama de bloques del sistema . . . 29
3.2. Servidor de almacenamiento y visualizaci ´on de datos . . . 29
3.2.1. Mosquitto . . . 29
3.2.2. InfluxDB . . . 30
3.2.3. Telegraf . . . 30
3.2.4. Grafana . . . 30
3.3. Dispositivo de medici ´on de calidad del aire . . . 31
3.3.1. Esquema el ´ectrico general . . . 31
3.3.2. Esquema de prototipo en breadboard . . . 31
3.3.3. Arquitectura de software . . . 33
4. Descripci ´on detallada 34 4.1. Descripci ´on del hardware . . . 34
4.1.1. Espressif ESP32 . . . 34
4.1.1.1. Memoria . . . 35
4.1.1.2. Bajo consumo . . . 36
4.1.2. Olimex ESP32-DevKit-LiPo . . . 37
4.1.3. BME680 . . . 40
4.1.4. PCB del proyecto . . . 42
4.1.4.1. Dise ˜no . . . 42
4.1.4.2. Fabricaci ´on y montaje . . . 44
4.2. Software del sistema . . . 46
4.2.1. Bosch Software Environmental Cluster (BSEC) . . . 46
4.2.1.1. Configuraci ´on . . . 46
4.2.1.2. Implementaci ´on . . . 47
4.2.1.3. Funcionamiento . . . 48
4.2.2. ESP-IDF . . . 49
4.2.3. Aplicaci ´on . . . 49
4.2.3.1. App event loop . . . 50
4.2.3.2. Device state . . . 51
4.2.3.3. Config manager . . . 53
4.2.3.4. Config manager Web . . . 54
4.2.3.5. Device name . . . 55
4.2.3.6. Power monitor . . . 55
4.2.3.7. Sensor . . . 56
4.2.3.8. Sensor reading queue . . . 57
4.2.3.9. Certificate manager . . . 58
4.2.3.10. Sender . . . 59
4.2.3.11. SNTP manager . . . 61
4.2.3.12. Wi-Fi manager . . . 61
4.2.3.13. BLE manager . . . 64
4.3. Medici ´on de consumos . . . 66
5. Viabilidad t ´ecnica 69 6. Valoraci ´on econ ´omica 69 6.1. Hardware . . . 69
6.2. Mano de obra . . . 70
6.3. Coste total . . . 71
7. Conclusiones 72 7.1. Autoevaluaci ´on . . . 72
7.2. Propuesta de mejoras y trabajo futuro . . . 73
8. Glosario 74 Referencias 75
´Indice de figuras
1. Esquema b ´asico . . . 92. Diagrama de Gantt general del proyecto . . . 14
3. Diagrama de Gantt de PEC2 . . . 15
4. Diagrama de Gantt general de PEC3 . . . 16
5. Diagrama de Gantt general la entrega final . . . 17
6. Placa Olimex ESP32-DevKit-Lipo . . . 19
7. Placa Adafruit BME680 . . . 20
8. Bater´ıa Li-Po de 1400 mAh . . . 20
9. Dispositivo obtenido sin caja . . . 21
10. Dispositivo obtenido con caja abierta . . . 22
11. Dispositivo obtenido con caja cerrada . . . 22
12. Herramienta de visualizaci ´on de datos obtenida . . . 23
13. Ejemplo de arquitectura con AWS IoT . . . 24
14. Ejemplos de sensores de calidad del aire sin conectividad . . . 25
15. Diagrama de bloques del sistema . . . 29
16. Dashboard Grafana del proyecto . . . 31
17. Esquema el ´ectrico general del dispositivo . . . 31
18. Esquema del prototipo en breadboard . . . 32
19. Arquitectura de software del dispositivo . . . 33
20. Diagrama de bloques del ESP32 [43] . . . 34
21. Regiones de memoria del ESP32 [21] . . . 35
22. Comparaci ´on entre light sleep y deep sleep . . . 37
23. Resumen de pines de Olimex ESP32-Devkit-Lipo . . . 38
24. Esquem ´atico de detecci ´on de bater´ıa y voltaje de Olimex ESP32-Devkit-LiPo . . 39
25. Curva de descarga de bater´ıas Li-Po [5] . . . 40
26. BME680 . . . 40
27. Resistencia de un sensor de metal- ´oxido [22] . . . 42
28. Esquem ´atico de PCB . . . 43
29. Dise ˜no de PCB . . . 44
30. Nuevo pedido en JLCPCB . . . 45
31. Estado de pedido en JLCPCB . . . 46
32. Clasificaci ´on de IAQ y c ´odigo de colores [2] . . . 46
33. Funcionamiento general de BSEC [28] . . . 49
34. M ´aquina de estados . . . 51
35. Captura de pantalla de p ´agina web de configuraci ´on . . . 54
36. Captura de pantalla de p ´agina web de configuraci ´on de certificados . . . 55
37. Cola de lecturas pendientes de env´ıo . . . 58
38. Traducci ´on de direcciones de memoria SRAM en certificados en memoria Flash [17] . . . 59
39. Proceso de configuraci ´on Wi-Fi [16] . . . 62
40. Seguridad del proceso de configuraci ´on Wi-Fi [16] . . . 63
41. C ´odigo QR de proceso de configuraci ´on Wi-Fi . . . 64
42. Perfil GATT del dispositivo . . . 65
43. Medici ´on de corriente consumida por el dispositivo . . . 67
44. Medici ´on de corriente consumida por el dispositivo con resistencia shunt . . . . 68
45. Gr ´afica de corriente consumida por el dispositivo a lo largo del tiempo . . . 68
´Indice de tablas
1. Listado de tareas . . . 132. Comparaci ´on de los tres procesadores del ESP32: Core 0, Core 1 y co-procesador ULP. . . 36
3. Consumo de corriente del ESP32. [34] . . . 37
4. Consumo de corriente del BME680. . . 41
5. Lista de materiales de PCB . . . 44
6. Atributos de una lectura de sensor en formato JSON . . . 60
7. Coste de materiales . . . 69
8. Coste de fabricaci ´on en JLCPCB . . . 70
9. Coste de mano de obra . . . 70
10. C ´alculo de tarifa por hora . . . 70
11. Coste total del proyecto . . . 71
12. Tabla de dedicaci ´on . . . 72
1. Introducci ´ on
1.1. Contexto y justificaci ´ on del trabajo
La atm ´osfera que recubre la Tierra es una capa gaseosa que contiene una mezcla de ele- mentos qu´ımicos simples y complejos, y es imprescindible para el desarrollo de casi cualquier tipo de vida. Sin embargo, debido a la actividad humana la composici ´on de estos gases y com- puestos qu´ımicos se est ´a viendo alterada a un ritmo cada vez m ´as acelerado.
Es bien conocido el papel de los gases de efecto invernadero, principalmente el Di ´oxido de Carbono (CO2), sobre el calentamiento global. El uso generalizado de combustibles f ´osiles para generaci ´on de energ´ıa es el principal responsable de estas emisiones [29]. Mediante el uso de instrumentos de medida de la proporci ´on de CO2en la atm ´osfera se puede cuantificar este problema, as´ı como su evoluci ´on hist ´orica mediante la recogida de lecturas.
Si bien el incremento de CO2atmosf ´erico es una de las mayores amenazas para el equilibrio de los ecosistemas terrestres, hay muchos otros elementos presentes en la atm ´osfera que afectan directa e indirectamente a la salud de los organismos vivos, incluyendo a los seres humanos.
Por otra parte, el Ozono (O3) es un componente fundamental en el bloqueo de los da ˜ninos rayos ultravioleta cuando se encuentra en las capas superiores de la atm ´osfera, pero resul- ta altamente irritante al entrar en contacto con las v´ıas respiratorias de los seres vivos [38].
Puesto que el Ozono se produce tambi ´en durante el la combusti ´on de combustibles f ´osiles, se encuentra presente especialmente en grandes ciudades y centros industriales, donde adem ´as suele haber una alta concentraci ´on de poblaci ´on.
Tambi ´en podemos encontrar la materia particulada en suspensi ´on (PM2,5 y PM10), la cual se trata de part´ıculas de tama ˜no microsc ´opico de unos micr ´ometros de di ´ametro, compuesta normalmente de metales, holl´ın y sustancias qu´ımicas org ´anicas. Estas part´ıculas causan gra- ves problemas respiratorios si son inhaladas durante largos periodos de tiempo [38], y al igual que el resto de contaminantes mencionados, tambi ´en vienen producidas mayoritariamente por la actividad humana.
Existen otros muchos elementos peligrosos para la salud como el Di ´oxido de Nitr ´ogeno (NO2), el Di ´oxido de Azufre (SO2), el Plomo (Pb) o el Formaldeh´ıdo (CH2O) [38], y por tanto, ante la diversidad de fuentes contaminantes, las autoridades suelen utilizar un ´Indice de Calidad del Aire (ICA), o Air Quality Index (IAQ) en ingl ´es, que resume el contenido de elementos contaminantes en el aire.
Este ´ındice no refleja la proporci ´on exacta de los contaminantes presentes, pero define una escala de valores que reflejan de manera sencilla de entender el nivel de contaminaci ´on en el aire. El c ´alculo del valor de este ´ındice y la escala de calidad que representa var´ıa entre pa´ıses y regiones, y por ejemplo en la Uni ´on Europea se utiliza el sistema estandarizado Common Air Quality Index (CAQI) [6].
Existen tambi ´en diversos estudios que vinculan concentraciones de CO2elevadas en inte-
riores con descensos de rendimiento acad ´emico de ni ˜nos en edad escolar [23] y trabajadores en entornos de oficina [33]. Del mismo modo, la alta concentraci ´on de CO2en espacios interio- res se considera un marcador de ventilaci ´on deficiente, lo cual incrementa considerablemente el riesgo de transmisi ´on de enfermedades transmitidas por v´ıa a ´erea como el COVID-19 [4].
Es de elevado inter ´es, por tanto, realizar una monitorizaci ´on en continua de los valores de estos contaminantes para que estos ´ındices de f ´acil comprensi ´on puedan estar actualizados en tiempo real. Si esta informaci ´on se hace disponible de forma p ´ublica en Internet, las autoridades pueden tomar medidas para la reducci ´on de picos de contaminaci ´on y las personas pueden tomar acciones tambi ´en a t´ıtulo individual para protegerse de los efectos nocivos para la salud.
Existen diversos portales para la consulta de estos datos, pero todos ellos necesitan de dispositivos que realicen las mediciones y env´ıen los datos peri ´odicamente. Si bien existen equipos de estas caracter´ısticas en el mercado, se trata en su mayor´ıa de dispositivos volumi- nosos, caros y con conectividad a Internet limitada.
Se presenta una necesidad, como se puede observar, que este proyecto humildemente aspira a cubrir.
1.2. Descripci ´ on del trabajo
Este proyecto plantea la creaci ´on de un dispositivo de medida de de la calidad del aire, bus- cando que sea sencillo y de bajo coste, pero sin renunciar a ninguna capacidad y maximizando las capacidades de conectividad para aprovechar la interacci ´on con dispositivos m ´oviles.
Figura 1: Esquema b ´asico
El microcontrolador elegido para operar este dispositivo es un Espressif ESP32, ya que
posee capacidades de conectividad Wi-Fi y Bluetooth integradas, adem ´as de buses de comu- nicaci ´on SPI e I2C para interoperar con los sensores de calidad de aire. Estos sensores vienen integrados en un ´unico paquete en el Bosch BME680, que ofrece lectura de humedad relati- va, presi ´on barom ´etrica, term ´ometro, as´ı como un detector de compuestos de gases vol ´atiles que si bien no ofrece un desglose concreto, sirve para aproximar el ´ındice de calidad del aire mediante una f ´ormula matem ´atica.
Para el desarrollo del programa que se ejecuta en el microcontrolador ESP32, se opta por utilizar el entorno de desarrollo nativo del fabricante, el ESP-IDF. Se trata de un sistema ope- rativo en tiempo real FreeRTOS al que se incorporan librer´ıas de abstracci ´on de hardware y otras de conectividad. Est ´a implementado en lenguaje de programaci ´on C y por tanto el pro- grama desarrollado utiliza el mismo lenguaje para tener el control de todo lo que se ejecuta en el dispositivo con la mayor precisi ´on posible.
El dispositivo ha de incorporar tambi ´en una bater´ıa que le permita funcionar sin alimenta- ci ´on el ´ectrica externa en entornos en los que pueda estar conectado a fuentes de generaci ´on de energ´ıa renovables, que suelen tener el inconveniente de ser intermitentes. Ser ´a necesario, por tanto, operar tanto el microcontrolador como sus perif ´ericos y sensores en modo de bajo consumo el mayor tiempo posible, de manera que se pueda optimizar el tiempo de funciona- miento con bater´ıa al m ´aximo posible.
Por otra parte, el dispositivo ha de aprovechar sus caracter´ısticas de conectividad Wi-Fi para enviar las lecturas a un servidor remoto mediante protocolo MQTT, ya que los datos podr ´an ser visualizados y procesados de manera m ´as rica de esta manera. Se elige el protocolo MQTT porque se trata ya de un est ´andar en la industria IoT que est ´a soportado por todos los pro- veedores de servicio en la nube, as´ı como todos los proyectos de software libre de dom ´otica.
Ser ´a necesario, no obstante, equilibrar el env´ıo de datos con el consumo de energ´ıa de manera que el muestreo sea suficientemente relevante por un lado, y por otro la vida ´util del dispositivo cuando no est ´a alimentado externamente no se vea seriamente comprometida.
Por ´ultimo, tambi ´en se propone aprovechar la tecnolog´ıa Bluetooth Low Energy soportada por el ESP32 para ofrecer un canal de comunicaci ´on directa entre el dispositivo y una amplia gama de tel ´efonos inteligentes. La funcionalidad consistir´ıa en ofrecer un perfil GATT que ofrez- ca todos los datos de calidad del aire de los sensores de manera que puedan ser consultados de forma c ´omoda por una aplicaci ´on ejecutada en el tel ´efono inteligente. Esta comunicaci ´on Bluetooth tambi ´en se ha de aprovechar para realizar la configuraci ´on de la red Wi-Fi a la que el dispositivo se ha de conectar, as´ı como cualquier otro par ´ametro configurable relativo a su fun- cionamiento. De esta manera no es necesario incorporar una pantalla y botones al dispositivo, ya que encarecer´ıa considerablemente el producto y limitar´ıa el tiempo de uso con bater´ıa.
Se plantea realizar el proyecto inicialmente en una placa de pruebas combinando diferentes placas de circuitos integrados para el ESP32, el BME680 y la bater´ıa, y una vez resulte fun- cional a nivel de hardware el siguiente paso ser´ıa dise ˜nar una placa de circuito integrado con Kicad y mandarla a fabricar y montar.
Esto se complementar´ıa tambi ´en con el dise ˜no de un envoltorio sencillo con herramientas de dise ˜no gr ´aficas, que ser´ıa impreso mediante una impresora 3D para obtener un prototipo perfectamente funcional de un producto t ´ecnica y comercialmente viable.
1.3. Objetivos
El principal objetivo de este proyecto es la obtenci ´on de un dispositivo completamente fun- cional que sea capaz de enviar datos de la calidad del aire con m´ınima intervenci ´on humana.
Ha de ser aplicable en la mayor variedad de ubicaciones posible, tanto en interior como exterior, as´ı como conectado a la red el ´ectrica o a una fuente de energ´ıa renovable aislada del resto de la red. Resulta tambi ´en clave que sea de bajo coste y f ´acil de usar para que pueda ser accesible para el gran p ´ublico.
Con todo esto se pretende que sea un elemento que contribuya a generar consciencia social y ecol ´ogica ante graves problemas como la contaminaci ´on atmosf ´erica y el calentamiento global. De esta manera la ciudadan´ıa estar ´a m ´as informada y preparada para tomar iniciativas comunes e individuales para poder atajar estos grandes retos.
Del mismo modo tambi ´en puede ser extremadamente ´util como indicador de ventilaci ´on de espacios interiores, ya que una ventilaci ´on deficiente incrementa el riesgo de contagio de enfermedades transmisibles por v´ıa ´area y tambi ´en reduce el rendimiento intelectual de las personas.
1.4. Enfoque y m ´etodo seguido
La metodolog´ıa para el desarrollo del proyecto ha consistido en identificar los requisitos del mismo (secci ´on 3.1.1) y ordenarlos por importancia y valor aportado al proyecto.
En base a esto se ha realizado un desglose de las funcionalidades en tareas como se desglosa en la tabla 1 y realizando una planificaci ´on temporal de las tareas en funci ´on de la importancia del requisito al que corresponden.
De este modo se pretende que en caso de imprevistos que comprometan la viabilidad tem- poral del proyecto siempre se pueda obtener al menos una parte relevante del mismo.
En cuanto a la ejecuci ´on del proyecto, se ha optado por intentar aprovechar todos los ele- mentos de software y hardware que sea posible para poder centrar el trabajo principalmente en la funcionalidad que se pretende ofrecer. Estos elementos se detallan en la secci ´on 1.6.
1.5. Planificaci ´ on del trabajo
1.5.1. Fases de desarrollo
El trabajo se ha desarrollado entorno a unas fases o etapas definidas en la asignatura, cada una de ellas con un hito entregable a su final. Por tanto ha sido necesario realizar la planificaci ´on del trabajo en funci ´on de e esto, ya que estas etapas ten´ıan un marco temporal prefijado. Las fases con las que se ha trabajado son las siguientes:
PEC1: Plan de trabajo. Del 03/10/21 al 121021. Se realiza una planificaci ´on inicial del proyecto.
PEC2: Seguimiento. Del 13/10/21 al 09/11/21. Se trabaja sobre la planificaci ´on y se realiza una entrega parcial de las tareas correspondientes a esta etapa.
PEC3: Seguimiento y previa de la memoria. Del 08/12/21 al 27/12/21. Se contin ´ua trabajando sobre la planificaci ´on y se realiza una entrega parcial de las tareas correspon- dientes a esta etapa, as´ı como una previa de la memoria.
C ´odigo final. Del 13/10/21 al 09/11/21. Se finalizan las tareas pendientes y se realiza la entrega final del c ´odigo del proyecto.
Memoria. Del 26/11/21 al 06/01/22. Se redacta y entrega la presente memoria.
1.5.2. Listado de tareas
En la tabla 1 se presenta el listado de tareas del proyecto, indicando en rojo aquellas que han variado la planificaci ´on inicial del mismo, bien sea porque una tarea inicialmente planficada de descart ´o, o bien porque se tuvo que realizar una tarea fuera de planificaci ´on.
Horas Horas
Tarea planificadas dedicadas Completada Entrega
Redactar plan de trabajo 8 8 100 % PEC1
Total PEC1 8 8 100 % PEC1
Montaje de elementos y pruebas b ´asicas de funcionamiento 7 4 100 % PEC2
Monitorizaci ´on de las magnitudes del sensor BME680 10 12 100 % PEC2
Conexi ´on a Internet mediante Wi-Fi 9 8 100 % PEC2
Sincronizaci ´on horaria mediante NTP 2 2 100 % PEC2
Despliegue y configuraci ´on de servidor Home Assistant 6 6 100 % PEC2
Implementaci ´on inicial del la l ´ogica de env´ıo de datos 15 25 100 % PEC2 Implementaci ´on de modo de configuraci ´on de par ´ametros de co-
nexi ´on Wi-Fi mediante BLE
12 7 100 % PEC2
Recepci ´on de par ´ametros de env´ıo por suscripci ´on MQTT 10 9 100 % PEC2
Replanteamiento de la parte de servidor - 5 100 % PEC2
Despliegue y configuraci ´on de Mosquitto, Telegraf y Grafana - 10 100 % PEC2 Configuraci ´on de par ´ametros de env´ıo en Home Assistant 10 - 0 % Descartada
Redacci ´on informe PEC2 8 8 100 % PEC2
Total PEC2 89 96 100 % PEC2
Finalizaci ´on de tareas pendientes PEC2 - 6 100 % PEC3
Configuraci ´on de par ´ametros por p ´agina web - 15 90 % PEC3
Detecci ´on de alimentaci ´on externa 6 7 100 % PEC3
Lectura de nivel de bater´ıa 6 10 100 % PEC3
Investigaci ´on de modos de bajo consumo de ESP32 5 4 100 % PEC3
Investigaci ´on de modos de bajo consumo de BME680 3 2 100 % PEC3
Preparaci ´on de entorno de medici ´on de consumo del dispositivo 5 3 100 % PEC3 Implementaci ´on de l ´ogica de entrada en modo sleep para ESP32 6 8 100 % PEC3 Apagado de perif ´ericos de radiofrecuencia durante modo de bajo
consumo
9 7 100 % PEC3
Realizaci ´on de lecturas de sensor BME680 intercaladas con tiem- po en modo sleep
10 14 100 % PEC3
Realizaci ´on de env´ıo de datos ´unicamente cuando Wi-Fi est ´a acti- vado
12 17 100 % PEC3
Pruebas de tiempo de funcionamiento con alimentaci ´on de bater´ıa 5 2 100 % PEC3
Redacci ´on informe PEC3 8 4 100 % PEC3
Redacci ´on de la previa de la memoria 18 8 100 % PEC3
Total PEC3 84 107 100 % PEC3
Finalizaci ´on de tareas pendientes PEC3 6 7 100 % Entrega final
A ˜nadir soporte de TLS a conexiones MQTT 6 15 100 % Entrega final
Definir perfil GATT para el dispositivo 12 20 100 % Entrega final
Modificaci ´on de par ´ametros de conexi ´on mediante BLE 10 8 100 % Entrega final
Lectura de valores del sensor mediante BLE 9 8 100 % Entrega final
Dise ˜no de PCB 17 16 100 % Entrega final
Dise ˜no y prototipado de caja 10 - 0 % Descartada
Revisi ´on general y correcci ´on de fallos de estabilidad - 8 100 % Entrega final
Redacci ´on informe c ´odigo final - 4 100 % Entrega final
Total entrega final 70 86 100 % Entrega final
Correcciones finales de c ´odigo 6 - 0 % Memoria
Redacci ´on memoria 40 - 0 % Memoria
Total memoria 46 0 % Memoria
Tabla 1: Listado de tareas
1.5.3. Diagramas de Gantt
Puesto que el diagrama de Gantt del proyecto es de tama ˜no considerable, realizamos una presentaci ´on general (Figura 2) y posteriormente el desglose para cada una de las partes relevantes (Figuras 3, 4 y 5).
Figura 2: Diagrama de Gantt general del proyecto
Figura 3: Diagrama de Gantt de PEC2
Figura 4: Diagrama de Gantt general de PEC3
Figura 5: Diagrama de Gantt general la entrega final
1.5.4. Cambios de planificaci ´on
El principal cambio de planficaci ´on se debi ´o a que inicialmente se hab´ıa previsto utilizar como servicio de recogida y visualizaci ´on de datos Home Assistant [26], pero este result ´o no ser la herramienta adecuada para el proyecto.
Esto se debe a que Home Assistant no utiliza una marca de tiempo a la hora de guardar y representar los datos recibidos, y puesto que el dispositivo de este proyecto realiza el env´ıo de datos a r ´afagas cuando trabaja en modo de bajo consumo, se produc´ıan gr ´aficas completa- mente in ´utiles. Lamentablemente esto no result ´o evidente hasta que se empez ´o a trabajar en su tarea correspondiente.
Por tanto, hubo que encontrar una alternativa m ´as adecuada durante el transcurso de la PEC1, quedando afectada sensiblemente la planificaci ´on para esa fase. Adem ´as como esta era una de las ´ultimas tareas correspondientes a la fase PEC1, tambi ´en afect ´o ligeramente al inicio de la fase PEC2.
Por otra parte, al final del desarrollo del proyecto se descart ´o la tarea relativa al dise ˜no de
una caja para el prototipo, pues las competencias para realizar esto no son parte de un perfil de Ingeniero Inform ´atico y ocupaba un tiempo precioso para arreglar algunos fallos detectados a ´ultima hora.
1.6. Recursos empleados
Se puede distinguir entre dos tipos de recursos empleados para la realizaci ´on del proyecto.
1.6.1. Recursos software
1.6.1.1 ESP-IDF
Se trata del framework de desarrollo oficial para dispositivos ESP32. Ofrece drivers para los perif ´ericos del microcontrolador, as´ı como diferentes librer´ıas que ampl´ıan su funcionalidad con protocolos de comunicaci ´on como MQTT, HTTP y TLS. Se basa en un n ´ucleo FreeRTOS y est ´a completamente escrito en lenguaje de programaci ´on C.
Adem ´as del software que se incluye, ESP-IDF tambi ´en aporta un entorno de compilaci ´on basado en CMake, as´ı como varias herramientas para grabar los firmware generados en los dispositivos y realizar depuraci ´on.
1.6.1.2 BSEC
Software de gesti ´on del sensor BME680 que permite permite realizar el c ´alculo del ´ındice de calidad de aire en base a las lecturas de los sensores de temperatura, humedad, presi ´on y gas.
1.6.1.3 Visual Studio Code
Entorno de desarrollo de c ´odigo abierto con amplio soporte para gran cantidad de lenguajes y tecnolog´ıas mediante el uso de extensiones desarrolladas por la comunidad.
Para este proyecto se utiliza la extensi ´on oficial de Espressif que realiza la integraci ´on con ESP-IDF para trabajar con dispositivos ESP32.
1.6.1.4 KiCAD
Herramienta de dise ˜no de placas de circuito electr ´onicos de c ´odigo abierto empleada para la obtenci ´on de la PCB del proyecto.
1.6.1.5 Docker
Se trata de una herramienta que automatiza el despliegue de aplicaciones dentro de conte- nedores de software. Esto se utiliza para realizar el despliegue de forma unificada del software de la parte de servidor del proyecto.
1.6.2. Recursos hardware
1.6.2.1 Olimex ESP32-DevKit-LiPo
Placa que utiliza un microcontrolador ESP32 e incluye un circuito cargador de bater´ıa.
Figura 6: Placa Olimex ESP32-DevKit-Lipo
1.6.2.2 Adafruit BME680
Placa que monta el sensor de calidad de aire BME680 con los componentes m´ınimos para su funcionamiento.
Figura 7: Placa Adafruit BME680
1.6.2.3 Bater´ıa Li-Po
Bater´ıa de pol´ımero de Litio con capacidad de carga de 1400 mAh.
Figura 8: Bater´ıa Li-Po de 1400 mAh
1.6.2.4 Otros recursos
Fuente alimentaci ´on AC/DC regulable para alimentar el dispositivo.
Ordenador de desarrollo con sistema operativo Linux.
Cable Micro-USB para conectar la placa Olimex ESP32-Devkit-LiPo con el ordenador de desarrollo.
Placa breadboard para conexionado de prototipo.
Cables de puente para la placa breadboard.
Resistencias THT para prototipado en breadboard.
Botones e interruptores para prototipado en breadboard.
LED RGB.
Mult´ımetro digital.
Analizador l ´ogico Saleae Logic.
1.7. Productos obtenidos
Tras la finalizaci ´on de este proyecto se obtiene un dispositivo de medici ´on de calidad del aire complemetamente funcional (Figura 9) y capaz de comunicarse con servicios de recogida y visualizaci ´on de datos.
Figura 9: Dispositivo obtenido sin caja
Si bien no forma parte del desarrollo de este proyecto por quedar fuera del alcance de las competencias de un Ingeniero Inform ´atico, tambi ´en se a ˜nade al producto obtenido una caja para protegerlo (Figuras 10 y 11) y darle un acabado profesional.
Figura 10: Dispositivo obtenido con caja abierta
Figura 11: Dispositivo obtenido con caja cerrada
Por otra parte tambi ´en se obtiene una herramienta de visualizaci ´on de datos que permite consultar la evoluci ´on de las lecturas del sensor de calidad del aire a lo largo del tiempo (Figura 12).
Figura 12: Herramienta de visualizaci ´on de datos obtenida
1.8. Breve descripci ´ on de los otros cap´ıtulos de la memoria
A continuaci ´on se detalla el contenido de cada uno de los cap´ıtulos a partir de este punto:
Cap´ıtulo 1: Se realiza una introducci ´on del trabajo realizado junto con su justificaci ´on, describiendo brevemente los objetivos buscados, la planificaci ´on del proyecto y los ele- mentos obtenidos.
Cap´ıtulo 2: Se realiza un an ´alisis de la tecnolog´ıa actualmente presente en el mercado, as´ı como de otros productos relacionados o similares.
Cap´ıtulo 3: En este cap´ıtulo se hace una descripci ´on funcional del sistema, explicando los diferentes m ´odulos, librer´ıas y drivers que lo componen, as´ı como sus interrelaciones y modelo de funcionamiento.
Cap´ıtulo 4: Se entra en detalle en la descripci ´on t ´ecnica de los puntos descritps desde una perspectiva funcional en el cap´ıtulo 3.
Cap´ıtulo 5: Se realiza un an ´alisis de la viabilidad t ´ecnica de la soluci ´on, atentiendo la disponibilidad de los elementos que se desean utilizar, as´ı como su fiabilidad y manteni- bilidad.
Cap´ıtulo 6: Se describen todos los componentes empleados en la soluci ´on aportando una valoraci ´on econ ´omica de cada uno de ellos. Se distinguen dos bloques: Uno dedi- cado a los componentes f´ısicos (hardware) y un segundo apartado dedicado a las horas invertidas en documentaci ´on, pruebas y desarrollo.
Cap´ıtulo 7: Por ´ultimo, en este cap´ıtulo se realiza una autoevaluaci ´on del trabajo de- sarrollado revisando los objetivos fijados durante el curso, aspectos mejorables y una autocr´ıtica del trabajo y experiencia obtenida.
2. Antecedentes
2.1. Estado del arte
Un sistema empotrado es un conjunto de dispositivos interconectados entre si en una misma placa de circuito impreso, los cuales son gobernados por un microcontrolador central. Los site- mas empotrados son concebidos para actuar de forma equivalente a otros sitemas generales, pero en un ´ambito u objetivo muy espec´ıfico.
En el caso del sistema empotrado que nos ocupa, se trabaja sobre la plataforma ESP32, la cual tiene un grado de madurez considerable y es ampliamente utilizada en entornos de entusiastas en la tecnolog´ıa, y que ha conseguido abrirse camino en la industria en los ´ultimos a ˜nos. El hecho de que se haga tanto ´enfasis en las opciones de conectividad y que se aporte una plataforma de desarrollo tan completa como ESP-IDF hace que sea especialmente ´util en proyectos relacionados con el sector IoT, el cu ´al ha experimentado una verdadera explosi ´on en la ´ultima d ´ecada.
En cuanto a las comunicaciones, se utiliza un protocolo de comunicaciones est ´andar en la industria IoT como es MQTT, para el cual ofrecen soporte todos los proveedores de servicios en la nube como Amazon AWS, Google Cloud y Microsoft Azure. En este sentido, todos estos proveedores ofrecen soluciones espec´ıficas orientadas al sector IoT.
Por ejemplo Amazon dispone de AWS IoT, que ofrece una colecci ´on de componentes con el que se pueden cubrir una gran cantidad de escenarios garantizando la escalabilidad de un despliegue con millones de dispositivos (Figura 13).
Figura 13: Ejemplo de arquitectura con AWS IoT
Sin embargo, trabajar con uno de estos servicios implica atarse a un proveedor concreto
durante la vida del producto, ya que los elementos que utilizan no est ´an estandarizados y pasar de uno a otro no suele resultar sencillo. Por lo tanto, cuando el proyecto est ´a en la fase inicial de prototipo es mejor intentar replicar las funcionalidades con diversas soluciones basadas en software libre y ´unicamente si tiene tracci ´on y existe la previsi ´on de crecimiento suficiente es cuando debe darse el salto a utilizar este tipo de servicios.
2.2. Estudio de mercado
Existe una enorme variedad de dispositivos de medici ´on de calidad el aire en interiores con bater´ıa integrada (Figura 14), pero no tienen ning ´un tipo de conectividad y muestran toda la informaci ´on en pantalla.
Figura 14: Ejemplos de sensores de calidad del aire sin conectividad
De entre todos ellos, ´unicamente algunos realizan guardado del hist ´orico de datos, pero para obtenerlos es conectarlos a un ordenador mediante cable USB y descargarlos en forma de archivo de texto u hoja de c ´alculo. El usuario ser´ıa responsable entonces de ir subiendo peri ´odicamente estos datos a una plataforma de su elecci ´on para tener un hist ´orico, lo cual no resulta nada pr ´actico.
3. Descripci ´ on funcional
3.1. Sistema de monitorizaci ´ on de la calidad del aire
3.1.1. Requisitos del sistema
3.1.1.1 Monitorizacion de las magnitudes del sensor BME680
El programa principal del microcontrolador ha de ser capaz de realizar lecturas peri ´odicas de datos de calidad del aire del sensor BME680. Estas lecturas se realizar ´an mediante el protocolo I2C, utilizando la librer´ıa BSEC del fabricante.
3.1.1.2 Conexi ´on a Internet por Wi-Fi
El dispositivo ha de ser capaz de conectarse a Internet mediante el protocolo Wi-Fi. Tambi ´en ha de de realizar reintentos de conexi ´on en caso de que esta se pierda por cortes de luz o fallos t ´ecnicos, de forma que sea capaz de restituir sin intervenci ´on la conexi ´on a Internet.
3.1.1.3 Sincronizaci ´on horaria del dispositivo
El dispositivo ha de mantener su hora del sistema sincronizada para poder mostrar informa- ci ´on relevante en el tiempo. Para este prop ´osito se utilizar ´a el protocolo SNTP con servidores p ´ublicos.
3.1.1.4 Servidor de demostraci ´on para recepci ´on, almacenamiento y representaci ´on de datos del sensor
Se ha de preparar un servidor MQTT de referencia que permita visualizar los datos recibidos del sensor y los almacene, de modo que sea posible configurar alertas. Tambi ´en ha de ser posible visualizar gr ´aficamente estos datos mediante una p ´agina web.
Se elige para este prop ´osito una combinaci ´on de los proyectos Grafana [25], InfluxDB [27], Telegraf [41] y Mosquitto [36], lo cual permite cubrir las necesidades del proyecto. Para mayor agilidad en el desarrollo, se implementa esta colecci ´on de componentes como archivos de Docker Compose.
3.1.1.5 Env´ıo de datos del sensor por MQTT
Los datos que son le´ıdos peri ´odicamente han de ser enviados por Internet a un servidor remoto mediante el protocolo MQTT.
Se han de contemplar posibles problemas de comunicaci ´on que interrumpan temporalmente la conexi ´on a Internet, por lo que es necesario definir una l ´ogica que trabaje con una cola de datos a enviar y realice los intentos reenv´ıos pertinentes cuando la conexi ´on se restablezca. Los datos a enviar, por tanto, deber ´an ir acompa ˜nados de una marca de tiempo de cuando fueron le´ıdos para no que no se pierda informaci ´on en la parte del servidor a la hora de procesarlos.
3.1.1.6 Configuraci ´on de par ´ametros de conexi ´on Wi-Fi mediante smartphone
Para un usuario debe ser posible modificar los par ´ametros de conexi ´on Wi-Fi del dispositivo para que pueda conectarse a cualquier red de uso com ´un. Esto se debe ser posible ´unicamen- te si el dispositivo entra en un modo de configuraci ´on, el cual debe ser indicado mediante un LED. El equipo entra autom ´aticamente en este modo cuando arranca si no hay ninguna confi- guraci ´on previa, o bien puede entrar tambi ´en manualmente si el usuario mantiene presionado un bot ´on cuando arranca. Este modo tambi ´en debe estar temporizado y retornar al modo de funcionamiento normal al cabo de un tiempo si no se interact ´ua con ´el.
En este modo de configuraci ´on, el equipo debe estar listo para recibir por Bluetooth Low Energy una configuraci ´on v ´alida. Se debe soportar la aplicaci ´on oficial para tel ´efonos inteligen- tes de configuraci ´on de dispositivos Espressif ESP32.
3.1.1.7 Soporte de cambios de configuraci ´on de par ´ametros del dispositivo
El programa ha de suscribirse a topics MQTT que contengan los par ´ametros de configura- ci ´on generales del dispositivo y aplicarlos cuando se reciba un mensaje.
3.1.1.8 Configuraci ´on de par ´ametros de env´ıo de datos del dispositivo v´ıa web
El dispositivo ha de servir una p ´agina web que permita modificar los par ´ametros de confi- guraci ´on generales del dispositivo.
3.1.1.9 Funcionamiento aut ´onomo mediante bater´ıa
El sistema ha incorporar soporte para una bater´ıa que le permita continuar funcionando cuando no hay alimentaci ´on externa, as´ı como la recarga de la bater´ıa cuando s´ı que est ´e presente.
Tambi ´en ha de ser capaz de distinguir entre alimentaci ´on externa y de la bater´ıa de manera que sea posible modificar el comportamiento del sistema, as´ı como detectar el nivel de carga de la bater´ıa si est ´a presente.
Estos valores se han de enviar tambi ´en por MQTT para que se vean reflejados en el servidor y se puedan tomar acciones si es necesario.
3.1.1.10 Modo de bajo consumo
El dispositivo ha de soportar, adem ´as del modo de funcionamiento normal que se ha rea- lizado hasta este punto, un modo de funcionamiento en el que se minimice el consumo de energ´ıa, y en el cual se entrar´ıa cuando se detecte que se est ´a alimentando mediante bater´ıa.
Para ello ser ´a necesario apagar todos los perif ´ericos y el propio microcontrolador durante el mayor tiempo posible, por lo que se debe modificar el comportamiento del protocolo de lectura y env´ıo de datos, as´ı como par ´ametros adicionales que distingan entre los dos modos de funcionamiento.
3.1.1.11 Soporte de TLS para el env´ıo de datos por MQTT
El programa principal del microcontrolador debe soportar conexiones TLS para realizar el env´ıo de datos por MQTT de forma segura. Estos certificados deben poder ser modificables tanto en tiempo de fabricaci ´on como de ejecuci ´on para dar m ´axima flexibilidad.
3.1.1.12 Configuraci ´on de par ´ametros de env´ıo y lectura de datos directa mediante smartphone
Los par ´ametros de configuraci ´on del protocolo de env´ıo de datos del dispositivo han de ser directamente accesibles y configurables con un tel ´efono inteligente mediante Bluetooth Low Energy. Tambi ´en han de ser posibles del mismo protocolo las lecturas de los los valores de los sensores.
Para conseguir esto ser ´a necesario definir un perfil GATT espec´ıfico del dispositivo.
3.1.1.13 Dise ˜no, fabricaci ´on y montaje de placa de circuito integrado
Se ha de dise ˜nar una placa de circuito integrado que contenga todos los elementos con los que se ha realizado el proyecto. La fabricaci ´on y montaje de componentes se externalizar ´a a una empresa que ofrezca estos servicios.
3.1.2. Dise ˜no, y prototipado de caja de pl ´astico del dispositivo
Se ha de dise ˜nar una caja sencilla que envuelva la placa de circuito integrado dise ˜nada, as´ı como realizar un prototipo mediante impresi ´on 3D.
3.1.3. Diagrama de bloques del sistema
Figura 15: Diagrama de bloques del sistema
3.2. Servidor de almacenamiento y visualizaci ´ on de datos
Como puede observarse en la figura 15 la parte de servidor del proyecto se implementa utilizando conjuntamente cuatro componentes de software con responsabilidades bien diferen- ciadas, pero que son comunmente utilizados para resolver problemas de este tipo.
3.2.1. Mosquitto
Se trata de un broker MQTT, es decir, el servidor que tiene el rol de recibir las conexiones de los clientes MQTT y distrubir los mensajes recibidos a cada uno de ellos en funci ´on del inter ´es que hayan mostrado los mismos al suscribirse a diferentes tiposo de mensajes utilizando topics.
Es una de las implementaciones m ´as utilizadas en el mercado, ya que est ´a desarrollado por la Fundaci ´on Eclipse, la cual es una de las grandes impulsoras del ecosistema MQTT.
Esto se debe a su sensillez y liviano tama ˜no, pero sin sacrificar flexibilidad ya que soporta pr ´acticamente todas las caracter´ısticas disponibles del protocolo.
El ´unico punto en el que queda eclipsado por sus competidores es en la escalabilidad en entornos de millones de conexiones concurrentes, pero al tratarse esta parte del proyecto de un servidor ´unicamente de demostraci ´on para unos pocos dispositivos, cumple perfectamente su funci ´on.
3.2.2. InfluxDB
Es la base de datos de series temporales de referencia en el mercado. Esto significa que almacena los datos junto a una etiqueta de tiempo y est ´a especializada en hacer consultas relativas a los datos almacenados en base a criterios temporales.
Esto es especialmente interesante en un proyecto como el que nos ocupa, ya que las lec- turas de los sensores que generan los dispositivos se realizan en un momento concreto del tiempo, y esta informaci ´on es especialmente relevante a la hora de visualizar y analizar el com- portamiento de las variables que los sensores miden.
3.2.3. Telegraf
Se trata de un software de la familia InfluxDB que hace de puente entre distintas fuentes de datos e InfluxDB. Entre las fuentes de datos soportadas se encuentran peticiones HTTP, logs de sistema o, como en el caso que nos interesa, mensajes MQTT. Estos mensajes recibidos de la fuente de datos seleccionada son entonces traducidos al protocolo interno de InfluxDB e insertados en la base de datos.
De esta manera se logra una gran compatibilidad entre fuentes de datos diversas e InfluxDB, ya que Telegraf permite una enorme flexibilidad a la hora de ser configurado para realizar sus traducciones. Afortunadamente, el caso que nos ocupa es bien sencillo y se trata de realizar una traducci ´on directa de los mensajes MQTT con las lecturas en formato JSON al formato de InfluxDB.
3.2.4. Grafana
Es un software especializado en la visualizaci ´on de datos y que es capaz de tomar como fuente una variedad de bases de datos, entre la que destaca InfluxDB como una de las m ´as utilizadas.
La visualizaci ´on es completamente configurable, disponiendo de m ´ultiples tipos de elemen- tos de visualizaci ´on en los que se pueden definir las consultas de bases de datos relacionadas con cada elemento de forma individual. Una colecci ´on de elementos de visualizaci ´on se llama- da dashboard.
Para este proyecto se ha implementado un dashboard que permite visualizar la evoluci ´on de todos los datos enviados por el dispositivo (Figura 16).
Figura 16: Dashboard Grafana del proyecto
3.3. Dispositivo de medici ´ on de calidad del aire
3.3.1. Esquema el ´ectrico general
Figura 17: Esquema el ´ectrico general del dispositivo
3.3.2. Esquema de prototipo en breadboard
Durante la fase de desarrollo del proyecto, se trabaja con los elementos de hardware en una breadboard para mayor facilidad de prototipado (Figura 18), a ˜nadiendo un interruptor a una
GPIO que permite simular cambios en la se ˜nal de alimentaci ´on externa sin cortar la conexi ´on con el dispositivo. Esto es necesario porque el cable Micro-USB que se utiliza para realizar la depuraci ´on alimenta la placa ESP32, por lo que ser´ıa imposible realizar depuraci ´on del sistema en modo bajo consumo sin recompilar la aplicaci ´on.
Figura 18: Esquema del prototipo en breadboard
3.3.3. Arquitectura de software
Figura 19: Arquitectura de software del dispositivo
33
4. Descripci ´ on detallada
4.1. Descripci ´ on del hardware
4.1.1. Espressif ESP32
El Espressif ESP32 implementa una arquitectura de tipo System on Chip, en adelante SoC, que integra la CPU, RAM, Wi-Fi, Bluetooth, coprocesadores especializados y controladores de perif ´ericos en un ´unico chip.
Los elementos contenidos en el SoC mostrados en la figura 20 son los siguientes:
Dos n ´ucleos Xtensa LX6 de 32 bit, llamados PRO CPU y APP CPU, con una frecuencia m ´axima de 240 Mhz.
Subistema RTC1con co-procesador Ultra Low Power (ULP).
448 KiB de ROM y 530 KiB de SRAM.
8 KiB de RTC SLOW SRAM y 8 KiB de RTC SLOW SRAM.
1Kb de memoria eFuse.
Perif ´ericos de radiofrecuencia: Wi-Fi 802.11 b/g/e/i, Bluetooth 4.2 y Bluetooth Low Energy.
Perif ´ericos de entrada/salida: SPI, UART, I2C, Ethernet, ADC (Analog to Digital Conver- ter ), DAC (Digital to Analog Converter ), sensores t ´actiles capacitivos, PWM (Pulse Width Modulation), etc.
Acelerador criptogr ´afico para SHA-256, AES, RSA y RNG.
Figura 20: Diagrama de bloques del ESP32 [43]
1Espressif utiliza la palabra RTC para referise al subsistema de bajo consumo al completo, no se refiere ´unicamente a un Real-Time Clock
Por su parte, la memoria flash disponible puede estar empotrada dentro del SoC o conec- tada externamente a trav ´es de SPI. Normalmente los m ´odulos ESP32 tienen 2, 4 u 8 MB de memoria flash externa.
4.1.1.1 Memoria
En cuanto a la memoria del sistema, el ESP32 utiliza una arquitectura Harvard [20] que separa la memoria de datos e instrucciones. El SoC contiene una System ROM interna, IRAM (RAM de instrucciones), DRAM (RAM de datos), memoria fast RTC de instrucciones y memoria slow RTC de datos. Adicionalmente hay regiones de la memoria flash utilizadas para guardar datos (DROM) e instrucciones (IROM).
Figura 21: Regiones de memoria del ESP32 [21]
System ROM: La ROM integrada en el SoC se utiliza para el bootloader de primer orden y otros componentes del sistema. No es accesible para las aplicaciones que corren en el ESP32.
IRAM (SRAM): Es utilizada para las cach ´es de la PRO CPU y APP CPU, partes del com- ponente Wi-Fi, gestores de interrupciones y c ´odigo que sea utilizado con alta frecuencia y cuyo rendimiento sea relevante.
IROM (Flash): El c ´odigo que no sea expl´ıcitamente colocado en tiempo de compilaci ´on en IRAM o memoria RTC se guarda en la memoria flash. El MMU del controlador de memoria Flash se encarga de relacionar las direcciones de memoria al rango de IROM.
Esta memoria es de solo lectura.
DRAM (SRAM): Los datos est ´aticos no constantes y los datos inicializados a cero son co- locados aqu´ı por el linker. El espacio que quede libre se utiliza como memoria heap para ser reservado din ´amicamente en tiempo de ejecuci ´on. Si se utiliza el perif ´erico Bluetooth, parte de DRAM queda reservada y no est ´a disponible para el c ´odigo de la aplicaci ´on.
DROM (Flash): Los datos constantes exceptuando los literales transformados por el com- pilador en c ´odigo son colocados en DROM.
External SPI RAM (SRAM): El ESP32 soporta hasta 8 MB de memoria SRAM externa conectada utilizando SPI. Esta memoria extiende DRAM y es utilizada para memoria heap reservada din ´amicamente. Utiliza las mismas regiones de cache que la memoria flash.
Fast Instructions RTC Memory (SRAM): Utilizada por c ´odigo que ha de correr en la PRO CPU tras despetar de modo deep sleep. Solamente es accesible para la PRO CPU.
Slow Data RTC Memory (SRAM): Las variables globales y est ´aticas utilizadas por el coprocesador ULP en modo deep sleep son colocadas aqu´ı. Solamente es accesible para la PRO CPU.
Tal y como se ha mencionado anteriormente y como se resume en la tabla 2, no todas las regiones de memoria son accesibles por todos los n ´ucleos del ESP32, y tampoco se programan del mismo modo, ya que el co-procesador ULP es de muy bajo nivel y ´unicamente se puede programar en ensamblador.
Procesador Lenguaje de programaci ´on Frecuencia de reloj
Regiones de memoria accesibles RTC RTC External Internal SLOW FAST SPI RAM RAM
4 KB 8 KB 4 MB 512 KB
Core 0 (PRO CPU) C 240 MHz ✓ ✓ ✓ ✓
Core 1 (APP CPU) C 240 MHz ✓ ✓
ULP Ensamblador 8 MHz ✓
Tabla 2: Comparaci ´on de los tres procesadores del ESP32: Core 0, Core 1 y co-procesador ULP.
4.1.1.2 Bajo consumo
Con respecto al consumo energ ´etico del microcontrolador, existe la posibilidad de desactivar los perif ´ericos de radio cuando no se est ´an utilizando, y adicionalmente se ofrecen dos modos de bajo consumo: light sleep y deep sleep.
En deep sleep tan s ´olo permanecen despiertos los perif ´ericos RTC, el ULP y la regi ´on de memoria RTC (slow y fast). Por otra parte, en light sleep los perif ´ericos digitales, y parte de la RAM y la CPU tambi ´en estar ´an despiertos en estado clock-gated, que es una t ´ecnica utilizada para reducir el consumo energ ´etico (Figura 22).
Al despertarse de light sleep el ESP32 preserva su estado, puesto que hay retenci ´on de RAM. Sin embargo, despertarse de deep sleep es a efectos pr ´acticos similar a un reset, ya que todo lo que no estuviera guardado en la regi ´on RTC de memoria se perder ´a (Figura 22).
Figura 22: Comparaci ´on entre light sleep y deep sleep
En la tabla 3 se presenta un resumen de los consumos de corriente habituales en los dife- rentes modos de funcionamiento del ESP32.
Consumo de corriente Modo
160 - 260 mA Todos los perif ´ericos activos
3 - 20 mA Perif ´ericos de radiofrecuencia apagados
0.8 mA light sleep
0.15 mA deep sleep utilizando ULP
10 µA deep sleep
Tabla 3: Consumo de corriente del ESP32. [34]
.
4.1.2. Olimex ESP32-DevKit-LiPo
Se trata de una placa compatible a nivel de pines (Figura 23) con el kit de desarrollo oficial de Espressif ESP32-DevKitC que a ˜nade un cargador de bater´ıas Li-Po, as´ı como la capacidad de obtener la alimentaci ´on desde la misma.
Figura 23: Resumen de pines de Olimex ESP32-Devkit-Lipo
El fabricante de esta placa suscribe el movimiento OSHW [39], por lo que todos los archivos de dise ˜no est ´an disponibles de forma abierta para ser consultados y modificados [24]. Esto fa- cilita enormemente su integraci ´on con proyectos existentes, y tambi ´en ofrece un valor did ´actico inestimable.
Para este proyecto resulta de especial inter ´es lo relativo al funcionamiento de la bater´ıa, pues existen requisitos que requieren la detecci ´on del origen de alimentaci ´on de la placa, bien sea alimentaci ´on externa o procedente de la bater´ıa. Del mismo modo, tambi ´en es necesario poder realizar alguna estimaci ´on del nivel de bater´ıa para poder estimar realizar estimaciones de duraci ´on.
Tal y como se puede observar en la figura 24, el dise ˜no de la placa contempla estos requi- sitos mediante la utilizaci ´on de divisores resistivos entre la tensi ´on de alimentaci ´on externa y la tensi ´on de alimentaci ´on de bater´ıa.
Figura 24: Esquem ´atico de detecci ´on de bater´ıa y voltaje de Olimex ESP32-Devkit-LiPo
En el caso de la detecci ´on de alimentaci ´on externa, este divisor resisitivo sirve para adaptar el nivel de tensi ´on procedente de la alimentaci ´on externa (5V) al nivel m ´aximo admitido por el microcontrolador ESP32 (3.3V). La salida de este divisor resistivo se conecta entonces direc- tamente a la GPIO39 del microcontrolador, con lo que con una simple detecci ´on de entrada digital es posible detectar la presencia o ausencia de alimentaci ´on externa.
Por su parte, con respecto a la detecci ´on del voltaje de bater´ıa el valor de salida se utiliza como una entrada anal ´ogica en GPIO35 por parte del microcontrolador. Puesto que el rango de tensi ´on admitido por el ADC del ESP32 es de de 0 a 2450 mV, el divisor resisitivo simplemente divide la tensi ´on de entrada de bater´ıa por dos, ya que as´ı el valor m ´aximo de entrada (4.2V) queda dentro del rango.
Merece la pena observar que los elementos descritos no est ´an activos de f ´abrica, ya que se encuentran tras jumpers SMT que es necesario soldar. Esto es debido a que estos divisores resistivos generan una carga el ´ectrica que ser´ıa indeseable en aplicaciones que no necesiten estas funcionalidades.
Por otro lado, con respecto a la detecci ´on de voltaje de bater´ıa la relaci ´on entre tensi ´on y capacidad de carga no resulta evidente, ya que se trata de un asunto complejo [5]. La curva de descarga de una bater´ıa Li-Po no es lineal tal y como se puede observar en la figura 25, y su comportamiento es altamente dependiente tambi ´en de la temperatura ambiental.
Figura 25: Curva de descarga de bater´ıas Li-Po [5]
Puesto que cualquier c ´alculo preciso del nivel de bater´ıa se encuentra fuera del alcance del proyecto, nos limitamos a utilizar un valor umbral de tensi ´on arbitrario que simplemente indique que la bater´ıa est ´a baja cuando la lectura quede por debajo. Un valor de umbral t´ıpico ser´ıa 3.5V [5], pero esto puede variar en funci ´on de las condiciones climatol ´ogicas de la instalaci ´on y el modelo concreto de bater´ıa utilizado.
4.1.3. BME680
El BME680 es un sensor digital 4 en 1 capaz de detectar gases, humedad, presi ´on at- mosf ´erica y temperatura (figura 26). El m ´odulo sensor se encuentra en el interior de un paquete Land Grid Array compacto con unas dimensiones de 3.0 mm x 3.0 mm x 0.93 mm, mientras que su rango de tensi ´on de alimentaci ´on admitido es de 1.71 a 3.6V. Algunas de sus aplicaciones son la medida de calidad del aire, dom ´otica, IoT y previsi ´on meteorol ´ogica [2].
Figura 26: BME680
El m ´odulo soporta dos modos de funcionamiento de bajo consumo: sleep y forced. En modo sleep no se realiza ninguna medida de ning ´un sensor, reduciendo as´ı el consumo energ ´etico
del dispositivo. Por su parte, en el modo forced se realiza secuencialmente una medida de los sensores de temperatura, presi ´on atmosf ´erica, humedad y gas, en ese orden, y una vez finalizada el m ´odulo regresa a modo sleep. La tabla 4 muestra el consumo de corriente para cada una de estas medidas bajo ciertas condiciones. Las interfaces digitales de las que dispone el m ´odulo son I2C (hasta 3.4 MHz) y SPI (3 y 4 hilos, hasta 10 MHz).
Consumo de corriente Condiciones
2.1 µA Sensores de humedad y temperatura a 1 Hz 3.1 µA Sensores de presi ´on y temperatura a 1 Hz 3.7 µA Sensores de humedad, presi ´on y temperatura a 1 Hz 0.09-12 mA Todos los sensores, dependiendo del modo de funcionamiento
0.15 µA En modo sleep
Tabla 4: Consumo de corriente del BME680.
.
La secuencia de medida de los cuatro sensores se realiza con un sobremuestreo configu- rable, y adicionalmente incluye una fase de calentamiento para la l ´amina utilizada para realizar le medida del sensor de gas a una temperatura objetivo, t´ıpicamente entre 200◦C y 400◦C, la cual es mantenida hasta la finalizaci ´on de la medida de este sensor.
Las medidas de presi ´on y temperatura pasan a trav ´es del Infinite Impulse Response (IIR), que filtra las perturbaciones de corta duraci ´on causadas por factores externos, como un soplido directamente sobre el m ´odulo o el cierre brusco de una puerta. En el caso de los sensores de humedad y gas, este filtro IIR no se aplica porque sus respectivos valores no oscilan r ´apida- mente.
El sensor de gas es de tipo metal- ´oxido y detecta Volatile Organic Compounds (Compuestos org ´anicos vol ´atiles), en adelante VOC, mediante la absorci ´on y oxidaci ´on de una l ´amina sensi- ble. Este elemento sensible est ´a dise ˜nado para detectar los VOC procedentes de las pinturas, lacas, decapantes, productos de limpieza, barnices, adhesivos y alcohol, entre otros.
La se ˜nal de salida es un valor de resistencia que cambia con la variaci ´on de la concentra- ci ´on de VOC presentes en el aire: Cuanto m ´as alta es la concentraci ´on de VOC, m ´as baja la resistencia, y viceversa. Esto significa que si la calidad del aire es mala, la concentraci ´on de VOC es alta, y por tanto la resistencia del elemento sensible se reduce. Esta se ˜nal en crudo es convertida a un valor de IAQ por los algoritmos propietarios de la librer´ıa Bosch Software Environmental Cluster (BSEC) [2].
Cuando la calidad del aire es buena, el Ox´ıgeno es absorbido por la superficie de la l ´amina de metal- ´oxido, que atra electrones libres hacia su superficie formando una barrera de poten- cial. Esta barrera previene el flujo de electrones e incrementa la resistencia (Figura 27a). En la presencia de VOC, el Ox´ıgeno reacciona con los gases y la barrera de potencial no se forma y, en consecuencia, los electrones fluyen libremente y la resistencia disminuye (Figura 27b).
(a) Aire limpio - alta resistencia
(b) Aire sucio - alta resistencia
Figura 27: Resistencia de un sensor de metal- ´oxido [22]
En cuanto a su utilizaci ´on, el fabricante ofrece un framework que permite realizar opera- ciones de alto nivel sobre el m ´odulo, como pueda ser obtener la lectura de cada uno de los sensores de forma peri ´odica. Este software se detalla en la secci ´on 4.2.1.
4.1.4. PCB del proyecto
Si el presente proyecto perteneciese a la rama del conocimiento de la Ingenier´ıa Electr ´onica, se podr´ıa hacer un dise ˜no de PCB ambicioso que integrase los componentes relevantes de las placas Olimex ESP32-Devkit-LiPo y Adafruit BME680 en una sola, pero para centrar el alcance se opta por realizar un dise ˜no que simplemente ofrezca una base com ´un para conectar ambas con las pistas y componentes m´ınimos para lograrlo.
4.1.4.1 Dise ˜no
Este dise ˜no se ha realizado mediante la herramienta de dise ˜no de software libre KiCAD, y ha sido necesario generar huellas y s´ımbolos tanto para la placa Olimex ESP32-Devkit-LiPo y Adafruit BME680, ya que no exist´ıan de manera sencilla, aislada y reaprovechable.
Como se puede observar en la figura 28, se trata de un dise ˜no sencillo en el que ´unicamente
se aportan dos LED para indicar el estado de conexi ´on Wi-Fi, un bot ´on para forzar el modo de configuraci ´on Wi-Fi. Adem ´as tambi ´en se ha a ˜nadido un cristal oscilador de 32 KHz que se puede activar opcionalmente para mejorar el comportamiento del subsistema RTC cuando el microcontrolador encuentra en los modos light sleep y deep sleep [21].
Figura 28: Esquem ´atico de PCB
Por otra parte, con respecto a la distribuci ´on de componentes y trazado de pistas en la PCB (Figura 29), se utiliza un plano de masa en la cara inferior y se colocan todos los componentes en la cara superior. Se a ˜naden tambi ´en agujeros de montaje en las esquinas para facilitar su colocaci ´on en una caja hecha a medida.
Figura 29: Dise ˜no de PCB
Como parte del dise ˜no se genera tambi ´en una lista de materiales necesaria para el proceso de fabricaci ´on (Tabla 5).
Componente Huella Referencia de proveedor LCSC Comentario
C1, C2 0606 C1634 10 pF
D1 0606 C72043 Green LED
D2 0606 C72041 Blue LED
R1 0606 C22808 150 Ω
R2 0606 C23182 47 Ω
R3 0606 C7250 10M Ω
SW1 SMD C318884 Push button
Y1 SMD3215 C32346 32.768 KHz
Tabla 5: Lista de materiales de PCB
4.1.4.2 Fabricaci ´on y montaje
La fabricaci ´on y montaje de la PCB se externaliza a un servicio externo, puesto que aun- que se trata de una PCB sencilla se utilizan componentes de peque ˜no tama ˜no que requieren maquinaria altamente especializada. Si bien se pod´ıa haber realizado un dise ˜no basado en componentes que fuesen soldables manualmente, trabajar de este modo tiene la ventaja de que ser´ıa mucho m ´as sencillo escalar la producci ´on a partir del prototipo a las unidades que fuesen necesarias.
El proveedor utilizado para este proyecto es JLCPCB [30], que est ´a ubicado en la Rep ´ublica Popular China y ofrece tanto el servicio de fabricaci ´on de PCB como el montaje de componen- tes en superficie (SMT).
El proceso de fabricaci ´on est ´a completamente automatizado, teniendo ´unicamente que re- llenar un formulario en su p ´agina web (Figura 30) y enviar los archivos de dise ˜no Gerber y lista de materiales. El propio proveedor ofrece gu´ıas para generar estos archivos en el formato requerido mediante la herramienta de dise ˜no KiCAD [31] [32], entre otras.
Figura 30: Nuevo pedido en JLCPCB
Una vez realizado el pedido, existe la posibilidad de seguir su evoluci ´on (Figura 31) a lo largo de todo el proceso de fabricaci ´on y montaje, hasta que se produzca su env´ıo una vez finalizado.
Figura 31: Estado de pedido en JLCPCB
4.2. Software del sistema
4.2.1. Bosch Software Environmental Cluster (BSEC)
El software BSEC proporcionado por el fabricante est ´a dise ˜nado para trabajar con los cuatro sensores integrados dentro del BME680, y est ´a basado un un algoritmo inteligente que ofrece una salida de IAQ. Los valores de esta salida se encuentran entre 0 (aire limpio) y 500 (aire altamente contaminado) para indicar y cuantificar la calidad del aire cercano al sensor (Figura 32).
Figura 32: Clasificaci ´on de IAQ y c ´odigo de colores [2]
4.2.1.1 Configuraci ´on
En primer lugar, para poder utilizar la librer´ıa BSEC es necesario aplicar una configuraci ´on, que resulta de realizar una combinaci ´on de los siguientes par ´ametros [28]:
Tensi ´on de alimentaci ´on del sensor BME680:
