Open gsigh opened 2 years ago
Have created a sigrok wiki page for the SBUS (Futaba) protocol decoder. Will update screenshots there as they become available (when captures become available). Several warnings are prepared in the existing implementation: Short messages, excess data after complete messages, invalid UART frames, unexpected header/footer/flags content. The range check for channel values remains an option (an easy thing to add, can be tested usefully when captures become available). https://sigrok.org/wiki/Protocol_decoder:Sbus_futaba
The sigrok decoder for the SBUS (Futaba) protocol has gone mainline, so it's available to you to play around with and explore. Getting real world captures would be very beneficial, to increase coverage, and improve usability of the decoder for you and your users. I have made up most of the boilerplate text, should there be better sources of information then these can get added in followup commits.
This is not an issue as such, but a plea to help me help you. :)
I'm in the process of creating an SBUS protocol decoder for the sigrok.org project. Which lets users inspect wire traffic and analyze at different layers which stack on top of each other. So far one could have sniffed SBUS communication and inspected the raw UART bits, but this quickly gets old. That's when another SBUS decoder would be useful to have, which collects the bits that are spread across several UART frames, and nicely presents the remote control's channels' values to the user, warns about error conditions or suspicious input data, highlights these spots and lets users navigate faster to the location of interest.
The current work in progress is operational but has never seen real world traffic. Have used synthetic data during development. Your project's notes on the protocol helped a lot in understanding its operation. The inter-message period of idle level is missing though, without that synchronization of an observer to a capture that starts at an arbitrary point in time would be difficult.
The current implementation is out of tree, sits on my disk right now. To complete it and bring it into sigrok mainline so that it's available to all users, some information is required, most of it just boilerplate but important nevertheless.
The questions are: Is there some "official" documentation that one can reference? For starters I could point to your https://github.com/uzh-rpg/rpg_quadrotor_control/wiki/SBUS-Protocol notes. What's the official name of the protocol and how to pronounce/write it? There is the potential for confusion with the SPARC computer bus system that's also called S-Bus and is seen as SBus and other writings. That's why the working title of the decoder is "sbus-futaba". What would be good short and long names and a description, so that users can recognize the protocol and tell it from other protocols.
For your reference this is the implementation of another decoder and the properties which a decoder announces, to get presented to users: http://sigrok.org/gitweb/?p=libsigrokdecode.git;a=blob;f=decoders/ieee488/pd.py;h=b0948a685b40bdf08999a98179c57be3264208b8;hb=HEAD#l257 By tradition the init.py next to the pd.py also has some information. Anything that helps users use the decoder, or learn about the protocol.
Another way to help is to create captures. A cheap 10 Euro logic analyzer will do for your kind of traffic (100kbps, typically sampled at a few MHz). The project keeps example captures for several reasons: Make data available to users who don't have the hardware to capture these, or the setups to create this traffic. To see and learn, to experiment and play. And also to run regression tests on decoder implementations. It would be nice if you could get some (preferrably short) captures that showcase typical features of the protocol, including exceptional conditions perhaps that you want a decoder to help you analyze in useful ways. See the sigrok-dumps repository, these captures typically come with a README, again to help interested users as well as developers.
When I find a way to attach images to this report then I could wet your appetite with screenshots from the current decoder implementation. Until then these have to do: https://i.imgur.com/Uwuiycc.png (one message, bird's view) and https://i.imgur.com/QXFV1PE.png (zommed into channel values and individual UART bits).