Betaflight failsafe: what your quad does when the link drops, and how to test it

Timings and defaults are taken from the Betaflight wiki and refer to Betaflight 4.5, with 4.4 values noted where they differ. On newer firmware, check the defaults in your own Configurator.

Make the receiver go silent

Failsafe can be handled in two places. In receiver-based failsafe, the receiver sends preset stick values when it loses the link. The flight controller sees what looks like normal data, so Betaflight's failsafe never triggers and the OSD shows nothing. In flight controller based failsafe, the receiver sends no data at all, and Betaflight reacts on its own. The Betaflight documentation does not recommend receiver-based failsafe and asks you to set the receiver to send nothing on signal loss.

The second approach has another advantage. Betaflight watches for missing data, so the same logic catches a broken receiver wire or a frozen receiver.

With an ExpressLRS receiver on a serial port (CRSF), there is no receiver failsafe value to set: the receiver stops passing channel data and Betaflight takes over. If you run an ELRS receiver with SBUS output, its Lua script has an SBUS Failsafe option. No Pulses stops all messages, which is the behaviour Betaflight asks for. Last Pos keeps sending the last channel positions with the failsafe bit set.

While you are in the radio setup, check one more ELRS rule: arm on AUX1, with low (about 1000 µs) as disarmed and high (about 2000 µs) as armed. ELRS sends AUX1 in every packet. A switch on another channel can take several packets to arrive, and ELRS gives no guarantee that the receiver gets that packet.

What happens, millisecond by millisecond

With default settings, Betaflight counts from the last valid packet:

Time since last good packet	What the flight controller does	What you see in the OSD
0-100 ms	Holds the last stick values	Nothing
100 ms	Declares signal loss and blocks arming	RXLOSS
300 ms	Stage 1: applies fallback values (sticks centred, throttle at minimum, switches held)	RXLOSS, no separate Stage 1 indicator
1.5 s	Stage 2: runs the chosen procedure (Drop by default, which disarms)	!FS! in the flight mode field

The Stage 1 length is failsafe_delay, also labelled "Guard time for stage 2 activation" in Configurator. It defaults to 1.5 s in 4.5 and 1.0 s in 4.4, and the minimum is 200 ms. If valid data arrives at any point before Stage 2, you get control back immediately. With a link that comes and goes, that shows up as jerky, intermittent stick response.

Stage 1 throttle deserves attention. It is zero by default, so the quad starts falling 300 ms after the link goes, long before Stage 2 begins. With Drop the quad is coming down anyway. For GPS Rescue it can end the flight before the rescue starts (more on that below).

Recovering from Stage 2 takes more steps. The signal has to stay good for failsafe_recovery_delay: 500 ms in 4.5, 100 ms in builds with the RACE_PRO option, 1.0 s in 4.4. After that you flip the arm switch to disarmed and arm again. Until you do, the OSD shows NOT_DISARMED (BAD_RX before 4.5). Since 4.3 you no longer need to power cycle the quad, so if it lands somewhere you cannot reach and you can get close enough to restore the link, you can re-arm and fly it out.

Two details catch people out. Stage 2 cannot start during the first 5 seconds after the flight controller boots. And there is a hidden "just disarm" case: if the throttle sat low for at least 10 seconds before Stage 2, Betaflight simply disarms instead of running the Stage 2 procedure (GPS Rescue is the exception). That protects you when you switch the radio off after landing with the battery still connected, but it can make a bench test look wrong.

Drop, Land or GPS Rescue

Drop disarms and stops the motors at the start of Stage 2. It is the default, and the Betaflight wiki names racers and park fliers as its typical users. For freestyle and training over open ground with nobody underneath, it is also the most predictable choice: the quad comes down close to where the link was lost, which makes it easier to find. Do not cut the guard time to the bone. The wiki gives 200 ms as the practical minimum, and anything shorter leaves you open to false failsafes from brief dropouts.

Land holds a fixed throttle (failsafe_throttle) for a set time (failsafe_off_delay) and then disarms. The wiki does not recommend it, except for testing failsafe switches and finding hover values for GPS Rescue. During the descent the PIDs are active and nobody is steering, so the quad drifts with the wind, can come down on people under power, and can burn out motors if the props jam on landing. If you use it anyway, set failsafe_throttle for a descent of about 1 m/s and make failsafe_off_delay long enough to reach the ground from your usual height. The Configurator documentation adds that without Altitude Hold in the firmware, a throttle value set too high makes the quad climb instead of descend, and one set too low brings it down hard. With Altitude Hold built in, the descent is controlled and the quad disarms when it lands.

GPS Rescue hands control to the GPS controller, which flies home and lands. It needs a working GPS module, enough satellites and a home point, and a few settings decide whether it rescues the quad or crashes it:

• Set the Stage 1 throttle to roughly a hover. The wiki calls this essential: with the default zero throttle, the quad can crash in Stage 1 before the rescue has time to start.
• Leave "Allow arming without fix" off. If you arm with no home point and a rescue starts, the quad disarms immediately and crashes.
• Keep sanity checks on. If they fail, the quad disarms rather than flying off.
• Mind the minimum distance to home. A rescue triggered closer than that makes the quad fly away first, possibly a long way in a random direction, before it turns for home.

To take control back during a rescue, the signal must hold for failsafe_recovery_delay and you then have to move the sticks more than 30° from centre (failsafe_stick_threshold). Sticks left centred mean the rescue continues. Even with all this in place, do not treat GPS Rescue as a guarantee that the quad will come back.

Test it with the props off

Before the test, open Configurator's Receiver tab and check how your radio reacts to the method you plan to use. The Betaflight wiki recommends disabling the transmitter module in the radio, because most radios stop sending data immediately. Switching the whole radio off can take several button presses, and some radios refuse to power up unless every switch, including arm, is off.

Drop test, props removed:

1. Set Stage 2 to Drop.
2. Arm and raise the throttle for a moment. This avoids the 10-second "just disarm" case.
3. Disable the TX module while moving the throttle up and down.
4. Confirm that RXLOSS appears and that the motors stop and the quad disarms after about 1.5 s.
5. Re-enable the module and check that the quad will not arm until you flip the arm switch to disarmed.

To watch Stage 1 in detail, temporarily set the guard time to 10 s (failsafe_delay = 100, since the setting counts in 0.1 s steps) and give Stage 1 a hover throttle value. With the props off, you should hear the motors hold their speed for 300 ms, drop to the Stage 1 value and stay there until the quad disarms. Repeat the test, but restore the link inside Stage 1: the motors should respond to the sticks straight away. Afterwards set the guard time back (the default is 15, or 1.5 s).

Land and GPS Rescue need a field test as well. A FAILSAFE switch, assigned on the Modes tab, lets you enter and leave failsafe on demand. failsafe_switch_mode decides what it does: STAGE1 simulates real signal loss, STAGE2 skips straight to the Stage 2 procedure, and KILL disarms instantly. Avoid KILL for this, since a single glitch on that channel will drop the quad. Test Land at a height of about a metre over long grass or other soft ground, away from people and buildings, and start with a low throttle value. If a switch-triggered Land or Rescue test starts to drift, do not disarm in a panic. Flip the switch back and you have control again at once. Do not leave it for more than about 15 seconds, or the quad may disarm and crash.

Run the bench test again after every firmware update, every receiver change and any larger configuration change.

Get the warning before the failsafe

Failsafe is what happens after the link has gone. Most of the time you get warning signs first, provided the OSD shows them. ExpressLRS recommends setting both RSSI Channel and RSSI_ADC to Disabled in the Receiver tab and adding the Link Quality and RSSI dBm elements in the OSD tab (not "RSSI Value"). For the alarms:

• set osd_link_quality_alarm = 60 is the starting value ELRS suggests.
• osd_rssi_dbm_alarm should sit 5-10 dB above the sensitivity limit of your packet rate. At 250 Hz the limit is -108 dBm, so an alarm between -103 and -98 dBm.

A brief RXLOSS is a warning too: the Betaflight wiki describes it as an early sign of significant packet loss. When link quality drops in flight, turn back towards yourself, climb if there are obstacles in the way, and keep out from behind trees and buildings. One last ELRS rule: do not change packet rate or other Lua parameters while armed. Changing the packet rate forces a disconnect, and other changes can desync the link on some hardware, which means a failsafe.