выбор режима работы устройства для экономии энергии
- Войдите на сайт для отправки комментариев
всем привет.
использую две anarduino+MW RF96(LoRa) http://www.anarduino.com/miniwireless/#
к одной подключены 7 термосенсоров DS18B20 - это сервер, он передает данные о температуре клиенту - второй anarduino по радиоканалу.
нужно отметить, что эти MW модули могут работать в двух диапазонах - 433MHz и 915Mhz в зависимости от настроек модуля (setFrequency(915.0); или setFrequency(434.0); )
теперь надо научить сервер спать и просыпаться по какойто команде от клиента, которая приходит по радиоканалу. если это вообще хороший вариант, в контексте экономии батареи.
наверное незачем все время слушать эфир. достаточно делать это периодически.
возник вопрос о питании сервера. он должен быть автономным и жить длительное время на аккумуляторе в наружных условиях зимой.
но вот вопрос - насколько часто, чтобы это было и экономно и удобно с точки зрения пользователя?
раз в минуту просыпаться и слушать эфир? или раз в полминуты?
достустим раз в минуту - это 60 раз в час, 1440 раз в сутки.
если допустим что при этом девайс будет потреблять 20mA в обычном режиме и 0.05 в sleep.
допустим он питается от аккума 2000 mA/ч
в обычном режиме батарея умрет за 2000/20 == 100 часов. это примерно 4 дня.
а как подсчитать насколько хватит батареи с учетом того, что девайс будет засыпать и раз в минуту, около 5 секунд будет кушать 20mA а все остальное время 0.05mA ?
значит в 1 минуту девайс будет в течении 5 сек. потреблять 20mA.
в 1 час это будет уже 300 сек == 5 минут такого потребления и 1.7mA потребления.
значит в течении часа работы в таком режиме девайс будет потреблять около 2mA в обычном режиме + оставшее время будет спать, потребляя при этом 0.045mA
Итого в час выйдет ну максимум 3mA.
2000/3 = 667 часов == 27 дней.
я верно подсчитал?
И как заряжать будете? Обычные литиевые при отрицательных температурах не заряжаются.
почему 6?
можете объяснить или это опытные данные?
сервер будет раз в минуту "слушать" эфир на предмет команды от клиента "дай данные о температуре"
если в очередную итерацию пробуждения он в течении 5 секунд услышит эту команду, он должен проснуться окончательно, измерить термературу и передать ее. потом уснуть снова и через минуту опять проснуться на 5 сек.
по крайней мере такая идея у меня. может что-то есть и получше..
Лучше сделать так, чтобы "сервер" не ждал команд, а просто периодически просыпался и слал данные. А клиент должен быть постоянно включен
иначе сложно сделать так, чтобы спящий МК услышал посланную по радио команду
Зачем вам измерять каждую минуту температуру? Тем более уличную. Более чем достаточно измерять раз в полчаса-час. Резкое изменение температуры (минут за 10 на 2-3 градуса) я наблюдал всего несколько раз (по пальцам пересчитать можно).
Зачем вам измерять каждую минуту температуру? Тем более уличную.
на случай термоядерного удара, например.
Лучше сделать так, чтобы "сервер" не ждал команд, а просто периодически просыпался и слал данные. А клиент должен быть постоянно включен
иначе сложно сделать так, чтобы спящий МК услышал посланную по радио команду
я рассуждаю так - для девайса приоритетный режим - режим экономии батареи.
и если даже раз в минуту просыпаться, и сразу измерять, и куда-то пытаться отправлять(хотя у меня реализовано не бродкаст отправка, а по адресу клиента) - то если никто не готов принимать - это будет просто пустая трата энергии.
поэтому, наверное, "дешевле" будет все же проснуться, проверить нет ли запроса, и если нет, то уснуть снова..
но я тут пытаюсь добавить хоть какуюто задержку в loop() и странные вещи получаются -
http://arduino.ru/forum/programmirovanie/peredacha-po-radikanalu-array-f...
взглянул бы кто более понимающий в програмировании..
Рассуждать надо не абстрактно, а применительно к возможностям вашего оборудования
ваш радиомодуль умеют получать сообщение и запоминать его пока ардуино спит?
если да - ок, можно и так, но тогда сам радиомодуль обязан постоянно работать и кушать батарею
если нет то зря вы надеятесь, что колебания магнитного поля будут ждать пока ваша ардуино будет готова их "проверить"
nRF24 умеет сам принимать и тык прерыванием. Буфер в 32 байта для температуры хватит с головой.
nRF24 умеет сам принимать и тык прерыванием. Буфер в 32 байта для температуры хватит с головой.
умеет. Вот только стоит это 12мА. Ничего? Литиевая батарея 2600 сядет через недельку в ноль, алкалиновые батарейки АА раза в двабыстрее. Зато спящий МК сэкономит 5мА!)
да, я уже говорил - надо спать всем модулям.
просыпаться только раз в минуту и в течении 5 сек слушать эфир.
при этом клиент, который хочет получить данные от таким образом "раз в минуту просыпающегося" сервера, должен спамить в эфир короткими командами, чтобы сервер успел за 5 сек получить ее.
ну и когда сервер поймает ее в это 5сек окно - он уже проснется окончательно и сделает что надо, и потом опять уснет.
как-то так думаю..
есть возражения или идеи получше ?
Цитирую axill :"если нет то зря вы надеятесь, что колебания магнитного поля будут ждать пока ваша ардуино будет готова их "проверить".
Чем плох вариант, раз в 10 минут проснуться, выплюнуть данные и уснуть. Что может произойти с температурой за такой промежуток времени? Зачем пользователю слать какие либо запросы? Смотри на последнюю и не умничай.
Клиент тоже на батарейной диете? А то получается, что в каждую минуту целых 55 секунд сервер будет недоступен (неактивен). Какова веротность, что клиент, который "спамит в эфир" попадет в это окно в 5 секуд? Это ему надо спамить непрерывно, ну или хотя бы каждые 2 секунды. Он сам истощит свою батарею рано-рано...
Рассуждать надо не абстрактно, а применительно к возможностям вашего оборудования
ваш радиомодуль умеют получать сообщение и запоминать его пока ардуино спит?
если да - ок, можно и так, но тогда сам радиомодуль обязан постоянно работать и кушать батарею
если нет то зря вы надеятесь, что колебания магнитного поля будут ждать пока ваша ардуино будет готова их "проверить"
ДАЖЕ если и да - то это все равно не вариант - слишком дорого для батареи.
и не совсем понимаю про вариант "нет" и колебания.. серьезно.
Клиент в принципе не на диете, он переносной и по вечерам его батарею можно подзаряжать.
Чем плох вариант, раз в 10 минут проснуться, выплюнуть данные и уснуть. Что может произойти с температурой за такой промежуток времени? Зачем пользователю слать какие либо запросы? Смотри на последнюю и не умничай.
может и не плох. раз в 10 минут слать бродкаст..
по идее это будет дешевле для батареи, чем раз в 1 минуту просыпаться.. а может и нет. надо мерить потребление точно в эти режимы и тогда подсчитывать.
но в этом случае клиенту надо будет тусить в течении 10мин +- время с последнего засыпания.
10 мин на холоде постоять. может быть не очень комфортно для человека с клиентом )
хотя надо проверить оба варианта.
вариант с периодической автоматической проверкой температуры хорош еще и тем, что термодатчики будет постоянно в "разогретом" состоянии. я тут заметил, что если их долго не опрашивать, то значения температуры с них не сразу устаканиваются до текущих. то есть не термосенсор долго не опрашивающийся сразу показывает не точную температуру. его нужно несколько раз спросить пока он не подстроится..
Как раз самая первая температура и есть уличная, далее идет самонагрев датчика, пока не достигнет точки равновесия.
А не думали сделать ретранслятор со стационарным питанием? Т.е. "Сервер" ничего не ждёт, просто иногда просыпается (как часто - параметр для дальнейшей настройки, для логики не важен) и шлёт температуру на ретранслятор
ретранслятор всегда помнит последнее измерение и выдаёт его мгновенно по любому запросу "клиента"
да вообще надеюсь, что LoRa хватит на дальность до стационарного клиента. пишут что до 3 км пробивает.
тогда да - буду сразу слать данные.
но с ретранслятором не получится - негде стационарное питания брать в этой местности да и лишний узел..
Запрос-ответ энергетически все равно не выгодный вариант. Не хотите ретранслятор, жертвуете батареей клиента раз её заряжать проще. Пусть клиент всегда слушает эфир и ловит любое сообщение от сервера. А сервер тогда сэкономит максимум энергии. Кстати он можетсэкономить больше если заложить ещё логику значимой разницы температур. Т.е. Если изменение не значимое, то не слать
И ещё для сервера можно подумать об альтернативной энергии, например солнечная батарея
Клиент тоже на батарейной диете?
И ещё для сервера можно подумать об альтернативной энергии, например солнечная батарея
да, я выше уже примерно подсчитывал какой аккум нужен будет на весь период эксплуатации.
чтото вроде такого - 6v 7ah:
http://www.1000va.ru/shop/general_security/gs_6-7/?utm_source=YandexMark...
возможно его и подзаряжать не надо будет с помощью СП..
Учтите, что свинцовый аккумулятор не стоит более чем на 60% ёмкости разряжать, а точнее надо контролировать напряжение и отключаться, иначе один-два глубоких разряда и в мусор
так же учите, что ёмкость при отрицательных температурах падает
Если система стационарная в поле, то имеет смысл поставить и 12V7A аккумулятор или мощнее. Только не знаю как ведут себя аккумуляторы на загущенном электролите на морозе. Может оказаться что автомобильный проще будет поставить - он до -30С работает.
И добавьте в передачу оставшуюся емкость аккумулятора - сможете своевременно заменять тогда.
Есть еще вариант для труднодоступных мест. Данные пишутся на карту памяти в течении допустим недели. Есть назначенный день и час съема данных. В это время сервер будет находится в течении часа активным слушателем. Если пришел сигнал от клиента, то передаем все накопленные данные, чистим и спать. Если сигнала нет, то собираем данные дальше и через неделю делаем новую попытку. Конечно в любой момент вы сможете просто забрать данные из прибора напрямую и они не потеряются.
Если система стационарная в поле, то имеет смысл поставить и 12V7A аккумулятор или мощнее. Только не знаю как ведут себя аккумуляторы на загущенном электролите на морозе. Может оказаться что автомобильный проще будет поставить - он до -30С работает.
И добавьте в передачу оставшуюся емкость аккумулятора - сможете своевременно заменять тогда.
Есть еще вариант для труднодоступных мест. Данные пишутся на карту памяти в течении допустим недели. Есть назначенный день и час съема данных. В это время сервер будет находится в течении часа активным слушателем. Если пришел сигнал от клиента, то передаем все накопленные данные, чистим и спать. Если сигнала нет, то собираем данные дальше и через неделю делаем новую попытку. Конечно в любой момент вы сможете просто забрать данные из прибора напрямую и они не потеряются.
вот как раз занимаюсь кодом для определения вольтажа источника питания.
чето он пока ребутит адрудину мою.
ну и с картой памяти тоже не вариант - данные нужны каждый день, раз в день.
// Измерение собственного напряжения питания int readVcc() { int result; ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1); delay(75); // Wait for Vref to settle ADCSRA |= _BV(ADSC); // Start conversion while (bit_is_set(ADCSRA,ADSC)); // measuring result = ADCL; result |= ADCH<<8; result = 1125300L / result; // (Kvcc * 1023.0 * 1000) (in mV); return result; }// Измерение собственного напряжения питания int readVcc() { int result; ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1); delay(75); // Wait for Vref to settle ADCSRA |= _BV(ADSC); // Start conversion while (bit_is_set(ADCSRA,ADSC)); // measuring result = ADCL; result |= ADCH<<8; result = 1125300L / result; // (Kvcc * 1023.0 * 1000) (in mV); return result; }спасибо. тоже нашел несколько вариантов.
в отдельную функцию добавил, вызываю ее в loop()
но все время на вывод получаю строку которая в setup() выводится.
значит ресетится контроллер почемуто..
разбираюсь..
я првильно понимаю, судя по pinout МК - http://www.anarduino.com/miniwireless/miniWirelessB-pinout.jpg
http://www.anarduino.com/miniwireless/#
- VIN - это пин куда можно подавать от 3.3 до 7 вольт и дальше МК будет питаться через бортовой стабилизатор, на котором будет происходить падение емкости батареи.
поэтому лучше питать его сразу от батареи в 3.3 вольта через VCC ?
но с другой стороны - такая батарея может выдавать не точно 3.3 и тогда девайс будет просаживаться по питанию..
я сейчас питаю девайс от USB-FTDI адаптера и код, измеряющий состояние VCC показывает:
Возьмите импульсный стабилизатор, у него КПД выше чем у линейного.
эм.. можете чуть подробнее ?
докупить какой-то модуль и использовать его между батареей и МК?
эм.. можете чуть подробнее ?
докупить какой-то модуль и использовать его между батареей и МК?
у вас батарея 6 вольт? Если свинец то надо исходить из того, что напряжение будет до 7.2вольт
Dc-dc преобразователь даст дополнительную экономию но только если сам будет потреблять мало. Не знаю таких готовых. Можно собрать самому на подходящей микросхеме, там обычно простая схема - микросхема, дроссель, 2-3 конденсатора, 2-3 резистора и диод
Как раз самая первая температура и есть уличная, далее идет самонагрев датчика, пока не достигнет точки равновесия.
да, блин, фигня какая-то - самонагревающийся датчик температуры
да, блин, фигня какая-то - самонагревающийся датчик температуры
А ток потребляемый в режиме преобразования куда девается?
А ток потребляемый в режиме преобразования куда девается?
да? - куда девается ток и почему не происходит аппаратной коррекции показаний датчика?
Ток обычно девается в тепло. Какую сделать аппаратную коррекцию в диапазоне -55 до 128?
Поэтому и не рекомендуют их долбить запросами непрерывно.
Ток обычно девается в тепло. Какую сделать аппаратную коррекцию в диапазоне -55 до 128?
Поэтому и не рекомендуют их долбить запросами непрерывно.
рекомендую не использовать говно-датчики.
И какие же порекомендуешь?
http://conrad.ru/catalog/datchiki_vlagnosti/tsifrovoy_datchik_vlagnosti_...
С 1мкА потребления, эффект будет незаметен. Только 100 вечнозеленых за возможную ошибку в пару десятых градуса, наверно многовато. ИМХО.
Да и честно говоря, где в бытовом потреблении это может быть востребовано?
С 1мкА потребления, эффект будет незаметен. Только 100 вечнозеленых за возможную ошибку в пару десятых градуса, наверно многовато. ИМХО.
ну, если многовато, то достаточно устроить программную термокомпенсацию отдельно взятого дешёвого датчика.
снять показания горячий&холодный и посмотреть, превышает ли разница заявленную в даташите точность измерений.
*самому интересно, на сколько градусов разогревается дешёвый датчик при температуре окружающей среды, например, 25С ?
Не проводил опытов. Про точность ничего не попадалось, цена разряда 0,00625гр. при 12бит режиме.
Насчет программной компенсации, предполагаю, что овчинка выделки не стоит. кристалл-корпус корпус-воздух, наличие конвекционных потоков и пр........ Фактически каждый будет зависеть от места размещения.
А главное, какой смысл в постоянном мониторинге?
Про точность ничего не попадалось, цена разряда 0,00625гр. при 12бит режиме.
ну, как нигде? даташит DS18B20 в свободном доступе.
Диапазон измерений от –55°C до +125°C и точностью 0.5°C в диапазоне от –10°C до +85°C.
http://www.labkit.ru/userfiles/file/documentation/Sensor/DS18B20_RU.pdf
*нужно подтвердить проблему саморазогрева, что бы, затем, корректно агрументировать нечто фактом саморазогрева.
А главное, какой смысл в постоянном мониторинге?
говорил где-то уже - на случай термоядерного удара.
0,5гр. я трактовал как погрешность датчика, а не точность измерения.
С термоядом боюсь зашкалит быстрее чем измерит, а раньше от ЭМ импульса сдохнет)))).
Охота, позанимайся математикой. Кушает 7мВт (сколько времени не знаем), находится в пластике (температурную проницаемость не знаем), как быстро сможет рассеять выделенную мощность?))))
Охота, позанимайся математикой. Кушает 7мВт (сколько времени не знаем), находится в пластике (температурную проницаемость не знаем), как быстро сможет рассеять выделенную мощность?))))
да - рисуем в SolidWorks 3D модель датчика и попадаем в информационную яму, что мы ничего не знаем - температурную проницаемость корпуса, который накапливает тепло и ног датчика, которые рассеивают тепло.
Как нибудь будет не лень, действительно попробую поэкспериментировать вживую.
Кстати есть подобный даташит Чернова.Г. там на последней странице есть приписка об этом. Сам Даллас скорее всего скромно умалчивает.