A pilot at my local chapter flew a 5-inch racer on SBUS for two years, then swapped to CRSF. His first comment after landing: “I thought my quad had delay because of the tune. It was the receiver the whole time.” The protocol between your radio and flight controller sets a hard floor on how fast the quad responds. Pick the wrong one and you’re tuning around latency that shouldn’t exist.
The Four Protocols: What Each One Does
SBUS (Futaba Serial Bus)
SBUS is the oldest protocol still in common use. It runs at 100,000 baud — about 100 kbps — and sends channel data at a fixed 9 ms frame rate (roughly 111 Hz). It carries 16 proportional channels and two digital channels, but only in one direction. SBUS is a receive-only wire: the receiver talks to the flight controller, and that’s it. No telemetry without a separate wire.
The signal is inverted, which means you either need a flight controller with a dedicated SBUS pad (with a hardware inverter) or you run an uninverted signal from the receiver. Most modern F4 and F7 flight controllers handle this natively.
Latency on SBUS is around 15-20 ms frame-to-output, depending on your radio. For freestyle and casual flying, this is fine. For racing, it’s a handicap.
CRSF (Crossfire — TBS)
CRSF is TBS’s serial protocol, running at 400,000-1,800,000 baud depending on the firmware. It’s bidirectional: the same two wires (TX and RX) carry channel data to the flight controller and telemetry back to the radio. Channel resolution is 11 bits (2048 steps) per channel, up from SBUS’s 10-bit resolution.
The real advantage is frame rate. CRSF at 150 Hz sends an update every 6.7 ms. At 250 Hz, it’s every 4 ms. For a racer who’s on the edge of a gate at 120 km/h, that difference is real — the quad responds to stick input two frames faster than SBUS.
CRSF also supports full MAVLink telemetry passthrough, so your radio’s screen can display GPS coordinates, battery voltage per cell, and RSSI without any additional wiring.
FPort (FrSky)
FPort is FrSky’s unified serial protocol — one wire for both channel data and telemetry, running at 115,200 baud. It’s FrSky’s answer to CRSF, but with a lower baud rate. Latency sits around 9-14 ms at the standard 100 Hz update rate, which is better than SBUS but not as fast as CRSF.
FPort’s main advantage is simplicity: one wire to the flight controller, and you’re done. The downside is it only works within the FrSky ecosystem. If you switch radio brands, your receivers become paperweights.
FPort also requires specific Betaflight configuration — the serial port must be set to “Serial RX” with FPort as the provider, and the receiver must be wired to a TX pad, not the SBUS pad. Wiring it wrong is the most common FPort setup mistake I see.
ExpressLRS (ELRS — CRSF Shot)
ExpressLRS uses the CRSF protocol over its own 2.4 GHz or 900 MHz LoRa link, but with a key addition: CRSF Shot. This is a modified CRSF implementation that sends channel data as soon as the radio frame is received, eliminating the 1-2 ms delay that standard CRSF adds while the receiver processes the packet. The result is sub-4 ms end-to-end latency at 500 Hz packet rates.
ELRS at 500 Hz with CRSF Shot delivers latency numbers that make SBUS look like dial-up. The trade-off is packet rate vs range — 500 Hz is for close-in racing, 50 Hz is for 30 km long-range flights. The protocol dynamically steps down the rate as signal quality drops, so you don’t lose the link; you just lose a few milliseconds of responsiveness.
Receiver Protocol Comparison Table
| Protocol | Baud Rate | Update Rate | Latency (approx) | Bidirectional | Telemetry | Ecosystem |
|---|---|---|---|---|---|---|
| SBUS | 100,000 | 111 Hz (9 ms) | 15-20 ms | No | Separate wire | Universal |
| FPort | 115,200 | 100 Hz (10 ms) | 9-14 ms | Yes | Single wire | FrSky only |
| CRSF | 400K-1.8M | 150-250 Hz | 4-8 ms | Yes | Single wire | TBS / ELRS |
| ELRS CRSF Shot | 1.8M+ | 50-1000 Hz | 2-4 ms | Yes | Single wire | ExpressLRS |
Common Receiver Protocol Setup Mistakes
Mistake 1: Wiring FPort to the SBUS pad. FPort uses an inverted, bidirectional signal on a single wire. It must connect to a TX pad on the flight controller, not the SBUS pad. The SBUS pad is UART RX with an inverter — FPort needs UART TX. If you wire FPort to SBUS and it doesn’t work, this is why.
Mistake 2: Running CRSF at 400K baud by default. CRSF ships at 400K baud to be compatible with everything, but it supports up to 1.8M baud on F7 flight controllers. The higher baud rate reduces latency because the serial frame transmits faster. Set your TBS receiver to 1.8M and match it in Betaflight’s Ports tab — you’ll see the effective update rate jump.
Mistake 3: Forgetting to set the serial receiver provider in Betaflight. Wiring the receiver to the right pad is step one. Setting the correct provider in Betaflight is step two. SBUS needs “SBUS” as the provider. CRSF needs “CRSF.” FPort needs “FPORT.” If the protocol is wrong, Betaflight sees garbage on the serial line and the receiver tab shows no movement.
Mistake 4: Using SBUS for a racing build in 2026. SBUS was standard in 2017. In 2026, CRSF and ELRS cost the same or less, and the latency difference is measurable in lap times. There’s no reason to spec SBUS on a new build unless you’re deliberately maintaining compatibility with legacy hardware.
⚠️ Regulatory Notice: The choice of receiver protocol may affect your drone’s compliance with 2026 Remote ID requirements and frequency regulations. ExpressLRS operates in the 2.4 GHz ISM band (globally unlicensed) and the 868/915 MHz SRD bands (region-specific). The 868 MHz band in Europe has a 1% duty cycle limit under ETSI EN 300 220 that ELRS LBT firmware respects via listen-before-talk. Always flash region-appropriate ELRS firmware — using 915 MHz hardware in an 868 MHz region is a spectrum violation. The CRSF protocol at 900 MHz requires an amateur radio license in some jurisdictions (Australia, parts of Asia).
Our deep dive on ExpressLRS 3.x flashing covers the firmware update procedures for ELRS receivers — matching your receiver protocol to your flight controller configuration starts with a clean flash.
The ELRS packet rate tuning guide explains when to run 500 Hz for racing and when to drop to 50 Hz for long-range — the protocol flexibility is one of ELRS’s strongest features.
Receiver protocol latency starts with the hardware link. The uavmodel ExpressLRS 2.4 GHz receiver runs a PA/LNA chipset that holds 500 Hz packet rates at 5+ km, giving you racing-level responsiveness with long-range reach — no protocol compromise needed.