Яке кодування використовується в цьому сигналі?

У мене є дешевий бездротовий термометр для басейну (AcuRite 617 1 ), і я хотів би перехопити дані про температуру на приймачі та використовувати їх у комп’ютеризованій системі реєстрації даних.

Зручно, що всередині приймача розташована невелика плата, що з'єднується з антеною і має цифрові штифти "V", "G", "D" та "SH":

Ось сегмент захоплених даних зі шпильки "D" під час передачі (вони трапляються один раз на хвилину). Перед цим сегментом є дані, що здаються значно швидшими, але я вважаю, що це може бути шумом - це початок даних 1,36 кГц / 680 Гц.

Я трохи погуглився і не можу знайти кодування, яке виглядає так приблизно, але якби я здогадався, що відбувається, ось що я думаю:

• початкові 4 цикли 680 Гц - це синхронізація годин, але не містить даних
• 13 циклів 1,36 кГц (2х початкова швидкість), які слідують за цим, мають одну з двох форм: вони або знижуються до середини циклу, або після неї - я вважаю, що одна форма є логічною, а інша дорівнює нулю.
• після цього, як видається, є дивний проміжок, але якщо ви знизите частину нижнього, що є частиною попереднього "1", то решта пробілу становить 735 мкс, що є (фазово правильним!) продовженням Преамбула 680 Гц.

Я правильно на це дивлюся? Чи існує назва цього кодування?

Деякі додаткові зауваження щодо розбивної дошки:

• плата позначена "RF211" і виглядає дивовижно відповідно до MICRF211 "загального призначення, 3V QwikRadio приймачем, який працює на 433,92 МГц" 3
• таблиця даних MICRF211 має такий малюнок (з дуже невеликим поясненням), який виглядає вражаюче як те, що я бачу, за винятком квадратної хвилі з подвійною швидкістю передачі даних у порівнянні з моїм захопленням:
  

Оновлення 2016-02-14: Я переглянув цей проект і, здається, отримую чистий 64-бітовий потік між преамбулою 4 циклу та "постамблером" 1 циклу, після чого дисплейна панель вимикає модуль РФ на тягнути ^ SH низько (верхня лінія):

Відповідно до схеми "33/66% ШІМ" Міцреля (яка більше ніде не з’являється в Google), це

-_-_-_-_0000011110011000110000000000000000000000100011101000010010101010-_

Тому зараз я повинен почати маніпулювати температурою для декодування бітів. Тут ("х") - біти, які, здається, змінюються без видимих ​​змін на дисплеї:

0000011110011000110000000000000000000000100011101000010010101010
------------------------------------------------x----xxxx----xxx

Я припускаю, що це або найменш значущі біти, або рівень акумулятора (який відображається лише як "Низький", коли він значно падає).

Оновлення 2016-02-15: Я беру шоу на шляху, щоб дати новій стеклянній "Reverse Engineering" змінити тріщину при визначенні значення: /reverseengineering/12048/what-is-conposed -in-this-передача-rf-pool-temperature-sensor-base-unit-re

Micrel називає це схемою 33/66% ШІМ. Здається, це досить простий, але тимчасовий протокол.

ШІМ розшифровує імпульсну модуляцію. Існує сторінка Вікіпедії, яка детальніше описується, але, коротше кажучи, PWM - це місце, де ви зберігаєте фіксований період, тож ось час від піднімаючого краю до наступного піднімаючого краю, але ви змінюєте відсоток часу, витраченого у високий стан шляхом зміни, коли відбувається падаюча грань Для цього можна побачити, що він високий 33% для '1' і 66% для '0'.

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

Дивіться http://www.micrel.com/_PDF/App-Notes/an-22.pdf для отримання додаткових відомостей про те, що вони очікують від модуля.

Типовим способом отримання такого роду кодування було б введення цього в контактний таймер вводу мікроконтролера. Або ви можете просто підключитися до загального входу та отримати його вибірку в 4-5x періоду ШІМ. Алгоритм декодування звідти не надто жорсткий.

Як варіант, запропонований markt, ви можете повернутись до самого датчика температури. Але, якщо це аналоговий вихідний сигнал, вам доведеться самостійно перетворити його в цифровий, і він може мати дещо інші цифри у вашій реєстрації від вихідного виводу.

Люди мого знайомого зазвичай називають таку техніку кодування "ШІМ", яка, напевно, є розумним описом.

Моя перша думка, дивлячись на ваш потік даних і припускаючи, що ви правильно вгадуєте полярність бітів, - це те, що це 12-бітове зчитування АЦП, спочатку LSB, з початковим бітом "1". Я сходжу з LSB спочатку, тому що початок того, що, мабуть, наступне читання, показує однобітну зміну, і навряд чи показник АЦП (басейну) температури буде змінюватися на 2-й або 3-й MSB за той короткий проміжок часу.

Я б занурився трохи далі в систему, повернувшись до того, що генерує дані (на відміну від їх передачі), подивіться, чи можете ви визначити датчик температури, і шукати деяку кореляцію між переданими даними та температурою.

Практично всі схеми передачі РФ повинні мати кілька характеристик у своїх протоколах кодування даних. Сюди входять:

1. Преамбула послідовного формату використовується для блокування приймача по частоті
2. Індикатор імпульсу синхронізації для позначення початку, якщо індикація кадру
3. Метод кодування даних 1 і 0 з якоюсь кодованою синхронізацією для відновлення даних.

Непарний кульовий імпульс, який ви відзначили, є, безумовно, індикатором імпульсу синхронизації.

Здається, що кодування даних слідує тому, що я бачив, як кодування ширини імпульсу. Це досить поширена методика, коли один напрямок переходу слід за постійною частотою, що веде до постійної ширини бітових частот. Під час бітової комірки активний імпульс представлений як 25% часу бітової комірки або 75% часу бітової комірки. Ця схема не є імпульсно-імпульсною схемою кодування з постійним імпульсом, як це пропонує кодування в Манчестері. Це поширена техніка з кодуванням ширини імпульсу, щоб забезпечити баланс постійного струму в протоколі повідомлення шляхом надсилання додаткових біт для створення загального балансу у всьому повідомленні. У своєму найпростішому вигляді дані надсилаються двічі, при цьому друга копія логічно перевернута.

У вашому прикладі дивно бачити дані, модульовані по ширині імпульсу, що виникають перед імпульсом синхронізації. Однак це все-таки можлива схема, якщо алгоритм декодування даних розроблений, щоб прийняти отримані дані з синхронізацією в цьому положенні. Можливо, що пристрій надсилає один тип даних перед синхронізацією та один після. Розділення може бути між адресою / тимп. Датчиками АБО справжніми даними / перевернутими даними.

Редагувати:

Цікаво зауважити, що це майже схоже на те, що передавальний блок використовує інший програмний алгоритм для формулювання позитивної ширини імпульсу для комірок даних перед схемою синхронізації, ніж для ширини імпульсу на та після схеми синхронізації. Це означає, що може існувати окрема частина програмного забезпечення, що генерує більш ранній шаблон, ніж для наступної частини шаблону. Ця різниця шаблону може означати, що джерело даних у кожному випадку вимагає різної обробки з точки зору способу доступу до нього побітно. Різниця, що спостерігається на діаграмі синхронізації, може бути просто тимчасовою інструкцією або двома різницею циклів генерації візерунків.

Я почав розшифровувати Acurite 617 і ось мої початкові спостереження. Я можу вам сказати, що останній байт - це якийсь байт "перевірки", а наступний до останніх трьох байтів містить температуру. Ці байти також надсилаються за допомогою 7-го біта, щоб зробити рівномірний паритет, і використовується лише нижня клітка кожного байта. Я написав програму Arduino для збору даних і побачив наступні повідомлення / температуру.

40 ce c0 00 00 0c 03 be
(00 0C 03) => 0C3 => 67F

40 ce c0 00 00 0c 84 39
(00 0C 04) => 0C4 => 67F

40 ce c0 00 00 0c 05 b8
(00 0C 05) => 0C5 => 67F

Інші дані / темпи, які я бачив:

E2 => 73F

F5 => 76F

108 => 80F (81 00 88)

109 => 80F

Використовуючи це, ви повинні мати можливість перетворити "пряму лінію" (припущення).

Оскільки я не маю хорошого розмаху (а також те, що дані надсилаються раз на хвилину), я не впевнений у своїх термінах. Я бачу, що синхронізація HI та LO є 720 Usec, а біти даних - 240 та 480 usec.

Сподіваюся, пізніше я отримаю більше інформації. У мене є купа таких. Як тільки вони починають просочуватися, я виймаю їх з басейну і висушую для використання навколо будинку. Пізніші 617 модулів (із відвернутими гвинтами та ущільнювальним кільцем) здаються довше

Я ще дешифрував. Останній байт (перевірити байт) робить XOR з усіх восьми байтів рівним 0FFH. Наприклад, для "40 CE C0 00 00 8D 0C 30", 40 xor CE xor C0 xor 00 xor 00 xor 8D xor 0C xor 30 дорівнює 0FF.

Крім того, я знизив температуру до 34 ° F, і підрахунок становив 10 десятків (i, наприклад, 00 00 0A), а при 80F підрахунок становив 264 десятків (тобто 81 00 88 або 108H).

З цього я використовую Temp (F) = 0,1811 * Count + 32,1889. Я можу отримати більший проміжок часу, щоб отримати кращі дані, якщо побачу помилку.

Дивлячись на рядок Роб Старлінг на 2016-02-14:

00000111/10011000/11000000/00000000/00000000/10001110/10000100/10101010 07 98 C0 00 00 8E 84 AA

XOR = FF

Підрахунок = 0E4 або 228

Температура = 73,5F