During the latency testing on the Frsky X-Lite, we discovered some interesting results. There is delay in the gimbals, (how often the gimbal value is being updated), and additional delay caused by OpenTX’s sample averaging.

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.

The testing was done by Andrey Mironov, with his permission to share the results here.

Gimbal Refresh Rate

The Hall Effect gimbals in the X-Lite output PWM signal of fixed frequency, like the Horus X10S and X12 (note: not all hall gimbals output PWM).

Roll and Pitch gimbals had frequencies of 263.5 Hz and 260 Hz respectively, which is 3.85ms.

Delay in OpenTX – Sample Moving Average

OpenTX is using a weird scheme for sampling this PWM signal from the gimbals. It’s a 6-sample moving window for filtering, which we found to introduce considerable amount of delay.

Note that the SBUS value only settles in the 3rd value after PWM is changed

Looking at the OpenTX code, we found out how it works: it accumulates 6 values, min and max values are then subtracted and the result is the average of the remaining 4 values.

This filtering introduces a varying delay depending on the pattern of the input signal, which effectively increases delay by 1 to 3 samples.

Therefore the latency caused by the filtering in OpenTX would be 3.85ms – 11.54ms.

Low quality analog gimbals might have noisy output, and the sample filtering can help smooth that out. But it’s my understanding that by using PWM gimbals, such filtering is no longer necessary. Let’s hope this get removed/fixed soon.

Note that this filtering only applies to the sticks and not the switches.

Testing Methods and Full Result

For the sake of testing, Andrey built a custom version of OpenTX which doesn’t do this 6-sample filtering. He was testing with the built-in iXJT module in the X-Lite, and an XSR receiver with the latest EU LBT firmware, in D16 8ch mode with telemetry on.

First test consisted of tapping into the pitch gimbal line and generating a 260 Hz PWM signal with a STM Discovery board, altering between 10% and 90% duty cycle every 128 milliseconds, while observing the resulting SBUS frame over the course of 60 seconds.

The Latency between Gimbal and SBUS Output

Latency is measured between the falling edge of gimbal PWM signal and the start of corresponding SBUS frame. This doesn’t take SBUS frame length (slightly less than 3 ms) into account, so keep that in mind.

Latency Result

• mean 19.95 ms
• std 4.80 ms
• min 12.09 ms
• max 49.33 ms

Quantiles

• 5% : 14.12 ms
• 25% : 16.83 ms
• 50% : 19.24 ms
• 75% : 21.78 ms
• 95% : 29.85 ms
• 99% : 35.82 ms

There were two “bad” values during these 60 seconds, 35.821 ms and 49.3363 ms, which is not that bad for a relatively long timespan.

The Latency between Switch and SBUS Output

The same test was repeated by tapping into one of 2-POS switches and flicked it on/off for 60 seconds at 120-250 ms intervals. In the future we can generate varying-frequency PWM signal instead of using the physical switch to avoid stressing it :-)

Latency

• mean 19.75 ms
• std 3.85 ms
• min 11.79 ms
• max 42.75 ms

Quantiles

• 5% : 14.27 ms
• 25% : 17.10 ms
• 50% : 19.41 ms
• 75% : 21.77 ms
• 95% : 25.77 ms
• 99% : 31.75 ms

Due to addition of human factor this test had a higher entropy of switch on/off times and resulted in a lower max value, but the remaining values are incredibly similar.

The resulting values of 20 ms average latency and 12 ms minimum seem to agree with what FrSky advertises on their site and in X-Lite manual. Though it doesn’t take SBUS frame length into account.

The interesting consequence of the 6-point averaging is, on X-Lite (and probably Horus X10S) your switches will have less theoretical minimum latency than you sticks.

More Latency Testing and Discussions

Here is the latency testing for the R9M-Lite module, and we confirmed it’s on par with theTBS Crossfire :)

All captures for Saleae as well as Python script used to produce the results will be posted on Andrey’s GitHub shortly.