Radio Signal Latency

Transmitter-to-Receiver latency is a much-cited metric when discussing radio systems.

Andy Kunz, a member of the Spektrum development team, wrote a couple of posts going into great detail about how latency is measured and what it means.  Because RCG posts get hard to search, I'm capturing them here for posterity.

I've moderately edited from these posts and a couple in between (quoting people asking questions).

Thanks Andy!



-----

Keep in mind, my answer is only for genuine Spektrum products. There are differences in how things are implemented by Lemon, and somebody else will have to answer those.

Published latency is the time between when an event happens on the transmitter until that event is sent to the servo. Servo latency is a whole 'nuther matter, so the standard is to measure the time from, say, when you flip a switch until the end of the pulse to the servo showing that change. That immediately implies an absolute minimum latency of the duration of the servo pulse (approx 1 to 2 ms). Sorry, those guys claiming 0 latency aren't quite accurate. John Koss has done a number of tests of different radios using the same equipment and technique and has very good, trustable results. His data matches our own both for our systems and those of others.

So, here's how it works. You move a stick on your transmitter. The time it takes to get to the output pulse of the servo is the latency. Latency comes from multiple sources, and we'll do them here in order.

First, you have the sampling rate. This can be the same as the RF frame rate, but often it's quite a bit faster. For sake of argument, let's assume it's 91 Hz (11ms).

If you make your change right after a sample was taken, it will take almost a full sample time until the radio knows that change was made. If you make the change immediately before the sample is taken, it's virtually 0. What that does is tells us what the uncertainty is, and is the reason you see in John's data that there is a vertical bar. It means that the fastest it was measured is X, and the longest is Y. The difference between Y and X is going to correspond pretty closely to the RF frame rate.

Next, you have the processing time. This is the time it takes between the sample time until it gets onto the air. In the old radios using analog encoders (NE5044), this was instantaneous. In digital radios, there is a lot of math going on. Here is a place where brands are differentiated. Because the AirWare radios were developed to minimize latency everywhere possible (the worlds best 3D air and heli pilots are team members), special care was taken to reduce this time. I know of one small brand which has absolutely horrible numbers here (they would have fired me if I had made it) but it's popular because of its low price. The smart FPV racers have learned this and are coming back to Spektrum as a result. Makes me proud!

Next you have latency in the RF system and protocol. It takes a small but measurable time for the hardware to convert the raw message to one that has been spread (for Direct Sequence), it takes time for the serial data to be clocked out. On the receiver side, it takes time for it to detect and decode the transmission and return it to the original packet that was sent.

Then you have time spent in processing the data in the receiver. If you are using old technology like PPM, the receiver will need to convert the digital values into pulses, each of which takes 1-2 ms to send out. If you are measuring the latency on a higher-number channel, it will include the times required to send all the other channels out. For an 8-channel PPM system, latency on channel 8 will be affected by the pulses going out for channels 1-7 too!

If you are using a serial communication system like the Spektrum Remote Receiver Protocol then the latency can be dramatically reduced. It takes 1ms for the entire packet to be sent from the receiver. And it is a constant 1ms, not a variable one.

From there the latency in your flight controller is entire up to your system. A flight controller will add some latency as it does the math to integrate gyro and accel data to the inputs. If implemented properly this can be minimal. If you are generating PWM to control ESCs or servos, there will still be some latency there, but with a smart design and chip selection those pulses can all go out at the same time instead of being delayed as they are with PPM.

People have asked why I so strongly rail against PPM. It's simple - it takes too long! If you are using a FC with a PPM input, consider this:

You get latency in the transmitter based on the frame rate. For a PPM system, you need 22ms frames for the data to all get out. Then you need to wait up to 22ms more for the receiver output to be generated (the FCs often read the full pulse train before starting to process the data). Then the FC does it's math, and can take another 22ms for it to get out to the ESCs/servos. Worst case 22 + 22 + small (FC gyro processing) + 22.

Doing it using Remote Receiver Protocol you can use 11ms frame rate + 1ms + small + (worse case PWM out) 22ms (best case is 1ms).

66ms + a small number or 34 + small number or 12 + small number.

Anybody thinking they get great performance with a PPM system simply hasn't reviewed the entire system.

-----

Just to be absolutely clear while you're around. PPM is the less obvious choice in the series PWM, PPM, SBUS, Sat ETC? Then why is it ever invented?

When it invented it was ingeniously clever and WAY better than other contemporary alternatives. Modern aircraft are quite a bit advanced and benefit from higher performance.

-----

Is PWM is actually better than PPM in terms of latency?

PWM is the final stage delivery mechanism. It's part of the equation. There are faster protocols but they are specialized and usually part of an integrated system approach, not the standard-component system most quads use.

-----

So I started reading about the differences and the fastest protocol. Seems to be serial SAT direct communication or SBUS, PPM is no go and PWM is a dated protocol, at least for FPV. For 3D planes it's perfect.

PWM is what almost all servos use. There are very few (and expensive) serial servos available. As noted in my previous post, this is only a 1-2ms delay max (note also that good servos are 10ms rotation speed, so the impact is minimal). While it may be dated, it is sufficient for the most part.

PPM is a no go, anywhere you can get rid of it you should.

And yes, the Remote Receiver Protocol or something like S.Bus would deliver the lowest latency. Especially if you are using a system that doesn't have to listen before talk.

-----

You really get me confused now, I always assumed when using one wire per channel on the RX side it is by definition a PWM system.

OK, I'll explain them all so you can see how they differ. Since PWM is used universally as the input standard for servos (and ESCs) I'll start there.

PWM is Pulse Width Modulation. The originating device (rx, typically, or flight controller) has a 3-wire connection to the servo. The wires are ground (aka common or return), power (about 5V), and signal. The signal lead gets a pulse every frame time (ranges from 5 to 25 ms, brand- and mode-dependent) that tells the servo where it should be. The pulses range from about 1ms to about 2ms (actual pulse is brand-dependent). The width of the pulse (in time) tells the servo the position, with about 1.5ms being the "go to center" value. In general, only a signal servo gets a connected to the output of the receiver. It is a point-to-point, 1-to-1 connection. This has been the standard for 40 years and is not likely to go away any time soon. The signal line is normally at the ground (0V) level, and goes up (to 3 to 5V, model- and brand-dependent) when the pulse is active.

PPM is also a 40-year-old standard, but it is disappearing quickly. PPM stands for Pulse Position Modulation. It used to be the way all the transmitters spoke to receivers, without regard to AM or FM. The signal on PPM can be either low with high-going pulses, or high with low-going pulses. The method used varies according to brand. It is possible for all channels to get their pulses at the same time.

In PPM, the signal line (which can also be RF) is at one state, then a short pulse (150-400us, brand-dependent) is generated and it goes back to its initial state. Later on, another pulse of similar size is generated. The distance between the leading edge of the pulses corresponds directly to the time of the PWM pulse that is generated for that servo - you can put take a PPM signal and a PWM signal on an oscilloscope at the same time and see how they directly related.

The next channel in PPM uses the starting edge of that second pulse mentioned above to define the start of its servo output period. In this manner, up to 8 (brand-specific) channels of data are transmitted one after the next as a group. This is called a Frame.

After all the channels have gone out (a total of 9 pulses = 8 + 1 to mark the end), the line must go idle (the Sync Time) for a minimum time of 6ms. This is why you have a standard frame rate of 22ms.

8 channels * 2ms + 6ms idle = 22ms

Every 22ms a complete frame (data for all channels) is transmitted.

PCM is Pulse Code Modulation. PCM radios were the first part of the transition from analog modulation schemes to pure digital like we have today. Instead of sending pulses of various widths, the radios essentially sent binary data (0 and 1) to the other side. The data can be checked for integrity and verified before using it to control the servos. The servos, btw, still used (and do today for the most part) the PWM pulsing we spoke of first. The limitation on PCM is that it still required to be the only transmitter on a frequency, and it still took 20-ish ms to send a frame of data. This was a factor of physics and the FCC rules limiting the channel to being 20kHz wide.

Modern 2.4gHz systems take this much further using technology such as Direct Sequence, Frequency Hopping, and such to better ensure delivery of the data. A Spektrum transmission takes only about 1ms to go out; other brands takes much longer. The higher the RF transmission speed, the quicker the data can be acted on by the flight controller/receiver and thus the servos.

Hopefully this explains why a serial interface is 1-wire, a PPM interface is 1-wire, and a PWM interface is 1-wire.

There are still some flight controllers out there which take PWM in from a servo. Those are multi-wire messes! It's a bunch of 1-wire interfaces coming together. Perhaps that is where the confusion resides for you?

blogodex = {"toc" : "Radio Latency", "idx" : ["PPM", "PWM", "Andy Kunz", "Spektrum"];