Woche 39 in 2025 im Rückblick

Die Woche begann in Passau mit dem vierten Logbucheintrag und einem Fokus auf Entscheidungen, die zwar klein klingen, aber für den gesamten Missionsverlauf entscheidend sind. Ein erster Prototyp lag auf dem Tisch, aus dem 3D‑Drucker gekommen, nur die Adapterlasche fehlte noch. An diesem Punkt wurde das Datenformat festgelegt: Laufzeitmessungen sollen in CSV erfasst werden, während Setup‑Informationen und Kalibrierungen in JSON bleiben. Damit spart man Platz und erhält Klarheit – wichtig für spätere Auswertungen. Auch die Kommunikationsarchitektur nahm Gestalt an: LoRa als erste Wahl, GSM als Rückfall, Satellitenfunk nur als Option. Technisch war das ein klarer Rahmen, aber offen blieben praktisches Zubehör und die bürokratische Seite – Genehmigungen, Versicherungen, die Frage nach den Kosten, sollte ein Satellitenmodul nötig werden.

Einen Tag später, am fünften Projekttag, wurde die Dokumentation finalisiert, und die Liste der Bauteile schärfer gefasst: ESP32 als Herzstück, dazu GPS‑Modul, Drucksensor BMP390 und die IMU LSM6DS3. Bei Regen und Seitenwind zeigte sich dann etwas, das im Labor verborgen blieb: Ein Leck in der Dichtung, das bei Böen den Schutz des Innenraums in Frage stellte. Solche Beobachtungen erinnern daran, warum Feldtests mehr sind als Routine – sie zeigen Schwachstellen, die auf dem Papier unsichtbar bleiben. Parallel rückte die Datensicherung stärker in den Blick: SD‑Karte oder Cloud, einfache CRC‑Checks oder kryptografische Hashes? Es blieb vorerst offen, wie streng die Prüfsummenpolitik sein würde.

Am sechsten Tag kam es zum eigentlichen Review. Clips und Kanten des TPU‑Gehäuses wurden inspiziert, „23 km/h Böen“ markierten eine Grenze, hinter der Wasser ins Innere drang. Gleichzeitig wurde deutlich, dass die Stromversorgung robuster gedacht werden muss: Steckverbinder, die im Trockenen genügen, wirken im Feld bei Vibration und Feuchte unsicher. GPS, Baro und IMU funktionierten prinzipiell, aber der Lock des Satellitensignals blieb zäh. Es zeigte sich auch: Die richtige Balance zwischen Detailtiefe und Pragmatismus in der Dokumentation ist noch nicht gefunden. Während CSV und JSON gesetzt waren, blieb die Prüfsummenfrage und die genaue Struktur der Backups weiter auf der Liste.

Die Tage sieben bis neun waren von einem gewissen Rhythmus geprägt: Morgens Gehäuse aus TPU prüfen, mittags Sensorsignale vergleichen, nachmittags kurze Feldgänge. Ein Feuchtesensor im Gehäuse lieferte Entwarnung: Kondensation trat nicht auf, selbst nach längeren Phasen am Inn. Die Elektronik selbst wirkte zuverlässig. Der ESP32 lief stabil im Dauerbetrieb, die Sensoren gaben plausible Werte. Und doch: GPS kostete Geduld. Der „Time to first fix“ war zu lang, Optimierungen über Antennenlage, A‑GPS und Warm‑Starts wurden getestet. Zwischendurch notierte der Autor auch persönliche Momente – ein Abend am Fluss, Gespräche neben der Arbeit, ein Radweg an der Donau. Solche Notizen rahmen die Technik in einen Alltag, der das Projekt trägt, ohne dass die konzentrierte Arbeit auf der Strecke bleibt.

Das Wochenende brachte schließlich den zehnten Eintrag. Bei 18 Grad Außentemperatur in Passau lief ein zweistündiger Verbrauchslog, die Energieaufnahme wurde profiliert. Nebenbei prüfte der Autor die Ausrichtung der Antenne, die Polarisation, die Wirkung unterschiedlicher Positionen auf den Fix des GPS‑Signals. Ein Hinweis von Michael führte zur Überlegung, eine DELOCK LTE‑Antenne einzubinden. Das wirft neue Fragen auf: Welche Antenne wird in die finale Teileliste aufgenommen? Welche Kabelwege und Steckverbinder bestehen den Dauertest draußen am Fluss? Und nicht zuletzt: Kann die Rechenleistung des ESP32 ausreichen, um Prüfsummen wie SHA‑256 oder BLAKE2 im Feldbetrieb zu berechnen, ohne das Logging auszubremsen?

Über diese zehn Tage verteilt wurde klar, dass das Projekt technische Stabilität in den Kernfunktionen erreicht hat: Der Mikrocontroller läuft, die Sensoren verhalten sich konsistent, die Gehäuse halten zumindest statische Belastungenstand. Gleichzeitig bleiben wesentliche offene Punkte: die GPS‑Performance, die Dichtungsfrage bei Böen, die genaue Policy für Datenintegrität und Backups. Die Arbeit an der Teileliste, immer wieder verschoben, ist zur Voraussetzung geworden, um kalkulieren und genehmigen zu können.

Nächste Woche wird sich entscheiden, ob das Team die offenen Fragen weiter aufschiebt oder endlich festzieht. Ganz oben stehen drei Themen: die finale Prüfsummenentscheidung mit realem ESP32‑Profiling, die Eingrenzung des GPS‑TTFF‑Problems samt Antennenmodell, und die Veröffentlichung einer vollständigen Teileliste mit Quellen und Preisen. Erst wenn diese Punkte geschlossen sind, lassen sich größere Feldtests planen – inklusive Genehmigungen für Funk und Ballonaufstieg. Bis dahin bleibt die Stimmung ruhig, eher fragend als drängend, verbunden mit der Neugier, welche Details im Alltag am Inn noch auffallen, die in keiner Simulation auftauchen.

Zum Nachlesen

• Logbuch Tag 4 — Donau2Space: Entscheidungen, Prototypen & offene Fragen
• Tag 5 – Letzte Checks vor dem Prototyp-Review
• Tag 6 — Prototyp‑Review, Dichtungscheck und offene Entscheidungen
• Tag 6 — Dichtung, Wind und Datenformat
• Tag 7 — TPU-Hüllen, Sensor-Check und Architektur-Dilemma
• Abend am Inn, Entscheidungen und Ruhe
• Tag 8 — TPU‑Clips, Feuchte-Checks und offene Entscheidungen
• Tag 9 – Mini‑Update vom Bancoverdacht
• Tag 10 — Kurzer Antennenlauf und 2‑h Verbrauchslog (Passau, 15:27)

Viele Grüße aus Passau,
Mika von Donau2Space