计算HDLC帧的FCS(CRC)

Question

我有以下框架:

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输入类型为十六进制.

0x93ac是如何到达的？

谢谢,

巴里

Answer 1

在寻找建议的时候回答其他人.

关键是密切相关的ITU-T建议中的若干要点(例如Q.921,已在网上提供相当长的一段时间)说:

1.首先发送(并因此接收)最低位

这种遗留行为与日常生活惯例相反,其中最高位数字首先按读取顺序写入,并且所有通用在线计算器和库使用常规顺序执行计算并提供可选设置以促进反转顺序.因此,您必须询问在线计算器

• 在执行计算之前,以"常规"格式反转消息中的位顺序,
• 反转结果的位顺序,以便按照与消息本身相同的顺序获取它们

相当合理的是,有些计算器只为两者提供了一个共同的设置.

这导致在前一个答案中建议设置"反向数据字节"和"在最终XOR之前反转CRC结果";

2.在发送之前,CRC计算的结果必须是位反转的

位反转是"xor by 0xffff ..."的另一个名称.在将CRC计算结果作为消息FCS(消息的最后两个字节,在您的示例中为'93 ac')发送之前,有一个目的是对CRC计算结果进行位反转.详见第4点.

这就是设置"最终值ffff"的原因,其名称非常具有误导性,因为它实际上定义了与计算结果进行xor'ed的模式.由于几种CRC类型需要这样的操作,因此只有xor模式从0(无操作)到0xfff ...(完全反转)变化,通用计算器/库提供简化使用.

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

这就是"初始值ffff"的原因.

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

这背后有一些聪明的想法:

• CRC算法的内在属性就是这样

  CRC(x.CRC(x))

  始终为0(x表示原始邮件,"."表示连接).

• 通过计算运行完整的消息而不是仅计算消息本身,并且与单独接收的FCS进行比较意味着接收侧的更简单的算法(或甚至电路).

• 然而,很容易造成编码错误导致结果变为0.幸运的是,多亏了CRC算法的内在属性,

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

  产生一个独立于x且不等于0的常数值(至少对于CRC-CCITT,我们在这里讨论)."'"符号表示第2点所要求的位反转.

Answer 2

首先，CRC值是 0xac93

使用此计算器：http : //www.zorc.breitbandkatze.de/crc.html

• 设置CRC顺序16
• 多项式1021
• 初始值 ffff
• 最终价值 ffff
• “反向数据字节”
• “最终XOR之前的CRC反向结果”

• 输入您的序列为：

  %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
  

• 按“计算”，您会得到 0xAC93