Kurz gesagt: Betaflight blockiert das Armen, solange mindestens ein „Arming Disable Flag“ gesetzt ist. Die häufigsten sind RXLOSS (kein Signal vom Empfänger), THROTTLE (Gas nicht ganz unten), ANGLE (Kopter zu schief) und MSP (Configurator verbunden). MSP siehst du fast immer, solange der Configurator verbunden ist, CLI, sobald du die Kommandozeile geöffnet hast – beides ist dann normal.
Beim Umstellen meiner Kopter auf einen gemeinsamen Standard hing ich selbst an NOPREARM: In Betaflight war noch ein alter Prearm-Schalter eingetragen, obwohl der Prearm längst in meiner Funke saß. Genau für solche Momente ist diese Seite – einmal einfügen, was die Drohne sagt, und du weißt, wo du suchen musst.
Der Flag-Decoder
Kopiere die Zeile aus dem CLI-Befehl status, die Warnung aus dem OSD oder die Badges aus dem Setup-Tab des Configurators hier hinein. Der Decoder erkennt die Flags und sagt dir, was zu tun ist. Alternativ: Piep-Code eintragen.
status aus, wertet die Flags aus und behebt die Ursache Schritt für Schritt – Props ab, Backup zuerst. Wo du die Flags siehst
- Configurator, Setup-Tab: Kasten „Arming Disable Flags“. Ist nichts gesetzt, steht dort „Arming Allowed“. Achtung: Der Configurator benutzt teils andere Namen (z. B.
BAD_RX_RECOVERYstattNOT_DISARMED) – der Decoder kennt beide. - CLI: Befehl
status, Zeile „Arming disable flags:“ mit den Namen in der Reihenfolge der Bits. Sobald du das CLI öffnest, ist dort selbstCLIgesetzt – das verschwindet erst nach einem Neustart (exit). - OSD: Solange der Arm-Schalter umgelegt ist, zeigt das Warnungs-Element den Grund an. Bei mehreren Flags wechselt die Anzeige etwa jede halbe Sekunde.
- Piepen: Nach einem gescheiterten Arm-Versuch piept Betaflight einen Code. Zuerst kommen ein paar schnelle Aufmerksamkeits-Pieps (bis 4.5 fünf, ab 2025.12 vier), dann der eigentliche Code: Jeder lange Piep zählt 5, jeder kurze 1. Die Summe ist die Nummer des wichtigsten Flags – 3 kurze heißt RXLOSS, 1 langer und 3 kurze heißt THROTTLE. Trag lange und kurze oben getrennt ein.
Die häufigsten Flags in 30 Sekunden
| Flag | Bedeutet | Erste Maßnahme |
|---|---|---|
RXLOSS | kein Signal vom Empfänger | Reihenfolge: erst Sender an, dann Kopter-Akku |
MSP | Configurator oder App hält die Sperre | Im Configurator auf „Disconnect“ klicken, dann USB abziehen |
ARMSWITCH / ARM_SWITCH | Arm-Schalter erst zurücklegen | Alle anderen Flags beheben, dann Arm-Schalter AUS und wieder AN |
THROTTLE | Gas nicht ganz unten | Receiver-Tab öffnen: Gas ganz unten muss deutlich unter 1050 liegen (ideal ~1000) |
ANGLE | Kopter steht zu schief | Kopter waagerecht hinstellen |
CLI | Kommandozeile war offen | CLI mit „exit“ verlassen – das startet den FC neu und löscht das Flag |
NOPREARM | Prearm nicht aktiv | Prearm-Taster halten/aktivieren, dann Arm-Schalter |
BADRX / NOT_DISARMED | Signal zurück, Schalter noch an | Arm-Schalter auf AUS stellen (das löscht das Flag, sobald das Signal stabil ist) |
Die Liste unten gilt für Betaflight 4.4, 4.5, 2025.12 und 2026.6. Die Nummern (Bits) sind über die Versionen fast gleich geblieben – nur das Flag für den Arm-Schalter rutscht seit 2025.12 mit jeder Version nach hinten, weil neue Flags davor eingefügt wurden. Wichtig ist das nur für den Piep-Code.
Die Klassiker
Diese Flags sieht fast jeder irgendwann – meist beim Einrichten oder direkt auf dem Feld.
RXLOSS – kein Signal vom Empfänger
Der Flight Controller (FC) bekommt gerade keine gültigen Daten vom Empfänger. Das ist das häufigste Flag überhaupt – meist ist einfach der Sender aus, nicht gebunden oder der Empfänger falsch konfiguriert.
Typische Ursachen
- Fernsteuerung aus / falsches Modell gewählt / nicht gebunden
- Empfänger nicht mit Strom versorgt oder falsch verdrahtet (RX-Pad, UART)
- Ports-Tab: das Häkchen „Serial RX“ fehlt oder sitzt am falschen UART (der Schnittstelle, an der der Empfänger angelötet ist)
- Receiver-Tab: falsches Empfänger-Protokoll (im Configurator „Serial Receiver Provider“, z. B. CRSF statt SBUS)
- Empfänger meldet Failsafe (ELRS: Sender noch nicht verbunden)
- Direkt nach dem Einschalten: das Flag bleibt gesetzt, bis für die Recovery-Zeit gültige Daten kamen (2025.12: failsafe_recovery_delay, Standard 0,5 s; 4.4: rxDataRecoveryPeriod 1,0 s)
- Im Flug: Paketverlust > 150 ms (RXLOSS_TRIGGER_INTERVAL) setzt das Flag sofort – im OSD dann ein Zeichen für Reichweitenrand
So löst du es
- Reihenfolge: erst Sender an, dann Kopter-Akku
- Receiver-Tab öffnen: bewegen sich die Kanalbalken? Wenn nein: Verkabelung, UART, Serial-RX-Häkchen, Provider prüfen
- Binden wiederholen; bei ELRS Bind-Phrase/Version von TX-Modul und RX vergleichen
- Bei Bedarf 1–2 Sekunden warten, bis das Signal als „stabil“ gilt
- Antennen, Stromversorgung des RX (4,5–5 V) prüfen
Achtung: Erscheint RXLOSS im Flug im OSD, sofort umkehren – die Verbindung steht kurz vor dem Failsafe.
THROTTLE – Gas nicht ganz unten
Der Gas-Kanal ist nicht „unten“: Der Wert liegt bei oder über min_check (Standard 1050 µs). Betaflight armt nur mit Gas auf Minimum, damit die Motoren nicht sofort hochdrehen.
Typische Ursachen
- Gas-Stick nicht ganz unten
- Sender-Endpunkte falsch: Gas-Minimum liefert z. B. 1080 statt 1000 µs (im Receiver-Tab sichtbar)
- „Erweiterte Wege/Extended Limits“ oder Subtrim am Sender verstellt
- Kanalzuordnung (Channel Map AETR/TAER) falsch – ein anderer Stick landet auf „Throttle“
- 3D-Modus: Gas muss in der Mitte (midrc ± deadband3d_throttle) stehen
So löst du es
- Receiver-Tab öffnen: Gas ganz unten muss deutlich unter 1050 liegen (ideal ~1000)
- Sender kalibrieren, Endpunkte/Trim zurücksetzen, Channel Map prüfen
- Nicht einfach min_check hochdrehen: Der Wert schützt dich davor, mit Gas oben zu armen – die Ursache liegt fast immer am Sender.
Achtung: Gas beim Armen immer ganz unten; Airmode dreht die Motoren nach dem Armen ohnehin an.
ANGLE – Kopter steht zu schief
Der Kopter steht zu schräg: Die Neigung ist größer als small_angle (Standard 25°, Configurator: „Maximum ARM Angle“). Das verhindert Starts vom Hang, aus der Hand oder auf dem Rücken.
Typische Ursachen
- Kopter steht auf unebenem Untergrund oder liegt auf dem Rücken (nach Crash)
- Accelerometer nicht kalibriert oder Board-Ausrichtung (board_align_*) falsch – der FC „denkt“, er sei schief
- Lage noch nicht berechnet (attitudeIsEstablished) kurz nach dem Boot
- Bug-Fall: Gyro liefert Nullwerte (Issue #7587)
So löst du es
- Kopter waagerecht hinstellen
- Setup-Tab: Accelerometer auf ebener Fläche kalibrieren; 3D-Modell im Setup-Tab muss der Realität folgen
- Board-Ausrichtung prüfen, wenn das Modell im Setup-Tab schief steht
- Wer aus der Hand/vom Hang starten will: small_angle = 180 setzt die Prüfung aus (Configurator: Maximum ARM Angle 180) – nur bewusst nutzen
- Nicht im Turtle-/Crashflip-Modus: bei aktivem Crashflip-Schalter wird ANGLE absichtlich ignoriert
Achtung: Mit small_angle 180 armt der Kopter auch auf dem Rücken – Propeller können dann beim Armen am Boden reißen.
BOOTGRACE – gerade erst eingeschaltetoft harmlos
Der FC ist gerade erst gestartet. In den ersten Sekunden (pwr_on_arm_grace, Standard 5 s) ist Armen gesperrt, damit ESCs, Sensoren und Funk sauber hochfahren.
Typische Ursachen
- Arm-Versuch innerhalb der ersten 5 Sekunden nach dem Anstecken
- Bei DShot zusätzlich: DShot-Kommandos (Streaming) sind noch nicht bereit – dann dauert es minimal länger
So löst du es
- Einfach ein paar Sekunden warten
- Arm-Schalter AUS und wieder AN (sonst bleibt ARMSWITCH stehen)
- Optional: pwr_on_arm_grace ändern (0–30 s) – 0 ist nicht empfehlenswert
NOPREARM – Prearm nicht aktiv
Es ist ein PREARM-Modus konfiguriert, aber der Prearm-Schalter/Taster ist nicht aktiv – oder er wurde nach dem letzten Disarmen nicht neu betätigt. Prearm ist eine „Zwei-Hand-Sicherung“ gegen versehentliches Armen.
Typische Ursachen
- PREARM im Modes-Tab angelegt, Taster nicht gedrückt
- Nach dem Disarmen muss Prearm erneut betätigt werden (außer prearm_allow_rearm = ON)
- Prearm-Bereich im Modes-Tab passt nicht zum Schalterwert
So löst du es
- Prearm-Taster halten/aktivieren, dann Arm-Schalter
- Nach jeder Landung: Arm AUS, Prearm neu betätigen, Arm AN
- Wenn kein Prearm gewünscht: den Modus im Modes-Tab entfernen
- prearm_allow_rearm = ON, wenn man ohne erneutes Prearm wieder armen will (z. B. nach Failsafe)
CALIB – Sensor kalibriert noch
Ein Sensor kalibriert gerade noch: Gyro (direkt nach dem Start), Accelerometer, Barometer oder Kompass. Der Kopter muss dabei ruhig stehen.
Typische Ursachen
- Kopter wurde beim Einschalten bewegt – Gyro-Kalibrierung startet immer wieder neu
- Starke Vibrationen/Wind, Kopter in der Hand
- Kompass-Kalibrierung läuft
- gyro_cal_on_first_arm aktiv: Kalibrierung beginnt erst beim ersten Arm-Versuch
- Selten (Forenberichte): CALIB bleibt hängen, wenn DShot-Bitbang oder ESC-Telemetrie Probleme machen
So löst du es
- Kopter auf festen Untergrund stellen und ein paar Sekunden nicht anfassen
- Akku ab- und anstecken, wieder ruhig stehen lassen
- Bei Kompass: Kalibrierung abschließen oder Mag deaktivieren
- Bleibt es dauerhaft: Gyro-Rauschen/Defekt prüfen (Blackbox, gyro_calib_noise_limit)
CLI – Kommandozeile war offenoft harmlos
Die Kommandozeile (CLI) wurde geöffnet. Aus Sicherheitsgründen bleibt das Flag bis zum Neustart gesetzt – auch wenn man den CLI-Tab wieder verlässt.
Typische Ursachen
- CLI-Tab im Configurator geöffnet (auch nur zum „status“-Schauen)
- CLI über Lua-Script/Terminal am Sender geöffnet
So löst du es
- CLI mit „exit“ verlassen – das startet den FC neu und löscht das Flag
- Alternativ Akku ab-/anstecken
MSP – Configurator oder App hält die Sperreoft harmlos
Der Configurator (oder ein anderes MSP-Programm) hat das Armen aktiv gesperrt. Das passiert automatisch, sobald der Configurator verbunden ist und z. B. speichert oder den Motors-Tab öffnet – damit auf der Werkbank nichts anläuft.
Typische Ursachen
- USB-Kabel steckt und Configurator ist verbunden
- Configurator wurde geschlossen/Kabel gezogen, ohne „Disconnect“ – das Flag wurde nie per MSP zurückgenommen
- Bluetooth-/WiFi-MSP-Modul, SpeedyBee-App, Lua-Script oder ein Companion-Computer hält eine MSP-Verbindung offen
- MSP-Passthrough/Telemetrie-Bridge auf einem UART aktiv
So löst du es
- Im Configurator auf „Disconnect“ klicken, dann USB abziehen
- Bleibt MSP hängen: Akku ab- und anstecken (Reboot löscht das Flag)
- Ports-Tab prüfen: MSP nur dort aktiv lassen, wo es gebraucht wird
- Bei Fernanzeige (OSD im Feld) ohne USB: MSP bedeutet dann ein Funk-/Bluetooth-Modul oder eine App sperrt
Achtung: Mit Propellern nie im Configurator armen. Das Motors-Tab hebt das MSP-Flag bewusst auf, wenn man den Motortest freischaltet.
ARMSWITCH / ARM_SWITCH – Arm-Schalter erst zurücklegenoft harmlos
Der Arm-Schalter stand auf AN, während ein anderes Flag aktiv war. Dieses Meta-Flag bleibt so lange stehen, bis der Schalter einmal auf AUS geht – auch wenn die eigentliche Ursache längst behoben ist. Es ist deshalb fast immer „Begleiter“ eines anderen Flags. Das gilt fürs Armen per Schalter; wer mit den Sticks armt, sieht dieses Flag nicht.
Typische Ursachen
- Arm-Schalter beim Einschalten schon auf AN
- Arm-Versuch, während RXLOSS/THROTTLE/ANGLE/BOOTGRACE usw. aktiv waren
- Selten allein: nach einem GPS-Rescue-Abbruch, einer Landung mit automatischem Disarm oder dem Ende einer Failsafe-Landung
So löst du es
- Alle anderen Flags beheben, dann Arm-Schalter AUS und wieder AN
- Steht ARMSWITCH allein: Schalter einmal aus/an; bleibt es, Arm-Bereich im Modes-Tab prüfen (AUX-Wert muss außerhalb des Bereichs sein, wenn „aus“)
Wenn nur ARMSWITCH übrig bleibt: Beim Armen per Schalter will Betaflight, dass du ihn einmal zurücklegst. Das ist Absicht: So startet ein Kopter nie, nur weil der Schalter schon oben war, als der Akku reinkam.
Nach einem Vorfall
Etwas ist passiert – Funkabriss, Absturz, Turtle – und Betaflight will, dass du einmal bewusst disarmst.
FAILSAFE – Failsafe hat disarmt
Der Failsafe (Stufe 2) hat ausgelöst und den Kopter disarmt; bis der Funk stabil zurück ist, darf nicht neu gearmt werden.
Typische Ursachen
- Funkverbindung war weg und Failsafe hat gelandet/abgeschaltet
- Failsafe-Schalter (BOXFAILSAFE) wurde benutzt
- GPS Rescue endete in Failsafe-Landung
So löst du es
- Funkverbindung wiederherstellen (Sender an, Reichweite)
- Warten: nach Rückkehr des Signals läuft erst die Recovery-Zeit (failsafe_recovery_delay, in 2025.12 Standard 0,5 s) ab, dann geht das Flag von selbst weg
- Failsafe-Schalter zurück in Normalstellung
- Arm-Schalter aus- und wieder einschalten
Achtung: Nach einem Failsafe im Flug erst prüfen, warum der Funk abriss, bevor man wieder startet.
Was vor diesem Flag passiert – Stage 1, Stage 2, die Prozeduren DROP, Land und GPS Rescue und die Recovery-Zeit bis zum Re-Arm – steht in Betaflight Failsafe einstellen und testen.
BADRX / NOT_DISARMED – Signal zurück, Schalter noch an
Das Funksignal ist gerade zurückgekommen, aber der Arm-Schalter stand dabei schon auf AN. Betaflight verweigert dann das Armen, damit der Kopter nicht von allein losfliegt, sobald der Empfänger wieder Daten liefert.
Typische Ursachen
- Kopter eingeschaltet, während der Arm-Schalter am Sender bereits auf „armed“ stand
- Nach Signalverlust (Failsafe) kam der Funk zurück, ohne dass man vorher disarmt hat
- Empfänger-Failsafe-Werte so gesetzt, dass der Arm-Kanal beim Wiederverbinden „AN“ liefert
So löst du es
- Arm-Schalter auf AUS stellen (das löscht das Flag, sobald das Signal stabil ist)
- Angewöhnen: Kopter immer mit Arm-Schalter AUS einschalten
- Empfänger-Failsafe so konfigurieren, dass „No Pulses“ bzw. der Arm-Kanal auf AUS geht
Achtung: Wichtiges Sicherheitsfeature: Ohne dieses Flag würde ein Kopter nach Signalrückkehr eventuell sofort hochdrehen.
RUNAWAY – Kopter beim Start ausgebrochen
Die Runaway-Takeoff-Prevention hat den Kopter disarmt, weil die Regelung beim Start „durchgedreht“ ist: hohe Reglerausgabe und gleichzeitig eine schnelle Drehung – typisch ein Überschlag direkt nach dem Hochdrehen. Klassisch bei falscher Motorreihenfolge, falsch herum montierten Propellern oder verkehrter Board-Ausrichtung.
Typische Ursachen
- Motorreihenfolge oder Drehrichtung falsch (Motors-Tab prüfen)
- Propeller verkehrt montiert
- Board-Ausrichtung (Yaw/Roll/Pitch-Offset) stimmt nicht
- Ein Motor/ESC dreht nicht mit
- Kopter beim Armen festgehalten oder in der Hand gestartet
So löst du es
- Disarmen: Arm-Schalter auf AUS (bei Stick-Arming: Disarm-Stick-Kommando) – erst das löscht das Flag
- Motorreihenfolge/-richtung im Motors-Tab ohne Propeller prüfen, Board-Ausrichtung im Setup-Tab kontrollieren
- Nur zum Test auf der Werkbank: runaway_takeoff_prevention = OFF (danach wieder ON)
Achtung: Nicht einfach neu armen – die Ursache (meist Motorreihenfolge/Props) finden, sonst hebt der Kopter beim nächsten Versuch unkontrolliert ab.
CRASH – Absturz erkannt
Die Crash-Erkennung (crash_recovery = DISARM) hat einen Aufprall erkannt und disarmt. Bis man bewusst disarmt, bleibt das Armen gesperrt.
Typische Ursachen
- crash_recovery auf DISARM gesetzt und ein Crash (oder sehr harter Stoß) wurde erkannt
- Sehr aggressive Schwellwerte bei crash_dthreshold/crash_gthreshold
So löst du es
- Arm-Schalter auf AUS bzw. Stick-Disarm ausführen – das löscht das Flag
- Kopter auf Schäden prüfen
- Wenn Fehlauslösungen: crash_recovery auf OFF oder ON (statt DISARM) stellen bzw. Schwellwerte anpassen
FLIP_SWITCH – Turtle-Schalter zurückgestellt
Crashflip (Turtle-Modus) mit manuellem Wieder-Armen: Der Flip-Schalter wurde während des aktiven Crashflips zurückgestellt; Betaflight disarmt dann und blockiert das Armen, bis der Pilot einmal bewusst disarmt hat (crashflip_auto_rearm = OFF).
Typische Ursachen
- Flip-Schalter im armierten Crashflip zurückgestellt und crashflip_auto_rearm steht auf OFF
So löst du es
- Arm-Schalter auf AUS (bewusster User-Disarm) – danach ist Armen wieder frei
- Wer nach dem Umdrehen direkt weiterfliegen will: crashflip_auto_rearm = ON
Achtung: Nach dem Turtle-Flip erst prüfen, ob die Propeller frei sind, bevor man wieder armt.
Ein Schalter steht falsch
Ein Modus-Schalter ist beim Armen an, der dort nicht sein darf.
BOXFAILSAFE – Failsafe-Testschalter ist an
Der Schalter für den Modus „FAILSAFE“ (zum Testen des Failsafe) steht auf AN. Solange der aktiv ist, wird nicht gearmt.
Typische Ursachen
- Failsafe-Modus im Modes-Tab einem Schalter zugewiesen und dieser steht auf AN
- Schalter-Bereich im Modes-Tab versehentlich so gesetzt, dass er dauerhaft aktiv ist
So löst du es
- Schalter zurückstellen
- Im Modes-Tab den FAILSAFE-Modus prüfen oder entfernen, wenn er nicht gebraucht wird
CMS – OSD-Menü ist offenoft harmlos
Das OSD-Menü (CMS) ist geöffnet – z. B. per Stick-Kombination Gas Mitte + Yaw links + Pitch hoch. Solange das Menü offen ist, wird nicht gearmt.
Typische Ursachen
- OSD-Menü versehentlich per Stick-Geste geöffnet
- Menü über Sender/Lua oder Displayport (HD-Brille) offen
So löst du es
- Menü mit „EXIT“ bzw. „SAVE+EXIT“/„SAVE+REBOOT“ verlassen
- Bei Reboot-pflichtigen Änderungen erscheint danach REBOOT_REQD
PARALYZE – Paralyze-Modus ausgelöst
Der Modus PARALYZE wurde aktiviert. Er „lähmt“ den FC absichtlich bis zum nächsten Neustart (z. B. um nach einem Crash den VTX-Kanal per OSD zu wechseln, ohne dass gearmt werden kann).
Typische Ursachen
- PARALYZE im Modes-Tab einem Schalter zugewiesen und (auch nur kurz) aktiviert
- Schalterbereich so gesetzt, dass er beim Einschalten aktiv ist
So löst du es
- Akku ab- und anstecken – nur ein Neustart hebt PARALYZE auf
- Modes-Tab: PARALYZE-Bereich prüfen oder Modus entfernen
GPS – zu wenige GPS-Satelliten
GPS Rescue ist konfiguriert, aber es gibt noch keinen ausreichenden GPS-Fix (weniger Satelliten als gps_rescue_min_sats). Ohne Fix könnte der Rescue nicht nach Hause fliegen.
Typische Ursachen
- GPS-Modul hat noch keinen Fix (Kaltstart dauert 1–3 Minuten, in Gebäuden gar nicht)
- gps_rescue_min_sats zu hoch für den Standort
- GPS-Modul falsch verdrahtet oder falsche Baudrate/Protokoll (Kein „Sats“-Wert im OSD)
So löst du es
- Draußen mit freier Sicht warten, bis der Fix steht (OSD zeigt Satellitenzahl)
- gps_rescue_allow_arming_without_fix = ON, wenn man auch ohne Fix starten will (Rescue dann nicht verfügbar)
- GPS Rescue deaktivieren (Modus/Failsafe-Einstellung), wenn es nicht genutzt wird
- Hinweis: Nach dem ersten Armen (WAS_EVER_ARMED) oder mit Crashflip-Schalter wird das Flag nicht mehr gesetzt
Achtung: Ohne Fix startet der Rescue bei Failsafe nicht – Failsafe-Stufe 2 fällt dann auf Drop/Land zurück.
RESCUE_SW – GPS-Rescue-Schalter ist an
Der GPS-Rescue-Schalter steht auf AN, während der Kopter noch am Boden ist. Man soll nicht in einen laufenden Rescue hinein armen.
Typische Ursachen
- GPS RESCUE-Modus im Modes-Tab auf einen Schalter gelegt und dieser ist aktiv
- Schalter nach einem Rescue-Test nicht zurückgestellt
So löst du es
- Rescue-Schalter auf AUS
- Modes-Tab: Bereich des GPS-Rescue-Modus prüfen
ALT_HOLD_SW – Höhenhalte-Schalter ist an
Der Schalter für Altitude Hold steht beim Armen auf AN. Man soll nicht direkt in den Höhenhalte-Modus hinein starten.
Typische Ursachen
- ALTHOLD-Modus im Modes-Tab aktiv geschaltet, bevor gearmt wurde
So löst du es
- Schalter auf AUS, armen, dann im Flug Alt Hold aktivieren
POS_HOLD_SW – Positionshalte-Schalter ist an
Der Schalter für Position Hold steht beim Armen auf AN.
Typische Ursachen
- POSHOLD-Modus im Modes-Tab aktiv geschaltet, bevor gearmt wurde
So löst du es
- Schalter auf AUS, armen, Position Hold erst im Flug einschalten
AUTOPILOT_SW – Autopilot-Schalter ist an
Neu in 2026.6: Der Autopilot-Schalter steht beim Armen auf AN.
Typische Ursachen
- Autopilot-Modus aktiv, bevor gearmt wurde
So löst du es
- Schalter auf AUS und neu armen
Konfiguration und Hardware
Seltener, aber hartnäckig: Hier stimmt etwas an Einstellungen oder Bauteilen nicht.
NOGYRO – kein Gyro gefunden
Der Flight Controller hat beim Start keinen Gyro-Sensor gefunden. Ohne Gyro kann ein Kopter nicht fliegen, deshalb wird das Armen komplett blockiert.
Typische Ursachen
- Falsches Target/Firmware für das Board geflasht
- Gyro-Chip defekt oder SPI-Verbindung unterbrochen (Lötstelle, Riss nach Crash)
- Custom-Build ohne passenden Gyro-Treiber
- Gyro beim Start nicht erkannt (seltener Timing-Fehler beim Boot)
So löst du es
- CLI „status“ prüfen: Zeile „GYRO=“ – steht dort NONE, ist es kein Konfigurationsfehler
- Richtiges Target und ggf. Cloud-Build mit passendem Gyro-Treiber flashen
- Akku ab-/anstecken, Board neu starten
- Bleibt es: Hardwarefehler, FC tauschen
Achtung: Niemals mit einem Gyro-Fehler fliegen; kein Workaround möglich.
LOAD – Prozessor überlastet
Der Prozessor des FC ist überlastet – die Regelschleife läuft nicht mehr zuverlässig in der Zeit. Dann ist Fliegen unsicher.
Typische Ursachen
- Zu hohe Loop-Rate (8 kHz) auf schwachem F4-Prozessor
- Zu viele Features/Filter gleichzeitig (RPM-Filter, dynamische Notch, GPS, OSD, Blackbox mit hoher Rate)
- Einzelne Tasks brauchen zu lange (Debug-Modus, langsamer SPI-Bus)
So löst du es
- CLI „status“ (CPU-Last) und „tasks“ anschauen
- PID-Loop-Rate senken (z. B. 4 kHz), Features abschalten
- Bei F4 keine 8k/8k, Blackbox-Rate reduzieren
Achtung: Überlast im Flug kann zu Wobbles bis zum Absturz führen.
BST – altes TBS-Flag
Historisch: Ein TBS-Gerät (Black Sheep Telemetry, z. B. Core Pro) hat disarmt. In 4.4 wurde das Bit zweckentfremdet: Es steht dort für „nach dem Einschalten noch nicht lange genug gültige Empfängerdaten“. Ab 4.5 wird das Flag im Code gar nicht mehr gesetzt.
Typische Ursachen
- 4.4: Direkt nach dem Boot, bis für rxDataRecoveryPeriod (1 s) gültige RX-Daten anliegen
- 4.5/2025.12: nicht mehr erreichbar (toter Eintrag, bleibt für die Bit-Kompatibilität)
So löst du es
- 4.4: kurz warten, Sender an, wie bei RXLOSS
- 4.5+: sollte nie erscheinen; wenn doch, Firmware-/Configurator-Version prüfen
RPMFILTER / DSHOT_TELEM – Motor liefert keine Drehzahl
Bidirektionales DShot ist eingeschaltet, aber mindestens ein Motor/ESC liefert keine Drehzahl-Telemetrie. In 4.4 wurde nur geprüft, wenn zusätzlich der RPM-Filter aktiv war; ab 4.5 reicht aktives bidirektionales DShot.
Typische Ursachen
- ESC-Firmware unterstützt kein bidirektionales DShot (BLHeli_S ohne Bluejay/JESC, alte BLHeli_32)
- Ein ESC-Kanal defekt oder nicht angeschlossen (z. B. nur 3 Motoren verkabelt, 4 konfiguriert)
- Direkt nach dem Anstecken: Telemetrie braucht 1–3 s, bis alle ESCs antworten
- Falsche motor_poles ändern das Flag nicht, aber falsche Timer/DMA-Zuordnung kann Telemetrie verhindern (siehe DSHOT_BBANG)
So löst du es
- Motors-Tab: zeigen alle Motoren RPM/Fehlerrate? Der fehlende Motor ist die Ursache
- ESC-Firmware aktualisieren (Bluejay für BLHeli_S) oder bidirektionales DShot ausschalten (dshot_bidir = OFF, dann auch RPM-Filter aus)
- Verkabelung Signal-Leitung des betroffenen ESC prüfen
- Ein paar Sekunden nach dem Einschalten warten
Achtung: Mit RPM-Filter ohne Telemetrie flögen die Filter blind – deshalb die Sperre.
REBOOT_REQD – Neustart nötig
Eine Einstellung wurde geändert, die erst nach einem Neustart wirkt (z. B. im OSD-Menü oder per Lua). Bis zum Reboot ist Armen gesperrt.
Typische Ursachen
- Änderung von Ports, Motorprotokoll, DShot-Bidir, Features usw. über CMS/OSD-Menü, MSP oder Lua ohne anschließenden Reboot
So löst du es
- FC neu starten: im OSD-Menü „SAVE+REBOOT“, im Configurator „Save and Reboot“, oder Akku ab-/anstecken
DSHOT_BBANG – DShot-Treiber startet nicht
Der „Bitbang“-DShot-Treiber (Standard für bidirektionales DShot) konnte nicht korrekt starten – meist ein Timer-/DMA-Konflikt mit anderen Funktionen. Die Motoren wären nicht ansteuerbar.
Typische Ursachen
- Timer/DMA-Konflikt mit LED-Strip, Kamera-Steuerung, SoftSerial, RX auf bestimmten Pads
- Motoren auf Pads verteilt, die nicht bitbang-fähig kombinierbar sind
- Falsches Target/Resource-Mapping nach Custom-Konfiguration
So löst du es
- dshot_bitbang = AUTO/OFF testen (mit OFF ist bidirektionales DShot nur auf unterstützten Timern möglich)
- Konfliktfeatures deaktivieren (LED_STRIP, SoftSerial) und prüfen, ob das Flag verschwindet
- Resource-Mapping (CLI „resource“, „timer“, „dma“) prüfen; ggf. „resource show all“
NO_ACC_CAL – Beschleunigungssensor nie kalibriert
Der Accelerometer wurde noch nie kalibriert, aber es ist ein Modus konfiguriert, der ihn braucht (Angle, Horizon, GPS Rescue, Alt/Pos Hold, Acro Trainer, Cam Stab …). Ohne Kalibrierung wären diese Modi gefährlich schief.
Typische Ursachen
- Neue Firmware/Reset und noch keine Acc-Kalibrierung
- Angle/Horizon/Rescue-Modus angelegt, Acc nie kalibriert
So löst du es
- Setup-Tab: Kopter waagerecht stellen und „Calibrate Accelerometer“ ausführen, speichern
- Alternativ die Acc-abhängigen Modi entfernen
- Bei widersprüchlicher Anzeige: CLI „status“ ist maßgeblich
MOTOR_PROTO – kein Motorprotokoll
Es ist kein Motor-/ESC-Protokoll ausgewählt (DISABLED) oder das gewählte konnte nicht initialisiert werden. Ohne Protokoll gibt es keine Motorsignale.
Typische Ursachen
- Neue Firmware/Reset: ESC-Protokoll steht auf DISABLED
- Motor-Pads im Target nicht definiert (Cloud-Build ohne Motor-Resources)
- Protokoll-Init fehlgeschlagen
So löst du es
- Configuration-Tab: ESC/Motor-Protokoll wählen (DSHOT300/600), speichern und neu starten
- CLI: „resource“ prüfen, ob MOTOR 1–4 zugewiesen sind
Sicher armen: Prearm und Co.
Wenn du häufig über NOPREARM stolperst oder nach einem versehentlichen Disarm nicht sofort wieder armen kannst, lohnt ein Blick auf meine Lösung mit einem Zeitfenster in der Funke: EdgeTX-Prearm-Fenster statt Betaflight-Prearm. Und wie ich Schalter und Rateprofile auf allen Koptern gleich halte, steht in Betaflight-Rateprofile per Schalter.
Häufige Fragen
Mein Kopter armt nicht – wo sehe ich überhaupt, warum?
Vier Wege: (1) Configurator Setup-Tab, Feld „Arming Disable Flags“; (2) CLI-Befehl „status“, Zeile „Arming disable flags:“ (Namen, keine Zahlen); (3) OSD: bei betätigtem Arm-Schalter erscheint der Flag-Name im Warnungs-Element, bei mehreren Flags rotierend alle 0,5 s; (4) Beeper: nach einem gescheiterten Arm-Versuch piept der kritischste Grund als Code (5 × lange + kurze Pieps = Flag-Nummer). Zusätzlich blinkt die Status-LED.
Im CLI steht „Arming disable flags: CLI MSP“ – ist das der Fehler?
Nein, beides ist normal, solange man per USB verbunden ist und das CLI offen hat. Relevant sind die Flags, die zusätzlich stehen. CLI verschwindet erst mit „exit“ (Reboot), MSP beim sauberen „Disconnect“ im Configurator.
Ich habe das USB-Kabel abgezogen, aber im OSD steht immer noch MSP.
Das Flag wird nur per MSP-Kommando vom Configurator zurückgenommen; beim reinen Kabelziehen bleibt es stehen. Akku ab- und anstecken. Steht MSP ohne USB, sperrt ein Bluetooth-/WiFi-Modul, eine App (z. B. SpeedyBee) oder ein Lua-Script per MSP.
RXLOSS, obwohl der Sender an ist und der Empfänger grün leuchtet?
Grün heißt nur „RX hat Verbindung zum Sender“, nicht „FC bekommt Daten“. Receiver-Tab prüfen: Bewegen sich die Balken? Wenn nein: Ports-Tab (Serial RX auf der richtigen UART), Receiver-Tab (Provider/Protokoll, z. B. CRSF), Verkabelung TX/RX gekreuzt, 5-V-Versorgung. Direkt nach dem Einschalten braucht der FC außerdem ~0,5–1 s gültige Daten, bevor RXLOSS weggeht.
THROTTLE steht, obwohl der Gas-Stick ganz unten ist.
Im Receiver-Tab den Gaswert ablesen: Er muss unter min_check (1050) liegen, ideal ~1000. Liegt er bei 1080–1120, sind die Sender-Endpunkte/Subtrim verstellt (typisch: „erweiterte Wege“ im TX16S ohne Kalibrierung) oder die Channel Map (AETR/TAER) ist falsch. Am Sender korrigieren, nicht min_check hochdrehen.
ANGLE – warum darf ich nicht aus der Hand oder vom Hang starten?
Betaflight verlangt, dass der Kopter weniger als small_angle (25°) geneigt ist. Waagerecht hinstellen oder im Setup-Tab „Maximum ARM Angle“ auf 180 setzen (small_angle = 180), dann entfällt die Prüfung. Zeigt das 3D-Modell im Setup-Tab schon im Stand eine Schräglage, ist der Accelerometer nicht kalibriert oder die Board-Ausrichtung falsch.
Nur ARMSWITCH ist gesetzt und trotzdem armt nichts.
ARMSWITCH heißt: Der Arm-Schalter stand auf AN, während ein anderes Flag aktiv war (das inzwischen weg sein kann). Schalter auf AUS, kurz warten, wieder AN. Bleibt es allein stehen: Modes-Tab prüfen, ob der AUX-Wert in Schalterstellung „aus“ wirklich außerhalb des ARM-Bereichs liegt; nach GPS-Rescue-Abbruch oder Landungs-Disarm setzt der Code ebenfalls nur dieses Flag.
NOT_DISARMED bzw. BAD_RX_RECOVERY nach einem Failsafe – was tun?
Der Funk ist zurückgekommen, während der Arm-Schalter noch auf AN stand. Bewusst auf AUS schalten, dann neu armen. Das ist Absicht: Der Kopter soll nach Signalrückkehr nicht von allein hochdrehen. Der Configurator nennt das Flag in allen Versionen BAD_RX_RECOVERY, OSD/CLI ab 4.5 NOT_DISARMED, in 4.4 BADRX.
Nach dem Umstieg auf 2025.12 zeigt mein altes Tool/Script die falschen Flag-Namen an.
In 2025.12 wurden drei Flags (FLIP_SWITCH, ALT_HOLD_SW, POS_HOLD_SW) vor dem Arm-Switch-Flag eingefügt; ARM_SWITCH liegt jetzt auf Bit 28 statt 25 (2026.6: Bit 29, plus AUTOPILOT_SW). Ein Tool muss die Flag-Anzahl aus MSP_STATUS mitlesen oder die Firmware-Version kennen – so macht es der Configurator (letztes Bit = ARM_SWITCH).
Was bedeutet der Piep-Code 1 lang + 3 kurz?
Flag-Nummer = 5 × lang + kurz = 8, also Bit 7 = THROTTLE (in allen Versionen). 3 kurz ohne lang = 3 = RXLOSS. 3 lang + 2 kurz = 17 = MSP. Der Beeper meldet immer nur das Flag mit dem niedrigsten Bit (den „kritischsten“ Grund) und nur, wenn sich der Grund seit dem letzten Versuch geändert hat.
PARALYZE steht und geht nicht mehr weg.
Gewollt: PARALYZE lähmt den FC bis zum nächsten Neustart. Akku ab-/anstecken. Danach im Modes-Tab prüfen, warum der Modus aktiv war (falscher Schalterbereich).
DSHOT_TELEM (früher RPMFILTER) – alle Motoren drehen im Motors-Tab, trotzdem gesperrt?
Bidirektionales DShot ist an, aber mindestens ein ESC liefert keine RPM-Telemetrie. Im Motors-Tab die RPM-/Fehleranzeige je Motor vergleichen: Der Motor ohne Wert ist die Ursache (ESC-Firmware ohne Bidir-Support, Signalleitung). Entweder ESC-Firmware (z. B. Bluejay) flashen oder dshot_bidir und RPM-Filter ausschalten.
Welches Flag hat dich zuletzt genervt?
Schreib es unten in die Kommentare – vor allem, wenn dein Kopter etwas anzeigt, das hier fehlt oder anders klingt. Ich ergänze die Liste und den Decoder dann.
Quellen
Alle Angaben stammen direkt aus dem Betaflight-Quellcode (runtime_config.h/.c, core.c, failsafe.c, cli.c, osd_warnings.c, beeper.c) der Releases 4.4.3, 4.5.5, 2025.12.5 und 2026.6.2 sowie der offiziellen Betaflight-Dokumentation. Stand: 30. September 2026.
Kommentare
Noch keine Kommentare — schreib den ersten!