There is no universal relationship between the two. An FPV build may use one radio system for control and another for video, with different antennas, frequencies, error handling, transmit powers and ground equipment. An integrated digital system may share more of the transport. Either way, a displayed image is evidence that some video reached the viewer, not proof that the flight controller is receiving valid commands now.
Separate the paths before interpreting the indicators
A conventional ExpressLRS-equipped FPV aircraft sends transmitter commands to the onboard receiver, which delivers channel and link-status data to the flight controller. The flight controller decides when those inputs are no longer valid and what failsafe behavior follows. A separate camera, video transmitter and receiver or goggles carry the image, potentially with an on-screen display added from flight-controller telemetry.
These paths have different definitions of success. The control receiver needs timely, valid packets containing a usable command state. The video decoder needs enough information to reconstruct a view; it may conceal some errors or continue displaying an old frame. A frozen but attractive frame is particularly poor evidence of present aircraft state.
ExpressLRS documentation distinguishes uplink measures at the aircraft from downlink telemetry measures received at the handset. Its FAQ identifies RQly as valid command packets received from transmitter to receiver, while TQly measures telemetry packets received in the other direction. One can degrade without identical behavior in the other. A healthy transmitter-side telemetry display is not a substitute for checking what the receiver actually got.
Not every setup uses physically separate radios. WFB-ng, an open-source raw-Wi-Fi transport, can carry RTP video alongside bidirectional MAVLink and other traffic. It offers separate streams, traffic shaping and forward error correction. Sharing a radio transport joins the failure budget, but it still does not make video decode, telemetry delivery and timely control commands the same measurement.
Link quality, signal strength and picture quality measure different things
ExpressLRS reports received-signal strength in dBm and link quality as the share of expected packets received. Its signal-health guide explains why neither metric replaces the other. Link quality can remain near its ceiling while the received signal approaches the sensitivity boundary for the selected packet rate. When that boundary is crossed, usable packets may disappear quickly. A fixed RSSI warning that ignores the active RF mode is therefore a poor general rule.
A display marked simply “RSSI” can be less useful still. The same documentation distinguishes a genuine dBm measurement from legacy percentage-like RSSI values, which depend on configuration and scaling. Pilots should identify the exact field on their OSD rather than treating every number from zero to 100 as interchangeable.
Video has its own accounting problem. Packet loss may be masked by forward error correction, but redundancy consumes channel capacity and recovery takes processing time. WFB-ng documents configurable forward error correction and channel-state logging. A useful video health record needs packet recovery, unrecovered loss and latency or frame-age information, not just a subjective score for image sharpness. A link can look excellent until a burst of loss exceeds what its decoder or redundancy scheme can absorb.
A blurred or blocky picture can also reflect camera exposure, encoder behavior or a bad local display path. No RF conclusion follows from the image alone. Conversely, clear video does not rule out an RC receiver fault, flight-controller serial fault or a link-quality collapse on a different band.
The flight controller has its own loss boundary
The firmware's definition of missing control is the operational boundary. Betaflight's failsafe documentation describes signal-validation, a guard stage and a later stage in which the configured response can disarm, land or invoke GPS Rescue. The timing, defaults and recovery conditions depend on the firmware and configuration; a pilot should not infer them from how long the goggles keep showing video.
This distinction creates several combinations that need different interpretation:
- Video present, commands absent: the aircraft may already be in an RC-loss response even though the view remains live. The recovery procedure depends on the selected failsafe mode.
- Commands present, video absent: the aircraft may still be receiving control, but the pilot has lost the visual information required for ordinary FPV flight. This is a separate operational emergency.
- Uplink good, telemetry downlink poor: control may remain effective while handset warnings or returned aircraft data become incomplete. ExpressLRS exposes the two directions separately.
- Both links unstable: a shared power fault, bad antenna installation, local interference or a common radio transport may be involved. The symptom alone cannot identify which.
In particular, a GPS Rescue configuration is not a general guarantee of safe recovery. It requires the relevant sensors, usable navigation state and appropriate configuration for the aircraft and environment. The Betaflight failsafe guide warns that the selected action must be configured deliberately.
Test the handoff without turning a flight into a radio experiment
Start with the exact aircraft, receiver firmware, transmitter configuration, flight-controller build and video system in use. On a restrained bench setup with propellers removed, confirm that current stick inputs change at the flight controller. Record which on-screen fields come from the RC receiver and which come from the video receiver. Confirm that a signal indication is still updating, rather than showing a stale last value.
Next, follow the firmware manufacturer's prescribed, propeller-off failsafe procedure. Check what the flight controller reports after control packets stop, which stage it enters, what action it would command and how recovery is recognized. A transmitter switch that invokes a failsafe is not always equivalent to a real receiver or serial-link loss; Betaflight documents different activation and recovery paths. Do not use uncontrolled airborne link interruption as a substitute for this check.
Inspect antenna placement and cable routing separately for the control receiver and video transmitter. In a combined radio system, also examine whether video traffic can delay safety-related messages and what priority or redundancy settings the transport supports. WFB-ng's documentation describes both traffic shaping and stream-specific configuration, but those features need validation on the installed hardware.
A flight review is stronger when it joins synchronized records. Useful fields include the RF mode and control-link quality at the aircraft, RSSI in dBm, returned telemetry quality, video packet-loss or FEC statistics where available, frame freezes, and flight-controller failsafe flags. Without timestamps, a reported one-second interruption can be difficult to attribute to the right subsystem.
What would establish a reliable margin?
A confident radio design needs more than a range claim or a flight that happened to finish. Repeatable tests should vary orientation, antenna shadowing, transmitter configuration and realistic interference conditions within the law. Log the worst periods of packet delivery and the time between a failure beginning and the flight controller recognizing it. For video, measure both recovered and unrecovered loss and the age of the displayed frame.
Results need to distinguish a short packet-loss burst from a sustained link failure. One may be hidden by error correction; the other can trigger a flight-controller safety transition. Comparing two systems solely at the point where their pictures become unusable omits the condition of their control paths.
The operational rule is simple: assess command delivery, returned telemetry, video continuity and failsafe state as separate signals. A picture may be clear and still be the wrong instrument for judging whether the aircraft can be controlled.