Анализировать просто. Это bitstream, т.е. поток бит. Каждый бит означает наличие или или отсутсвие сигнала в течение 500микросекунд. Например, последовательность 8880000000 означает:
Сигнал 500us
Пауза 1500us
Сигнал 500us
Пауза 1500us
Сигнал 500us
Пауза 1500us
Пауза 14ms
Важно понимать, что сейчас драйвер радио использует частоту дискретизации 500us (2кбит/сек). Это означает, что если ваше устройство использует более короткие импульсы, то несколько импульсов будет “схлопываться” в один 0 или 1. Например, Livolo использует две длительности импульсов 200us и 400us, различить их при частоте дискретизации 2КГц невозможно.
Т.е., в сухом остатке, если для вас важен только факт передачи информации о движении, скорее всего, стабильно наблюдаемые последовательности типа 8e8eee888e8eee8e8e8eee88800000008e8eee888e8eee8e8e8eee88800000008e8eee888e8eee8e8e8eee88800000008e8eee8 можно декодировать, как команду “движение”. Для этого нужен класс, аналогичный https://github.com/contactless/rfm69-linux/blob/master/noolite.py
Либо дождаться, когда я завершу работы над декодером, не использующим дискретизацию радио-модуля. Если есть желание принять участие в бета-тестировании, могу прислать все, что нужно для записи радио-пакетов, вы запишите, пришлете мне пакеты, а я сделаю декодер.
После этого прислать /run/Main.log и все файлики capture*
Если у Вас не WB5, то к параметрам запуска rfsniffer возможно придется добавить -s /dev/spidev<номер устройства>. Правильные номера устройства зависят от версии WB. Теоретически, он должен сам определять параметры устройства, но эта функциональность не тестировалась.
Хочу отметить, что файлы писались чаще, чем срабатывал датчик. В случае с MQTT – сообщения туда падали именно в те моменты, когда срабатывал датчик (загоралась лампочка на нем)
Честно говоря, это странно. Я вечером посмотрю пакеты и напишу, что в них. Возможно просто эфир сильно зашумлен. В этом случае, нужно будет уменьшить чувствительность приемника, расположить датчик недалеко от антенны (~1-2 метра) и повторить упражнение.
Приемник RFM69 очень чувствительный, например, у меня он стабильно принимает датчики, расположенные за 2-мя бетонными стенами на расстоянии более 10 метров. По умолчанию он работает в режиме автоподстройки чувствительности, из-за чего может быть много “мусора”, это не критично в нормальной работе, но мешает выделению нужного сигнала при анализе протокола.
Первый файл содержит очень аккуратную, дважды повторяемую последовательность. Любопытно, что частота дискретизации ровно 2кГц, т.е. можно использовать стандартный драйвер WB.
Как называется датчик движения? Модель? Производитель? Мне это нужно для того, чтобы хоть как-то назвать декодер
У Вас только одно устройство? Оно отправляет только сигнал движения или отсутствие движения тоже отправляет? Нет ли датчика освещенности? Мне это нужно для того, чтобы понять, есть ли другие команды, кроме единственной записанной…
Похоже, что я ошибся. Во всех пакетах очень много мусора.
Просьба повторить запись с параметром -f 30. 30 очень приблизительное значение и зависит от уровня шума и мощности передачтика в датчике). Задача найти такой параметр, при котором пакеты пишутся только в момент передачи данных датчиком. Увеличение параметра увеличивает чувствительность (соотв, после некоторого значения полезет шум). Уменьшение параметра уменьшает чувствительность (после некоторого значения перестанет слышать передатчик). Обычно легко удается найти значение, при котором шума уже нет, а сигнал еще четко слышен.
Почему, интересно, в очередь пишутся в моменты, которые соответствуют событиям?
Потому, что я использую немного другие настройки радиомодуля, чем основной драйвер. У меня были проблемы, когда я пытался использовать одинаковые настройки.
Ошибка о которой я писал, никак не влияет на текущий драйвер, она как раз проявляется при использовании lirc-совместимого драйвера.
Могу попробовать собрать версию с настройками, идентичными стандартным
