September 2026: Nach neun Wochen Pause stand ich vor meinem eigenen Code und verstand ihn nicht mehr. Der Frühling war schnell gewesen: viele Umbauten, viele halbfertige Ideen, Wissen, das nur im Kopf lag und dort nicht überlebt hatte. Bevor es planvoll weitergehen konnte, musste ich erst verstehen, was da eigentlich lief, und dann aufräumen. Der September war dafür da.
Der Wiedereinstieg war bewusst klein: Dokumentation ordnen, die Firmware meldet beim Start ihre Version, ein größerer Stack behebt einen Absturz im Analyzer. Das erste Lab-Experiment, eine Abstandsleiter, blieb ohne klares Ergebnis.
Mitte September wurden die Detektoren zusammengeführt und toter Code entfernt. Eine schlanke Parameter-Registry kam dazu: Einstellungen lassen sich jetzt zur Laufzeit ändern, ohne neu zu flashen. Das ist die Voraussetzung dafür, Nodes später im Raum live zu stimmen. Außerdem wurde die VEKTOR-Spezifikation (Link folgt) importiert, eine künftige Schnittstelle nach außen, vorerst nur abgelegt.
Mit dem Aufräumen fiel auch eine Hardware-Entscheidung: weg vom Piezo, hin zu einem kleinen Class-D-Verstärker mit 3-Watt-Lautsprecher. Der Piezo war vor allem viel zu leise. Ob der Wechsel sich lohnt, zeigt erst vole Tests im Oktober.
Ende September wurden mehrere parallel entwickelte Zweige zusammengeführt. Das brachte einige echte Bugfixes und rund 14 KB weniger Speicherbedarf.
Dabei bekam die Detection ihre heutige Form: eine Kette aus vier Stufen, jede mit einer einzigen Aufgabe.
Wie ein Node jetzt hört
- Merkmale. Aus dem Mikrofonsignal wird alle 0,25 ms eine Handvoll Zahlen gerechnet, vor allem: Wie viel Energie liegt gerade bei der Zieltonhöhe? Die letzten 256 Millisekunden bleiben in einem kurzen Gedächtnis.
- Detector. Beobachtet diese Zahlen über die Zeit und sucht den Umriss eines Rufs: Pegel springt hoch, bleibt lang genug oben, fällt wieder ab. Passt der Umriss, meldet er ein Ereignis. Passt er nicht, verwirft er es und sagt warum (zu kurz, zu lang, zu leise).
- Inspector. Schaut sich das gemeldete Ereignis im Nachhinein genauer an, mit dem Gedächtnis aus Stufe 1. Wie laut war der Ruf in der Kernzeit? Wie klar stach er gegen die Nachbarfrequenzen hervor? Jeder Befund bekommt eine Klasse, etwa schwach, mittel, stark.
- OccurrenceEvaluator. Vergleicht Befunde mit Mindestanforderungen und fällt das Urteil: gültig oder nicht. Nur ein gültiges Urteil erreicht das ‚Behaviour‘, also die Entscheidung, ob der Node antwortet.
Vorher war das alles ineinander verwoben, und ich konnte nicht sagen, warum ein Ruf durchfiel. Jetzt kennt der Detector nur den Umriss, der Inspector nur die Beweise, der Evaluator nur die Regel. Wenn etwas schiefgeht, lässt sich sagen, in welcher Stufe. Das hat später im Oktober geholfen.
ESP32 mit Flachbandkabel
Was bleibt offen
- Die Abstandsleiter blieb ohne Ergebnis. Liegt es an der Messung oder an der Hardware?