A Crossfire receiver running CRSF at 150Hz delivers stick inputs to your flight controller in 6.7 milliseconds. That same receiver running SBUS — even with the same radio link — takes 14 milliseconds, more than double the latency. The protocol between your receiver and flight controller matters as much as the radio link itself. Here’s what each protocol does, where they differ, and how to pick the right one for any build.
FPV Receiver Protocols: What They Are and Why They Matter
A receiver protocol is the serial communication format between your receiver and flight controller. It determines three things: how fast stick positions reach the flight controller (latency), how much telemetry data flows back to your radio (bandwidth), and how many wires you need (wiring complexity). The differences are measurable in flight feel — and once you’ve flown CRSF or F.Port after SBUS, going back feels like flying through molasses.
Protocol 1: SBUS — The Universal Default
SBUS is Futaba’s inverted serial protocol, running at 100,000 baud. It has been the standard for a decade and every flight controller supports it natively. It is also the slowest modern protocol and carries zero telemetry.
Specifications:
– Baud rate: 100,000
– Frame rate: 7ms (Fast SBUS) or 14ms (standard)
– Channels: 16 proportional + 2 digital
– Telemetry: None
– Wiring: 3 wires (5V, GND, Signal)
– Inverted signal: Yes (requires hardware UART inversion on F4 FCs)
Best for: Budget builds where latency doesn’t matter, fixed-wing with simple channel requirements, or any build using a receiver without CRSF or F.Port support.
The inversion problem: SBUS is an inverted UART signal. F7 and H7 flight controllers handle inversion in hardware — just connect SBUS to any RX pad. F4 flight controllers require a dedicated SBUS pad with a hardware inverter. Connecting SBUS to a regular UART RX on an F4 gives you nothing — the FC literally cannot read the inverted signal. This has wasted more hours of troubleshooting than any other single wiring issue in FPV.
Protocol 2: CRSF (Crossfire) — The Performance Standard
CRSF is TBS Crossfire’s native protocol, now also supported by ExpressLRS receivers. It is the fastest widely-available protocol with full-duplex telemetry at high bandwidth. If you fly Crossfire or ExpressLRS, use CRSF. Period.
Specifications:
– Baud rate: 400,000 (standard) or 1,800,000 (CRSFshot on Crossfire)
– Frame rate: 150Hz (standard), 500Hz (CRSFshot)
– Channels: 16
– Telemetry: Full duplex — GPS, battery voltage, RSSI, link quality, and custom sensors
– Wiring: 4 wires (5V, GND, TX to FC RX, RX to FC TX)
– Inverted signal: No (standard UART)
Best for: Any build where latency matters (racing, freestyle), any build using telemetry (GPS, long-range), any ExpressLRS or Crossfire receiver — which is basically everything modern.
CRSFshot note: CRSFshot (1.8M baud, 500Hz) requires a capable flight controller UART. Most F7/H7 FCs handle it, but verify your UART can negotiate 1.8M baud before enabling. If the FC can’t keep up, you’ll get RX Loss warnings in flight.
Protocol 3: F.Port — The One-Wire Wonder
F.Port is FrSky’s protocol that combines SBUS channel data and S.Port telemetry on a single wire. It was FrSky’s answer to CRSF — decent latency, full telemetry, one less wire. The catch is that F.Port is an inverted half-duplex signal, which makes it finicky to set up on some flight controllers.
Specifications:
– Baud rate: 115,200
– Frame rate: 7ms
– Channels: 16
– Telemetry: Half duplex via S.Port — GPS, battery, RSSI, and FrSky sensors
– Wiring: 3 wires (5V, GND, single bidirectional signal wire)
– Inverted signal: Yes (inverted and bidirectional)
Best for: FrSky ACCESS/ACCST receivers that support F.Port. Saves a UART (one wire handles both RC control and telemetry). Good for compact builds where every pad counts.
The F.Port wiring trap: F.Port on an F4 FC requires connecting to the TX pad of a UART (not RX), with SoftSerial or a hardware mod to handle the bidirectional inversion. On F7/H7, connect to any TX pad and enable half-duplex in Betaflight. Get this wrong and nothing works — no stick input, no telemetry.
Protocol 4: IBUS — The Budget Option
IBUS is FlySky’s protocol, running at 115,200 baud with basic telemetry support. It works, it’s reliable, and it’s slow. For budget builds with FlySky radios, it’s your only option — and it’s perfectly fine for learning.
Specifications:
– Baud rate: 115,200
– Frame rate: 7ms
– Channels: 10 (older) or 14 (iBUS2)
– Telemetry: Basic sensors only (voltage, RSSI)
– Wiring: 3 wires (5V, GND, Signal to FC RX)
– Inverted signal: No
Best for: Budget builds, beginners using FlySky radios, or any situation where a $15 receiver on a $80 whoop is the right call.
Receiver Protocol Comparison Table
| Protocol | Baud Rate | Frame Rate | Telemetry | Wires Needed | Inverted | Best Radio System |
|---|---|---|---|---|---|---|
| CRSF | 400K-1.8M | 150-500Hz | Full duplex, high bandwidth | 4 | No | Crossfire, ExpressLRS |
| F.Port | 115K | 7ms (143Hz) | Half duplex via S.Port | 3 | Yes (bi-dir) | FrSky ACCESS/ACCST |
| SBUS | 100K | 7-14ms (71-143Hz) | None | 3 | Yes | Universal (all systems) |
| IBUS | 115K | 7ms (143Hz) | Basic (voltage, RSSI) | 3 | No | FlySky |
| SRXL2 | 115K | 5.5ms (182Hz) | Full via SRXL2 sensors | 3 | No | Spektrum |
What Most Pilots Get Wrong
Mistake 1: Running ExpressLRS on SBUS instead of CRSF. ExpressLRS receivers default to CRSF but can be switched to SBUS for compatibility with older flight controllers. Consequence: You bought a 500Hz radio link and you’re bottlenecking it through a 14ms SBUS frame. Your actual stick-to-air latency doubles. Fix: In the ExpressLRS receiver’s web UI, ensure the protocol is set to CRSF, not SBUS. In Betaflight, set the receiver protocol to “CRSF” in the Receiver tab.
Mistake 2: Connecting SBUS to a random UART RX pad on an F4 FC. SBUS is inverted. F4 UARTs require an external inverter or a dedicated SBUS pad. F7/H7 UARTs handle inversion natively. Consequence: “Receiver not detected” errors that persist through firmware reflashes, wiring checks, and everything short of replacing the FC. Fix: On F4, use the dedicated SBUS pad (usually labeled SBUS or RX1 with an inverter). On F7/H7, any RX pad works.
Mistake 3: Enabling CRSFshot (1.8M baud) on a UART that can’t handle it. Not all UARTs on a flight controller can sustain 1.8M baud. Some F7 chips have specific UARTs clocked differently. Consequence: Intermittent RX Loss warnings — the UART drops bytes, the CRSF frame gets corrupted, and Betaflight triggers failsafe for one frame before recovering. It happens so fast you might barely notice a twitch, but your blackbox log is full of RX Loss flags. Fix: Stick to 400K baud CRSF unless you’ve verified your specific FC supports 1.8M on the UART you’re using. Check the manufacturer’s pinout diagram for UART clock speeds.
Mistake 4: Not connecting the TX wire from CRSF receiver to FC RX for telemetry. Some pilots connect only three wires (5V, GND, RX-to-TX) for CRSF, leaving telemetry disconnected. Consequence: No LQ (link quality) in OSD, no RSSI dBm, no GPS coordinate passthrough from the FC to the radio. You’re flying without the data that tells you when you’re about to failsafe. Fix: CRSF requires four wires. TX on the receiver goes to RX on the FC. Without it, you get stick input but zero telemetry.
⚠️ Regulatory Notice: The receiver and radio protocol configurations in this article should be followed in accordance with the latest 2026 drone regulations in your country or region. Always verify local laws regarding radio frequency usage, transmission power limits, and remote ID requirements. Regulations vary significantly between the FCC (US), ETSI (EU), Ofcom (UK), SRRC (China), and other authorities. Some regions restrict certain frequency bands (900MHz, 868MHz) or require amateur radio licensing for specific power levels.
For a complete guide to binding and updating your ExpressLRS receivers, see our ExpressLRS 3.x WiFi and Backpack Flashing guide. If you’re setting up RSSI and link quality warnings in your OSD, our Betaflight OSD Customization article covers element placement and warning thresholds.
The Happymodel EP1 Dual TCXO ExpressLRS receiver on CRSF at 250Hz is the best $13 you can spend on a 5-inch build — genuine 5km+ range with solid LQ telemetry. Pair it with any F7 FC and you’ve got a radio link that outperforms setups costing five times as much.