Serial protocol receiver setup

In this article you will learn how to set up your receiver with your flight-controller. Setting up your receiver consist of physically attaching the receiver to the flight-controller and software setup within Betaflight.

There are different protocols enabling receivers to communicate with the flight-controller. Some only work in one direction, others work bi-directional, so that the flight controller can send data back to the receiver and the receiver on the other hand can transmit this data back to the transmitter.

Bi-directional communication can happen either by using a full UART - using both RX and TX pin or via half duplex mode by only using the UARTs TX pin.

In this post we will only look at serial receiver protocols - there are some other protocols out there but when it comes to quadcopters we nowadays only deal with the serial ones.

  1. Protocol Overview and hardware setup
    1. SBUS
    2. IBUS
    3. F.Port
    4. S.Port
    5. Crossfire (CRSF)
    6. Spektrum 1024/2048
    7. SUMD / SUMH
    8. XBUS
  2. Signal inversion
  3. Betaflight setup
  4. Testing the receiver

Protocol Overview

Each vendor has its own protocol(s) which does not make it easy for the user. All of them are slightly different to configure. But once you know the basics, it should be easy to figure out how to set up everything.

One thing all of the serial receivers have in common is, that they all use an UART in one way or another. UART stands for Universal Asynchronous Receiver Transmitter and you can think of them as the USB ports of your flight controller. Depending on your actual flight-controller, the amount of UARTs available will vary.


SBUS is one of the most wide spread protocol used for transmitting receiver data to the flight controller. It is a one way protocol, the receiver is attached to the RX pin of a UART.

Most flight-controllers nowadays have a dedicated SBUS pin you should use - this is basically the (inverted) RX pin on one of the UARTs (often UART 2 is used). If there is such a pin the corresponding TX pin of that UART is usually not broken out.

SBUS is an inverted protocol mainly used by FrSky and Futaba receivers.


IBUS comes in two flavors, one of them is basically like SBUS, just not inverted. In this case you do not have telemetry and can connect the receiver to the RX pin of any free UART, just not the SBUS pin. The second flavor is with telemetry. In this case you need to connect the receiver to the TX pin of any free UART.

This protocol is exclusively used by FlySky.


F.Port has been created by FrSky in cooperation with the OpenTX developers. It basically fuses SBUS and S.Port into one wire. This protocol is a half duplex serial protocol, meaning that transmitting and receiving both happens over one wire.

The F.Port pin of the receiver has to be connected to the TX pin of an UART. This has to be a real UART and not soft serial. If you have an F4 flight controller you have to make sure to use the inverted F.Port output of your receiver. If you have an F3 or F7 flight controller you do not need to care about signal inversion.


S.Port or Smart Port is used to send telemetry data back to the receiver. If your receiver supports S.Port and you want to use it, you need a free UART, this can not be the same UART that is used for another serial connection, but it can be soft serial.

S.Port is like SBUS or IBUS one way communication - just in the other direction, the flight controller is sending data to the receiver, but there is no communication in the other direction.

S.Port is an inverted protocol.

S.Port is most commonly used in combination with SBUS.

Crossfire (CRSF)

Crossfire is TBS’ communication protocol. It is four times faster than SBUS and utilizes a full UART port, meaning that you will need both UART pins - RX and TX.

You attach the TX pin of the receiver to the RX pin on the flight controller and the RX pin of the receiver to the TX pin of the same UART.

Spektrum 1024/2048

DSM2 receivers use the Spektrum1024 receiver protocol and DSMX use Spektrum2048 receiver protocol. Those protocols are Spektrums counterparts to SBUS, again without the inversion.

The Spektrum1024 or Spektrum2048 pin can be attached to the RX pin of any free UART.


Those are serial protocols used by Graupner. SUMH is the legacy, predecessor protocol to SUMD. There are updates for most SUMH receivers to instead use SUMD. It is very comparable to SBUS, except that it is not inverted.

The SUMD pin of the receiver should be attached to the RX pin of any free UART.


XBUS is JR’s serial protocol. Not very commonly used in the quadcopter hobby, actually there is only one receiver model that is currently supported by Betaflight.

The XBUS pin of the receiver has to be connected to the RX pin of any free UART.

Signal inversion

Signal inversion can get confusing very quickly.

If you have an F3 or F7 flight controller you do not have to worry about this at all. Those processors handle signal inversion on their own, without the need for you to do anything.

If you have an F4 flight controller, read on in order to know what is up.

SBUS uses an inverted signal, that is also the reason why there is a dedicated SBUS pin on most flight controllers. This pin has signal inversion in place. If you have an F3 or F7 flight controller you could connect your receivers SBUS pin to any RX of any UART - not so with an F4 flight controller - here you have to connect your SBUS receiver to your SBUS pin or it will not work.

This is also the reason why the SBUS pin can not be treated as just a normal RX pin on F4 flight controllers.

S.Port and F.Port have the same issue - they are also inverted protocols. A lot of F.Port enabled receivers have an F.Port and an inverted F.Port pin. This is confusing because the inverted F.Port pin actually provides an un-inverted signal, but since F.Port is by definition inverted the inverted pin makes an un-inverted signal out of it.


Betaflight setup

To set up your serial receiver with Betaflight you first go to the Ports tab and activate the Serial RX switch on the UART that you connected your serial receiver to.

Do not forget to hit Save and Reboot.

Go to the Configurations tab and in the Receiver Mode drop-down select Serial-based receiver. In the Serial Receiver Provider drop-down select the protocol you are using.

Depending on the protocol you are now done and can proceed to the Receiver tab to verify that everything is working properly.

With some protocols there is some additional setup you have to do:


When you are using F.Port you have to make sure to enable half duplex mode. Go to the CLI and depending on your flight controller type:

F3 and F7

set serialrx_halfduplex = ON
set serialrx_inverted = ON


set serialrx_halfduplex = ON
set serialrx_inverted = OFF

IBUS with telemetry

When you have a telemetry capable IBUS receiver enable half duplex mode in the CLI:

set serialrx_halfduplex = ON


When using S.Port go to the Ports tab and in the Telemetry Output section of the UART you connected S.Port to, select the option SmartPort.

Hit Save and Reboot.


In case you are using one of the systems that support telemetry do not forget you enable the Telemetry option in the Other Features section of the Configuration tab.

Testing the receiver

In order to confirm that your receiver is working properly, switch to the Receiver tab. I am assuming that your transmitter is already bound to your receiver.

Move the sticks and switches on your transmitter and make sure that the corresponding bars move accordingly in the Betaflight configurator.

In case something is not responding properly you can switch the channel order either in the Betaflight configurator or in your transmitter. Personally I prefer to switch the channel order on the transmitter to match the default of Betaflight, then I do not have to worry about channel order after updating.

Betaflights default channel order is TAER1234 meaning that it expects the channels being transmitted in this order:

  1. Throttle
  2. Aileron
  3. Elevator
  4. Rudder
  5. Aux 1
  6. Aux 2
  7. Aux 3
  8. Aux 4

If everything is set up properly, you can now move on and set up your modes.

Chris is a Vienna based software developer. In his spare time he enjoys reviewing tech gear, ripping quads of all sizes and making stuff.

Learn more about Chris, the gear he uses and follom him on social media:

Also check out

Betaflight Modes

Betaflight Modes

Betaflight CLI bind

Betaflight CLI bind

FrSky R9

FrSky R9
Show more comments