Futaba S.Bus R/C Feature
Posted 08 June 2010 - 03:48 PM
What I am thinking is that the flight stabilization system designers could clean up a lot of wiring by adopting the protocol. For example, just take a look at the OSD's that have RTH. The rats nest clutter could be reduced a lot with a serial R/C buss. Just a thought...
Posted 08 June 2010 - 11:12 PM
BUT, it's going completely against the logic used in these models, i.e adding as much redundancy as possible, dual power supplies, dual receivers, 2 servos per control surface each with their own wire... and there, what you're essentially doing is grouping a whole set of controls on a single wire/plug... not making people very confident.
But yes, for FPV, probably might be interesting... except that this would obviously tie down to using Futaba S-bus servos, which at the moment means scarce, few size choices, expensive... Futaba are known to keep their protocols tight too, even the now old PCM1024 hasn't been reverse engineered AFAIK...
Posted 09 June 2010 - 08:27 AM
From a failure statistics point of view, less wiring/connectors can offer higher reliability. Not that I know for sure, but it looks to me like you could still maintain a redundant servo installation with it. And for the Jet crowd, the cost of a proprietary servo is not an issue that shows up on their radar. But even so, they can still use standard servos with the S.Bus (Futaba has a app for that). Hmm, I should work for Futaba marketing.
and there, what you're essentially doing is grouping a whole set of controls on a single wire/plug... not making people very confident.
Here is where I am going with this: Just imagine hacking your favorite Rx with a DiY PPM-to-S.Bus interface. Connections to S.Bus enabled OSD/RTH/stability hardware and servos would be free of the typical rats nest mess. A nice organized FPV installation gives the S.Bus concept a reason to be noticed. It will be interesting to see how the bussed servo method plays out over the next few years.
Posted 10 June 2010 - 03:11 PM
Yep, this is the only advantage I would find it for FPV, to clean installations where devices must be connected between RX and multiple servos. But a typical FPV plane has only one servo per wing, so not much to save with a bus, all the servos that are in the fuselage are already close enough to the receiver to connect straight to it, actually having to add "hubs" would only create more mess... there would maybe just be one wire to save to go to the tail if the tail servos are mounted in the back...
Connections to S.Bus enabled OSD/RTH/stability hardware and servos would be free of the typical rats nest mess. A nice organized FPV installation gives the S.Bus concept a reason to be noticed.
You're surprising me there. Let's do a little challenge... You have 5 minutes to think of a solution that is open, is based on long existing equipment, and requires less than 2 hours "development" to do exactly the same as the S-bus.
if the Chinese copy it
Edited by Kilrah, 10 June 2010 - 03:11 PM.
Posted 10 June 2010 - 04:26 PM
But there are interconnections between OSD's, Rxs, 6DOF/IR thermopile stability, and so on. If you look at the typical rats nest in a FPV, a lot of cables are bouncing around between those things. Of course a OSD maker could build it all onto one board (EagleTree is doing this), but I've noticed that all-in-one solutions are rarely implemented to please everyone. So, I think that we will still see a some messy installations because the gadgets are separate.
But a typical FPV plane has only one servo per wing, so not much to save with a bus, ...
You have 5 minutes to think of a solution that is open, is based on long existing equipment, and requires less than 2 hours "development" to do exactly the same as the S-bus.
I was expecting you to bring that up. Yes, there are many existing buss standards out there we can use instead: I2C, SPI, Can, etc. And as you no doubt already know, some of these are being used in FPV OSD products. Plus, the MK is in effect using a primitive serial data method in their convenient PPM stream decoding (eliminates a lot of cables to the Rx).
But I am expecting that the S. Bus will have the advantage in that there will be a growing number of ready-to-use R/C products that we can plug together. So we won't have to make everything ourselves.
Posted 10 June 2010 - 10:46 PM
Already too complicated!
Yes, there are many existing buss standards out there we can use instead: I2C, SPI, Can, etc.
The goal is to have a multiplexed signal that can be sent to all servos... but the 30 year old PPM is nothing else. Just take a receiver wth PPM out, send that down the bus with the same kind of wiring as s-bus, then use OpenServo electronics to which you add a few lines of code to implement the PPM decoder/channel selector, make a little separate decoder board "adapter for normal servos" just like Futaba with a well-known 8pin PIC... and there you are, you have the same functionality that was there for everybody to use for "ever"
Posted 11 June 2010 - 08:07 AM
But we seem to be a dying breed; for the 99% of the other folks that have no interest in DiY, an off-the-shelf solution like S.bus (or whatever flavor of R/C serial buss that may become popular) would have more mass appeal (than DiY). But, if the overall attitude in the R/C market is negative, then the R/C buss concept will certainly fade away. I guess we need to return back to this thread in 3-5 years to post how we feel about it then.
Perhaps you can relate to this (you have a similar background): As a long time DiY guy I like building stuff. But, as a sales guy that also does a LOT of tech support on FPV related products, I believe that the market needs a R/C FPV wiring scheme that helps make things clean and simple. So, the S.Bus gets my attention as a possible white horse.