Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

THN800 #12

Open
Hutker opened this issue Sep 20, 2020 · 21 comments
Open

THN800 #12

Hutker opened this issue Sep 20, 2020 · 21 comments

Comments

@Hutker
Copy link

Hutker commented Sep 20, 2020

Добрый день!
Протестировал Вашу библиотеку Oregon_NR в своем проекте метеостанции. Все работает отлично. Большое спасибо! Использовал датчик THGN132N и на нем декодер работает без проблем. Так же тестировал дождемер PCR800 и для него воспользовался модифицированной библиотекой Saphareas/Oregon_NR. И этот датчик работает без проблем.
У меня еще есть термометр THN800. Можно ли его добавить в библиотеку?
Пакет имеет вид C8441EE16810949B..., он короче, чем у THGN132N
C8441EE16810949B...
Код датчика C844
CHNL: 0
TMP: 18.6C
BAT: F
ID: EE
если я правильно перевел)

@invandy
Copy link
Owner

invandy commented Sep 20, 2020

Здравствуйте.
Для того, чтобы разобраться "кто есть кто" в пакете, надо много разных пакетов от датчика, в т.ч. и после сброса. Может быть там код датчика не только C844. Так тоже бывает.
В целом, полагаю, вы правы. Нужно ещё выяснить подходят ли последние два байта на роль контрольной суммы и CRC

@Hutker
Copy link
Author

Hutker commented Sep 21, 2020

Хорошо. Завтра сделаю запись множества пакетов и скину сюда. Этот датчик у меня 7 лет на ардуине работал и я его через этот код C844 разбирал с помощью библиотеки ookDecoder. У него протокол v3. Если нужен этот старый код с ookDecoder'ом то могу тоже закинуть, там CRC считалось без проблем

@Hutker
Copy link
Author

Hutker commented Sep 22, 2020

Собрал пакеты и прикрепил в файл. 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

pack.txt

@invandy
Copy link
Owner

invandy commented Sep 23, 2020

Добавил ваш датчик в библиотеку. Скачайте, проверьте. Там расчёт CRC оказался похож на THN132.

@Hutker
Copy link
Author

Hutker commented Sep 23, 2020

Большое спасибо! Датчик распознается отлично!
pack2.txt
Если вдруг найдутся какие либо ошибки, то обязательно сообщу.

@Hutker
Copy link
Author

Hutker commented Sep 23, 2020

Есть еще небольшой вопрос. Когда Вы изучали протокол Oregon Scientific RF Protocols для написания этой библиотеки, то не встречали ли описание пакетов передачи данных от погодной станции Oregon Scientific I300 или I600?
У пакетов вот такой вид:
00A5012A302400000000000000000000000000000000052 1ms
00A5012A302400000000000000000000000000000000052 1ms
2915012A302101037371037371037372E10200071D2D8D6 1ms
2915012A302101037371037371037372E10200071D2D8D6 1ms
Сейчас занимаюсь их расшифровкой и попытаюсь на основе Вашей библиотеки написать программу для передатчика через NodeMCU

@invandy
Copy link
Owner

invandy commented Sep 24, 2020

Нет, с таким не сталкивался.
Кстати, если у вас есть живой осадкометр, давайте уж с ним до конца разберёмся. Нужны с него пара-тройка различающихся пакетов длиной 22-24 нибла, Сделаете? Я тогда посчитаю для него CRC и добавлю в библиотеку

@invandy
Copy link
Owner

invandy commented Sep 25, 2020

Скачайте библиотеку заново. Там кое что подправил, в т.ч. в ашнике можно изменением PACKET_LENGTH выделять память под пакеты большой длины. Вам это возможно поможет. И с вас образцы пакетов с осадкометра...

@Hutker
Copy link
Author

Hutker commented Sep 26, 2020

да, спасибо, я уже подправил код на 48 ниблов под свою метеостанцию. Пакеты сегодня запарсил, но если мало, могу наловить больше.
pack.txt

@invandy
Copy link
Owner

invandy commented Sep 26, 2020

Спасибо. добавил в библиотеку проверку CRC8 для PCR800. Проверьте у себя, если данные с датчика будут расшифровываться, как и прежде, значит всё правильно.

@Hutker
Copy link
Author

Hutker commented Sep 28, 2020

Проверил. Все прекрасно работает с обновленной библиотекой и PCR800 распознается без проблем! Огромное спасибо!

@Hutker
Copy link
Author

Hutker commented Sep 28, 2020

Я вижу, что Вы хорошо разбираетесь в алгоритмах расчета crc. Не могли бы Вы помочь расшифровать алгоритм контрольной суммы пакетов от метеостанции? Там 4 нибла и первые два я расшифровал - это простая сумма всех предыдущих байтов. А вот с последними двумя какая то засада(
pct
Пакеты
flow2.txt

@invandy
Copy link
Owner

invandy commented Sep 28, 2020

Я вас разочарую - я очень плохо разбираюсь в этих алгоритмах. Но выучил простое правило - у Орегона последний байт посылки - это обычно CRC8 за ислючением контрольной суммы и ID датчика. Образующий полином - 07h, а вот стартовая сумма бывает разная . Для её поиска у меня написана утилитка. Причешу её и выложу.

@invandy
Copy link
Owner

invandy commented Sep 28, 2020

В общем, выдаю удочку, ловить будете сами :). Скачайте библиотеку заново и воспользуйтесь утилитой в примерах. Нужно забить данные с трёх разных пакетов и выставить размер посылки. Утилита выдаст параметры (если найдёт) для подсчёта CRC8, которые будут нужны при вызове check_oregon_crcsum().

@Hutker
Copy link
Author

Hutker commented Sep 29, 2020

Благодарствую, барин! Вечером затестим "шайтан-машину")

@Hutker
Copy link
Author

Hutker commented Sep 30, 2020

да прога хорошая! crc хорошо считает даже на "левых" датчиках из интернета)
Я добавил функцию разбивки на байты из строки, т к это проще и быстрее
hexCharacterStringToBytes(data1, "1D2025D121204446301");
hexCharacterStringToBytes(data2, "1D2025D131204447360");
hexCharacterStringToBytes(data3, "1D2025D141205449317");
Можно и Serial.read() впихнуть при желании)
Жаль только не помогла в расшифровке моих больших пакетов(

@invandy
Copy link
Owner

invandy commented Sep 30, 2020

Ну так надо искать в чём дело. Может в длинных пакетах не исключены из расчёта 6-ой и 7-ой ниблы?

@Hutker
Copy link
Author

Hutker commented Oct 1, 2020

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

@invandy
Copy link
Owner

invandy commented Oct 1, 2020

Взял из вашего файла несколько образцов:

для посылок 49 ниблов
00A5012A302400000000000000000000000000000000052F6
00A5012A3023000000000000000000000000000000000421C
00A5012A30220000000000000000000000000000000003212
Получаем POLY = 7, START_SUM= 5

а для посылок 47 ниблов
2915012A3021010171700171710F6F62E1020006032E8AE
2915012A3021010171700171710F6F62E1020007032F8DB
Получаем POLY = 7, START_SUM= 14

Всё вроде сходится...

@Hutker
Copy link
Author

Hutker commented Oct 2, 2020

да Вы просто гений! Я почему то не догадался отфильтровать пакеты по первому байту и фильтровал только по длине посылки. А теперь все сошлось. Большое спасибо! Напишите, куда отправить Вам "благодарность" на пивасик)

@invandy
Copy link
Owner

invandy commented Oct 7, 2020

Тут провёл кое-какие изыскания и немного переписал расчёт CRC для датчиков третьей версии. Ну и пример для расчёта обновил. для v3.0 оказалось, что начальная сумма везде нулевая и при расчёте используется ID. Т.е. они унифицировали метод расчёта

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants