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

【问题标题】：error correcting codes aimed at slow CPUs transmitting to fast CPUs针对慢速 CPU 传输到快速 CPU 的纠错码
【发布时间】：2009-12-09 20:02:07
【问题描述】：

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

我对纠错码知之甚少，除了简单的汉明码之外，它们似乎都比我能处理的复杂。

有什么建议吗？

编辑：我要简明扼要地接受卡尔的回答......我想有两件事我没有提到：

(1) 我并不严格需要纠错，这对我来说只是有利的，而且我认为可能有一些纠错算法可以以最小的成本获得合理的收益。汉明码可能非常合适，即使它们看起来对我的编码应用程序来说成本太高。

(2) 比纠错本身更大的优势是能够正确地重新同步到跟随错误的数据包。（如果我长时间不同步，那很糟糕）所以我认为如果我保持简单的话会更好。

【问题讨论】：

赞成，因为这是一个有趣的问题，而且我可能需要更聪明的人的帮助。此外，更新了我的 cmets 中的建议。

标签： algorithm error-correction

【解决方案1】：

我还没有完全弄清楚你能负担多少开销。在您的评论中，您说 16 位错误检测/纠正代码是正确的，但您没有指定您正在考虑将其附加到多大的块。为了有意义，您可能应该将允许的开销表示为百分比。 64 位数据的 16 位纠错与千字节数据的 16 位纠错有很大不同。

如果您能承受 15-20% 左右的开销，您可能可以将卷积码与 Viterbi 解码器一起使用。这是高度不对称的——卷积编码器非常简单（基本上是一个移位寄存器，输出抽头通向异或）。一个非常大的寄存器可能会使用一个 16 位寄存器和六个左右的 XOR。

幸运的是，您有一台重型计算机来处理解码，因为 Viterbi 解码器可能是可怕的野兽。特别是当您使用更大的编码器来减少开销时，解码器的大小会爆炸式增长。解码器的大小与代码组的大小成指数关系。

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

【讨论】：

re：开销：在数据或计算方面并不多。数据包很短，通常为 8-16 字节，我不想看到每个数据包开销超过 16 位。具有与包单元不同的代码单元（例如，每个代码多个包或每个包多个代码）的计算复杂性可能是不可接受的。不幸的是，硬件解决方案已经出现，所以即使是卷积编码器，如果我理解正确的话，在软件方面的工作量可能太多了。但是 +1 以获得一些很好的解释 + 建议。

【解决方案2】：

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

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

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

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

【讨论】：

换句话说，您提倡反对前向纠错，而是提倡更传统的“交互式”协议，包括校验和、确认等。在这个应用程序中使用显式确认是不切实际的（与我需要的吞吐量相比，循环延迟是无法忍受的），所以这不是我想要的，但是这样的建议对其他应用程序很有用。
哦，好的。这改变了一些事情。根据我的经验，我确实在嵌入式微型计算机系统上编写了 IO，通信要么完美无缺，要么根本没有。除非您处于非常嘈杂的环境中，否则您不会得到通过单位校正处理的那种错误。我知道这对你原来的问题仍然没有帮助......我会去看看我能挖掘出什么。
好的，我已经查看了 Wikipedia 文章和参考资料……我可能可以实现其中一种建议的算法，但这会让人头疼。你有足够的带宽来做一些愚蠢而简单的事情吗？分块发送数据，每个块发送 3 次。对于每一位，3 场比赛中最好的 2 场获胜。一个完整的前向ECC算法，用2句话描述:)
我写了一些与雷达探测器接口的代码。在我办公桌上的长凳上，通讯是完美的，但汽车却有各种各样的噪音。在分析数据之后，看起来每个数据包都被发送了两次。最后我只是比较了最后两个数据包，如果它们相同，我认为它是有效的。这种方法效果很好，我没有看到任何故障，并且数据发送速度足够快，不会过时。
嗯。你们都提出了有趣的观点。我想我正在寻找的是比 CRC 稍微好一点的东西，因为它允许进行一些纠错，在源端的计算成本不高，并且不会干扰我的吞吐量需求。（发送 3x 对于带宽使用来说太贵了）它不一定是完全防弹的，我只是想看看那里是否已经存在某些东西（也许它不存在，在这种情况下，CRC 可能就足够好了） .

【解决方案3】：

我建议使用基于数据包的前向纠错形式。如果您必须发送六个等长的数据包，请向每个数据包发送足够的信息以将其识别为“6 个数据包 1”、“6 个数据包 1”等，以及另一个数据包，其第一个有效负载字节是数据包 1-6 的第一个有效负载字节，其第二个有效负载字节是数据包 1-6 的第二个字节的异或，以此类推。接收到总共七个数据包中的任何六个数据包的代码将能够重建丢失的数据包。作为一个轻微的改进，对“偶数”数据包使用一个“奇偶校验”数据包，对“奇数”数据包使用另一个。如果你这样做，系统将能够从任何不超过一个数据包的突发错误中恢复。

【讨论】：