• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Энергопотребление ESP(сверхновое)

nikolz

Well-known member
Продолжаю выкладывать результаты исследований различных режимов работы eSP на стандартном SDK 2.1.0
--------------------
Информация к размышлению.
Сочетание режима deep-sleep и wifi_fpm_do_wakeup.
Алгоритм работы такой.
ESP8266 просыпается из режима deep-sleep, отключает WIFI и CPU и ждет прерывания от пинов (т е датчиков) при этом ток потребления примерно 1.5(0.5 без светодиода) ма (см на картинке) после получения прерывания от GPIO включает wIFI и передает на сервер данные по UDP, после получения ответа от сервера ложиться спасть (ток 10-30 мка)
upload_2017-10-24_16-54-39.png
================
а это картинка последовательного отключения после просыпания
1) отключаем WIFI, работает cPU ток 15 ма
2) отключаем и CPU и ждем прерываний от GPIO ток 0.5 ма
3) при приходе сигнала с GPIO включаем CPU и WIFI ток 70 ма, передаем на сервер по протоколу UDP ток 300 ма, получаем подтверждение 70 ma
4) включаем deep-sleep на 10 секунд (или на сколько надо) ток потребления 10-30 мка.

upload_2017-10-24_17-17-15.png
 
Последнее редактирование:

pvvx

Активный участник сообщества
3) при приходе сигнала с GPIO включаем CPU и WIFI ток 70 ма, передаем на сервер ток 300 ма
А где соединение модуля с AP?
Передаем собственно составленные пакеты через драйвер WiFi в режиме приема-передачи сырых пакетов с коллизией всем окружающим?

+ Promiscuous mode в микроконтроллере ESP-8266
 
Последнее редактирование:

nikolz

Well-known member
А где соединение модуля с AP?
Передаем собственно составленные пакеты через драйвер WiFi в режиме приема-передачи сырых пакетов?
Соединение с AP происходит в момент включения питания либо после потери связи с роутером, а также в 150 мс, которые проходят с момента включения WIFI и CPU в п3.
-------------------------------
Работаем по протоколу UDP с подтверждением приема сервером .
 

pvvx

Активный участник сообщества
Соединение с AP происходит в момент включения питания либо после потери связи с роутером, а также в 150 мс, которые проходят с момента включения WIFI и CPU в п3.
-------------------------------
Работаем по протоколу UDP с подтверждением приема сервером .
Если соединение с роутером есть, то необходимо отслеживать каждый beacon на модуле. Это по стандарту каждые 0.1024 секунды и отвечать на всякие запросы арбитража. Иначе роутер обязан выкинуть клиента с неподдерживаемым стандарту протоколу WiFi. Чтобы было возможно пропустить несколько beacon, в WiFi веден режим сна с DTIM(n) (n - кол-во пропускаемых beacon спящим устройством). Вход и выход в/из данного режима модуль должен согласовать с AP. Пиков тока при передачи этих согласований тоже нет на вашей диаграмме.
Если роутер переключен в режим сниффера, то можно сделать как у вас (Promiscuous mode в микроконтроллере ESP-8266). Но тогда не понятно, что модуль делает столько времени и жрет ещё при этом (!). Передача нескольких сырых пакетов - это всего несколько мкс. Ожидание подтверждения от роутера-сниффера - так-же не более десятка мкс.

UDP то тут при чем? Вы хотите использовать формат кадров от UDP?

Espressif же уже выдумала свой "отсебятенный" протокол посылки-приема кадров WiFi и к нему есть API...
 
Последнее редактирование:

nikolz

Well-known member
Если соединение с роутером есть, то необходимо отслеживать каждый beacon на модуле. Это по стандарту каждые 0.1024 секунды и отвечать на всякие запросы арбитража. Иначе роутер обязан выкинуть клиента с неподдерживаемым стандарту протоколу WiFi. Чтобы было возможно пропустить несколько beacon, в WiFi веден режим сна с DTIM(n) (n - кол-во пропускаемых beacon спящим устройством). Вход и выход в/из данного режима модуль должен согласовать с AP. Пиков тока при передачи этих согласований тоже нет на вашей диаграмме.
Если роутер переключен в режим сниффера, то можно сделать как у вас (Promiscuous mode в микроконтроллере ESP-8266). Но тогда не понятно, что модуль делает столько времени и жрет ещё при этом (!). Передача нескольких сырых пакетов - это всего несколько мкс. Ожидание подтверждения от роутера-сниффера - так-же не более десятка мкс.

UDP то тут при чем? Вы хотите использовать формат кадров от UDP?

Espressif же уже выдумала свой "отсебятенный" протокол посылки-приема кадров WiFi и к нему есть API...
Нового Вы ничего не сказали. Эти статьи я читал.
У меня протокол uDP и сервер на компе.
А Все остальное, Вами сказанное, есть в ВИКИ и желающие могут там прочитать.
Относительно того,кто, что придумал. Не нравиться - не используйте. А то Вы - откуда пьете, туда и плюете.
Может хватит следить за мировым порядком и мнить себя карающим мячом?
 

pvvx

Активный участник сообщества
Нового Вы ничего не сказали. Эти статьи я читал.
У меня протокол uDP и сервер на компе.
UDP? И как же без соединения с роутером он работает?
А Все остальное, Вами сказанное, есть в ВИКИ и желающие могут там прочитать.
Про то, как без соединения с роутером по стандарту WiFi передавать UDP пакеты там ничего не сказано. Допишите или дайте сслыку.
Относительно того,кто, что придумал. Не нравиться - не используйте. А то Вы - откуда пьете, туда и плюете.
Может хватит следить за мировым порядком и мнить себя карающим мячом?
Это вы про что?
 

nikolz

Well-known member
UDP? И как же без соединения с роутером он работает?
Про то, как без соединения с роутером по стандарту WiFi передавать UDP пакеты там ничего не сказано. Допишите или дайте сслыку.

Это вы про что?
Вам нечего делать?
мне не интересно с Вами беседовать, а оправдываться перед Вами или в чем то вас убеждать тем более нет желания.
Я понимаю, что Вам досадно - столько накопали - а все на свалку.
Бывает...
Пишите в личку , если действительно будет желание беседовать, а не ерничать.
 

enjoynering

Well-known member
а я соглашусь с pvvx. если уж пишитете - "А Все остальное, Вами сказанное, есть в ВИКИ и желающие могут там прочитать", то ССЫЛКУ надо прикладывать.
 

pvvx

Активный участник сообщества
Вам нечего делать?
мне не интересно с Вами беседовать, а оправдываться перед Вами или в чем то вас убеждать тем более нет желания.
Можно я тут процитирую ваше-же из одного поста :) : Пишите в личку , если действительно будет желание беседовать, а не ерничать.
Я понимаю, что Вам досадно - столько накопали - а все на свалку.
Бывает...
Какая досада может быть в хобби и тем более если ESP уже устарел? Ну и ранее на ESP8266 уже представлял варианты пошустрее и экономичнее ваших, но RTL-ки ещё быстрее и экономичнее...
Вы в первый раз сталкиваетесь с электроникой? У неё всё имеет свой ограниченный срок жизни и актуальности (от года до 5-ти лет в пределе). Привыкайте. Далее всегда сравнивают новые вещи со старыми. Так происходит развитие.
----
Я вот не видел стандарта WiFi, по которому вы пытаетесь работать и строите измерения. По этому и прошу указать ссылку или сделать описание его. У народа с ESP8266 время соединения с AP от 2-х до 10 секунд и тенденций уменьшения не наблюдается. Выходит, что вы что-то скрываете от всех (или приводите рисунки графиков от руки или что-то у вас сбоит в измерителе).
------
Так-же есть документация на SDK от производителя, где четко указано время на этап инициализации WiFi.

При работе с большими перерывами в deep_sleep, и особенно с автономным питанием используют полную калибровку WiFi на напряжение питания, температуру и обстановку при инициализации. Большой перерыв для WiFi считается от 10 пауз стандартных beacon (1 сек), где уже режим сна с DTIM(x) нерационален. При DTIM(10) пинг уже 1 сек.

Это время у Espressif для ESP8266 указано как: RF initialization will do the whole RF calibration which will take about 200 ms; this increases the current consumption.


Теперь по этапам, со старта:

1) Загрузка системы. Тут ESP8266 явный аутсайдер по всем параметрам.

2) Инициализация SDK. У ESP8266 это происходит достаточно долго по сравнению с другими WiFi SoC из-за нескольких ошибок при разработке чипа (требуется полная переинициализация PLL и прочего оборудования из-за кварца в 26 МГц, а не проектного на 40 МГц). Так-же требуется калибровка RTC (это практически у всех WiFi-SoC).

3) Инициализация WiFi блока. Тут у ESP8266 по докам – от 200 мс. На данном этапе он более ничего не делает, т.к. нет RTOS. У других модулей калибровка адаптивная и выполняется уже на этапе работы. Инициализация у них производится сразу в необходимый режим и включает п.п. 4.1. и п.п.4.2 в зависимости от установок. На самом слабом модуле RTL8710AF инициализация WiFi совместно с LwIP и RTOS в базовой версии SDK занимает 275 мс со времени старта CPU. После этого модуль готов к передаче и приему любых посылок (например в режиме полноценного сниффера с HT40). По этой причине многие знакомые с ESP8266 и взявшие RTL-00 удивляются о скоростном соединении при использовании IAR и SDK3.5 и пишут про это на форумах. :p В своей сборке web-свалки я не стремлюсь получить скорость, т.к. она предназначена для другого. Опыты по скорости "с патчами" SDK полноценного соединения-отсоединения приведены в профильных темах использования RTL для автономных устройств...

4) Соединение с AP. Включает в себя п.п:

4.1) Оповещение сети о выходе модуля в WiFi сеть.

4.2) Сканирование сети на поиск AP. Бывает активная и пассивная. Есть ещё модификации. В итого это обычно укладывается в 3 типа основных вариантов. У дров WiFi ESP8266 выбора не предусмотено. Он тупо перебирает все каналы WiFi, на каждом посылает запрос и ждет приема ответов и beacon-ов не менее 100 мс (паузы одного beacon). Итого, если каналов включено 13 -> 13*0.1xx = от 1.3 сек. Прервать процесс скана по нахождению нужной AP в ESP не предусмотрено.

4.3) Этап соединения с AP. Если есть встроенный аппаратный Crypto-Engine и он используется, то это дело быстрее. ESP8266 голый и тормоз в данном вопросе.

4.4) Получение модулем IP. Бывает с вызовом запросов DHCP или фиксированный. На старых роутерах на запросы-ответы на получение IP уходит от 0.7 сек. На новых роутерах с более быстрыми CPU и более шустрых WiFi-SoC это время сокращается и часто значительно, т.к. попадает в один арбитраж AP между одной паузой beacon. Но ESP8266 не успевает...

На этом этап соединения можно сказать закончен.

5) Передача информации. Тут всё зависит от целей приложения.

6) Отсоединение от AP. Туда входит закрытие всех соединений и согласование с AP отключения станции, что высвобождает ресурсы AP.

7) Переход в режим пониженного потребления. Для ESP8266 переход в deep_sleep занимает от 100 мс.

@nikolz - сколько пунктов вы выкинули из стандарта соединения-отсоединения к AP? Все? :)
 
Последнее редактирование:

nikolz

Well-known member
Информация к размышлению.
В данном примере реализованы все возможные (или почти все) варианты режимов работы ESP.
Программа реализована на стандартном SDK 2.1.0 и модифицированном загрузчике rboot.
Модификация пока свелась к тому, что в rboot добавлен таймер RTC.
---------------------------------------
Алгоритм работы ESP следующий.
При старте загрузчика ESP запускает таймер (чтобы подождать готовность датчиков ) при этом работает лишь процессор
Как видим в дальнейшем из картинок, время перехода в режим работы таймера составляет примерно 40 мс.
После завершения работы таймера - это примерно 3.5 сек(потребление 15 ма), происходит загрузка основного приложения.
После загрузки ESP переходит в режим fpm_MODEM-Sleep , потребление 15 ма и работает в этом режиме 100 мс (на графике до 3655) . После этого, ESP переходит в режим fpm_LIGHT_SLEEP_T ток потребления 500 мка и в этом режиме ждет прерывание от GPIO (кнопка) на графике до 6150 примерно.
После нажатия кнопки,ESP переходит в режим fpm_MODEM-Sleep,потребление 15 ма, т е как бы думает, послать или не послать. После этого , решив послать соединяется с роутером и посылает привет серверу по протоколу UDP, потом принимает ответ и уходит в deep-sleep. На графике это участок после 6250 примерно.Длительность данного участка примерно 150 мс.
А вот и картинка:
upload_2017-10-29_10-47-36.png
------------------
Что еще не сделано.
В стадии реализации:
1) выход из режима fpm_LIGHT_SLEEP_T по тайму
2) проверка напряжения питания в режиме старта загрузчика. Надо отправить спать, если автономный источник питания еще не зарядился , например от солнечной батареи. При этом показания датчика могут быть сохранены в памяти RTC (реализовано) а ESP может уйти спать без загрузки основного приложения (реализовано).
 
Последнее редактирование:

nikolz

Well-known member
Это результат эксперимента с режимом frm_Light_sleep по тайму.
В данном случае используется стандартный загрузчик, его время исполнения 130 мс примерно
Потом включается режим Modem_sleep на 100 ms, затем Light_sleep примерно на 800 ms, затем Modem_sleep на 100 ms , потом WIFI и после всего этого deep-sleep.
А вот и картинка:
upload_2017-10-29_13-27-50.png

------------------------------
Режим frm_Light_sleep по тайму удобно использовать для ожидания готовности датчиков.
например электрохимические датчики различных газов или датчик температуры DS1820
т е любые медленные устройства, так как ток потребления ESP в этом режиме менее 1 ма ( в моих измерениях на ESP12 получилось менее 600 мка) что в 20 раз меньше тока потребления CPU и в 100 раз меньше, чем при включенном модеме.
В отличии от deep-sleep нет потери энергии на старт загрузчика.
-------------------------
Ну что еще надо для ...
 
Последнее редактирование:

=AK=

New member
так как ток потребления ESP в этом режиме менее 1 ма ( в моих измерениях на ESP12 получилось менее 600 мка)
Мне 1 мА отдавать ни за что ни про что жалко. Поэтому я ESP в качестве основного проца не использую, он у меня чисто связные функции выполняет. По мере надобности, изредка, основной проц его будит, а потом снова загоняет в сброс. А сам основной проц и все его обрамление, включая дисплей, потребляют в среднем около 100 мкА. Можно и до 30 мкА догнать, но мне и 100 мкА хватает.
 

nikolz

Well-known member
Мне 1 мА отдавать ни за что ни про что жалко. Поэтому я ESP в качестве основного проца не использую, он у меня чисто связные функции выполняет. По мере надобности, изредка, основной проц его будит, а потом снова загоняет в сброс. А сам основной проц и все его обрамление, включая дисплей, потребляют в среднем около 100 мкА. Можно и до 30 мкА догнать, но мне и 100 мкА хватает.
Если не секрет то какой процессор с периферией в активном режиме потребляет 100 мка?
 

nikolz

Well-known member
Мне 1 мА отдавать ни за что ни про что жалко. Поэтому я ESP в качестве основного проца не использую, он у меня чисто связные функции выполняет. По мере надобности, изредка, основной проц его будит, а потом снова загоняет в сброс. А сам основной проц и все его обрамление, включая дисплей, потребляют в среднем около 100 мкА. Можно и до 30 мкА догнать, но мне и 100 мкА хватает.
Вообще-то 1 ма тратится вместо того чтобы тратить 40 ма при старте ESP.
А когда ESP спит то тратит примерно 30 мка и просыпается по таймеру либо по прерыванию по пину. Т е все тоже самое но без доп процессора.
 

=AK=

New member
как вы его паяете
Микросхемы в корпусах BGA и QFN/DFN я паяю горячим воздухом. Маленький секрет состоит в том, чтобы сначала примерно минуту прогреть плату снизу прехитером, и только потом дуть сверху феном. Я использую прехитер Atten 853A. Ну и флюсом надо намазать и PCB, и пины. Правда, легкие BGA корпуса трудно паять, они легко сдуваются феном, им нужна оправка, чтобы удержать на месте.

А конкретно Appolo не использую, у него АЦП не очень... Вы спросили про малопотребляющий проц - я ответил.
 

pvvx

Активный участник сообщества
А флешь RTC не "протрется" за пару месяцев?
Во всех последних SDK есть установки/включение WiFi с опциями без записи конфига во Flash. А если пользуетесь моими сборками SDK или сами расковыриваете его, то всегда можно написать перехват или замену функции записи/чтения конфигов из закрытых китайских либ на свои... Кроме конфигов WiFi надо ещё махнуть сохранение калибровок для быстрого рестарта после deep_sleep и калибровок по напряжению питания - они пишутся в другой сектор, в одно и то-же место, после блока esp_init_data_default.bin.

А в Arduino протрет дыру наверняка...

Для =AK= это не важно - он перепаивает Flash после пары месяцев работы модуля в устройстве с мало-потребляющим дополнительным MCU. :)

В общем это решаемая часть, в отличии от функционирования ESP8266 с активным "просыпанием" по пинам при малом токе потребления. Слишком много жрет в таком режиме и очень долгое время восстановления.
 
Последнее редактирование:
Сверху Снизу