Запись и воспроизведение произвольного сигнала 433Mhz


#81

У меня есть THN132N и THGN132N и THN122. У них насколько я помню у всех протокол 2.0, 3.0 был у всяких анемометров и еще чего-то.


#82

Поддерживаю предыдущего оратора - самые распространенные THN132N и THGN132N, там 2.0.


#83

Большое спасибо за проделанную работу!

Приложение сейчас работает только на приём? Передачу не планировали делать?

Можем помочь с пакетированием.

Для орегона и ноолайта могут помочь тесты от текущего драйвера, там есть распарсенные пакеты: https://github.com/contactless/rfm69-linux/blob/master/tests.py


#84

Сейчас только прием. Вроде ничего хитрого с передачей нет. Я пока не придумал зачем нужна передача, так что не пробовал.

Да с пакетированием мне было не очень хотелось заморачиваться. Т.е. собрать пакет не проблема, а вот мейтейнить ключи, репозиторий и т.п. очень не хочется…

Я не очень понимаю, как использовать пакеты, полученные через SPI. Получается, что нужно взять частоту дискретизации и нарезать из нулей-единиц LIRC пакеты с длинами сигналов и пауз?


#85

Передача в текущем драйвере есть для управления лампочками через nooLite, для управления Livolo тоже может быть полезно.

Про пакеты и SPI не очень понял. Если речь про то, что делать с входными данными из тех тестов, то да, всё как вы описали. Частота дискретизации там 500мкс, насколько я помню.


#86

Про SPI пакеты я неудачно выразился. Я хотел сказать, что через SPI мы получаем bitstream c частотой дискретизации, а через lirc тайминги.

Радиоуправление выключателями - штука бесполезная. Отсутствие возможности определить включен свет или выключен - полностью убивает всю ценность удаленного управления.

Для Livolo я сейчас пытаюсь прикрутить nrf24le1 для полноценного управления с обратной связью. Модули идеально влезают внутрь выключателя и обладают всей требуемой функциональностью. На прототипе все получается очень неплохо, но есть несколько проблем и не хватает времени довести до ума. Если все получится, должно получиться очень неплохое с точки зрения дизайна (камешек в огород nooLite) и цены решение с полноценной обратной связью и другими плюсами.

Так что если кому-то нужна передача - могу попробовать сделать, но для себя практической пользы пока не вижу.


#87

А не думали кстати сделать не на NRF24LE01, а на Bluetooth LE?

Тоже 2.4Ghz, та же дальность, но зато стандартный протокол, поддержка из коробки в Wiren Board, и всех современных ноутбуках и телефонах. Модули менее распространены, но стоят по-моему даже дешевле ,чем LE01.


#88

Евгений, а можете дать наводку на модули? Мне попадались только китайские HC05-HC08, рассчитанные на эмуляцию последовательного порта поверх BT…

BtLE идея интересная. С LE1 засада в том, что в режиме приема он потребляет около 15ma. Встроенного блока питания Livolo при “паразитном” питании не хватает для того, чтобы постоянно давать дополнительные 15ma. Вернее, если хотя бы один из каналов выключателя включен - проблем нет. Но когда все выключено - не хватает.

Я не рискнул уменьшать сопротивление резистора, на котором построено питание в выключенном состоянии. Пока самый удачный вариант - включение режима приема примерно на 20% времени. В таком варианте все работает, но требуется синхронизация приемника и передатчика.

BTLE вроде как должен сам решать эту проблему и может все сильно упростить. Но я как-то не думал копать в этом направлении из-за интуитивно большей сложности… Возможно я не прав…


#89

Насколько я понял, рынок BLE чипов примерно ограничивается линейкой nRF51 от Nordic и CC2540 от TI.

Для Nordic’а вроде сильно больше комьюнити разработок, но для TI сильно больше доступно готового железа…


#90

Ещё есть CSR1010-CSR1012. Там кажется закрытый SDK, но у нас по чистой случайности лежит он купленный без дела, можем поделиться.


#91

Евгений, а вы CSR1010 как-то осмысленно выбирали?

Для меня вопрос в том, есть ли какой-то из вариантов, который можно “взять из коробки” (без значительных расходов на SDK/DevKit) и сваять устройство с довольно простой функциональностью:

  • простой обмен с WB

  • два цифровых входа (контроль каналов)

  • эмуляция RF протокола livolo (прикол в том, что выключатели без радиомодуля отлично принимают команды, если передавать их через PIN, предназначенный для радиомодуля :slight_smile: ). Мне кажется, что это надежнее, чем эмулировать “нажатие сенсора”

  • Контроль напряжения питания (там есть пин с делением 0…12В на 0…3В) для засыпания при нехватке питания

  • Обновление по воздуху

  • Доступные готовые модули маленького размера (1.5х2см максимально)

  • Желательна поддержка iBeacon/Eddystone. Если уж прикручивать BLE, так заодно поэксперементировать с позиционированием в помещении… :smile:

P.S. Как активировать BT на WB? Вроде как все включено и запущено, но поиск устройств выдает ошибку…


#92

Выбирали по цене за чип. Кроме этого, у CSR есть некая проприетарная Mesh-сеть поверх BLE.

Вообще с TI наверное начать будет проще: модулей больше, кода больше, комьюните более живое.


#93

Туда вот этот драйвер нужен: https://github.com/lwfinger/rtl8723au_bt
Я вот не помню, стоит ли он у нас уже в стандартной поставке. Проверю через пару дней, если нет - добавлю.


Bluetooth в WirenBoard 5
#94

Прикупил THGN132N. Постараюсь в выходные добраться и собрать декодер.

А кто-нибудь знает, можно ли этот датчик заставить принудительно отправить сигнал, чтобы не ждать несколько минут, пока он соизволит что-то послать?


#95

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


#96

Неудобно ждать 40 сек, когда каждые несколько секунд прилетает какой-нибудь пакет… 433Mhz не самая свободная частота…

Оказалось, что через несколько секунд после нажатия на reset датчик отправляет пакет.

В общем, получилось принять пакет и декодировать их странноватый манчестер. А вот разобрать получаемые 80 бит в температуру, влажность и т.п. пока не получается… Принимаемый пакет не очень похож на документацию (


#97

В общем, с датчиком THGN132N все получилось.

Столкнулся с проблемой, что уже на расстоянии около 6 метров и одной стеной значительная часть пакетов приходят поврежденными. Как с этим бороться примерно понятно (фактически пакет передается дважды и за счет манчестера есть дублирование данных, а также CRC для контроля целостности).

Планирую сначала решить проблему с дальностью приема, потом выкладывать. Может ли кто-то помочь с проверкой работы на датчиках, отличных от THGN132N (1D20)? У Oregon для каждого типа датчика свое расположение данных о температуре/влажности и т.п.


#98

Говори что делать - у меня есть 1d20 и ec40.


#99

Скачать https://www.dropbox.com/s/ymkgz7w69shmwd2/rfsniffer и запустить.

Допущения:

  • Пока запускается только на WB5, т.к. предполагает, что RFM69 подключен к /dev/spidev32766.0, а его DIO2 подключен к /dev/lirc0
  • Mqtt доступен по localhost без авторизации
  • Датчики 1d20(проверен), ec40 - нужно пробовать, структура пакета взята из интернета

Можно прямо на WB набрать:
mkdir Test
cd Test
wget https://www.dropbox.com/s/ymkgz7w69shmwd2/rfsniffer
chmod +x rfsniffer
./rfsniffer

Дальше он будет в консоль писать все попытки получить и декодировать пакеты. При обнаружении валидного пакета от Oregon будет что-то типа:
09/06 18:47:03 [8820] RF Recieved: Oregon:type=1D20 id=51 ch=1 t=23.2 h=39. RSSI=-102 (-103)
09/06 18:47:03 [8820] Msg from RST Oregon:type=1D20 id=51 ch=1 t=23.2 h=39

После этого в интерфейсе WB появится(обновится) устройство :

Нужно какое-то время подождать и прислать мне файл /run/Main.log. Также, хочется получить какие-то данные по расстоянию и препятствиям до датчиков.

У меня датчик стоит в нескольких метрах от WB через бетонную стену. “Бьется” около 20-30% пакетов, но есть идеи как это полечить.


Ну а всетаки будет ли когда нибудь заявленная в рекламе поддержка китайского 433 МГц оборудования?
Ну а всетаки будет ли когда нибудь заявленная в рекламе поддержка китайского 433 МГц оборудования?
#100

C дальностью вроде разобрался. Прием от Oregon работает стабильно. Нужно тестирование на других датчиках Oregon и других Wiren Board, т.к. могут всплыть какие-то особенности…

Были опасения в высоком потреблении CPU, т.к. много шума и каждый принятый пакет нужно пропустить через пачку декодеров. Подозрения не оправдались. На фоне wb-rules нагрузка незаметна совсем.

Готов собрать демон с конфигурационными файлами и т.п. Евгений, поможете с пакетированием? Детали, лучше обсудить по почте.

Важно понимать, что мой декодер может работать только вместо стандартного. В связи с этим, нужно ли добавить декодирование еще каких-то устройств? nooLite?Поддержка передачи команд, а не только прием?