Carnet de bord hardware : conception du prototype pikoAQI

Intro

Je voulais me lancer dans un projet hardware, sans la moindre compétence technique en électronique. J'ai donc démarré ce projet pour apprendre sur le tas, en sachant que l'IA pourrait m'épauler.

Il s'agit d'un capteur de qualité de l'air portable (wearable). Je l'ai choisi parce que j'en avais besoin, mais aussi pour son dosage parfait de la difficulté : inutile de faire de la R&D sur les capteurs puisqu'ils existent déjà, mais le défi reste entier. Il faut en effet faire cohabiter plusieurs fonctionnalités dans un format compact, le tout en maîtrisant la consommation d'énergie.

Commander les pièces du prototype

Pour démarrer, j'ai pitché mon projet à Claude (l'IA), qui m'a aidé à affiner mes idées et à sélectionner les composants électroniques.

Voici ma première commande passée en boutique d'électronique :

Pourquoi ces composants ?

• ESP32 : un microcontrôleur d'entrée de gamme mais très performant. Il intègre le WiFi et le Bluetooth, reste compact et offre assez de puissance de calcul pour un usage en production.
• Écran E-ink : une consommation d'énergie quasi nulle. Il ne tire sur la batterie que lors des rafraîchissements et conserve l'image même éteint.
• Module GPS : pour le suivi de base de la position géographique.
• Capteur de qualité de l'air (SDS011) : détecte les particules fines (PM2.5, PM10) en suspension dans l'air.
• Capteurs BME280/BME680 : mesurent la température, la pression atmosphérique, l'humidité et les composés organiques volatils (COV).

Apprivoiser l'écran e-ink

Le premier composant que j'ai testé est l'écran e-ink. Le modèle que j'ai commandé est livré sans aucune documentation technique, avec pour seul guide un exemple Arduino. J'ai fourni ce bout de code à Cursor en guise de contexte, et l'IA a réussi à le faire tourner dans mon projet.

L'écran communique via l'interface SPI. La carte ESP32 est censée embarquer une implémentation SPI native, mais impossible de la faire dialoguer avec l'écran. J'ai donc conservé l'implémentation SPI sur mesure trouvée dans l'exemple de la doc.

Le talon d'Achille de l'e-ink, c'est son taux de rafraîchissement : c'est extrêmement lent, et un réaffichage complet peut prendre jusqu'à 2 secondes.

L'écran propose deux modes : la « mise à jour partielle » et le « rafraîchissement complet ». La mise à jour partielle est bien plus rapide car elle ne réinitialise pas tout l'affichage. Je m'en suis servi pour bidouiller un mode de rafraîchissement « rapide » :

1. Mise à jour partielle avec un écran tout blanc pour effacer l'image en cours
2. Mise à jour partielle pour peindre la nouvelle image

Un effet de ghosting (images fantômes) peut subsister. Ce mode rapide est donc réservé aux cas où ces légères traces ne sont pas dérangeantes.

Tests de performance :

• Rafraîchissement complet : 2 secondes
• Rafraîchissement « rapide » : 1,1 seconde

Ce que j'ai appris

• Il existe plusieurs modes pour afficher une image (mise à jour partielle / complète).
• Les écrans e-ink sont très lents au rendu.
• Ce modèle fait l'affaire pour l'instant, mais je peux sans doute trouver moins cher et plus réactif.
• Il faut que je creuse pour comprendre pourquoi le SPI natif refuse de fonctionner avec cet écran.

Intégration du GPS

Le GPS s'est révélé beaucoup plus docile. Claude a tout de suite su comment le câbler, et la doc m'a redirigé vers la bibliothèque TinyGPS++.

Les LED physiques de la puce (POWER et PPS) m'ont aussi grandement simplifié le débogage. Lors de mon premier essai, le GPS était mal alimenté (un bête problème de câblage).

Au début, je ne comprenais pas pourquoi je ne recevais aucune donnée de localisation. J'ai vite appris que le GPS a besoin de se synchroniser, et que ce premier démarrage à froid peut être très long (parfois plus de 5 minutes). Chez moi, ça a pris encore plus de temps, probablement parce que le signal capte très mal dans ma chambre.

Une fois le signal accroché, la LED PPS se met à clignoter exactement une fois par seconde. C'est un excellent indicateur visuel pour comprendre que l'absence de données ne venait pas de mon code : le GPS cherchait juste ses satellites.

Le module GPS que j'ai acheté tourne à 10 Hz (contre 1 Hz pour des modèles classiques) car il est conçu pour les drones. Je n'ai clairement pas besoin d'une telle fréquence. Ce qu'il me faut en revanche, c'est une précision chirurgicale, y compris en intérieur, et un prix plus doux. Je viserai une référence plus adaptée pour le prochain prototype.

Ce que j'ai appris

• Un GPS prend son temps pour se synchroniser : plusieurs minutes lors d'un démarrage à froid, plus de 30 secondes à chaud.
• Un taux de rafraîchissement de 10 Hz est superflu, je ne fabrique ni un avion ni un appareil hyper-rapide.
• J'ai besoin d'un capteur bien plus performant en intérieur.
• Je dois chercher une alternative à la fois moins chère et plus réceptive.

Câblage du BME680 (capteur d'air)

Faire communiquer ce capteur a été une vraie galère. Cursor n'a pas réussi à pondre une implémentation fonctionnelle, même en s'appuyant sur des exemples. Par chance, Adafruit a développé une bibliothèque spécifique pour ce modèle, que je me suis empressé d'utiliser. Ils proposent des bibliothèques pour une tonne de capteurs différents, c'est vraiment très pratique.

Le capteur de COV nécessite un étalonnage et fluctue pas mal au début. Les valeurs ne deviennent fiables qu'après les premières 48 heures d'utilisation. Ça s'annonce compliqué à intégrer dans un produit final, car on ne peut pas demander aux utilisateurs de le calibrer eux-mêmes. Il faudra que je croise ses données avec d'autres capteurs pour les valider.

Ce que j'ai appris

• Le capteur de COV a besoin d'être calibré. Je ne sais pas encore comment gérer ça côté utilisateur ; je m'en servirai peut-être uniquement pour suivre les variations globales.

La batterie

Je me suis penché sur les batteries LiPo et Li-Ion. Le format LiPo est bien plus intéressant, c'est d'ailleurs ce qu'on retrouve dans tous les appareils portables où l'encombrement et le poids sont critiques (ordinateurs portables, smartphones).

Le hic, c'est que la plupart des LiPo sortent du 3,7 V, alors que ma carte ESP32 attend du 5 V. Je pourrais utiliser un amplificateur de tension, mais cela rajoute de la complexité et gaspille bêtement de l'énergie.

De plus, les batteries ne sont pas à prendre à la légère : elles sont extrêmement sensibles aux dommages physiques. Une cellule LiPo peut prendre feu si elle est percée, en surchauffe, trop déchargée, etc.

Pour l'instant, je me contente donc d'une batterie externe classique branchée avec un câble USB-C.

Ce que j'ai appris

• La majorité des petites batteries LiPo délivrent 3,7 V.
• Les normes et règles de sécurité sont primordiales quand on manipule des batteries.

Implémentation logicielle

J'ai pas mal planché sur la partie logicielle et la synchronisation des données.

L'objectif est de faire fonctionner l'ESP32 comme un serveur Bluetooth Low Energy (BLE), avec un client sur mon ordinateur pour récupérer les mesures.

Au début, impossible de téléverser mon code sur le microcontrôleur : il était tout simplement trop lourd. En creusant un peu, j'ai découvert que la librairie BLE par défaut est une vraie usine à gaz qui vampirisait 75 % de la mémoire flash disponible. Je suis passé sur NimBLE, qui est environ deux fois plus légère. En contrepartie, elle ne gère que le BLE et fait l'impasse sur le Bluetooth classique. Ça tombe bien, je n'avais de toute façon pas prévu de l'utiliser.

Restez dans le coin pour suivre les prochaines étapes du développement de mon capteur portable pikoAQI !