|2 pages [ << < 1 ( 2 ) > >> ] 3082 views||POST REPLY|
It seems incredible that Futaba does not know to perfection its proprietary protocols S.Bus and S.Bus2 and yet... There are various hypotheses: perhaps, being proprietary and not public, they have never well documented it and when they contracted out the realization of the CGY750, they were not able to give documentation to the developer of the CGY750? Or the CGY750 uses a processor so little powerful that it cannot handle the data flow S.Bus2 that is continuous (the fact that CGY750 is used by pilots who make slow F3C flights and very few pilots make fast 3D flight could be the proof). But they're all just hypotheses and there's nothing for sure. I don't have any contact in Futaba to find out. Unlike all the other companies in the industry (even those that have and sell Flybarless units such as Spektrum, Graupner and Jeti) Futaba never even had the courtesy to respond to my email request for collaboration. As a result, I never signed an NDA with Futaba.To make simple: S.Bus2 transmits the same data transmitted by the S.Bus bus but between a channel frame and the next channel frame, it inserts in 8 slots, telemetric frames for a total of 32 slots. Then, after 4 channel frames, it starts again from the first slot.If the control unit is not able to recognize, distinguish and separate the telemetric data from the data of the radio channels, it risks using the telemetric data as radio channels or synchronizing on the telemetric frames instead of on the frames of the radio channels and even if it discards them as invalid, it loses many valid data and risks going into fail safe mode.The old Brain1/iKon1 control units, unlike Futaba, have always recognized and distinguished the channel data from telemetric data correctly even if they are not able to process also the telemetric data. Only the most powerful Brain2/iKon2 can also not only perform continuous processing of the flow of both types of frames but also to send and transmit to the ground the telemetric data received from other devices (such as ESCs) and also to record telemetric data in to the internal flight log memory for successive graphical analysis.However, the old CGY750 control units have long been out of production and no longer in the catalogue. It would be interesting to understand if the new CGY760 controllers have a more powerful processor and are now able, if not to process the telemetric data frames, at least to recognize and distinguish them from the channel data frames.
wjvail So this thread is now a couple of years old and I still don't have my head 100% around what can and cannot be plugged into the SBus2 port.I recently got off the phone with the people from iKon. I have been flying my Align 700XN with my iKon HD BT plugged into the SBus port of the installed R7008SB receiver. Life has been good.Things got more interesting when I set out to add temperature telemetry from the model. IKon suggested I plug the iKon unit into the SBus2 port on the 7008 and include a y-harness to allow me to also plug the Futaba SBS-01T temp sensor into the same SBus2 port. By doing so I will not only get telemetry real-time from the model to the TX, but the iKon will also log the temperature for future review. Apparently there is enough intelligence in the FBL unit to decode the digital information coming into the iKon via the Serial Bus 2 protocol for it to decipher what is control information (TX commands, switch positions, etc) and what is telemetry data.This is how I now have the model set up. The iKon is plugged into the SBus2 port on the RX. Not only does that go against how the Futaba 750 is to be installed, but it confuses me on what are the differences between SBus and SBus2.Futaba's words are:
So as I understand it, the 750 gyro was not compatible with bi-direction information from the SBus2 port. Attempting to do so would/could cause the 750 to reset. In contrast, the iKon is capable of bi-directional communication and by plugging both my temp probe and FBL unit into the SBus2 port, digital data from the temp probe is sent to both the FBL controller and receiver.Are there other things I need to know about SBus2? Is data processed at the same rate on both SBus and SBus2? Was I wrong to initially plug the iKon into the SBus port instead of the SBus2 port? What other none-sensor devices might I plug into the SBus2 port? What might be gained by plugging a SBus2 comparable servo into the SBus2 port? I suppose information such as current draw could be both broadcast back to the TX and recorded by the FBL unit?Sorry for a long and rambling post. I'm just trying to get my head around what SBus2 is and what it can do for me.
S.BUS2 extends S.BUS and supports bidirectional communication.
Sensors are connected to the S.BUS2 port.
*Only S.Bus2 capable devices may be connected to the S.Bus2 port.
Standard S.Bus servos and gyros should not be connected to the S.Bus2
|SHARE PM EMAIL HOMEPAGE GALLERY Attn:RR Quote|
What a wonderful post. It has taken me a little while to digest all you posted and I meant to write back sooner. While I still have questions about S.Bus2 I have a much clearer picture what I'm doing. Dr. Ben started this thread to simply say the older CGY was incomparable with the newer S.Bus2 port. It has morphed into a larger discussion of S.Bus2 - and that really valuable.With a better understanding of S.Bus2 I'm pretty excited about what is possible. Why did this take so long to become clear(er)?
|SHARE PM EMAIL GALLERY Attn:RR Quote|
|2 pages [ << < 1 ( 2 ) > >> ] 3082 views||POST REPLY|
|Print TOPIC||Make Suggestion|