Привет.
Нет просто перезагрузка демона не помогает, даже перезагрузка девайса не помогает, только выключение/включение. Причем я пару раз сталкивался с ситуацией, что устройство не включалось, либо просто не загружалось после выключения питания.
Привет.
Нет просто перезагрузка демона не помогает, даже перезагрузка девайса не помогает, только выключение/включение. Причем я пару раз сталкивался с ситуацией, что устройство не включалось, либо просто не загружалось после выключения питания.
Это какие-то чудеса. У меня воспроизвести не получается. Давайте попробуем локализовать проблему.
Она выглядит так или так? Разница в наличии двух маленьких черных чипов справа.
Привет.
Первую часть попробую сделать в воскресенье, пока на даче. Вот про рейку это интересно, 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
дубликат этого. Не стоит писать в несколько тредов одно и то же.