Aventura de hardware: Creando el prototipo de pikoAQI

Introducción

Quería meterme en un proyecto de hardware, pero no tenía ni idea de electrónica ni de componentes. Así que me lancé a la piscina con la idea de ir aprendiendo por el camino, sabiendo que la IA me echaría un cable.

El proyecto consiste en un sensor de calidad del aire portátil (o wearable). Lo elegí porque me hacía falta uno y porque tiene el nivel de dificultad perfecto: no hay que investigar ni desarrollar los sensores desde cero (porque ya existen), pero tampoco es pan comido, ya que hay que integrar varias funciones en un formato compacto y con un consumo de energía muy bajo.

Pidiendo las piezas del prototipo

Para arrancar, le conté mi idea a Claude (la IA), que me ayudó a hacer una lluvia de ideas y a elegir los componentes electrónicos.

Este fue mi primer pedido a la tienda de electrónica:

Por qué elegí estos componentes

• ESP32: un microcontrolador básico pero muy capaz. Incluye WiFi y Bluetooth de serie, es muy pequeño y tiene potencia de sobra para un entorno de producción.
• Pantalla de tinta electrónica: gasta poquísima energía. Solo consume cuando actualiza la imagen; cuando se apaga, la última imagen se queda fijada.
• Módulo GPS: para las funciones básicas de localización.
• Sensor de calidad del aire (SDS011): mide las partículas suspendidas en el aire (PM2.5 y PM10).
• Sensores BME280/BME680: miden temperatura, presión, humedad y compuestos orgánicos volátiles (COV).

Trasteando con la pantalla de tinta electrónica

Lo primero que probé fue la pantalla. El modelo que compré no traía documentación técnica, solo un ejemplo para Arduino. Se lo pasé a Cursor como contexto y logró hacerlo funcionar en mi código.

La pantalla se comunica por SPI. Se supone que la placa ESP32 ya incluye una implementación nativa de SPI, pero no fui capaz de hacer que se entendiera con la pantalla, así que tiré de la implementación personalizada del ejemplo de la documentación.

El problema de la tinta electrónica es la tasa de refresco: es lentísima, y actualizar toda la pantalla puede tardar hasta 2 segundos.

La pantalla tiene dos modos: actualización parcial y refresco completo. El primero es más rápido porque no tiene que borrar y redibujar toda la pantalla. Lo usé para montarme un modo de refresco «rápido»:

1. Actualización parcial con una pantalla totalmente en blanco para borrar la imagen actual.
2. Actualización parcial para dibujar la imagen nueva.

Puede quedar algo de rastro (el famoso efecto fantasma), así que este modo rápido solo vale para casos donde ese pequeño residuo visual no moleste.

Tiempos medidos:

• Refresco completo: 2 segundos
• Refresco «rápido»: 1,1 segundos

Lo que aprendí

• Hay distintos modos de mostrar una imagen (actualización parcial o completa).
• Las pantallas de tinta electrónica son muy lentas renderizando el contenido.
• Esta pantalla me hace el apaño de momento, pero seguro que puedo encontrar algo más barato y rápido.
• Todavía me queda investigar por qué el SPI nativo no funciona con ella.

Trabajando con el GPS

Con el GPS todo fue mucho más fluido. Claude me dijo exactamente cómo cablearlo, y la documentación apuntaba directamente a la librería TinyGPS++.

Además, el chip GPS tiene unos ledes físicos (POWER y PPS) que me facilitaron mucho la vida a la hora de depurar. En mi primer intento, no lo había alimentado bien (un problema de cables).

Al principio me volví loco porque no recibía datos de ubicación, hasta que descubrí que el GPS necesita sincronizarse primero. Ese arranque inicial en frío puede eternizarse (más de 5 minutos). En mi caso tardó aún más, seguramente porque la señal en mi cuarto es pésima.

Una vez que el GPS consigue señal, el led PPS parpadea una vez por segundo. Fue una forma muy gráfica de confirmar que la falta de datos no era un fallo de mi código: el GPS simplemente estaba buscando cobertura.

El GPS que compré va a 10 Hz (lo normal es 1 Hz) y está pensado para drones. No necesito tanto rendimiento. Lo que sí necesito es que sea muy preciso (incluso en interiores) y más barato. Para el próximo prototipo buscaré algo que se ajuste mejor.

Lo que aprendí

• El GPS se toma su tiempo para sincronizar: varios minutos si arranca en frío, y más de 30 segundos si ya estaba caliente.
• No me hace falta un GPS de 1 a 10 Hz, no estoy construyendo un avión ni nada que se mueva rápido.
• Necesito un GPS que responda mejor en interiores.
• Toca buscar una alternativa más barata y potente.

El reto del BME680 (sensor de aire)

Me costó sudores conseguir que el sensor se comunicara. Cursor no fue capaz de sacar una implementación que funcionara, ni siquiera con ejemplos. Por suerte, la gente de Adafruit tiene una librería específica para este sensor, así que eché mano de ella. Hacen librerías para un montón de sensores diferentes, es todo un lujo.

El sensor de COV tiene miga: necesita calibrarse y al principio los valores pegan unos bandazos tremendos, así que los datos solo son fiables tras 48 horas de uso. Esto va a ser un dolor de cabeza para integrarlo en un producto final, porque el usuario no puede calibrarlo fácilmente. Tendré que cruzar los datos con los de otros sensores para validarlos.

Lo que aprendí

• El sensor de COV necesita calibración. Aún no tengo claro cómo gestionar esto de cara al usuario final; igual solo lo uso para detectar variaciones y no valores absolutos.

La batería

Estuve mirando baterías LiPo y de iones de litio. El formato LiPo es muchísimo mejor y es el que se usa en wearables (e incluso en portátiles y móviles) cuando el tamaño y el peso mandan.

El problema es que la mayoría de las baterías LiPo sacan 3,7 V, y mi ESP32 funciona a 5 V. Podría meterle un elevador de tensión, pero eso complicaría el circuito y haría que perdiera eficiencia energética.

Además, las baterías no son un juego: son muy sensibles a los golpes y una celda LiPo puede salir ardiendo si se pincha, se calienta demasiado o se descarga por debajo de su límite.

Así que, de momento, he tirado por la calle de en medio y estoy usando una batería externa (un power bank de toda la vida) con un cable USB-C.

Lo que aprendí

• La mayoría de las baterías LiPo pequeñas funcionan a 3,7 V.
• Hay que tomarse muy en serio las normas de seguridad al trastear con baterías.

Implementación del software

También he estado dándole caña a la parte del software y a la sincronización de datos.

La idea es que el ESP32 haga de servidor Bluetooth Low Energy (BLE), y que un cliente en el ordenador recoja los datos.

Al principio no podía ni subir el código al microcontrolador porque pesaba demasiado. Tras investigar un poco, me di cuenta de que la librería BLE por defecto no tiene nada de ligera: ¡se comía el 75 % de la memoria flash! Me pasé a NimBLE, que pesa más o menos la mitad. La única pega es que solo soporta BLE y no el Bluetooth clásico, pero me viene de perlas porque no pensaba usar el clásico de todas formas.

¡No te pierdas las próximas actualizaciones mientras sigo puliendo el sensor portátil pikoAQI!