解码火星2020

美国国家航空航天局（NASA）对火星的最新飞行任务“火星2020”于几周前发射升空。但是，由于所有Tianwen-1的工作正在进行中，到目前为止，我还没有时间专门为该任务指定一个帖子（尽管我在Twitter上有偷看的机会）。该任务由流动站和直升机组成（这是太空探索的真正新颖之处）。两者都是在巡航阶段以及进入，下降和着陆系统于7月30日从卡纳维拉尔角（Cape Canaveral）发射升空的，目前它们正以天文一号和阿联酋航空火星任务的形式向火星转移。

在这篇文章中，我将使用波鸿天文台20m射电望远镜处理AMSAT-DL的一些录音。这些功能具有低速率安全模式遥测功能，该功能非常强大，并且在使某些NASA DSN接收器饱和时会引起一些轶事，并且标称10kbps遥测信号随后会打开。在这里，我将描述调制和编码，并给出GNU Radio解码器，并介绍一下数据。 r00t.cz也写了一个帖子，他在其中显示了类似的信息。

火星2020的X波段下行链路约为8414.9 MHz。在安全模式下，使用PCM / PSK / PM传输的波特率仅为80波特（有关术语，请参见本文档）。这意味着遥测是将PSK信号调制到子载波上，然后将其相位调制到残留载波上。在这种情况下，副载波是25kHz方波。

下图显示了信号频谱，如UTC 2020-07-30 20:25在Bochum中记录的。我们看到中心残留载波与0Hz的偏移很小，然后是数据边带及其奇次谐波。由于方波子载波，我们只有奇次谐波。当相位调制时，正弦波子载波会同时产生偶数和奇数谐波。

如果放大到调制的中心，由于波特率低，我们会看到数据边带非常窄。

编码是CCSDS Turbo帧，如TM同步和信道编码蓝皮书中所述。使用1/2的速率和223字节的帧大小。注意，由于波特率低，每个帧需要45.5秒的时间发送。

GNU Radio解码器流程图如下图所示（单击以查看完整尺寸）。它的结构与我在以前的文章中展示的其他PCM / PSK / PM解调器非常相似，例如，用于Tianwen-1的解调器。残留载波由PLL锁定（此处使用200Hz带宽），信号的虚部用于提取数据边带，将子载波下移至基带，然后使用Costas环路进行时钟恢复和子载波恢复完成。最后，使用gr-dslwp中的块完成Turbo解码。流程图可在此处找到。

下图显示了解码器的运行情况。信号很强，所以星座很干净。我们可以在BPSK子载波的频谱中看到，由于某些旁瓣是可见的，因此数据符号未过滤。

标称的10kbps信号取代了正常航天器运行期间的安全模式调制。调制为60kbaud PCM / PM / NRZ。这意味着数据直接被相位调制到残余载波上。

下图显示了Bochum在2020-07-31 20:04 UTC记录的信号频谱。我们可以看到残留载波和数据调制，可以通过与载波正交的BPSK调制来近似。

像安全模式信号一样，编码是CCSDS Turbo帧，但是这里使用1/6的速率和1115字节的帧大小来改善低Eb / N0性能。这样，帧大约需要0.9秒才能传输。

下图显示了10kbps信号的GNU Radio解码器流程图。这里使用的方法与阿联酋航空火星任务解码器（也是PCM / PM / NRZ）略有不同。残留载波由PLL（带宽为50Hz）锁定，然后对信号的虚部进行采样以获得BPSK调制。使用ML TED和多相根升余弦滤波器进行时钟恢复。对于安全模式信号，使用gr-dslwp块进行Turbo解码。解码器可以在这里找到。

解码器如下所示运行。信号不是很强，并且有很多误码，但是Turbo解码器仍然能够纠正大多数误码，因此帧错误率很低。

对于安全模式和10kbps信号，成帧是相同的，因此在此处对其进行描述。这些帧是AOS空间数据链路帧，如CCSDS AOS空间数据链路协议蓝皮书中所述。这些帧包含一个CRC-16，用于丢弃未纠正错误的帧。

在我检查过的记录中，AOS帧中仅使用了航天器ID 168和虚拟通道0。帧的有效载荷包含使用M_PDU协议的空间数据包（请参见CCSDS空间数据包协议蓝皮书）。

空间数据包包含一个辅助报头，它是使用CUC格式的6字节时间戳（请参阅《时间码格式》蓝皮书）。这意味着时间戳是一个48位计数器，在这种情况下，它使用\（2 ^ {-16} \）秒的单位。计数器的纪元是J2000纪元，即2000-01-01 12:00:00。我不确定所用的时标（UTC，TAI等），因为相对于录制文件名中的时间戳而言，时间戳有些偏离。

由于安全模式帧需要花费很长的传输时间，因此从短记录中仅提取了4帧。由于信号逐渐消失，它们中的最后一部分已部分损坏，因此其CRC错误。框架如下所示，每行一帧。稍后我们将看到，蓝色带对应于ASCII文本。

这些帧中有7个空间数据包。前四个属于APID 8，其余三个属于空闲APID2047。下面显示的数据包时间戳非常有趣。我们看到，由于数据速率低，前四个数据包（APID 8中的那些数据很有用）几乎同时生成并在可能的情况下发送。根据文件名，录制从世界标准时间20:25:19开始。最后三个数据包是空闲的，并且可能具有实时时间戳。这些的时间戳间隔为45.5秒，恰好是帧的持续时间。

APID 2047空闲数据包中填充了ASCII文本作为复活节彩蛋。但是，安全模式帧太短而无法包含全文，因此稍后将在10kbps帧中显示。

APID 8中的数据包包含以下ASCII字符串以及一些二进制数据

从记录中总共提取了950帧。从这些，只有4个具有不正确的CRC。框架可以在下图中看到。大多数帧都有一个带有复活节彩蛋ASCII文本的空闲数据包，如蓝色条所示（深蓝色的块是ASCII空间）。顶部附近更不规则的块是旧遥测数据的传输。

下面我们根据虚拟通道帧数显示丢失的帧数。

此记录中有三个活动的APID：APID 2047（包含空闲数据包，具有741个数据包），APID 9（包含一些实时遥测，具有58个数据包），APID 247，包含旧的遥测，具有14个数据包。在下图中可以很好地看到数据包的分布，该图显示了APID分类的时间戳。我们看到，在大多数情况下，会发送空闲数据包，偶尔在APID 9中进行实时遥测。一段时间以来，旧数据在APID 247中进行传输，而实时APID 9数据则在继续。

APID 9中的数据包包含难以解析的格式的数据。它是一种标记值格式，其中有一个2字节的标记，描述字段的类型，然后描述字段本身。问题在于字段长度是隐式的。这可以在下面的块中看到，该块以十六进制显示一些APID 9数据包的有效载荷的前64个字节。它们中的大多数以标签0x027a开头，然后是float64值，然后是标签0x027d，后跟32位字段，是标签0x027e，依此类推。

解析此类数据的问题在于猜测每个字段的长度。但是，我做了一个启发式算法，并没有做得那么糟糕。它基于这样一个事实，即一个标签和下一个标签通常是相关的：第二个标签等于第一个标签加上一个小数字。我将“块”称为具有相同标签的所有字段的集合，这表示存在相同类型的数据（格式和语义）。

我试图绘制一些使用float64格式的块，并在下面找到的最有趣的块下面显示。这些显然具有某种正弦行为。但是，像往常一样，我不清楚这些是什么。

每个APID 2047数据包都包含以下ASCII文本。有趣的是，CRLF用于行跳转，并且除了最后一行（不能完全容纳在框架中）外，行以48个字符的宽度填充（包括两个空行）。

N.Abcouwer P.Basa M.Belete E.Benowitz S.Brooks J.Biesiadecki L.Burke D.Byrne S.Chen S.Scandore J.Carsten K.Edelberg D.Gaines D.Leang R.Joshi R.Haleski A.哈里斯·L·加尔达梅斯·刘易斯·T·里特温·D·兰·Q·何·M·迈蒙·M·麦克亨利·D·摩根·Myint B.马丁·P·帕蒂基安·拉比多·P·罗曼诺·R·曹·Schoppers A.Shearer R Srisamang C.Williams L.Stewart O.Toupet I.Trettel I.Uchenik V.Verma P.Vieira E.Wang B.Wright G.Yang B.Cichy C.Pong G.Reeves M.Tuszynski J.Casoliva P.Brugarolas Z.Rahman G.Griffin T.Fouser M.Wang P.Kwan A.Baez Harry *** MSL FSW开发团队。空间有美，有序。没有天气，而且有规律。这是可以预见的。看看我们的小探险家；您可以通过它设置时钟。太空中的一切事物都遵守物理学定律。如果您知道并遵守这些定律，太空将对您友善。 -维尔恩·冯·布劳恩（Wernher von Braun）深紫色72-让我们去太空卡车

上面显示的框架的分析已在此Jupyter笔记本中进行。 信号的频谱已在此Jupyter笔记本中计算并绘制。 框架的数据文件可在Github存储库中找到。