Mal so ganz theoretisch angenommen... Sollte jemand einen eigenen Flugschreiber bauen wollen....

Was würdet ihr euch wünschen?
Was für Daten wollt ihr über Eure Flüge wären cool?
Was wär cool?

Anyways... vielleicht gehen Wünsche ja in Erfüllung...

Viele Daten!

- Beschleunigungen in allen Achsen, in Z gerne min. 100G
- Drehraten in allen Achsen
- Luftdruck
- evtl. zusätzliche Eingänge für andere Sensorik, z.B. um einen Drucksensor (Tankdruck bei Hybriden) o.ä. anschließen zu können

Und das alles mit einigen hundert Hz Samplerate wenn das geht?

Für mich persönlich ist aber eher das User Interface (Einstellungen und Auswertungen) wichtiger, da ich da weniger selber machen kann oder es in Excel ausartet. Ich möchte z.B. aus den Flugdaten mit wenigen Inputs (Maße und Gewichte) eine Schubkurve des Motors bekommen oder Rückschlüsse ziehen können ob irgendwas vibriert hat (Flossen die Flattern, Elektronik nicht gut befestigt usw.).

Viele Grüße
Roman

Ich hatte ja mal sowas ähnliches gemacht (Telemetrie mit LoRa), wo auch aufgezeichnet wurde (Altitude, Events wie Apogee, Fallschirmausstoß, Spannungsänderung und auch Übertragung der geographischen Position bei Landung), fand zwar Anerkennung, aber ansonsten kein Interesse -> Projekt eingestellt.

Eine „schlüsselfertige Lösung“ scheint mir schwer realisierbar zu sein.

Gruß Achim

Geändert von AchimO am 13. November 2025 um 12:16

Da ich solche Flugschreiber aus dem UL Bereich kenne.

- sollte unter 1Kg bleiben
- bezahlbar sein
- sonst schließe ich mich Roman an
- Temperatur habe ich noch nicht gelesen

Zitat:

---

Original geschrieben von Roman

Viele Daten!

- evtl. zusätzliche Eingänge für andere Sensorik, z.B. um einen Drucksensor (Tankdruck bei Hybriden) o.ä. anschließen zu können

---

Was denn so für Eingänge/Ausgänge/Interfaces?
Man munkelt, ein CAN-Interface sei vorgesehen, aber man kann ja auch z.B. eein SPI und ein UART exposen, vielleicht sogar 1-2 Interrupt lines. Das wird halt im Interface schwieriger umzusetzen, wenn es ohne viele Fachkenntnis konfigurierbar sein solll, weil nunmal jederSensor anders abgefragt wird / ne andere Registermap hat.

Zitat:

---

Original geschrieben von Roman



Für mich persönlich ist aber eher das User Interface (Einstellungen und Auswertungen) wichtiger, da ich da weniger selber machen kann oder es in Excel ausartet. Ich möchte z.B. aus den Flugdaten mit wenigen Inputs (Maße und Gewichte) eine Schubkurve des Motors bekommen oder Rückschlüsse ziehen können ob irgendwas vibriert hat (Flossen die Flattern, Elektronik nicht gut befestigt usw.).

---

User Interface ist ein sehr advanceder aber wichtiger Punkt. Da hab ich mir tbh noch gar keine Gedanken zu gemacht, weil das noch so weit in der Ferne liegt... Wird wohl ersteinmal etwas rough sein und dann möglicherweise mit einer Auswertungssoftware ergänzt.
Ein User Interface im Gerät (z.B. Webserver on device etc.) ist ersteinmal aus Gründen von Platzmangel und Komplexitätsreduktion nicht vorgesehen.

Zitat:

---

Original geschrieben von AchimO

Ich hatte ja mal sowas ähnliches gemacht (Telemetrie mit LoRa), wo auch aufgezeichnet wurde (Altitude, Events wie Apogee, Fallschirmausstoß, Spannungsänderung und auch Übertragung der geographischen Position bei Landung), fand zwar Anerkennung, aber ansonsten kein Interesse -> Projekt eingestellt.

Eine „schlüsselfertige Lösung“ scheint mir schwer realisierbar zu sein.

Gruß Achim

---

Ich wollte mich erst einmal auf Aufzeichnen, Analysieren und State Estimation beschränken.
Mehr so, weil ich Bock hab, was zu frickeln, was sich sehen lassen kann.

"Schlüsselfertig" wird es vermutlich eine ganze Weile nicht werden...

Zitat:

---

Original geschrieben von Daniel Hahn

Da ich solche Flugschreiber aus dem UL Bereich kenne.

- sollte unter 1Kg bleiben
- bezahlbar sein
- sonst schließe ich mich Roman an
- Temperatur habe ich noch nicht gelesen

---

Temperatur ist ein guter Punkt, da war ich mir bisher noch nicht sicher über die Anforderungen was Anzahl/Art der Sensoren und Interfaces angeht.

Unter 1kg muss es sowieso bleiben, ich will ja hauptsächlich auf allen meinen Raketen Daten aufzeichnen und ich hab mein lvl1 noch nicht und P2 auch nicht.
Das meiste Gewicht geht wie immer für Akkus drauf, das sollte aber mit 1-2 18650 oder äquivalent reichen.

Bezahlbar ist auch in meinem Interesse... Solange mir niemand Geld schenken möchte für das Projekt bin ich immer noch ein armes Studentchen.

Ich hatte mal daran experimentiert. ESP32, BME280 (schlechte auflösung), BME390 (sehr gute auflösung, schnell auslesbar), MPU6050 (Billig, gute verfügbar, max nur 16G), LSM6DSV80X (6DoF aber "nur" 80G), ST H3LIS331DL (reiner a-Sensor, also 3DoF ohne Drehraten, aber dafür ±100/200/400G), verschiedene u-Block Module die mich zur Verzweiflung gebracht haben, da ab bestimmten Geschwindigkeiten/Beschleunigungen keine neue Daten mehr kamen.


Habe verschiedene Arten von State-Maschine durchprobiert zur Flugstatus zu erkennen, Schreiben mit SPIFF/LittleFS und ganz zum Schluss das ganze in RTOS um die Werte so gut es geht parallel abzufragen und zu speichern.

Da ich kein Informatiker bin und mir das gefährliche Halbwissen nur über Youtube, Foren und KI (war als ich angefangen habe damit 2020 noch nicht ganz so fortgeschritten) angeeignet habe, kam irgendwann mal sehr viel Frust auf, weil alles nicht sooo funktioniert hat wie ich es mir vorgestellt habe. Aber ich kann dir gerne bei Interesse Bilder, Schaltpläne, teilweise platinen und Quellcode zukommen lassen.

Sah teilweise sehr wild aus:

Zitat:

---

Original geschrieben von Cover1987

Ich hatte mal daran experimentiert. ESP32, BME280 (schlechte auflösung), BME390 (sehr gute auflösung, schnell auslesbar), MPU6050 (Billig, gute verfügbar, max nur 16G), LSM6DSV80X (6DoF aber "nur" 80G), ST H3LIS331DL (reiner a-Sensor, also 3DoF ohne Drehraten, aber dafür ±100/200/400G), verschiedene u-Block Module die mich zur Verzweiflung gebracht haben, da ab bestimmten Geschwindigkeiten/Beschleunigungen keine neue Daten mehr kamen.

---

Sehr schönes Experiment, da hast du ja jede Menge Sensoren ausprobiert! Geringe Auflösung beim BME280 kann ich zwar nicht wirklich nachvollziehen, aber ok. Da ich auch immer nach interessanten Sensoren suche, schreibe ich mir die jedenfalls mal raus und speichere mir die Datenblätter weg.

Dein Frust mit den GPS-Modulen dürfte hausgemacht sein, Halbwissen und so...
Es gibt US-Rüstungsexportbeschränkungen die dafür sorgen sollen, dass man kommerzielle GPS-Receiver nicht dazu nutzt, um Marschflugkörper oder gar ballistische Raketen(*) ins Ziel zu lenken. Im Rahmen von Stratosphärenballons war mir schon lange bewusst, dass die meisten GPS-Receiver den Betrieb einstellen sobald die Höhe mehr als 60.000 Fuss, a.k.a. ~18 km beträgt. Bei dem Ballonprojekt an dem ich beteiligt war hat der GPS-Receiver auch prompt in dieser Höhe abgeschaltet. Wir wissen daher nicht genau wie hoch wir eigentlich gekommen sind. Beim Abstieg hat der Receiver unterhalb von 18km aber wieder eingesetzt und wir konnten die Nutzlast wiederfinden.

Angeblich kann diese Restriktion mit einem Geschwindigkeitslimit von etwa 500m/s kombiniert werden. Einige gute Receiver schalten
wohl erst ab wenn die Geschwindigkeit größer als ~500m/s und die Höhe größer als 60.000 Fuss ist. Einige Ballongruppen haben definitiv GPS Tracking bis in über 32km Höhe hinbekommen.

Es würde mich aber in keinster Weise wundern, wenn es auch für die Beschleunigung Kindersicherungen gäbe um eine nicht-bestimmungsgemäße Verwendung zu verhindern. Für meinen aktuellen u-blox NEO 6 kann ich z.B. verschiedene Dynamikmodelle konfigurieren die einen Einfluss auf die Positionsbestimmung und die Datenfilterung haben:



Das agilste dürfte "Airborne <4g" sein. Ich wills ja nicht beschreien, aber das sieht für mich so aus als würde der Receiver nur Beschleunigungen bis 4g mitmachen und darüber wahrscheinlich einfach keine Daten mehr ausgeben.

Dass deine GPS-Receiver an gewissen Punkten ausgestiegen sind ist also kein Bug, sondern ein (Sicherheits-)Feature!
Wenn man die Details dazu genau wissen will hilf wohl nur RTFM...

Besten Gruß
Schmidti

(*) Zu dumm, dass du im Prinzip genau das vor hast...

Hi Schmidti,

genau darauf hinaus sind meine Recherchen hinaus gelaufen, dass GPS/GNSS für meinen/unseren Anwendungsfall (und nein, falls das FBI, der BND oder wer auch immer hier mitliest, ich möchte keine Ballistische Rakete in ein Ziel lenken oder einen Marschflugkörper bauen) keine geeignete Methode ist. Vom Paragliden oder flightradars kenn man vll. schöne Darstellungen von Flugverläufen. Das wird in unserem Fall nicht möglich sein (zu große Beschleunigungen, schnelle Höhenänderungen, wie auch immer). Das ganze rein über einen GNSS-Fix und dann anhand von der IMU zu berechnen (Sprich ein Inertial Navigation System (INS) bzw. Inertial Dead Reckoning zu modellieren) wäre mir der Aufwand "etwas" zu groß. Paar Integrale habe ich während meines Studiums mal gelöst, aber dafür gibt es ganze Unternehmen die an sowas sitzen und umsetzen. Dafür muss ich nicht meine sehr beschränkte Freizeit opfern

zu BME280: Ist schon paar Tage her, aber wenn ich mich recht erinnere war im vergleich zum BMP390 die Messwerte des 390ers um ein einiges weiter aufgelöst/genauer und die Samplerate war um einiges höher. Frag mich aber nicht mehr nach den genauen Kommastellen

(Kurze Recherche ergab: BME280 75Hz (wahrscheinlich ausreichend), BMP390 200hz )