第4章遥测数据结构

4. 遥测数据结构：源包格式、传输帧格式、虚拟信道概念

好，咱们今天聊点硬核的。遥测数据怎么从卫星上下来？不是一股脑儿往下倒，而是有严格的包装层次。我当年第一次看CCSDS协议栈时，说实话，头有点大。但后来发现，搞懂了源包、传输帧和虚拟信道这三层，整个遥测链路就清晰了。

源包是什么？说白了，就是卫星上某个设备产生的一包数据。比如温度传感器采集的温度值，打包成一个源包发下来。

我个人习惯把源包想象成一个信封。信封外面写地址，里面装内容。CCSDS源包的结构也是这样：

| 包主头(6字节) | 包数据域(可变长度) | 包差错控制(可选,2字节) |

包主头里最重要的几个字段：

关键点：APID是区分不同数据源的核心。我见过不少新手把APID和虚拟信道搞混，记住——APID标识“谁产生的数据”，虚拟信道标识“数据走哪条路”。

源包长度可变，但最大不超过65536字节。实际项目中，我建议源包长度控制在256字节以内。为什么？因为传输帧长度有限，源包太长会导致分包重组，增加复杂度。

源包打包好了，怎么往下传？这就轮到传输帧出场了。传输帧是物理层传输的基本单位，相当于把多个源包装进一个集装箱里往下扔。

CCSDS传输帧格式：

| 帧主头(6字节) | 帧数据域(可变) | 帧差错控制(4字节,可选) |

帧主头里这些字段你得记住：

我的经验：帧计数是判断丢帧的关键。我曾经排查过一个遥测丢数问题，就是发现帧计数跳变——从0x3A直接跳到0x3C，中间少了0x3B。嗯，那帧数据丢了。

传输帧长度通常是固定的。常见的帧长有223字节、1115字节等。固定帧长的好处是接收端好处理，不用猜帧边界。

虚拟信道这个概念，我刚开始学的时候觉得挺玄乎。说白了，就是在一根物理天线上，分出多条逻辑通道。每条虚拟信道独立传输数据，互不干扰。

你想想看，卫星上同时有遥测数据、科学数据、工程数据，这些数据重要性不同。遥测数据丢了可能影响卫星安全，科学数据丢了顶多少发篇论文。如果混在一起传，万一信道拥堵，重要数据可能被挤掉。

虚拟信道解决了这个问题：

每个虚拟信道有自己的帧计数、自己的缓冲区、自己的调度策略。物理层按优先级轮询各虚拟信道，取出帧发送。

注意：虚拟信道不是物理隔离，而是时分复用。我曾经遇到过一个坑——某个虚拟信道一直发大包，占用了太多带宽，导致其他虚拟信道的数据延迟。后来加了带宽限制，每个虚拟信道最多占用50%的物理带宽，问题才解决。

源包、传输帧、虚拟信道这三层怎么配合？我画个流程你就明白了：

接收端反向操作：收到传输帧→解析帧头→提取数据域→拆出源包→根据APID分发到对应应用。

这里有个细节：一个传输帧可以装多个源包，也可以只装一个源包的一部分。如果源包太大，需要跨帧传输。CCSDS用“分组标志”和“源包序号”来标识分包关系。

避坑指南：我曾经遇到一个分包重组的问题。某个源包被分成3帧传输，但第2帧丢了。接收端一直等第2帧，导致第3帧也处理不了。后来加了超时机制——如果3秒内没收到完整包，就丢弃已收到的部分，并上报丢包事件。

说了这么多理论，来点实际的。如果你正在设计星载计算机的遥测协议，我建议：

嗯，遥测数据结构这块就讲这么多。下一章咱们聊聊遥控协议，那又是另一番天地了。