Контрольные суммы последовательной связи RS232?

Question

Я общаюсь с сервоприводом через последовательный порт RS232. Встроенные функции, поставляемые с моим сервоприводом, слишком медленные (25 мс для простого 54-байтового сообщения на 57 600 бодах), поэтому я пытаюсь написать свои собственные функции связи, однако встроенные функции не документированы. Я использовал монитор портов, чтобы определить, какая информация отправляется сервоприводу, и мне нужна помощь в расшифровке результатов. Я использовал встроенные функции, чтобы подать команду сервоприводу на "пошаговое" наращивание шагов (1, 2, 3 и т. Д.). В результате 5 пакетов были отправлены сервоприводу для каждой команды goto. Первые 4 пакета идентичны для каждой команды goto. Я приложил около 50 шестнадцатеричных пакетов ниже (1 на строку). Если вам нужно больше, напишите, и мы можем что-нибудь придумать.

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 байта являются некоторой контрольной суммой. Мой вопрос к вам: как рассчитывается контрольная сумма? Я уже попробовал xor'ing все байты, как по одной, так и в двухбайтовых парах, и я попробовал контрольную сумму Флетчера и простую контрольную сумму (сумму всех байтов). Я также проверил дополнение 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 AD 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

Answer 1

Это поздний ответ, но, надеюсь, это поможет другим задачам реинжиниринга CRC:

Ваш CRC является производным от так называемого "CRC 16-битной ширины, как обозначено CCITT", но с "нулевым значением инициализации".

CRC рассчитывается от позиции байта 3 до позиции байта 12 данных вашего примера. например

08 20 03 01 11 25 00 00 00 00

Полная спецификация CRC в соответствии с нашим обзором спецификаций CRC:

CRC:16,1021,0000,0000,No,No

Проблема заключалась не только в том, чтобы найти правильный полином CRC, но и в поиске следующих ответов:

• Какая часть данных включена в расчет CRC, а какая нет.
• Какое значение инициализации использовать? Применить окончательное значение xor?
• Этот алгоритм ожидает отраженных входных или выходных значений?

Снова, посмотрите наше ручное описание или библиотеку Boost CRC о том, что это значит.

Я выполнил сценарий грубой силы, который просто пробовал несколько популярных 16-битных полиномов CRC со всеми видами комбинаций начальных / конечных положений, начальных значений, отраженных версий. Вот как выглядит результат обработки:

 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, который работает с бесплатной оценкой Docklight Scripting V2.2. Я предполагаю, что это может быть очень полезно и для других задач по реинжинирингу CRC.

Пример также помог решить вопрос Stackru 22219796