In den letzten Beiträgen habe ich Schritt für Schritt beschrieben, wie aus einem einfachen ESP32 mit INMP441-Mikrofon ein Audiosensor entstanden ist, der WAV-Segmente an einen Python-Receiver schickt. Seitdem hat sich BirchEar dramatisch weiterentwickelt. Version 2.34 ist keine Firmware-Erweiterung mehr – es ist ein vollständiges verteiltes System mit KI-Analyse, mobilem Web-UI, PWA-Unterstützung und einem zweiten Sendertyp auf Basis des Raspberry Pi Pico 2 W.

Dieser Beitrag gibt einen strukturierten Überblick über die wichtigsten Meilensteine seit Version 2.0 und erklärt, wie die einzelnen Bausteine zusammenpassen.

Die Architektur im Überblick

BirchEar besteht heute aus drei unabhängigen Schichten:

  • Sender-Firmware – läuft auf dem ESP32-S3 oder dem Raspberry Pi Pico 2 W, nimmt Audio per I²S auf und streamt WAV-Segmente mit Metadaten-JSON zum Receiver.
  • Receiver-Container – ein Python-Dienst in Docker mit zwei separaten HTTP-Servern: Port 9000 für den ESP32/Pico-Upload, Port 80 für die Web-UI und die REST-API.
  • Web-Frontend (PWA) – eine Single-Page-Anwendung im Browser, die alle Analyse-, Export- und Konfigurationsfunktionen bereitstellt und seit Version 2.33 als Progressive Web App auf Android und iOS installierbar ist.

Ein zweiter Sendertyp: Raspberry Pi Pico 2 W

Mit Version 2.16 habe ich ein zweites PlatformIO-Environment für den Raspberry Pi Pico 2 W angelegt. Zwei Versionen später – in 2.17 – ist die vollständige Audiofirmware für den RP2350 fertig: I²S-Aufnahme auf den Pins GP18 (BCLK), GP19 (LRCLK) und GP20 (DATA), ein persistentes LittleFS-Konfigurationsportal und ein offener Setup-Hotspot BirchEar-Setup, der parallel zur WLAN-Station läuft.

Der Pico braucht weder SD-Karte noch Display. Er streamt Mono-WAV-Segmente während der Aufnahme direkt zum Receiver – genauso wie der ESP32. Aus Receiver-Sicht sind beide Sendertypen identisch, was die Analyse- und Export-Pipeline vereinfacht.

Ab Version 2.4 läuft ein Analyse-Worker im Hintergrund des Receivers. Zunächst war die Klassifikation heuristisch – speech, machinery, silence, other. Ab 2.14 kam das Google-Modell YAMNet als externer TFLite-Dienst dazu. Die Entwicklung verlief in mehreren Stufen:

Das Ergebnis ist ein System, das jede Aufnahme automatisch klassifiziert und die Ergebnisse in SQLite speichert. In der DATENANALYSE-Ansicht lässt sich nach Kategorie, Modellversion, Zeitraum, Device und Mindestpegel filtern – und einzelne oder mehrere Aufnahmen direkt als WAV oder ZIP herunterladen.

Audioanalyse im Browser – ohne Server-Roundtrip

Die AUDIOANALYSE-Sektion ist das Herzstück des Web-Frontends. Alle Signalverarbeitungsschritte laufen über die Web Audio API direkt im Browser:

  • Verstärkung von 0 bis +60 dB (dB-basiert)
  • Hochpass 0–1.000 Hz (0 Hz = deaktiviert)
  • Tiefpass 1.500–20.000 Hz
  • Parametrischer NOTCH-Filter mit Mittenfrequenz, Bandbreite und Dämpfung (violett im Spektrum visualisiert)
  • Live-Frequenzspektrum mit Originalsignal und bearbeitetem Signal auf einer dBFS-Skala
  • Gefilterter WAV-Export einzelner Dateien oder ZIP-Archiv bei Mehrfachauswahl

Ab Version 2.29 lassen sich Filtereinstellungen als benannte Profile speichern und laden. Zunächst nur im localStorage des Browsers – ab Version 2.34 serverseitig in SQLite, sodass Profile auf allen Geräten zur Verfügung stehen.

AUDIOAUFBEREITUNG: automatische Rauschreduzierung

Version 2.30 bringt einen neuen Menüpunkt: AUDIOAUFBEREITUNG. Eine browserseitige FFT-Analyse erkennt tieffrequentes Rumpeln und schmalbandige Störtöne und erstellt einen Filtervorschlag. Ab 2.30.2 kommt echte spektrale Rauschreduzierung hinzu:

  • Die leisesten Abschnitte einer Aufnahme bilden ein frequenzabhängiges Rauschprofil.
  • STFT-Filtermasken (Short-Time Fourier Transform) reduzieren Breitbandrauschen, ohne Nutzsignale anzutasten.
  • Das Ergebnis lässt sich direkt an die AUDIOANALYSE übergeben – die Originalaufnahme auf dem Server bleibt unverändert.

Mobile-UX, Dashboard und PWA

Mit Version 2.32 kommt das DASHBOARD als neue Standard-Startseite: alle bekannten Geräte als Cards mit Ampelstatus (LIVE / AKTIV / INAKTIV), Echtzeit-Upload-Anzeige (15-Sekunden-Polling, grüner Puls-Indikator) und Speicher-Fortschrittsbalken. Auf Mobilgeräten faltet sich die Navigation unter einem Hamburger-Button zusammen.

Version 2.33 vervollständigt die Mobile-Geschichte: BirchEar Receiver ist jetzt eine Progressive Web App. Mit manifest.json, einem Service Worker (sw.js) und App-Icons für 192 × 192 und 512 × 512 Pixel lässt sich die Oberfläche auf Android und iOS zum Homescreen hinzufügen – inklusive Standalone-Modus ohne Browser-Chrome.

Praxis-Tipp: Nach einem UI-Update muss der CACHE_NAME in sw.js hochgezählt werden (z. B. birchear-ui-v2 → birchear-ui-v3). Sonst liefert der Service Worker PWA-Nutzern weiterhin die gecachte alte Version aus.

Persistente Filterprofile – geräteübergreifend (v2.34)

Das neueste Feature schließt eine langjährige Lücke: Filterprofile der AUDIOANALYSE wurden bisher nur im localStorage des jeweiligen Browsers gespeichert – auf dem Laptop angelegte Profile waren auf dem Tablet nicht verfügbar.

Ab 2.34 werden Profile in einer neuen SQLite-Tabelle filter_profiles auf dem Receiver-Server gespeichert. Drei neue REST-Endpoints erledigen das CRUD:

GET    /api/filter-profiles          → alle Profile laden
POST   /api/filter-profiles          → Profil anlegen / überschreiben (UPSERT)
DELETE /api/filter-profiles/<name>   → Profil löschen

Das Frontend-JavaScript wurde auf async-Fetch-Funktionen umgestellt. Ein In-Memory-Spiegel (_profileCache) sorgt dafür, dass bereits geladene Profile ohne zweiten Request sofort verfügbar sind. Beim Öffnen des AUDIOANALYSE-Tabs werden alle Profile automatisch vom Server geladen.

Was fehlt noch – Ausblick

  • Mehrkanal-Aufnahme – derzeit nimmt BirchEar Mono auf. Stereo-I²S mit zwei Mikrofonen an einem ESP32 wäre ein nächster Schritt.
  • Edge-KI auf dem Gerät – YAMNet läuft aktuell als externer HTTP-Dienst. Eine TFLite-Variante direkt auf dem ESP32-S3 (mit PSRAM) wäre interessant, aktuell aber zu groß für den Flash.
  • Push-Benachrichtigungen – bei bestimmten Kategorien (z. B. „Glas“ oder „Hund“) wäre eine Benachrichtigung ein naheliegender nächster Schritt.
  • OTA für den Pico 2 W – der ESP32 hat Web-OTA, der Pico muss noch per USB geflasht werden.

Fazit

Was als Experiment mit einem ESP32 und einem Mikrofon begann, ist heute ein vollständiges System: zwei Sendertypen, ein containerisierter Python-Receiver mit SQLite-Datenbank, KI-gestützte Audioklassifikation, umfangreiche Audioanalyse im Browser und eine installierbare PWA für das Smartphone.

Am meisten hat mich überrascht, wie viel Signalverarbeitung im Browser möglich ist. Die Web Audio API ist erstaunlich leistungsfähig – Hochpass, Tiefpass, NOTCH-Filter, Live-Spektrum und WAV-Export laufen allesamt lokal, ohne einen einzigen Audio-Byte zum Server schicken zu müssen.

Noch ein Blick auf den Sensor

Der Sensor hat eine gut laufende/ stabile Firmware. Mechanisch sind jedoch noch ein paar Dinge optimierbar. Die beiden Micros sind auf der Platine verbaut und die Gehäuse kommen nur über die darüber befindlichen Löcher zu den eigentlichen Micros. Ich habe jetzt einmal ein Micro mit Kabeln verbunden und im Deckel direkt unter das Loch im Gehäusedeckel befestigt.

Auf dem Schreibtisch war das Ergebnis ein großer Schritt

AI-Modified & Supported Content