In this post we will share some findings and results regarding the latency of FPort receiver protocol. Separate tests were run on the XSR and R-XSR RX’s, using a logic analyser.
FPort and SBUS Latency Measurement and Comparison
The latency stated in the table were measured at the gimbal/switch output, and the receiver output. It includes latency from OpenTX and iXJT->XSR.
|Latency (ms)||Mean||Stddev||Min||Max||25%||50%||75%||95%||Refresh rate (Hz)||Notes|
|iXJT – XSR – SBUS||19.748||3.852||11.789||42.749||17.100||19.409||21.774||25.766||111||add 2.97ms for SBUS frame|
|iXJT – XSR – FPORT||15.078||3.628||8.244||35.896||12.547||14.967||17.303||20.272||111||add 3.55 ms for FPORT frame|
|iXJT – R-XSR – FPORT||16.724||3.354||10.039||29.761||14.346||16.804||19.134||21.820||111||add 3.55 ms for FPORT frame|
As the result suggests, FPort is slightly better than SBUS in terms of latency, even though every control frame (RC signal data packet) contains telemetry data. However the protocol design is not yet optimal which means it will only get better in the future.
When testing FPort on the XSR, we found it has more erratic refresh rate. Hopefully reliability will improve in future software updates.
There were some performance difference between receivers when using FPort. For example, we found XSR was slightly better than R-XSR, that’s probably because of the different micro controllers. XSR has a more advanced 32-bit MCU while the R-XSR is using an 8-bit MCU.
Credit: Andrey Mironov