第1章 SBUS协议概述

1. SBUS协议概述：什么是SBUS、SBUS的历史与起源、SBUS在无人机领域的地位

SBUS，全称Serial Bus，说白了就是遥控器和飞控之间的一种串行通信协议。它由Futaba公司开发，专门用来传输遥控通道数据。

我刚开始接触SBUS时，第一反应是：这不就是个串口协议吗？嗯，确实底层是串口，但它有自己的帧结构。一个SBUS数据包能携带16个标准通道和2个数字通道，总共18个通道的信息。

它的物理层是反向串口，波特率100kbps，8位数据位，2位停止位，偶校验。这个配置在遥控领域很常见，但有个坑——信号是反相的。我记得第一次用示波器抓SBUS波形时，怎么都对不上，后来才发现需要加反相器。

核心特点：

SBUS最早出现在Futaba的遥控器上，大概是2010年左右。那时候主流遥控协议还是PWM和PPM。PWM每个通道需要一根线，8通道就要8根线，飞控上密密麻麻的排针，看着就头疼。

PPM虽然能一根线传8个通道，但精度和稳定性都不太理想。我在一个早期项目中用过PPM，信号抖动问题折腾了我整整一周。后来换成SBUS，问题迎刃而解。

Futaba推出SBUS的初衷很简单：用更少的线，传更多的通道，而且要有更高的可靠性。他们借鉴了工业串行总线的思路，但做了针对遥控场景的优化。

为什么会选择100kbps这个波特率？你想想看，16个通道，每个通道11位精度，加上同步头、标志位、校验位，算下来刚好25字节。100kbps下传输25字节大约2ms，留1ms余量，正好满足200Hz的刷新率。这个设计很巧妙，对吧？

个人经验： 我在做开源飞控时，发现很多SBUS接收机其实兼容性有差异。有些接收机输出的SBUS信号电平是3.3V，有些是5V。最好加个电平转换，别直接怼到飞控的IO口上。

现在SBUS已经是无人机遥控的事实标准了。几乎所有的飞控——Pixhawk、ArduPilot、Betaflight、iNav——都原生支持SBUS。你随便买个遥控接收机，十有八九都带SBUS输出。

它的地位为什么这么稳固？说白了就三点：

我记得有一次给客户做工业无人机，他们要求16通道全用上。如果用PWM，飞控上得接16根线，布线难度直接翻倍。换成SBUS，一根线搞定，客户看了直呼专业。

注意： SBUS虽然叫总线，但它不是像CAN那样的多主总线。它是典型的单主多从结构，遥控器是主，接收机是从。别想着用SBUS做双向高速数据传输，那不是它的设计目标。

来看一下SBUS的数据帧长什么样。每个帧25字节，结构如下：

字节0: 起始字节 0x0F
字节1-22: 16个通道数据，每个通道11位
字节23: 
  bit0: 通道17（数字通道）
  bit1: 通道18（数字通道）
  bit4: 帧丢失标志
  bit5: 安全保护标志
字节24: 结束字节 0x00

这个结构很紧凑。16个通道，每个11位，总共176位，刚好22字节。加上头尾和标志位，正好25字节。Futaba的工程师在协议设计上确实下了功夫。

我在解析SBUS时踩过一个坑：通道数据是低位在前，高位在后。如果你按大端序去解析，出来的数据全是乱的。后来看了Futaba的官方文档才明白，人家用的是小端序。

从表格能看出来，SBUS在通道数和延迟上都有明显优势。CRSF虽然延迟更低，但那是ExpressLRS的私有协议，生态不如SBUS成熟。

避坑指南： 我曾经在SBUS和CRSF之间纠结了很久。如果你做的是消费级无人机，SBUS完全够用。如果是竞速机或者远航机，可以考虑CRSF。但说实话，对大多数项目来说，SBUS是最稳妥的选择。

ArduPilot对SBUS的支持非常完善。在硬件上，它使用UART接口，通过一个反相器来接收SBUS信号。软件上，有专门的SBUS解析器，在AP_HAL库中实现。

我建议你在学习SBUS时，直接看ArduPilot的源码。它的实现很规范，注释也很详细。特别是AP_RCProtocol_SBUS.cpp这个文件，把SBUS的解析逻辑写得清清楚楚。

嗯，这里要注意：ArduPilot的SBUS解析器默认只支持16个标准通道。如果你需要用到那两个数字通道，得自己改代码。我在做农业无人机时，就用那两个数字通道来传输喷洒开关状态，效果很好。

总结一下：

这张图把SBUS的知识体系梳理清楚了。从协议基础到数据帧结构，再到实际应用场景，层层递进。你学SBUS时，就按这个脉络来，不会乱。

好了，这一章就到这里。SBUS协议看似简单，但里面细节不少。下一章我们会深入解析SBUS的数据帧，手把手教你如何用代码解析SBUS信号。

公众号:蓝海资料掘金营，微信deep3321