top of page

SBUS Vs FBUS: FrSky's Serial Data Protocols

You need a way to connect your receiver to your flight control unit, such as FBL, Redundancy Bus, or Gyros.  In the early days of gyro stabilization on RC models, it wasn't uncommon to use a "squid" cable of sorts, where you'd take a PWM signal for each channel from the receiver to the gyro.  That means at least four, sometimes up to 12+ signal wires in addition to one or two sets of power wires.  Yuck!

These days, however, we have easy access to serial data protocols, which at a minimum send all control channels (usually 16) as well as some other misc information (such as failsafe status) and, sometimes, telemetry data.  This means that with the right hardware, you just need a single 3-wire servo cable to connect from the receiver to your gyro.

So where does it start?

a diagram showing how to connect servos and sensors


Modern RC-related serial protocols started to gain popularity with S.Bus.  Originally coined and engineered by Futaba long ago but now widely adopted by many different radio systems and almost every gyro/flight control system, and even in many areas outside of the RC hobby.  S.Bus carries 16 channels from a receiver to a flight control unit, along with several other pieces of information (packet lost, failsafe status, etc).  It's a digital protocol, as opposed to PWM, so it's much less susceptible to noise and interference.

FrSky adopted S.Bus many years ago, much to the enjoyment of its users.  In combination with their S.Port protocol (more on that later), it was possible to have communication back FROM the flight controller to the receiver, which would then pass any information to the transmitter as new telemetry sensors.  S.Bus is also used for redundancy in parts of the FrSky ecosystem.  You can, for example, connect the S.Bus input on one receiver to the S.Bus output from a second receiver.  If the first receiver loses signal, even momentarily, the S.Bus signal from the second receiver is automatically and seamlessly passed onto the output of the first receiver.  You can also use S.Bus with any S.Bus compatible servo, allowing multiple servos to run from the same signal wire but respond to different channels.

Somewhat recently, FrSky has come out with a customized version of S.Bus called SBUS-24.  It's more or less the same protocol, but with 8 more channels than typical S.Bus.  This makes it incompatible with anything that expects the standard S.Bus 16-channel signal, and so far, only FrSky products have and can use SBUS-24.  However, all modern FrSky receivers can output either version of S.Bus, just by changing a setting in the receiver.  The default is the standard 16-channel protocol. 

The S.Bus protocol runs at 100,000 bits per second.


As stated earlier, S.Port is FrSky's original telemetry protocol.  Technically, there was one before it, but it's very old and no longer used, so it's not worth explaining further.  S.Port is a bidirectional serial data protocol that was designed to connect various telemetry sensors, such as GPS sensors, Voltage/Current sensors, etc to a FrSky receiver.  Because it is bidirectional, it allows you to connect sensors in 'parallel' - meaning all of the signal lines are connected together, and each sensor takes turns giving its reading.  S.Port is still in use today, and still supported by all modern FrSky equipment.  

The S.Port protocol runs at 57,600 bits per second.


F.Port was FrSky's first attempt at a single-line control AND telemetry data protocol.  It was more or less a direct combination of S.Bus and S.Port.  It can carry up to 16 channel worth of data from the receiver to a flight controller, and simultaneously up to 27 sensors and other information from the flight controller to the receiver, to be sent to the transmitter as telemetry sensors.  F.Port is only for connection from a receiver to a flight controller, and cannot accept any extra telemetry sensors in parallel nor can it be used on a telemetry sensor by itself.  The main reason for this is that F.Port was conceptualized when FrSky was big in the FPV community, and people didn't want to have to run S.Bus and S.Port at the same time because of the extra wiring.  Since most of the time any extra sensors would be connected to the flight controller instead, there was no reason to use extra telemetry sensors connected to the receiver itself.  Hence, F.Port can only be used for the one specific purpose of RX->FC connection.

The F.Port protocol runs at 115,200 bits per second, just a bit faster than S.Bus and twice as fast as S.Port, meaning telemetry data gets through faster.  

diagram showing an example way to connect servos and sensors


F.BUS is FrSky's latest, most advanced serial data protocol.  F.BUS actually started out as "F.Port2", but it was very brief before it was modified and renamed to F.BUS.  It is like F.Port in that it carries control data and telemetry data bidirectionally on a single line, however, it differs in several ways.  F.BUS allows the connection of extra telemetry sensors to the same signal line, just like S.Port.  As part of that, F.BUS can be used for not only the receiver to flight controller connection, but also bidirectional signaling for telemetry sensors, servos, ESCs, and more.  Whereas S.Bus only allows you to control S.Bus-compatible servos, with F.BUS you can not only control F.BUS-compatible servos but also receive information from them... things like servo current, temperature, etc, as well as being able to program the servo itself for things like rotate direction, travel range, etc.  FrSky also has a line of F.BUS-compatible ESCs, meaning you can send throttle control to the ESC while simultaneously receiving telemetry info back from it, such as temperature, current, voltage, etc.

The F.BUS protocol runs at 460,800 bits per second, which is four times as fast as S.Bus/F.Port, and EIGHT times as fast as S.Port, meaning both control and telemetry data can be moved around much more quickly.

BLS5400 Series servos are a perfect match To Utilize SBUS or FBUS Protocols

Xact MD5301H 374.9 mini Servo


bottom of page