What failsafe really does when the link drops

The symptom you are trying to avoid

There are two ways this ends, and you do not get to choose which.

The first is the fly-away. The link drops, the aircraft carries on doing whatever it was doing — a slow forward cruise, a gentle turn — and it keeps doing it, at altitude, until the battery is flat. You watch it shrink. Then you spend the afternoon walking a field with a phone, and the evening explaining to somebody why an aircraft came down in their garden.

The second is the sudden stop. The link drops, the motors cut, and 5 kg of airframe falls out of the sky. Over an empty field that is a cheap outcome and often the right one. Over a car park, a crowd, or a road, it is the worst thing your aircraft can possibly do.

Failsafe is the machinery that decides which of these happens, and under what circumstances. It is the single most safety-critical piece of configuration on the aircraft, and it is also the piece that most people copy from a forum post and never look at again.

Failsafe is TWO systems, and people forget one

This is the paragraph that matters. Read it twice.

There is a failsafe in your receiver, and there is a failsafe in your flight controller, and they are not the same thing. The receiver's failsafe governs what the receiver outputs to the FC when it can no longer hear the transmitter. The flight controller's failsafe governs what the aircraft does about the signal it is receiving. The FC cannot smell radio waves. It only sees what the receiver hands it.

Your receiver has, broadly, three choices when the transmitter disappears:

• Hold. Keep outputting the last channel values it received, indefinitely.
• Pre-set values. Output a set of positions you configured in advance — typically throttle low, or a specific switch position.
• No output at all, or an explicit "link lost" flag on the wire (most modern digital protocols carry a failsafe bit for exactly this).

Now look at what "hold" does. The link drops. The receiver dutifully keeps feeding the FC the stick positions from the last good frame — half throttle, a little forward pitch, whatever you happened to be holding. The flight controller sees a perfectly valid, perfectly stable RC stream and concludes that everything is fine. No failsafe fires. Nothing fires. The aircraft continues to fly the last command it ever received, out over the treeline, for as long as the battery lasts. Your beautifully configured FC failsafe — the return-to-home you spent an evening setting up — never runs, because as far as the FC is concerned there is nothing to return from.

That is the fly-away, and it is nearly always this. Not a firmware bug. A receiver configured to lie.

So: configuring the receiver to stop outputting, or to send an explicit failsafe signal the FC recognises, is what makes the flight controller's failsafe work at all. Everything in the rest of this article is downstream of that one setting. If you get it wrong, the rest of the article is decoration.

The one deliberate exception is the throttle-low trick: some pilots set the receiver to output pre-set values with throttle at minimum, which the FC will read as a genuine command to cut throttle. It works, but it is a blunt instrument — it hands you motors-off and nothing else, and it forecloses any chance of a return-to-home, because the FC never learns the link is gone. Prefer the explicit failsafe signal and let the FC decide.

What the flight controller can do about it

Once the FC knows the link is gone, it has a menu. Each option has real prerequisites, and each fails in its own way if those prerequisites are not met.

Be honest with yourself about that last row. Return-to-home is the failsafe everybody wants and the one with the most ways to go wrong. If the home point was set before the GPS had a decent fix, "home" is a point in a field two hundred metres away. If the heading source is bad — a magnetometer sitting next to a power lead, or a magnetometer-less setup that has to infer heading from motion — the aircraft can set off confidently in the wrong direction, or enter a slow toilet-bowl orbit and never converge. If the return altitude is below the trees between you and it, it will fly home through them.

RTH is not a magic word. It is a piece of navigation code with hard input requirements, and it will do precisely what you configured it to do, including the wrong thing.

Failsafe is not just RC loss

RC loss is the famous case, but every mainline firmware treats "failsafe" as a family of conditions, each with its own configured response:

• Low battery. Voltage or consumed capacity crosses a threshold and the aircraft warns, then acts — typically a forced land or return. Note that voltage sags under load, so a threshold tuned at hover can trip on a hard climb.
• GPS loss during a GPS-dependent mode. You are in a position-hold or a waypoint mission and the fix goes. What now? Firmwares generally fall back to an attitude-stabilised mode, which means the aircraft stops holding position and starts drifting with the wind — and if you are not watching, that drift is your problem now.
• Crash or gyro fault. Betaflight's crash-recovery and runaway-takeoff-prevention logic exists to stop a mis-tuned or damaged aircraft from spooling up into something dangerous. ArduPilot has its own crash-detection disarm.
• Geofence breach. A distance or altitude limit is exceeded and the aircraft acts — typically hold, return, or land. This is a failsafe you actively want on a heavy platform, and it is worth testing precisely because it can also trip on a bad GPS reading and pull you out of the air unexpectedly.

Each of these is separately configured. Setting up RC-loss failsafe and assuming the rest are handled is a common and expensive mistake.

The staged behaviour

Radio links glitch. A momentary dropout — a body between you and the aircraft, a brief multipath null, a passing van — lasts a fraction of a second and then recovers. If every one of those threw the aircraft into a full return-to-home, the aircraft would spend its life abandoning you mid-manoeuvre, and you would learn to hate and eventually disable the feature.

So mainline firmware stages it. Betaflight is explicit about this with its stage 1 / stage 2 concept: on the first sign of a bad link, the FC applies a short holding behaviour — a brief, benign set of outputs, roughly "keep the thing in the air and do nothing dramatic" — and waits. If the link comes back within that grace period, flight resumes as though nothing happened, and you will often not even notice. Only if the link stays gone does the FC commit to the real failsafe procedure: the drop, the landing, or the rescue.

That grace period is a deliberate trade. Too short and you get spurious failsafes on a link that was fine. Too long and the aircraft flies onward, uncommanded, for the duration before anything happens — which at cruise speed can be a meaningful distance in the wrong direction. Look up what your firmware's default actually is and decide whether it suits how you fly; do not assume it was chosen with a 5 kg platform in mind.

Testing it — the part nobody does

Here is the uncomfortable truth. Almost nobody tests failsafe. It is the only feature on the aircraft that runs exclusively when things have already gone wrong, which means the first time most people find out what their failsafe does is the moment they most need it to be correct.

Failsafe that has never been tested is not a safety feature. It is a hypothesis.

Test it like this:

1. Props off. Not "props on but I'll be careful." Off — the same rule that governs every check before the first power-up. You are about to deliberately provoke the aircraft into changing its motor outputs while you stand next to it.
2. Connect the Configurator or ground station so you can see the FC's state. Power the aircraft, bind, and arm.
3. Turn the transmitter off. Not the model — the whole radio.
4. Watch what the FC reports. Does it register the link loss at all? Does it flag failsafe? Does the receiver's output go to your configured values, or does it sit there holding your last stick positions like nothing happened? If it is the latter, stop — you have found the fly-away, and you have found it on a bench instead of at 400 feet.
5. Turn the transmitter back on and confirm the aircraft recovers the way you expect, including whether it needs a disarm/re-arm cycle before it will fly again.

Only when the bench test is unambiguously right do you go outside. Then: props on, a low hover, over grass or dirt, nothing and nobody downwind, and switch the radio off. Watch what it actually does. If it is configured to drop, it drops from a metre and you learn something cheaply. If it is configured to return, you watch it climb and turn — and that is the moment you find out whether your home point and your heading are what you thought they were.

Do not skip the bench stage, and never provoke a failsafe with props fitted while the aircraft is on a table in front of you. An aircraft that decides to execute a rescue climb on a bench is a large, sharp, unrestrained object at head height.

What good failsafe configuration looks like

• The receiver does not hold last-known stick positions. It either stops outputting or sends an explicit failsafe signal the FC recognises.
• The flight controller is confirmed to detect that condition — you have watched it flag failsafe with your own eyes, on a bench, props off.
• The chosen action matches the aircraft and the ground you fly over. Motors-off over an empty field is a defensible choice. Motors-off over anything else is not.
• If you rely on return-to-home, you have verified the home point is set at arming with a real fix, the heading source is trustworthy, and the return altitude clears everything between you and the launch point.
• Battery, GPS-loss and geofence responses are configured deliberately, not left at whatever the defaults happened to be.
• You know roughly how long the grace period is, and you are content with how far the aircraft can travel in that time.
• You have tested it — on the bench, then at a low hover — and you re-test after any change to the receiver, the radio, or the firmware.

That last point is the whole article. Every other line is a setting; that one is the difference between a safety feature and a hope.