Похоже что CRC это два байта перед завершающим символом 0xDD
Но первый байт принимает значение 0x00, 0x80 и 0x88 (может быть еще 0x08 но не встречал)
Второй уменьшается по мере увеличения суммы байт команды
Самое большое значение 0x77, потом идет 0x00
Уверенны, что выбрали правильную скорость передачи данных? Прежде чем ломать протокол, надо убедиться, в стабильности принимаемых/отправляемых байт при одинаковых условиях работы устройств. А CRC - это всегда 2 последних байта, и алгоритмы их вычисления известны из таблиц (это не секрет какой то) . Если идёт плавание данных, то скорость выбрана неправильно. А вообще, датчику этот CRC нафик не упёрся. Вряд ли он там вообще есть.
Байты хвоста: в первом используются только два старших бита в каждом полубайте. Во втором по три младших. Из приведенных примеров достаточно было бы одного финального байта, если там не заложено на большее. Иначе какая-то систематическая ошибка. Согласен с версией про скорость.
Вы выделили структуру пакетов? Где адреса, где данные?
Первый байт - заголовок 0xDB
Затем два байта дублируется (зачем то?) адрес
Потом команда с аргументами (встречал 2 и 4 байта)
Потом эти самые полубайты CRC
И замыкающий 0xDD
В ответе первый байт 0xEA
Потом непонятно
Последние три байта аналогичны команде
Скорость и параметры UART подбирал разные
Везде кроме 9600 8N1 датчик просто е отвечает
Есть ответ га 9600 8O1 и 9600 8E1 но там структура пакета разваливается (завершающий постоянно разный
Ну и в ответе я четко нашел байт растояние
Какую сторону вам надо эмулировать? Контроллер или датчик? Если время поджимает, а память есть, для запросов можно и таблицу составить.
Обратите внимание на закономерность адреса и первого байта хвоста.
В запросах в последнем байте уж очень стабильная повторяющаяся цикличность, как бы не счетчик оказался. Как минимум, хорошо бьется с адресом.
7 5 3 1 с 0 и 7 5 3 1 с 8. И так периодически. Сторону запроса таблично подобрать не сложно.
Команда запроса только 0х70?
Кажется что первая цифра из 0х88 (8 пока что) дополняет команду, вторая из 0х88 (0 или 8) дополняет адрес.
Мля методики нет у вас, скорость 9600, в даташите сказано, подсоедините один а не зоопарк, шлите команду на чтение получайте ответ и увеличивайте расстояние до объекта.
Тогда хоть что то понять будет можно.
Еще одна проверка. Являются ли контрольные биты зависимыми друг от друга, или нет. Несколько исходных пакетов отличающихся только в одном разряде в каких-либо байтах (не обязательно только в одном). Влияет ли это на 1 бит контрольной суммы, или на всю? Пока что по виду предполагаю независимость. Банальный XOR ведь проверили? По всему пакету, по пакету без разметки, по пакету без разметки и повторений.
По всему-то смысла нет, если рассматривать стандартное строение фрейма. Хотя, зная китайцев, можно предположить, что они считают всё, кроме трёх байт из середины.
