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.

End to End Latency in FPV and RC Systems

For context, there are four major sources of latency in an FPV-RC system, each with varying degrees of consistency and effect. These exist in a repetitive cycle, so to facilitate discussion we will follow the flow of information coming into the FPV system through the craft responding to pilot inputs and beginning a new cycle with updated inputs to the FPV system.

For this discussion, the first information is what the FPV camera receives as an image captured on the sensor, which is then processed in the camera and transmitted to the rest of the FPV system as an NTSC or PAL image. OSD chips on the camera, FC, or standalone can impart additional information onto this image, although the latency cost is negligible. This information is then routed to a video transmitter, which transmits this information via transmission in an ISM band to the video receiver on the ground connected to the pilot.

The order of magnitude for these total delays are in the range of 5-55ms, with the caveat that the actual PAL/NTSC framerates (50/60Hz for partial frames – the nominal framerate for these two systems are 25Hz for PAL and 30Hz for NTSC) end up grouping the total latency of the signals into discrete frames. Assuming that partial frames are the earliest usable information the pilot can receive, we can assume the higher framerate is useful – 50Hz (PAL) equates to 20ms, while NTSC achieves 16.7ms between frames at 60Hz.

In practice, this means that actual camera latency values as tested can be grouped into the number of PAL or NTSC frames ‘behind’ the overall camera processing has caused the image to be. Three frames of total delay (e.g. Version 1 RunCam Eagle cameras) can produce noticeable delay, while most popular racing cameras achieve 5-8ms of total delay which ends up resulting in only one frame of total throughput delay, and marginal performance difference between 5ms and 8ms compared to a camera that has 22ms delay.

Another potential source of latency exists in the video reception side, primarily if any processing is involved at the goggles that can result in latency. Fortunately, dedicated analog systems perform excellently in this regard, and DJI digital (as well as Connex digital) systems perform in the 23-33ms latency range, which amounts to a 2-frame delay at worst, but with improvements in ability to see with greater clarity when signal quality is high enough. Earlier versions of DJI goggles operating from analog inputs have experienced some additional latency, but firmware improvement have been made to mitigate these issues.

Ultimately, the total latency from the camera sensor (that receives information at the speed of light) to the light emitted by the pilot’s FPV screen ends up being between 1-5 PAL/NTSC frames, depending on hardware and video format selected. This range of 18-88ms covers a significant differential in responsiveness, although recent hardware brings this consistently below 50ms for all applications which is very adequate for fast-paced flying. There remain some inherent tradeoffs in latency versus resolution, as DJI digital video remains typically one NTSC frame ‘behind’ an analog camera, but the significant increase in the amount of data present in each frame and ability to see objects can allow for faster paced flying due to that extra information, with virtually any complaints from racers using DJI being related to cases where the video segment latency changes during flight.

The most variable segment for latency can be described as ‘that part between the goggles and the sticks’. In practice, pilot response to video inputs and precision in applying the correct gimbal inputs is the essence of why this is a hobby that requires skill, and practically the best way to improve this I have found is simply time spent on the sticks. Realistically, studies have shown a median human reaction time of 215ms to basic stimuli, but this can be described as an oversimplification of the act of piloting. There are numerous research articles related to these phenomenal, but they can be briefly summarized as an understanding of neuroscience where piloting FPV craft we are using visual stimuli to update our perception alongside expectations and spatial models we have created in oud minds. Since we are flying craft primarily on expectation of where we will be in roughly a tenth (or two) of a second, what matters is how fast something that deviates from expectations in our mind’s eye can be determined, and an appropriate response to achieve a corrective steering input can be applied (https://www.futurity.org/video-games-speed-up-reaction-time ). While quantifying this value is useful, in most cases the best way to improve the likelihood that the pilot can apply a timely corrective stick input involves reducing as much overall hardware latency as possible.

The last critical segment this article is here to discuss is the radio control link. Essentially measuring the gimbal positions, encoding and transmitting that information to the receiver onboard the craft, and relaying that information to the craft is the RC link. While both conventional and hall effect gimbals have very low latency to decode positional data, subsequent steps required to process these through a mixer on the transmitter, send this information to a radio module (internal or external) that then converts this data into (serial) data packets to be transmitted to the receiver which then receives those radio frames and transmits data to the craft. It is still possible to use PPM or PWM as radio communication protocols, however the latency on these systems is substantially greater than any modern serial protocol, so much so that I will refer you to this article and highly recommend going directly to serial data transmission: https://oscarliang.com/rc-protocols/.

The range of overall latency for the RC link is deceptively large, although not always for intuitive reasons. First, to clarify there is a Radio protocol that determines how the transmitter sends data to the receiver, and a Communication protocol used to send information to/from the radio components. Often these pairings are synonymous, some more flexible hardware actually enables mixing & matching of radio and serial protocols. FlySky uses AFHDS-2A with IBUS for fast data. FrSky D8/D16 are most frequently used with SBUS (an inverted signal serial protocol), but can also be used with F.Port. TBS Crossfire can use standard Crossfire radio link, or improved CRSF-Shot, but provides the option between CRSF Serial protocol, or SBUS (to include non-inverted SBUS). The specific frame rates of the radio protocols dictate how fast the information reaches the receiver, though practically serial protocols from the receiver to flight controller are fast enough to not be a major concern. Where these radio protocol framerates matter more is at the transmitter.

There are frame locking effects that exist, as transmitter have specified ‘heartbeat’ signal rates at which channel data is passed to radio modules, and de-syncing these heartbeat frequencies can result in cases where total latency is based on the sum of those two update intervals. There are specific frame rates for the various serial communication protocols, which can vary by the total number of channels utilized – more on that later, as this is a key method of reducing latency from default RC systems.

For the final step in the overall latency picture, the setpoint data must then be processed by the flight controller in such a way that the D-term of a PID controller is not over-reacting to large setpoint changes that appear to have arbitrarily high slopes of lines (Derivative calculations respond to slope/rate-of-change for setpoint & error calculations), and noisy or inconsistent setpoint data requires additional filtering to be performed that adds effective latency, or accepting extremely large motor command spikes that result in hot motors and poor performance.

There remains some hardware and software latency present in how quickly a craft responds to filtered setpoint and gyro inputs to achieve new motor mixer commands, followed by how rapidly a multicopter can achieve a rotational result from motor mixer commands. However, these latency areas exist in the regime of 2-5ms from detection of a setpoint change to calculation of PID error from filtered gyroscope data (keep in mind, KISS operates on one PID calculation every 1ms, with Betaflight running 2-8x as fast (F3 on Betaflight Performance Edition 4.X needs 2kHz PID loops from 4kHz sampling, F411 on BF4.X can run 4kHz PID loops from 8kHz sampling, and BF4.2 allows F7/F405 to run synced 8k/8kHz PID Loop and gyro sampling), and FL1 achieving even lower looptimes (32kHz gyro sampling, 16kHz PID loops). More important than flight controller looptimes, there are also immutable delays from the mathematics of filtering required to remove noise from signals, for example attenuating a 200Hz sinusoidal oscillation will always carry a 2.5ms delay because of the math. For motors to spin up or down enough to achieve an actual thrust/torque differential, it will often take 1-3ms to fully achieve. Practically, the reason these are so fast is to allow multicopters to react to uncommanded movements, such as propwash, rather than reacting to radio control inputs. From the perspective of control and FPV latency, these operate at much lower timescales compared to video frames and RC control link frames. Even the best RC link still operates at a higher net latency than the slowest underpowered multirotor can react to a signal.

Therefore, we can conclude that the FPV systems allow only limited means of minimizing latency, onboard flight controllers are inherently very fast at reacting to setpoint commands, and that human response can be best improved through more flight. Carefully selecting FPV components for latency works well (for Analog, running low latency cameras in NTSC mode with good analog goggles is best, although PAL systems suffer only minor performance degradation for slightly improved color resolution – DJI systems can use focus mode to keep overall latency low). This leaves the radio control link as the largest area where significant improvements can be made, and depending on hardware selected these can be the single largest contributor to reducible latency.

What radio latency is achievable

The serial radio protocols can have frame rates as low as 6.67ms (CRSF-Shot), but also be as high as 47ms (FrSky ACCST on OpenTX pre-XJT fix). This can be made worse by instances where a radio protocol uses a certain frame intervals to transmit no new information on the R/P/Y/T channels. Upcoming LoRa based systems can achieve frame rates as low as 4.5ms (IRC Ghost).
There are additional delays resulting from heartbeat updates at the transmitter side, as alluded to above there have previously been bugs present in the heartbeat sync of OpenTX on FrSky XJT hardware that has resulted in higher latency due to different sync, resulting in up to 9ms of extra latency for SBUS and FPort over ACCST protocols. (Link – https://github.com/opentx/opentx/issues/4640).

Most other radio control protocols fall in between these areas for latency. FlySky AFHDS-2A with IBUS sits at 13.7-16.3ms and is very consistent, provided the receiver is functioning correctly. Spektrum radios in DSMX are a locked 11/22ms of latency depending on channel numbers, while SRXL/SRXL2 appears to have consistent 11ms latency. Futaba is somewhat of an outlier among 2.4GHz radio systems, with a claimed 7.9ms latency on FASSTest-10+2Ch, and ~11ms in SHFSS which in practice this is among the better control links, with the downside that Futaba radio hardware trends towards more expensive options. The good news is that multiprotocol modules (Jumper/Radiomaster T-16/TX16S, IRX4, etc.) actually have the capability to run SHFSS protocols. Finally, TBS Crossfire in default dynamic 50/150Hz mode ends up with an average latency around 14ms, but in high link quality areas this can be as low as 8ms in my experience. At longer range, these average values tend to exceed 20ms, though flying beyond a mile latency is not as critical. CRSF-Shot locks the transmitter to 150Hz mode, locking the frame rate to 6.7ms, though the practical end-to-end latency on most OpenTX systems adds in a similar amount of latency from stick movements but this is ultimately trivial and present in all radio systems.

Upcoming LoRa based systems have similar capabilities of remaining in locked low-latency operation, and can also dynamically reduce framerate which enables larger spreading factors which can significantly improve range by reducing symbol errors. The IRC Ghost system can utilize 222Hz (4.5ms), 160Hz (6.7ms), 62Hz (16.1ms), and 15Hz (66ms) framerates with matching spreading factors that significantly improve the range potential at these lower framerates. In less technical terms, the wider spreading factor enables processing gain increases of 3dB (doubling power), however at the cost of longer chirps that require lower frame rates. Real-world testing with actual OpenTX radios will inform actual end-to-end latency calculations, but as discussed these are only part of the picture.

So how do we minimize latency

There are three primary steps to take in order to reduce latency on the Radio Control link. The first is minimizing any delays (and particularly inconsistency) with aligning the gimbal data to transmitter module information, which requires reflashing radio firmware. The second is limiting the number of channels the transmitter is transmitting data on, primarily reducing Aux channels used and then forcing the transmitter to only transmit those channels. Updating transmitting modules, in the case of TBS Crossfire, can enable new radio transmission protocols (specifically CRSFShot) that can enable new lower latency modes. Reflashing receiver firmware can also achieve lower overall latency – in the case of XSR/R-XSR systems, the FrSKy F.Port firmware actually achieves slightly lower latency, and also enables a single-wire RC/Telemetry solution that is easier to wire into most flight controllers that can easily accept SmartPort connections for telemetry. Finally, making adjustments to how flight controllers manage new setpoint data to improve the RC smoothing calculations for both latency and smoothness can also aid in reducing effective latency of the overall RC-FPV system.

As far as updating radio firmware to account for fixes to heartbeat, this fix is arguably the most significant for most users. This is particularly notable in OpenTX pre-2.3 versions where XJT modules have hearbeat sync issues, but is also an improvement made in CRSFShot capable builds of OpenTX. The branched variants of OpenTX (JumperTX, FreedomTX, etc.) may not contain these fixes, however OpenTX 2.3.3 contains targets for the latest Jumper T16, and FreedomTX for the Tango2 has CRSFShot capability (and no provisions for running XJT modules).

The short answer is that if you fly CRSF, updating to be able to run CRSFShot is absolutely worthwhile, even if you don’t have it enabled for every flight. If you fly FrSky receivers, it is absolutely worth the hassle of upgrading OpenTX versions to get the XJT heartbeat fix, as this applies to all D16/D8/LR12 systems and is a marked improvement in both total latency, and consistency of this latency.

What else requires consideration?

Another key element of understanding why there are limits to lower latency is that the ultimate goal of this information is to provide a craft with accurate information about the desired stick positions. Each time a new radio receiver frame provides information to a flight controller, the flight controller must either perform some additional smoothing operations to this stair-stepped data, or find other ways to account for the seemingly infinite rate of change (arbitrarily derivative value) that occurs at that point. For flight controller systems that use PID with Feed-Forward (or even D-Term Setpoint enhancement that calculates D-term from setpoint), these rapid changes in setpoint can create large amounts of PID loop response resulting in very stair-stepped error, which typically results in oscillations in motor commands and end result being less smooth moves and extra motor heat. These FF/D-Term-Setpoint-Weight features are excellent for improving setpoint tracking, but more smoothed setpoint values being fed to the PID controller can result in better setpoint tracking despite a small amount of delay from interpolation of FF commands and RC filtering caused by the math of reducing the stair-stepped nature of the signal.

There are significant benefits to limiting the number of Aux Channels used. While Betaflight has the capability to operate with more Auxiliary channels, the information in these Aux channels is not as critical as the actual Roll/Pitch/Yaw/Throttle data that is needed in flight, and most radio systems are set up to transmit entire frames of Aux channels if more than a certain number are used. Some common systems have very obvious breakpoints – for example FrSky D16 on 8 channels is twice as fast as D16 using 9-16 channels, for both SBUS and F.Port. Helpfully, there are ways to fit virtually every necessary function into 5-8 channels.

This excellent resource from Joshua Bardwell on how to ‘channel stack’ is a great initial guide for how to reduce the number of auxiliary channels used if you have more than a few basic functions. Practically it isn’t necessary to install every function onto a single channel, but this overall technique can be used to use fewer Aux channels if you have functions that do not have to be concurrently operated. Link – https://www.youtube.com/watch?v=Ut7Hpmmy_Us
I personally run three primary Aux channels on all my race/freestyle/cruising/long-range quads, most of which are set up for team racing with some overlapping functions, and that make use of RSSI Channels on Aux4 or LED Color commands if RSSI is transmitted over Aux12 or CRSF LQ data. The channel selection is based on what overlapping is possible – for example I only want Blackbox Logging while Armed, always want video while in Turtle Mode, but don’t need to simultaneously engage the Dshot ‘Beep’ function and Prearm the quad. Obviously, I am somebody who very strongly recommends running Prearm capability on non-whoop quadcopters, a preference learned from experience and pain.

Aux1 for Arming, Launch Mode, and Blackbox mixed from two switches as a pot.
Aux2 is used for Prearm, Buzzer/Beeper, and for GPS models Level mode & GPS-RTH (Failsafe emulation)
Aux3 is my utility channel, used for Turtle/Crash-Flip mode, VTX Pit Switch, and Paralyze (for team racing
Aux4 is for loop-back RSSI on XSR/R-XSR (https://youtu.be/t-evOAS9Mkg?t=83), or used for LED RGB.
Aux12 is where XM+ RSSI-16.frk outputs RSSI information, just requires reflashing firmware (with thanks to the late great ProjectBlueFalcon – https://www.youtube.com/watch?v=q-rOd4_DSIk). This data is NOT sent by the transmitter, but instead is generated by the receiver, hence why no additional latency is required. If you have multiple quads, some on XM+ and others on XSR/R-XSR, there is a RSSI-8.frk version that moves this RSSI channel to Aux4, which is helpful if you want to share CLI images.

Finally, there are some Radio Transmitter configuration options that can help significantly with both latency and signal cleanliness. For Taranis radios, one of the most important changes is disabling the ADC Filter – short answer is that you want to do this for multirotor setups on a Taranis, always: https://www.youtube.com/watch?v=ESr2H_EZ89Q. Setting up gimbals, and moving to Hall effect gimbals can also result in smoother signals, that will allow you to reduce the required RC filtering, as these gimbals have overall lower noise thresholds in practice, though again this is not a necessary cost.

Upcoming LoRa Systems (ImmersionRC Ghost)

There are likely to be numerous new radio control link systems based on the LoRa PHY layer, which is parter of the broader LoRaWAN Internet of Things ecosystem to enable cheap devices to communicate over ISM bands. In practical terms, for RC applications we are taking the existing LoRa physical layer and turning the framerate knobs up as high as possible to achieve minimum latency given the desired signal to noise ratio (SNR) that allows these ‘chirp spread spectrum’ devices to operate at or below noise floor levels while still accurately decoding frame data. The reason LoRa is unique has to do with the dynamic center frequency, where each ‘chirp’ moves across a narrow range of center frequencies, but takes advantage of dFFT algorithms to reassemble this data quickly, and this allows for much simpler, lighter, and cheaper radio hardware to accurately meet frequency precision requirements to transmit data.

The LoRa implementations for RC applications will primarily vary by the arrangements of data stacks, packaging factors, and the dynamic selection of spreading factors. These are still spread spectrum physical layer radio links, where the actual data is mixed with a higher data rate spreading code that causes the data bursts to appear like higher bandwidth/lower amplitude noise to adjacent stations, and provided these spreading codes are relatively orthogonal, allows multiple users to operate very close to the noise floor with reliable signal reception. There is processing gain in reconstituting these spread spectrum signals once received, and the amount of processing gain increases depending on the spreading factor, i.e. how much slower the payload data is relative to the spreading code. Within a defined bandwidth, the spreading code and spreading factor determine the actual data throughput, and helpfully RC command signals do not need to send large amounts of data per frame, allowing a LoRa implementation to maximize framerate on the RC channels.

For RC applications, these LoRa systems are configured to operate at the maximum bitrate, updating RC data positions as frequently as possible to achieve lowest possible latency levels. Once set to maximum bitrate within the bandwidth constraints of existing ISM bands, LoRa RC systems effectively only alter the spreading factor and frame rate in order to maintain reliable signals. Changing spreading factor to have a more reliable signal results in progressively lower framerate, but allows for significantly more range than RC systems we are familiar with in those same bands. https://hal.archives-ouvertes.fr/hal-01977497/document

FlySky claims 20km capability with their 2.4GHz LoRa system operating at 1W, IRC claims a much more reasonable 4-8km usable range with a 350mW system that can operate on supplied JR Module power. In practical terms, for most mid-range pilots this hardware should be capable of those claimed values, with the caveat that properly implemented LoRa systems will change to a much lower framerate in order to maintain link quality.

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.