【问题标题】:How efficient is the CRC algorithm?CRC算法的效率如何?
【发布时间】:2021-05-15 08:37:55
【问题描述】:

在我使用 53 (110101) 作为除数,误码率为 10^(-3) 的 200,000 条 k = 20 位消息中的 CRC 算法实现中,有 4987 条消息有错误,其中只有一条出现通过未被发现。这些是有效的结果吗? CRC算法可以如此高效还是我的实现可能有问题? (我没有发布我的代码,因为我只是想要一些关于我想自己调试的结果的反馈)

-编辑:我使用的 CRC 算法是 here。我使用数字 53 来划分二进制消息,得到的余数是帧校验序列。然后将此序列附加到消息的末尾,然后传输消息。在接收端,发送的消息再次除以 53,但这次余数应为 0,除非发生位错误。 (虽然可能会发生未注意到的位错误)

【问题讨论】:

  • 您使用的是 5 位 CRC? CRC中有多少位?每个消息是 20 位? (“k”本身没有任何意义。)
  • 再一次,每条消息是 20 位吗?您是否为每条消息附加 5 位 CRC?
  • 迟到了 25 位抱歉
  • “它”是什么?消息是 25 位的?消息加上CRC是25位?好的,再来一次。每条消息是 20 位吗?然后,您是否为每条消息附加 5 位 CRC?

标签: signals signal-processing crc


【解决方案1】:

看起来您对位错误的实现很可能不正确。

如果我正确阅读了问题并且每条消息都有 20 位,那么预期的错误消息数是 200000 (1 - (1 - 10-3)20 sup>),即 3962。标准差大约是 63 的平方根。您的 4987 条消息比预期数字高出 16 个标准差!偶然发生的概率小于10-58​​sup>。所以你有一个错误。

至于误报,对于 200,000 条具有该误码率和该特定 5 位 CRC 的 20 位消息,您应该预计平均大约有 1 个(更准确地说是 0.982)。

多项式 x5 + x + 1 (100011) 更适合您指定的条件。对于同一案例,这给出了 0.0071 个误报。

【讨论】:

  • 我计算了相同的结果,3962。我没有测试它,但 5 位 CRC 似乎不太可能有 20 位消息的 2 位故障情况。 CRC Zoo 不包括 hex 35 作为 5 位 CRC 的 6 位多项式之一。如果我没记错的话,20 位消息中出现 3 位错误的概率是 (.001^3) (.999^17) (comb(20,3)) ~= 0.00000112。
  • 你说得对,我在帖子中添加了一些关于所使用算法的说明。
  • 导致误报的最小错误位数是多少?也许这可以包含在您对 200,000 条测试消息中误报概率为 0.0982 的答案中。仍在等待 OP 澄清包括 CRC 在内的消息大小是 20 位还是 25 位。
  • 迟到了 25 位抱歉
猜你喜欢
  • 2021-03-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-12-30
  • 1970-01-01
  • 1970-01-01
  • 2016-11-06
  • 2015-03-12
相关资源
最近更新 更多