That is why a failsafe setting cannot be evaluated by reading one menu. The engineering question is whether the receiver's loss indication, the autopilot's detection logic and the intended aircraft response form a complete sequence. The result also depends on the current flight mode, available navigation aids and whether other links have failed at the same time.
The receiver determines what the autopilot sees
A receiver has to translate a missing radio signal into something on its output interface. That translation is part of the safety system.
The ExpressLRS transmitter Lua documentation distinguishes SBUS failsafe choices. With No Pulses, channel messages stop. With Last Pos, the receiver can continue sending the previous channel values while setting the SBUS failsafe flag. An autopilot that interprets that flag can recognize a loss even though the numerical stick positions have not moved. The same numerical positions without a valid failsafe indication are a different situation.
A PWM receiver presents another interface. The ExpressLRS PWM receiver documentation describes configurable fallback channel positions and its own signal-loss handling. A controller reading individual PWM channels cannot rely on an SBUS status bit that is not present on those wires. Its ability to detect radio loss depends on what the receiver does to pulse timing and values, and on the flight controller's configuration.
These behaviors are protocol- and firmware-specific. The EdgeTX RF settings documentation likewise describes different receiver or module failsafe controls for different radio protocols. A label such as “hold” on the transmitter is not enough to establish what an attached autopilot will detect.
The first bench observation should therefore be made at the flight controller, not inferred from the radio menu: when RF is removed, do channel frames stop, does a failsafe flag appear, or do valid-looking preset channels continue?
Autopilot detection and action are separate choices
ArduPilot Copter's radio failsafe documentation describes detection by missing receiver updates and, in applicable configurations, a low-throttle indication or loss of RC overrides. It warns that a receiver configured to hold its last values may conceal a radio loss from the controller. For some digital protocols a failsafe status indication supplies additional evidence; the specific receiver interface still needs to be checked.
Detection only starts the second decision: what should the aircraft do? In Copter, that can mean landing, RTL, SmartRTL or another configured outcome, subject to mode and navigation conditions. It is not equivalent to forcing the flight-mode channel to an RTL position. The latter can resemble a manual mode change, bypass the intended loss handling and behave differently on reconnection.
PX4 exposes a related but distinct configuration. Its safety and failsafe documentation separates the RC-loss timeout and action from flight-mode exceptions, alongside the time allowed before an action is applied. Parameter names such as COM_RC_LOSS_T and NAV_RCL_ACT make those decisions explicit, but copying a parameter value from another airframe does not validate the result. A position-dependent return action has different prerequisites from a controlled descent.
Autopilot branches and vehicle types must also be kept distinct. A fixed-wing aircraft, helicopter and multicopter do not necessarily have the same safe response to an absent pilot command. ArduPilot Plane's failsafe guidance addresses behavior specific to that vehicle class.
Ground-station loss is not RC loss
A MAVLink telemetry connection to a laptop or operations console is usually a separate link from the receiver's RC input. Its disappearance can matter even while the aircraft remains controllable by radio.
ArduPilot's GCS failsafe documentation uses ground-station heartbeat reception and a timeout to identify a missing GCS, with conditions that differ from the RC failsafe. PX4's safety configuration likewise specifies data-link loss independently of manual-control loss, including COM_DL_LOSS_T and NAV_DLL_ACT.
That distinction creates at least four testable states: radio present with GCS present; radio absent with GCS present; radio present with GCS absent; and both absent. Treating the last three as the same “link lost” case can hide a conflict between configured actions.
There can also be a third-party companion computer or application sending manual-control or override messages. An operator should identify which input source actually controls the vehicle and which heartbeat or timeout is being monitored. A live video feed does not, by itself, prove that the radio or command path remains healthy.
Redundant receivers add a handover boundary
Two receivers do not automatically provide uninterrupted control. The autopilot needs a clear rule for selecting an active source, deciding that it is no longer valid and accepting a replacement.
ArduPilot's multiple-receiver guidance describes receiver precedence and switching when an input is no longer considered valid. A fallback receiver with a different channel order, calibration or failsafe output can be accepted electrically and still command an unexpected value. Likewise, a receiver that holds apparently valid frames can delay failover.
The test is not simply whether either receiver works alone. It is whether the active receiver can fail while the aircraft transitions to the expected input source, and whether the selected channel values remain consistent across that transition.
A bench-test matrix worth recording
Remove propellers and secure the airframe before exercising motors, receivers or mode changes. Use a simulator for situations that require flight dynamics, GNSS loss or an automatic landing. A propeller-free bench pass verifies command and state transitions, not the safety of the resulting trajectory in the air.
- Record the starting state. Save the flight-controller firmware version, receiver firmware and output protocol, radio failsafe configuration, control mode, relevant RC/GCS timeout parameters and the current navigation state.
- Interrupt RF, not receiver power. Observe the raw channel stream or failsafe flag if accessible, the flight controller's reported RC-valid state, elapsed time to detection, selected failsafe action and any flight-mode change.
- Interrupt only the GCS link. Keep the RC path intact. Check the GCS heartbeat timeout and whether the controller takes the configured data-link-loss action or deliberately ignores the event in the current mode.
- Remove both links. Confirm which event is recognized first and what action remains in force. PX4 documents interaction and priority among failsafes; do not assume the latest event always wins.
- Restore the links and repeat in relevant modes. Check whether a reconnect automatically restores pilot control, requires an explicit mode change or leaves the aircraft executing a safety action. In ArduPilot Copter's documented behavior, RTL does not automatically return to the previous flight mode solely because the radio reconnects.
Log the time of each interruption, receiver output, autopilot state and action. Where possible, compare controller logs with receiver or transmitter telemetry. If the two timelines disagree, the discrepancy is worth resolving before any live-flight validation.
The most informative failure is a mismatch: the transmitter declares a lost link while the flight controller still sees normal channels; the controller detects RC loss but selects an unavailable navigation action; or a restored link unexpectedly cancels the planned response. Each points to a different configuration or integration problem.
What the test can and cannot prove
A successful bench sequence establishes that a particular receiver, protocol, firmware build and autopilot configuration produce the expected state transitions under the tested conditions. It does not prove reliable radio range, safe behavior during a turn, or a controlled landing with damaged sensors.
The same discipline should be applied after changing receiver firmware, moving from SBUS to CRSF or PWM, adding an RC-over-MAVLink source, changing autopilot failsafe settings or fitting a second receiver. The important artifact is a repeatable record of what actually reached the flight controller and what it did next, rather than a screenshot of an enabled failsafe option.