Difference between revisions of "Protocol decoder:Sbus futaba"
Jump to navigation
Jump to search
(mention sbus vs sbus (remote control vs computer bus)) |
(mention bytes and bits layout in frames, ask for captures) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Infobox protocol decoder | {{Infobox protocol decoder | ||
| id = sbus_futaba | | id = sbus_futaba | ||
| name = | | name = Futaba SBUS (Serial bus) | ||
| description = | | description = Serial bus for hobby remote control by Futaba | ||
| status = | | status = supported | ||
| license = GPLv2+ | | license = GPLv2+ | ||
| source_code_dir = sbus_futaba | | source_code_dir = sbus_futaba | ||
| image = [[File:Pd-sbus_futaba-message.png|250px]] | | image = [[File:Pd-sbus_futaba-message.png|250px]] | ||
| input = uart | | input = uart | ||
| output = | | output = sbus_futaba | ||
| options = | | options = min/max value for proportional channels | ||
}} | }} | ||
The '''sbus_futaba''' protocol decoder can decode SBUS ("Serial bus") communication as it is seen in hobby remote control by the Futaba vendor. Which is not to be confused with the SPARC computer bus system which is also referred to as S-Bus. | The '''sbus_futaba''' protocol decoder can decode SBUS ("Serial bus") communication as it is seen in hobby remote control by the Futaba vendor. Which is not to be confused with the SPARC computer bus system which is also referred to as S-Bus. | ||
The protocol runs on top of UART communication | The protocol runs on top of UART communication. Typical parameters are 100kbps, 8e2 frame format, inverted (high voltage level is logic low). | ||
SBUS messages consist of 25 UART bytes | SBUS messages consist of 25 UART bytes. A message provides 16 proportional channels of 11 bits each, 2 digital channels of 1 bit each, and two flags (frame lost, failsafe). Applications may communicate values between 192 and 1792 on the wire, and map these to values 1000 to 2000 for their firmware purposes. Some implementations happen to use different value ranges. | ||
SBUS messages take 3ms to communicate. | SBUS messages take 3ms to communicate. Typical repeat intervals are: 14ms (analog mode), 7ms (high speed mode). | ||
A frame has the following layout: | |||
* Data is always sent with the LSB first. | |||
* Inter-frame gaps allow to synchronize, data content is not sufficient for synchronization (the same fixed patterns can also occur in other data fields). | |||
* Header byte, always 0x0f. | |||
* 16 channels with 11 bits each, dense packing. Results in 22 bytes length. | |||
* Flags byte. Upper nibble always 0. Lower nibble carries: failsafe, frame lost, channel 18, channel 17. | |||
* Footer byte, always 0x00. | |||
The sigrok decoder was developed based on exernal documentation (see [[#References]] below) and synthetic data. Real world captures have yet to become available. | |||
== Example interactive use == | == Example interactive use == | ||
| Line 29: | Line 39: | ||
</gallery> | </gallery> | ||
TODO Add illustrations of error conditions: Short messages. Excess data after complete messages. Invalid header and footer values. UART frame errors. Value range violations (when the decoder grows support for them). | TODO Add illustrations of error conditions: Short messages. Excess data after complete messages. Invalid header and footer values. UART frame errors. Value range violations (when the decoder grows support for them, and when captures become available). | ||
== Example command line use == | == Example command line use == | ||
TODO This section is work in progress. Finish these notes. Provide the command's output. | TODO This section is work in progress. Finish these notes. Provide the command's output. When captures become available. | ||
<small> | <small> | ||
| Line 43: | Line 53: | ||
== References == | == References == | ||
* [https://github.com/uzh-rpg/rpg_quadrotor_control/wiki/SBUS-Protocol RPG Quadrotor Control wiki] has a very good description of the SBUS protocol, concise and complete, easy to grasp | * the [https://github.com/uzh-rpg/rpg_quadrotor_control/wiki/SBUS-Protocol RPG Quadrotor Control wiki] has a very good description of the SBUS protocol, concise and complete (except for idle between messages), easy to grasp | ||
* this [https://blog.katastros.com/a?ID=01000-4a28701c-2e84-4f1c-ad0b-9b749c0d1ca0 blog] mentions inter-message idle phases and message repeat intervals, refers to proportional and digital channels, references the [https://os.mbed.com/users/Digixx/notebook/futaba-s-bus-controlled-by-mbed/ Futaba S-BUS controlled by mbed] article by Uwe Gartmann | |||
* the [https://www.futabarc.com/sbus/index.html vendor page(?)] kept failing to load when this wiki page was written | |||
[[Category:Protocol decoder]] | [[Category:Protocol decoder]] | ||
[[Category:Supported]] | |||
Latest revision as of 07:53, 18 September 2022
 | |
| Name | Futaba SBUS (Serial bus) |
|---|---|
| Description | Serial bus for hobby remote control by Futaba |
| Status | supported |
| License | GPLv2+ |
| Source code | decoders/sbus_futaba |
| Input | uart |
| Output | sbus_futaba |
| Options | min/max value for proportional channels |
The sbus_futaba protocol decoder can decode SBUS ("Serial bus") communication as it is seen in hobby remote control by the Futaba vendor. Which is not to be confused with the SPARC computer bus system which is also referred to as S-Bus.
The protocol runs on top of UART communication. Typical parameters are 100kbps, 8e2 frame format, inverted (high voltage level is logic low).
SBUS messages consist of 25 UART bytes. A message provides 16 proportional channels of 11 bits each, 2 digital channels of 1 bit each, and two flags (frame lost, failsafe). Applications may communicate values between 192 and 1792 on the wire, and map these to values 1000 to 2000 for their firmware purposes. Some implementations happen to use different value ranges.
SBUS messages take 3ms to communicate. Typical repeat intervals are: 14ms (analog mode), 7ms (high speed mode).
A frame has the following layout:
- Data is always sent with the LSB first.
- Inter-frame gaps allow to synchronize, data content is not sufficient for synchronization (the same fixed patterns can also occur in other data fields).
- Header byte, always 0x0f.
- 16 channels with 11 bits each, dense packing. Results in 22 bytes length.
- Flags byte. Upper nibble always 0. Lower nibble carries: failsafe, frame lost, channel 18, channel 17.
- Footer byte, always 0x00.
The sigrok decoder was developed based on exernal documentation (see #References below) and synthetic data. Real world captures have yet to become available.
Example interactive use
These images illustrate the interactive use in the GUI application. The data used in this setup is synthetic.
overview of one message
zoom in on channel values and UART bits
TODO Add illustrations of error conditions: Short messages. Excess data after complete messages. Invalid header and footer values. UART frame errors. Value range violations (when the decoder grows support for them, and when captures become available).
Example command line use
TODO This section is work in progress. Finish these notes. Provide the command's output. When captures become available.
$ INPUT="-i file.bin -I protocoldata:protocol=uart:bitrate=100000:frameformat=8e2"
$ P_UART="uart:baudrate=100000:parity=even"
$ sigrok-cli $INPUT -P ${P_UART},sbus_futaba -A sbus_futaba
References
- the RPG Quadrotor Control wiki has a very good description of the SBUS protocol, concise and complete (except for idle between messages), easy to grasp
- this blog mentions inter-message idle phases and message repeat intervals, refers to proportional and digital channels, references the Futaba S-BUS controlled by mbed article by Uwe Gartmann
- the vendor page(?) kept failing to load when this wiki page was written