Arduino.ru

За помошь закину баланс на тел. :)

Берите калькулятор и считайте сами. На сколько хватит фантазии.))

Если бы не получилось не писал бы, не как не могу решить. Может кто лучше разбирается

почитайте этот топик, для начала

этот на второе

Поймал вот такие два пакета у которых у обоих Контрольная сумма равна 00:

A5 5A 05 CC 01 00 AE

A5 5A 0F C1 02 00 AE

Если суммировать 05+СС+01=D2 также 0F+C1+02=D2 но не как не 00

Прогнал по всем стандартным CRC  на сайте http://crccalc.com/ без результатно. Пересобрал и прогнал те примеры которые отправил Гриша тоже не работает.

Значит один пакет битый или 00 - не контрольная сумма.

У Вас вообще непонятно контрольную сумму чего считать. В исходном сообщении Вы утверждали, что третье число 05 это длина пакета. Какие пять байт из Ваших шести "пакет"? А теперь там уже не 05, а 0F. Ну и где 15 байт? Так что у Вас даже исходных данных для подбора контрольной суммы нет.

Оригинальное пакет был такой я просто его сократил: A5 5A 0F C1 02 00 00 00 00 00 00 00 00 00 00 00 AE там было 10 нулей

жесть! Ышо  одна жыжыгалка

Мужик ты крут. Выкинуть нули из пакета это пять! Воткни в любой онлайн калькулятор свои строчки и добавляй нули в HEX. Наслаждайся изменением CRC8 после каждого следующего нуля. Казалось бы,причем здесь нули?   

Смотри, сокращалка: в алгоритме контрольной суммы может участвовать, например, не только значение байта, но и его позиция в пакете, и длина пакета в байтах. Смекаешь? Это я к тому, что порой удивляет - да ничо страшного, я тут сократил, догадайтесь, какой длины пакет и как считается контрольная сумма.

Не останавливайся на достигнутом: сократи пакет до одного байта, и попроси угадать, как там считается контрольная сумма. И не обращай ни на что внимания - нули там, не нули - просто тупо сокращай по самые помидоры, всё равно тут каждый второй с натёртым хрустальным шаром сидит, трепеща в ожидании вот таких вот угадывательных задач.

Ма-ла-дца!

Может, лучше заняться макраме?

Убрал нули потому что тут сумма без полинома я это понял из следующего E7 01 = E8 00. Что то делают с суммой и получается этот проверочный байт который в конце. Также если поменять местами байты в данных то не меняется проверочный байт что не характерно для полиномных контрольных сумм.

Самое непонятное что если я увеличиваю значение сумма то растет то уменьшается (два раза растет потом куда то прыгает):

Any ideas...

Идея: хачьте исходник. 

Вы бы хоть написали, что это за секретные команды такие, от кого кому. На всякий случай. Может у кого подробное описание лежит, а мы тут гадаем...

Программа по управлению Беспилотно летательных апаратов GSC. Управляется по UART. Разного рода команды ручное управление, посадка итд.

а вы уверены, что эти пакеты не используют шифрование? Вообще-то все, что работает на расстоянии дальше 15-20м, обычно не шлет данные в открытом виде.

Я смотрю, у вас в пакете 17 байт - может это 16 байт простейшего блока AES128 + 1 байт окончания пакета?

Не дороговато ли по ресурсам на леталках AES закручивать/раскручивать?

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

Видел в сети тесты ардуиновских АЕS библиотек -  атмега328 успевает шифровать UART примерно до 38 или 57кбод. Правда ничего другого уже не делает :)

//Убрал нули потому что тут сумма без полинома я это понял из следующего E7 01 = E8 00.

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