Jump to content

Phil G's Frame Divider for S-Bus


Bob Cotsford
 Share

Recommended Posts

Phil Green sent me one of his S-Bus frame dividers to try out, so I did.

Essentially it's a device to connect your analogue servo to an S-Bus decoder without worrying whether your servo can cope with the S-Bus high frame rate.

I lost a couple of servos before Chris highlighted the clause in the S-Bus decoder instructions that states that the decoded output is at the same rate as the S-Bus port - which it fails to mention is 9ms - a tad too fast for some analogue servos. How do you know if your analogue servos can cope? Simple, connect them up and wait to see if smoke escapes.

To try Phil's device out I hooked up an S-Bus decoder set to channels 9 to 12, set channels 9 to 12 to 100% switch G, plugged in a servo direct to the decoder and switched on. I tried a variety of Emax, DYS and unbranded micro servos that I had to hand, The first warning is that a servo starts buzzing on switch on. Mine don't do it every time, and it seems that if they initialise ok they work. However the next time you switch on it's a 50-50 chance that instead of initialising and picking up the correct position they will oscillate around a random position. So happy I could reproduce the problem I plugged Phil's pill between the servos and decoder and cycled power until I got bored. No buzzing, just normal servo operation. thumbs up Phil, it looks to be a success

frame divider.jpg

Edited By Bob Cotsford on 21/08/2014 21:20:27

Link to comment
Share on other sites

Nice one Bob - and Phil. I knew it wouldn't take much, I just wish I was clever enough to make the solution.

(I probably could have with a bit of old fashioned TTL or CMOS, but then, that would show just how out of date I am, so I won't mention it). thumbs up

The real solution of course, is for OpenTx to make it selectable in the Tx. But until then, this is a great stopgap.

Link to comment
Share on other sites

Yeap - Phil provided me with a couple of these for my H9 Mustang - thanks Phil. Smashing bit of kit.

It would have been nice, even if they didn't make it switchable, if FrSky had made it a bit more obvious "up front" that there might be a problem with frame times on the S-bus for analogue servos. As folks will know I'm a great fan of FrSky, but they do have their little foibles!

BEB

Link to comment
Share on other sites

  • 2 months later...

Just to bring this up to date, there is now the option of two adapters:

One is used on a per-servo basis - it divides the frame-rate of one PWM servo output. In other words it takes the 8ms frame servo signal from the SBUS decoder, and outputs a 16ms frame to the servo. This is to enable the use of a standard servo on the output of the SBUS decoder. If you wanted to run all four SBUS outputs into conventional servos then you would need four of these, one between each servo and its SBUS servo connector.

The second type plugs between the receiver SBUS port and the SBUS decoder itself, the one adapter affecting all servo outputs. So instead of the SBUS decoder seeing an SBUS data packet repeated every 8ms from the receiver, it sees a 16ms repetition rate and consequently uses this framerate on all its servo outputs, making them all 'analogue-friendly' with just the one adapter.

More HERE and HERE

Cheers
Phil

Link to comment
Share on other sites

  • 4 years later...

I've not been paying attention to developments, so five years on, please can someone in-the-know tell me if this is still a problem or have Frsky made the SBUS framerate switchable? What I'm really asking is, are the servo framerate and SBUS framerate dividers obsolete now?

Ta v much

Phil

Edited By Phil Green on 12/08/2019 23:41:26

Link to comment
Share on other sites

SBUS is still 9mS, and I don't expect it to change. Too many users feed it to a flight controller (e.g. betaflight), and want the 9mS rate to minimise latency.

My own SBUS decoder (on Github), using an Arduino Pro Mini, outputs 16 channels, at an 18mS rate. However, If I see a change on the SBUS 9ms after a pulse has been output, I send another pulse to minimise latency, but then revert to pulses every 18mS for a short while before allowing another pulse to be sent "early".

Mike

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...