Алгоритм энергосбережения на практике
От автора
Это моя первая статья — жду конструктивной критики, мнений, замечаний, вопросов.
Предисловие
Эта статья посвящена решению проблемы энергосбережения, которая присутствовала при разработке ПО радио-модуля под нужды детектирования разрыва\замыкания цепей и получения температуры.
Что имеем
Был разработан радио-модуль на «борту» которого: «мозг» — atmega128rfa1, со встроенным радиопередатчиком и датчик температуры FM75. Питается устройство от 1-ой батарейки CR2032 (3.3 В, ~200 мА*час).
Функции, которые выполняет модуль
- при замыкании\размыкании контактов, заведенные на внешнее прерывания — отсылка данных о событии серверу, с подтверждением о приеме;
- при приеме команды от сервера — выполнить необходимые действия, отправить результат выполненных действий, получить подтверждение о приеме (для рассматриваемой задачи, такими действиями было — получение текущей температуры, получение состояния контактов, управление состоянием модуля);
Применимость модуля
- как дополнение к бытовым датчикам движения
- как радио-кнопка (для включения\включения освящения: закладывается в обычные выключатели, вместо подведения разрыва одного из проводов 220 В; также наличие напряжения в сети 220 В, при подключении датчика ноля; положение дверей и тд.)
- для периодического сбора данных о температуре
Проблема
Потребление модуля:
- со включенным радиопередатчиком ~9.4 мА
- при непрерывной передачи данных по радио на полной мощности ~14 мА
- с выключенным радиопередатчиком ~5.4 мА
- при получении температуры ~25 мА
- в режиме глубокого сна (power down mode) ~200 нА
Таким образом, если не выключать радиопередатчик, и ничего не передавать и не принимать, то батарейки 200мА теоретически должно хватать на 20 часов, на практике порядка 16 часов. А если говорить о том, что модулю нужно выполнять еще и какие то функции ?!
Приведем два примера эксплуатации модуля: обычной и экстремальной.
Обычная эксплуатация (предполагаемая):
- 1 раз в час получение текущей температуры, по запросу от сервера
- 1 раз в час включение\выключение, допустим — света (т.е. модуль сообщает серверу о состоянии выключателя, отвечающего за свет)
Практическое время работы модуля изменилось не существенно и составило все те же 16 часов.
Экстремальная эксплуатация, для поиска решения проблемы энергосбережения и для наглядности:
- 1000 раз в час получение текущей температуры, по запросу от сервера
- 1000 раз в час включение\выключение, допустим — света (т.е. модуль сообщает серверу о состоянии выключателя, отвечающего за свет)
Практическое время работы модуля составило скромные 4 часа.
Тут кончено есть существенная погрешность в оценке, т.к. батарейки имеют широкий разбег емкости от 190 до 250 мА в одной партии, но тем не менее, для грубой оценки времени работы этого достаточно.
Преследуемые цели
Необходимо, чтобы модуль от батарейки емкостью 200 мА в комнатных условиях работал не меньше года в режиме нормальной эксплуатации (описан выше).
Решение
Решение очевидно — использование спящих режимов и не просто спящих, а именно «глубокого сна» (power down mode). Предлагаемый ниже алгоритм применим для микроконтроллеров разных производителей, поэтому будет приведен лишь алгоритм (без кода) — составить код, используя datasheet нужного микроконтроллера, не составит труда.
И так, у микроконтроллеров (далее «МК») есть разные режимы сна и способы выведения из этих режимов.
Но, нам важно, чтобы МК откликался на сообщения от сервера! — а это значит что радиопередатчик должен быть включен — есть режим когда МК спит, но «слушает» эфир на предмет сообщений для него и просыпается, если таковые есть — для нас не подходит, т.к. энергопотребление порядка ~10 мА.
Что тогда делать ?! Ведь в режиме «глубокого сна», радио отключено (т.е. МК уже ничего не будет принимать или передавать), и вывести его из этого режима, можно только по сигналу с внешнего прерывания, ЛИБО по «собачьему таймеру» (Watch Dog), который умеет работать как в режиме сбрасывания МК, так и в режиме вызова прерывания — вот он то нас и спасет!
Алгоритм
И так, для решения поставленной цели был разработан, отлажен и протестирован следующий алгоритм:
1) МК все время находится в режиме «глубокого сна» (power down mode).
2) При срабатывании внешнего прерывания (изменение положения выключателя), МК просыпается, отсылает сообщение серверу, получает подтверждение приема и снова ложится в сон.
3) Т.к. нам необходимо, ко всему прочему, выполнять команды с сервера, необходимо периодически включать радио и прослушивать эфир на предмет сообщений для МК. Ставим Watch Dog в режим прерывания с периодичностью 0.016 до 8 секунд (для наших нужд достаточно периода в 8 сек). В прерывании слушаем эфир, если для MK ничего нет, то снова ложимся в сон.
Разберем пункты подробнее
Находясь в «глубоком сне», МК потребляет ~200 нА (если бы не было саморазряда батарейки, то 200 мА хватило бы на много… лет). Не будем сейчас учитывать саморазряд.
Тогда, на время «жизни» влияет лишь то, насколько часто отрабатывают пункты 2 и 3.
При срабатывании внешнего прерывания на пункте 2, МК работает порядка 20 мс — что тоже можно не учитывать в режиме «нормальной эксплуатации».
Основной потребитель энергии у нас пункт 3. Для наших задач, нам достаточно чтобы МК откликнулся на сообщение от сервера в течении 8 сек. Поэтому настраиваем «собачий таймер» именно так, что бы он проверял эфир раз в 8 сек и сканировал эфир на протяжении 20 мс, затем снова падал в сон. Т.о. если нет сигнала с пункта 2 и нет сообщений от сервера, то наш МК работает 20 мс за 8 секунд, что выливается в 0.0235 мА*час.
Чтобы достучаться до МК, сервер непрерывно в течении 8 секунд посылает пакеты для него, МК отвечает по разному — может мгновенно, а может и в конце 8 секунд — но отвечает!
Результат
Воплотив алгоритм в код, модуль (вообще их несколько) на текущий момент проработал больше 378 дней. Остаток емкости на батареи 40 мА — так что еще будет работать. Режим эксплуатации правда более щадящий, чем предполагалось в описанном выше режиме «обычной эксплуатации» — но такова жизнь, готовились к худшему, надеясь на лучшее.
P.S.
Надеюсь статья кому нибудь пригодится в решении подобной задачи.
Развитие проекта
Эта статья вызвала живой интерес к разработке как «железа» так и ПО среди хабровчан, чему я несказанно рад. Сейчас я закончил разработку модуля под один из проектов на хабре — DIY-диммер «Умного дома» (это взаимодействие результат, как раз, этой статьи).