Найдите алгоритм, который генерирует контрольную сумму

У меня есть сенсорное устройство, которое передает 6-байтовое сообщение вместе с 1-байтовым счетчиком и предположительно контрольной суммой.

Данные выглядят примерно так:

------DATA----------- -Counter- --Checksum?--

55 FF 00 00 EC FF ---- 60---------- 1F

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

Теперь мне нужно найти алгоритм для вычисления этой контрольной суммы на основе -DATA-. то, что я пробовал, - это все возможные полиномы CRC-8, для каждого полинома я пытался отразить данные, переключить их, инициировать с ненулевыми значениями и т. д. Я пришел к выводу, что я не имею дело с нормальным CRC- алгоритм. Я также безуспешно пробовал некоторые методы flether и adler, вещи xor взад и вперед, но все же я не знаю, как сгенерировать контрольную сумму.

Меня больше всего беспокоит, как используется счетчик ??? Те же данные, но с другим значением счетчика, генерируют разные контрольные суммы. Я попытался включить счетчик в свои вычисления, но безуспешно.

Вот еще несколько примеров данных:

55 FF 00 00 F0 FF A0 38  
66 0B EA FF BF FF C0 CA  
5E 18 EA FF B7 FF 60 BD  
F6 30 16 00 FC FE 10 81  

Еще одна вещь, о которой, возможно, стоит упомянуть, это то, что последний байт данных принимает только значения FF или FE.

Пожалуйста, если у вас есть какие-либо советы или уловки, которые я могу попробовать опубликовать здесь, я действительно в отчаянии.

Спасибо


crc
person knivmannen    schedule 24.05.2010    source источник
comment
Я думаю, что ваш лучший вариант - изучить документацию по оборудованию ... Может быть, на нем есть какой-то серийный номер, который поможет вам его идентифицировать.   -  person fortran    schedule 24.05.2010
comment
Привет, у меня нет документации для просмотра. У меня больше данных, чем указано выше, но это все.   -  person knivmannen    schedule 24.05.2010
comment
6-байтовое сообщение вместе с 1-байтовым счетчиком и якобы контрольной суммой - это правда? Просто спрашиваю, так как вы, кажется, очень мало знаете об устройстве.   -  person Jonas Elfström    schedule 24.05.2010
comment
Это не факт, это предположения. Я могу с уверенностью сказать, что счетчик - это счетчик, просто взглянув на данные. Предполагается, что последний байт является контрольной суммой. Если это не так, я совершенно не понимаю.   -  person knivmannen    schedule 24.05.2010


Ответы (1)


Несколько случайных идей:

  1. Порядок битов: в настоящее время вы представляете данные в виде октетов, но алгоритм CRC видит это иначе. CRC работают с полиномами, представленными в виде массивов битов, а не массивов октетов. Из-за этого возможно, что устройство выполняет CRC, используя схему порядка битов, отличную от той, которую вы используете.
  2. В зависимости от устройства, я бы сказал, весьма вероятно, что счетчик включен в расчет CRC.
  3. Если это встроенное устройство, оно может использовать другой код, например BCH.

Есть ли еще какая-либо информация о рассматриваемом устройстве?

Это может дать некоторое представление о том, насколько сильное кодирование было использовано. Например, определенный CRC-12 (0x8F8) обеспечивает расстояние Хэмминга от 5 до длины слова данных 53 бит (в ваших данных слово данных может быть 52 бит, при условии, что размер CRC составляет 12 бит).

Изменить: см. ответ в Как я мог угадать алгоритм контрольной суммы? для некоторых дополнительных идей.

person Schedler    schedule 24.05.2010
comment
Привет, 1. Да, я подумал об этом (думаю). Вместо этого я прочитал байты, начиная справа, я также отразил каждый байт. Я не менял местами байты, но мало верю, что это так. 2. Есть ли счетчик, чтобы перепутать это из-за низкого разнообразия в сообщении или как? 3. Я не уверен в этом. Я проверю BCH. К сожалению, у меня не так много информации, чтобы дать вам больше информации. Этот датчик используется в автомобильной промышленности для измерения ускорения объекта. - person knivmannen; 24.05.2010
comment
3. После некоторых размышлений я мог бы подумать, что BCH очень маловероятен, учитывая большое количество бит данных по сравнению с небольшим количеством контрольных бит. Вы уже знаете, как интерпретировать данные? Это может дать некоторые идеи об общей структуре фрейма данных. - person Schedler; 24.05.2010
comment
У меня есть указания, что означают разные байты, но точно нет. Я не уделял этому слишком много внимания, так как полагал, что не имеет значения, что они на самом деле представляют. - person knivmannen; 24.05.2010
comment
Я разговаривал с коллегой, и он был в некоторой степени уверен, что по крайней мере второй байт (считая с левой стороны) был рысканием, а байты 5 и 6 - боковыми ускорениями. Я не понимаю, чем это может быть полезно. - person knivmannen; 24.05.2010