Нужно инициализировать трансивер, чтобы перевести его Continuous mode.
Пример есть в /usr/lib/wb-homa-ism-radio/test_raw.py
Если его выполнить при выключенном демоне wb-homa-ism-radio - появятся данные на lirc0… Но на самом деле, есть куча настроек, которые можно и нужно крутить…
Открытые для меня вопросы:
Синхронный/асинхронный режим? По идее асинхронный, но…
Частота дискретизации, если синхронный?
Шейпинг?
Частота ресивера? Что-то у меня все больше подозрений, что нужно шевелить в стороны от 433.92
Динамическая загрузка DT-оверлеев поддерживается в ядре 4.1 (у нас в репозитории это ветка dev/v4.1.15), а так же требует dtc со специальными патчами (при сборке ядра из указанной ветки, правильный dtc будет в scripts/dtc/). Также если собирать ядро скриптами из репозитория build_kernel, бранча dev/v4.1.15 - все соберется в deb-пакеты, включая правильный dtc который можно запускать на WB.
Если подключаете к разъемам для внутренних модулей расширения, можете сделать по аналогии с https://github.com/contactless/wb-hwconf-manager/blob/master/modules/wbe-i-w1.dtso - это простой модуль, использующий два GPIO. wb-hwconf-manager при загрузке обрабатывает этот файл tcc, производя замену макросов SLOT_*(x) на реальные пины соответствующего слота, компилирует его в DTBO (исходник), и грузит в ядро через configfs, вручную это что-то вроде такого:
Команды хелпера confed-tojson и fromjson нужны только для веб-интерфейса. Вручную попросить hwconf-manager загрузить оверлей можно так:
wb-hwconf-manager init <slot> <module>
где slot - определение слота из slots/.def без расширения, module - названия модуля из modules/.dtso (тоже без расширения). Если ваш dtso не использует уже определенные слоты, можно создать пустой .def.
Судя по всему для работы lirc-драйвера не хватает мощности процессора.
Ниже приведены две картинки. На обоих сигнал с радипульта, повторяющийся 5 раз. В каждом случае мы видим довольно длительные пропуски сигнала. Т.к. у этих пропусков примерно одинаковая длительность и они бывают как НОЛЬ, так и ЕДИНИЦА, то очень похоже что в эти момент kernel driver теряет процессор и перестает откликаться на прерывания от пина, к которому подключен радиомодуль.
Вот к сожалению да. Неприятный баг, совсем недавно поймали и исправили. Попробуйте или остановить опрос или обновить ядро, может быть правда в этом дело.
Проблема в том, что хоть сколь-нибудь стабильную картинку удается получить в режиме OokThreshType=fixed и низкой чувствительности приемника. Заставить нормально работать OokThreshType=peak пока не получается.
В /dev/lirc0 ничего не падает. Пробовал различные настройки, но хоть сколь-нибудь значительных успехов пока не достиг. В наилучшем варианте дальность приема еще меньше, чем в режиме fixed…
Нашел неприятный баг, который похоже портил мне жизнь. В lirc0 переодически меняются местами 0 и 1. Т.е. записываешь сигнал, делаешь декодер. Тестируешь на записанных пакетах - все вроде норм. А потом раз и не работает… Записываешь, смотришь, а 0/1 (delay/pulse) поменялись местами.
Сейчас удалось добиться стабильной работы с датчиком темп/влажности от метеостанции RST. С пультами Livolo по-прежнему проблема. У них очень короткие сигналы и дисперсия больше разницы значений. Пытаюсь научить rfm более четко “обрезать” сигнал.
root@wirenboard:~# apt-get install --reinstall linux-image-4.1.15-imxv5-x0.1
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reinstallation of linux-image-4.1.15-imxv5-x0.1 is not possible, it cannot be downloaded.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@wirenboard:~# apt-get install linux-image-4.1.15-imxv5-x0.1
Reading package lists... Done
Building dependency tree
Reading state information... Done
linux-image-4.1.15-imxv5-x0.1 is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@wirenboard:~# apt-cache search linux-image| grep linux-image
.....
linux-image-4.1.15-imxv5-x0.1 - Linux kernel, version 4.1.15-imxv5-x0.1 on armel
....
