’娥五号是中国的月球样本返回任务。它于2020年11月23日从文昌发射升空，估计将于周六进行月球轨道注入。从那以后，许多业余爱好者，例如美国卫星通信公司，保罗·马什·莫伊特，斯科特·蒂利VE7TIL，费·伊沃特·杜伊特等人都从航天器接收X波段信号，并在Twitter上发布报告。同时，r00t.cz一直在解码帧，这使他获得了从信号中检索短视频的惊人成就。
在这篇文章中，我将介绍在执行任务的前两天，美国卫星通信公司和保罗公司解调的一些帧。框架结构与Tianwen-1有很多相似之处，我在这里和这里的几篇文章中都已经描述过。但是，存在一些有趣的差异。
低数据速率遥测信号是PCM / PSK / PM信号，其子载波速率为65536 Hz，波特率为2048波特。编码是Reed-Solomon码字大小为252字节的CCSDS级联帧，因此帧需要2秒钟来传输。 Reed-Solomon代码使用对偶基础，如TM同步和通道编码蓝皮书中所指定。这与Tianwen-1的低速率信号非常相似。唯一的区别是，Tianwen-1使用16384波特的波特率（因此帧需要0.25秒来传输），以及传统的Reed-Solomon基础（不是标准CCSDS）。
娥五号在X波段使用了许多不同的频率。在这里，我将研究美国卫星电视在2020-11-24 UTC的4点到6点之间收到的一些帧。
这些框架是来自航天器ID 91的CCSDS AOS框架。航天器ID非常相关，因为航天器具有不同的可拆卸模块：服务模块，返回模块，着陆器和上升模块。这些模块中的每个模块很可能使用不同的航天器ID，实际上我们看到的是来自不同航天器ID的数据。
正在使用两个虚拟通道。虚拟通道1包含大多数数据（总共5888帧），而虚拟通道2仅包含5帧。
两个虚拟通道中的AOS帧都有一个8字节长的插入区域。前4个字节的用途未知，而后4个字节是小尾数时间戳记，编码为自UTC 2012-08-01 00:00:00起经过的秒数。将此时间戳格式与Tianwen-1中使用的时间戳格式进行比较很有趣，该格式使用48位big-endian时间戳，自2016年1月1日00:00:00北京时间以来，该时间戳编码100us单位。从大尾数法到小尾数法的变化是特殊的，因为CCSDS协议以某种方式偏爱大尾数法领域，从北京时间时代到UTC时间的改变也是一个有趣的好奇心。
下图显示了来自虚拟通道1的帧中的时间戳和虚拟通道帧计数器。间隔对应于USA Satcom提供的不同文件之间的时间间隔。
虚拟通道1中的空间数据包使用许多不同的APID。我一直在浏览每个APID中的数据图，它们看起来让人联想到Tianwen-1。模拟遥测通道有很多，但我无法发现任何具有明显含义的通道，并且似乎没有像Tianwen-1那样的浮点数据。在这里，我展示了一些最有趣的APID。
虚拟信道2中的五个帧是连续发送的，也许是响应远程命令而发送的。它们每个都包含来自APID 897的单个空间包，该空间包占据所有帧。
这些空间数据包中的数据看起来像某种文件下载或内存转储。前8个字节包含三个固定字节，它们可能标识文件或内存区域，其后是5字节小端块计数器。这里的传输仅使用5个块，最后一个块中的大多数数据都填充有0xaa填充字节。下图显示了此传输中的数据，每行一个块。数据清楚地显示了模式，但我不知道它是什么。
此部分的代码和数据（包括所有APID的全部图）可以在Jupyter笔记本中找到。
高数据速率遥测根据r00t使用2.5Mbaud BPSK。与Tianwen-1高数据速率长帧的情况一样，编码是使用四个交错的Reed-Solomon码字（每个255字节）来连接CCSDS帧。
此处使用的数据是Paul在2020年11月24日UTC在8455 MHz处接收的一小段。看到由Reed-Solomon解码器校正的误差非常有趣，该误差表现出较大的可变性，但表明Paul具有足够的SNR余量来解码信号。
数据由来自航天器ID 26的AOS帧组成（请注意，这是与上一部分使用的低速率数据中的航天器ID不同的航天器ID）。虚拟通道38和63正在使用，分别具有18396和51850帧。
与用于低数据速率遥测的AOS帧相比，此处的AOS插入区只有6个字节长，其中2个未知字节始终包含值0xf0f0，后跟4个字节的时间戳，使用与低数据相同的格式给帧评分。没有M_PDU。数据紧随插入区域之后。
虚拟通道63仅由空闲数据组成。这是AOS空间数据链路协议的标准功能，称为OID通道（仅空闲数据），始终为虚拟通道63。此虚拟通道的帧中的数据填充有0xaa填充。
从虚拟通道帧计数器中的跳转计算出的帧丢失表明丢失了很少的帧。末尾的大幅跳动对应于Paul的数据缺口，该缺口分为两个文件。
虚拟频道38非常有趣。我在Twitter上开玩笑说它类似于Inception电影，因为它具有多层CCSDS协议。该虚拟通道中的时间戳很奇怪，因为与OID通道中的时间戳相比，它们似乎运行得太快，并延伸到未来。如图所示，该虚拟通道中的18396帧无法跨越一小时零30分钟。我不确定这是怎么回事。
这显示了虚拟通道38中的第一帧。我们可以辨别AOS标头，然后辨别两个看起来很相似的部分，然后辨别大部分0xaa填充。
这些AOS帧中每个帧的数据字段都包含一个空间包，该空间包直接嵌入而无需使用M_PDU。空间数据包的长度（包括其标题）为510字节，这说明了为什么AOS帧的末尾填充有填充。这些空间数据包属于APID 92。
这些空间数据包中每个数据包的内容都是两个背对背的AOS帧，这在下图中说明了重复过程。 AOS帧属于航天器ID 197（但还是新航天器！），虚拟通道ID 52，并设置了重播标志。
这些已重播的AOS帧的插入区域包含三个未知字节，后跟通常格式的32位时间戳。时间戳和帧数如下所示。重放数据实际上是从前一天开始的，从启动后仅30分钟开始。
与通常的AOS帧相比，这些AOS帧具有CRC-16，后者依赖于Reed-Solomon奇偶校验字节进行错误检测。我解码的所有重播帧的CRC都是正确的。
这些重放的AOS帧使用M_PDU，并且包含来自APID 301和2047（空闲APID）的空间分组。如预期的那样，空闲的APID数据包仅包含零。下图显示了APID 301中的数据。我不确定如何解释它，但是其中一些结构是显而易见的。
此部分文章中使用的数据和代码可以在Jupyter笔记本中找到。
感谢所有的业余社区，他们在每次午餐后都对这些活动保持着新鲜的兴趣，并以其非常有趣且具有挑战性的使命祝愿中国农历探月计划万事如意。