Futaba S-BUS controlled by mbed

Introduction

The Futaba S-BUS protocol is a serial protocol to control servos. Up to 16 proportional and two digital channels are available. The protocol is derived from the very known RS232 protocol used everywhere. The signal must be first inverted. The frame is 8E2.

This board provide a complete electrical separation of RC gear and mbed controller. The S-BUS serial signal is converted and isolated by optocoppler. To keep control of the plane/car/ship an additional controller (ATTINY13) is on board. It monitors a standard servo signal (Master) and sends the serial S-BUS signal either to the mbed or directly to the servos. A special 'middle' position sends the S-BUS data to the servos and the mbed. In this mode the mbed can check stick positions and range without sending data to servos. Because the S-BUS data contains the Master signal, mbed knows about this mode.

S-BUS protocol

The protocol is 25 Byte long and is send every 14ms (analog mode) or 7ms (highspeed mode).
One Byte = 1 startbit + 8 databit + 1 paritybit + 2 stopbit (8E2), baudrate = 100'000 bit/s
The highest bit is send first. The logic is inverted (Level High = 1)

[startbyte] [data1] [data2] .... [data22] [flags][endbyte]

startbyte = 11110000b (0xF0)

data 1-22 = [ch1, 11bit][ch2, 11bit] .... [ch16, 11bit] (ch# = 0 bis 2047)
channel 1 uses 8 bits from data1 and 3 bits from data2
channel 2 uses last 5 bits from data2 and 6 bits from data3
etc.

flags = bit7 = ch17 = digital channel (0x80)
bit6 = ch18 = digital channel (0x40)
bit5 = Frame lost, equivalent red LED on receiver (0x20)
bit4 = failsafe activated (0x10)
bit3 = n/a
bit2 = n/a
bit1 = n/a
bit0 = n/a

endbyte = 00000000b

block diagram

coming soon ..

captured S-BUS protocol

www.flightronic.com/uploads/images/futaba_sbus/dataframe.gif

Links

schemata (PDF) /media/uploads/Digixx/sbus_mbed-schemata.pdf
schemata (Eagle V6.1) /media/uploads/Digixx/sbus_mbed.sch
board (Eagle V6.1) /media/uploads/Digixx/sbus_mbed.brd

Version 2

added 3v3 to the XBEE port and renamed it AUX /media/uploads/Digixx/sbus_mbed_v2.brd /media/uploads/Digixx/sbus_mbed_v2.sch

S-BUS Library

SBUS-Library http://mbed.org/users/Digixx/programs/SBUS-Library_16channel/m6i4ue


12 comments on Futaba S-BUS controlled by mbed:

08 Mar 2012

I've written some mbed code for logging data between an R6203SB rx and a CGY750 flybarless controller. I've found that the data rate is actually 98Kbaud, not 100.

Steve

09 Mar 2012

Hi Steve

Just to be sure, I connected a digital analyzer to the S-BUS output of the receiver. It is sending at 100'000 baud, shown here on the start bit. Maybe this vary from receiver to receiver?

/media/uploads/Digixx/s-bus_r6203sb.jpg

25 May 2012

Interesting. There are a number of hints one can use that will tell you if the reception of S.Bus frames is broken. The first byte with be 0x0f and will have been preceded by 4ms of inactivity on the bus. If you're expecting the start of a frame and see any other byte, or if it arrives in less than 4ms, you've missed reception of a byte. Similarly the bytes within a frame shouldn't take anything more than 150us between them, and the last byte should be 0x00, so if any byte other than the first one arrives more than 150us after it's predecessor, or if the last byte in the frame isn't 0x00, again something went wrong. Applying the above I keep track of the number of frames received and the number of aborted frames due to any of the above issues. I am then able to set a baud rate, reset the counters, wait for the reception of a number of frames, check the error counts, change the baud rate and repeat. I did this because I was seeing missed frames at 100Kbaud, and I found that at 97, 98, or 99Kbaud there were no errors, but any higher or lower rate caused issues. I thus settled for the middle setting and haven't dropped a frame since. My first thought was that perhaps the clock on my mbed was out slightly, but if this was the case then I would also expect my PWM monitoring to be out, but I see exactly 1100us intervals measured for Futaba channels at minimum.

Your plot above can't really be refuted, so I'm not sure what could be a cause of the timing inconsistency I see!

08 Nov 2013

Hi, great work! I'm accessing the SBUS data from pin-4 from the T18MZ. I just can't quite figure out how to split the data, as it's much longer as written here. Also I get 0x0f, not 0xf0. /media/uploads/utillity/sbus_pitch0.log

can someone kindly give me a kickstart on this?

thanks!, Tilli

10 Nov 2013

Hi Tilli,

Looking at a hex dump of this I see the following sequence repeated. Ignore the colours; I just used code wrappers to get a fixed font.

0F 00 1C 20 00 01 08 40 00 02 10 80 00 04 20 00 01 08 40 00 02 10 80 00 24 0B 00 00 8B 00 00 4B 00 00 CB 00 00 2B 00 00 AB 00 00 6B 00 00 EB 00 00
0F 00 1C 20 00 01 08 40 00 02 10 80 00 04 20 00 01 08 40 00 02 10 80 00 24 0B 00 00 8B 00 00 4B 00 00 CB 00 00 2B 00 00 AB 00 00 6B 00 00 EB 00 00
0F 00 1C 20 00 01 08 40 00 02 10 80 00 04 20 00 01 08 40 00 02 10 80 00 24 0B 00 00 8B 00 00 4B 00 00 CB 00 00 2B 00 00 AB 00 00 6B 00 00 EB 00 00
0F 00 1C 20 00 01 08 40 00 02 10 80 00 04 20 00 01 08 40 00 02 10 80 00 24 0B 00 00 8B 00 00 4B 00 00 CB 00 00 2B 00 00 AB 00 00 6B 00 00 EB 00 00

That's 49 bytes in total per frame rather than the 25 bytes for normal S.Bus data. The data appears stable, which is a good start!

What mode do you have the Tx set to?

There are two things I suggest trying:

1. Capture a log where you record a us timestamp against each byte. It will be interesting to know if this data is in a single burst or is made up of more than one with a pause between. This may be the case if there is a two way communication going on given that you may be seeing telemetry data.

2. Record a log where you are changing only the value of channel 1, then channel 2 etc. Include all switch channels. You should then be able to easily determine which bytes in the stream are affected by which channel.

Steve

11 Nov 2013

hi Steve,

thanks. not sure what you mean by mode (it's a mode-2 TX, with binding to a FASSTest receiver - running a H1 heli-model-profile).

using the futaba CIU adapter for reading the data - seems it already inverts the bits which saves me some trouble. - so I can't log the us. But a collegue just checked it and said there is a small latency between the 2 packets (sbus and sbus2).

I made multiple recordings with moving only one stick. will work on that to see, if I have to parse the 11 bits myself or not.

thanks for the help!

Tilli

30 Jul 2014

Hi,

I was wondering if you guys could help me out, how do you guys physicaly capture 'packets' from the sbus system? (I'm using futaba R30008SB, NAZA M V2) I want to be able to program with the packets....

thx in advance!

07 May 2015

I am having X-cam gimbal which is working on S.bus protocol. Can anyone help how to make program for it in Atmega32A.

24 Mar 2016

thanx all for nice explanation

27 Mar 2016

Excited to share our processing sketch for real-time graphical representation of the 16 Channel S-BUS Protocol. Project details http://www.robotmaker.eu/ROBOTmaker/quadcopter-3d-proximity-sensing/sbus-graphical-representation

/media/uploads/robotmaker/sbus_protocol_visualisation.jpg

26 Oct 2016

block diagram

coming soon .. (May I have this block diagram if it is ready to upload to have a better understanding)

Also the below link is not available. Kindly check and update the information.

captured S-BUS protocol

www.flightronic.com/uploads/images/futaba_sbus/dataframe.gif

please also suggest me the reference that I can go through, read and understand in a better way.

Thanks a lot

10 Nov 2017

When I try this sketch on my Elegoo Mega2560 R3, and when I have my Sbus RX in to RX0, I cannot upload the sketch, but if that wire is unplugged, it uploads no problem. then when I try and go to the serial monitor, I get all values of -100 regardless of any input I give on my futaba transmitter. Any thoughts?

Please log in to post comments.