Open Hutker opened 3 years ago
Здравствуйте. Для того, чтобы разобраться "кто есть кто" в пакете, надо много разных пакетов от датчика, в т.ч. и после сброса. Может быть там код датчика не только C844. Так тоже бывает. В целом, полагаю, вы правы. Нужно ещё выяснить подходят ли последние два байта на роль контрольной суммы и CRC
Хорошо. Завтра сделаю запись множества пакетов и скину сюда. Этот датчик у меня 7 лет на ардуине работал и я его через этот код C844 разбирал с помощью библиотеки ookDecoder. У него протокол v3. Если нужен этот старый код с ookDecoder'ом то могу тоже закинуть, там CRC считалось без проблем
Собрал пакеты и прикрепил в файл. 10 штук с разной температурой: 46.0s 3 p C8441EE08810A419A55 0ms 311.0s 3 dp C8441EE078109458202 0ms 893.8s 3 C8441EE06810842DA55 0ms 1741.8s 3 C8441EE0581074B2... 1ms 2059.8s 3 d C8441EE0481064C75A6 1ms 2801.8s 3 d C8441EE0381054EDEDE 0ms 3278.8s 3 C8441EE028104498659 1ms 3914.8s 3 C8441EE018103407101 0ms 4550.8s 3 d C8441EE008102472... 1ms 4709.8s 3 d C8441EE09710A450... 0ms
Добавил ваш датчик в библиотеку. Скачайте, проверьте. Там расчёт CRC оказался похож на THN132.
Большое спасибо! Датчик распознается отлично! pack2.txt Если вдруг найдутся какие либо ошибки, то обязательно сообщу.
Есть еще небольшой вопрос. Когда Вы изучали протокол Oregon Scientific RF Protocols для написания этой библиотеки, то не встречали ли описание пакетов передачи данных от погодной станции Oregon Scientific I300 или I600? У пакетов вот такой вид: 00A5012A302400000000000000000000000000000000052 1ms 00A5012A302400000000000000000000000000000000052 1ms 2915012A302101037371037371037372E10200071D2D8D6 1ms 2915012A302101037371037371037372E10200071D2D8D6 1ms Сейчас занимаюсь их расшифровкой и попытаюсь на основе Вашей библиотеки написать программу для передатчика через NodeMCU
Нет, с таким не сталкивался. Кстати, если у вас есть живой осадкометр, давайте уж с ним до конца разберёмся. Нужны с него пара-тройка различающихся пакетов длиной 22-24 нибла, Сделаете? Я тогда посчитаю для него CRC и добавлю в библиотеку
Скачайте библиотеку заново. Там кое что подправил, в т.ч. в ашнике можно изменением PACKET_LENGTH выделять память под пакеты большой длины. Вам это возможно поможет. И с вас образцы пакетов с осадкометра...
да, спасибо, я уже подправил код на 48 ниблов под свою метеостанцию. Пакеты сегодня запарсил, но если мало, могу наловить больше. pack.txt
Спасибо. добавил в библиотеку проверку CRC8 для PCR800. Проверьте у себя, если данные с датчика будут расшифровываться, как и прежде, значит всё правильно.
Проверил. Все прекрасно работает с обновленной библиотекой и PCR800 распознается без проблем! Огромное спасибо!
Я вижу, что Вы хорошо разбираетесь в алгоритмах расчета crc. Не могли бы Вы помочь расшифровать алгоритм контрольной суммы пакетов от метеостанции? Там 4 нибла и первые два я расшифровал - это простая сумма всех предыдущих байтов. А вот с последними двумя какая то засада(
Пакеты
flow2.txt
Я вас разочарую - я очень плохо разбираюсь в этих алгоритмах. Но выучил простое правило - у Орегона последний байт посылки - это обычно CRC8 за ислючением контрольной суммы и ID датчика. Образующий полином - 07h, а вот стартовая сумма бывает разная . Для её поиска у меня написана утилитка. Причешу её и выложу.
В общем, выдаю удочку, ловить будете сами :). Скачайте библиотеку заново и воспользуйтесь утилитой в примерах. Нужно забить данные с трёх разных пакетов и выставить размер посылки. Утилита выдаст параметры (если найдёт) для подсчёта CRC8, которые будут нужны при вызове check_oregon_crcsum().
Благодарствую, барин! Вечером затестим "шайтан-машину")
да прога хорошая! crc хорошо считает даже на "левых" датчиках из интернета) Я добавил функцию разбивки на байты из строки, т к это проще и быстрее hexCharacterStringToBytes(data1, "1D2025D121204446301"); hexCharacterStringToBytes(data2, "1D2025D131204447360"); hexCharacterStringToBytes(data3, "1D2025D141205449317"); Можно и Serial.read() впихнуть при желании) Жаль только не помогла в расшифровке моих больших пакетов(
Ну так надо искать в чём дело. Может в длинных пакетах не исключены из расчёта 6-ой и 7-ой ниблы?
да я по разному пробывал и 6,7 ниблы исключал и другие. Пакет 2 самый короткий - 43нибла и в нем полином находится, а вот в других никак. Пробывал их сократить до 43ниблов, но тоже не дает результата
Взял из вашего файла несколько образцов:
для посылок 49 ниблов 00A5012A302400000000000000000000000000000000052F6 00A5012A3023000000000000000000000000000000000421C 00A5012A30220000000000000000000000000000000003212 Получаем POLY = 7, START_SUM= 5
а для посылок 47 ниблов 2915012A3021010171700171710F6F62E1020006032E8AE 2915012A3021010171700171710F6F62E1020007032F8DB Получаем POLY = 7, START_SUM= 14
Всё вроде сходится...
да Вы просто гений! Я почему то не догадался отфильтровать пакеты по первому байту и фильтровал только по длине посылки. А теперь все сошлось. Большое спасибо! Напишите, куда отправить Вам "благодарность" на пивасик)
Тут провёл кое-какие изыскания и немного переписал расчёт CRC для датчиков третьей версии. Ну и пример для расчёта обновил. для v3.0 оказалось, что начальная сумма везде нулевая и при расчёте используется ID. Т.е. они унифицировали метод расчёта
Добрый день! Протестировал Вашу библиотеку Oregon_NR в своем проекте метеостанции. Все работает отлично. Большое спасибо! Использовал датчик THGN132N и на нем декодер работает без проблем. Так же тестировал дождемер PCR800 и для него воспользовался модифицированной библиотекой Saphareas/Oregon_NR. И этот датчик работает без проблем. У меня еще есть термометр THN800. Можно ли его добавить в библиотеку? Пакет имеет вид C8441EE16810949B..., он короче, чем у THGN132N C8441EE16810949B... Код датчика C844 CHNL: 0 TMP: 18.6C BAT: F ID: EE если я правильно перевел)