How to Improve Radio Control Latency for FPV Drones

Minimizing the radio control latency can improve flight performance of the FPV drone, as well as giving the pilot more confidence and faster response. In this post I will explain how to reduce RC link latency as well as the considerations.

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.

This article is written by Daniel Appel, Edited by Oscar Liang. Still looking for the latest and greatest radio on the market? Check out this radio transmitter buyer’s guide.

Why Worry About RC Latency

While latency itself is not inherently problematic in making a multicopter respond to flight inputs, depending on flight discipline the importance of control link latency can vary. Some pilots can be more sensitive to the control link latency than others, and racing tends to value minimum latency more than smooth freestyle or long range flight uses.

Often moving to a lower latency system doesn’t provide immediate and obvious flight performance improvements, other than sometimes feeling a bit more confident for some ‘close call’ situations. But reverting to a higher latency system can often be more noticeable for the pilot, result in feeling as though the craft is clumsy and typically results in significant overshoot on pilot inputs as the craft responds less quickly than expected.

The other key effect is the RC signal frame rate. The radio control information is grouped into frames, and the flight controller has fixed calculation cycles (PID Looptime). The timing of these frames plays a significant role in overall latency for the whole flight control system.

In this article, I will first explain how you can improve latency in some of the most popular radio control systems used in FPV drones. Later I will explain other considerations and what could affect radio control latency in a bit more detail.

How to Reduce RC Latency

TBS Crossfire

Technically the smallest improvement possible is with the TBS Crossfire system because it already performs pretty good out of the box. However for racing where every latency improvement counts.

For a start, moving to CRSFShot (a new protocol for Crossfire) and have the refresh rate locked at 150Hz is the hot ticket:

• Update radio firmware to the latest OpenTX (OpenTX 2.4 or newer), this enables the new CRSFShot protocol to be used (how to update OpenTX)
• Update the transmitter module firmware to a CRSFShot capable version. Download the latest TBS Agent, connect the transmitter module, and update that firmware to Version 3.25 or later. This now enables CRSFShot from the transmitter
• Allow the transmitter module to OTAR (Over-The-Air-Reflash) the receivers. This enables the CRSFShot radio link to be used
• Finally, in the Crossfire configuration (.lua), change the radio transmission protocol to CRSFShot (not enabled by default), and set the rate to 150Hz locked.
• From there you’ve done it

And there are still benefits to reducing the number of channels transmitted (e.g. using 8 channels rather than 12). If you are on Betaflight 4.1.3 or later, you no longer need to transmit the LQ or RSSI values on an actual data channel.

No further changes are required, although you can now be more aggressive with RC smoothing. For example in Betaflight4.2, I have found that RC_Smoothness on Auto, set to 8 provides more than adequate smoothness, but extremely good latency performance. On long range setups, I will run values of 20, as my mountain-surfing rigs aren’t as latency-driven, and the very smooth response is actually a means of smoothing out my stick inputs. Values up to 40 can still be used, particularly on cinewhoops. Play with this value and see what works best for you.

Frsky Taranis with XM+

The Taranis radio and XM+ receiver has a somewhat variable 22-37ms latency (measured on stock OpenTX2.2 and stock XM+ firmware). There are three steps required to reduce latency.

• Update the radio firmware to the latest OpenTX (2.3.3 or later). This fixes the “unsync heartbeat” bug in with XJT and OpenTX, eliminating up to 9ms of latency (how to update OpenTX)
• reflash XM+ receiver firmware. I recommend the ACCST Pre-2.0 (1.X RSSI .frk files), as there are bugs present in some of the newer FrSky provided versions. This adds the ability to display RSSI in the OSD
• Change the D16 protocol to operate on CH1-8 (using 8 channels only). To do this, go into the radio menu, select the model, press page once, and scroll to the bottom of the screen. On the ‘channel selection’ menu, select the ‘16’ value in Ch1-16, and go left until that value is 8 (or less – there is no latency benefit to going below 8). This stops the transmitter from transmitting Ch9-16 data every other frame, effectively doubling the rate at which R/P/Y/T data is sent. As needed, rearrange the Aux channels on the transmitter and FC configuration to retain the same functions

Finally, you can adjust the RC Smoothing in flight control firmware, though stock is a great compromise. For racing, values of 8-12 work best for me, practically I’m content to run defaults for Betaflight 4.2. I run the XM+ as the primary option for racing rigs, though if you use these for freestyle, values from 20-40 all work well cinewhoops are quite happy at 40).

Frsky Taranis with R-XSR

The most significant improvement possible is with XSR and R-XSR receivers for reducing latency and making the latency more consistent. This will involve the most steps, but achieve the most, as going from a variable 25-47ms latency 16Ch setup to a consistent 13-17ms setup while simplifying the wiring and telemetry is a great improvement.

• Update the radio firmware to the latest OpenTX (2.3.3 or later). This fixes the “unsync heartbeat” bug in with XJT and OpenTX, eliminating up to 9ms of latency (how to update OpenTX)
• Second, update receiver firmware to the one that support F.Port. I recommend the ACCST Pre-2.0 (1.X F.Port .frk files), as there are bugs present in some of the newer FrSky provided versions
• Third, use FPort instead of SBus, which is a faster protocol
• Fourth, Change the D16 protocol to operate on CH1-8. To do this, go into “Model Settings”, scroll to the bottom of the screen. On the ‘channel selection’ menu, select the ‘16’ value in Ch1-16, and change it to CH1-8. This stops the transmitter from transmitting Ch9-16 data every other frame, effectively doubling the frame rate

Finally, you can adjust the RC Smoothing in flight control firmware, though stock is a great compromise. For racing, values of 10-15 work best for me, practically I’m content to run defaults for Betaflight 4.2 (10). For freestyle flying, I have found that 20 is an excellent value. Values up to 40 can still be used, particularly on cinewhoops.

FrSky R9M – Counterexample

I have included somewhat of an example with the FrSky R9 system, as there are ways of reducing latency. Yet the most functional setup for improving overall RC-FPV combined useful latency actually involves accepting some tradeoffs that don’t providing minimal latency, but improve the effective response latency maximally.

The same updates to the XSR and R-XSR can benefit the R9M system. F.Port is still the faster (and easier connection) configuration for this hardware. The same XJT fixes are also tremendously beneficial.

• Update the radio firmware to the latest OpenTX (2.3.3 or later). This fixes the “unsync heartbeat” bug in with XJT and OpenTX, eliminating up to 9ms of latency (how to update OpenTX)
• Second, update receiver firmware to the one that support F.Port. I recommend the ACCST Pre-2.0 (1.X F.Port .frk files), as there are bugs present in some of the newer FrSky provided versions
• Third, use FPort instead of SBus, which is a faster protocol
• Go into “Model Settings”, scroll to the bottom of the screen. On the ‘channel selection’ menu, change “Ch1-16” to “CH1-8”. This stops the transmitter from transmitting Ch9-16 data every other frame, effectively doubling the frame rate

Here is where there exists a counterexample where we no longer configure the RC Smoothing (and FeedForward Interpolation or D-Term_Setpoint_Weights) to maximize response, but instead of smooth signals for inputs to the PID controller. Mark Spatz has an excellent video on just this: https://www.youtube.com/watch?v=6WL8FEWNB2g

For Betaflight 4.2, the solution is to use the new FF_interpolate = 4 functionality, which uses an interpolation of the last 4 data points, and leverage the RC_Smoothing with values of 30-50 to further filter this data.

While adding filtering delay may sound unpalatable, in practice the motor heat that can result from having those large variable stair-stepped setpoint datapoints injected into the PID loop results in having to detune PID (PID/Dmin/FF) gains resulting in less rapid response to inputs, therefore slightly over-filtering the RC commands (which adds about 4-8ms of effective latency) but allowing larger FeedFoward values, P&D Gains, and reduced filtering (particularly on D-Term for lowpass filters) results in overall faster craft response (typically going from 12-15ms to setpoint step responses down to 6-9ms to setpoint step responses) results in actually better response, cooler motors, and most of all the response of the craft is more consistent (As some of the variability in latency cannot be completely removed).

The mathematicians among you will realize this isn’t a net improvement on latency, however, there are more important aspects of the overall flight experience, and consistency of copter response matters a lot more, particularly on larger and long-range intended craft that benefit most from the R9 system. If it sounds like I’m being needlessly hard on the R9 system, I will own up to having moved away from the entire FrSky radio infrastructure to Crossfire for my more expensive 7” long range quads after experiencing some crashes due to radio link… but the good news is that the above F.Port and XJT fixes will result in actually lower overall latency on the R9 system from stock, and these extra smoothing inputs will result in a better flying quad, and to some extent some additional artificial smoothing of stick inputs.

What is Radio Control Link Latency?

Radio control link latency is the delay between the radio system decoding stick positions and the copter receiving setpoint (stick position) data that can be used by a flight controller for determining what outputs to next send to the ESCs and motors to cause the craft to respond to the remote control inputs. There are some additional latency effects involved in flight controller calculation from filtered gyro data, which must be touched upon briefly, but for the most part this article will focus on ways of minimizing the delay between the controller gimbals and the flight controller without significant negative effects.

Author: Daniel “Tehllama” Appel
I’ve been an avid FPV Pilot for the last three years, with a background in signal processing, RF communication systems development, carbon electrode electrochemistry research, high performance computing research, and aerospace manufacturing.