Расшифровка контрольной суммы/CRC

Я пытаюсь выяснить, как проверить ошибки в следующих потоках данных. Данные поступают от коммерческого пульта дистанционного управления для программирования электрических радиаторных обогревателей.

Я тщательно изучил большинство протоколов IR (RC5, NEC и т. д.), и, насколько я могу судить, он не подходит ни для одного из них. Однако я не могу подтвердить, что это не ИК-порт.

Аппаратное обеспечение, которое я использую, представляет собой стандартный приемник Vishay IR 38 кГц, подключенный к старому ПК с запущенной WinLIRC, поэтому я могу видеть необработанную последовательность импульсов/пространств и подтверждаю с помощью различных тестов/настроек основные параметры в конфигурации (такие как время штамп с разрешением до секунд), что данные выводятся через ИК в виде 10-битного, одного стартового бита, 8-битного байта данных и стопового бита. Затем я инвертировал байты данных, поменяв местами биты MSB-LSB, чтобы добраться до точки, которая соответствует расписанию программирования.

Единственным камнем преткновения для меня является последний байт, который, как я считаю, является проверкой ошибок, я знаю это, потому что я настроил тестовую установку для отправки данных с другой проверкой ошибок, и нагреватель не принимает их, и с правильным значение, как записано, принимается.

Ниже показан поток данных, за которым следуют еще 2 итерации, но с отметкой времени, опережающей на 1 секунду в каждом случае. Я вижу некоторое математическое сходство между проверками ошибок, но я пробовал все 8-битные CRC/контрольные суммы XOR, методы декодирования сложения, вычитания и т. д., а также использовал reveng, который не дал ответа.

Любая помощь в этом очень ценится!

1-Й РАУНД ДАННЫХ

ДВОИЧНЫЕ ШЕСТНАДЦАТИЧНЫЕ ДЕСЯТИЧНЫЕ ПРИМЕЧАНИЯ

11111111 FF 255
00000000 0 0
00001111 F 15
10110011 B3 179
01001100 4C 76
00000000 0 0
00000000 0 0 0
3 0 0 0
0 0 0 1 0 0 0 0 0 1 0 0 0 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
0 0 0000000 br> 00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000000 0 0
000 00000 0 00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 0 0
0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
000000 11 3 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
0 0000 0
00000011 3 3
00000010 2 2 ЧАСА
00010010 12 18 МИНУТ
00000000 0 0 СЕКУНД
01101011 6B 107 ПРОВЕРКА CRC?

2-Й РАУНД ДАННЫХ ТАК ЖЕ, ЧТО 1-Й РАУНД ДО СЕКУНД ОТ МЕТКИ ВРЕМЕНИ: -

00000001 1 1 СЕКУНДЫ
00110101 35 53 ПРОВЕРКА CRC?

3-Й РАУНД ДАННЫХ ТАК ЖЕ, КАК 1-Й РАУНД, ДО СЕКУНД ОТ МЕТКИ ВРЕМЕНИ: -

00000010 2 2 СЕКУНДЫ 11010111 D7 215 CRC ПРОВЕРИТЬ?

4-Й РАУНД ДАННЫХ ТАК ЖЕ, КАК 1-Й РАУНД ДО СЕКУНДЫ ВРЕМЕНИ: -

00000011 3 3 СЕКУНДЫ
10001001 89 137 ПРОВЕРКА CRC?

5-Й РАУНД ДАННЫХ ТАК ЖЕ, КАК 1-Й РАУНД, ДО СЕКУНД ОТ МЕТКИ ВРЕМЕНИ: -

00000100 4 4 СЕКУНДЫ
00001010 ПРОВЕРКА 10 CRC?

6-Й РАУНД ДАННЫХ ТАК ЖЕ, КАК 1-Й РАУНД, ДО СЕКУНД ОТ МЕТКИ ВРЕМЕНИ: -

00000101 5 5 СЕКУНД
01010100 54 84 ПРОВЕРКА CRC?

7-Й РАУНД ДАННЫХ ТАК ЖЕ, КАК 1-Й РАУНД ДО ОТМЕТКИ ВРЕМЕНИ МИНУТ: -

00011000 18 24 МИНУТЫ
00001101 D 13 СЕКУНД
01110001 71 113 ПРОВЕРКА CRC?

8-Й РАУНД ДАННЫХ ТАК ЖЕ, КАК 1-Й РАУНД ДО ОТМЕТКИ ВРЕМЕНИ МИНУТ: -

00011011 1B 27 МИНУТ
00111011 3B 59 СЕКУНД
01000111 47 71 ПРОВЕРКА CRC?


person AaronT    schedule 28.11.2017    source источник
comment
Нужно больше данных. Пожалуйста, предоставьте не менее десяти образцов. Если вы можете получить несколько для сообщений разной длины, это также будет полезно.   -  person Mark Adler    schedule 28.11.2017
comment
Привет, вот еще некоторые данные, я включил то же самое выше для простоты: -   -  person AaronT    schedule 30.11.2017
comment
4-Й РАУНД ДАННЫХ ТАК ЖЕ, КАК 1-Й РАУНД ДО ОТМЕТКИ ВРЕМЕНИ СЕКУНДЫ: - 00000011 3 3 СЕКУНДЫ 10001001 89 137 CRC CHECK? 5-Й РАУНД ДАННЫХ ТАК ЖЕ, ЧТО 1-Й РАУНД ДО ОТМЕТКИ ВРЕМЕНИ СЕКУНД: - 00000100 4 4 СЕКУНДЫ 00001010 ПРОВЕРКА 10 CRC? 6-Й РАУНД ДАННЫХ ТАК ЖЕ, ЧТО 1-Й РАУНД ДО ОТМЕТКИ ВРЕМЕНИ СЕКУНДЫ: - 00000101 5 5 СЕКУНД 01010100 54 84 ПРОВЕРКА CRC?   -  person AaronT    schedule 30.11.2017
comment
7-Й РАУНД ДАННЫХ ТАК ЖЕ, КАК 1-Й РАУНД ДО ОТМЕТКИ ВРЕМЕНИ МИНУТЫ: - 00011000 18 24 МИНУТЫ 00001101 D 13 СЕКУНД 01110001 71 113 ПРОВЕРКА CRC? 8-й РАУНД ДАННЫХ ТАК ЖЕ, ЧТО 1-Й РАУНД ДО ОТМЕТКИ ВРЕМЕНИ МИНУТ: - 00011011 1B 27 МИНУТ 00111011 3B 59 СЕКУНД 01000111 47 71 CRC CHECK?   -  person AaronT    schedule 30.11.2017
comment
не знаю, как добавить комментарий большего размера, поэтому я разбил данные, а также теперь неправильное форматирование .... может быть, мне следует начать еще один пост?   -  person AaronT    schedule 30.11.2017
comment
Вместо комментариев отредактируйте вопрос.   -  person Mark Adler    schedule 30.11.2017


Ответы (2)


CRC RevEng легко находит решение исходной проблемы. Это командная строка Bash для компактности: -

reveng -w 8 -s ff000fb34c00000003000000000003000000000003000000000003000000\
00000300000000000300000000000300000302\
{12006b,120135,1202d7,120389,12040a,120554,180d71,1b3b47}

который возвращает: -

width=8  poly=0x31  init=0xa5  refin=true  refout=true  xorout=0x00  check=0x67  residue=0x00  name=(none)

Поскольку все потоки имеют одинаковую длину, CRC RevEng не может вычислять одновременно Init и Xorout. xorout=0x00 - это предположение, которое заставляет init=0xa5 правильно вычислять потоки в наборе задач. Потоки длиной, отличной от 52 байтов, потребуют оба параметра, и нахождение одного из них даст вам средства для их вычисления.

poly=0x31 появляется только один раз в Каталоге под CRC-8/MAXIM, что тоже отражено, но имеет init=0x00; если это действительно используемый алгоритм, то init=0xa5 – это образ байтов, передаваемых в алгоритм, которого быть не должно (т. е. первые n символов не будут передаваться в CRC-8/MAXIM); к сожалению, я не смог найти префикс потоков данных, равный начальному значению 0xa5.

Если вам нужен код для расчета этих CRC, доступны другие пакеты, которые преобразуют выходные данные модели Rocksoft™ с помощью CRC RevEng в язык C, например pycrc или crcany Марка Адлера.

person regregex    schedule 01.12.2017

Спасибо Спасибо!!! Вы попали! Абсолютно блестящий! Я попробовал еще раз в отместку, но так и не смог ничего получить, даже скопировав ваш пример. Итак, я попробовал это на этом сайте: -

http://www.sunshine2k.de/coding/javascript/crc/crc_js.html

включая последний байт, с найденным вами poly и init и бинго!

Мой поток данных всегда одинаков, 52 байта.

Еще раз большое спасибо всем за помощь с форматированием и т. д., и, конечно же, за ответ!

Аарон Т.

person AaronT    schedule 01.12.2017