News: SPI_RX – A New Receiver Protocol

SPI_RX is a new communication protocol used between the flight controller and receiver over SPI BUS. There are some advantages with SPI_RX over traditional serial RX protocols such as SBUS, which we will explain in this article.

What is SPI_RX?

I first heard the term “SPI_RX” when talking to developers from Betaflight and Matek in early 2017, but only just recently I found out that Matek is releasing a flight controller, the F411-ONE, with a built-in receiver that finally uses the new SPI_RX protocol.

Further Reading: What is an RX protocol?

Note that SPI_RX is NOT at all related to FPort, another RX protocol that is being developed by Frsky and Betaflight.

Basically, SPI is a communication protocol like UART, a serial communication protocol. A SPI connection requires 4 wires, while an UART connection only uses 2 (TX and RX). However SPI is faster than UART and places less stress on the processor.

The use of SPI BUS in flight controllers is not a new concept, in fact we have always been using it for our sensors like the Gyro, SD card reader etc. More recently we “upgraded” our OSD from using UART to SPI and that’s how we have Betaflight OSD. If you have previously used the MinimOSD, you should have realized by now how much better Betaflight OSD is comparing to traditional OSD using serial connection:

  • Betaflight OSD doesn’t take up any UART
  • Betaflight OSD has faster update rate, because SPI is faster than serial connection, also the FC micro-controller (MCU) is connected directly to the OSD chip without having to go through another MCU in the OSD (e.g. MEGA328P in the MinimOSD)
  • No wiring hassle, because Betaflight OSD is built into the FC

Receivers using SPI BUS has similar benefits, and I think the whole point of SPI_RX is to have the receiver integrated on the FC.

Serial receiver protocols such as SBUS, IBUS, Spektrum DSM and TBS Crossfire, all require a dedicated MCU on the receiver as an interface to talk to the flight controller over UART.

As you can see in the SPI receiver connection, the FC MCU is able to talk directly to the RF chip on the receiver, and there is no need for another MCU on the receiver for communication.

An new receiver mode “SPI_RX support” will be added to Betaflight Configurator in BF 3.3, and you will find the different protocols it supports.

For the Taranis and Horus users, you will be using Frsky_X (16 channels) and Frsky_D (8 channels) protocols.

The Advantages of SPI_RX

Here are the benefits of SPI_RX we know so far:

  • SPI_RX supports Telemetry and LUA script
  • SPI_RX can free up two UART’s by replacing SBUS and SmartPort, or at least 1 UART by replacing CRSF, iBUS or DSM
  • According to Andrey Mironov, a Betaflight dev, the latency should be lower than SBUS theoretically, I will update with actual figure once I get an update
  • Receivers using SPI_RX can be built into flight controllers, and the overall cost should be cheaper than buying standalone receivers such as R-XSR. Also there will be no more hassle with soldering and wiring
  • You can enable bind mode in the software, or using the bind button like normal receivers
  • RSSI is integrated into the protocol, so no need to send RSSI value using a channel

The Downside

  • (Unconfirmed) Every time you flash the firmware on your FC with a built-in SPI receiver, you will have to bind your TX and RX again; BF might implement a feature to retain binding information in the future so it doesn’t get erased during firmware flashing

I will keep this post updated, let me know if you have any questions or comments.

8 thoughts on “News: SPI_RX – A New Receiver Protocol

  1. Michael K

    Hey Oscar, your statement re losing the binding information is wrong. The binding information will be part of the diff / dump, like so:

    set frsky_spi_tx_id = 96,80
    set frsky_spi_offset = -43
    set frsky_spi_bind_hop_data = 5,102,213,83,188,58,163,33,138,8,113,218,88,193,63,168,38,143,13,118,223,93,198,68,173,43,148,18,153,228,98,203,73,178,48,153,23,128,233,103,208,78,183,53,158,28,135,0,0,0
    set frsky_x_rx_num = 5

    If the config is backed up before the upgrade, and then restored, the binding will be preserved (this can also be used to copy the binding information to a new board, without ever having to re-do the binding process).

    1. deadmoo

      This isn’t an over-the-air protocol. It is just the protocol between the FC processor and the RF chip.

  2. Kelvin

    Any word on cost of this little fella? If its around the same as the F405 it will be a winner. More I’d just assume spend the extra on a rx I can reuse.


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 You might get a faster response from me there (multirotor related only).