Gerade sitze ich halb unter dem Vordach, um das Mess‑Setup trocken zu halten. Über Passau hängen die Wolken tief, 12 °C, leichter Wind – typischer Oktober halt. Und trotzdem zeigt das Board wieder denselben Kapazitäts‑Shift bei etwa 70 % relativer Feuchte. Zum dritten Mal in Folge. Wenn das so bleibt, dann ist das wohl kein Zufall mehr, sondern tatsächlich reproduzierbar.
Validierung und Logger‑Upgrade
Die Baselines mit NP0/C0G und Shunt‑RC‑Blöcken bei 40 % und 70 % rF sind durch. Das Python‑Logger‑Script läuft stabiler: Temperaturlogging, Drift, Rauschanteil – alles drin. Seit gestern hat es sogar Unit‑Tests (kleiner Sieg ✌️). Ich hab nur ein Problem: WLAN‑Reboots. Die reißen Lücken in die Zeitreihen, und das nervt echt, vor allem wenn man gerade eine glatte Messkurve braucht.
Heute Nachmittag start ich den „Confirming‑Run“ bei 70 % rF, wieder unter dem Vordach: NP0/C0G plus Shunt‑RC, Logging diesmal doppelt – lokal gebuffert und parallel per WLAN‑Upload. Idee: Wenn das WLAN wieder kurz weg ist, sollte die SD‑Datei weiterlaufen. Zusätzlich logge ich jetzt noch Temperatur, Drift und Rauschen mit engerer Samplerate, um das Verhalten von Outliern sauberer zu sehen.
Statistik‑To‑dos und offene Fragen
Auf der Auswertungsseite steht als Nächstes der Vergleich von Bootstrapping und t‑Test, auch wenn die Stichprobe klein bleibt. Dazu muss ich mich entscheiden, welcher Outlier‑Filter sinnvoll ist: klassischer MAD oder Hampel‑Erkennung, eventuell IQR oder ein robuster ML‑Ansatz. Wichtig wird noch, fünf 70 %-Runs unter gleichen Bedingungen zu schaffen, damit das Validierungsprotokoll rund wird.
Wenn das klappt, folgt ein sauberer Report mit Script‑Version, Logger‑Snapshot, den Rohdaten und (endlich) eine kleine Review‑Session. Die Kalibrierung rutscht dafür auf Priorität 1.
Praktisches Drumherum
Was mich weiterhin ärgert: Die WLAN‑Reboots. Mein Zwischen‑Workaround: lokal‑first Logging mit periodischem Push und nem Watchdog‑Counter, der Neustarts zählt. Mal schauen, ob das stabil genug ist, bis ich den richtigen Router‑Fix hab. Morgen räum ich den Tisch auf – sonst find ich bald gar nix mehr zwischen den Kabeln. 😉
Feedback gesucht
Kurze Frage in die Runde: Welche robuste Outlier‑Strategie würdet ihr bei dieser Datenmenge bevorzugen (MAD, IQR, Hampel oder was Eigenes)? Und hat jemand Erfahrungen mit resilientem Logging gegen WLAN‑Reboots – also Filesystem‑Buffer vs. SD‑Logger vs. kleine USV für den Router? Bin gespannt, was ihr da empfehlen würdet.
Wenn der heutige Run wieder den Shift zeigt, steht fest: das Protokoll bekommt sein erstes echtes Resultat 🚀.
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
