解码猎鹰9 Falcon9 上级
本文核心词：火箭,业余无线电,猎鹰9,遥测,深空业余无线电
转载自
机器翻译简单校对，部分公式无法正常显示，请参考原文
这不再是新闻了。自几周前以来，一些人一直在从Falcon-9上级解码S波段遥测，其中包括有关航天器外部和液氧罐内部的实时视频。这始于r00t.cz，@ aang254和其他人的工作，他们在三月的第二周左右首次设法从遥测中解码视频。r00t.cz已发布有关遥测的一些信息，@ aang254已将解码器添加到SatDump中，而亚历山大·鲁马（Alexandre Rouma）将解码器添加到了SDR ++中。实际上，解码视频的整个过程已经变得非常流行，并且越来越多的人正在对最新发布的视频进行解码。
在2021年3月24日有一个发射60颗星联从卫星卡纳维拉尔角，和伊班卡多纳EB3FRN送我他做的第一轨道的智商记录，在发射后约18分钟。我决定为此制作一个GNU Radio解码器流程图，因为即使已经有几个软件解码器，但我还没有看到有人在使用GNU Radio。我发现我可以很容易地用gr卫星的一些块来组装流程图。这将成为使用GNU Radio解码数字信号的有用且有趣的示例。
如r00t.cz所述，遥测信号为3.5714 Mbaud GMSK。编码是CCSDS Reed-Solomon帧，具有（255,239）码（而不是更频繁的（255,223）码）和每帧5个交错的Reed-Solomon码字，其未编码帧大小为1195字节。
解码器流程图如下所示。可以在这里下载。最后，我花了一些时间尝试优化解调器，以提高解码帧的数量。我使用的是基于正交解调的方法，而不是FSK音调的功率检测，这是我最初尝试的方法（它似乎工作得更糟）。
Falcon-9 GMSK S波段遥测GNU无线电解码器流程图
由于记录是以6 Msps采样的，每个符号仅提供1.68采样，因此第一步是内插2倍。此步骤是可选的，但它使测试不同的时钟同步算法更加容易。但是，从CPU使用率的角度来看，上采样并不是一个好主意。作为上采样过程的一部分，我们将信号低通滤波到4 MHz带宽（或多或少占用的带宽），以使更少的噪声功率进入非线性正交解调器。
接下来，我们有一个正交解调器，其增益被调整为GMSK信号的偏差。然后，我们使用符号同步块恢复符号时钟并执行一些脉冲形状滤波。对于脉冲整形，我使用的是与BT对应的1的高斯形状脉冲。这是正确的：它只是一个高斯，而不是高斯和矩形窗口的卷积，这将是GMSK的典型脉冲形状。通过对脉冲形状进行实验，我发现较窄的形状会更好地工作，并且高斯BT使我可以很好地控制设置脉冲的宽度。
我使用的是最大可能性TED，但我发现Gardner TED也能很好地工作。我决定将阻尼系数设置为0.7，这似乎比通常的系数1更好。
解调后，通过使用gr-satellites的“同步并创建PDU”块将帧转换为PDU，该PDU块会在帧开始时检测CCSDS同步字。然后，我们有了来自gr-satellite的CCSDS解扰器。
解扰后，我们需要进行里德-所罗门解码。Falcon-9使用的Reed-Solomon代码使用CCSDS标准规定的对偶基础。因此，有必要在解码之前进行基础改变。但是，Phil Karn KA9Q的libfec仅实现常规（255,223）代码的基础更改。虽然也很容易为（255,239）代码添加它，但是为了不修改代码，我决定使用Map块执行到常规基础的转换。转换表在libfec的and数组中给出，可以将其直接复制到Map块中。
为了节省一些时间（可能还有一些错误），我从SDR ++复制了Reed-Solomon代码参数，但是从CCSDS TM同步和信道编码蓝皮书给出的文档中也可以很容易地推导出这些参数。字段生成器多项式为391，或者为二进制，用于对多项式进行编码x^8+x^7+x^2+x+1在标准中给出。（255,223）和（255,239）代码相同。这两个代码的原始元素均为11，因为α^11 用作 GF（2个8）GF（2个8）。第一个连续的根是128 – E，其中E是代码可以纠正的错误数：（255,223）代码为E = 16，（255,239）代码为E = 8。这对应于代码生成多项式的因式分解GG 作为
在Reed-Solomon解码之后，我们撤消基础更改，并将解码后的帧写入文件，以供以后在Jupyter笔记本中进行分析。
值得一提的是，此遥测信号中使用的FEC并非设计得非常健壮或不允许以较弱的信号进行复制。它可能旨在作为一种低开销的方法来纠正偶发错误。下图摘自CCSDS绿皮书，显示了BPSK / QPSK在AWGN上的性能。我们看到复制大约需要6.5 dB Eb / N0。在这里，我们正在对GMSK进行非相干解调，因此Eb / N0阈值较高。
这些框架遵循临时协议，该协议在r00t.cz的文档和我的Jupyter笔记本电脑中都有描述。帧内部有分段的数据包，对它们进行碎片整理的方式与将空间数据包封装到AOS帧中的CCSDS M_PDU协议非常相似。
所有帧都有一个13位的序列计数器，某些数据包具有一个时间戳，该时间戳以64位整数形式给出，该整数计算自GPS时代以来经过的纳秒。下图显示了已解码数据包的时间戳和顺序计数。注意缺少帧的分段的规律性。这是信号中周期性衰落的结果。
所有数据包都包含一个64位ID，该ID提供了数据包中传输的信息的来源或种类。这些源之一包含视频，该视频通过在每个数据包内封装五个188字节MPEG传输流数据包来传输。
由于频繁的信号丢失，因此解码后的视频不能非常流畅地播放，但是下面我们显示了一些说明其内容的帧。
Falcon-9液氧罐的内部
Falcon-9上级Merlin发动机
在航天器外部的视图，显示要部署的卫星
传输的数据中只有大约28％对应于视频传输流，因此，除了视频之外，还有大量遥测。传输流使用以下PID：
PID 0比率0.4％PID 32比率0.4％PID 511比率6.5％PID 2748比率11.8％PID 4112比率79.4％PID 8191比率1.4％
与往常一样，PID 0被用来携带节目分配表（PAT），并且可以与被解码dvbsnoop通过做
dvbsnoop -if falcon9.ts -s ts -tssubdecode 0
这显示了以下解码：
我们看到只有程序1，其程序映射表（PMT）在PID 32中传输。我们还可以使用dvbsnoop解码PMT，获得
这些表明该程序中有两个流：
PID 4112中的H.264视频流
PID 2748中具有专用KLV元数据的PES数据包流
此外，程序时钟参考（PCR）包含在PID 511中。请注意，流的PID为，且为十六进制，因此可能已选择它们，因为它们的十六进制值为“ nice”。
来自PCR PID 511的数据包仅将PCR作为有用数据：
PCR时间戳记从2:13:10开始，因此传输流在启动前将近2小时开始。下图显示了携带传输流数据的数据包中PCR时间戳和GPS时间戳的比较。
这就是KLV流数据包的样子：
PID 4112包含分辨率为640×360和每秒29.97帧的H.264视频。
另一个数据包来源专用于车载GPS接收器的日志。通过丢弃这些数据包的前25个字节和后2个字节，我们获得了ASCII格式的日志。如下所示。请注意，由于丢失了数据包，某些行被缩短。
此日志中的大多数信息都是不言自明的。我不明白的是列表中SVN旁边的代码。这些代码可能表示有关跟踪质量，星历表的可用性或在导航解决方案中的用法。自GPS时代以来，每行开头列出的时间戳均为纳秒。
这篇文章只是对已知事物的回顾。遥测的其余部分尚未得到很好的理解，因此对于任何有兴趣的人都存在很好的逆向工程挑战。这篇文章的文件包含在我的jupyter_notebooks存储库中的此文件夹中。解码的帧与git附件一起存储，并且可以按照README中的说明进行下载