计算 HDLC 帧的 FCS(CRC)

我有以下框架：

7e  01 00  00  01  00  18  ef  00  00  00   b5   20 c1 05 10 02 71 2e 1a c2 05 10 01 71 00 6e 87 02 00 01 42 71 2e 1a 01 96 27 be 27 54 17 3d b9 93 ac 7e

如果我理解正确的话，那么就是计算 FCS 的帧的这一部分：

010000010018ef000000b520c1051002712e1ac205100171006e8702000142712e1a019627be2754173db9

我尝试将其输入多个在线计算器，但无法从上述数据中生成 0x93ac。

http://www.lammertbies.nl/comm/info/crc-calculation.html http://www.lammertbies.nl/comm/info/crc-calculation.html输入类型为十六进制。

0x93ac是如何得到的？

Thanks,

Barry

而是为那些在寻求建议时来到这里的其他人做出回答。

关键是密切相关的 ITU-T 建议书（例如 Q.921，已经在线提供相当长一段时间了）中的几点内容：

1. 首先发送（并因此接收）最低位

这种遗留行为与日常生活惯例相反，日常生活惯例是按照读取的顺序首先写入最高位数字，并且所有通用在线计算器和库都使用常规顺序执行计算，并提供可选设置以方便相反的顺序。 因此，你必须询问在线计算器

• 在执行计算之前反转您以“常规”格式输入的消息中的位顺序，
• 反转结果的位顺序，以便将它们输入 与消息本身相同的顺序

相当合理的是，一些计算器只为两者提供一个通用设置。

这就是上一个答案中推荐的设置“反向数据字节”和“最终 XOR 之前反向 CRC 结果”的原因；

2. CRC计算的结果在发送前必须进行位反转

位反转是“xor by 0xffff...”的另一个名称。在将 CRC 计算结果作为消息 FCS 发送之前对其进行位反转（消息的最后两个字节，示例中的“93 ac”）是有目的的。 详情请参阅第 4 点。

这导致设置“最终值 ffff”，其名称非常具有误导性，因为它实际上定义了与计算结果进行异或的模式。由于多种 CRC 类型需要此类操作，因此只有异或模式从 0（无操作）到 0xfff...（完全反转）变化，通用计算器/库提供它以简化使用。

3.计算必须包括对0xffff前导序列的处理

这就是“初始值ffff”这一点的原因。

4. 在接收（检查）端，建议推送完整的消息，即包括FCS，通过CRC计算，并期望结果为0x1d0f

这背后有一些巧妙的想法：

• CRC 算法的内在属性是

  CRC( x.CRC(x) )

  始终为 0（x 代表原始消息，“.”代表串联）。

• 通过计算运行完整的消息而不是 仅计算消息本身并与 FCS 进行比较 单独接收意味着算法（甚至电路）更简单 在接收端。

• 然而，很容易犯编码错误，导致结果变成 0。幸运的是，再次感谢 CRC 算法的内在属性，

  CRC( x.(CRC(x))' )

  产生一个独立于 x 且不同于 0 的常量值（至少对于我们在这里讨论的 CRC-CCITT 而言）。 “'”符号表示第 2 点中要求的位反转。