R9M-Lite & Crossfire Latency Testing

We will test and compare the latency of Frsky R9M-Lite with that of the TBS Crossfire. Both are great 900MHz RC systems for long range and many are having trouble deciding which to get. With latency being one of the main considerations we hope you find the test useful.

Many thanks to Frsky for providing the R9M-Lite module and X-Lite transmitter for this test. This test was done by Andrey Mironov, with his permission to share the result here.

Learn more about the TBS Crossfire in this article. Check out our review of the Crossfire vs. R9M.

Latency in our Radio Control System

The latency in our RC link can be divided into 4 parts:

Gimbals => TX Interface (OpenTX) => TX module => RX => FC

The latency is measured between the points before OpenTX and after RX (bold text).

Measuring Latency in R9M-Lite and Crossfire

The latency are measured with the TX modules installed in the Frsky X-Lite. Other gear used:

  • R9M-Lite TX module with R9 Mini receiver
  • Crossfire Micro TX module with Crossfire Micro V2 receiver

Further Reading: Does the Frsky X-Lite support Crossfire?

Note that there is a stick filtering (6-sample averaging) that exists in OpenTX, which introduces a varying delay. To properly measure latency a custom version of OpenTX was built to get rid of this filtering. This was explained in more detail in our previous latency test of the X-Lite.

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

Latency is measured between the falling edge of gimbal PWM signal and the start of corresponding RX signal frame.

Note that this doesn’t take RX signal frame length into account. The frame length for SBUS is slightly less than 3 ms, that of CRSF is 0.7ms, which is in turn dictated by 100k vs. 420k baudrate, 2.97ms × 100/420 = 0.7ms.

The R9M-Lite is flash with FCC firmware.


Here is the average latency:

  • R9M-Lite => SBUS – 14.07ms
  • Crossfire Micro TX => CRSF – 13.9ms
  • Crossfire Micro TX => SBUS – 20.23ms

The R9M-Lite actually performed surprisingly good, very close to the Crossfire in terms of latency. But note that the SBUS protocol still has a longer frame length than CRSF (over 2ms).

Another surprising observation is that the Crossfire doesn’t seem to work as well with SBUS, there is an 8ms extra delay compared to when using CRSF protocol on the receiver. Our guess is that the Crossfire goes into 50Hz mode when SBUS is selected as output (instead of 150Hz). However R9M has 150Hz for SBUS.

Here is the full result:

Latency (ms) Mean Stddev Min Max 25% 50% 75% 95% Refresh rate (Hz) Notes
R9M Lite  – SBUS (R9 Mini) 14.066 2.501 7.515 20.205 12.140 14.524 16.016 17.843 150 add 2.97 ms for SBUS
XFIRE Micro – CRSF (Micro V2) 13.900 2.448 8.432 19.635 12.075 13.879 15.752 17.842 150 add 0.7 ms for CRSF
XFIRE Micro – SBUS (Micro V2) 20.231 6.233 7.680 32.831 14.828 20.606 25.346 29.756 50 add 2.97 ms for SBUS
OpenTX latency (switch) 5.626 1.478 2.046 8.937 4.628 5.630 6.574 7.558

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

3 thoughts on “R9M-Lite & Crossfire Latency Testing

  1. Don Olsen

    Similar question would this suggest the R9M would perform as well as the R9M-Lite. I’m interested because if so I believe the trainer port on my Spektrum DX6 is SBUS and this may be the solution I need. Instead of either buying a new DX9 $450 & CRSF $225 in order to get 900Mhz but keep the high 150hz refresh for the lower latency.


Leave a Reply

Your email address will not be published. Required fields are marked *

Are you Robot? *

I only check blog comments once or twice a week, if you want a quick reply you can post your question on this forum IntoFPV.com... You might get a faster response from me there (multirotor related only).