Wasserrakete · Bodenstation · Aufzeichnung
Das einzige Fenster zur fliegenden Rakete
Sobald die Rakete startet, ist sie unerreichbar. Alles, was man in den nächsten Sekunden erfährt, kommt durch ein Programm auf einem Laptop — und alles, was es nicht aufzeichnet, ist danach für immer weg.
Warum das mehr ist als eine Anzeige
Der naheliegende Gedanke: Die Bodenstation zeigt Zahlen an. Höhe, Geschwindigkeit, Flugphase — fertig.
Sie hat aber drei Aufgaben, und die Anzeige ist die unwichtigste davon.
Warum die Reihenfolge so herum ist
Die Anzeige darf ausfallen. Ärgerlich, aber die Daten sind trotzdem da und man schaut sie sich hinterher an.
Die Aufzeichnung darf nicht ausfallen. Fällt sie aus, ist der Flug verloren — nicht die Rakete, aber alles, was man aus ihm hätte lernen können. Deshalb wird zuerst geschrieben und erst danach gezeichnet.
Aufzeichnen: auch das Kaputte
Die Aufzeichnung speichert die rohen Bytes von der Funkstrecke, nicht die fertig ausgewerteten Werte. Das klingt umständlich und ist der Kern der Sache.
Jeder Satz trägt seine Länge vorne. Dadurch kann das Programm beim Laden einmal durchlaufen und sich merken, wo jeder Zeitpunkt liegt — danach springt der Wiedergabe-Regler sofort, statt die Datei jedes Mal neu zu durchsuchen.
Warum auch gestörte Pakete gespeichert werden
Es gibt zwei Aufzeichnungen: eine mit allem, was ankam, und eine nur mit dem, was die Prüfsumme bestanden hat.
Warum den Müll aufheben? Weil er keiner ist. Ein Paket, das die Prüfsumme nicht besteht, sagt trotzdem etwas — nämlich dass etwas ankam. Zwanzig gestörte Pakete an einer Stelle bedeuten „die Verbindung war schlecht“. Zwanzig fehlende Pakete bedeuten etwas ganz anderes: entweder ist die Rakete außer Reichweite geraten, oder der Flugrechner hat aufgehört zu senden.
Diese Unterscheidung entscheidet nach einem verunglückten Flug, wo man mit der Fehlersuche anfängt. Wirft man die kaputten Pakete beim Empfang weg, ist sie unwiederbringlich verloren.
Zwei Uhren, die nichts miteinander zu tun haben
Ein unscheinbares Detail mit großer Wirkung: Der Flugrechner kennt nur Millisekunden seit seinem eigenen Einschalten. Er hat keine Ahnung, welcher Tag heute ist. Der Laptop kennt die echte Uhrzeit, aber nicht den Moment, in dem die Rakete eine Messung gemacht hat.
Die Aufzeichnung speichert deshalb beides getrennt: die echte Startzeit einmal am Dateianfang, und dann bei jedem Satz die Zeit seit Aufzeichnungsbeginn. Sie versucht gar nicht erst, die beiden Uhren ineinander umzurechnen — das ginge nur mit einer Annahme über die Laufzeit, die man nicht belegen kann.
Beurteilen: wie zählt man, was nie ankam?
Jeder Beacon trägt eine laufende Nummer. Kommt nach 41 die 43, fehlt genau eines. So einfach der Gedanke ist, so viele Sonderfälle hat er — und alle drei sind real aufgetreten, keiner ist ausgedacht.
Wie man so etwas testet, ohne fünf Stunden zu warten
Diese Rechnung enthält kein Qt, keine Fenster, keine Grafik — sie ist reine Arithmetik in einer eigenen Datei. Genau deshalb kann man ihr einfach eine erfundene Zahlenfolge vorsetzen: erst 65 530, dann 3, dann wieder 0.
Der Überlauf wird so in Millisekunden geprüft statt nach fünf Stunden Betrieb zufällig entdeckt. Dasselbe gilt für die Flugzusammenfassung und die Paketauswertung.
Das ist der Grund für die 253 Tests in einem Programm mit Oberfläche: Nicht die Fenster werden getestet, sondern die Logik dahinter — und die wurde bewusst so geschrieben, dass sie ohne Fenster läuft.
Anzeigen: und was man dabei nicht tun darf
Auf dem Bildschirm laufen während des Flugs mehrere Darstellungen gleichzeitig: die nackten Zahlen, Höhen- und Geschwindigkeitsdiagramme, eine 3D-Ansicht mit der tatsächlichen Lage der Rakete im Raum, und eine Tafel mit den unverarbeiteten Sensorwerten.
Roh und gefiltert werden nie vermischt
Die Rakete sendet beides: die rohen Messwerte und die gefilterten Schätzungen. Es wäre verlockend, daraus einen „besten“ Wert zu mitteln.
Genau das darf nicht passieren. Der Flugrechner hält die beiden aus gutem Grund getrennt — nur die rohen Werte dürfen eine Fallschirmauslösung beeinflussen. Und die interessanteste Information nach einem Flug ist oft gerade die Abweichung zwischen beiden: Wo weichen sie voneinander ab, und warum? Ein gemittelter Wert versteckt genau das.
Deshalb zeigt die Auswertung beide nebeneinander und nie zusammengerechnet.
Wiedergabe: den Flug noch einmal ansehen
Eine Aufzeichnung lässt sich später abspielen — anhalten, vor- und zurückspringen, in anderer Geschwindigkeit. Dabei läuft dieselbe Anzeige wie live, mit denselben Diagrammen und derselben 3D-Ansicht.
Das ist mehr als bequem: Nach einem echten Flug hat man vielleicht drei Minuten Daten und Wochen Zeit, sie zu verstehen. Und weil es dieselbe Anzeige ist, wird sie beim Nachbereiten mitgetestet.
Ein Fehler, der genau hier lange verborgen lag
Die Wiedergabe verwarf jeden Beacon, der nicht exakt 50 Byte hatte. Die Rakete sendet vor dem Start und nach der Landung aber eine 54 Byte lange Variante — mit einem Zusatzfeld, das den Füllstand des Flugspeichers meldet.
Folge: Beim Abspielen fehlte die gesamte Zeit auf der Rampe und alles nach der Landung. Und zwar lautlos, weil diese Pakete nicht einmal als „übersprungen“ gezählt wurden. Eine vollständige Aufzeichnung hätte als halb leere Wiedergabe ausgesehen, ohne jeden Hinweis darauf.
Gefunden am 29. August 2026, beim Suchen nach etwas ganz anderem. Ein Test dazu existierte nicht, weil niemand auf die Idee gekommen war, dass eine Zahl wie „50“ irgendwann eine zweite Bedeutung bekommt.
Der Bauplan — und warum er so aussieht
Die Trennung ist keine Ordnungsliebe. Eine Oberfläche testet man schwer: Man müsste Fenster öffnen, Klicks nachstellen und Bilder vergleichen. Reine Rechnung testet man in Millisekunden.
Deshalb wandert alles, was rechnet, aus der Oberfläche heraus: die Verlustzählung, die Flugzusammenfassung, das Suchen von Paketgrenzen im Bytestrom. Übrig bleibt in der Oberfläche nur noch Darstellung — und wenn dort ein Fehler ist, sieht man ihn sofort mit bloßem Auge.
Ein Paket durfte nie die ganze Verbindung kosten
Beim Testen mit absichtlichem Rauschen fiel auf: Ein Paket mit einem ungültigen Zustandsbyte löste eine Ausnahme aus — direkt in der Empfangsschleife. Diese Schleife wäre daran gestorben, und mit ihr die gesamte Live-Telemetrie.
Und zwar bei schwacher Verbindung, also im Flug, also genau dann, wenn Störpakete überhaupt erst auftreten.
Daraus wurde eine Regel: Nichts, was aus empfangenen Bytes berechnet wird, darf eine Ausnahme in die Empfangsschleife werfen. Ein schlechtes Paket darf ein Paket kosten — niemals die Verbindung. Dasselbe gilt inzwischen für das Schreiben der Aufzeichnung: Ist die Festplatte voll, wird das einmal deutlich gemeldet und die Aufzeichnung beendet, statt bei jedem Paket erneut zu klagen und damit die Anzeige unbrauchbar zu machen.
Was man von unten nach oben schicken darf
Vier Befehle gehen zur Rakete: Lebenszeichen abfragen, Status abfragen, Flugspeicher löschen, und entschärfen.
| Befehl | Absicherung | Warum so |
|---|---|---|
| Lebenszeichen, Status | keine | verändert nichts |
| Flugspeicher löschen | zweistufig, und die Oberfläche verweigert es, bis in dieser Sitzung einmal exportiert wurde | löscht unwiederbringlich die einzige Kopie echter Flugdaten |
| Entschärfen | keine Nachfrage | führt in Richtung sicherer — ein Dialog davor macht eine Sicherheitsfunktion nur langsamer, genau wenn man sie schnell braucht |
| Scharfschalten | gibt es nicht, absichtlich. Nur ein physischer Schalter an der Rakete kann das. | |
Die drei Zeilen sind derselbe Gedanke in drei Abstufungen: Die Absicherung richtet sich danach, in welche Richtung ein Befehl das System bewegt — nicht danach, wie kompliziert er zu implementieren war.
Die Nacht, in der drei Messwerkzeuge falsch lagen
Am 30. August wurde der Flugspeicher zum ersten Mal wirklich ausgelesen — 25 555 Zeilen, fehlerfrei übertragen. Was die Bodenstation daraus machte, war aufschlussreich.
73 % der Datei wurden weggeworfen
Beim Laden meldete das Programm: „18 623 Zeilen konnten nicht gelesen werden und wurden übersprungen.“ Das klingt nach einer beschädigten Datei. Sie war völlig in Ordnung.
Eine Flugspeicherdatei enthält zwei Arten von Zeilen: lesbare Klartextzeilen und kompakte Rohdatensätze. Der Auswerter kannte nur die erste Art. Und weil die Rohdaten dreimal so häufig geschrieben werden, war das nicht ein Randfall, sondern der größere Teil — und ausgerechnet der wertvollere: Beschleunigung, Drehrate, Druck, Temperatur, also genau das, womit man einen Flug hinterher nachrechnen kann.
Der Entschlüsseler dafür existierte längst, in einer Nachbardatei. Es hatte nur nie jemand beides verbunden.
Und dann spielte die Bodenstation neun Flüge gleichzeitig ab
Nachdem die Datei vollständig gelesen wurde, kam der nächste Fehler zum Vorschein: Die Uhr im Flugrechner zählt ab dem Einschalten. Der Speicher wird zwischen Neustarts nicht geleert. Eine echte Datei enthält also mehrere Sitzungen, und in jeder fängt die Uhr wieder bei null an.
Das Abspielprogramm sortierte die Messpunkte nach dieser Uhr. Ergebnis: 6930 von 6932 Punkten landeten an der falschen Stelle. Was ablief, waren neun verschiedene Einschaltvorgänge ineinandergeschoben — die Höhe sprang, der Zustand wechselte hin und her, und jeder dieser Sprünge war ein Artefakt der Sortierung, nicht etwas, das die Rakete getan hätte.
Jetzt werden die Sitzungen in Dateireihenfolge hintereinandergelegt — die ist ohnehin chronologisch, weil angehängt wird — mit einer sichtbaren Lücke dazwischen. Und beim Laden steht dabei, wie viele es waren.
Viermal derselbe Denkfehler
Dieselbe Annahme — „die Uhr läuft durch“ — steckte in vier Programmen: im Abspieler, im Flugbericht, in der Nachrechnung der Filter und in der Rauschanalyse. Jedes lieferte dadurch eine falsche Dauer oder eine falsche Abtastrate.
Das Tückische daran: Die falschen Antworten sahen alle plausibel aus. 40 Hz ist eine glaubwürdige Abtastrate. 464 Sekunden ist eine glaubwürdige Dauer. Nichts blinkte rot. Aufgefallen ist es erst, weil eine Datei zufällig neun Sitzungen enthielt statt einer — genug, dass die Zahlen offensichtlich nicht mehr zusammenpassten.
Die Regel, die daraus wurde
Niemals „letzter Zeitstempel minus erster“ für eine Dauer, und niemals nach Zeitstempel sortieren. Stattdessen die einzelnen Zeitabstände aufaddieren und einen Rückwärtssprung als Sitzungsgrenze behandeln — zählen und melden.
Bei einer durchgehenden Aufnahme kommt genau dasselbe heraus. Die Korrektur kostet also nichts und macht den Unterschied nur dort, wo er besteht.
Was offen ist
- Sie wurde noch nie bei einem echten Start benutzt. Alles bisher ist Schreibtisch, wenige Meter Entfernung, ohne Hindernisse.
- Die Wiedergabe kann bisher nur die eigene Aufzeichnung laden, nicht den vollständigen Flugspeicher, der nach der Landung aus der Rakete geholt wird. Der Auswerter dafür existiert, ist aber noch nicht mit dem Dateidialog verbunden.
- Der Paketverlust wird nur als Gesamtzahl angezeigt, nicht als Verlauf über die Zeit. Gerade Letzteres wäre nach einem Flug interessant: Wo genau wurde die Verbindung schlecht?
- Die alte Programmversion wird weiterhin mitgeliefert. Ob sie verschwindet, wird nach dem ersten echten Flug entschieden — nicht vorher.
Begriffe
- Bodenstation
- Das Programm auf dem Laptop, das die Funkdaten der Rakete empfängt, aufzeichnet und darstellt.
- Laufende Nummer
- Ein Zähler in jedem Funkpaket. Nur damit lässt sich feststellen, ob etwas fehlt — sonst sieht man nur, was da ist.
- Überlauf
- Ein Zähler mit fester Stellenzahl fängt irgendwann wieder bei null an. Bei 16 Bit nach 65 536 Schritten.
- Wiedergabe (Replay)
- Eine gespeicherte Aufzeichnung noch einmal abspielen, mit derselben Anzeige wie live.
- Roh gegen gefiltert
- Unverarbeiteter Messwert gegenüber der berechneten Schätzung. Werden nie vermischt — ihre Abweichung ist selbst eine Information.
- Trennung von Logik und Oberfläche
- Rechnende Teile werden bewusst ohne Fensterbezug geschrieben. Sie sind dadurch in Millisekunden testbar statt nur von Hand bedienbar.