Des avions, des décibels et un ESP32

Dans le cadre de mon projet de suivi des avions qui passent à proximité de la maison, j'avais déjà réussi à récupérer pas mal d'informations.

Je savais quel avion était passé, à quel moment, à quelle altitude, à quelle distance de la maison...

Mais il manquait toujours une donnée essentielle :

combien de bruit avait-il réellement fait ?

Pour répondre à cette question, il ne me fallait pas simplement un sonomètre.

Il me fallait un sonomètre capable de rester dehors, de fonctionner en permanence et surtout de fournir automatiquement ses mesures à mon système de tracking.

Le cahier des charges était pourtant assez modeste :

• mesurer correctement le niveau sonore ;
• pouvoir rester installé à l'extérieur ;
• fonctionner en permanence ;
• permettre à mon tracker de récupérer automatiquement les mesures.

Rien de très exotique.

Du moins, c'est ce que je pensais.

Acheter quelque chose ?

Mon premier réflexe a évidemment été de chercher une solution existante.

Je commence par Amazon.

Des sonomètres, il y en a des pages entières. Des petits, des gros, avec écran, avec enregistrement...

Mais un modèle que je puisse installer dehors, laisser fonctionner en permanence et interroger automatiquement depuis mon script ?

Rien.

Ou, en tout cas, rien que je trouve.

J'élargis donc mes recherches au reste du Web.

Et là, je commence effectivement à trouver des systèmes de mesure acoustique connectés. Sauf qu'on entre rapidement dans le monde des solutions professionnelles, avec des tarifs qui n'ont plus grand-chose à voir avec mon petit projet expérimental.

Et nous parlons bien ici d'une expérience.

Dépenser plusieurs centaines d'euros simplement pour répondre à une question que je me posais par curiosité n'avait pas beaucoup de sens.

Dernière étape presque obligatoire lorsqu'on cherche un capteur un peu improbable : AliExpress.

Même constat.

Beaucoup de choses autour de la mesure du bruit, quelques modules intéressants... mais toujours pas cette petite boîte évidente que j'avais imaginée :

je la pose dehors, je lui demande le niveau sonore quand j'en ai besoin, elle me répond.

À ce stade, le réflexe DIY commence évidemment à me démanger.

Donc...

Je vais le fabriquer.

Un ESP32, évidemment

L'ESP32 s'est assez naturellement imposé.

J'en utilise régulièrement pour toutes sortes de petits projets. J'en ai même utilisé un pour fabriquer un densitomètre destiné à suivre le degré de fermentation d'un brassin de bière.

Pour quelques euros, on dispose du Wi-Fi, d'UART, d'I²C, de GPIO, d'une puissance de calcul largement suffisante et d'un environnement que je connais déjà.

Restait à trouver comment mesurer le bruit.

Le premier réflexe est évident :

un ESP32, un microphone, quelques lignes de code...

Ça ne doit quand même pas être bien compliqué.

Un micro ne mesure pas

Sauf qu'en creusant un peu, je me rends rapidement compte que je suis en train de confondre deux choses.

Un microphone capte du son. Il ne mesure pas, à lui seul, un niveau sonore.

Récupérer un signal audio avec un ESP32 est relativement simple. Détecter qu'un bruit vient de se produire aussi.

Mais moi, ce que je veux, ce sont des valeurs qui aient un minimum de sens : pouvoir associer un niveau sonore au passage d'un avion et comparer cette mesure avec celle du passage suivant ou avec le bruit ambiant.

L'amplitude obtenue avec un simple module microphone dépend du microphone lui-même, de son préamplificateur, du gain, de l'ADC, de sa réponse en fréquence, du montage mécanique...

Et si je veux obtenir quelque chose qui commence à ressembler à une mesure en dBA, il faut encore s'occuper de pondération fréquentielle, de calibration et de traitement du signal.

Autrement dit, je ne cherche pas simplement à construire un détecteur de bruit.

Il me faut au minimum une base qui ressemble réellement à un sonomètre.

Et je retourne fouiller dans le gigantesque tiroir à composants qu'est AliExpress.

Sans d'ailleurs trop savoir ce que je cherche.

Le module au nom beaucoup trop long

Au hasard de mes recherches, je finis par tomber sur ceci :

« Module de capteur de bruit de qualité industrielle RS485, testeur de capteur de bruit, sonomètre en décibels, détecteur de bruit de haute précision, transmetteur sonore »

Voilà.

Au moins, sur le plan des mots-clés, on était couverts.

Plus sérieusement, la fiche technique commence à devenir intéressante.

Le module ne se contente pas de fournir le signal brut d'un microphone : il annonce directement une mesure du niveau sonore avec une pondération A, sur une plage de 30 à 120 dB.

Il existe en plusieurs variantes avec différentes tensions d'alimentation et interfaces de communication.

Pour mon montage, je choisis la version UART TTL alimentée en 5 V, qui correspond particulièrement bien à une utilisation avec un ESP32.

Le constructeur annonce même une précision de ±0,5 dB à son point de référence de 94 dB à 1 kHz.

Soyons clairs : je n'ai aucune intention de faire confiance aveuglément à une fiche technique AliExpress et encore moins de prétendre construire avec ce module un instrument de mesure professionnel.

Mais ce n'est pas non plus ce dont j'ai besoin.

Mon objectif est beaucoup plus modeste : obtenir une mesure suffisamment cohérente du niveau sonore pour pouvoir observer ce qui se passe lorsqu'un avion passe et comparer différents événements.

Même en prenant les spécifications du constructeur avec les pincettes réglementaires, ça commence quand même sérieusement à ressembler à un sonomètre.

Et surtout, le module coûte environ 15 € livré.

À ce prix-là, l'expérience mérite clairement d'être tentée.

Commandé.

Premiers essais

Entre-temps, le module arrive et je peux enfin passer aux premiers essais avec un ESP32-S3.

Pour faire cohabiter tout ça, j'utilise ESP-IDF 5.5.5.

Pourquoi ce choix plutôt qu'Arduino, ESPHome ou autre chose ?

Pour une raison extrêmement scientifique :

c'est ce que j'avais sous la main.

À ce moment-là, j'étais justement occupé à bricoler un Border Router OpenThread à base d'ESP32. Mon environnement ESP-IDF était donc installé, configuré et ouvert.

Autant continuer avec celui-là.

Je commence donc à vibe coder un premier firmware avec mon IA favorite.

Rien de très ambitieux au départ : faire parler le module, comprendre ce qu'il renvoie et vérifier que les valeurs semblent exploitables.

Et les premiers résultats sont très encourageants.

La communication fonctionne, les données remontent proprement et les valeurs obtenues semblent cohérentes.

On progresse rapidement.

Le bricolage commence sérieusement à ressembler à une solution.

Un chiffre ne raconte pas toute l'histoire

En avançant, je réalise cependant qu'une simple mesure instantanée du bruit est assez réductrice.

Le niveau sonore varie constamment.

Une valeur récupérée à un instant précis peut tomber juste avant le passage d'un avion, pendant son maximum ou quelques secondes après.

Elle ne raconte finalement pas grand-chose de ce qui s'est réellement passé.

Mais qu'à cela ne tienne.

Puisque l'ESP32 reçoit en permanence les mesures du capteur, autant lui demander d'en faire un peu plus.

Le firmware commence donc à conserver un historique et à calculer plusieurs indicateurs sur différentes fenêtres de temps.

L'idée n'est plus seulement de savoir combien de bruit il y a maintenant, mais de pouvoir décrire un événement sonore et le replacer dans son environnement.

À ce stade, j'ai tout ce qu'il me faut côté mesure.

Une petite API

Reste maintenant à rendre ces informations accessibles.

L'étape suivante consiste donc à ajouter une petite API HTTP qui expose les données au format JSON.

Là encore, un peu de vibe coding et la question est rapidement réglée.

Une simple requête permet désormais de récupérer l'état actuel du sonomètre et les différentes valeurs calculées.

C'est exactement ce qu'il me faut : mon système de tracking pourra interroger le capteur lorsqu'un avion passe et récupérer les données acoustiques correspondant à cet événement.

L'API reste volontairement extrêmement simple.

Il n'y a ni compte utilisateur, ni token, ni clé d'API, ni mécanisme d'authentification.

Ce n'est pas un oubli.

Les informations exposées sont simplement des mesures de niveau sonore et elles n'ont, dans mon cas, aucune raison particulière d'être confidentielles.

Ajouter une authentification aurait surtout compliqué inutilement les systèmes chargés de récupérer ces données.

La seule barrière indirecte est finalement le Wi-Fi lui-même : il faut avoir accès au réseau local pour joindre l'ESP32.

Mais c'est davantage une conséquence de l'architecture qu'une véritable mesure destinée à sécuriser le sonomètre.

Et tant qu'à faire... Home Assistant

Puisque tout fonctionnait étonnamment bien jusque-là, pourquoi s'arrêter en si bon chemin ?

J'ajoute donc au firmware la publication des mesures via MQTT, ce qui permet de les intégrer directement dans Home Assistant.

Est-ce que j'avais réellement besoin de retrouver mon sonomètre dans Home Assistant ?

À ce stade, absolument aucune idée.

Mais puisque MQTT était disponible et que j'ai tendance à centraliser dans Home Assistant tout ce qui produit une donnée vaguement exploitable dans la maison, ça me semblait logique de l'y ajouter.

On trouverait bien une utilité à ces données plus tard.

Maintenant, il faut mettre tout ça dehors

Le prototype fonctionne suffisamment bien pour commencer à envisager une installation permanente.

Il reste toutefois un problème pratique : l'alimentation.

J'ai envisagé un moment une solution autonome avec batterie et panneau solaire.

Sur le papier, c'était séduisant.

En pratique, beaucoup moins.

Le premier problème était le coût. Une batterie, son électronique de charge, un panneau correctement dimensionné et tout ce qui va avec auraient probablement multiplié le prix du projet par quatre ou cinq.

Le second était la fiabilité.

Une batterie installée en permanence dehors doit supporter le froid, la chaleur et des variations de température parfois importantes. Cela ajoutait beaucoup d'incertitude à un projet qui n'avait simplement pas besoin d'être autonome.

Un câble USB suffisamment long fera donc parfaitement l'affaire.

Moins élégant sur un schéma, certes.

Mais simple, bon marché et probablement beaucoup plus fiable.

En réfléchissant à l'installation extérieure, une autre question commence cependant à me préoccuper :

l'humidité dans le compartiment électronique.

Humidité... ou plutôt condensation ?

Plutôt que de simplement ajouter un capteur d'humidité, je décide d'utiliser un petit capteur capable de mesurer température, humidité et pression atmosphérique.

Mon choix se porte sur le très classique BME280.

Il coûte peu cher, s'interface facilement avec un ESP32 et j'ai l'habitude, avec ce genre de petit module, d'en commander deux ou trois.

On verra que cette habitude peut parfois être utile...

La température et l'humidité permettent surtout de calculer une donnée beaucoup plus intéressante pour mon problème :

le point de rosée.

Petit retour au vibe coding pour intégrer le BME280, calculer le point de rosée et ajouter toutes ces informations aux données déjà exposées.

J'en profite également pour intégrer un petit breakout USB, histoire de simplifier les manipulations et l'alimentation du S3 et du module sonomètre.

À ce stade, il est temps de faire quelque chose de particulièrement difficile lorsqu'on aime bricoler :

ne plus toucher à rien pendant quelques jours.

Le système va tourner tranquillement afin de vérifier sa stabilité.

Pendant ce temps, je peux m'occuper du boîtier.

Une maison imprimée en 3D

La contrainte est assez particulière.

L'électronique doit être protégée des intempéries, mais le capteur acoustique doit, lui, rester exposé à l'air extérieur.

Enfermer complètement le microphone dans une boîte étanche aurait évidemment été assez contre-productif.

Après un peu de brainstorming, l'impression 3D paraît être une bonne solution.

Je peux dessiner un boîtier exactement autour de mes contraintes plutôt que d'essayer d'adapter une boîte existante.

Quelques passages dans Fusion 360 plus tard, j'arrive à un premier prototype qui me semble répondre au besoin.

Je choisis une construction à double paroi, avec une chambre séparée pour l'électronique.

Le capteur acoustique reste en contact avec l'extérieur, mais suffisamment en retrait pour être relativement bien protégé des intempéries.

Et il conserve évidemment sa bonnette.

La double paroi reste relativement fine. Je ne m'attends donc pas à transformer le boîtier en thermos, mais elle pourra peut-être jouer un petit rôle de tampon vis-à-vis des variations extérieures.

On verra.

Quel filament ?

Pour un objet destiné à vivre dehors en permanence, l'ASA aurait probablement été un choix plus rigoureux, notamment pour sa résistance aux UV et aux températures élevées. L'ABS pouvait également être envisagé.

Mais je n'avais aucune envie de transformer cette partie du projet en nouvelle expérimentation.

J'avais du PETG Anycubic sous la main, je savais l'imprimer correctement et ses caractéristiques me semblaient largement suffisantes pour cette expérience.

Ce sera donc du PETG.

Est-ce qu'il conservera parfaitement ses propriétés et son aspect après plusieurs étés, hivers, périodes de gel et journées en plein soleil ?

On verra bien.

Après tout, le boîtier vient lui aussi de devenir une expérience.

Concevoir aussi pour l'impression

L'impression se déroule parfaitement et, surtout, avec très peu de déchets.

C'est quelque chose auquel j'essaie de penser dès la conception : une pièce imprimée en 3D doit aussi être dessinée en fonction de la manière dont elle sera imprimée.

Une petite modification de géométrie peut parfois supprimer presque tous les supports.

Et lorsqu'une pièce devient trop compliquée à imprimer proprement, il est souvent préférable de la diviser en plusieurs éléments conçus pour être assemblés ensuite.

Cela demande quelques minutes supplémentaires dans Fusion 360, mais permet d'économiser du filament, du temps d'impression et cette merveilleuse activité qui consiste à arracher des supports pendant vingt minutes.

Dans un premier temps, j'imprime les deux éléments principaux :

C'est le moment de sortir l'électronique de son installation provisoire et de lui faire découvrir sa nouvelle maison.

Le S3, le module sonomètre, le BME280 et le breakout USB prennent place dans les petits logements prévus à cet effet.

Ces logements sont d'ailleurs un choix à double tranchant.

Ils maintiennent les différents modules sans devoir ajouter vis, entretoises ou colle. En revanche, le boîtier devient dépendant des dimensions exactes des cartes utilisées.

Pour un prototype, j'accepte volontiers le compromis.

L'ensemble repart ensuite pour quelques jours de fonctionnement afin de vérifier que tout reste stable dans sa nouvelle configuration.

Et comment accrocher ce truc ?

Il reste encore à trouver comment fixer le boîtier à l'extérieur.

Une chose est certaine :

je ne veux pas le percer.

Chaque trou constituerait une voie potentielle supplémentaire pour l'eau ou l'humidité.

Je dessine donc une sorte de grand T muni de deux longues glissières, qui vient simplement se coller au dos du boîtier.

Sa grande surface offre une zone de collage confortable et permet de bien répartir les efforts.

Le principe de fixation est extrêmement simple.

Deux vis sont placées sur la façade qui accueillera le sonomètre, en laissant légèrement dépasser leur tête.

Il suffit ensuite de présenter le boîtier et de faire glisser les têtes des vis dans les deux rainures.

Le boîtier reste totalement intact et l'ensemble peut être posé ou retiré en quelques secondes.

Simple.

Et là... plus rien

Je colle donc la glissière au dos du boîtier, je remets l'ensemble sous tension...

Et là :

plus rien.

Le S3 est alimenté.

Le module sonomètre aussi.

Mais plus de ping, plus d'accès à l'API, plus aucune donnée sur le réseau.

Quelques minutes plus tôt, tout fonctionnait parfaitement.

Mon premier suspect est évidemment le câblage Dupont.

Je vérifie, manipule un peu les connexions...

Rien de probant.

Je passe donc en monitoring pour voir ce que raconte réellement le S3.

Et là, première découverte :

le BME280 ne répond plus.

Deuxième découverte, plus gênante :

le firmware n'apprécie vraiment pas la situation.

L'échec d'initialisation du BME280 provoque un crash, suivi d'un reboot qui tente à nouveau d'initialiser le BME280, échoue, redémarre...

Une jolie boucle sans fin.

J'ai donc maintenant deux problèmes à résoudre.

Pourquoi le BME280 a-t-il subitement disparu ?

Et surtout :

pourquoi ai-je laissé un capteur totalement accessoire mettre hors service tout le sonomètre ?

Une panne peut parfois être utile

La priorité est évidente : corriger le firmware.

L'absence du BME280 doit être considérée comme une erreur non bloquante.

Au pire, ses données seront indisponibles, mais le S3 doit continuer à fonctionner, mesurer le bruit et exposer les informations du module sonomètre.

Retour au vibe coding.

Quelques modifications plus tard, le problème logiciel est réglé.

Je peux débrancher le BME280 sans que le reste du système ne s'en préoccupe outre mesure.

Parfait.

Il ne reste plus qu'à comprendre pourquoi ce BME280 refuse obstinément de fonctionner.

Je soupçonne toujours les Dupont et décide donc de contrôler toute la chaîne au multimètre.

Tout est normal.

On pousse le diagnostic du bus I²C un peu plus loin.

Rien de probant non plus.

Le BME280 reste obstinément absent.

Et puis je me souviens que j'en ai acheté plusieurs.

Je remplace le module.

Je redémarre.

Tout fonctionne.

Pour être certain que je ne viens pas simplement de tomber sur une coïncidence, je remets l'ancien BME280.

Le problème revient.

Je réinstalle le nouveau.

Tout fonctionne à nouveau.

Bon.

Le verdict est suffisamment clair : quelque chose ne va plus avec le premier module.

Pourquoi ?

Aucune idée pour le moment.

Je le mets donc de côté avec une petite mention « Broken by... ? ».

On lui fera peut-être subir quelques expériences à l'occasion.

Cette petite panne aura tout de même eu un effet bénéfique : elle m'a forcé à corriger un véritable défaut du firmware avant que le système ne parte vivre dehors.

Heureux hasard ?

Des Dupont dans un montage définitif ?

Il y a un autre choix dans ce prototype qui mérite d'être assumé :

j'ai conservé des fils Dupont.

En matière de fiabilité à long terme, ce n'est clairement pas une solution idéale.

Les contacts peuvent bouger, s'oxyder ou finir par devenir intermittents. Ce n'est certainement pas ainsi que je construirais un équipement destiné à fonctionner dix ans sans intervention.

Mais ce n'est pas non plus l'objectif.

Il s'agit toujours d'un prototype expérimental.

Et les Dupont apportent ici un avantage très concret : chaque élément du montage peut être remplacé en quelques secondes.

L'épisode du BME280 vient d'ailleurs parfaitement de le démontrer.

Pour cette version, je préfère donc volontairement la modularité et la facilité d'expérimentation à une fiabilité mécanique maximale.

Le câblage n'est peut-être pas digne d'une armoire industrielle, mais ce n'est pas non plus le chaos.

Et surtout, tout reste accessible.

On ferme ?

Cette fois, le projet commence réellement à être prêt pour l'extérieur.

Par précaution, je glisse quelques petits sachets de dessiccant dans le compartiment électronique.

Le BME280 permettra de surveiller ce qui s'y passe réellement, mais autant mettre toutes les chances de mon côté.

Reste à fermer le boîtier.

Initialement, j'avais prévu de réaliser l'étanchéité au silicone.

Ce serait probablement efficace.

Ce serait également assez pénible le jour où je voudrais rouvrir le boîtier.

Et puisqu'il s'agit toujours d'un prototype expérimental, la probabilité de devoir y remettre les doigts n'est pas exactement nulle.

Je décide donc de faire beaucoup moins élégant :

Duct tape.

Facile à poser, facile à retirer et probablement suffisant pour les premiers essais.

Je sens que je vais regretter ce choix.

Mais bon...

Et maintenant, dehors

Voilà où en est le projet aujourd'hui.

Le firmware tourne.

Le module sonomètre mesure.

L'API répond.

MQTT publie ses données.

Home Assistant les récupère, même si je ne sais toujours pas exactement ce que je vais en faire.

Le BME280 surveille température, humidité, pression et point de rosée.

Le boîtier est imprimé.

Quelques sachets de dessiccant attendent de découvrir si leur présence était réellement nécessaire.

Et maintenant, on mesure

Le boîtier a finalement quitté l'atelier.

Il est maintenant fixé sur la façade, le sonomètre tourne en permanence et ses mesures remontent automatiquement via l'API et MQTT. Home Assistant récupère également le niveau sonore et les différentes statistiques, ainsi que la température, l'humidité et la pression mesurées dans le boîtier.

Bref, cette fois, ce n'est plus vraiment un prototype posé sur un bureau.

Il reste évidemment des choses à observer.

Le boîtier imprimé en PETG va maintenant devoir affronter la pluie, le soleil, les variations de température et quelques saisons dehors. Il sera intéressant de voir comment il vieillit et comment évolue la température intérieure lorsqu'il est exposé au soleil.

Et surtout, il reste à reconnecter tout cela à la question qui avait déclenché le projet.

Mon tracker d'avions connaît déjà leur trajectoire, leur altitude et leur distance par rapport à la maison. Il peut désormais également interroger le sonomètre.

La prochaine fois que les avions recommenceront à passer à basse altitude, je pourrai donc enfin mettre les deux jeux de données côte à côte.

Quel avion est passé ?

À quelle altitude ?

À quelle distance ?

Et combien de bruit a-t-il réellement fait ?

C'était la question de départ.

Il aura simplement fallu un ESP32-S3, un module sonomètre chinois, un BME280, quelques lignes de Modbus, une API, MQTT, un boîtier imprimé en 3D et quelques détours parfaitement raisonnables pour commencer à y répondre.