протокол орегон V 3.0

кто подскажет по алгоритму crc если таковой тут вообще используется

0xFA, 0x28, 0x24, 0x96, 0x10, 0x16, 0x40, 0x04, 0x3E, 0x0A

0xF идент датчика
A синхра
0x28 идент датчика
2 канал #1 (1=0, 2=1...)
4 ? (не меняется для всех типов датчиков)
0x96 адрес, меняется рандомно после сброса
1 десятые градуса
0 b3 1=reset/norm, b2 = lowbat, b1 ? b0 ? *
1 единицы градусов
6 десятки градусов
4 единицы влажности
0 b3 1 = отрицательная темп. b2 ? b1 ? b0 ?
0 ?
4 десятки влажности
0x3E checksum, сумма ниблов - 0x0A (синхра)
0x0A crc?

0xFA, 0x28, 0x14, 0xF4, 0x42, 0x21, 0x70, 0xE7, 0x56, 0x81
0xFA, 0x28, 0x14, 0xF4, 0x32, 0x21, 0x70, 0xE7, 0x55, 0xE3
0xFA, 0x28, 0x14, 0xF4, 0x20, 0x21, 0x80, 0xC7, 0x51, 0xF6
0xFA, 0x28, 0x14, 0xF4, 0x20, 0x21, 0x90, 0xC7, 0x52, 0xE3
0xFA, 0x28, 0x14, 0xF4, 0x10, 0x21, 0x90, 0xC7, 0x51, 0xD9
0xFA, 0x28, 0x14, 0xF4, 0x10, 0x21, 0x00, 0xC8, 0x49, 0xBA

 

Если есть checksum, то нафига еще crc? Скорей всего, просто код lf, означающий конец строки.

 

что навело вас на такую мысль? 0АН в отдельно взятом пакете? ниже есть еще несколько
и там последний байт совсем не 0а. нафига? не знаю, возможно и не crc, а какой-то другой
хеш, но пока 0х00 не встретился ни в одном пакете, опять же что еще можно перебрать кроме полиномов и начального значения я не знаю.

 

Просто приходилось программировать через RS-232/422/485 частотные инверторы, например. А еще цифровые осциллографы. А еще... Понятно, что системы команд разные, но общие принципы наблюдаются.

Один из них - контрольная сумма в конце командной строки. Обычно, просто сумма байтов по модулю 256, иногда с инверсией. Иногда - сумма кодов 16-ричных цифр, которыми записываются байты строки. А вот CRC в командной строке не встречалось ни разу. (Вру, один раз встретилось CRC-8 в строке для какого-то советского ящика, который так и не удалось запустить, потому что он был горелый).

Другой - явный конец строки, обычно в виде LF или CR/LF. Иногда строки разделяются XON/XOFF, это если программная синхра. Ноль для конца строки ни разу не видел.

 

может это как то поможет
0xCA, 0x48, 0x14, 0x45, 0x62, 0x21, 0x10, 0xB3
посылка с термометра, влажности нет по этому пакет короче, если знак температуры
в 7 байте то хеш получается всего 4 бита

и пара с одинаковым хешем
0xFA, 0x28, 0x14, 0xB9, 0x98, 0x25, 0x60, 0xC7, 0x63, 0xFF
0xFA, 0x28, 0x14, 0xF4, 0x80, 0x20, 0x50, 0xC8, 0x54, 0xFF

 

У тебя нет ни одной пары, чтобы входные данные только в одном информационном байте отличались ?
А то тут можно долго гадать ...

 

manefa у тебя есть ссыль на описание железяки в которой этот протокол используется?

 

OLS, ок, попробую разобрать датчик, если термосенсор окажется аналоговым
и удастся заткнуть датчик влажности то такую пару можно будет подобрать,
21 и 12 градусов дадут одинаковую кс но разный хеш (возможно).


zicker, только инструкции по эксплуатации.
http://ftpserver.distec.be/OregonScientific/manuals/
WMR100
WMR200
WMRS200
WGR800 Датчик скорости и направления ветра
PCR800 Датчик уровня выпавших осадков
THGN801 Датчик температуры и влажности
THGR810 Датчик температуры и влажности 10 ch
UVN800 Датчик УФ-излучения
THWR800 Датчик-поплавок для измерения температуры воды 3ch
THGR800 Датчик температуры и влажности 3ch

 

Не нужно ничего разбирать. Пример с одинаковой КС и разным хешем в твоем наборе уже есть - присмотрись.

Интереснее плавное изменение одного параметра, проще всего наверное температуры.
В идеале - таблица хотя бы 3х3 из ступенчатого изменения двух параметров (все возможные пары значений).

Я понимаю, что при этом автоматом изменится КС, но это пока некритично.

 

manefa
Там вроде ПО имеется. Может есть смысл его поковырять?

 

табличка в экселе 19.9-21.7 ; 76-93
http://www.radioscanner.ru/uploader/2010/801.zip

по имеется, есть лог с usb и вроде протокол в сети есть, но интересует именно rf протокол.

 

manefa
глянь здесь вроде прога этот протокол поддерживает.
Еще нагуглил первую версию протокола. Если нужно ссылку дам позже.

 

разобранный THGN801

датчики аналоговые так что можно накрутить любой параметр по отдельности.

 

Тогда если не сложно, накрути при любых неизменных первых 7 байтах восьмой байт чем больше значений, тем лучше.
XLS-файл видел, анализировал, пока наиболее перспективно искать зависимость по изменению последнего (восьмого) байта, т.к. там хоть что-то проглядывается (таких пар в файле четыре, но зависимость пока не очень ясна). А при фиксации других "семерок" изменение "внутренних" байт даже на бит вызывает бросок хеша на очень большое значение.

 

manefa
качай аттач должен помочь

 

восьмой байт это десятки влажности + индекс комфорта или что то подобное + хзч для пятого байта, любое значительное изменение
(несколько градусов или десять % влажности) вызывают изменение старшей тетрады 8 байта, те накрутить его линейно не получится.
сырой лог за сегодня http://www.radioscanner.ru/uploader/2010/270710.zip, как доберусь до дома разберу,
удалось накрутить (0-9) ст. тетрады 7 и 5 байта, назначение
счетчика в пятом байте пока не ясно и что он делает со ст. тетрадой
восьмого то же.

 

По сегодняшнему файлу нашел только зависимость старшего нибла 6-го байта (байты нумерую с 0) :
он (назовем его N6hi) наложен на хеш трижды :

N6hi XOR (N6hi shl 2) XOR (N6hi shl 4)

При зафиксированных 4-м, 5-м и 7-м байтах после XOR хеша с указанной формулой всегда получаются константы.

Также очевидно, что CRC (8-ой байт) вообще не охвачен хешем,
а ниблы 7-го байта N7hi и N7lo воздействуют независимо на ниблы хеша, причем крест-накрест.

 

Про 7-ой байт - я был не прав (анализировал нерепрезентативную выборку).

 

Извини, матрица не сошлась ...
...

 

спасибо огромное за помощь, почта в лс.