This post will give a broad overview of all the common RC protocols in FPV, and how they fit into the communication system in an FPV drone, and what their differences are.
Some of the links on this page are affiliate links. I receive a commission (at no extra cost to you) if you make a purchase after clicking on one of these affiliate links. This helps support the free content for the community on this website. Please read our Affiliate Link Policy for more information.
Table of Contents
What are RC Protocols?
A protocol is like the language spoken between devices within an FPV drone.
Different components use different protocols, so some components, like the receiver and the flight controller, have to be bilingual – they “listen” in one language (input) and “speak” in another language (output).
FPV Drone Communication System Overview
Protocols in FPV can be divided into 3 groups:
- TX Protocols – communication between radio transmitter (TX) and radio receiver (RX)
- RX Protocols – communication between radio receiver (RX) and flight controller (FC)
- ESC Protocols – communication between FC and ESC
Each of these links has different requirements, which is why different protocols are used.
TX Protocols
The communication between radio and receiver is wireless.
Most radio manufacturers have their own proprietary TX protocols unless it’s an open source radio system like ExpressLRS.Here is a list of common TX protocols:
- ACCST (Frsky)
- ACCESS (Frsky)
- DSM (Spektrum)
- DSM2 (Spektrum)
- DSMX(Spektrum)
- AFHDS (Flysky)
- AFHDS 2A (Flysky)
- A-FHSS (Hitec)
- FASST (Futaba)
- Hi-Sky (Deviation / Devo)
Frsky’s TX Protocols
Frsky has two TX protocols, ACCST and ACCESS. Note that for ACCST, there is the older V1 and the newer V2, and the two are not compatible.
ACCST:
- D16: for X-series receivers, e.g. X4R-SB, R-XSR, XM+
- D8: for D- and V-series receivers, e.g. D4R-II, D8R-II+, V8FR-II, VD5M, etc
- LR12: for the long range receiver L9R
ACCESS: Frsky’s latest air protocol,New Frsky Air Protocol – ACCESS
Spektrum’s DSM2 and DSMX
DSM2 and DSMX are the two TX protocols used by Spektrum radios.
DSM2 signal is known to be resistant to noise, interference and other transmitters transmitting on the same frequency. It also finds a backup frequency at start-up in case the primary frequency fails. This greatly lowers the chance of losing signal, however if both channels becomes unusable you may still lose the connection.
DSMX was based on and improved from DSM2, which also uses the same encoding scheme. The difference is the DSMX signal is able to switch to a new frequency channel in case of cut out within a couple of milliseconds, so in theory you wouldn’t even notice the glitch.
DSM2 is still a popular technology, if you are away from sources of radio interference (such as WiFi, microwaves, and wireless security cameras), it should work just as well as DSMX, but DSMX for sure is more reliable.
RX Protocols
Unlike the communication between TX and RX, the communication between RX and FC is a wired communication. It is desirable that the protocol have low latency. Latency is basically the time it takes the receiver to “translate” the signal from the transmitter into the signal that it is going to send to the flight controller. Less latency means your quadcopter will respond quicker to what you tell it to do.
Some RX protocols are universal and used in receivers from different manufactures, but some can be exclusive to certain brands. Here is a list of common RX protocols:
- PWM (universal)
- PPM or CPPM (universal)
- SBUS(Futaba, Frsky)
- IBUS (Flysky)
- XBUS (JR)
- MSP (Multiwii)
- CRSF (ExpressLRS, TBS Crossfire and Tracer)
- SPEKTRUM1024 (Spektrum DSM2)
- SPEKTRUM2048 (Spektrum DSMX)
- FPort (Frsky)
- SPI_RX (universal) – More detail in this article
- GHST (ImmersionRC Ghost)
PWM – Pulse Width Modulation
PWM stands for pulse width modulation. This is perhaps the oldest radio control protocol, back in the days when there was no flight controller, the receivers were used to control the servos and ESC directly with standard PWM signal.
It involves three wires, typically colored as ground (black), +5V (red), and signal (white or yellow), which communicate with devices like servos or ESCs (Electronic Speed Controllers).
The length of the pulse specifies the servo output or throttle position, and therefore it shares characteristics of both digital and analog signals. The length of the signal pulse normally varies between 1000µs and 2000µs (micro seconds), with 1000µs being the minimum & 2000µs the maximum.
The downside of this is probably the wiring mess, as you have one servo cable for every channel. And so PPM and SBUS are often preferred over PWM when using an FC, which pass all the channels through a single wire and yet offer the same performance if not better.
PPM – Pulse Position Modulation
PPM is also known as CPPM or PPMSUM. A PPM signal is basically a series of PWM signals sent one after another on the same signal wire, and modulated differently.
The advantage of PPM over PWM is that only one single wire is needed for several channels, educing the cable clutter. So typically, you would only need to connect the ground, power and signal wires for up to 8 channels.
As the channel values don’t arrive at the same time, it’s not as accurate or jitter-free as serial communications (which we will cover in a minute).
Serial Protocols
A serial protocol is a digital loss-less protocol that uses only 3 wires (signal, power, ground) for multiple channels. Unlike PPM which is a signal in time domain, serial protocols are completely digital which means they are made up of a bunch of one’s and zero’s.
As the name suggests, serial protocols require a serial port on the flight controller (aka UART).
SBUS
Aka S.BUS or Serial BUS, is commonly used by Futaba and FrSky. It supports up to 16 channels using only one signal wire.SBUS signal should be connected to the RX pin of an UART.
Note that the SBUS signal in Frsky’s receivers is inverted, and therefore (normally) on F1 and F4 FC, there are dedicated SBUS input which indicates there is an inverter in place for the inverted SBUS signal. However for F3 and F7 FC’s, the processor has built-in inverters on all of their UART’s, and so you can connect SBUS to any UART you want.
CRSF
CRSF is developed by Team Black Sheep (TBS) for their Crossfire RC system. It’s similar to SBUS or other digital RX to FC protocols. With just four wires and the capability of both telemetry and radio control, it’s a robust and efficient technology. ExpressLRS’s adoption of CRSF is a testament to its potential.
The main advantages include fast update rate and two-way communication capabilities, allowing features such as hassle free Telemetry to be injected into the radio link with no additional UART port required.
IBUS
IBUS is flysky’s serial protocol. It’s a two way communication which means it can send and receive data: one port for servo data output and one port for sensors.
XBUS
XBUS is used by JR, which supports up to 14 channels in one signal wire. One of the advantages is the tiny time delay between each channel.
MSP
MSP (Multiwii Serial Protocol) was created as part of the multiwii software. Basically it allows you to use MSP commands as the RC input and it supports 8 channels in one signal cable.
FPort
FPort is developed by Frsky and Betaflight developers. Normally, control signal and telemetry data requires separate connections, but FPort manages to combine them into one single bi-directional signal, which makes it more compact and easier to manage.
Unlike Frsky’s SBUS which is inverted, FPort is compatible with F4 flight controllers UART without additional inverters or hacks.
You can learn more about FPort and how to setup here.
MAVLINK
MAVLINK is a telemetry protocol similar to SmartPort. While SmartPort is developed by FrSky, MAVLINK is developed by the Pixhawk/ArduPilot community. Both are robust, allowing for two-way communication between the controller and device. This real-time feedback is invaluable, especially for drones, providing crucial flight data.
ESC Protocols
Communication between the FC and ESC’s is wired as well. ESC protocols are basically the flight controller telling the ESC how fast they should drive the motors.
The FC has to communicate to the ESC’s at a much faster rate than the receiver has to communicate with the FC. That’s because apart from taking commands from the pilot, the flight controller is also constantly getting lots of data from various sensors such as gyro and accelerometer at a much faster rate (e.g. 2 to 8 thousand times per second), ESC protocol speed must keep up with the PID loop frequency for optimal performance.
Here is a list of the protocols for FC to ESC that you are likely to encounter in this hobby (this list is based off of what’s available in Betaflight FC firmware).
- PWM
- Oneshot (Oneshot42, Oneshot125)
- Multishot
- Proshot
- Dshot (Dshot150, Dshot300, Dshot600)
Note that DShot is a bi-directional protocol, not only the ESC gets commands from the FC, it also tells the FC how fast the motors are running (RPM), which is then used in RPM filter in Betaflight.
How to Choose the Right Protocol?
The choice of TX and RX protocols is pretty much determined/limited by your hardware, as most receiver only support certain TX and RX protocols.
If you are buying a pre-built drone, then you don’t have to worry about it at all. But if you are building from scratch, then your decision would affect what you should/can buy. Just pick a radio transmitter you like, and then find a compatible receiver, preferably support one of the serial protocols.
Take a look at what gear I use in this post.
Latency
We do not have the proper equipment to test TX and RX latency yet, but fortunately our friend Dronemesh on Youtube have been doing this type of testing for many different kind of TX and RX.
In a radio control system, the latency happens in multiple places. There is latency between your sticks and the RF module on the TX (before it’s transmitted through the air), between transmitter and receiver (signal travels at speed of light so almost negligible), and also there is latency between the receiver and your flight controller.
This is the testing result captured from one of the testing video:
- Flysky i6X – 13.7ms
- Turnigy Evolution – 14.6ms
- Crossfire (on X10) – 19.5ms
- Frsky Horus X10 – 31.5ms
- Frsky QX7 – 36.3ms
- Spektrum DX6i – 41.5ms
Of course, lower latency is better, but I don’t think that’s all the reason in choosing a radio. You should also consider the reliability of the RC connection, the features of the radio and ergonomics. But really, can 15ms extra latency affect someone’s flying? Maybe, maybe not.
And there is speculation that the latency of the Flysky system actually increases with range while that of Frsky is more consistent. Hopefully someone will test and confirm.
Edit History
- March 2015 – Article created for RX protocols
- July 2017 – expanded list of TX protocols
- Feb 2018 – added section about latency
- Apr 2021 – updated article
- Feb 2023 – revised
beginnersradioreceiver
