3. 遥测遥控协议标准：CCSDS标准、分包遥测、分包遥控

好，咱们今天聊聊遥测遥控协议标准。说实话，刚入行那会儿，我总觉得协议这东西就是一堆文档，背下来就行了。后来在项目中吃过亏才明白——协议是航天器的“语言”，语言不通，卫星就跟你“装死”。

这一章，我重点讲三个核心概念：CCSDS标准、分包遥测和分包遥控。你想想看，没有标准会怎样？每个卫星厂家各搞一套，地面站得配几十种解调器，那不乱套了？

3.1 CCSDS标准：航天通信的“通用语言”

CCSDS，全称是“空间数据系统咨询委员会”。说白了，就是一群航天大国坐在一起，定了一套大家都认的通信规矩。我参与的第一个星载项目，用的就是CCSDS标准。当时觉得“国际标准”肯定很复杂，结果一看，其实核心思想就四个字：分层、分包。

CCSDS标准体系里，跟我们嵌入式工程师最相关的是这几层：

• 物理层：定义射频、调制方式。比如我常用的OQPSK调制。
• 数据链路层：定义帧结构、同步、纠错。这是咱们写驱动时最常打交道的。
• 网络层：定义数据包的路由。多星组网时特别重要。
• 应用层：定义遥测遥控数据的格式。分包遥测、分包遥控就在这层。

我记得有一次，团队里新来的同事问我：“CCSDS标准里那么多选项，我到底该用哪个？”我的回答是：先看你的任务需求。是低轨还是深空？数据率多大？星上存储多大？这些决定了你选哪个子集。

3.2 分包遥测：把数据“打包”送下来

分包遥测，英文叫Packet Telemetry。它的核心思想是：把星上各种数据（温度、电压、姿态、载荷数据）都装进统一格式的“小包裹”里，然后按顺序发下来。

你可能会问：“为什么不直接发原始数据？”嗯，这个问题我当年也问过。原因很简单：原始数据没有“身份信息”。地面收到一串0101，根本不知道哪个字节是温度，哪个是电压。分包遥测就是在数据前面加了个“快递单”——告诉你这里面装的是什么。

分包遥测的数据结构，我习惯用这个表格来记：

字段	长度（位）	说明
包主导头	48	包含版本号、包类型、APID、序列标志等
包副导头	0~64	可选，用于时间戳、源数据等
用户数据域	可变	真正的遥测数据，比如温度值、电压值
包差错控制	16	CRC校验，防止数据传错

这里有个关键点：APID（应用过程标识）。每个遥测参数都有一个唯一的APID。地面站看到APID，就知道该用哪个解析函数。我在项目中遇到过一个问题：两个传感器不小心配了同一个APID，结果地面收到的温度数据被当成了电压值，差点把整星判了死刑。从那以后，我每次写配置表都要反复核对APID。

3.3 分包遥控：给卫星下指令的正确姿势

分包遥控（Packet Telecommand）跟遥测正好相反——它是地面发给卫星的指令。结构上跟遥测包类似，但多了个指令验证机制。

为什么需要验证？你想想看，地面发一条“关闭太阳翼”的指令，如果因为干扰传错了，卫星真把太阳翼关了，那可就出大事了。所以分包遥控协议里，有个“回令-确认”机制。

分包遥控的包结构大致如下：

| 包主导头 (48位) | 副导头 (可选) | 指令数据域 | 包差错控制 (16位) |

其中指令数据域里，通常包含：

• 指令码：比如0x01代表“开机”，0x02代表“关机”
• 执行参数：比如“开机持续10秒”
• 校验字：防止指令被篡改

我曾经踩过一个坑：某次测试，地面连续发了三条“复位”指令，星上只收到了两条。查了半天，发现是遥控包里的序列号没处理好。分包遥控协议要求每个包都有唯一的序列号，地面和星上都维护一个计数器。如果星上收到的序列号不连续，说明有丢包，应该要求重发。我当时没做这个检查，结果漏了一条指令。

3.4 实际项目中的经验总结

说了这么多，我总结几条实战经验：

1. 协议裁剪要谨慎：CCSDS标准很庞大，小卫星可以只实现子集。但裁剪前一定要想清楚：未来会不会需要扩展？我见过一个项目，为了省代码量，把副导头砍了，结果后来要加时间戳，只能改版。
2. 测试要覆盖边界：比如遥测包的最大长度、遥控包的最小长度、APID为0的情况。这些边界条件最容易出bug。
3. 日志要详细：星上软件一定要记录每个收发包的原始数据。出了问题，靠的就是这些日志。我习惯在日志里同时打印十六进制数据和解析后的字段值。
4. 地面和星上要同步：协议版本号、APID分配表、指令码定义，这些必须地面和星上完全一致。我建议用同一个配置文件生成两边的代码，避免手写不一致。

嗯，这一章的内容就这些。分包遥测和分包遥控，说白了就是给数据加了个“信封”。信封上写清楚“谁发的、发给谁、里面是什么”。你只要把这个逻辑理清了，写代码就是体力活了。

下一章，我会讲具体的编码实现——怎么在RTOS里写一个分包遥测的发送任务。到时候咱们手撕代码，敬请期待。