Wifi bridge?, Посоветуйте low power connectivity Опции

[A. Fig Lee]

Хочется устройство на батарейках, в котором будет реал тайм часы, EEPROM 256 bytes, 16 IO (можно наверное и 8),
сериал порт для фирмвар апгрейд или связи с компьютером и самое главное, надо по интернету достучатся до устройства.
Иногда, может пару раз в день, может раз в неделю.
Батарейки желательно 4хАА например, можно неначительно больше.

Все хорошо, но wifi chip потребляет сумасшедшие миллиамперы. Желательно чтоб устройство жило месяц на батарейках, как минимум.
Куда копать? Вроде есть и зигби поменьше едят, но может wifi есть которые спят, мало едят и можно их разбудить.
Думал еще над бриджем от компьютера на инфракрасных лучах, это вроде должно быть малопотребляемым.
Какие есть идеи?

[firew0rker]

Bluetooth Low Energy. Хватит литиевой "таблетки" на месяцы, может быть даже годы - зависит от периодичности просыпания.

[jcxz]

Какие есть идеи?

nRF24L01+

[esaulenka]

ТЗ напрочь отсутствует.
Это устройство где жить будет? Рядом на стенке будет висеть своя базовая станция? Рядом с телефоном пользователя? Или рядом только вайфай (с десятью NAT'ами, но это отдельные проблемы). Или GSM ?

Если нет "своего" устройства на другой стороне радиоканала, выбор совсем небольшой...

[jcxz]

Если нет "своего" устройства на другой стороне радиоканала, выбор совсем небольшой...

Если его там нет, то его можно сделать
Если требуется надёжность работы и хорошее мнение пользователей о Вас, то, имхо, лучше сразу забыть про блютуз, как бы ни было легко на нём сделать. Из личного опыта.

[WLESS.RU]

Интересная статейка про Amazon Dash Button с Wi-Fi и BLE, с помощью которых американских домохозяек приучают туалетную бумагу заказывать:
New Amazon Dash Button Teardown (JK29LP)
Работает от одной AA, но как долго - непонятно...

[bzx]

Хочется устройство на батарейках, в котором будет реал тайм часы, EEPROM 256 bytes, 16 IO (можно наверное и 8), сериал порт для фирмвар апгрейд или связи с компьютером и самое главное, надо по интернету достучатся до устройства. Иногда, может пару раз в день, может раз в неделю. Батарейки желательно 4хАА например, можно неначительно больше...должно быть малопотребляемым.Какие есть идеи?

Рекомендую esp8266.
В данный момент у нас в разработке подобная конструкция. Для тестирования esp.qbit.su
В слипе не более 0.5мА. Данные от устройства отсылаются на сервер, на серваке хранятся уставки и при подключении записываются в устройство. Работают и управляются несколько io, pwm, adc. На adc подключен термодатчик ntc 10k. Если интересно – пишите на email: info собака qbit.su

[jcxz]

Рекомендую esp8266.
В слипе не более 0.5мА.

Так ТС нужно:

самое главное, надо по интернету достучатся до устройства.
Иногда, может пару раз в день, может раз в неделю.

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

[bzx]

Так ТС нужно:

а в слипе до esp8266 не достучишься.

Если девайс в слипе, причём глубоком, и не важно, будь это esp или иной чип, то не достучаться никак до устройства.

[jcxz]

Если девайс в слипе, причём глубоком, и не важно, будь это esp или иной чип, то не достучаться никак до устройства.

Важно, ибо вход/выход в/из слипа nRF24L01+ - это микросекунды, для ESP8266 - это время на порядки больше.
Так что для nRF24L01+ ничего не стоит сделать просыпание раз в несколько секунд на несколько миллисекунд и организовать хендшейк в эти временнЫе окна.
Среднее потребление будет мало отличаться от постоянного слипа, а время доступа - несколько секунд до ближайшего окна просыпания.
Делал такую систему на nRF24L01+ - работает уже 2 года от одной AA.

[bzx]

Важно, ибо вход/выход в/из слипа nRF24L01+ - это микросекунды, для ESP8266 - это время на порядки больше.
Так что для nRF24L01+ ничего не стоит сделать просыпание раз в несколько секунд на несколько миллисекунд и организовать хендшейк в эти временнЫе окна.
Среднее потребление будет мало отличаться от постоянного слипа, а время доступа - несколько секунд до ближайшего окна просыпания.
Делал такую систему на nRF24L01+ - работает уже 2 года от одной AA.

Шикарно!

Только пара моментов:

...и самое главное, надо по интернету достучатся до устройства...может пару раз в день, может раз в неделю.

Поэтому, выходим из слипа 1мкс или 10мс - это не играет роли, если спим часы!

[krux]

выход в интернет - однозначно будет чем-либо из Ethernet/ WiFi/ GSM. Разбудить WiFi по этому же самому WiFi невозможно.
Все они ни капли не являются чем-либо, близким к батарейному (4хАА) питанию. Сжирание батареек за 2 дня в самом удачном случае гарантировано.
поэтому. единственный разумный вариант - это мост из "Ethernet/ WiFi/ GSM", висящего наример, на аккумуляторе типа 12v х 9 Ah, непрерывно подзаряжаемого от 220, и собирающего/раздающего по ZigBee/LoWPAN/и т.п. прочей малопотребляющей низкоскоростной линии передачи - данные от устройств с батарейным питанием.

Либо. покупать Qualcomm SDK замногоденег и пилить свою "а-ля мобилу" с питанием от компактного аккума на 4200mAh, но опять-таки, более недели оно без подзаряда не проживёт один фиг, не говорю уже про АА.

[x893]

Потребление nRF2401+ не сильно отличается от sub-1GHz приемников, а дальность больше. Только опять же какой то центр нужен для отправки сообщений на активацию WiFi. Конечно без детального описания - получается гадание на кофейной гуще.

[Aner]

Потребление nRF2401+ не сильно отличается от sub-1GHz приемников, а дальность больше. Только опять же какой то центр нужен для отправки сообщений на активацию WiFi. Конечно без детального описания - получается гадание на кофейной гуще.

Нет, нет, дальность то меньше причем при той же мощности излучения как у Tx/Rx sub-1GHz. Физику и энергетику не обманишь. Причем потребление больше, при непрерывном излучении и приемник не такой уж и маложрущий. Бит данных переданный/принятый проигрывает по энергетике субмегагерцовым трансиверам.

[jcxz]

Поэтому, выходим из слипа 1мкс или 10мс - это не играет роли, если спим часы!

ТС не осветил алгоритм доступа к устройству. И что означает это: "Иногда, может пару раз в день, может раз в неделю"?
По какому событию? Кто достукивается? Если не проблема ждать очередного окна связи когда устройство проснётся не секунды, а на порядки дольше - то можно интервал сна соответственно увеличить. Но если ждать так долго нельзя? Если ждать можно не более нескольких секунд (скажем опрос инициирует пользователь, а ему не комфортно ждать даже несколько секунд)?

Да и какие 10мс на просыпание для ESP8266? А регистрация в сети и т.п.? Усыплять ESP8266 я не пробовал, но по-крайней мере холодный старт после сброса у него более 1сек.

Нет, нет, дальность то меньше причем при той же мощности излучения как у Tx/Rx sub-1GHz. Физику и энергетику не обманишь. Причем потребление больше, при непрерывном излучении и приемник не такой уж и маложрущий. Бит данных переданный/принятый проигрывает по энергетике субмегагерцовым трансиверам.

Это здесь совсем не при чём. В любом случае хоть какой приёмник, будучи он работает непрерывно, не протянет много времени на батарейках если будет непрерывно включен.
В любом случае, проводящий большую часть времени во сне nRF24L01+, выиграет у непрерывно включённого приёмника, пусть даже с меньшим непрерывным потреблением.
А если нужно получить очень малое время отклика устройства (скажем десятки/сотни мс), то, при скорости просыпания/засыпания nRF24L01+, не проблема сделать период сна коротким и время ответа будет для пользователя практически таким-же как если бы приёмник всё время был включен.

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

[Aner]

Дальность меньше и еще по другой причине, это более широкая полоса Rx/Tx, что снижает существенно соотношение С/Ш и сокрашает дальность.
Ну и естественно, если мы просыпаемся Rx_ом по временным окнам, потребление меньше на соответствующее соотношение времён. Тут нет причин спорить.

Другой момент связан с мнинимальным временем работы приемника, или его окна. Главным ограничителем оказывается время выбега кварца на стабильную частоту, что может составлять 10мс ...100мс в зависимости от схемы, кварца. Это время плюсуется по любому к временному окну, затем еще синхра, далее минимальный пакет. И если делать все времянки по минимуму, то получаем максимум ненадежности. Из-за причин внешних помех и внутренних ошибок, джиттера и тп. Особенно это ярко замето на границе уверенного приема, когда подходим к порогу. По этому всегда ищется компромис и оптимальное решение для минимального временного окна.

Так что единицы миллисекунд не реально за разумные деньги.

[rx3apf]

Например, для CC110x время старта опорника - доли ms (точнее, у меня не превышало 200 us), опрос на наличие эфирного запроса - менее 1 ms (при терминировании по отсутствию несущей средствами трансивера) и менее 2 ms при принудительном терминировании "извне". С WiFi такой фокус не пройдет, а для поднятия соединения с ESP8266 секунд пять потребуется, и жрет она при этом как утюг...

[jcxz]

Так что единицы миллисекунд не реально за разумные деньги.

У меня есть работающий проект на nRF24L01+ с окнами приёма длительностью = ~7мс.

[Aner]

А что про полосу частот вы ничего не написали, про длительность синхры ну и тд.
Затем вы явно эти времена указываете без учета длительность выбега частоты после включения, что составляет 5…10 мс.
Может вы не разобрались или не сами проекты делали. Старт опорника и выбег частоты после включения кв генератора вещи разные.

[rx3apf]

Господин теоретик, к чему все это, а ? Достаточно того, что решение работает, с указанными времянками. Ну, и "до кучи" - посмотрите типовое время запуска у готовых современных TCXO.

[Aner]

Вы господин радиолюбитель оставляйте право на теоретика за собой. И посмотрите типовое время запуска у чипа о котором говорится nRF24L01+ а не СС110х. Поскольку интересует окно с момента подачи питания. Где в даташите указано ожидание 100мс для указанного чипа,
затем еще плюс время до получения данных в регистрах проца. Поэтому работающий проект на nRF24L01+ с окнами приёма длительностью = ~7мс это при постоянном питании.

[rx3apf]

А работающее десятками тысяч изделие на CC110x - 1...2 ms от подъема опорника из powerdown (с остановленным генератором и субмикроамперным потреблением). С приемом пакета данных (и передача в 1-ms таймслоте с такого же порядка временем пробуждения).

Что до nRF24L01 - у него указано до 1.5 ms max из powerdown, поэтому к чему рассуждение о постоянном питании ? Он тоже меньше 1 uA жрет в этом режиме и ключевать питание необходимости нет.



Сообщение отредактировал rx3apf - Feb 22 2017, 17:45

[jcxz]

Где в даташите указано ожидание 100мс для указанного чипа,
затем еще плюс время до получения данных в регистрах проца.

Господин нерадиолюбитель и нетеоретик, не затруднитесь привести выдержку из даташита на nRF24L01+ откуда Вы взяли эти 100мс?
И посчитать время загрузки стандартного максимального пакета в 32байта на SCLK ==10МГц сами сможете или калькулятором пользоваться научить?
Да и речь вообще-то шла о выходе чипа из сна в режим приёма, для которого никакая загрузка данных не нужна, а нужно лишь чтение слова состояния в конце интервала бодрствования.

[Aner]

Господин нерадиолюбитель и нетеоретик, не затруднитесь привести выдержку из даташита на nRF24L01+ откуда Вы взяли эти 100мс?
И посчитать время загрузки стандартного максимального пакета в 32байта на SCLK ==10МГц сами сможете или калькулятором пользоваться научить?
Да и речь вообще-то шла о выходе чипа из сна в режим приёма, для которого никакая загрузка данных не нужна, а нужно лишь чтение слова состояния в конце интервала бодрствования.

Господин нерадиолюбитель и нетеоретик, не затруднитесь прочесть требование ТС? Откуда следует, что устройство нужно выключать а не уводить в слип. И кому кроме вас нужно только чтение слова без подтверждения? Да никому. И покажите работающий проект на nRF24L01+ с окнами приёма длительностью = ~7мс

[jcxz]

Откуда следует, что устройство нужно выключать а не уводить в слип.

Вы о чём????

И кому кроме вас нужно только чтение слова без подтверждения?

Вы сами то поняли что написали? Подтверждение чего? Чтения слова состояния чипа???
Вы вообще в курсе что такое nRF24L01+? Как он работает? Что у него внутри? О чём тут спорите.
Ещё раз - ответьте на вопросы поставленные выше. Откуда Вы берёте этот бред?

[Aner]

Вы о чём????

Вы сами то поняли что написали? Подтверждение чего? Чтения слова состояния чипа???
Вы вообще в курсе что такое nRF24L01+? Как он работает? Что у него внутри? О чём тут спорите.
Ещё раз - ответьте на вопросы поставленные выше. Откуда Вы берёте этот бред?

Ответьте на вопрос поставленный выше: откуда этот бред про длительность = ~7мс?

[A. Fig Lee]

Значит так, с интернетом связь будет через комп который недалеко.
Устройство в кварире, но нельзя подключить к сети.
Дальность, ну.. 10 метров до компа. Устройство будет установлено стационарно.
Мне на квартиру ездить чем реже тем лучше.
Да, реал тайм похоже не получается.
Ну можно сделать запрос и ответ СМСом, наверное.
В принципе, 10 секунд окно и опрос думаю допустимо.
То бишь nRF24L01+ или ESP8266.
Спасибо.

[Aner]

Значит так, с интернетом связь будет через комп который недалеко.
Устройство в кварире, но нельзя подключить к сети.
Дальность, ну.. 10 метров до компа. Устройство будет установлено стационарно.
Мне на квартиру ездить чем реже тем лучше.
Да, реал тайм похоже не получается.
Ну можно сделать запрос и ответ СМСом, наверное.
В принципе, 10 секунд окно и опрос думаю допустимо.
То бишь nRF24L01+ или ESP8266.
Спасибо.

Если устройство стационарное, то питание какое? Если батарейка и нужна экономия то nRF24L01+ будет кушать около 1микроампера постоянно и около 13ма в период передачи/подтверждения. Причем к nRF24L01+ нужен проц, например STM8Lxx или аналогичный. И другой комплект около компа. А если хочется в комп по USB подключатся, то желателен проц и поддержкой USB например от тех же STM32F103/107 или аналогичный. Этот старенький трансиверок nRF24L01+ хорош для клав, мышек и тп устройств к компу. Его архитектура и поток данных удобно ориентированы на последующую передачу через USB но нужен проц для обслуги и прога.

ESP8266 этот модуль скорее всего подразумевали, не сам чип. Может и хорош, но проблем с ним поболее, в плане написания софта и получения стабильной долговременной работы. Было выпущено китайцами более 10 ревизий, и тут при покупке желательно не нарваться на старые глючные. Внутри у него есть свой шустрый проц и возможность написать свою прогу по обслуге периферии и выдать через Wi-Fi. Тогда на стороне компа ничего не потребуется, если он поддерживает Wi-Fi. Минус это большое потребление этого модуля. На смену этому модулю выпущены уже модули на чипе ESP32, работают намного стабильнее, лучше их использовать.

[jcxz]

Значит так, с интернетом связь будет через комп который недалеко.
Устройство в кварире, но нельзя подключить к сети.
Дальность, ну.. 10 метров до компа. Устройство будет установлено стационарно.
Мне на квартиру ездить чем реже тем лучше.
Да, реал тайм похоже не получается.
Ну можно сделать запрос и ответ СМСом, наверное.
В принципе, 10 секунд окно и опрос думаю допустимо.
То бишь nRF24L01+ или ESP8266.

Батарейное устройство (СЛЭЙВ) содержит МК(малопотребляющий) + nRF24L01+.
Опрашивающее устройство (МАСТЕР), имеет постоянное питание и постоянное соединение (с сетью или компом). Варианты либо 1 либо 2:
1. Простое устройство, втыкаемое в комп по RS232 или USB. Оно имеет МК+nRF24L01+. На компе - Ваша прога, которая через МАСТЕР опрашивает СЛЭЙВ.
2. (я так делал в своём проекте): Более сложное устройство, содержит МК+nRF24L01+. Также имеет ETHERNET-интерфейс и TCP стек. Втыкается в любой роутер без компа. Опрашивает СЛЭЙВ по командам (в моём случае в МАСТЕР-е я реализовал почтовый клиент SMTP/POP3; можно сделать любой другой способ опроса как удобнее).

Алгоритм опроса в обоих случаях одинаковый - я приводил его выше. В СЛЭЙВе и МК и nRF24L01+ большую часть времени спят.
МАСТЕР, когда ему нужно опросить СЛЭЙВ, периодически передаёт в эфир запрос (у меня период ==3мс), в течение времени не более таймаута (у меня ==1мин).
Когда СЛЭЙВ в очередной раз просыпается (у меня - каждые 20сек) и включает приёмник на время окна приёма (у меня ==7мс) в это окно приёма если сейчас идёт передача от МАСТЕРа гарантированно попадает один из запросов. В конце окна СЛЭЙВ смотрит статус приёма - если принято валидное сообщение - переходит в состояние обмена, если нет - засыпает опять на 20сек.
В состоянии обмена СЛЭЙВ отвечает мастеру ГОТОВ К ОБМЕНУ, увеличивает окно приёма (у меня - до десятков мс (в зависимости от типа запроса МАСТЕРА)) и ждёт очередной команды.
Ну и дальше собственно - работа в режиме запрос-ответ. Если в очередном окне приёма не было получено данных (таймаут обмена) СЛЭЙВ прерывает состояние обмена и уходит в состояние сна на 20 сек.
Примерно так. МК на СЛЭЙВе у меня был - MSP430FR5739.

[controller_m30]

Куда копать? Вроде есть и зигби поменьше едят, но может wifi есть которые спят, мало едят и можно их разбудить.
Думал еще над бриджем от компьютера на инфракрасных лучах, это вроде должно быть малопотребляемым.
Какие есть идеи?

Если расположение устройства, относительно компа, позволяет связываться по ИК - то можно скомбинировать. ESP8266 спит, а по ИК ожидается импульс пробуждения от компа. ИК вызов пришёл, ESP-шку разбудили, по инету связались. А потом пусть дальше спит, хоть месяцами, и без "окон".

Сообщение отредактировал controller_m30 - Feb 23 2017, 10:50

[jcxz]

Если расположение устройства, относительно компа, позволяет связываться по ИК - то можно скомбинировать. ESP8266 спит, а по ИК ожидается импульс пробуждения от компа. ИК вызов пришёл, ESP-шку разбудили, по инету связались. А потом пусть дальше спит, хоть месяцами, и без "окон".

А ИК-приёмник у Вас сколько будет потреблять?

[rx3apf]

Ну, питание ИК-приемника тоже можно ключевать. Но ТС нужно десять метров, такое оптикой не получится (если только это не спортзал). В квартире и 2.4 гига на таком расстоянии могут споткнуться (тем более что диапазон забит). В особо неблагоприятных случаях даже и 433 MHz не пробивает (с десятком mW).

[controller_m30]

А ИК-приёмник у Вас сколько будет потреблять?

Интегральный ИК-приёмник, рассчитанный на определённую частоту ИК-импульсов, типа TSOP4ххх - кушает 0.7mA в покое (по даташиту).
Но если не задаваться целью искать несущую ИК-частоту, а просто ожидать 1-2 импульса "побудки", то можно собрать схему из ИК-фотодиода и микропотребляющего усилителя, и вероятно в десяток микроампер уложиться.

Сообщение отредактировал controller_m30 - Feb 23 2017, 12:47

[k155la3]

Хочется устройство на батарейках, в котором будет реал тайм часы, EEPROM 256 bytes, 16 IO (можно наверное и 8),
сериал порт для фирмвар апгрейд или связи с компьютером и самое главное, надо по интернету достучатся до устройства.
Иногда, может пару раз в день, может раз в неделю.
Батарейки желательно 4хАА например, можно неначительно больше.
. . . .
Какие есть идеи?

Посмотрите реализацию у Ti EZ430 Chronos Watch / datalogger (красивый апнот - наручные часы на CC430XXXX)
Есть радиоинтерфейс и кушают очень мало, - по определению.
Со стороны PC можно использовать аналогичный чип с выходом на USART - COM порт PC - далее кудаугодно.

Сообщение отредактировал k155la3 - Feb 23 2017, 14:56

[ar__systems]

Интегральный ИК-приёмник, рассчитанный на определённую частоту ИК-импульсов, типа TSOP4ххх - кушает 0.7mA в покое (по даташиту).
Но если не задаваться целью искать несущую ИК-частоту, а просто ожидать 1-2 импульса "побудки", то можно собрать схему из ИК-фотодиода и микропотребляющего усилителя, и вероятно в десяток микроампер уложиться.

ИК приемники очень долго просыпаются.

[rx3apf]

Глянул даташит на TSOP18xx от Vishay - 200 us. Это даже меньше, чем нужно, например, CC110x до начала приема. Но оптика подразумевает либо прямую видимость, или хотя бы достаточно хорошее переотражение от стен. С прямой-то видимостью приемник можно сделать и с нулевым потреблением...