3. 遥控器信号解析：PWM信号基础，SBUS协议简介，CRSF协议简介，信号丢失检测
各位同学，今天我们来聊聊遥控器信号。这玩意儿是飞控系统的“耳朵”，要是听错了或者听不见了，飞机可就真成“断了线的风筝”了。我个人习惯把遥控器信号解析比作“翻译官”——把遥控器那边的手势（摇杆动作）翻译成飞控能懂的指令。翻译错了，后果很严重。
3.1 PWM信号基础：最老实的“方波”
PWM，全称脉冲宽度调制。说白了，就是靠一个方波的高电平持续时间来传递信息。你想想看，一个周期内，高电平占的时间越长，代表的值就越大。
标准PWM信号长这样：
- 频率：50Hz（周期20ms）
- 高电平脉宽：1ms ~ 2ms
- 对应值：1000 ~ 2000（微秒）
举个例子，油门摇杆推到最低，脉宽是1ms，飞控读到1000；推到最高，脉宽是2ms，飞控读到2000。中间位置就是1.5ms，对应1500。
核心要点：PWM信号是模拟时代的产物，简单可靠，但效率低。一个通道就需要一根信号线，8通道就要8根线。这在现代飞控上简直是灾难——接口根本不够用。
我在项目中遇到过一个问题：用PWM直连飞控时，线束太长导致信号衰减，飞控读到的脉宽总是偏小。后来换了屏蔽线才解决。嗯，这里要注意，PWM对线材质量其实挺敏感的。
3.2 SBUS协议简介：串行化的“省线方案”
为了解决PWM线太多的问题，Futaba搞出了SBUS协议。它只用一根信号线，就能传16个通道的数据。怎么做到的？说白了，就是把所有通道的数据打包成一个串行数据包，通过UART接口发送。
SBUS协议特点：
- 物理层：反相UART，波特率100000bps
- 数据格式：8位数据位，2位停止位，偶校验
- 每帧25字节：1字节起始 + 22字节数据 + 1字节标志 + 1字节结束
- 每帧传输16个通道，每个通道11位精度
你想想看，16个通道挤在一根线上，每11毫秒刷新一次。这效率比PWM高太多了。我个人习惯在飞控代码里这样解析SBUS：
// SBUS数据包解析示例（简化版）
void sbus_parse(uint8_t *frame, uint16_t *channels) {
// 检查帧头帧尾
if (frame[0] != 0x0F || frame[24] != 0x00) {
return; // 帧格式错误
}
// 提取16个通道数据（每个通道11位）
channels[0] = ((frame[1] | frame[2] << 8) & 0x07FF);
channels[1] = ((frame[2] >> 3 | frame[3] << 5) & 0x07FF);
// ... 以此类推提取所有通道
// 检查标志位（第23字节）
uint8_t flags = frame[22];
if (flags & 0x04) {
// 信号丢失标志置位
sbus_signal_lost = 1;
}
}
避坑指南：我曾经在SBUS解析上栽过跟头——忘记处理反相逻辑。SBUS信号在硬件上是反相的，如果直接用普通UART接收，读出来的数据全是错的。解决办法是在UART外设上配置反相接收，或者在软件里手动取反。
3.3 CRSF协议简介：穿越机的“高速通道”
CRSF是Crossfire（现在叫ELRS）用的协议。这玩意儿比SBUS还猛——它不光传遥控通道数据，还能传遥测数据，而且是双向的。说白了，遥控器能发指令给飞控，飞控也能把电池电压、GPS坐标等信息传回遥控器。
CRSF协议特点：
- 物理层：标准UART，波特率420000bps（高速）
- 帧结构：地址 + 长度 + 类型 + 数据 + CRC
- 支持RC通道、遥测、设备信息等多种数据包类型
- 延迟极低，约3-5ms（SBUS约11ms）
我个人觉得CRSF最大的优势是延迟低。穿越机飞手对延迟极其敏感，CRSF的3ms延迟和SBUS的11ms延迟，手感上差别很明显。你想想看，同样的动作，CRSF比SBUS早8ms响应，这在高速飞行中可能就是撞墙和擦墙而过的区别。
注意：CRSF协议是开源的，但不同版本的接收机可能有细微差异。我建议在解析时一定要校验CRC，否则收到错误数据包可能导致飞控误动作。我曾经遇到过接收机固件版本不匹配，CRC校验一直失败，排查了半天才发现是固件没升级。
3.4 信号丢失检测：最后的“安全绳”
信号丢失检测，说白了就是判断遥控器是不是“掉线”了。飞控必须能快速、准确地检测到信号丢失，然后触发失控保护（Failsafe）。
常见的检测方法：
| 检测方法 | 原理 | 优缺点 |
|---|---|---|
| 超时检测 | 超过一定时间没收到新数据帧 | 简单可靠，但延迟取决于超时时间设置 |
| 帧标志位检测 | 协议自带信号丢失标志（如SBUS的bit4） | 响应快，但依赖协议实现 |
| CRC校验失败计数 | 连续多次CRC校验失败判定为信号丢失 | 抗干扰能力强，但实现复杂 |
我个人习惯用“超时检测 + 帧标志位”双重保险。超时时间一般设为200ms——太短容易误判（比如信号瞬间遮挡），太长又反应太慢。200ms是个折中值，既不会因为短暂遮挡就触发失控，也不会让飞机在失控后飞出去太远。
核心逻辑：信号丢失后，飞控必须立即切换到失控保护模式。常见的做法是保持最后有效值、缓慢回中、或者直接执行预设的返航/降落动作。我个人强烈建议使用“预设动作”——比如直接切到返航模式。因为保持最后值可能导致飞机一直朝一个方向飞，直到撞上什么东西。
我曾经遇到过一个问题：某款接收机在信号弱的时候会输出“假数据”——数据帧格式正确，但通道值乱跳。CRC校验也通过了，但飞控就是会莫名其妙地抖动。后来我加了一个“通道值变化率限制”——如果某个通道在10ms内变化超过500个单位，就判定为异常数据，直接丢弃。这才彻底解决了问题。
小技巧：在飞控代码里，我建议把信号丢失检测放在最高优先级的中断里。因为一旦信号丢失，你需要尽快响应。放在主循环里的话，如果主循环被其他任务卡住了，信号丢失检测就会延迟，后果可能是炸机。
好了，关于遥控器信号解析，我们就聊到这里。PWM是基础，SBUS是主流，CRSF是趋势。信号丢失检测是最后一道防线，一定要重视。下次调试飞控时，不妨先看看遥控器信号解析这部分代码——很多时候问题就出在这里。