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