openAger: den Instablitäten auf der Spur

Nachdem der Ager monatelang super stabil gelaufen ist, bemerkt ich plötzlich ein gegensätzliches Verhalten: aus nicht nachvollziehbaren Gründen startete das Teil neu.

Nicht nachstellbar / reproduzierbar. Im höchsten Debuggingmode: keine Infos. Zum Haare raufen eben.

Als erstes habe ich mir das i2c Subsystem näher angeschaut – und alles mögliche durchgetestet: zusätzliche Kondensatoren eingebaut wo sinnvoll, zusätzliche Widerstände für die Clock und Data-Leitung des Busses. Aber keine merkbare Verbesserung.

Um überhaupt zu „sehen“, was da abgeht habe ich mir extra ein Ozilloskop und ein Logic Analyizer angeschafft – auch hier sieht alles superfein aus: saubere, steile Flanken und keine störenden Spikes etc.

Arrrgh!

Als nächstes habe ich den 12V -> 3.3V Stepdown ausgestauscht und zusätzlich die Stromversorgung des Boards umgestellt von 3.3V auf 5V – aber ebenfalls keine Besserung.

Durch viel Literaturrecherche habe ich einiges gelesen über Probleme im Zusammenhang mit WLAN – und da wir jeden Sensor recht spontan über MQTT rausschicken hatte ich hier ein wenig schlechtes Gewissen und programmierte das Sensorenprotokoll um auf ein JSON Format mit weniger Overhead. Aber „weniger“ und aufgeräumtere WLAN Nutzung war auch noch nicht des Rätsels Lösung.

Der Strom… der Strom!

Aus purer Neugier dann mal die eigentliche 12V Quelle angeschaut. Man erinnere sich: Beim Zerlegen des Schrankes fand ich einen 12V Trafo für die ehemalige Innenbeleuchtung, welche ich für meine Zwecke genutzt habe.

Soweit auch ein stabiles 12V Signal – allerdings damals noch mit einem normalen Multimeter gemessen. Hmm… wie sieht denn das jetzt mit dem Ozilloskop aus?

Yep – da sind Spannungsabfälle zu sehen. Zwar im Bruchteil einer Millisekunde und „nur“ 500mV, aber das reicht offenbar bereits für einen Crash oder seltsamen Zwischenzustand.

Der ESP32 zieht bei starker WLAN Nutzung schon mal 400mA statt der üblichen 50-70mA. Aber diese Spitzen sind so „schnell“, dass man sie ohne ein geeignetes Gerät nicht entdecken kann.

Die Lösung schaut jetzt erstmal so aus: direkt beim ESP32 einen kleinen Kondensator verbaut, der versucht die Spikes auszugleichen. Zusätzlich habe ich statt des verbauten Trafos eine externe 12V Stromquelle im Einsatz, die auch nicht den potentiellen Störungen des Kühlkompressors ausgeliefert ist.

Fazit

*Wirklich* eine stabile Stromversorgung verwenden! Multimeter vergessen und stattdessen das Netzteil mit einem Ozilloskop prüfen, dicke Kabel verwenden und notfalls sogar eine Batteriepufferung verwenden.

Somit läuft das Ding erstmal wieder superstabil. Hoffen wir mal, dass die Freude nicht verfrüht ist 🙂

Update: Natürlich war es verfrüht 🙂 Auch wenn die instabile Stromversorgung sicherlich nicht zuträglich ist, was das eigentliche Problem im Arduino Code versteckt…