The relevance of certain aspects of your RC system’s performance is without a doubt a heavily debated topic. So what if my system’s latency isn’t up there with the best of them. Am I going to notice it? Do I really need 2048-step resolution when I’m almost certain that my servos aren’t capable of tracking changes that small? Do these questions ring a bell? Then perhaps I can shed a little light on the subject.
WHAT ARE THE KEY PERFORMANCE ATTRIBUTES?
I’d like to begin by establishing some context to this discussion. There are many factors that contribute to system performance. But this discussion is going to address the two mentioned in the introduction – ‘Latency’ and ‘Resolution’. In simple terms these are how quickly a system will propagate your commands to the model and how precisely it can represent those commands.
Other performance attributes such as how well a system maintains its RF link or how comprehensive the programming suite is are also important. I will, however, defer those topics for another day.
Every radio system introduces some delay (or ‘Latency’) between user input and the reflection of that input in the channel position commands output by the receiver. The characteristics of this latency can have a dramatic effect on the overall ‘feel’ of the pilot/model connection.
To put latency into perspective, if one were to assume that 200 mSec (or 1/5 of a second) is a typical eye-hand reaction time; then a radio system with relatively high latency could account for up to 30 percent of the total hand-eye-servo reaction time. Alternatively, a radio system with a relatively low latency can reduce its contribution to the total hand-eye-servo reaction time to below 10 percent.
To the user, a radio system with low latency results in a model that feels ‘connected’, while the same model flown using a system with high latency tends to feel ‘mushy’ in comparison. Users who switch from a higher to a lower latency system oft en comment on how much more alive, precise, and responsive the model feels when in fact nothing else in the model was changed other than the receiver.
WHAT CONTRIBUTES TO LATENCY?
Here’s what happens when you move a transmitter control. The system must first sample the position of all its controls; sticks, switches, knobs, etc. It then converts those positions into a digital number and processes those numbers; applying all the programming feature algorithms in use. With the final channel output positions calculated, the positions are then encoded onto an RF carrier for transmission to the receiver. The receiver must decode these positions, convert them to PWM signals, and send them out to their corresponding channel output ports.
How oft en the transmitter’s controls are sampled, the internal processing speed, firmware efficiency, number of channels, frame rate, and RF propagation delay all contribute to a system’s overall latency.
HOW IS LATENCY MEASURED?
To measure latency, a test fixture attaches to an input control in the transmitter and monitors the corresponding channel’s output port on the receiver. The test fixture programmatically injects control position changes into the TX, effectively simulating movement of the control.
Precision timers that have accuracy in the nanosecond (billionths of a second) range measure the elapsed time between when the signal is injected and the detection of a channel position change at the receiver.
The test is repeated thousands of times, yielding ‘minimum’, ‘average’, and ‘maximum’ latency measurements. Furthermore, the tests are performed using a helicopter model type with a programmed swash type of 120° eCCPM, as this represents one of the more taxing transmitter configurations with respect to internal processing delays.
HOW DOES LATENCY AFFECT THE WAY YOU FLY?
Average latency will determine how connected you feel with your model, as it’s the ‘usual’ elapsed time between your input and the model’s response to that input. But just as (if not more) important is the spread (or difference) between the minimum and maximum latency measurements.
You see, the human mind is amazingly adept at compensating for consistent delays and will very effectively (almost unconsciously) make predictions based on that delay. However, it doesn’t do nearly as well when latency is inconsistent – something a pitcher will commonly use to his advantage when trying to strike out a batter.
A system’s ‘Resolution’ will determine the number of discrete output positions that it is capable of specifying at the receiver’s channel outputs. Put another way, it defines how ‘fine’ the system’s positioning capability is.
Resolution is expressed in one of two ways:
• Number of steps (e.g. 1024-step, 2048-stop, etc.)
• Number of bits (e.g. 10 bits, 11 bits, etc.)
To convert bits to steps, simply raise 2 to the x power; where x is the number of bits. In a 10-bit system for example, 2 raised to the 10th power equals 1024. 10-bit resolution and 1024-step resolution are equivalent.
At the receiver’s output, position is specified using a ‘Pulse Width Modulated’ (or PWM) signal. This is basically a steady stream of variable width pulses; with the width of the pulse used to indicate the desired position. A typical R/C system uses pulses in the order of 900 mSec – 2100 mSec in width; a range of approximately 1200 mSec. If you take that range and divide it by the system’s resolution, you can effectively calculate the system’s incremental positioning capability.
Here are some examples:
• 7-bit / 128-step = 9.4 mSec / step
• 8-bit / 256-step = 4.7 mSec / step
• 9-bit / 512-step = 2.3 mSec / step
• 10-bit / 1024-step = 1.2 mSec / step
• 11-bit / 2048-step = 0.6 mSec / step
As you can see, higher resolution systems have finer positioning capability. But is finer necessarily better? Well that depends. Consider an average servo that has a deadband of 5 mSec and an end-to-end rotation of 120°. If it cannot respond to changes smaller than 5 mSec, it will NOT benefit from system resolutions greater than 8-bit / 256-step – as it maxes out at a little less than 0.5° of rotation per step. However, servos with a smaller deadband will benefi t. A servo with a deadband of 3 mSec for example can track just fine to systems using 9-bit / 512- step resolution.
But you must also consider that servos aren’t the only devices driven by a receiver’s channel output. Other peripherals such as Electronic Speed Controllers (ESCs), Gyros, Flybarless Controllers, Throttle Governors/ Limiters, etc. all contain internal processing that can take full advantage of higher resolutions. The bottom line here is that you need to know the operational characteristics of the devices being driven in order to determine whether or not you’ll benefit from higher resolutions.
THE FINAL WORD
We’ve gone through just two aspects of radio system performance. There’s more to cover but my hope is that you are now beginning to realize that there are many things to consider when selecting a system. With a plethora of systems to choose from, knowing what to look for makes the price/performance decision a much more educated one.
Edited for the web by Jon Hull