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.
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.