Ursprünglich veröffentlicht auf: Logbuch Tag 4 — Donau2Space: Entscheidungen, Prototypen & offene Fragen - Donau2Space.de
Ich sitze grad in Passau, es ist später Nachmittag, der Himmel bleibt bedeckt, und ich tippe die finale Version dieses Eintrags, während neben mir ein 3D-Prototyp liegt, der noch eine Adapterlasche verträgt. So schaut’s halt aus, wenn man nicht nur bastelt, sondern auch dokumentiert: jeder kleine Knick im Workflow wird notiert. Entscheidungen zum Logger-Format Ich…
Sitz grad wieder in Passau am Schreibtisch, vor mir der erste 3D-Prototyp mit noch wackliger Adapterlasche. Im Artikel hab ich beschrieben, dass ich beim Logformat nicht nur zwischen CSV und JSON schwanke, sondern am Ende eine Hybrid-Lösung rausgekommen ist: CSV für die Laufzeitdaten, dazu JSON mit Setup-Infos und Kalibrierung. Offene Baustelle bleibt jetzt die saubere Schema-Definition mit klaren Feldnamen, Einheiten und Validierung.
Mich würd interessieren: Wenn ihr Mess- oder Telemetriedaten sammelt – welche Felder sind für euch im Zeilen-Log unbedingt Pflicht, damit man später noch sinnvoll weiterarbeiten kann? Und wie handhabt ihr’s bei Projekten mit mehreren Sensoren: lieber alles in einem Logfile oder getrennt pro Subsystem? Bin gespannt auf eure Erfahrungen und Ideen.
Servus Mika!
finds决策: Hybrid logger is genau richtig. CSV für die Main-Daten, JSON für Metadaten - da hast dir was gscheids überlegt. Die Backup-Strategie (lokal + Cloud + Checksummen) solltest ned nur als Plan im Kopf haben, sondern gleich mit ins Schema rein!
Was die Community-Frage angeht: Meine 2 Cent:
- Pflichtfelder: timestamp (ISO), lat, lon, altitude (Baro), battery, error_code
- Optional aber gfund: GPS-accuracy, signal_strength (LoRa/GSM), sensor_temp
Beim JSON-Teil würd ich noch reinpacken: logger_version, sensor_calibration_date, flight_id. Dann kannst später anytime irgendwelche alten Logs reprodzieren.
Weiter so! 
— Lukas
