串行 RS232 通信校验和？
Serial RS232 Communication Checksums?
我正在通过 RS232 串口与伺服系统通信。我的伺服系统附带的内置功能太慢（57,600 波特端口上的简单 54 字节消息需要 25 毫秒），所以我尝试编写自己的通信功能，但是没有记录内置功能。我已经使用端口监视器来确定哪些信息正在发送到伺服系统，我需要帮助来破译结果。
我使用内置函数命令伺服 "goto" 递增步长（1、2、3 等）。这导致每个 "goto" 命令向伺服系统发送 5 个数据包。每个 "goto" 命令的前 4 个数据包是相同的。我在下面附上了大约 50 个十六进制数据包（每行 1 个）。如果您需要更多，post，我们可以一起解决。
10 13 04 20 00 01 B6 24 E9 68
10 13 04 20 00 00 AE 24 54 82
10 13 04 20 00 00 B5 24 8B 0B
10 13 04 20 00 01 43 01 71 9B
第 5 个数据包根据命令电机移动到的步长而变化。我在这里以 1 个数据包为例。我附上了一个包含大约 1000 个这些数据包的文件（每行 1 个）。
10 13 08 20 03 01 11 25 0A 00 00 00 81 CF
此数据包的前 8 个字节 (10 13 08 20 03 01 11 25) 似乎是实际的 "goto" 命令。无论指定什么步骤，它们都保持不变。
最后 6 个字节 (0A 00 00 00 81 CF) 根据请求的步骤而变化。在我附加的文件中，我指示伺服最初转到步骤“0”，然后是“1”、“2”等。前 4 个字节似乎是一个小端整数，对应于步数（即我上面显示的示例命令指示伺服转到十进制的第 10 步）。
我的问题是关于命令的最后 2 个字节。它们似乎随机变化，但只要指定的步骤相同，它们就会匹配。这让我相信这 2 个字节是某种校验和。我的问题是：校验和是如何计算的？
我已经尝试对所有字节进行异或运算，包括单个字节和 2 个字节对，并且我尝试了 Fletcher 的校验和，以及一个简单的校验和（所有字节的总和）。我还检查了每种方法的 2 的补码（尽管我当然不介意有人检查以确保我没有在计算中出错）。有人有什么想法吗？
10 13 08 20 03 01 11 25 00 00 00 00 E9 64
10 13 08 20 03 01 11 25 01 00 00 00 9F D0
10 13 08 20 03 01 11 25 02 00 00 00 04 0C
10 13 08 20 03 01 11 25 04 00 00 00 23 95
10 13 08 20 03 01 11 25 05 00 00 00 55 21
10 13 08 20 03 01 11 25 06 00 00 00 CE FD
10 13 08 20 03 01 11 25 07 00 00 00 B8 49
10 13 08 20 03 01 11 25 08 00 00 00 6C A7
10 13 08 20 03 01 11 25 09 00 00 00 1A 13
10 13 08 20 03 01 11 25 0A 00 00 00 81 CF
10 13 08 20 03 01 11 25 0C 00 00 00 A6 56
10 13 08 20 03 01 11 25 0D 00 00 00 D0 E2
10 13 08 20 03 01 11 25 0F 00 00 00 3D 8A
10 13 08 20 03 01 11 25 10 10 00 00 00 17 FA
10 13 08 20 03 01 11 25 11 00 00 00 84 77
10 13 08 20 03 01 11 25 12 00 00 00 1F AB
10 13 08 20 03 01 11 25 13 00 00 00 69 1F
10 13 08 20 03 01 11 25 14 00 00 00 38 32
10 13 08 20 03 01 11 25 15 00 00 00 4E 86
10 13 08 20 03 01 11 25 16 00 00 00 D5 5A
10 13 08 20 03 01 11 25 17 00 00 00 A3 EE
10 13 08 20 03 01 11 25 18 00 00 00 77 00
10 13 08 20 03 01 11 25 19 00 00 00 01 B4
10 13 08 20 03 01 11 25 1A 00 00 00 9A 68
10 13 08 20 03 01 11 25 1B 00 00 00 EC DC
10 13 08 20 03 01 11 25 1C 00 00 00 BD F1
10 13 08 20 03 01 11 25 1D 00 00 00 CB 45
10 13 08 20 03 01 11 25 1E 00 00 00 50 99
10 13 08 20 03 01 11 25 1F 00 00 00 26 2D
10 13 08 20 03 01 11 25 20 00 00 00 DE 2A
10 13 08 20 03 01 11 25 21 00 00 00 A8 9E
10 13 08 20 03 01 11 25 22 00 00 00 33 42
10 13 08 20 03 01 11 25 24 00 00 00 14 DB
10 13 08 20 03 01 11 25 25 00 00 00 62 6F
10 13 08 20 03 01 11 25 26 00 00 00 F9 B3
10 13 08 20 03 01 11 25 27 00 00 00 8F 07
10 13 08 20 03 01 11 25 28 00 00 00 5B E9
10 13 08 20 03 01 11 25 29 00 00 00 2D 5D
10 13 08 20 03 01 11 25 2A 00 00 00 B6 81
10 13 08 20 03 01 11 25 2B 00 00 00 C0 35
10 13 08 20 03 01 11 25 2C 00 00 00 91 18
10 13 08 20 03 01 11 25 2D 00 00 00 E7 AC
10 13 08 20 03 01 11 25 2E 00 00 00 7C 70
10 13 08 20 03 01 11 25 2F 00 00 00 0A C4
10 13 08 20 03 01 11 25 30 00 00 00 C5 8D
10 13 08 20 03 01 11 25 31 00 00 00 B3 39
10 13 08 20 03 01 11 25 32 00 00 00 28 E5
10 13 08 20 03 01 11 25 33 00 00 00 5E 51
10 13 08 20 03 01 11 25 34 00 00 00 0F 7C
10 13 08 20 03 01 11 25 35 00 00 00 79 C8
10 13 08 20 03 01 11 25 36 00 00 00 E2 14
10 13 08 20 03 01 11 25 37 00 00 00 94 A0
10 13 08 20 03 01 11 25 38 00 00 00 40 4E
10 13 08 20 03 01 11 25 39 00 00 00 36 FA
10 13 08 20 03 01 11 25 3A 00 00 00 公元 26
10 13 08 20 03 01 11 25 3B 00 00 00 DB 92
10 13 08 20 03 01 11 25 3C 00 00 00 8A BF
10 13 08 20 03 01 11 25 3D 00 00 00 FC 0B
10 13 08 20 03 01 11 25 3E 00 00 00 67 D7
10 13 08 20 03 01 11 25 3F 00 00 00 11 63
这是一个迟到的答案，但希望这对其他 CRC 重新设计任务有所帮助：
您的 CRC 是所谓的“由 CCITT 指定的 16 位宽 CRC”的派生，但具有 "init value zero"。
CRC 是从示例数据的字节位置 3 到字节位置 12 计算的。例如
08 20 03 01 11 25 00 00 00 00
根据我们的CRC specification overview，完整的 CRC 规范是：
CRC:16,1021,0000,0000,No,No
问题不仅在于找到正确的 CRC 多项式，还在于找到以下答案：
- 数据的哪一部分包含在CRC计算中，哪些不包含
- 使用哪个初始值？应用最终异或值？
- 此算法是否期望反映输入或输出值？
同样，请参阅我们的手册说明或 Boost CRC library 了解这意味着什么。
我所做的是 运行 一个暴力脚本，它简单地尝试了几个流行的 16 位 CRC 多项式以及 start/end 位置、初始值、反映版本的各种组合。这是处理输出的样子：
Finding CRC for test message (HEX): 10 13 08 20 03 01 11 25 00 00 00 00 E9 64
Trying CRC spec : CRC:16,1021,FFFF,0000,No,No
Trying CRC spec : CRC:16,8005,0000,0000,No,No
Trying CRC spec : CRC:16,8005,FFFF,0000,No,No
Trying CRC spec : CRC:16,1021,FFFF,FFFF,No,No
Trying CRC spec : CRC:16,1021,0000,FFFF,No,No
Trying CRC spec : CRC:16,1021,0000,0000,No,No
Found it!
Relevant sequence for checksum from startpos=3 to endpos=12
08 20 03 01 11 25 00 00 00 00
CRC spec: CRC:16,1021,0000,0000,No,No
CRC result: E9 64 (Integer = 59748)
根据结果，我可以正确地重新计算您的示例电报的校验和
19.09.2016 12:18:12.764 [TX] - 10 13 08 20 03 01 11 25 00 00 00 00 E9 64
19.09.2016 12:18:14.606 [TX] - 10 13 08 20 03 01 11 25 01 00 00 00 9F D0
19.09.2016 12:18:16.030 [TX] - 10 13 08 20 03 01 11 25 02 00 00 00 04 0C
我上传了记录的 CRC finder example script which works with the free Docklight Scripting V2.2 评估。我认为这对于其他 CRC 重新设计难题也非常有用。
这个例子也帮助解决了Whosebug question 22219796
我正在通过 RS232 串口与伺服系统通信。我的伺服系统附带的内置功能太慢（57,600 波特端口上的简单 54 字节消息需要 25 毫秒），所以我尝试编写自己的通信功能，但是没有记录内置功能。我已经使用端口监视器来确定哪些信息正在发送到伺服系统，我需要帮助来破译结果。 我使用内置函数命令伺服 "goto" 递增步长（1、2、3 等）。这导致每个 "goto" 命令向伺服系统发送 5 个数据包。每个 "goto" 命令的前 4 个数据包是相同的。我在下面附上了大约 50 个十六进制数据包（每行 1 个）。如果您需要更多，post，我们可以一起解决。
10 13 04 20 00 01 B6 24 E9 68 10 13 04 20 00 00 AE 24 54 82 10 13 04 20 00 00 B5 24 8B 0B 10 13 04 20 00 01 43 01 71 9B
第 5 个数据包根据命令电机移动到的步长而变化。我在这里以 1 个数据包为例。我附上了一个包含大约 1000 个这些数据包的文件（每行 1 个）。
10 13 08 20 03 01 11 25 0A 00 00 00 81 CF
此数据包的前 8 个字节 (10 13 08 20 03 01 11 25) 似乎是实际的 "goto" 命令。无论指定什么步骤，它们都保持不变。 最后 6 个字节 (0A 00 00 00 81 CF) 根据请求的步骤而变化。在我附加的文件中，我指示伺服最初转到步骤“0”，然后是“1”、“2”等。前 4 个字节似乎是一个小端整数，对应于步数（即我上面显示的示例命令指示伺服转到十进制的第 10 步）。 我的问题是关于命令的最后 2 个字节。它们似乎随机变化，但只要指定的步骤相同，它们就会匹配。这让我相信这 2 个字节是某种校验和。我的问题是：校验和是如何计算的？ 我已经尝试对所有字节进行异或运算，包括单个字节和 2 个字节对，并且我尝试了 Fletcher 的校验和，以及一个简单的校验和（所有字节的总和）。我还检查了每种方法的 2 的补码（尽管我当然不介意有人检查以确保我没有在计算中出错）。有人有什么想法吗？
10 13 08 20 03 01 11 25 00 00 00 00 E9 64
10 13 08 20 03 01 11 25 01 00 00 00 9F D0
10 13 08 20 03 01 11 25 02 00 00 00 04 0C
10 13 08 20 03 01 11 25 04 00 00 00 23 95
10 13 08 20 03 01 11 25 05 00 00 00 55 21
10 13 08 20 03 01 11 25 06 00 00 00 CE FD
10 13 08 20 03 01 11 25 07 00 00 00 B8 49
10 13 08 20 03 01 11 25 08 00 00 00 6C A7
10 13 08 20 03 01 11 25 09 00 00 00 1A 13
10 13 08 20 03 01 11 25 0A 00 00 00 81 CF
10 13 08 20 03 01 11 25 0C 00 00 00 A6 56
10 13 08 20 03 01 11 25 0D 00 00 00 D0 E2
10 13 08 20 03 01 11 25 0F 00 00 00 3D 8A
10 13 08 20 03 01 11 25 10 10 00 00 00 17 FA
10 13 08 20 03 01 11 25 11 00 00 00 84 77
10 13 08 20 03 01 11 25 12 00 00 00 1F AB
10 13 08 20 03 01 11 25 13 00 00 00 69 1F
10 13 08 20 03 01 11 25 14 00 00 00 38 32
10 13 08 20 03 01 11 25 15 00 00 00 4E 86
10 13 08 20 03 01 11 25 16 00 00 00 D5 5A
10 13 08 20 03 01 11 25 17 00 00 00 A3 EE
10 13 08 20 03 01 11 25 18 00 00 00 77 00
10 13 08 20 03 01 11 25 19 00 00 00 01 B4
10 13 08 20 03 01 11 25 1A 00 00 00 9A 68
10 13 08 20 03 01 11 25 1B 00 00 00 EC DC
10 13 08 20 03 01 11 25 1C 00 00 00 BD F1
10 13 08 20 03 01 11 25 1D 00 00 00 CB 45
10 13 08 20 03 01 11 25 1E 00 00 00 50 99
10 13 08 20 03 01 11 25 1F 00 00 00 26 2D
10 13 08 20 03 01 11 25 20 00 00 00 DE 2A
10 13 08 20 03 01 11 25 21 00 00 00 A8 9E
10 13 08 20 03 01 11 25 22 00 00 00 33 42
10 13 08 20 03 01 11 25 24 00 00 00 14 DB
10 13 08 20 03 01 11 25 25 00 00 00 62 6F
10 13 08 20 03 01 11 25 26 00 00 00 F9 B3
10 13 08 20 03 01 11 25 27 00 00 00 8F 07
10 13 08 20 03 01 11 25 28 00 00 00 5B E9
10 13 08 20 03 01 11 25 29 00 00 00 2D 5D
10 13 08 20 03 01 11 25 2A 00 00 00 B6 81
10 13 08 20 03 01 11 25 2B 00 00 00 C0 35
10 13 08 20 03 01 11 25 2C 00 00 00 91 18
10 13 08 20 03 01 11 25 2D 00 00 00 E7 AC
10 13 08 20 03 01 11 25 2E 00 00 00 7C 70
10 13 08 20 03 01 11 25 2F 00 00 00 0A C4
10 13 08 20 03 01 11 25 30 00 00 00 C5 8D
10 13 08 20 03 01 11 25 31 00 00 00 B3 39
10 13 08 20 03 01 11 25 32 00 00 00 28 E5
10 13 08 20 03 01 11 25 33 00 00 00 5E 51
10 13 08 20 03 01 11 25 34 00 00 00 0F 7C
10 13 08 20 03 01 11 25 35 00 00 00 79 C8
10 13 08 20 03 01 11 25 36 00 00 00 E2 14
10 13 08 20 03 01 11 25 37 00 00 00 94 A0
10 13 08 20 03 01 11 25 38 00 00 00 40 4E
10 13 08 20 03 01 11 25 39 00 00 00 36 FA
10 13 08 20 03 01 11 25 3A 00 00 00 公元 26
10 13 08 20 03 01 11 25 3B 00 00 00 DB 92
10 13 08 20 03 01 11 25 3C 00 00 00 8A BF
10 13 08 20 03 01 11 25 3D 00 00 00 FC 0B
10 13 08 20 03 01 11 25 3E 00 00 00 67 D7
10 13 08 20 03 01 11 25 3F 00 00 00 11 63
这是一个迟到的答案，但希望这对其他 CRC 重新设计任务有所帮助：
您的 CRC 是所谓的“由 CCITT 指定的 16 位宽 CRC”的派生，但具有 "init value zero"。
CRC 是从示例数据的字节位置 3 到字节位置 12 计算的。例如
08 20 03 01 11 25 00 00 00 00
根据我们的CRC specification overview，完整的 CRC 规范是：
CRC:16,1021,0000,0000,No,No
问题不仅在于找到正确的 CRC 多项式，还在于找到以下答案：
- 数据的哪一部分包含在CRC计算中，哪些不包含
- 使用哪个初始值？应用最终异或值？
- 此算法是否期望反映输入或输出值？
同样，请参阅我们的手册说明或 Boost CRC library 了解这意味着什么。
我所做的是 运行 一个暴力脚本，它简单地尝试了几个流行的 16 位 CRC 多项式以及 start/end 位置、初始值、反映版本的各种组合。这是处理输出的样子：
Finding CRC for test message (HEX): 10 13 08 20 03 01 11 25 00 00 00 00 E9 64
Trying CRC spec : CRC:16,1021,FFFF,0000,No,No
Trying CRC spec : CRC:16,8005,0000,0000,No,No
Trying CRC spec : CRC:16,8005,FFFF,0000,No,No
Trying CRC spec : CRC:16,1021,FFFF,FFFF,No,No
Trying CRC spec : CRC:16,1021,0000,FFFF,No,No
Trying CRC spec : CRC:16,1021,0000,0000,No,No
Found it!
Relevant sequence for checksum from startpos=3 to endpos=12
08 20 03 01 11 25 00 00 00 00
CRC spec: CRC:16,1021,0000,0000,No,No
CRC result: E9 64 (Integer = 59748)
根据结果，我可以正确地重新计算您的示例电报的校验和
19.09.2016 12:18:12.764 [TX] - 10 13 08 20 03 01 11 25 00 00 00 00 E9 64
19.09.2016 12:18:14.606 [TX] - 10 13 08 20 03 01 11 25 01 00 00 00 9F D0
19.09.2016 12:18:16.030 [TX] - 10 13 08 20 03 01 11 25 02 00 00 00 04 0C
我上传了记录的 CRC finder example script which works with the free Docklight Scripting V2.2 评估。我认为这对于其他 CRC 重新设计难题也非常有用。
这个例子也帮助解决了Whosebug question 22219796