Kurz gesagt: Für einen Kopter ohne GPS sind die Betaflight-Defaults die dokumentierte Empfehlung: Bei Signalverlust hält Betaflight die letzten Werte 300 ms, zentriert dann die Sticks und nimmt das Gas raus (Stage 1, 1,5 s), danach schaltet Stage 2 mit der Prozedur DROP die Motoren ab. Bei ELRS mit CRSF musst du im Empfänger nichts einstellen. Land ist ohne Höhensensor kaum brauchbar, GPS Rescue nur mit GPS-Modul und gültigem Home-Point. Einen Failsafe-Schalter brauchst du ohne GPS nicht – er würde nur DROP oder Land auslösen. Und: Props ab und einmal am Tisch testen, bevor du dich darauf verlässt.
Für Einsteiger: die Begriffe in diesem Artikel
FC ist der Flight Controller, auf dem Betaflight läuft. Failsafe ist das, was der FC tut, wenn die Funkverbindung zur Fernsteuerung abreißt. Stage 1 ist die kurze Wartephase direkt nach dem Verlust, Stage 2 die eigentliche Notfall-Prozedur. ELRS (ExpressLRS) ist das Funksystem, CRSF das Protokoll, mit dem der ELRS-Empfänger am FC hängt. RXLOSS ist die OSD-Warnung „kein Empfängersignal“, !FS! die Anzeige für „Failsafe aktiv“. AUX-Kanäle sind die Schalterkanäle deiner Funke (Kanal 5 aufwärts). CLI ist die Kommandozeile im Betaflight-Configurator, ein Diff der CLI-Export aller Einstellungen, die von den Defaults abweichen.
Kanalwerte misst Betaflight in µs (Mikrosekunden): 1000 heißt Stick unten, 1500 Mitte, 2000 oben. Der Hover-Wert ist der Gaswert, bei dem der Kopter gerade schwebt. Zeiten in den Failsafe-Parametern stehen fast immer in Zehntelsekunden: 15 heißt 1,5 s. Einzige Ausnahme ist failsafe_landing_time in 2025.12, die in ganzen Sekunden zählt.
Ich fliege vier Kopter an einer TX16S MK3 mit einem gemeinsamen Schalter-Standard: den ERA5 (5-Zoll-Freestyle), den Kayoumini (2,5-Zoll-Freestyle), den FlyTimes-85-Whoop und den 7-Zoll-Langstreckenkopter FERNWEH. GPS bekommt nur FERNWEH. Beim Abgleichen der Schalter bin ich auf dem ERA5 über einen FAILSAFE-Schalter gestolpert, der noch aus GPS-Zeiten dort lag – das GPS war längst abgebaut. Dieser Fund war der Anlass, das Thema Failsafe einmal komplett aus dem Quellcode und dem Wiki aufzuarbeiten. Hier ist das Ergebnis.
Was Failsafe in Betaflight bedeutet
Failsafe ist nicht ein Schalter, sondern eine Kette von Entscheidungen im FC: Erst muss er den Signalverlust überhaupt erkennen, dann wartet er eine kurze Zeit ab (vielleicht kommt das Signal ja zurück), und erst danach greift die Prozedur, die du eingestellt hast. Genau diese drei Schritte heißen Erkennung, Stage 1 und Stage 2. Jeder hat eigene Parameter, und die Defaults sind vernünftig – wenn man weiß, was sie tun.
Erkennung: Wie Betaflight merkt, dass das Signal weg ist
| Was | 4.5 | 2025.12 |
|---|---|---|
Kein gültiges Empfängerpaket für … → RXLOSS im OSD, Arming blockiert | 100 ms | 150 ms |
| Ein einzelner ungültiger Kanal (nur Roll/Pitch/Yaw/Throttle) wird … auf dem letzten Wert gehalten, danach gilt das Signal als verloren | 300 ms | 300 ms |
Gültiger Kanalwert liegt zwischen rx_min_usec und rx_max_usec | 885–2115 µs | 885–2115 µs |
Die Grenzen rx_min_usec/rx_max_usec gelten laut Code-Kommentar nur für die ersten vier Kanäle. Für ELRS mit CRSF sind sie praktisch egal, weil der Empfänger bei Linkverlust gar keine Kanalpakete mehr schickt (dazu gleich mehr). Gedacht sind sie für PWM-, PPM- und SBUS-Empfänger, die im Failsafe „unmögliche“ Werte senden. Ein SBUS- oder FPort-Frame mit gesetztem Failsafe-Flag zählt für Betaflight übrigens genauso als „kein Paket“; CRSF kennt ein solches Flag nicht.
Betaflight Failsafe: Stage 1 vs. Stage 2
Stage 1 ist die Wartephase. Sie beginnt beim letzten gültigen Paket und dauert failsafe_delay, Default 15 = 1,5 s. In den ersten 300 ms hält Betaflight alle Kanäle auf den letzten Werten, danach setzt es sie auf die Stage-1-Fallback-Werte, die du im Failsafe-Tab unter „Channel Fallback Settings“ pro Kanal einstellst:
- Auto (Default für Kanal 1–4): Roll, Pitch, Yaw auf Mitte (1500), Throttle auf
rx_min_usec(885). Der Kopter fällt also schon in Stage 1. - Hold (Default für alle AUX-Kanäle): Der letzte gültige Wert bleibt stehen. Deine Modeschalter bleiben so, wie sie waren.
- Set: ein fester Wert in 25-µs-Schritten. Nützlich, um Throttle für GPS Rescue auf den Hover-Wert zu setzen oder einen AUX-Kanal auf „Angle-Mode an“.
Die PID-Regelung läuft in Stage 1 normal weiter, im OSD steht RXLOSS, aber noch kein !FS!. Kommt das Signal in dieser Zeit zurück, hast du sofort wieder Kontrolle, die Timer werden zurückgesetzt.
Stage 2 beginnt, wenn failsafe_delay abgelaufen ist. Jetzt setzt Betaflight den Flugmodus FAILSAFE (OSD: !FS!) und führt die Prozedur aus, die in failsafe_procedure steht: DROP, AUTO-LAND oder GPS-RESCUE.
Sonderfall „Just Disarm“
Stand der Throttle-Stick beim Signalverlust schon länger als failsafe_throttle_low_delay (Default 100 = 10 s) ganz unten, überspringt Betaflight Stage 1 und Stage 2 und disarmt sofort. Laut Code-Kommentar schützt das davor, dass ein Kopter am Boden losfliegt, wenn die Funke nach dem Kopter eingeschaltet wird. Drei Details, die man wissen sollte: Die 10 s zählen ab dem letzten Moment, in dem der Throttle-Stick über der Minimum-Schwelle stand – also seit dem letzten Gasgeben. Wer nach dem Armen nie Gas gegeben hat, wird bei Linkverlust ebenfalls sofort disarmt, egal wie lange das Armen her ist. Und der Wert 0 schaltet das Feature nicht ab, sondern bedeutet das Gegenteil: sofortiger Disarm, sobald der Throttle beim Verlust unten steht. Der Kurzschluss gilt nicht, wenn die Prozedur GPS-RESCUE ist.
Recovery: das Signal kommt zurück
Nach einem Verlust müssen erst failsafe_recovery_delay lang (Default 5 = 0,5 s) durchgehend gültige Pakete ankommen, bevor der Link als „up“ gilt und RXLOSS verschwindet. Das gilt auch direkt nach dem Einschalten. War Stage 2 schon aktiv, wartet Betaflight danach noch einmal dieselbe Zeit, bevor das Flag FAILSAFE fällt und Arming wieder erlaubt ist – zusammen also etwa 1 s; der Code-Kommentar dazu lautet „allow re-arming 1 second after Rx recovery“. War die Prozedur DROP, ist der Kopter dann disarmt und muss neu gearmt werden – und zwar mit Arm-Schalter erst aus, dann an, sonst zeigt das OSD NOT_DISARMED. Bei GPS Rescue kommt eine Bedingung dazu: Erst wenn du Roll, Pitch oder Yaw mehr als failsafe_stick_threshold (Default 30 %) auslenkst, endet der Rescue; sonst fliegt der Kopter weiter nach Hause.
Wiki vs. Code: Ältere Fassungen des Betaflight-Wikis nennen nach einem Failsafe eine Re-Arm-Sperre von 3 s bzw. 30 s. Im aktuellen Code der Branches 4.5 und 2025.12 sind die zugehörigen Konstanten zwar noch definiert, werden aber nirgends verwendet. Maßgeblich ist die Recovery-Zeit von etwa 1 s (zweimal failsafe_recovery_delay) plus einmal Arm-Schalter aus.
Alle Parameter und Defaults auf einen Blick
| CLI-Parameter | Default | Bereich | Einheit | Bedeutung |
|---|---|---|---|---|
failsafe_ | 15 | 1–200 | 0,1 s | Dauer Stage 1 |
failsafe_ (nur 4.5) | 10 | 0–200 | 0,1 s | Dauer Land bis Disarm |
failsafe_ (nur 2025.12) | 60 | 0–250 | s | Dauer Land bis Disarm |
failsafe_ | 1000 | 750–2250 | µs | Throttle in Stage 2 (Land); in 2025.12 von Altitude Hold überstimmt, wenn verfügbar |
failsafe_ | 100 | 0–300 | 0,1 s | Throttle-unten-Zeit für „Just Disarm“ (0 = sofort) |
failsafe_ | DROP | AUTO-LAND / DROP / GPS-RESCUE | – | Stage-2-Prozedur |
failsafe_ | STAGE1 | STAGE1 / KILL / STAGE2 | – | Verhalten des FAILSAFE-Schalters |
failsafe_ | 5 | 1–200 | 0,1 s | gültige Daten bis Recovery; Arming nach etwa der doppelten Zeit |
failsafe_ | 30 | 0–50 | % | Stick-Auslenkung (Roll, Pitch, Yaw), die GPS Rescue beendet |
rx_ / rx_ | 885 / 2115 | 750–2250 | µs | gültiger Kanalbereich (Kanal 1–4) |
rxfail (pro Kanal) | Kanal 1–4 Auto, AUX Hold | Auto / Hold / Set | – | Stage-1-Fallback |
Alle Werte stammen aus dem Quellcode der Branches 4.5 und 2025.12; wo nichts anderes steht, sind sie in beiden gleich.
DROP, Land oder GPS Rescue – wann welche Prozedur?
DROP (Default)
Betaflight disarmt, die Motoren gehen aus, der Kopter fällt. Klingt brutal, ist aber die dokumentierte Empfehlung für alles ohne GPS: schnell, berechenbar, und der Kopter driftet nicht mit laufenden Motoren irgendwohin. Im Wiki steht, dass Racer DROP wegen der schnellen Reaktion nutzen.
AUTO-LAND / „Land“ – in 4.5 und 2025.12 zwei verschiedene Dinge
| 4.5 | 2025.12 | |
|---|---|---|
| Dauer | failsafe_, Default 10 = 1,0 s | failsafe_, Default 60 s (ersetzt failsafe_) |
| Throttle | fester Wert failsafe_ (Default 1000), Sticks auf Mitte, Angle-Mode wird erzwungen | Ist Altitude Hold in der Firmware, ein Beschleunigungssensor da, die Höhe per Baro/GPS verfügbar, kein GPS Rescue aktiv und wurde der Throttle nach dem Armen mindestens einmal angehoben, übernimmt Altitude Hold einen geregelten Sinkflug; mit Position Hold (braucht GPS) zusätzlich ohne Abdrift. Sonst: fester failsafe_ |
| Ende | Disarm nach Ablauf der Zeit | Disarm nach Ablauf der Zeit – oder früher durch Aufsetz-Erkennung, die aber nur aktiv ist, wenn landing_ größer als 0 ist (Default 0 = aus; der Wert gilt pro PID-Profil) |
Was das für Einsteiger heißt: In 2025.12 bedeutet „Land“ mit Defaults auf einem Kopter ohne Baro oder GPS: 60 Sekunden lang Throttle 1000 – Motoren praktisch aus, aber armed und im Angle-Mode – und dann Disarm. Auf einem Kopter mit Baro: bis zu 60 s geregelter Sinkflug, und ohne gesetzten landing_disarm_threshold bleibt er nach dem Aufsetzen armed, bis die 60 s um sind. Genau dieses Verhalten ist als Issue #14865 gemeldet; die Maintainer-Antwort war sinngemäß: Aufprall-Schwelle setzen und die Zeit lang genug wählen. Für 4.5 warnt das Wiki ausdrücklich: Der Land-Modus sei „potentially hazardous“ und „not generally recommended“ – Drift bei Wind, und die Motoren können unerwartet anlaufen.
Alte CLI-Diffs aufpassen: Wer einen Diff aus 4.5 mit failsafe_off_delay in 2025.12 einspielt, bekommt die Zeile verworfen; failsafe_landing_time bleibt auf 60 s. Das OSD-Menü zeigt diesen Wert in allen 2025.12.x-Releases außerdem falsch als „6.0“ an und lässt dort höchstens 200 zu; der Fix (PR #15751) kommt erst mit 2026.12.
GPS-RESCUE
Betaflight aktiviert den GPS-Rescue-Modus, und die Rescue-Logik fliegt den Kopter zum Home-Point zurück. Voraussetzungen und Defaults (CLI-Präfix gps_rescue_):
min_sats= 8 (Wiki: „10 is best“). Solange die Prozedur GPS-RESCUE ist oder ein GPS-RESCUE-Mode angelegt wurde, blockiert Betaflight das erste Armen nach dem Einschalten mit dem Flag GPS, bis 3D-Fix und Mindest-Satellitenzahl erreicht sind. Nach einem erfolgreichen Arm (oder im Flip-over-after-crash) greift die Sperre nicht mehr.allow_arming_without_fix= OFF – laut Wiki dringend so lassen.min_start_dist= 15 m: Innerhalb steigt der Kopter erst auf mindestens 10 m und fliegt heraus; unter 5 m und „on the ground“ disarmt er sofort.altitude_mode= MAX,return_alt= 30 m,initial_climb= 10 m,descent_dist= 20 m,descend_rate= 150 cm/s.sanity_checks= FS_ONLY: Bei echtem Linkverlust führt ein Fehler zum Abbruch (Disarm); per Schalter ausgelöst zu „Do Nothing“ für rund 20 s.disarm_threshold(Aufprall-Erkennung): 20 in 4.5, 30 in 2025.12.- Kompass (
use_mag) ist optional und laut Wiki nur einzuschalten, wenn kalibriert und per Log verifiziert; Baro optional, verbessert die Höhe.
Der Home-Point wird beim Armen gesetzt. Das Wiki formuliert es drastisch: Sei dir zu 100 % sicher, dass ein gültiger Home-Point da ist, bevor du armst – sonst disarmt der Kopter bei einem echten Failsafe und stürzt ab. Kontrolle: Home-Icon und Distanz im OSD, und der Home-Pfeil zeigt nach dem Wegfliegen zum Start. Zwei Punkte, die man leicht vergisst: Throttle in Stage 1 auf „Set“ mit Hover-Wert stellen, sonst fällt der Kopter 1,5 s lang, bevor Rescue übernimmt. Und zum Beenden nach der Rückkehr des Signals Roll, Pitch oder Yaw bewegen (über 30 %), sonst fliegt er weiter heim.
Wann welche Prozedur?
- Kein GPS (Whoop, Toothpick, 5-Zoll, Cinewhoop): DROP mit Defaults. Offizielle, klassenspezifische Empfehlungen darüber hinaus gibt es nicht – ich habe keine gefunden.
- GPS-Kopter / Long Range: GPS-RESCUE mit Stage-1-Throttle auf Hover (siehe oben),
min_sats8–10, Home-Point-Check vor dem Start. Eine längere Stage 1 (etwa 3–5 s) wird in Foren empfohlen; der Code erlaubt bis 20 s, eine offizielle Empfehlung dazu habe ich nicht gefunden. - Land: nur, wenn du weißt, warum – und in 2025.12 nur mit Baro, gesetztem
landing_disarm_thresholdund einer bewusst gewähltenfailsafe_landing_time.
Für meine Flotte heißt das: FERNWEH ist der einzige Kopter, der ein GPS bekommt, und damit der einzige Kandidat für GPS Rescue. Für die anderen drei sehe ich keinen Grund, von den Defaults – also DROP – abzuweichen.
ELRS Failsafe: was der Empfänger bei Signalverlust macht
Das Betaflight-Wiki verlangt vom Empfänger, dass er bei Signalverlust gar keine Daten mehr sendet (im Wiki: „send no data“), statt die letzte Stickposition zu halten. Bei ELRS mit CRSF ist genau das fest eingebaut. Im ELRS-Code beginnt die Routine, die CRSF-Kanalframes an den FC schickt, mit einer Abfrage, ob ein neues Funkpaket angekommen ist; wenn nicht, wird kein Kanalframe gesendet. Bei Linkverlust hört der Empfänger also einfach auf, Kanalpakete zu liefern (die Link-Statistik läuft weiter). Betaflight sieht 150 ms lang (4.5: 100 ms) keine Pakete, meldet RXLOSS und startet Stage 1. Es gibt keine Empfänger-Einstellung, die das ändert – und es muss auch keine geben.
Wann ELRS selbst in den Failsafe geht, beschreibt die ELRS-Doku so: wenn die Link Quality auf 0 fällt oder eine Sekunde ohne gültiges Kanalpaket vergangen ist, je nachdem, was zuerst eintritt. LQ wird über ein Fenster von 100 Paketen berechnet; bei 500 Hz sind das etwa 0,2 s, bei 250 Hz 0,4 s, bei 150 Hz 0,67 s, bei 100 Hz 1 s. Ehrlicherweise: Die Ein-Sekunden-Regel steht in der Doku, im Code habe ich die Stelle nicht lokalisiert. Für Betaflight ist das aber zweitrangig, denn der FC reagiert schon auf die ausbleibenden Kanalpakete, lange bevor der Empfänger seinen eigenen Disconnect-Timeout erreicht.
Nur wer ELRS per SBUS betreibt, hat eine Einstellung: Im Lua-Script bzw. Web-UI unter „SBUS failsafe“ die Option „No Pulses“ wählen. „Last Pos“ sendet die letzten Positionen zusammen mit dem Failsafe-Bit, das Betaflight ebenfalls als Verlust wertet – funktioniert also auch, ist aber nicht der empfohlene Weg. PWM-Empfänger haben eigene Failsafe-Positionen, die für Betaflight-Kopter keine Rolle spielen.
Der Failsafe-Schalter – und die Falle ohne GPS
Im Modes-Tab gibt es den Mode FAILSAFE. Legt man ihn auf einen Schalter, simuliert er einen Signalverlust. Wie genau, bestimmt failsafe_switch_mode:
- STAGE1 (Default): sofort die Stage-1-Werte, nach
failsafe_delayStage 2 mit der eingestellten Prozedur. Hold-Kanäle lassen die aktuellen Werte durch, die Modeschalter bleiben also bedienbar. Zurückschalten gibt sofort Kontrolle (keine Recovery-Wartezeit). - STAGE2: überspringt Stage 1 und geht direkt in die Prozedur. Laut Wiki „useful for instant auto-landing, GPS Return, or Drop“.
- KILL: sofortiger Disarm. Das Wiki warnt: Ein einziger Glitch auf dem Failsafe-Kanal lässt den Kopter sofort abstürzen. Danach gilt die normale Recovery-Zeit. Das Wiki empfiehlt stattdessen STAGE2 mit DROP und einem minimalen
failsafe_delay– gleich schnell, aber sicherer.
Der entscheidende Punkt: Der Schalter löst immer dieselbe failsafe_procedure aus wie ein echter Linkverlust. Es gibt keine separate Schalter-Prozedur. Nur wenn die Prozedur GPS-RESCUE ist und GPS samt Home-Point vorhanden sind, ist der Schalter eine „Return to Home“-Taste. Mit DROP disarmt der Kopter nach 1,5 s (bei STAGE2 oder KILL sofort), mit Land sinkt er blind.
Genau das ist der Fall vom ERA5 aus meinem Schalter-Artikel: FAILSAFE lag auf SG unten, aus der Zeit mit GPS-Modul – auf dem Schalter, der auf den anderen Koptern „Beeper aus“ bedeutet. Was ohne GPS dabei passiert, sagt der Code. Steht failsafe_procedure noch auf GPS-RESCUE, blockiert Betaflight schon das erste Armen nach dem Einschalten mit ARMING_DISABLED_GPS, bis Fix und Mindest-Satellitenzahl da sind – ohne GPS-Modul also gar nicht. Es sei denn, jemand hat gps_rescue_allow_arming_without_fix auf ON gesetzt. Wird der Rescue dann ausgelöst, gibt es keinen Home-Point: Bei echtem Linkverlust (Sanity-Check FS_ONLY, Default) folgt sofort der Abbruch, also Disarm; per Schalter ein „Do Nothing“-Sinkflug von rund 20 s, dann Disarm. Steht die Prozedur auf DROP oder Land, tut der Schalter genau das. Kurz: Failsafe-Schalter ohne GPS = Absturz oder blinder Sinkflug.
Zwei Nebeneffekte, die dir beim Einrichten begegnen: Ist der Schalter im disarmten Zustand an, zeigt das OSD schon die Failsafe-Warnung, und Arming ist mit dem Flag BOXFAILSAFE blockiert. Und in Stage 2 verhält sich ein Schalter-Failsafe für Kanal 1–4 identisch zum echten Verlust; nur die AUX-Kanäle laufen über Hold/Set, wobei Hold die aktuellen Werte durchlässt.
Meine Regel daraus: Ein FAILSAFE-Schalter gehört nur auf Kopter mit funktionierendem GPS Rescue – in meiner Flotte käme dafür nur FERNWEH in Frage, sobald das GPS dort läuft. Wenn du ihn bewusst als Test- oder Kill-Schalter willst: nicht auf einen Schalter, der auf einem anderen Modell etwas Harmloses macht.
Failsafe testen – ohne Props, Schritt für Schritt
Props ab, immer. Alle Tests hier laufen mit Akku, und bei einigen drehen Motoren an. Propeller runter, bevor der LiPo dran kommt, Kopter fixieren. Und nie die Funke ausschalten, solange der Kopter armed am Boden steht – das Wiki sagt: Funke an lassen, Sticks disarmed, bis der Kopter stromlos ist.
Noch ein Stolperstein: Solange der Configurator verbunden ist, sperrt er das Armen (im OSD steht dann MSP). Schritt 1 läuft deshalb mit Configurator; für alle Schritte, in denen du armst, trennst du ihn vorher und beobachtest das OSD in der Brille. Das entspricht auch dem Bench-Test im Wiki, der den Configurator gar nicht erwähnt.
- Erkennung im Receiver-Tab prüfen. Kopter per USB und LiPo anschließen, Receiver-Tab öffnen. Dann im Radio-Setup das TX-Modul ausschalten (EdgeTX: Modell → Internes/Externes Modul → Aus) oder die Funke ausschalten. Die Kanalbalken müssen einfrieren bzw. auf die Fallback-Werte springen, der Configurator zeigt Failsafe/
RXLOSS. Bei ELRS-CRSF passiert das ohne weitere Einstellung. Modul wieder an: Balken laufen wieder. - Stage 1 sichtbar machen.
failsafe_delaytestweise auf 100 (10 s), Prozedur DROP, Stage-1-Throttle (Kanal 4 auf „Set“) auf einen hover-nahen Wert, speichern, Configurator trennen. Armen, kurz Gas geben, Link trennen, Sticks bewegen: Die Motoren halten 300 ms die Drehzahl, fallen dann auf den Stage-1-Wert und reagieren nicht mehr auf die Sticks, im OSD stehtRXLOSS, nach 10 s kommt Stage 2 und der Kopter disarmt. Zweiter Durchlauf: Link innerhalb der 10 s wiederherstellen – die Motoren müssen sofort wieder auf die Sticks reagieren. Danachfailsafe_delaywieder auf 15 und den Throttle-Fallback zurück auf Auto (außer bei GPS Rescue). - Stage 2 DROP. Standardwerte, Configurator getrennt, armen, Gas, Link trennen: Nach 1,5 s Motoren aus,
!FS!im OSD. Neu armen geht etwa 1 s nach Rückkehr des Links und erst nach Arm-Schalter aus/an. - Stage 2 Land (nur am Tisch). Throttle-Wert und Zeit setzen, Link trennen: fester Throttle für die eingestellte Zeit, dann Disarm. Einen Feldtest erlaubt das Wiki nur in etwa 1 m Höhe über weichem Boden, nachdem DROP getestet ist, mit Angle-Mode über einen Stage-1-AUX-Wert gesetzt und mit einem Link, der jederzeit sofort wiederhergestellt werden kann.
- Just Disarm. Armen, Throttle unten lassen und kein Gas geben, Link trennen: sofortiger Disarm ohne die 1,5 s. Zweite Variante: kurz Gas geben, dann mindestens 10 s Throttle unten, Link trennen – ebenfalls sofort. So verhält sich der Kopter, wenn du nach der Landung zuerst die Funke ausschaltest.
- Schalter-Test. Wenn ein FAILSAFE-Schalter existiert: Bench-Test mit dem Schalter. Der zeigt sofort, welche Prozedur greift – und ob du auf diesem Kopter überhaupt einen haben willst.
- GPS Rescue (nur mit GPS): erst per Schalter testen, weil du ihn sofort abbrechen kannst, dann echten Linkverlust durch Abschalten des TX-Moduls – nicht durch Ausschalten der Funke.
CLI-Vorlage
Für einen Kopter ohne GPS ist die Vorlage schnell erklärt, weil sie den Defaults entspricht. Sie ist trotzdem sinnvoll im Diff, damit ein übernommener Fremd-Diff nichts anderes hinterlässt:
# Failsafe-Vorlage ohne GPS (entspricht den Betaflight-Defaults)
# Stage 1: 15 = 1,5 s warten
set failsafe_delay = 15
# Stage 2: Motoren aus
set failsafe_procedure = DROP
# Throttle seit >= 10 s unten? Dann sofort disarmen (0 = sofort, nicht "aus")
set failsafe_throttle_low_delay = 100
# 5 = 0,5 s gueltige Daten; Armen geht nach etwa der doppelten Zeit
set failsafe_recovery_delay = 5
# Verhalten eines FAILSAFE-Schalters (falls angelegt)
set failsafe_switch_mode = STAGE1
saveFür einen GPS-Kopter kommt die Prozedur GPS-RESCUE dazu. Die Stage-1-Fallback-Werte stellst du im Failsafe-Tab unter „Channel Fallback Settings“ ein (CLI-Befehl rxfail); Throttle dort auf „Set“ mit deinem Hover-Wert.
# Failsafe-Vorlage mit GPS Rescue (nur mit GPS-Modul!)
set failsafe_delay = 15
set failsafe_procedure = GPS-RESCUE
# Arming erst mit 3D-Fix und mindestens 8 Satelliten
set gps_rescue_min_sats = 8
# Wiki: unbedingt OFF lassen
set gps_rescue_allow_arming_without_fix = OFF
# Roll, Pitch oder Yaw > 30 % beenden den Rescue
set failsafe_stick_threshold = 30
# Hover-Gas des Autopiloten (nur 2025.12; in 4.5 heisst der Wert gps_rescue_throttle_hover,
# dort liefert diese Zeile "Invalid name")
set ap_hover_throttle = 1275
save
# Zusaetzlich im Failsafe-Tab: Throttle (Kanal 4) in Stage 1
# auf "Set" mit Hover-Wert statt "Auto"Zum Hover-Gas: In 4.5 heißt der Parameter gps_rescue_throttle_hover, in 2025.12 ap_hover_throttle (Bereich 1100–1700); der Default ist in beiden 1275. Dazu kommt in 2025.12 ap_landing_altitude_m = 4, die Höhe, ab der der Autopilot die Landephase einleitet (in 4.5 entspricht dem gps_rescue_landing_alt). Trage bei ap_hover_throttle den Wert ein, bei dem dein Kopter tatsächlich schwebt – 1275 ist nur der Startpunkt.
Für Fortgeschrittene: Blackbox, Debug-Modus und ein veralteter Code-Kommentar
Mit debug_mode = FAILSAFE schreibt die Blackbox Schalterzustand, RX-Status und Failsafe-Phase mit:
# Failsafe-Phasen in der Blackbox mitschreiben
set debug_mode = FAILSAFE
saveBeim Auswerten eines Land-Failsafes in 2025.12 aufpassen: Die Blackbox loggt den Throttle vor der Autopilot-Übernahme. Im Log steht also failsafe_throttle, obwohl die Motoren dem Altitude Hold folgen (Hinweis eines Nutzers in Issue #14865, im Code bestätigt).
Und eine Kuriosität: Ein Kommentar in failsafe.c behauptet noch, der Default für failsafe_procedure sei „auto-landing“. Das ist veraltet, der tatsächlich gesetzte Wert ist DROP.
Typische Fehler
- Failsafe nie getestet. Das Wiki: „Always confirm that your failsafe system is working properly before flying!“ – Testablauf.
- Funke nach der Landung ausschalten, während der Kopter noch armed ist. Nur harmlos, wenn Just Disarm greift; sonst läuft Stage 2, und bei Land laufen die Motoren an.
- Land in 2025.12 ohne
landing_disarm_threshold. Der Kopter bleibt nach dem Aufsetzen bis zu 60 s armed – Land-Vergleich. - Alten CLI-Diff mit
failsafe_off_delayin 2025.12 einspielen. Die Zeile wird verworfen – Details. - FAILSAFE-Schalter von einem GPS-Setup übernommen, GPS ausgebaut. Mein ERA5-Fall – die Falle ohne GPS.
- Stage-1-Throttle auf Auto bei GPS Rescue. 1,5 s freier Fall, bevor Rescue übernimmt – GPS-RESCUE.
- Nach Signalrückkehr nicht neu armen können. Arm-Schalter erst aus (NOT_DISARMED), etwa 1 s Recovery abwarten; bleibt RXLOSS oder FAILSAFE stehen, ist der Link noch nicht sauber zurück.
- Nach GPS Rescue nicht die Sticks bewegen. Der Kopter fliegt weiter heim.
rx_min_usec/rx_max_usecenger setzen als das, was der Sender liefert. ELRS liefert 988–2012 µs; bei 885/2115 ist das kein Problem. Engere Werte können nach der Logik im Code Fehl-Failsafes erzeugen – ein konkretes Fehlerbild dazu habe ich nicht belegt.- Empfänger-Failsafe „Last Position“ bei SBUS/PWM statt „No Pulses“ – ELRS-Abschnitt.
Wie ist dein Failsafe eingestellt?
Schreib mir unten in die Kommentare, wie du Failsafe auf deinen Koptern eingestellt hast – DROP, Land oder GPS Rescue, welche Betaflight-Version, und ob der Tisch-Test bei dir so lief, wie er im Wiki und oben beschrieben ist. Gerade beim Land-Modus in 2025.12 sammle ich gern Erfahrungswerte, denn dazu gibt es außer dem Issue noch wenig Belastbares.
Häufige Fragen
Was passiert mit Betaflight-Defaults, wenn die Verbindung abreißt?
Nach 150 ms ohne Paket (4.5: 100 ms) zeigt das OSD RXLOSS. Die letzten Werte werden 300 ms gehalten, dann stehen Roll, Pitch und Yaw auf Mitte und Throttle auf Minimum (Stage 1). Nach 1,5 s kommt Stage 2 mit der Prozedur DROP: Motoren aus, Kopter fällt. Kommt das Signal innerhalb der 1,5 s zurück, hast du sofort wieder Kontrolle.
Muss ich im ELRS-Empfänger etwas für Failsafe einstellen?
Bei CRSF nein. Der Empfänger schickt bei Linkverlust einfach keine Kanalpakete mehr – genau das, was Betaflight erwartet. Nur wer ELRS per SBUS betreibt, stellt „SBUS failsafe“ auf „No Pulses“.
Warum fällt mein Kopter sofort, statt zu landen?
Weil DROP der Default ist, und das mit Absicht. Ohne Höhensensor lässt sich ein fester Landegas-Wert kaum sinnvoll setzen, und der Kopter driftet im Wind weg. Das Betaflight-Wiki nennt den Land-Modus „not generally recommended“.
Ist Land in Betaflight 2025.12 besser geworden?
Mit Baro (und optional GPS) ja: Dann regelt Altitude Hold einen kontrollierten Sinkflug – vorausgesetzt, du hast nach dem Armen einmal Gas gegeben. Aber die neue Zeit failsafe_landing_time steht auf 60 Sekunden, und der automatische Disarm beim Aufsetzen ist nur aktiv, wenn landing_disarm_threshold größer als 0 ist (Default 0). Ohne Baro bleibt es beim festen Throttle-Wert für 60 s.
Wie lange sperrt Betaflight das Armen nach einem Failsafe?
Etwa eine Sekunde: erst failsafe_recovery_delay (Default 0,5 s) lang gültige Daten, bis RXLOSS verschwindet, dann noch einmal dieselbe Zeit, bis das Flag FAILSAFE fällt. Dazu muss der Arm-Schalter einmal aus gewesen sein. Ältere Wiki-Texte nennen Sperren von 3 s oder 30 s – die passenden Konstanten sind im aktuellen Code zwar noch definiert, werden aber nicht mehr benutzt.
Warum ist mein Kopter nach dem Ausschalten der Funke sofort disarmt, ohne 1,5 s zu warten?
Das ist „Just Disarm“: Stand Throttle beim Verlust schon mindestens 10 s unten (failsafe_throttle_low_delay = 100), disarmt Betaflight sofort. Die 10 s zählen ab dem letzten Gasgeben; wer nach dem Armen nie Gas gegeben hat, wird ebenfalls sofort disarmt. Bei GPS-RESCUE als Prozedur ist dieser Kurzschluss abgeschaltet.
Brauche ich einen Failsafe-Schalter?
Nur zum Testen oder als Return-to-Home-Taste bei GPS Rescue. Ohne GPS löst er dieselbe Prozedur aus wie ein Linkverlust, also DROP oder Land – Absturz oder blinde Landung. Und nie auf einen Schalter legen, der auf anderen Modellen etwas Harmloses macht.
Was ist der Unterschied zwischen failsafe_switch_mode STAGE1, STAGE2 und KILL?
STAGE1 verhält sich wie ein Linkverlust: erst 1,5 s Stage 1, dann die Prozedur. STAGE2 springt direkt in die Prozedur. KILL disarmt sofort. Bei STAGE1 und STAGE2 hast du beim Zurückschalten sofort wieder Kontrolle, bei KILL erst nach der Recovery-Zeit und neuem Armen. Das Wiki empfiehlt statt KILL lieber STAGE2 mit DROP und kurzem Delay.
Quellen
Abläufe, Parameter, Defaults und Bereiche stammen aus dem Betaflight-Quellcode der Tags 4.5.5 und 2025.12.5 (failsafe.c/.h, rx.c, pg/rx.c, rx.h, settings.c, core.c, cms_menu_failsafe.c, alt_hold_multirotor.c, pid.c, pg/gps_rescue.c bzw. gps_rescue_multirotor.c, pg/autopilot_multirotor.c) sowie den Pull Requests #13816 und #15751 und Issue #14865; die Arming-Sperre des Configurators aus dessen Quellcode (serial_backend.ts, MSPHelper.ts); die Empfehlungen und Testabläufe aus dem Betaflight-Wiki (Failsafe, Failsafe-Tab, GPS Rescue, Position Hold 2025.12). Das ELRS-Verhalten stammt aus dem ExpressLRS-Quellcode (SerialCRSF.cpp, SerialSBUS.cpp, devSerialIO.cpp, rx_main.cpp, common.cpp) und der ELRS-Doku (PWM-Receivers, Lua-Howto). Wo Wiki und Code sich widersprechen (Re-Arm-Sperre, Default-Kommentar), steht das im Text. Stand: 30. September 2026.
Kommentare
Noch keine Kommentare — schreib den ersten!