0

我们正在尝试开发一个用于立方体卫星操作的流程图。我们的流程图在一个流程图中包括下行链路和上行链路部分。它使用 SoapySDR 作为 SDR 的驱动程序。大多数使用的块都包含在 GNURadio 的核心中。使用了 Daniel Estévez 的 gr-satellites 的几个区块。通过 TCP 服务器（接收器和源块）提供数据输入和输出。

我们的 GFSK mod/demod 流程图

上行部分从 TCP 端口获取二进制数据并提供 KISS 去帧。解帧后的数据被打包到 HDLC 帧中。HDLC 成帧器块的输出是表示流的各个位的字节（0x00 和 0x01 字节）。对于 KISS 去帧和来自 gr-satellites 的 HDLC 帧块被使用。之后 G3RUH 加扰和 NRZI 编码完成。使用的 Scrambler 块来自 GNURadio 核心，NRZI Encoder 来自 gr-satellites。产生的比特流需要再次重新打包成字节，随后发送到 GFSK 调制器。Repack Bits 块用于此操作。它将传入的 8 个字节（代表 1 个字节的 8 位）打包成一个输出字节。如果比特填充和 NRZI 编码导致总比特数不能被 8 整除，则比特流的结尾被剪切。

GFSK Mod 参数为：

  • 每个符号的样本数：40
  • 灵敏度：(0.625*pi)/40 (偏差 3kHz, 9600bd -> mod. index 0.625)
  • 蓝牙：0.5

在这一部分中，我们正在处理一个我们无法解决的问题。虽然使用 2 个后同步码来确保在 Repack Bits 块中至少有一个被正确重新打包，但似乎没有完全发送。我们已经尝试了几个接收器（流程图的下行链路部分、我们的 cubesat TRX 模块、带有第二个 SDR 的 UZ7HO hs-soundmodem），但没有一个能够正确接收数据包。

我们开始连续快速发送数据包。其中一些通过接收器。似乎第 (N+1) 个数据包的第一个前导字节用作第 N 个数据包的后导字节。

在此之后，我们尝试增加后同步字节数。这样一来，成功率就提高了。有趣的事实是，所有使用的接收器都正确接收了某些数据包。我们最终得出的结论是 20 个后置字节足以通过几乎 100% 的数据包。这似乎有效，但绝对不是解决此问题的正确方法。在正确的操作中，只需要一个后同步字节。增加后同步字节数会影响整体数据吞吐量。

检查编码块后，我们还保存了 GFSK Mod 块的输出。它是一个 32 位浮点 IQ 文件，通常直接发送到 SDR。我们创建了一个小而简单的流程图来解调和解码保存在文件中的这些数据。

用于 IQ 解调和解码的流程图

作为第一种解调方法，我们使用了 gr-satellites 包中的 FSK 解调器模块。解调后，我们还进行了解码过程并将输出保存到文件中。

这是二进制形式的解调和解码数据：

x1111111 11111000 00111111 11111111 11111111 11111111 11111111 11111111 10101011 11111111 01101010 0101110101111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 0111111001111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 0111111001111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 0111111001111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110001011

我们可以看到 150 字节的前导码（粗体），后面跟着一个不完整的数据字节。这个不完整的数据部分似乎是正确的，因为第一个预期字节是 B4 → LSB 00101101 MSB

我们尝试的第二种方法是使用来自 GNURadio 核心的 GFSK Demod 块。我们使用与第一种方法相同的输入文件。

这是二进制形式的解调和解码数据：

xxxxx011 00000000 00110001 1111111001111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 0111111001111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 0111111001111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 0111111001111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 0111111000101101 00001111 11000110 00000000 00000000 01001010 10111110 11001010 10001010 00111010 00

这里我们只能看到 149 个前导字节而不是编码的 150 个字节。之后我们可以看到一个不完整的数据包。执行了位去填充并且分析显示数据字节是正确的。

在整个数据编码过程中，流程图的“数字”部分似乎是正确的。没有观察到错误并且数据包以预期的方式改变。

我们可以看到两个解调器对数据的解调方式不同。在两个输出中，数据包的结尾都丢失了。如果我们将 postambles 设置为 5，则第二种方法能够正确解调数据包，观察两个 postambles。使用第一种方法时，仍然缺少后置码。仅使用 5 个后置码通过空中传输数据包的成功率非常低。

通过空中发送和解调数据最终会遇到类似的问题。数据包的结尾只是丢失了。有人知道问题出在哪里吗？

4

0 回答 0