👷‍♂️ Entwicklertagebuch NEXUS-Habitat: Wenn Sensoren plötzlich anfangen zu singen und das Jahr 1979 anruft 🤔

Wenn Sensoren plötzlich anfangen zu singen und das Jahr 1979 anruft

Eigentlich stand für heute nur eine kleine "kosmetische" Änderung auf dem Programm. Der Dateiname der NEXUS-CSV-Dateien sollte um die MAC-Adresse des ESP32 erweitert werden (Format: MAC_dd-mm-yy-counter.csv), um die spätere Datenauswertung sauberer zu trennen. Was als 5-Minuten-Aufgabe geplant war, entwickelte sich schnell zu einem tiefen Kaninchenbau aus Hard- und Software-Rätseln. Aber der Reihe nach.

Akt 1: Die Python-Falle

Kaum war der neue Sketch aufgespielt, verweigerten meine Post-Processing Python-Scripte auf dem Rechner plötzlich ihren Dienst. Keine Daten wurden mehr eingelesen. Der Fehler war ein klassischer Fall von "Computer machen genau das, was man ihnen sagt, nicht was man meint". Das Script suchte mit re.match() nach dem Datum – und zwar exakt am Anfang des Dateinamens. Da nun aber die MAC-Adresse ganz vorne stand, brach die Suche sofort ab. Die Lösung? Ein simpler Wechsel auf re.search(), wodurch Python nun den gesamten String durchsucht, bis es die Datums-Struktur findet. Ein Wort geändert, Script läuft wieder. Abgehakt.

Akt 2: Die absolute Eiszeit (-127°C) 

Der wirkliche Krimi begann danach beim NEXUS-Habitat-Modul. Plötzlich warfen alle fünf DS18B20-Temperatursensoren nur noch den Wert -127.00 aus. In der Welt der Mikrocontroller ist das der Fehlercode für: "Hier ist nichts, der Bus ist tot".

Der Verdacht fiel zunächst auf die üblichen Verdächtigen: Fehlender Pull-Up-Widerstand (war aber verlötet), Wackelkontakt im Kabel oder ein defekter Sensor, der alle anderen mit in den Abgrund zieht. Also ran an die Hardware und einen OneWire-Scanner-Sketch aufgespielt. Das Ergebnis auf Pin D6: Keine Sensoren gefunden. Ein Wechsel auf D7: Wieder nichts.

Und dann passierte einer dieser glorreichen Zufälle, die man mit purer Schlosser-Logik am besten löst. Aus Frust steckte ich das Datenkabel der Sensoren auf den Pin D3 um. Plötzlich poppten die Adressen der Sensoren im Serial Monitor auf! Aber zeitgleich begann der kleine Piezo-Buzzer auf dem Seeed Expansion Board (der fest mit D3 verdrahtet ist) furchtbar an zu knarzen.

Was ich da hörte, war im wahrsten Sinne des Wortes die Matrix: Der Buzzer übersetzte den rasend schnellen, digitalen Datenstrom der Temperatursensoren direkt in Schallwellen. Das bewies: Kabel, Sensoren und Widerstand waren zu 100 % in Ordnung!

Akt 3: Die Architektur des ESP32S3 

Warum also blieben D6 und D7 tot? Die Antwort liegt tief in der Hardware-Architektur des XIAO ESP32S3. Sobald man im Code die serielle Kommunikation für den Monitor (Serial.begin()) startet, krallt sich der Chip gnadenlos die Pins D6 (TX) und D7 (RX) für sich selbst. Die OneWire-Bibliothek ruft zwar auf diesen Pins nach den Sensoren, wird aber vom System hardwareseitig völlig blockiert.

Da das Knarzen auf D3 für Fledermäuse und Menschen gleichermaßen unerträglich wäre, wurde das System kurzerhand komplett neu strukturiert:

  1. Das GPS-Modul (AIR530) wurde auf seine angestammten Hardware-Serial-Pins (D6 & D7) umgeroutet. Dort läuft es nun völlig im Hintergrund.

  2. Der OneWire-Bus bekam den sauberen, freien Pin D0.

  3. Der komplette Code wurde neu geschrieben, um alte Timing-Konflikte auszumisten.

Akt 4: Grüße aus dem Jahr 1979 

Das System lief wieder flüssig, lieferte brillante Messwerte – nur der Windows-Explorer behauptete steif und fest, die CSV-Datei sei am 31.12.1979 erstellt worden. Ein bekannter Bug bei FAT32-Dateisystemen ohne gepufferte Echtzeituhr. Auch das ließ sich beheben: Der ESP32 wartet nun beim Hochfahren auf den ersten GPS-Fix und synchronisiert seine interne Systemuhr über den Befehl settimeofday() auf die Millisekunde genau mit den Satelliten, noch bevor er die erste Datei auf der SD-Karte anlegt.

Fazit & Ausblick 

Eine abschließende Messung mit dem USB-Tester brachte dann die endgültige Bestätigung: Bei rund 5,1 V fließen gerade einmal 165 mA (ca. 0,84 Watt). Mit einer handelsüblichen 10.000 mAh Powerbank läuft das NEXUS-Habitat damit gut 37 bis 40 Stunden durch. Perfekt für lange Nächte draußen. Anders bei einer 30.000 mAh Powerbank - dann sind es zwischen 111 Stunden bis zum 120 Stunden Arbeitszeit.

Die Generalprobe ist also geglückt. Nächster Halt: Die Einbindung des MLX90614 Infrarot-Thermometers. Damit die Signale auf dem Weg ins Habitat nicht zusammenbrechen, liegen die I2C-Extender-Bausätze von Horter & Kalb schon im Warenkorb. Es bleibt spannend!

Kommentare

Beliebte Posts