Контрольная сумма

[OakRidge]

Упало на мою голову делать реверс, три недели верчусь
Серийный протокол. Работает в условиях неслабых помех.
Первый байт 0x24 само собой
Второй и третий данные. Какой бит для чего проверял. Сходится.
Четвертый и пятый должны быть контролем. Затык однако. Как вычислить понятия не имею.
Сложение, вычитание, XOR не работают. Дешифратор младший ПИК 8 бит. Без аппаратного умножения.
Может нечто с коррекцией ошибок заложено. Непонятно
Ну не в Блечли Парке живу, никакой не Алан Тюринг .....
Мне бы маленькую подсказку

 0x24, 0xFF, 0xF9, 0xD0, 0xB3  
 0x24, 0x7F, 0xF9, 0xD0, 0x33  
 0x24, 0x7F, 0xA4, 0x30, 0xCA  
 0x24, 0xFF, 0xB0, 0xB0, 0xBC  
 0x24, 0xFF, 0x30, 0xB0, 0x3C  
 0x24, 0xFF, 0x24, 0x30, 0xCA  
 0x24, 0xFF, 0x8E, 0x8C, 0xA3  
 0x24, 0xFF, 0xFF, 0x8C, 0xCA  
 0x24, 0xBF, 0xA4, 0x10, 0x72  
 0x24, 0xBF, 0xF9, 0x90, 0x93  
 0x24, 0xFF, 0xC0, 0x50, 0x0C  
 0x24, 0xFF, 0xF9, 0xD0, 0xB3  
 0x24, 0xFF, 0xA4, 0x30, 0x2A  

 Еще
 24  F9  F9  A8  EE  
 24  82  80  72  2D  
 24  82  82  32  4F

[Ara41]

Вряд ли в младшие ПИК влезет какой-то серьезный алгоритм црц. Какой-то самопал. Нет данных с одинаковыми 2-3 байтами? Типа FF FF. Было бы легче анализировать.

[mike-y-k]

OakRidge, стоит попробовать отсюда - может удасться подобрать алгоритм.

Ara41, так если они одинаковые, то что это облегчит
А так - 8-я строка именно FF FF…

[OakRidge]

Сей обмен идет на скорости 18 килобит. По обычным проводам. Без экрана, без витой пары.
Один провод CLOCK, второй данные, типа LIN, I2C вроде.
Там мерял конденсаторы на входах после делителя 150К+100K. 12пФ, поставил 47пФ. Бу менять на 22.
Вроде заработало без неких битов. Без контроля.
Шину слушлал SALEAE с добавкой декодера на контроллере.
Было что напутать

[Vlad German]

Еще можно попробовать этот калькулятор http://www.sunshine2k.de/coding/java...rc/crc_js.html, может быть подойдет какой-то алгоритм

[Vlad German]

И еще одна ссылка: http://reveng.sourceforge.net/

[makakus]

Какой смысл делать crc16 для двух байт?! Дешевле их повторить ещё раз, можно в инверсном виде.
Младший пик вполне потянет crc8.
Многие сети довольствуются не crc, а контрольной суммой, простым сложением.

[vavan1983]

Пользовался для передачи по радиоканал usart этим

unsigned __int16 in_cksum ( unsigned __int16 *ptr, int nbytes ) 
{ 
register unsigned __int32 sum; 
unsigned __int16 oddbyte; 
register unsigned __int16 answer; 
sum = 0; 
while ( nbytes › 1 ) 
{ 
sum += *ptr ++; 
nbytes -= 2; 
} 
if ( nbytes == 1 ) 
{ 
oddbyte = 0; 
* (( unsigned char *) &oddbyte ) = * (unsigned char *) ptr; 
sum += oddbyte; 
} 
sum = ( sum ›› 16 ) + ( sum & 0xFFFF); 
sum += (sum ›› 16 ); 
answer=~sum; 
return (answer); 
} 
unsigned __int16 aaa[4] = {0x398a, 0xf802, 0x14b2, 0xc281}; 
unsigned __int16 bbb; 
int main() 
{ 
bbb = in_cksum (aaa, sizeof(aaa)); 
cout ‹‹ hex ‹‹ bbb ‹‹ endl; 
getch(); 
}

[OakRidge]

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

[vavan1983]

Ну а зачем тебе crc если это дисплей он же все равно без диалога с контроллером обмениваются данными