Introduction

When getting started with RC, quadcopters, and the building process, one critical step that we must take is choosing an RC receiver. The RC receiver is a device that communicates between your RC Transmitter (i.e. Taranis) and your flight controller (i.e. Naze32). There are a surprisingly large number of options available for receivers, and many of them work with different communications protocols. Three of the most popular are PWM, PPM, and S.BUS. These are all very commonly used within the FrSky ecosystem, for example, as well as in many others. So, to help you make the best decision about the RC receiver that you’re going to pick in your upcoming build, we’re going to break down the different aspects of each protocol.

PWM

PWM or Pulse-width-modulation is the “original” analog signal interface that’s been used in RC communications since the beginning. PWM uses separate cables and ports for each channel, so when you hook the receiver up to your flight controller, you have to run one cable for each channel. In addition, of the signal protocols mentioned in this article, PWM is the only one that will work directly with servos/ESCs. As a result, it’s often the most popular choice for those that want to fly a fixed wing aircraft that might not necessarily have a flight controller — the flight controller has to interpret the PPM or S.BUS signal to be able to convert the RC signal input into information useable by the electronics on the aircraft.

Pulse-width-modulation is a process by which signals are sent down the signal line from the receiver to the device that to which communication is needed. The signal forms “pulses” by sending precicely separated bursts of signal, the distance between which will give different commands to the servos or speed controllers. With a servo, the separation of the signal will determine the angle that the servo is supposed to have, and for a speed controller, it tells it the speed at which it’s supposed to spin the motor. When you look at your radio or in the cleanflight configurator and see values ranging between 1000 and 2000 microseconds; these are the values of the pulses that are sent out through the radio frequency, and interpreted by the software on the machine.

Here is a technical explanation of pulse-width modulation and how it can work for RC equipment.

PPM/CPPM

PPM stands for “pulse position modulation” which hints towards the way that it works. Unlike with PWM, which requires one signal line per channel, PPM only requires one signal cable overall. Thus, rather than sending signals from receiver to flight controller back to back, it actually iterates through all channels one after another. The flight controller then reads each of the signals in sequence, and then reads the pulse width of each channel, setting that as the value for the channel.

Thus, PPM is also still an analog signal, but transmitted in a nearly digital way. That is, the receiver and the flight controller each have to know how many channels to expect, so they know how to read the analog signal.

One downside of analog signals like PPM and PWM is that the signal is potentially “lossy.” Occasionally in transmission, data can be false or erroneous due to thousands of potential interferences. When this happens in an analog signal, there’s zero way for the flight controller to know that a particular value has error. As a result, the flight controller is responsible for executing what is called a “3 frame rolling average.” Essentially, what this provides is a “smoothing” factor over values given from the receiver such that any erroneous values don’t affect performance of the machine is extremely adverse ways (i.e. temporarily cut throttle, or turn one motor all the way up for a split second).

So, despite the cleanliness that one wire PPM signal provides, there is also the potential for error in analog signals. With analog signals, latency between the receiver and the flight controller ends up somewhere in the 18-27ms time — depending on firmware. However, because of the 3 frame rolling average, we have to triple the communication time, because your input isn’t going to matter until 3 “frames” later. Frames, being the time that it takes the flight controller to read the values of all channels being passed from the receiver.

Even with the 3 frame smoothing, sometimes PPM values can be a little “jittery” when there is a signal issue, so betaflight and cleanflight added the ability to turn on a feature called RC smoothing, which will do another process on the values to continue to clean out potential error. However, this also adds about 20ms of delay, all of which can eventually add up to 100ms depending on specific circumstances. While this doesn’t seem like a particularly huge amount, it’s important to remember that all delay in a control system is additive, so introducing any unnecessary delay further reduces the amount of time that the pilot has to correct a mistake or change course, even if it seems like an imperceptible amount.

S.BUS

The final communication protocol that we are going to talk about is S.BUS. S.BUS is a Serial Bus communication, and takes advantage of the UART communication ports that are available on flight controllers. Unlike PWM and PPM, S.BUS is the only mentioned communication protocol that uses a purely digital signal instead of analog. This means that, instead of sending analog signals, it’s actually sending detailed information from receiver to flight controller, rather than different variances of electric power. As such, it’s possible to send a lot more information across a single wire because the frame size stays small. Because of this, S.BUS receivers will support up to 16 channels across one wire that runs between the receiver and the flight controller. For users that fly FrSky with the Taranis, you’ll be able to take advantage of all 16 channels, if that’s useful to you.

S.BUS uses the UART communication ports to send the one-way SBUS signal from the receiver to the flight controller. UART traditionally has 5v, gnd, rx and tx, but S.BUS only requires the ability to send the signal from the receiver to the flight controller, so many flight controllers now are creating a dedicated UART port that only has input, simplifying the connection process for the user hooking up the receivers.

As a result of this, like with PPM, S.BUS requires only one cable running from the receiver to the flight controller, and across this all channels will be transported.

Because S.BUS uses a serial communication protocol, the communication between the receiver and flight controller is up to three times faster than the analog signal with PWM/PPM. In addition, because of a digital signal, we have the ability to take advantage of what are called “checksums.” These are clever little pieces of information that are sent along with each message to the receiver that tell it whether or not the value received had an error state. The analog signals from PPM have to be accepted by the flight controller because there is no possibility for checksum with analog signals. As a result, the SBUS connection doesn’t require a 3 frame average, bringing its response time down to around 9ms, while PPM stays in the 50+ range. In in addition, RC Smoothing is not required because there is little to no error.

All that to say, S.BUS tends to have the best performance out of all of the protocols, and tends to be the most flexible.

Conclusion: Which Protocol Should I use?

Unsurprisingly, there really isn’t a right answer. So, we’ll give a few different use-cases where each is particularly effective. PWM tends to be the simplest to set up, since it doesn’t require a flight controller to communicate with individual electronics. Thus, you can plug a speed controller or servo directly into the receiver and it will “just work.” This works particularly well when you’re flying a fixed wing aircraft, where you might not want to have a flight controller on board. Next, PPM, despite that it’s a bit slower, is still very fast and a very reliable RC connection. We wouldn’t choose it for racing quads, but for larger photography rigs or fixed wings, it works perfectly well, and the delay is almost unnoticeable. Finally, S.BUS, because of it’s response time and speed, tends to suit racing quads the best, where every inch and every split second counts.

We hope this helps clarify the differences and advantages of each protocol! Keep flying!