Kategorie: Dev

Mai bis Juni 2026: Im Mai lief zum ersten Mal ein Kreis aus fünf Nodes auf der Werkbank: Einer ruft, der nächste antwortet, und der Ruf wandert reihum. Ein erstes System! Im Juni ging es dann an eine unbequemere Frage: Was liefert das Mikrofon eigentlich, bevor der Code es interpretiert?

Wie

Anfang Mai bekam der Emitter seine erste echte Implementierung, dazu einen Kalibrierung für den Grundpegel und einen ersten Versuch, zu bewerten, wie gut ein Klang zur Zielfrequenz passt. Ein ‚Analyzer-Mode‘ der Firmware lieferte jetzt stabile Testsequenzen. Damit ließ sich Erkennung zum ersten Mal wiederholbar messen.

Mitte Mai standen fünf Nodes im Raum. Danach wurde die Erkennung komplett neu gebaut, ebenso der Analyzer. DAs Ergebnis war erstmal ein grosser Code-Salat. Eine Woche lang ging es nur ums Löschen: alte Pfade, alte Modi, alte Aliase. Detection- einstellungen bekamen eigene Profile, ziwschen denen ohne Firmware-Update gewechselt werden konnte.

Ende Mai lief der Kreis: fünf Nodes, langsames Call and Response. Die Erkennung schwankte von Tag zu Tag, viel Zeit ging in Diagnose. Am Ende stand ein Speicher-Overrun, der bis in den Juni brauchte.

Im Juni wurde aufgeräumt, mit klaren Zuständigkeiten: Jeder Detektor schreibt seine eigenen Reports, der Analyzer liest sie, statt sie nachzubauen. Dazu kamen ein Glossar für die Begriffe, Health-Checks für das Rohsignal und, sehr praktisch, automatisierte Tuning-Läufe.

Dann die Rohdaten. Die Mitschnitte zeigten keine Schwingung, sondern eine Treppe: Die Werte summierten sich auf, statt das Signal abzubilden. Erst aus den Differenzen benachbarter Werte entsteht das eigentliche Signal.
Warum das so ist? Keine Ahnung…

Danach kam der Wechsel auf den I2S-Treiber des ESP32, und alle Detektorwerte wurden auf gemeinsame Einheiten normiert.

Was bleibt offen

• Der Kreis lief, aber nicht verlässlich. Wie viel davon war Erkennung, wie viel der Dekodierfehler? Was Rauschen, was Signal?
• Woher kommt der Sonderbare Kodierfehler des Originalsignals?
• Detektor und Analyzer sind over-engineered, dun den Ergebnissen traue ich nicht ganz über den Weg.
• Danach: Sommerpause. Die Nodes ruhen bis September.

Mai 2026: Der erste Prototyp eines Nodes: ein ESP32 mit Mikrofon, LED und Piezo-Lautsprecher. Die Ausgangsfrage war, ob ein einzelnes Gerät auf einen Testsound (‚Chirp‘) reagieren kann (und nicht auf jedes Geräusch).

Wie

Am ersten Tag lief die Grundschleife: hören, Pegelspitzen erkennen, mit einem LED-Blink quittieren, mit einem Chirp über den Piezo antworten. Kurz danach kam ein Debug-Modus, der den Signalverlauf live plottet.

Das erste Problem lag nahe. Der eigene Chirp ist das lauteste Ereignis im Raum, also hörte der Node sich selbst und antwortete auf sich. Die Lösung ist vorerst: Während der Node sendet, wertet er nichts aus.

Parallel lief ein Vergleich zwischen einem analogen und einem MEMS-Mikrofon. Das MEMS lieferte zu dem Zeitpunkt keine besseren Ergebnisse, also blieb es beim analogen. Erkennungs- und Chirp-Parameter sind seitdem pro Mikrofonquelle getrennt hinterlegt, damit der Vergleich wiederholbar bleibt.

Zum Monatsende kam ein zweiter Gerätetyp dazu, der Emitter. Er spielt nur Testsignale ab und hört nicht zu. Damit lässt sich die Erkennung messen, ohne dass zwei reagierende Nodes sich gegenseitig beeinflussen.

Was bleibt offen

• Reicht ein Zeitfenster gegen das Selbsthören, sobald mehrere Nodes gleichzeitig senden?
• Pegelspitzen reagieren auf alles, was laut ist. Wie unterscheidet ein Node ein Chirp von einer zufallenden Tür?
• Analog oder MEMS- Mikrofone?

Beitrag nachgetragen im Oktober 2026