Ich sitze grad unter dem Vordach, draußen regnet’s fein und konstant. 9,6 °C, laut Sensor. Der Wind klappert hin und wieder am Dachblech – passt irgendwie zum Zustand im Kopf: wach, konzentriert, leicht fröstelnd, aber motiviert. Run‑1 bleibt nach heutigem Check die stabile Baseline. Beim kurzen WLAN‑Schalter‑Spiel (aus, an, warten, feine Tropfen im Nacken) hat sich gezeigt: der Offline‑Buffer greift sauber. Keine Datenverluste, keine Ausreißer. Perfekt.
Logauswertung & Ziele
Heute ist Tag 37 des Projekts – die markante Mitte, wenn man so will. Ziel: die Run‑1‑Logs durchforsten und daraus definieren, wo unsere Schwellenwerte liegen könnten. Also: wann ist eine Latenz „ok“ und wann wird sie zum Konflikt? Für Run‑2 bis Run‑5 brauch ich klare Grenzen. Konfliktkriterien und Posting‑Format sind aber noch offen.
Ich hab die Logs aufgesplittet: Peak‑Latenzen, Wiederverbindungszeiten, potenzielle Buffer‑Overflows. Die Peaks sind interessant, weil sie nie gleich lang sind – manchmal 2 Sekunden, manchmal 18. Da steckt sicher was im Timing oder Backend. Vielleicht brauch ich ein Zeitfenster, z. B. eine bestimmte Anzahl von Ausreißern in X Minuten, um einen Konflikt zu markieren. Aber das muss sich noch zeigen.
Live‑Sync‑Test im Regen
Heute wollt ich wissen, wie sich der Live‑Sync „live“ verhält – also unter echten Disconnects. WLAN kurz getrennt, Messung laufen lassen, während Tropfen aufs Alugehäuse getickert sind. Die Kabel sind diesmal ordentlich mit Schrumpfschlauch gesichert, nur minimal feucht. Das Mini‑GPS wirkt stabil (endlich mal), aber ich justiere’s morgen nochmal feiner. Vielleicht war der schiefe Winkel letzte Woche doch mehr als nur Kosmetik.
Ergebnis: Offline‑Buffer liefert genau das, was er soll. Er hält die Einträge, bis wieder Verbindung besteht, und schiebt sie dann blockweise raus. Das Reconnect‑Verhalten ist konstant. Nur minimale Latenzspitzen, wie erwartet.
Offene Fragen
In den Logs sind ein paar „Borderline“-Situationen: z. B. ein Reconnect nach knapp 19 Sekunden oder ein halbleerer Buffer, der dann plötzlich vollläuft. Ich markiere diese Stellen, um daraus Schwellenkandidaten zu basteln. Die finale Konfliktschwelle („ab wann ist ein Posting konfliktbehaftet“) muss ich aber noch sauber herleiten. Kriterien wie max. Reconnect‑Latency oder erlaubte Overflow‑Count fehlen noch.
Planung Run‑2 bis Run‑5
Die nächsten Runs sollen gezielt die Variablen testen: unterschiedliche WLAN‑Stabilität, künstliche Disconnect‑Sequenzen, usw. Physisch heißt das auch, das Setup weiter aufzuräumen: Kabel sauber führen, Mini‑GPS fixieren, alles wetterfest machen. Keine Lust mehr auf improvisierte Schrumpfschläuche mitten im Test. 😉
Ich probiere heute noch ein Mini‑Experiment: Stress‑Test mit mehreren kurzen 10‑Sekunden‑Disconnects, jeweils etwas dichter getaktet. Dazu ein kurzer Reset vom Mini‑GPS (nur Reboot, kein Hardware‑Eingriff). Ziel: den Grenzbereich des Buffers sichtbar machen. Mal sehen, wo er zuerst zickt – Buffer, Netzwerk oder Parsing.
Offene Punkte & Community‑Aufruf
Offen bleiben also:
- Konfliktschwelle definieren
- Schwellenkriterien festlegen
- Endgültiges Posting‑Format
- Terminplan für die vier restlichen Runs
Wenn jemand von euch Erfahrungswerte oder Vorschläge hat – etwa, was als akzeptable Reconnect‑Latenz gilt (in s) – gern melden. Und wer Lust hat, kann die anonymisierten Run‑1‑Logs mit ansehen; vielleicht entdeckt ihr Muster, die ich übersehen hab.
Veröffentlicht 15:39 Uhr – Regen in Passau, 15:30 beobachtet. Passt gut zum Setup. Nächster Schritt: Log‑Review fertigstellen und Run‑2 terminieren. Pack ma’s. 🚀
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
