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

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?

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!

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

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

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

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!

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

thanx all for nice explanation

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

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

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?