SPI_RX – A New Receiver Protocol | FC with Built-in RX

SPI_RX is a new communication protocol between the flight controller and receiver using SPI BUS. We will explain what SPI_RX is, and the advantages over traditional serial RX protocols such as SBUS.

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 (https://goo.gl/SXTJBD), with a built-in receiver that finally uses the new SPI_RX protocol.

Further Reading: What is an RX protocol?

SPI_RX - Matek F411 ONE FC

Matek F411 ONE FC with built-in SPI_RX

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

What is SPI?

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.

Example, SPI for Betaflight OSD

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: 1. SPI is a faster protocol than UART; 2. 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 or soldering

The Connection and Settings of SPI_RX

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

Serial receiver protocols including 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. There is no need for another MCU on the receiver as a communication interface.

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

Binding SPI Receiver

Before binding, go to Betaflight’s configuration tab, and change “SPI Bus Receiver Provider” to the one you prefer.

SPI receivers have two different modes, FRSKY_D (D8) and FRSKY_X (D16).

You can get telemetry with D16 mode, but D8 is generally recommended as it offers better range.

Then go to your radio’s Model Setup page, under Internal RF, you need to change mode to either D8 or D16 according to your settings in Betaflight above.

FC with built-in SPI receivers normally allows you to enter bind mode via CLI.


  1. Connect the FC to computer, open Betaflight Configurator and go to the CLI tab
  2. Enter this command to force FC into bind mode:
    • For Betaflight 4.1: bind_rx, BF4.0: bind_rx_spi, for BF3.x: frsky_bind
    • Enter save
    • The red blinking LED on the FC should now stop blinking
  3. Activate the bind option on the radio
  4. Wait a few seconds, then stop the bind function on the radio
  5. Reboot FC, Done!

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 theoretically lower than SBUS. I will come back and 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 Downsides

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

31 thoughts on “SPI_RX – A New Receiver Protocol | FC with Built-in RX

  1. Seth Baker

    Hello Oscar,

    I am desperately trying to find a 10 channel receiver to use with a Spektrum DX9 gen 2 and the Fly Wing H1 FC. The transmitter outputs DSMX/DSM2 and I need the receiver to output S-Bus or PPM. Do you have any suggestions?

    Thanks in advance for your help.


  2. Jorge

    Hello, i was moving my spi bus Receiver provider And switched it to one that says flysky beacuse i just bought a flysky transmitter, so when i choose the the option and saved my drone started beeping and couldn’t connect it to my old or new transmitter or betaflight, what do i do?

  3. Andrew Joseph Blanche

    Don’t think you actually gave the command line in CLI to activate binding but you mentioned it, could you either write it out I’m assuming it’s short or direct via link to the github page.

  4. Markus

    I think you can remove the disadvantage “new binding after flashing”. You don’t need to do that with BF 3.4 – I already flashed my MatekF411RX already several times and it was not necessary to re-bind.
    The big issue I have (I’m using non-EU firmware) is that I get twitches and fail-saves in X mode. D mode seems to work properly.

  5. Hendrik

    My board FC CrazybeeF3 BNF Frysky,
    I accidently choosing wrong SPI reciever Provider to A7105_Flysky_2A and save it

    now my FC can not connect to USB anymore, everytime connect it is says ” Unkown USB device (Device descriptor request Failed) for windows 10″
    is there any suggestions to fix it? please help me anyone..

  6. Dom

    Hi everybody,

    I wonder if the Airbot Omnibus F4 v5 does support FrSky SPI_Rx or not?
    I can´t find any references on the web but the manual clearly states the is does have CS, Miso, SCL, Mosi, VCC and GND so it should be able to “use” this port. Any D- or X- FrSky receivers should be able to communicate with it. Question ist how to connect the boards physically. Because the r.xsr for example does not have the desired outputs, or at least they are not labeled this way. Any idea?

    Thanks Dom

  7. Philippe

    Any chance to get LUA scripts working on a EU version ?
    Coz I read somewhere that it’s availablefor international only. True?

  8. Krotow

    Interesting… How about exotic PPM receiver support in Betaflight via SPI. Some toy quad 2.4G receivers for example are connected to FC va SPI. V2x2 receivers for example. Maybe we finally found a way how to use receivers from broken toys with stock transmitters in Betaflight controlled tiny whoops. Or how to implement Betaflight in these toy quads and control them with stock remote :)

    1. John^^

      You still need the hardware protocol chips as found in 4in1 moduals to control toy quads… not that the JJ1000 is not RC grade machinery with a good hobby grade TX. Seems like the DEVO with a 4in1 module will be have less latency than a FrSky TX like the Horus… what brought me here looking at the SPI comms protocol

  9. Patrick McKee

    I have one and it is losing telemetry and sign so I can’t fly it but latency looks low in the configurator.

  10. pizzy

    This is big, I can only assume this will lower thr latency which is what we all really care about let’s be honest. Also if you don’t understand that most everything will be one chip or pcb then you’re not thinking ahead. I can’t not wait to see this become a standard in more products, bye bye sbus

  11. Joe

    The “no need” for an extra MPU does not seem correct. The X4R-SB has a STM32F0 and is used for many things including failsafe/telemetry. Or are you saying the RF chip does all this and outputs spi-rx? I personally don’t think so.

    1. Steven

      Mine constantly failsafes in d16. It works fine in d8 mode but then lua scripts wont work. Also when the tx is on and connected to betaflight it constantly says telemetry lost.

      1. Pizzy

        Thanks man your comment at least got me flying stable. How is your range? I had to resolder on an ant on my Taranis dx9+, my range seems less than it should be, so I am going to redo ant and put it outside of my radio and test again. This latency is the lowest in my exp, compared to crfs. I don’t have Futaba to compare too.

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

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

For prompt technical support, please use our forum IntoFPV.com. I check blog comments weekly.