Projektstand · Nacht auf den 30. August 2026
Stand des Flugrechners
Nach Verifikationsgrad getrennt: was auf der Hardware belegt ist, was nur im Ruhezustand, und was überhaupt nicht. Die dritte Spalte ist die wichtigste.
In der Nacht: vier Fehler, drei davon im Messwerkzeug
Der Flugrechner blieb über Nacht eingeschaltet, damit lange Tests laufen können. Das Bemerkenswerte am Ergebnis ist nicht die Zahl der Funde, sondern wo sie lagen: drei von vier steckten in den Programmen, mit denen gemessen wird, nicht in der Rakete.
| Fund | wo |
|---|---|
| Das Speicher-Kontingent galt nur für einen Einschaltvorgang — acht Neustarts füllten den Speicher trotzdem | Rakete |
| Der Auswerter verwarf 73 % jeder echten Speicherdatei | Werkzeug |
| Die Nachrechnung nahm die Abtastrate fest an und rechnete zehnmal zu schnell | Werkzeug |
| Der Regressionstest konnte nicht zweimal laufen und prüfte den Funk mit einer zweiten, kaputten Kopie | Werkzeug |
Warum das die interessantere Hälfte ist
Ein Fehler im Flugrechner macht eine Rakete kaputt. Ein Fehler im Messwerkzeug macht alle Schlüsse kaputt, die man damit gezogen hat — und er tut das lautlos, weil das Ergebnis weiterhin nach plausiblen Zahlen aussieht.
Das deutlichste Beispiel: Die Nachrechnung hatte 50 Messungen pro Sekunde fest eingebaut. Mit Daten aus dem Flugspeicher, der vor dem Start nur 5 pro Sekunde schreibt, rechnete sie alles zehnmal zu schnell und meldete „0,10 Stunden“ für eine ganze Stunde Daten. Nichts daran sah falsch aus.
Ein Ergebnis kippte dadurch
Mit richtiger Zeitrechnung gewinnt bei 5 Messungen pro Sekunde nicht mehr der große Filter, sondern der kleine (0,0244 gegen 0,0289 m/s). Bei 50 pro Sekunde ist der große siebenmal besser (0,0044 gegen 0,0317).
Das ändert die Entscheidung nicht — an Bord laufen alle Filter mit 100 pro Sekunde, die 5 sind nur die Schreibrate. Es ändert aber, wie solche Tabellen zu lesen sind: Ein Filtervergleich gilt für den Flug nur, wenn er mit der Flugrate gerechnet wurde.
Was am Tag gefunden wurde
Der Tag bestand zu einem kleinen Teil aus Bauen und zu einem großen aus Herausfinden, wo das Gebaute falsch lag. Sieben echte Fehler, jeder mit einem Test abgesichert, der gegen die kaputte Version geprüft wurde.
Der schwerste — der Filter zerstörte sich selbst
Nach 53 Minuten Laufzeit behauptete der Navigationsfilter, die Rakete sei 1,26 Milliarden Meter entfernt und bewege sich mit 1,3 Millionen Metern pro Sekunde. Der geschätzte Gyroskop-Nullpunkt lag bei −286 rad/s — das sind 16 400 °/s, bei einem Sensor, der bis 2000 misst.
Ursache: Eine Schutzmaßnahme gegen numerische Fehler war selbst der Auslöser. Sie klemmte einen Unsicherheitswert und ließ die zugehörigen Zusammenhänge stehen — genau die Operation, vor der ein Kommentar vierzig Zeilen weiter oben in derselben Datei warnt.
Es hat nie Telemetrie oder eine Flugentscheidung berührt. Der Filter ist bewusst an nichts Sicherheitsrelevantes angeschlossen. Genau deshalb war das eine Kuriosität und kein Unfall.
Die Lösung: eine Form, die den Fehler unmöglich macht
Die Unsicherheitstabelle wird nicht mehr direkt gespeichert, sondern als Produkt zweier Teile (Bierman-Thornton-UD-Faktorisierung, in den 1970ern am JPL für genau dieses Problem entwickelt). Die kritische Eigenschaft folgt dann aus der Form der Speicherung statt aus Wachsamkeit.
Auf denselben sechs Stunden echter Sensordaten: 521 Verluste der positiven Definitheit vorher, 0 nachher. Die scheinbare Wanderung des stillstehenden Boards fiel von 36 m auf 2 cm.
| Weitere Funde | Zustand |
|---|---|
disarm() warf die Rakete bedingungslos aus dem Flug — auch mitten im Aufstieg | behoben |
| Rohdaten-Telemetrie brach die Paketerkennung: 60 s echter Funk, null dekodierte Pakete | behoben |
| Ein einziges gestörtes Paket konnte den Empfangs-Thread der Bodenstation beenden | behoben |
| Der Replay verwarf lautlos jeden Vorstart- und Landebeacon | behoben |
| Der Soak-Test nutzte noch die gebrochene Paketerkennung — und meldete dadurch zu gute Werte | behoben |
| Die Antwortsuche gab den ersten Prüfsummen-Treffer zurück und verdeckte damit echte Antworten | behoben |
| Der Flugspeicher war nach 45 Minuten voll — an einem Starttag also vor dem Abheben | behoben |
Der teuerste war die Antwortsuche: Sie ließ einen funktionierenden Uplink stundenlang tot erscheinen und führte zu zwei falschen Diagnosen. Das Werkzeug, das den Irrtum scheinbar unabhängig bestätigte, enthielt eine Kopie derselben Funktion — zwei Werkzeuge mit gemeinsamem Code sind eben eine Messung.
Auf der Hardware belegt
| Größe | Wert | Bedeutung |
|---|---|---|
| Unsicherheit der Höhe | 0,033 m | der Filter kennt seine Höhe auf gut 3 cm |
| Verworfene Barometermessungen | 0–59 | von über 74 000 — er glaubt seinen Sensoren |
| Gyroskop-Nullpunkt | 0,0087 rad/s | 0,5 °/s, genau im Datenblattbereich |
| Dauerlauf ohne Zusammenbruch | > 55 min | vorher starb er nach 53 |
| Selbsttests beim Booten | alle OK | ESKF, Lagegatter, Zustandsautomat, Entschärf-Sperre |
| Fernentschärfen über Funk | 0,36 s | erster Versuch, Zustand danach IDLE und bleibt es |
| Beacon-Sequenz über 90 s | 259, 0 Lücken | kein Verlust und kein Fehltreffer |
Der Gyroskop-Nullpunkt ist der aussagekräftigste Wert, und zwar aus einem Grund, der nichts mit dem Filter zu tun hat: Das Datenblatt des Sensors gibt dafür eine Größenordnung vor. Der geschätzte Wert liegt darin. Der Filter schätzt also nicht nur stabil, sondern nachprüfbar richtig — gemessen an einer Quelle außerhalb des Projekts.
Nur im Ruhezustand oder synthetisch belegt
Die wichtigste Einschränkung des Projekts, unverändert
Fast alles ist im Ruhezustand belegt. Ein stillstehendes Board kann einen guten Schätzer nicht von einem unterscheiden, der einfach null ausgibt, wenn nichts passiert.
Und heute hat sich gezeigt, dass es sogar noch schwächer ist als das: Der Filter bestand 18 von 18 Selbsttests und einen 2,5-Stunden-Dauerlauf, und starb trotzdem nach 53 Minuten. Es fehlten zwei Zutaten, die kein einziger Test gleichzeitig hatte — spürbare Neigung und Zeit.
- Höhen- und Geschwindigkeitsfilter, Vergleich der Verfahren, Breite des Regressionsfensters — alles im Stillstand gemessen.
- Sensorausfall-Robustheit — synthetisch belegt, ein echter GNSS-Ausfall wurde nie erlebt.
- GPS-Geschwindigkeit — heute angebunden. Dass sie die Gierrichtung beobachtbar macht, ist inzwischen gemessen (Unsicherheit 3,17 → 0,39 rad), aber nur im Replay: das Board bewegt sich nie schnell genug, um die 2-m/s-Schwelle auszulösen.
- Offline-Replay — läuft mit dem echten Flugcode, aber nie gegen einen echten Flugdatensatz, weil es keinen gibt.
Ungeklärt oder unbelegt
Kommandozuverlässigkeit — teilweise geklärt, teilweise nicht
Ein Teil war mein eigener Fehler. Als der Zustand ARMED für das Fernentschärfen empfangsbereit gemacht wurde, bekam er auch eine eigene, schnellere Beacon-Rate — 2 Hz, gesetzt auf Basis einer Messung, die gegen ein bereits verklemmtes Funkmodul lief und deshalb wertlos war.
Zusammen mit 1 Hz Rohdaten sind das 3 Pakete/s bei einer Kapazität von etwa 3,5. Das Modul war dauerhaft belegt und der Entschärf-Befehl kam nicht mehr an — eine Sicherheitsfunktion, abgeschaltet durch eine ungemessene Optimierung.
Neu gemessen, mit Reset vor jedem Punkt und 60 s Einschwingzeit:
| Beacon-Rate in ARMED | Befehle pro Versuch |
|---|---|
| 2,00 Hz | 32 % |
| 1,00 Hz | 0 % |
| 0,67 Hz | 0 % |
| 0,50 Hz | 24 % |
| 0,33 Hz | 80 % |
Der Verlauf ist nicht monoton, und das ist ungeklärt. Bei 25 Versuchen je Punkt ist der Abstand zwischen 32 % und 0 % kein Rauschen — da bewegt sich noch etwas anderes als die Sendelast. Belastbar ist nur: 0,33 Hz funktioniert, alles Schnellere nicht verlässlich.
0,33 Hz ist genau die Rate, die IDLE ohnehin benutzt. Die Lösung war also keine neue Konstante, sondern keine — die Sonderbehandlung wurde wieder entfernt. Danach in ARMED gemessen: PING 18/25 (72 %) und Entschärfen beim zweiten Versuch in 0,51 s.
Am Abend geklärt: es gab nie eine Periode
Die auffällige Regelmäßigkeit — Quote alle zwölf Minuten auf null — war ein Messartefakt. Ein Sweep über das reservierte Empfangsfenster mit Kontrollpunkt am Ende zeigte es: 800 ms ergab 80 %, danach 1200 ms und 1600 ms je 0 %, und die Wiederholung der Ausgangseinstellung 400 ms ebenfalls 0 % — obwohl genau diese Einstellung zu Beginn funktioniert hatte.
Gemessen wurde also nicht der Parameter, sondern wie lange das Funkmodul vorher Ruhe hatte. Damit fällt auch die Tabelle darüber: Ihre Nicht-Monotonie ist der Fingerabdruck dieses Zerfalls, nicht der Beacon-Rate.
Reproduzierbar ist genau eine Größe: Mit Rohfunk am Boden zerfällt die
Quote (47 % → 7 % → 0 %), ohne ihn ist sie stabil (83 % / 90 % / 83 %,
Antwortzeit 375 ms). RAW_TELEMETRY_RATE_PREFLIGHT_HZ steht deshalb jetzt
auf 0. Der Flugspeicher zeichnet am Boden unverändert alles auf, und im Flug
ändert sich nichts.
Ungeklärt bleibt das Warum: Rechnerisch war der Kanal mit 1,3 von 3,5 Paketen pro Sekunde gar nicht ausgelastet. Das Modul verklemmt sich trotzdem.
Eine der widerlegten Vermutungen war doch richtig
Auch vor dieser Fehlkonfiguration schwankte die Zuverlässigkeit — 100 %, 75 % und mehrfach 0 % auf derselben Hardware. Vier Vermutungen wurden geprüft und alle für widerlegt erklärt: aufgestaute Sendewarteschlange (Nachlauf wuchs in 8 min um 0,04 s, also gar nicht), verzögert verarbeitete Befehle (20 Befehle, dann 3 min Stille → eine Antwort, danach keine), Verschlechterung mit der Laufzeit, und mein eigener Konsolen-Mitschnitt (A/B/A: 75/67/83 %, ein Paket Unterschied).
Die dritte stimmte. Sie war damals nur nicht scharf genug gemessen worden, um sich von den anderen zu unterscheiden. Mit Ruhepausen zwischen den Blöcken ist sie eindeutig: 47 % → 7 % → 0 %, in eine Richtung, ohne Rückkehr. Genau das ist die Ursache, die weiter oben steht.
Drei weitere Vermutungen kamen am Abend dazu und ließen sich sauber ausschließen: blockierende Schreibvorgänge auf demselben Kern (höchstens 180 ms gemessen), der offene USB-Konsolenmitschnitt (A/B/A widerlegte es selbst), und ein zu kleines Empfangsfenster (Kontrollpunkt am Ende der Messreihe).
Die Lehre ist unbequemer als die einzelne Korrektur: Eine Vermutung gilt nicht als widerlegt, weil eine Messung sie nicht bestätigt hat. Sie gilt als widerlegt, wenn eine Messung sie bestätigt hätte, falls sie stimmt — und die damalige konnte das nicht.
Der Downlink ist dabei durchgehend sauber — 638 Beacons mit null Prüfsummenfehlern in einem Zeitraum, in dem die Befehle bei 43 % lagen. Es betrifft also nur die Richtung nach oben.
- Funkreichweite — nie gemessen. Die Sendeleistung wurde nach einem echten Absturz von 22 auf 10 dBm gesenkt, grob drei Viertel weniger Reichweite. Muss vor einem Flug geklärt werden, bei dem verlorene Telemetrie eine verlorene Rakete bedeutet.
- Magnetometer — vorbereitet, nicht verbaut. Ohne ihn bleibt die Gierrichtung im Stillstand unbeobachtbar.
- Temperaturkompensation — die Sensornullpunkte wandern mit der Temperatur. Die Daten werden aufgezeichnet, aber nicht genutzt.
- Arm-Schalter — nicht verbaut. Derzeit schaltet sich der Flugrechner 15 s nach dem Einschalten selbst scharf, ein Behelf für Bodentests.
- Zündelektronik — existiert nicht. Die gesamte Auslöselogik ist reine Rechnung.
Was ich nicht selbst machen kann
Der Bewegungstest
Das Board eine gemessene Höhe anheben (etwa genau 1,00 m), rund 10 s halten, absenken. Idealerweise zusätzlich einmal hochwerfen und fangen, für ein echtes Freifall-Segment.
Alles Nötige wird gleichzeitig protokolliert, ein einziger Durchgang beantwortet also mehrere Fragen auf einmal: welcher Vertikalbeschleunigungs-Modus wirklich der beste ist, ob der Kalmanfilter den komplementären in Bewegung schlägt, ob das Regressionsfenster zu träge ist, und die absolute Höhengenauigkeit.
Ohne ihn bleibt alles in Stufe B.
- Bewegungstest — mit Abstand der wertvollste offene Punkt
- Löten nach dem Rework-Leitfaden — entsperrt alles Weitere
- Sendeleistung schrittweise anheben, nach jedem Schritt neu prüfen
- Reichweitentest bei der dann gewählten Leistung
- Arm-Schalter verbauen, Behelfs-Autoarm entfernen
- Checkliste für den Starttag
- Erster echter Flug
Schalterstellungen
| Schalter | Wert | Bedeutung |
|---|---|---|
| ESKF_ENABLED | an | rechnet mit, parallel zu den alten Filtern |
| TELEMETRY_ESTIMATOR | 2 | gesendet wird jetzt der ESKF — Höhe und Geschwindigkeit |
| TELEMETRY_ATTITUDE_SOURCE | 1 | auch die Lage im 3D-Bild kommt vom ESKF (anderes Bezugssystem, siehe unten) |
| MIN_FREE_BYTES_FOR_FLIGHT | 512 KB | Startbedingung: darunter meldet der Rechner beim Einschalten, dass kein Flug aufgezeichnet werden kann |
| use_ud_covariance | an | faktorisierte Kovarianz; die alte Form bleibt umschaltbar |
| ESKF_USE_GPS_VELOCITY | an | ab 2 m/s, macht die Gierrichtung beobachtbar |
| RAW_TELEMETRY_RATE_PREFLIGHT_HZ | 0 | am Boden aus — gedrosselt reichte nicht, siehe oben. Im Flug unverändert. |
| MAG_ENABLED | aus | Hardware nicht verbaut |
| DEBUG_AUTO_ARM_DELAY_MS | 15000 | Flugwert; der Behelf ersetzt den fehlenden Schalter |
Nichts davon ist mit einer sicherheitskritischen Funktion verbunden. Der neue Filter rechnet mit und wird beobachtet — die Umschaltung auf ihn ist eine bewusste Entscheidung, keine technische.