Ich sitze halb unter dem Vordach, der Logger klappert leicht im Wind – so ein dumpfes klack, als wollte er mich dran erinnern, dass beim nächsten Stoß das WLAN sicher sein sollte. Es sind 13 °C, wolkig, und wie schon an Tag 27 zeigt sich wieder dieser Kapazitäts‑Shift bei etwa 70 % relativer Feuchte. Reproduzierbar. Und das ist spannend genug, um den restlichen Nachmittag damit zu verbringen.
Reproduzierbarkeit oder Zufall
Wenn sich das wirklich über mehrere Läufe bestätigt, muss ich die Kalibrierung nach vorne ziehen. Ich hab heute schon zwei Serien fertig—Baselines mit NP0/C0G, und die Shunt‑RC‑Blöcke bei etwa 40 % und 70 % rF. Temperatur, Drift, Rauschen loggt der Python‑Kram automatisch mit. Das Script hab ich vorhin um einen Outlier‑Schwellwert erweitert. Nur simpel erstmal, aber es auf Unit‑Tests laufen zu sehen, fühlt sich gut an.
Das WLAN spinnt allerdings immer noch. Sobald’s rebootet, fehlen paar Sekunden im Datensatz, und das nervt, weil genau da manchmal der Sprung liegt. Ich überlege gerade, wie ich das lückenlos dokumentiere – vielleicht ein Marker im Logfile, vielleicht direkt im Plot?
Kurzer Testlauf – Ergebnisse in Sicht
Ich hab grad eben einen 5‑Minuten‑Durchlauf gemacht: 40 % rF → 70 % rF, zweimal gewechselt. Der Shift liegt jeweils im Bereich, der auf einen echten Dielektrik‑Effekt hindeutet, nicht auf Rauschen. Noch will ich keine Statistik ausspucken, aber der Trend ist eindeutig. Wenn das nochmal so kommt, wird’s Zeit für Bootstrap und t‑Test.
Frage an euch
Ich hab im Script aktuell eine einfache Outlier‑Filterung drin – basically eine fixe Grenze über dem Mittelwert. Mich würde interessieren, welche Methodik ihr bevorzugt: IQR, z‑Score oder lieber was Robustes wie MAD? Schreibt’s mir gern, ich bau das dann direkt ein.
Und ja – der Schreibtisch wartet noch. Das wird die nächste Mini‑Charge Spacer, bevor die Woche rum ist. Aber eins nach dem anderen … pack ma’s 🚀
