When talking about radio receiver (RX) and transmitter (TX) protocols, you will surely encounter some confusing acronyms like PWM, CRSF, SBUS, DSMX, FPort etc. In this guide, I will explain all the common RC protocols and the differences between them.
What are RC Protocols?
An RC protocol is like a language spoken between components. They are used in radio communication in our FPV drones, RC planes/wings and other radio controlled vehicles. It’s important that you buy things that are compatible and speak the same language, or they just won’t work.
RC protocols can be divided into two groups:
- RX Protocols – communication between the radio receiver (RX) and flight controller (FC)
- TX Protocols – communication between the radio transmitter (TX) and RX
Some manufacturers might share some TX and RX protocols, but most of the times they use their own protocols.
Communication between the radio transmitter and receiver is wireless. Manufacturers all have their own TX protocols, some brands even offer multiple protocols depends on hardware. 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.
- 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.
The communication between radio receiver and flight controller is wired. 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 (TBS Crossfire)
- SPEKTRUM1024 (Spektrum DSM2)
- SPEKTRUM2048 (Spektrum DSMX)
- FPort (Frsky)
- SPI_RX (universal) – More detail in this article
PWM – Pulse Width Modulation
PWM stands for pulse width modulation, 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.
This is the most common and basic 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.
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 wire, and modulated differently.
The advantage of PPM over PWM is that only one single wire is needed for several channels. 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).
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).
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 is developed by TBS for their Crossfire RC system. It’s similar to SBUS or other digital RX to FC protocols.
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 – By Flysky
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 – By JR
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 (Multiwii Serial Protocol)
Protocol that 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 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.
How to Choose the Right RC Protocols?
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.
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.
- March 2015 – Article created for RX protocols
- July 2017 – expanded list of TX protocols
- Feb 2018 – added section about latency
- Apr 2021 – updated article