Principe de fonctionnement
Beep Locator repose sur la détection acoustique synchronisée de plusieurs appareils capables d’enregistrer le son ambiant via le microphone du navigateur. Chaque dispositif conserve un tampon audio de 60 secondes et applique un algorithme de détection basé sur la Transformée de Fourier rapide (FFT) combinée à un filtre passe‑haut afin d’isoler les impulsions sonores à haute fréquence, typiques d’un bip. Lorsqu’un bip est repéré, le serveur identifie l’appareil présentant le plus faible temps aller‑retour (RTT) et lui fait émettre un chirp court. Tous les écouteurs téléchargent alors un extrait audio couvrant 0,6 s avant le bip jusqu’à 0,8 s après le chirp. Ce segment commun sert à aligner les enregistrements grâce au chirp, ce qui rend possible la comparaison temporelle précise des ondes sonores entre les capteurs.
Une fois les enregistrements alignés, le serveur calcule les différences d’arrivée (TDOA) entre chaque paire d’appareils. En combinant ces TDOA avec les positions estimées des capteurs, il résout un système d’équations hyperboliques pour obtenir la localisation 2D du son. Le résultat s’affiche sous forme d’une croix (X) sur la carte, accompagné d’une ligne de log « Sounds located ». L’utilisateur peut confirmer le bip en le marquant, après quoi le système mesure l’intervalle entre les bips et affine la position à chaque nouvelle détection.
Architecture logicielle
Le cœur du projet est un serveur web Python (probablement Flask ou FastAPI) qui gère les connexions WebSocket avec les clients. Le serveur expose une interface UI accessible via QR‑code ou URL ; les navigateurs demandent alors l’accès au microphone grâce à l’API WebAudio. Les écouteurs exécutent un script JavaScript (detector.js) qui effectue la FFT et le filtrage haute‑fréquence, puis transmet les événements de bip au serveur sous forme de messages JSON contenant le timestamp et le niveau de confiance.
Le serveur orchestre plusieurs tâches : (1) réception des événements, (2) sélection du dispositif le plus proche du serveur (RTT minimal), (3) émission du chirp via la même connexion WebSocket, (4) collecte des clips audio, (5) alignement temporel et calcul de la localisation. Un mécanisme d’installation dynamique de modules (installModule()) permet d’injecter du code JavaScript à la volée sur les clients, évitant ainsi toute interaction manuelle pour actualiser les permissions du microphone après chaque rechargement de page.
Analyse de précision et limites
Le système a atteint une précision d’environ 40 cm dans un environnement domestique encombré, ce qui correspond aux performances rapportées par le papier de référence BeepBeep (2007). Cette précision provient de trois techniques : la mesure bidirectionnelle (two‑way sensing) qui compense les latences réseau, l’auto‑enregistrement (self‑recording) qui garantit que chaque appareil possède son propre tampon audio, et le comptage d’échantillons (sample counting) qui affine les TDOA à la résolution du taux d’échantillonnage (généralement 44,1 kHz sur les navigateurs modernes).
Les limites principales résident dans la dépendance à la qualité du microphone et à la synchronisation réseau. Les appareils mobiles utilisent des horloges internes non synchronisées, ce qui introduit un jitter de quelques millisecondes pouvant se traduire en plusieurs dizaines de centimètres d’erreur. De plus, le filtrage haute‑fréquence élimine les bruits basse fréquence mais peut masquer des bips à fréquence plus basse, réduisant la robustesse dans des environnements très bruyants. Enfin, le besoin d’une connexion WebSocket stable signifie que les zones avec une couverture Wi‑Fi irrégulière peuvent entraîner des pertes de paquets, perturbant l’alignement du chirp.
