Moved: Радио-модуль перестаёт принимать данные Oregon

Привет.

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

Это какие-то чудеса. У меня воспроизвести не получается. Давайте попробуем локализовать проблему.

  1. Снимите пожалуйста заднюю крышку корпуса и посмотрите на платку радио-модуля. Расположен от так: http://beta.hstor.org/getpro/habr/post_images/fdb/f19/011/fdbf19011cc67e32153630c394dbe95f.png , это маленькая зелёная квадратная платка.

Она выглядит так или так? Разница в наличии двух маленьких черных чипов справа.

  1. В WB SH есть возможность отключить программно всю рейку питания 3.3V, при этом выключится почти вся периферия, включая радио, Ethernet, USB и Wi-Fi.
    Делается это с помощью GPIO 39. У вас есть USB-UART кабель, чтобы попробовать это сделать?

Привет.

Первую часть попробую сделать в воскресенье, пока на даче. Вот про рейку это интересно, UART есть но на работе, попробую в понедельник вторник.
Волчанка продолжается, т.к. за последнии 3 дня данные хоть с перерывами но принимаются.

Без UART тоже можно, просто тогда надо выключение-включение 3.3V завернуть в скрипт и отвязать его от терминала (по-моему через nohup), чтобы он не вылетел, когда отпадёт Ethernet.

Привет.

Модуль первого типа, с двумя маленькими чипами справа.
Выставление 39 гпио в 0 выключило все, т.к. делал без консоли скрипт должен был его выставить обратно в 1-цу, но в какой-то момент погас светодиод рядом с разьемом питания, и собственно больше не включился, у меня такое уже бывало, при старте, т.е. сначала зажигался, а потом выключался и ничего не работало. Может всетаки дело в питании?

Дополнение - данные орегона он принимал все выходные, один датчик иногда отваливался, но все равно возвращался, при перезапуске демона, собственно за 1 час не одного апдейта данных.

Я думаю проблема с орегоном - просто в плохом уровне сигнала. Видимо датчики у вас находятся на большом расстоянии, либо стены мешают.

Можно попробовать достать антенну из корпуса и попробовать её по разному ориентировать. Можно попробовать подключить внешнюю антенну на 433Mhz.

С лампочкой питания конечно всё очень загадочно. Мы такого поведения никогда не наблюдали.
Интересно было бы посмотреть на сообщения в консоли по UART.

Вот перезагрузка в момент включения 3.3V вполне может случиться, если блок питания недостаточно мощный. При включении 3.3В включается чип Ethernet и потребляет импульсно большой ток. Стоит попробовать другой блок питания (желательно вольт на 9-15).

Ещё подскажите пожалуйста, у вас к выходу 5 вольт платы что-нибудь подключено?

Привет.

Блок стоит только с подключенным изернетом и питанием. Ничего большего не подключено. Попробую заменить на другой блок питания на 9-12 вольт.
Вот вопрос про антенну - этот такой проводок который внутри корпуса болтается?
Сколько ему нужно мощности блока питания чтобы гарантированно не было проблем?

Поменял блок питания на 12в/800ма - вот теперь скрипт сработал, и нормально передернул питание (из того что видно по dmesg - это вайфай и изернет).
Немного поменял дислокацию блока - буду мониторить состояние.

Рекомендуемая мощность 10W. Мы комплектуем контроллеры блоками питания 12V 1A.

Антенна - да, проводок, который болтается внутри, свободный конец в белой термоусадке.

Привет.

Ну вообщем THGN122 видится без проблем, а вот с наружним THGN132 проблемы - нивидит не в какую, причем станция которая стоит дальше контроллера этот датчик видит без проблем.

Есть вопрос про модуль RFM96 - а как в нем задается размер посылки которую он принимает (т.е. что я вижу raw)? Он имеет фиксированный размер, или есть какие-то ограничения на размер посылки? Я тут просто пытаюсь разобраться с протоколом моего энерджи монитора - вроде пакеты похожие на то, что он должен выдавать вижу, но они какой-то неправильной длинны, судя по тому описанию что я нашел.

Сейчас там всё очень примитивно: после получения прерывания принимается всегда 60 байт. Т.е. если пакет у вас меньше, то в конце будут FF. Возможно с учётом шума некоторые биты в этих FF будут сброшены.

По поводу изучения протокола: я бы рекомендовал вам для простоты выключить демон wb-homa-ism-radio и запускать напрямую https://github.com/contactless/rfm69-linux/blob/master/rfm69.py .

У меня есть подозрение, что некоторые проблемы могут возникать из-за слишком низкого битрейта. Т.е. в вашей железке скорее всего что-то типа https://code.google.com/p/rc-switch/wiki/KnowHow_LineCoding , а там размеры битов бывают какие попало. У нас сейчас стоит битрейт ~2000 b/s, т.е. 500мкс на бит. Возможно стоит попробовать битрейт больше (выставляется он тут: https://github.com/contactless/rfm69-linux/blob/master/rfm69.py#L400 )

Как это совместить с приёмом oregon пока не очень очевидно.

Будет ли поддержка протокола 3.0?
есть датчик THGR800 на нем маркировка 3.0

дубликат этого. Не стоит писать в несколько тредов одно и то же.