Betaflight Firmware Update: flashen ohne Datenverlust

Ein Firmware-Update in Betaflight dauert zwei Minuten. Die Arbeit davor und danach dauert länger, weil der Flash den kompletten Konfigurationsspeicher leert: Rates, Filter, Portzuweisungen und OSD-Layout sind danach weg. Wer die richtige Reihenfolge kennt, verliert dabei nichts.

Das Wichtigste in Kürze

• diff all im CLI-Tab sichert die Konfiguration, und zwar bevor der Flasher überhaupt geöffnet wird.
• Aktuell ist Betaflight 2026.6.1 vom 2. August 2026; seit 4.6 läuft die Zählung nach dem Muster JAHR.MONAT.PATCH.
• Der Flash löscht die Einstellungen, der Bootloader bleibt erhalten.
• “Full Chip Erase” gehört bei jedem Versionssprung aktiviert.
• Ohne Anlass kein Update: Eine abgestimmte Konfiguration ist mehr wert als die neueste Versionsnummer.

Wann ein Update wirklich lohnt

Es gibt drei Gründe, die ein Update tragen. Erstens eine Fehlerbehebung, die genau dein Board oder dein Bauteil betrifft. Zweitens neue Hardware, die eine Mindestversion voraussetzt, etwa ein Empfänger oder ein Drehzahlregler mit neuem Protokoll. Drittens eine Funktion, die du tatsächlich fliegen willst.

Alles andere ist Risiko ohne Gegenwert. Eine Drohne, die sauber fliegt, fliegt nach dem Update erst einmal anders, weil sich Vorgabewerte für Filter und Feedforward zwischen den Versionen verschieben. Diese Arbeit holst du dir freiwillig ins Haus.

Umgekehrt gilt: Wer ein neues Modell aufbaut, startet direkt auf der aktuellen Version. Die Einrichtung steht ohnehin an, und der Ablauf dafür steht im Ratgeber zum Betaflight Configurator.

Das Versionsschema seit 4.6

Bis Version 4.5 zählte Betaflight klassisch nach Haupt- und Nebenversion. Mit dem Sprung auf 4.6 hat das Projekt auf ein Datumsschema umgestellt: JAHR.MONAT.PATCH. Aus 4.6 wurde damit 2025.12.0, geplant sind zwei Hauptversionen pro Jahr im Juni und im Dezember.

Der Configurator folgt derselben Zählung. Firmware und Configurator sollten zusammenpassen, weil neue Parameter sonst gar nicht angezeigt werden. Die Web-Fassung unter app.betaflight.com ist immer auf dem aktuellen Stand, die Desktop-Anwendung aktualisierst du selbst.

Was der Flash im Board anfasst

Diese Aufteilung erklärt zwei Dinge. Zum einen, warum ein Board auch nach einem abgebrochenen Flash noch ansprechbar ist: Der Bootloader liegt in einem eigenen Bereich und wird beim normalen Flashen nicht angerührt. Zum anderen, warum die Konfiguration jedes Mal fällt, selbst wenn du dieselbe Version erneut aufspielst.

Schritt 1: Die Konfiguration sichern

Verbinde die Drohne ohne Flugakku per USB, öffne den CLI-Tab und gib ein:

diff all

Der Befehl listet jede Einstellung, die vom Werkszustand abweicht. Diese Ausgabe kopierst du vollständig in eine Textdatei. Ein Dateiname mit Modell und Datum zahlt sich später aus, etwa 5zoll-2026-08-16.txt.

Zwei Dinge fängt die Textdatei nicht ein, deshalb gehören sie extra gesichert:

• Screenshots der Tabs Ports, Modes und Receiver. Sie sind in zehn Sekunden gemacht und ersparen im Zweifel eine halbe Stunde Suchen.
• Die Build-Optionen, falls du eine eigene Firmware-Zusammen­stellung nutzt (etwa mit aktiviertem Magnetometer oder GPS).

Der Befehl dump gibt mehr aus als diff all, darunter board­spezifische Kalibrierungswerte. Für ein Update auf demselben Board ist diff all die passende Wahl.

Schritt 2: Flashen

Im Configurator öffnest du den Firmware-Flasher. Vier Angaben entscheiden über das Ergebnis:

1. Das Target. Es steht für das konkrete Board und muss exakt stimmen. Bei einer bereits verbundenen Drohne liest der Configurator es aus, ansonsten steht es im Datenblatt des Flight Controllers. Ein falsches Target ergibt vertauschte Pins und stumme Anschlüsse.

2. Die Version. Die aktuelle Stabilversion ist der Normalfall. Entwicklungsversionen sind für Piloten gedacht, die Fehlerberichte schreiben wollen.

3. Full Chip Erase. Haken setzen. Die Option leert den gesamten Flash-Speicher, bevor geschrieben wird. Ohne sie mischen sich Reste der alten Konfiguration mit den neuen Vorgabewerten, und die Fehler daraus sind schwer zu finden.

4. Der DFU-Modus. Der Configurator schickt das Board beim Flashen selbst in den Bootloader. Von Hand geht es über den CLI-Befehl bl.

Der Vorgang läuft danach ohne Zutun durch und dauert je nach Board 20 bis 60 Sekunden. Das USB-Kabel bleibt dabei stecken.

Schritt 3: Custom Defaults übernehmen

Nach dem Neustart fragt der Configurator, ob die Custom Defaults geladen werden sollen. Die Antwort ist ja. Dahinter stecken die Vorgaben des Board-Herstellers: Pin-Belegung, Ausrichtung des Gyroskops, vorbelegte Ports. Ohne sie startest du mit einer generischen Konfiguration, die zu deiner Platine nur zufällig passt.

Danach lohnt ein Blick in die CLI mit dem Befehl status. Er nennt Firmware-Version und Target-Namen. Stimmen beide mit dem überein, was du flashen wolltest, ist der technische Teil erledigt.

Schritt 4: Die Einstellungen zurückspielen

Jetzt kommt die gesicherte Textdatei zurück ins Board. Der Weg dorthin hängt vom Versionssprung ab.

Innerhalb einer Hauptversion (etwa 2026.6.0 auf 2026.6.1) fügst du den kompletten Block in die CLI ein und schließt mit save ab.

Über mehrere Versionen hinweg arbeitest du abschnittsweise. Erst defaults ausführen, dann in dieser Reihenfolge einfügen:

1. Portzuweisungen (serial-Zeilen)
2. Empfängerkonfiguration
3. Flugmodi (aux-Zeilen)
4. OSD-Layout
5. Rates

Nach jedem Abschnitt prüfst du die Ausgabe auf Zeilen mit ###ERROR###. Sie zeigen Parameter, die es in der neuen Version nicht mehr gibt oder die anders heißen. Diese Zeilen lässt du weg und setzt den Wert später über die Oberfläche.

PID- und Filterwerte überträgst du bei großen Sprüngen besser gar nicht. Die Vorgabewerte einer neuen Version sind auf deren eigene Filterkette abgestimmt, alte Werte hineinzukopieren erzeugt genau das Flugverhalten, das man dann tagelang sucht.

Wenn das Board nicht mehr antwortet

Ein unterbrochener Flash hinterlässt ein Board ohne funktionierende Firmware. Das sieht nach einem Totalschaden aus, ist aber in den allermeisten Fällen keiner, weil der Bootloader in einem eigenen Speicherbereich liegt.

Der Weg über die BOOT-Pads braucht ruhige Hände: Zwei Lötpunkte auf der Platine werden mit einer Pinzette überbrückt, während das USB-Kabel eingesteckt wird. Danach lässt der Configurator das Board im DFU-Modus wieder flashen.

Nach dem Update: drei Kontrollen

Erstens die Motoren. Propeller ab, dann im Motors-Tab jeden Motor einzeln antippen und Reihenfolge sowie Drehrichtung prüfen. Diese Zuordnung liegt in der Konfiguration und ist nach dem Flash zurückgesetzt.

Zweitens der Empfänger. Fernsteuerung einschalten, im Receiver-Tab alle Knüppel und Schalter durchgehen. Passt das Protokoll nicht, bleiben die Balken stumm. Bei ExpressLRS ist außerdem die Versionsfrage zwischen Sender und Empfänger relevant, dazu steht alles im Ratgeber zum ELRS Firmware-Update.

Drittens das Failsafe-Verhalten. Mit abgenommenen Propellern armen, dann die Fernsteuerung ausschalten. Die Motoren müssen sofort stoppen. Diese Prüfung kostet eine Minute und verhindert im Zweifelsfall eine unkontrolliert davonfliegende Drohne.

Der erste Flug nach einem Update gehört auf eine freie Fläche, nicht zwischen Bäume. Wer die neuen Vorgabewerte erst im Simulator kennenlernen will, findet passende Programme im Ratgeber FPV-Simulator.

Häufige Fehler beim Update

Die Sicherung wird erst nach dem Flashen erstellt. Der klassische Fehler, und er lässt sich nicht reparieren. Sobald der Flash läuft, ist die alte Konfiguration weg.

Der JSON-Export des Configurators gilt als Sicherung. Er deckt weniger ab als diff all und lässt sich nicht abschnittsweise einspielen. Als alleinige Sicherung ist er zu wenig.

Full Chip Erase bleibt aus. Spart 20 Sekunden und kostet gelegentlich einen Abend Fehlersuche.

Nach dem Flash wird sofort geflogen. Motorreihenfolge, Drehrichtung und Failsafe stehen auf Werkszustand. Der Startversuch mit falscher Motorzuordnung endet direkt nach dem Abheben.

Das Update wird ohne Grund gemacht. Wer alle zwei Wochen flasht, verbringt mehr Zeit im Configurator als in der Luft.

Fazit: sichern, flashen, zurückspielen

Ein Betaflight-Update ist unspektakulär, sobald die Reihenfolge sitzt. diff all in eine Datei, Target und Version prüfen, Full Chip Erase aktivieren, flashen, Custom Defaults übernehmen, Sicherung abschnittsweise zurück. Zwischen 15 und 30 Minuten, davon eine für den eigentlichen Flash.

Der wertvollste Handgriff daran ist die Sicherung, und sie lohnt sich auch ohne Update: Ein diff all nach jedem Abend, an dem die Drohne gut geflogen ist, verwandelt jede spätere Panne in fünf Minuten Arbeit. Wer die passende Fernsteuerungs-Firmware gleich mitzieht, findet den Ablauf für Radiomaster-Funken im Ratgeber Radiomaster Firmware-Update.