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?
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.
- Connect the FC to computer, open Betaflight Configurator and go to the CLI tab
- Enter this command to force FC into bind mode:
- For Betaflight 4.1:
bind_rx_spi, for BF3.x:
- The red blinking LED on the FC should now stop blinking
- For Betaflight 4.1:
- Activate the bind option on the radio
- Wait a few seconds, then stop the bind function on the radio
- 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 doesn’t take up any UART
- According to Andrey Mironov, a Betaflight dev, the latency should be theoretically lower than SBUS – up to a few milli-seconds delay reduction compared to UART connection
- Receivers using SPI_RX can be built into flight controllers, and the overall cost might 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 use the bind button like traditional receivers
- RSSI is integrated into the protocol, so no need to send RSSI value using a channel
- Receiver firmware is embedded in the flight controller firmware, which means in order to update the receiver firmware you need to flash the FC firmware
I will keep this post updated, let me know if you have any questions or comments.
Can anybody tell me what the resource ‘RX_SPI_CS’ relates to? I am wanting to add RGB LED’s and the LED_STRIP resource needs to be on A15 which is currently occupied by RX_SPI_CS. For information I use a crossfire receiver which connects via 4 wires not the usual 3. I have tested and LED’s do work if I set the strip to A15 resource, can I set RX_SPI_CS to none without issue? Or should I leave it sharing A15? Or do I need to remove the LED’s?
Appreciate any help anyone can offer.
Did you figure it out? I have the same question
You article is very helpful and informative. I really appreciate you effort. It probably saved me hours of frustration, as I got my Flywoo Firefly going right away after your tips on binding it.
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.
There is also a “FRSKY_X_LBT” provider for people in Europe.
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?
Can you bind an access protocol radio to an spi_rx day such as the Emax tinyhawk AIO has built in?
I’ve been told D16 might work, but i have yet to get an ACCESS radio to confirm
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.
is it possible to use the SPI protocol with the sp racing F3?
There is no more Betaflight updates to F3 FC’s.
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.
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..
did you fix it?
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?
Any chance to get LUA scripts working on a EU version ?
Coz I read somewhere that it’s availablefor international only. True?
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 :)
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
I have one and it is losing telemetry and sign so I can’t fly it but latency looks low in the configurator.
My FC just keeps losing rssi . I tried everything to troubleshoot with no luck.
Same here, waiting on the fix
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
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.
I think he is correct. My board only has a transceiver on it.
As far as I know Racerstar Crazybee also uses spi rx.
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.
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.
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).
No EU-LBT! :(
Excellent news…. thanks!
What does MCU stand for?
Also any ideas on robustness of this vs. older protocols? How does SPI behave over a not-perfect RF link?
This isn’t an over-the-air protocol. It is just the protocol between the FC processor and the RF chip.
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.