Mehr Stabilität, bessere Diagnose und flexiblere WLAN-Verbindungen

Ein akustischer Sensor soll vor allem eines tun: zuverlässig aufnehmen und seine Daten übertragen – auch dann, wenn das WLAN schwankt, der Empfänger vorübergehend nicht erreichbar ist oder die Zeitsynchronisation verspätet erfolgt.

In den aktuellen Firmwareversionen des BirchEar-Sensors lag der Schwerpunkt deshalb nicht nur auf neuen Funktionen. Ein großer Teil der Arbeit floss in die Stabilität, Fehlererkennung und Diagnose des Gesamtsystems.

Die aktuelle Firmwarelinie basiert auf Version 3.15.x. Zu den wichtigsten Neuerungen gehören mehrere WLAN-Profile, eine robustere NTP-Behandlung, ein Hardware-Watchdog, umfangreiches Logging und eine konfigurierbare Einschwingzeit des Mikrofons.

Klare Aufgabenteilung zwischen den Prozessorkernen

Der Raspberry Pi Pico 2 W besitzt zwei Prozessorkerne. Die Firmware nutzt diese bewusst für unterschiedliche Aufgaben:

  • Core 1 übernimmt die zeitkritische Audioaufnahme und Signalverarbeitung.
  • Core 0 kümmert sich um WLAN, Weboberfläche, Syslog und HTTP-Uploads.

Diese Trennung ist wichtig: Netzwerkoperationen können schwanken oder kurzzeitig blockieren. Das Mikrofon liefert seine Samples dagegen in einem festen Takt. Würden beide Aufgaben im selben Ablauf stattfinden, könnte ein langsamer Receiver direkt zu verlorenen Audiodaten oder einer blockierten Bedienoberfläche führen.

Zwischen den Kernen liegt deshalb ein statisch reservierter Ringpuffer. Core 1 schreibt Audiodaten hinein, während Core 0 sie an den Receiver überträgt. Kurzzeitige Netzwerkschwankungen können dadurch abgefangen werden.

Bei einem länger blockierten Upload wird das betroffene Segment kontrolliert abgebrochen. Die Firmware bevorzugt einen klar protokollierten Fehler gegenüber einer beschädigten WAV-Datei.

Hardware-Watchdog gegen vollständige Blockaden

Ein zentraler Hardware-Watchdog überwacht beide Prozessorkerne. Er wird nur dann zurückgesetzt, wenn Core 0 läuft und gleichzeitig ein aktuelles Lebenszeichen von Core 1 erhalten hat.

Bleibt einer der Kerne vollständig stehen, startet der RP2350 den Sensor nach spätestens 16 Sekunden neu.

Nach einem Watchdog-Neustart enthält das Eventlog einen entsprechenden Eintrag. Zusätzlich wird festgehalten, in welchem Bereich Core 0 zuletzt aktiv war – beispielsweise:

  • WLAN-Abfrage
  • Syslog
  • Weboberfläche
  • Upload-Verarbeitung
  • Recovery

Bei bestimmten Neustartursachen wird außerdem der externe CYW43-WLAN-Chip kurz vollständig abgeschaltet. Dadurch werden nicht nur der Mikrocontroller, sondern auch WLAN-Chip und Netzwerkstack definiert neu initialisiert.

Der Watchdog erkennt allerdings nur einen echten Stillstand. Wenn beide Kerne weiterlaufen, aber ein Receiver keine Daten annimmt, gilt das technisch nicht als Blockade. Für diesen funktionalen Fehlerzustand ist mit Issue #60 eine zusätzliche Recovery-Eskalation geplant.

Mehrere WLAN-Profile

Seit Firmware 3.14.0 können bis zu fünf WLAN-Profile hinterlegt werden. Jedes Profil besitzt:

  • eine SSID,
  • ein Passwort,
  • einen Aktivstatus,
  • eine Priorität.

Beim Start versucht der Sensor zunächst das zuletzt erfolgreich verwendete Profil. Ist dieses nicht erreichbar, folgen die übrigen aktivierten Profile in ihrer Prioritätsreihenfolge.

Die Versuche sind zeitlich begrenzt:

  • maximal zehn Sekunden pro Profil,
  • maximal 40 Sekunden für den gesamten WLAN-Start.

Kann keine Verbindung hergestellt werden, aktiviert der Sensor den Setup-Access-Point. Dadurch bleibt eine Neukonfiguration möglich, ohne dass das Gerät in einer endlosen Verbindungsschleife hängen bleibt.

Bei einem späteren Verbindungsverlust versucht die Recovery zunächst das aktive Profil und anschließend mögliche Ersatzprofile.

Gespeicherte WLAN-Passwörter werden nicht in das HTML der Konfigurationsseite zurückgeschrieben und erscheinen weder im Status noch im Log.

AP-Hopping innerhalb eines WLANs

Mehrere WLAN-Profile und AP-Hopping lösen unterschiedliche Probleme:

  • Ein Profilwechsel verbindet den Sensor mit einer anderen SSID oder anderen Zugangsdaten.
  • AP-Hopping sucht innerhalb der aktuell verwendeten SSID nach einem besseren Access Point.

Das ist besonders in WLAN-Netzen mit mehreren Access Points oder Mesh-Knoten hilfreich. Erkennt der Sensor einen deutlich besseren Zugangspunkt, kann er gezielt zu dessen BSSID wechseln.

Profil-Failover und AP-Hopping bleiben bewusst getrennt. Dadurch bleibt nachvollziehbar, ob der Sensor lediglich innerhalb eines Netzes gewechselt oder tatsächlich ein anderes WLAN-Profil verwendet hat.

Robustere Zeitbehandlung

Nach einem Neustart besitzt der Pico zunächst keine gültige Echtzeit. Ohne NTP-Zeitabgleich könnten Dateinamen und Metadaten deshalb auf das Jahr 1970 verweisen.

Frühere Versionen konnten in diesem Zustand dauerhaft auf NTP warten. Die aktuelle Firmware behandelt das robuster:

  1. NTP wird nach dem WLAN-Verbindungsaufbau gestartet.
  2. Die Firmware prüft fortlaufend die tatsächliche Systemzeit.
  3. Eine später eintreffende gültige Zeit gibt den Recorder automatisch frei.
  4. NTP-Wiederholungen erfolgen nicht blockierend und mit begrenztem Backoff.
  5. Bleibt die Zeit länger als fünf Minuten ungültig, nimmt der Sensor trotzdem auf.

Aufnahmen ohne gültige Zeit erhalten eindeutig erkennbare _unsynced_-Dateinamen. Die JSON-Metadaten kennzeichnen den fehlenden Zeitabgleich, anstatt eine vermeintlich korrekte Uhrzeit vorzutäuschen.

Konfigurierbare Einschwingzeit des Mikrofons

Beim Start der I²S-Schnittstelle können MEMS-Mikrofone einen kurzen Einschwingtransienten erzeugen. Dieser kann in der Aufnahme als Klick oder auffälliger Ausschlag erscheinen.

Seit Firmware 3.15.0 lässt sich die Einschwingzeit auf der Audio-Seite konfigurieren:

  • Minimum: 0 Millisekunden
  • Maximum: 1.000 Millisekunden
  • Standard: 200 Millisekunden
  • Schrittweite: 10 Millisekunden

Während dieser Zeit läuft das Mikrofon bereits, die eintreffenden Samples werden jedoch verworfen. Die eigentliche 60-sekündige Nutzaufnahme beginnt erst danach und wird durch die Einschwingzeit nicht verkürzt.

Zusätzlich blendet die Firmware die ersten 20 Millisekunden der gespeicherten Aufnahme linear ein. Warmup und Fade-in erfüllen dabei unterschiedliche Aufgaben:

  • Der Warmup entfernt Samples vor der Aufnahme vollständig.
  • Der Fade-in glättet den Anfang der gespeicherten Audiodaten.

Der verwendete Warmup-Wert wird protokolliert und in den JSON-Metadaten des Segments gespeichert.

Exponentieller Backoff schützt das Gesamtsystem

Ein nicht erreichbarer Receiver darf nicht dazu führen, dass der Sensor ununterbrochen neue Verbindungen aufbaut. Ein solcher Retry-Sturm würde WLAN, Prozessor und Receiver zusätzlich belasten.

Nach einem Uploadfehler verwendet die Firmware deshalb einen exponentiellen Backoff. Die Wartezeit wird nach wiederholten Fehlern schrittweise erhöht und auf einen konfigurierbaren Höchstwert begrenzt.

Parallel kontrolliert ein Stall-Timeout, wie lange der TCP-Sendepfad ohne Fortschritt bleiben darf. Nimmt der Receiver innerhalb dieser Zeit keine Daten an, wird das Segment kontrolliert abgebrochen.

Typische Meldungen sind:

[RECORDER] Verbindung zum Receiver fehlgeschlagen
[RECORDER] Receiver nimmt seit 1500 ms keine Daten an
[RECOVERY] WLAN verbunden – Receiver-Backoff bleibt aktiv

Diese Strategie schützt die lokale Weboberfläche und verhindert, dass ein gestörter Receiver den gesamten Sensor blockiert.

Ein Feldtest hat allerdings eine noch offene Lücke gezeigt: Bleibt das WLAN formal verbunden, kann die Firmware den Receiver-Backoff unbegrenzt fortsetzen, obwohl ein WLAN-Neustart den Zustand beheben würde.

Eventlog: die dauerhafte Gerätehistorie

Der Sensor besitzt ein persistentes Eventlog im Flash-Dateisystem. Darin landen wichtige Zustandsänderungen und Fehler, beispielsweise:

  • Systemstart und Firmwareversion
  • WLAN-Verbindung und verwendetes Profil
  • NTP-Synchronisation
  • Start und Abschluss einer Aufnahme
  • Uploadfehler
  • Recovery-Aktionen
  • Watchdog-Neustarts
  • kritische RSSI-Zustände

Das Eventlog bleibt über einen Neustart hinweg erhalten und kann über die Weboberfläche abgerufen werden. Seine Größe ist begrenzt, damit das Log nicht unbegrenzt wächst.

Die Meldungen enthalten Zeitstempel, Schweregrad und Komponente:

2026-10-03T12:04:35 [INFO] [RECORDER] Segment startet, RSSI -66 dBm, SR 16000 Hz
2026-10-03T12:05:35 [INFO] [RECORDER] Aufnahme abgeschlossen in 59 s, RSSI -66 dBm

Vor erfolgreicher NTP-Synchronisation erscheinen zwangsläufig Zeitstempel aus dem Jahr 1970. Sobald eine gültige Zeit vorhanden ist, wechseln die Einträge automatisch auf die korrekte lokale Zeit.

Live-Diagnose über USB-Serial

Alle wichtigen Logmeldungen werden zusätzlich über USB-Serial mit 115.200 Baud ausgegeben. Das ist besonders bei schwer reproduzierbaren Fehlern hilfreich: Ein angeschlossener Rechner kann den letzten Zustand vor einem Neustart oder Verbindungsabbruch aufzeichnen.

Beispielsweise lässt sich PlatformIO als serieller Logger verwenden:

pio device monitor --port COM3 --baud 115200 --filter time --filter log2file

Der tatsächliche COM-Port hängt vom jeweiligen Rechner ab.

Syslog für die zentrale Überwachung

Für dauerhaft installierte Sensoren ist ein USB-Kabel keine praktikable Diagnosemethode. Deshalb unterstützt die Firmware zusätzlich Syslog über UDP.

Normale Ereignisse können an einen zentralen Syslog-Server gesendet werden. Zusätzlich erzeugt der Sensor regelmäßig einen flüchtigen Status-Heartbeat. Dieser enthält unter anderem:

  • Firmwareversion
  • Laufzeit
  • freien Heap
  • WLAN-Status und IP-Adresse
  • RSSI
  • aktives WLAN-Profil
  • Recorder-Zustand
  • Aufnahmefortschritt
  • verwendete Samplerate
  • Zustand und Füllstand des Ringpuffers
  • Alter der letzten Netzwerkaktivität
  • erfolgreiche und fehlgeschlagene Segmente
  • verbleibenden Receiver-Backoff

Ein gekürztes Beispiel:

[STATUS] fw=3.15.0 uptime_s=120
wifi_status=3 ip=192.168.0.73 rssi_dbm=-63
wifi_profile=0 wifi_ssid=xxxxxx.xxxx
recorder_stage=stream_write recording=1 progress_pct=42
upload_buffer_bytes=2048 segments_ok=4 segments_failed=0

Der Status-Heartbeat wird nicht in das lokale Eventlog geschrieben. Dadurch verursacht die regelmäßige Diagnose keinen unnötigen Flash-Verschleiß.

Jedes Syslog-Paket trägt außerdem die konfigurierte Geräte-ID. So lassen sich mehrere Sensoren auch dann unterscheiden, wenn sie hinter derselben öffentlichen IP-Adresse betrieben werden.

Diagnose statt Blindflug

Die Stabilitätsmaßnahmen verfolgen ein gemeinsames Ziel: Fehler sollen nicht nur abgefangen, sondern auch nachvollziehbar werden.

Ein einzelner Logeintrag reicht selten aus, um einen komplexen Fehler zu verstehen. Erst die Kombination aus Aufnahmezustand, RSSI, Netzwerkaktivität, Backoff, Watchdog-Daten und Zeitstempeln zeigt, ob die Ursache beim Mikrofon, WLAN, Receiver oder in der Firmware liegt.

Fazit

Die jüngsten Firmwareversionen machen den BirchEar-Sensor nicht nur funktionsreicher, sondern vor allem besser beobachtbar und widerstandsfähiger:

  • getrennte Audio- und Netzwerkverarbeitung auf zwei Kernen
  • statischer Ringpuffer zur Entkopplung von Aufnahme und Upload
  • Hardware-Watchdog für vollständige Blockaden
  • kontrollierter CYW43-WLAN-Reset
  • mehrere priorisierte WLAN-Profile
  • AP-Hopping innerhalb einer SSID
  • robuste NTP-Wiederherstellung
  • Aufnahmebetrieb auch ohne gültige Zeit
  • konfigurierbare Mikrofon-Einschwingzeit
  • begrenzte TCP-Operationen und exponentieller Receiver-Backoff
  • persistentes Eventlog
  • Live-Diagnose über USB-Serial
  • zentrale Überwachung über Syslog

Gleichzeitig zeigen Feldtests, wo die nächste Verbesserung ansetzen muss: Ein formal verbundenes WLAN bedeutet nicht automatisch, dass der TCP- und Receiverpfad noch funktionsfähig ist. Issue #60 soll deshalb eine begrenzte Recovery-Eskalation ergänzen, ohne bei kurzen Störungen unnötige Neustarts auszulösen.

Genau diese Verbindung aus Schutzmechanismen, transparenter Diagnose und realen Feldtests macht eingebettete Systeme langfristig zuverlässig.