What are RC Protocols?

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 – 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).

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 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

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.

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.

相关文章