纠错码针对慢速CPU传输到快速CPU

Question

我正在寻找一种在微控制器上相对容易/快速编码的前向纠错码;解码将在PC上完成，因此可能更复杂。

我对错误纠正码的了解不多，除了简单的汉明码之外，它们似乎都比我能处理的更复杂。

有什么建议吗？

编辑：我要简短地接受卡尔的回答......我猜有两件事我没有提及：

（1）我并不严格需要纠错，这对我来说是有利的，我认为可能会有一些纠错算法，这对于最低成本来说是一个合理的好处。汉明码可能是合适的，甚至看起来它们对我的编码应用来说可能太昂贵了。

（2）比错误纠正本身更大的优点是能够正确地重新同步到出错的数据包。 （如果我长时间不同步，这很糟糕）所以我觉得如果我保持简单就好了。

Answer 1

我还没有完全明白你能承受多少开销。在您的评论中，您说16位错误检测/更正代码是正确的，但您没有指定您想要将其附加到的块的大小。为了有意义，您应该将允许的开销表示为百分比。 64位数据的16位纠错与一千字节数据的16位纠错有很大不同。

如果你能负担15-20％左右的开销，你可以使用带维特比解码器的卷积码。这是高度不对称的 - 卷积编码器非常简单（基本上是移位寄存器，输出抽头导致XOR）。一个非常大的可能会使用一个16位寄存器和大约六个XOR。

幸运的是，你有一台较重的计算机来处理解码，因为维特比解码器可能是一个可怕的野兽。特别是当您使用更大的编码器来减少开销时，解码器的大小会爆炸。解码器的大小相对于代码组的大小是指数级的。

提到了Turbo码。与使用维特比解码器的卷积码相比，它们可以更好地利用可用带宽 - 但是它们使用相当复杂的编码器 - 至少两个特定类型的卷积编码器（递归系统卷积编码器）。因此，它们似乎也不符合您的规范。

Answer 2

纠错码的问题在于它们可以让您从单个位或2位错误中恢复，但通常无法检测或修复重大损坏。

因此，我的建议是将数据流分成块（1 KB，10 KB，最多1 MB）并计算每个块的校验和。然后，当数据到达另一个CPU时，您可以确定它是否正确，如果没有则请求重新传输该块。因此，接收计算机将确认并等待下一个块，或者否定确认并期望重新发送。

是的，我们在这里实现TCP / IP的子集。但是这个协议如此成功是有原因的：它有效！

对于校验和，我建议使用CRC-32。它需要一个（我认为）256个32位数字的表和一些相当容易的计算（数组索引，OR和XOR，大多数），因此对于“哑”CPU来说计算起来相当容易。

Answer 3

我建议使用基于数据包的前向纠错形式。如果你必须发送六个相等长度的数据包，请向它们发送足够的信息以将其识别为“数据包1 of 6”，“2 of 6”等，以及另一个数据包，其第一个有效负载字节是xor分组1-6的第一个有效载荷字节，其第二个有效载荷字节是分组1-6的第二个字节的xor，等等。接收七个总数中的任何六个分组的代码将能够重建丢失的一个。作为轻微的增强，对于“偶数”数据包使用一个“奇偶校验”数据包，对于“奇数”数据包使用另一个“奇偶校验”数据包。如果这样做，系统将能够从任何不超过数据包的突发错误中恢复。