Wasserrakete · Flugspeicher · Datenrettung
Zwei Megabyte, die drei Minuten halten
Der Funk überträgt ein paar Stichproben pro Sekunde. Die vollständigen Messdaten passen da nicht durch — die schreibt die Rakete in ihren eigenen Speicher. Und der ist kleiner, als man denkt.
Warum überhaupt zwei Wege?
Die Rakete schreibt ihre Daten doppelt auf: einmal per Funk zum Boden, einmal in den eigenen Speicher. Das wirkt verschwenderisch und ist es nicht — die beiden Wege haben gegensätzliche Stärken.
| Funk | Flugspeicher | |
|---|---|---|
| Menge | wenige Stichproben pro Sekunde | bis zu 100 vollständige Messungen pro Sekunde |
| Verfügbar | sofort, während des Flugs | erst nach dem Wiederfinden |
| Überlebt | auch den Verlust der Rakete | nur, wenn man sie zurückbekommt |
Die Arbeitsteilung
Der Funk ist die Versicherung: Landet die Rakete im Baum, im See oder auf einem fremden Grundstück, sind die per Funk empfangenen Stichproben alles, was bleibt. Wenig ist unendlich viel mehr als nichts.
Der Flugspeicher ist die Wahrheit: hundertmal pro Sekunde, alle Rohwerte, ungefiltert. Damit lassen sich nach dem Flug auch völlig andere Verfahren durchrechnen als die, die damals an Bord liefen — man kann einen besseren Filter bauen und ihn gegen den echten Flug prüfen, ohne noch einmal starten zu müssen.
Die Rechnung, die man vorher machen muss
Der Speicher fasst 2 Megabyte. Klingt nach viel. Bei 100 Messungen pro Sekunde reicht er für etwa dreieinhalb Minuten.
Für einen Flug ist das reichlich — eine Wasserrakete ist nach einer Minute wieder unten. Das Problem liegt woanders.
Der Fehler, der wirklich passiert ist
Bei einem Prüflauf blieb der Flugrechner rund 13 Minuten im Zustand „Aufstieg“ hängen — nicht weil er flog, sondern weil ein Schwellwert auf dem Tisch ausgelöst hatte.
In diesem Zustand schreibt er mit 100 Messungen pro Sekunde. Nach dreieinhalb Minuten war der Speicher voll. Die restlichen zehn Minuten schrieb er ins Leere.
Und das ist der eigentliche Punkt: Er hat es nicht gemerkt. Die Aufzeichnung hörte auf, das Programm lief weiter, und von außen sah alles normal aus. Erst als jemand auf den Gedanken kam, den Füllstand abzufragen, kam es heraus.
Zwei Konsequenzen daraus
Erstens meldet der Flugrechner den Füllstand jetzt in jedem Funkpaket vor dem Start. Damit sieht man am Boden, bevor man startet, ob überhaupt noch Platz ist. Ein Fehler, den man nur durch gezieltes Nachfragen findet, wird zu einem, der einem ins Auge springt.
Zweitens wurde die Schreibrate im Wartezustand von 10 auf 2 Messungen pro Sekunde gesenkt. Eine realistische Wartezeit auf der Rampe füllte sonst den Speicher, bevor die Rakete überhaupt gestartet war — man hätte den ganzen Flug mit einem bereits vollen Speicher geflogen.
Die zweite Maßnahme hat allerdings nicht gehalten. Warum, steht gleich hier darunter — und es ist der lehrreichere Teil der Geschichte.
Derselbe Fehler, ein halbes Jahr später, durch die Hintertür
Am 29. August 2026 stand der Flugrechner 45 Minuten lang scharf auf dem Tisch. Danach stand in der Konsole:
2600 fehlgeschlagene Schreibversuche in Folge. Der Speicher war wieder voll.
Die Ursache war eine Zeile, die kurz vorher hinzugekommen war: Zusätzlich zu den lesbaren Zeilen sollten vor dem Start auch Rohdaten mitgeschrieben werden, fünfmal pro Sekunde. Eine gute Idee — nur hatte niemand nachgerechnet, was sie kostet:
2 097 152 Bytes geteilt durch 785 Bytes pro Sekunde sind 2672 Sekunden — 45 Minuten. Genau die Zeit, die das Board dagestanden hatte. Hier ist nichts Feines oder Überraschendes passiert: Die Rechnung war schlicht nicht gemacht worden.
Warum das schlimmer ist, als es klingt
Der Fehler ist nicht „der Speicher läuft irgendwann voll“. Der Fehler ist wann er voll läuft.
An einem Starttag steht der Flugrechner deutlich länger als 45 Minuten unter Strom: Rakete aufbauen, Wasser einfüllen, Druck aufbauen, Rampe ausrichten — und dann wartet man auf eine Windpause. Eine Stunde ist normal, zwei sind nicht ungewöhnlich.
Das heißt: Der Speicher wäre voll gewesen, bevor die Rakete startet. Das Board hätte dabei völlig gesund ausgesehen — es funkt, es antwortet auf Befehle, alle Anzeigen normal — und hätte vom Flug, dem einzigen Teil des Tages, auf den es ankommt, nichts aufgezeichnet.
Warum die naheliegende Lösung die falsche ist
Der erste Reflex ist, die Rate wieder zu senken. Das wurde bewusst nicht gemacht, und der Grund lohnt sich:
Eine niedrigere Rate verschiebt den Ausfall nur
Bei 1 Messung pro Sekunde statt 5 ist der Speicher nach etwa vier Stunden voll statt nach 45 Minuten. Der Ausfall ist nicht weg — er wartet nur länger. Der Nächste, der das Board über Mittag anlässt, findet genau dasselbe leere Flugprotokoll.
Schlimmer noch: Weil es dann so viel länger dauert, sieht es nicht mehr nach demselben Fehler aus. Man hätte ihn ein zweites Mal von vorne gesucht.
Die Lösung: ein Budget statt einer Rate
Die Aufzeichnung vor dem Start bekommt ein festes Kontingent von 256 Kilobyte — ungefähr fünf Minuten. Ist es aufgebraucht, pausiert sie und sagt das einmal in der Konsole.
Flugphasen werden nie gedrosselt. Wenn die Rakete fliegt, wird geschrieben, Punkt. Das Budget existiert ja gerade dazu, dass in diesem Moment noch Platz da ist.
Das ist eine Zusicherung, die eine Rate niemals geben kann: Egal wie lange das Board auf der Rampe steht — beim Abheben sind mindestens 1,75 MB frei. (Genauer: solange das Board zwischendurch nicht aus war — siehe den Nachtrag gleich unten.) Das reicht für etwa drei Minuten bei voller Geschwindigkeit, also für ein Vielfaches eines Wasserraketenflugs.
Nachtrag: Diese Zusicherung war zu stark formuliert
Der Satz oben stimmt für einen Einschaltvorgang. Über mehrere hinweg nicht — und das kann er auch gar nicht. Ein Kontingent pro Durchlauf kann keinen Platz zurückgeben, den ein früherer Durchlauf schon verbraucht hat.
In der Nacht auf den 30. August war der Speicher wieder voll: 2 093 056 von 2 097 152 Bytes. Acht Neustarts beim Testen, jeder mit seinem eigenen frischen 256-KB-Kontingent, in einen Speicher, den niemand dazwischen geleert hatte. Acht mal 256 KB sind zwei Megabyte.
Die Ergänzung: eine Startbedingung statt einer weiteren Grenze
Eine dritte Grenze hätte dasselbe Problem noch einmal. Deshalb prüft der Flugrechner jetzt beim Einschalten schlicht nach, ob überhaupt Platz für einen Flug da ist — 512 KB, etwa 63 Sekunden bei voller Geschwindigkeit:
Dazu die Anweisung, was zu tun ist, und die Vorstart-Aufzeichnung bleibt aus, damit sie den Rest nicht auch noch aufbraucht.
Der Unterschied ist der Zeitpunkt. Die alte Warnung kam, wenn Schreibvorgänge scheiterten — an einem Starttag also, nachdem die Rakete aufgebaut, befüllt und unter Druck gesetzt war. Die neue kommt beim Einschalten, wenn man noch etwas dagegen tun kann.
Und es bleibt eine Sache, die kein Programm lösen kann: Wenn der Speicher voll ist, muss ihn jemand leeren. Der Flugrechner kann das sichtbar machen, früh und laut. Entscheiden muss es ein Mensch — es könnten ja die Daten des letzten Fluges darauf sein.
Der Unterschied in einem Bild
Eine Rate ist die Anweisung „iss langsam, dann reicht der Vorrat länger“. Wie lange er reicht, hängt davon ab, wie lange gewartet wird — und das weiß vorher niemand.
Ein Budget ist die Anweisung „von diesem Vorrat darfst du 256 Gramm anrühren, der Rest ist für unterwegs“. Wie lange gewartet wird, spielt dann keine Rolle mehr. Der Rest ist noch da, wenn es losgeht.
Beide Hälften wurden nachgewiesen
Dass das Budget greift, zeigte die echte Hardware: Nach 8,1 Minuten stoppte die Aufzeichnung bei 262 212 Bytes — und danach kam kein einziger fehlgeschlagener Schreibversuch mehr, wo es vorher 2600 waren.
Dass der Flug trotzdem aufgezeichnet wird, ist die wichtigere Hälfte — und die kann man ohne Rakete nicht vorführen. Dafür läuft bei jedem Einschalten ein Selbsttest, der jede einzelne Flugphase durchgeht und prüft, dass sie auch bei aufgebrauchtem Budget noch schreibt. 20 von 20 Prüfungen bestanden auf dem echten Board.
Die Flugphasen sind in diesem Test einzeln aufgezählt statt in einer Schleife durchlaufen. Wer später eine neue Phase ergänzt, ohne an die Aufzeichnung zu denken, sieht dann eine fehlende Zeile — statt dass der Test stillschweigend durchgeht.
Die Schreibrate hängt an der Flugphase
| Phase | Messungen pro Sekunde | warum |
|---|---|---|
| Untätig | 1 | nichts passiert |
| Scharf, wartend | 2 + 5 | lesbare Zeilen und Rohdaten — zusammen begrenzt durch das 256-KB-Budget |
| Schubphase | 100 | hier passiert alles, und zwar schnell |
| Steigflug, Scheitelpunkt | 100 | der Moment der Fallschirmentscheidung |
| Sinkflug | 50 → 20 | langsamer, weniger Detail nötig |
| Gelandet | 1 | fertig |
Der Gedanke dahinter: Speicherplatz dorthin, wo die interessanten Dinge passieren. Die Sekunde um den Scheitelpunkt herum ist mehr wert als zehn Minuten Warten auf der Rampe.
Wie die Daten wieder herauskommen
Die Rakete ist zurück, die Daten sind im Speicher. Jetzt müssen zwei Megabyte über ein USB-Kabel auf den Laptop — und dabei darf kein einziges Byte verloren gehen oder verfälscht werden.
Eine stärkere Prüfsumme als beim Funk
Der Funk benutzt eine 8-Bit-Prüfsumme, hier sind es 16 Bit. Der Unterschied ist groß: Eine zufällige Verfälschung rutscht bei 8 Bit mit einer Chance von 1 zu 256 durch, bei 16 Bit mit 1 zu 65 536.
Warum der Aufwand hier und nicht beim Funk? Weil beim Funk jedes Byte Sendezeit kostet und ein verlorenes Paket im nächsten wieder aufgeholt wird. Beim Auslesen gibt es keinen nächsten — das sind die einzigen Daten des Flugs, und eine unbemerkte Verfälschung darin wäre unbemerkbar falsch.
Drei Fehler, die nur ein voller Speicher zeigte
Die Übertragung wurde zuerst mit einem kurzen Testprotokoll geprüft. Alles gut. Erst gegen einen wirklich vollen Speicher — 26 282 Zeilen — kamen drei echte Fehler heraus, die bei kurzen Daten unsichtbar blieben.
Einer davon ist besonders lehrreich: Das Empfangsprogramm auf dem Laptop verwarf nach jedem Block die Bytes, die es schon vom nächsten Block gelesen hatte. Bei wenigen Blöcken fällt das nicht auf. Bei vielen scheiterte jeder zweite Block an der Prüfsumme — während eine Mitschrift der Leitung zeigte, dass 407 von 411 Blöcken einwandfrei angekommen waren. Die Daten waren nie das Problem.
Die Lehre: Ein Test mit einer kleinen Datenmenge prüft die Mechanik, nicht die Wirklichkeit. Nach der Korrektur: 26 282 von 26 282 Zeilen, kein fehlender Block, jede Prüfsumme richtig, in zehn Sekunden.
Was bei einem Stromausfall passiert
Eine Rakete landet nicht immer sanft. Ein Akkukontakt kann sich lösen, der Rechner kann abrupt ausgehen — mitten im Schreiben.
Deshalb wurde genau das geprüft, und zwar nicht simuliert: Beim laufenden Schreiben wurde das USB-Kabel physisch herausgezogen. Ergebnis: Das Dateisystem überlebt, die bis dahin geschriebenen Daten sind lesbar, nur der allerletzte unvollständige Eintrag fehlt.
Warum das nicht selbstverständlich ist
Viele Dateisysteme nehmen übel, wenn man ihnen mitten im Schreiben den Strom nimmt — im schlimmsten Fall ist danach die ganze Datei unlesbar, nicht nur der letzte Eintrag.
Das hier verwendete System ist für genau diesen Fall gebaut. Aber: „ist dafür gebaut“ ist keine Messung. Deshalb wurde am Kabel gezogen, statt dem Datenblatt zu glauben.
Was offen ist
- Ein echter Flug wurde nie aufgezeichnet. Alle bisherigen Daten sind Schreibtischdaten. Die 100 Messungen pro Sekunde in der Aufstiegsphase sind noch nie gegen einen wirklichen Aufstieg gelaufen.
- Vor dem Start kann der Speicher nicht mehr volllaufen — dafür sorgt das Budget. Während eines Fluges aber schon: Bleibt der Rechner versehentlich in einer Flugphase hängen, schreibt er weiter mit voller Geschwindigkeit, und nach dreieinhalb Minuten ist Schluss. Das ist Absicht — ein Budget, das eine echte Flugaufzeichnung abschneidet, wäre schlimmer als das Problem, das es löst. Der Füllstand im Funkpaket macht diesen Fall sichtbar, verhindern tut er ihn nicht.
- Das ausgelesene Protokoll lässt sich noch nicht direkt in der Bodenstation abspielen. Der Auswerter existiert, ist aber noch nicht mit dem Dateidialog verbunden.
- Nur die Rohdatenzeilen haben eine Formatversion. Die menschenlesbaren Zeilen sind frei formatiert — unproblematisch, aber gut zu wissen, wenn jemand ein Auswerteprogramm dafür schreibt.
Begriffe
- Flash-Speicher
- Der Speicher, der auch ohne Strom erhalten bleibt — wie in einem USB-Stick. Hier 2 Megabyte, fest im Rechner verbaut.
- Partition
- Ein fest abgetrennter Bereich des Speichers. Hier: 1,5 MB für das Programm, 2 MB für Flugdaten. Der eine kann dem anderen nichts wegnehmen.
- Adaptive Schreibrate
- Die Aufzeichnung wird je nach Flugphase schneller oder langsamer. Speicherplatz wandert dorthin, wo die interessanten Dinge passieren.
- Blockweise Übertragung
- Daten werden in Abschnitten mit eigener Prüfsumme übertragen. Ein Fehler kostet dann einen Abschnitt statt der ganzen Datei.
- 16-Bit-Prüfsumme
- Erkennt Verfälschungen deutlich zuverlässiger als die 8-Bit-Variante des Funks: eine Chance von 1 zu 65 536 statt 1 zu 256, dass ein Fehler durchrutscht.