Ich sitze unter dem Vordach, es ist bedeckt und still. 11 °C, leichter Wind, alles leicht gedämpft – perfekt, um konzentriert am Code zu werkeln. Zum dritten Mal zeigt sich derselbe Effekt: Der Kapazitäts‑Shift bei rund 70 % relativer Feuchte. Wenn das kein Zufall ist, dann steckt da ein echtes Muster dahinter.
Reproduzierbarer Shift
Kurz zusammengefasst: Der Kapazitätswert springt bei etwa 70 % rF reproduzierbar um dieselbe Größenordnung. Das halte ich jetzt schon für mehr als Zufall. Ab hier gilt: Kalibrierung = Priorität 1. Ich will herausfinden, ob die Ursache in der Hardware, im Feuchtesensor, in der Umgebung oder irgendwo im Code steckt. Wahrscheinlich eine Mischung, aber wer weiß – nur systematisches Vorgehen bringt Klarheit.
Logger & Reboots
Mein Python‑Logger läuft inzwischen stabiler. Ich habe Temperatur‑ und Drifttracking ergänzt und Unit‑Tests hinzugefügt, damit keine plötzlichen Datenverrenkungen durchrutschen. Aber ein Problem ist geblieben: Die WLAN‑Reboots erzeugen Lücken. Lösung in Arbeit: lokal‑first‑Logging, dann periodischer Push, plus ein Watchdog, der Lücken erkennt und notfalls neu schiebt. Klingt simpel, aber in der Praxis… na ja, wird spannend 😉.
Nächste Schritte
Das Validierungsziel ist klar: fünf identische Runs mit 70 % rF unter vergleichbaren Bedingungen. Danach will ich statistisch prüfen, ob der Shift signifikant ist. Ich tendiere zu Bootstrap‑Tests, aber vielleicht reicht ein t‑Test aus. Dazu kommt die Frage, ob ein robuster Outlier‑Filter etwas verbessert – das zeigt sich erst, wenn die fünf Serien abgeschlossen sind.
Live‑Test unter dem Vordach
Ich starte gleich einen schnellen Versuch: WLAN kurz neu starten, um die Watchdog‑Kette zu testen. Ziel: simulierte Lücke → Lücken‑Detektion → verspäteter Push. Gleichzeitig loggt das Board Temperatur und Drift, damit ich heute noch einen Quickcheck für die Kalibrierung machen kann. Der Rauschpegel verändert sich leicht mit der Temperatur, was mir vorher gar nicht so aufgefallen war. Die Unit‑Tests laufen grün, immerhin.
Offene Punkte
- fünf 70 %-Runs abschließen
- Statistikentscheidung (Bootstrap vs. t‑Test) treffen
- Outlier‑Filter prüfen
- vollständige Kalibrierung (Prio 1)
- Ursache klären: Hardware / Umwelt / Software
- lokal‑first‑Strategie unter Realbedingungen validieren
Das Licht ist flach, kein Sonnenspiegeln auf den Displays – eigentlich perfekte Laborbedingungen im Freien. Ich tipp jetzt die letzten Zeilen ins Script und schau, ob der Watchdog sich brav meldet, falls das WLAN kurz weg ist.
Habt ihr Erfahrungen mit Bootstrap vs. t‑Test bei kleinen Messreihen oder clevere Outlier‑Filter‑Ansätze für kapazitive Messungen? Oder vielleicht Tipps für robuste Watchdog‑Patterns bei Embedded‑Loggern? Schreibt mir gern eure Gedanken – wär interessant zu sehen, wie ihr sowas löst 🚀
