Микропотребление ESP8266-12E

[alexhi]

Делаю устройство батарейке, в режиме
System.deepSleep(0,eDSO_RF_CAL_BY_INIT_DATA);
получаю около 15 мкА, все GPIO на вход. У кого то получалось уменьшить потребление?

 

[kkozyrev]

Разве 15 микро это много? Или все-таки 15 мили ?

 

[alexhi]

Конечно микроампер он же в sleep , я на ESP-01 получал около 10 мкА
http://esp8266.ru/forum/threads/web...ylkoj-na-e-mail-ot-batarejki-3v.71/#post-1657
думал что ESP12E что то улучшили . Для батарейки 15 mкA это прилично.
Судя по этой таблице:
http://bbs.espressif.com/viewtopic.php?f=6&t=133
В режиме Power Off должно быть 0.5mкА ,кто то пробывал этот режим и будет ли выходить из него модуль по RESET

 

[pvvx]

Судя по этой таблице:
http://bbs.espressif.com/viewtopic.php?f=6&t=133
В режиме Power Off должно быть 0.5mкА ,кто то пробывал этот режим и будет ли выходить из него модуль по RESET

Таблица не учитывает потребление Flash, любых вешних компонентов типа "подтяжек" к чипу ESP8266, а так-же активности WiFi и кол-ва пакетов за единицу времени
Чистый китай-рекламный трюк
Потребление от батарейки составляет в основном время работы ПО.
Из жручести следует отметить потребление CPU при записи своей памяти и работе с Flash. При работе с Flash следует учитывать тип Flash и согласование её с чипом ESP (проводники, их емкости...). С Winbond flash потребление меньше.
Так-же, во время работы ПО сильно сказывается кол-во прерываний по назначенным программным таймерам, т.к. в SDK используется команда ожидания прерывания выключающая большую часть чипа ESP8266 (потребление в пару mA).
Загрузка и инициализация после deep-sleep потребляет очень много и длительность этого пика потребления зависит от выбранного ПО (проекта).
Как итог, потребление от батарейки напрямую зависит от выбранного ПО и его скорости инициализации после deep-sleep.
"Rapid Loader" сокращает время дикого потребления при загрузке до запуска инициализации с 0.2 сек до 30 ms. Т.е. дает уменьшение потребления в 200/30 раз

 

[alexhi]

Таблица не учитывает потребление Flash, любых вешних компонентов типа "подтяжек" к чипу ESP8266, а так-же активности WiFi и кол-ва пакетов за единицу времени
Чистый китай-рекламный трюк

Это да, приврать они любят У меня задача вообщем то простая,нажали на кнопку(это бывает редко) модуль проснулся , соединился с WIFI сетью,выдал несколько пакетов(по UDP) и благополучно уснул.Сейчас это получается, но жрет 15mkА.Можно конечно сделать потребление ~0 ,поставив полевую сборку с блокировкой модулем,но хочется без лишних деталей, софтом красивее Почитаю еще, как то мало на эту тему док.видно никому не интересно.

 

[pvvx]

Это да, приврать они любят У меня задача вообщем то простая,нажали на кнопку(это бывает редко) модуль проснулся , соединился с WIFI сетью,выдал несколько пакетов(по UDP) и благополучно уснул.Сейчас это получается, но жрет 15mkА.Можно конечно сделать потребление ~0 ,поставив полевую сборку с блокировкой модулем,но хочется без лишних деталей, софтом красивее Почитаю еще, как то мало на эту тему док.видно никому не интересно.

Надо лепить отдельное питание на RTC. Тогда можно задействовать и ухищрения ПО.
Выигрыша во время отключения это сильно не дает, т.к. RTC кушает ~6 мкА, но при 0.8..1В (диод и батарейка на 1.2..1.5В - хватает "утечки" диода типа КД521, по тому и не - 0.6В). Но остальное питание можно снять.
Для кучи:
Измеренные ТТХ по питанию модуля:
Потребление при передаче на скорости к 1 мегабайт в секунду - пример два графика в конце
Потребление модулем в разных режимах WiFi-sleep модуля и стартовые примеры
Потребление по питанию часов (по ноге RTC_VDD)
Скорость реакции ножки RESET по просыпанию от ноги GPIO16 (deep-sleep).
Время от старта модуля до исполнения кода из flash при использовании специального загрузчика = 30 ms.
PS: Модуль ESP-12E не лучший для режимов микро-потребления. У него лишние нагрузки на шину QSPI работающую на 80 MHz.
При понижении до 40 MHz интерфейса с flash получаем большее потребление за счет уменьшения скорости работы "кэша" flash и скорости загрузки.
Увеличение CLK CPU до 160 MHz тоже в итоге уменьшает потребление, безусловно если правильно написано ПО.

 

[pvvx]

Почитаю еще, как то мало на эту тему док.видно никому не интересно.

Почему не интересно? По причине невозможности влияния на поведение ПО?
Прикидочные расчеты показывают, что ваша задача - посылка пару пакетов UDP с инициализацией связи ST<->AP укладывается до 0.5 сек со средним потреблением ниже 70 mA.
Остальное потребление в deep-sleep - не существенно.
Но, чтобы достигнуть минимальное время соединения и передачи после deep-sleep, требуется правильное ПО Всякие Arduino и типа - не катят.
Так-же существует зависимость потребления от используемых датчиков на время снятия с них замеров. Тут вообще большая тема для выкрутасов Все варианты c этим решаются только спец. загрузчиком и типа своей операционкой, которая должна осуществлять управление deep-sleep без всяких загрузок SDK, пока данные с датчиков не набраны (не готовы для передачи или осуществляется ожидание порогов с датчика для передачи аварий и т.д.). На то уже начало положено https://github.com/pvvx/SDKnoWiFi

Как итого, в режиме отслеживания порогов для сигнализации, получаем формулу типа:
30..35ms время работы опроса значений с датчика + остальное deep-sleep. При срабатывании происходит загрузка с SDK на время до 0.5 сек на передачу пакетов аварии.
При такой организации можно использовать любой источник питания, даже не дающий пару mA в пике, за счет накопления в емкости, достаточной для поддержки самого долгого цикла просыпания модуля, что позволяет "выедать" батарейку во много раз дольше, до полного окончания в ней каких-либо хим.физ реакций

Беретесь реализовать такую систему? Или тоже "не интересно"