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

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

nikolz

Well-known member
Это сделали и вы, сняв график работы примера в GitHub - pvvx/SDKnoWiFi: ESP8266 Open SDK without WiFi (startup < 30 ms to complete the flash cache) :p

Я вам отвечал - в Lua это время бывает и за несколько секунд, т.к. это время инициализации Lua до пользовательского вызова WiFi если стоит SPIFFS и он сильно фрагментирован.
В других случаях с Espressif SDK время от старта (срабатывания RESET) до рабочего пользовательского вызова работы с WiFi (инициализации всей системы, включения LwIP, таймеров и прочего необходимого) измеряется от 200 ms. Не менее.
Описанная у Espressif калибровка WiFi - это один из сотни процессов инициализации до работоспособности SDK.
Я Вам тоже написал что Описанная у Espressif калибровка WiFi - это время от 2 до 18ms а не 200
И что никаких других функций не исполняется
так как измеряется время от конца user_init до срабатывания колбека wifi_handle_event_cb
по событию wifi_handle_event_cb. Это время 143 ms. Других программ нет.
Если не будите дурака включать то поймете, что ничего здесь сложного нет и причину задержки я написал как гипотезу.
Если не можете подтвердить или опровергнуть, я Вас за язык не тяну. Просто скажите, что не знаете ответа.
Или слабо признаться? Мания величия не позволяет?
 

pvvx

Активный участник сообщества
Я Вам тоже написал что Описанная у Espressif калибровка WiFi - это время от 2 до 18ms а не 200
И что никаких других функций не исполняется
так как измеряется время от конца user_init до срабатывания колбека wifi_handle_event_cb
по событию wifi_handle_event_cb. Это время 143 ms. Других программ нет.
Если не будите дурака включать то поймете, что ничего здесь сложного нет и причину задержки я написал как гипотезу.
Если не можете подтвердить или опровергнуть, я Вас за язык не тяну. Просто скажите, что не знаете ответа.
Или слабо признаться? Мания величия не позволяет?
Кто вам сказал, что "время от конца user_init до срабатывания колбека wifi_handle_event_cb" составляет 143 ms? :)
На вашем графике этого нет.
До user_init исполняется стартовая инициализация, в которую входит и калибровка - подгрузка записанных значений измерений VDD из сектора за данными esp_init_data_default.bin :p. А так-же сохраненных настроек WiFi и их применение.
Т.е. вы лжете - гадаете на "кофейной гуще", которую сами сварили и не знаете что там у вас.
 
Последнее редактирование:

nikolz

Well-known member
Кто вам сказал, что "время от конца user_init до срабатывания колбека wifi_handle_event_cb" составляет 143 ms? :)
На вашем графике этого нет.
Это я Вам доп информацию сообщаю. измерено в программе. Это измерение совпадает с временем на графике в 150 мс.Могу рассказать как я его измеряю.
Но мне не интересно да и нет надобности что-то кому-то доказывать. Поэтому я задал конкретный вопрос.
Понял что ответа на него никто не знает.
Тоже ответ.
 

pvvx

Активный участник сообщества
Гадание по вашему графику свидетельствует, что выход в эфир WiFi модуль производит после 280 мс, а до этого не производит никаких стандартных действий по регламенту соединения к AP принятым в спецификации WiFi. Нет пиков активности передатчика до 280 мс после начала потребления питания, что не значит даже отпускание RESET (до этого ещё дцать мс стартует генератор кварца).
Вот эти 280 мс и есть у вас инициализация дров WiFi, без работы.
А вы обещали всем на ESP8266 80 мс :) на что вам отвечаю - выход из sleep с активацией WiFi блока у RTL менее нескольких мкс и смысла возится с устаревшим ESP8266 нет.

В ESP8266 это не позволяют сделать быстро ошибки допущенные Espressif и чип не имеет возможности оставить включенным питание на часть SRAM c таймерами и прочими устройствами c отключением CPU и блока WiFi при приемлемом потребляемом токе. Восстановление работы CPU там требует длительного ожидания выхода на режим PLL. Так-же не предусмотрены разные отключения внутренностей – отсутствует блок PMU. Пользователю SDK это предоставлено только через deep_sleep с потерей информации в RAM и новой полной загрузкой SDK с итоговыми от 280 ms, как вы и измерили. Хотя режим LIGHT и работает на ESP8266 с отключением CPU и WiFi, но включение CPU и WiFi требует значительно больших затрат (восстановление PLL), плюс потерю таймеров и других прерываний за время отключения. ESP8266 и его SDK не создавался для решения использования в автономных задачах.

@nikolz - Совершенно не понятны ваши потуги реализовать режим LIGHT sleep с DTIM(x) через deep_sleep() на ESP8266.:confused:

Открываете доку 9B-ESP8266-Sleep_Mode_Low_Power_Solutions__EN_V1.1_20160415.pdf и читаете – потребление у ESP8266 в режиме Light-sleep при DTIM(10) – 0.55 мА, что уже менее чем у вас.

При DTIM(10) и стандартном следовании Beacon в 0.1024 сек, реакция у чипа к 1 сек.

Не верите своим любимым Espressif ? :D
 
Последнее редактирование:

nikolz

Well-known member
Гадание по вашему графику свидетельствует, что выход в эфир WiFi модуль производит после 280 мс, а до этого не производит никаких стандартных действий по регламенту соединения к AP принятым в спецификации WiFi. Нет пиков активности передатчика до 280 мс после начала потребления питания, что не значит даже отпускание RESET (до этого ещё дцать мс стартует генератор кварца).
Вот эти 280 мс и есть у вас инициализация дров WiFi, без работы.
А вы обещали всем на ESP8266 80 мс :) на что вам отвечаю - выход из sleep с активацией WiFi блока у RTL менее нескольких мкс и смысла возится с устаревшим ESP8266 нет.

В ESP8266 это не позволяют сделать быстро ошибки допущенные Espressif и чип не имеет возможности оставить включенным питание на часть SRAM c таймерами и прочими устройствами c отключением CPU и блока WiFi при приемлемом потребляемом токе. Восстановление работы CPU там требует длительного ожидания выхода на режим PLL. Так-же не предусмотрены разные отключения внутренностей – отсутствует блок PMU. Пользователю SDK это предоставлено только через deep_sleep с потерей информации в RAM и новой полной загрузкой SDK с итоговыми от 280 ms, как вы и измерили. Хотя режим LIGHT и работает на ESP8266 с отключением CPU и WiFi, но включение CPU и WiFi требует значительно больших затрат (восстановление PLL), плюс потерю таймеров и других прерываний за время отключения. ESP8266 и его SDK не создавался для решения использования в автономных задачах.

@nikolz - Совершенно не понятны ваши потуги реализовать режим LIGHT sleep с DTIM(x) через deep_sleep() на ESP8266.:confused:

Открываете доку 9B-ESP8266-Sleep_Mode_Low_Power_Solutions__EN_V1.1_20160415.pdf и читаете – потребление у ESP8266 в режиме Light-sleep при DTIM(10) – 0.55 мА, что уже менее чем у вас.

При DTIM(10) и стандартном следовании Beacon в 0.1024 сек, реакция у чипа к 1 сек.

Не верите своим любимым Espressif ? :D
Вы внимательно смотрите на графики и читайте посты, а то у вас получилась каша в голове.
======================
специально для Вас поясняю.
1) 85 мс Вы можете видить на графиках с названием nboot_SDK_2.1.0. На этих графиках показна активность ESP в нутри лоадера, т е та самая мечта которую Вы не доделали в Вашем SDKnoWIFI.
В отличие от Вашего решения, в мое на основе стандартного SDK и из лоадера можно либо пойти спать либо загрузить WIFI и передать сообщение.
Это показано на графиках с названием nboot_SDK_2.1.0_UDP
В этом случае реализован алгоритм, когда eSP выходит на связь на каждое восьмое просыпание.
Т е семь раз просыпается и снова спать а на восьмое передает сообщение.
Таким образом, данное решение позволяет читать датчики сохранять значения в памяти RTC и либо спать либо передавать данные. При этом если WIFI не нужен, то минимальное время активности 85 ms, а если надо связь по WIFI то время активности до 3 секунд при старте ESP или потере связи с роутером и 0.3 сек в остальное время.
================================
На последних графиках нет в названиях nbooot, т е это режимы работы на стандартном загрузчике.
Время работы загрузчика при этом не 85 mc а 130 mc.
Но в этих графиках я рассматриваю не режим загрузки а режим работы eSP уже после перехода на user_init.
Т е меня интересует интервал от 130 мс (это старт User_init) до 280 mc - это страт send ( т е событие EVENT_STAMODE_CONNECTED)
==============================
 

nikolz

Well-known member
Вот графики работы eSP при различных режимах калибровки RF при выходе из deep_sleep
upload_2017-10-17_10-11-21.png
Я использую deep_sleep_option(2)
---------------------------------
deep_sleep_set_option(0) The 108th Byte of the init parameter determines whether the RF
calibration will be performed after the chip wakes up from Deep-sleep.
-----------------------------------
deep_sleep_set_option(1) The chip will carry out the RF calibration during waking up from Deepsleep.
Power consumption is high.
----------------------------------------
deep_sleep_set_option(2) The chip will not perform the RF calibration during waking up from
Deep-sleep. Power consumption is low.
-----------------------------
deep_sleep_set_option(4) The chip will not turn on the RF during waking up from Deep-sleep.
Power consumption is the lowest, same as in Modem-sleep.
--------------------------
На графике видно, время работы стандартного загрузчика 130 мс . Далее либо есть калибровка либо ее нет. Потом тот самый интервал 150 мс и далее передача по UDP.
Со стандартным загрузчиком и deep_sleep_set_option(2) общее время активности 320 мс.
Об этом написано в самом начале темы.
 
Последнее редактирование:

nikolz

Well-known member
upload_2017-10-17_11-55-30.png
пояснение.
первый импульс и далее через два импульса - это просыпание опрос датчиков запись в RTC и снова засыпание.
второй и третий импульс и далее такие же - это просыпание опрос датчиков запись в RTC и вызов основного приложения в котором осуществляется связь с сервером по WIFI протокол UDP и снова спать.
 

pvvx

Активный участник сообщества
В общем скучная картина. Когда дойдете до ОДНОЙ милли/микро секунды, то появится возможность начать сравнивать с RTL серии "B"...
Но сначала вам придется выкинуть датчик с таким разрешением шага измерения тока и напряжения.
INA219 не годится для замеров RTL.
К модулю, в питание, впаяно 1000 мкФ x 16В.
Пробуем на INA219 измерить опрос 4-х каналов ADC и промежуточный вывод в UART каждые 10 сек, без остановки SDK (пример вложен в базовый SDK)...
В шкале c миллисекундами в отображении dygraph.js (без усреднения) при приеме показаний с другой RTL c подключенной INA219 получаем живой график:
Imp_power.gif
Видим активность на отработку вывод значений в UART на 115200...
Если усреднить (rollPeriod: 100 для dygraph.js), и шкалу сделать в сек, то получаем:
Power.gif
Модуль в плате с отладчиком и дает несколько большие показания, т.к. измерено ранее, что в паузах до 700 мкA по документации с включенным непрерывно измеряющим ADC и если большую часть потрохов не глушить... Можно и менее, с отключением и лишних таймеров, и прерывистой работой ADC... Тогда и менее 200 мкА... Потом уже совсем в deep_sleep c активацией по пороговым уровням ADC... Короче скучно смотреть на ваши страдания с ESP8266...
 
Последнее редактирование:

nikolz

Well-known member
Вот новый тест производителя:
PDF: ESP8266 Low Power Test Demonstration
Посмотреть вложение 4857
http://download.espressif.com/FB/EvaKit/ESP8266_Low_Power_Test_EN.zip
А у вас почему-то больше даже с deep_sleep (!).
Все тесты разработчика я видел в момент их опубликования.
--------------------
C deep-sleep у меня ток ноль (ниже разрешения INA c шунтом 0.1 ом)
Графики отображаются с сжатием без потери экстремумов.
Если посмотрите внимательно на графики - ось время , то легко заметите что она не равномерная.
подряд идущие нули на ней заменяются первым и последним
 

nikolz

Well-known member
В общем скучная картина. Когда дойдете до ОДНОЙ милли/микро секунды, то появится возможность начать сравнивать с RTL серии "B"...
Но сначала вам придется выкинуть датчик с таким разрешением шага измерения тока и напряжения.
INA219 не годится для замеров RTL.
К модулю, в питание, впаяно 1000 мкФ x 16В.
Пробуем на INA219 измерить опрос 4-х каналов ADC и промежуточный вывод в UART каждые 10 сек, без остановки SDK (пример вложен в базовый SDK)...
В шкале c миллисекундами в отображении dygraph.js (без усреднения) при приеме показаний с другой RTL c подключенной INA219 получаем живой график:
Посмотреть вложение 4848
Видим активность на отработку вывод значений в UART на 115200...
Если усреднить (rollPeriod: 100 для dygraph.js), и шкалу сделать в сек, то получаем:
Посмотреть вложение 4849
Модуль в плате с отладчиком и дает несколько большие показания, т.к. измерено ранее, что в паузах до 700 мкA по документации с включенным непрерывно измеряющим ADC и если большую часть потрохов не глушить... Можно и менее, с отключением и лишних таймеров, и прерывистой работой ADC... Тогда и менее 200 мкА... Потом уже совсем в deep_sleep c активацией по пороговым уровням ADC... Короче скучно смотреть на ваши страдания с ESP8266...
Вы все пытаетесь доказать, что если дороже, то лучше.
Но это же главный прием маркетинга.
Поэтому это стереотип и с ним не спорят.
Но есть еще eSP32 пока ничяего сказать не могу да и Вы не можете.
Поэтому авто разные выпускаются. И если оно покупается то значит кого-то это устраивает.
 

nikolz

Well-known member
Это?
typedef enum _auth_mode {
AUTH_OPEN = 0,
AUTH_WEP = 1,
AUTH_WPA_PSK = 2,
AUTH_WPA2_PSK =3 ,
AUTH_WPA_WPA2_PSK =4 ,
AUTH_MAX = 5
} AUTH_MODE;
Спасибо.
Но это режимы AP, а у меня установлен режим станции и только.
-----------
Возможно знаете
чем вызваны данные задержки
после старта проходит от 17 до 40 мс до данного события
Но вне зависимости отмомента этого события проходит
150 мс до события EVENT_STAMODE_CONNECTED
Спасибо.
 
Последнее редактирование:

gerkimuyda

New member
Странно, что вы задаете такие вопросы. STAtion - это wifi-client в отличии от softAP. Т.е. клиент подстраивается под настройки АП (роутера) к которому он пытается подключится. АП говорит, что используется безопасность WPA2_PSK, на что модуль соглашается и переключает у себя режим в AUTH_WPA2_PSK.
А EVENT_STAMODE_CONNECTED - это происходит уже тогда, когда клиент с АПешкой договорились и связь установлена.
Т.е. - сначала идет запрос на подключение к АП, потом АП выдает какой режим безопасности надо пользоваться (возможны варианты по мак-адресу клиента), клиент передает логин/пароль, АП проверяет (логин, пароль, мак-адрес) и дает добро, готово = CONNECTED. На всю эту процедуру необходимо время, в зависимости от загруженности wifi, уровня сигнала, коллизий в эфире.
Если включен DHCP - то надо еще время для получения ИП-адреса и настроек, после чего будет событие EVENT_STAMODE_GOT_IP.
Кстати, у меня включен автоконнект (wifi_station_get_auto_connect()) на модуле и, возможно, поэтому события EVENT_STAMODE_AUTHMODE_CHANGE не происходит. Т.е. после EVENT_STAMODE_CONNECTED идет EVENT_STAMODE_GOT_IP. Но я в этом до конца не уверен, т.к. я использую wifi_set_opmode_current(WIFI_STA), вместо wifi_set_opmode(WIFI_STA)
---------
Но это режимы AP, а у меня установлен режим станции и только.
Но событие-то называется EVENT_STAMODE_AUTHMODE_CHANGE - т.е. для STAtion режима.
И не забывайте, что АПешка может иметь свой набор разрешенных нескольких режимов безопасности, а клиент - свой. И только находя общие режимы на обоих концах - они договариваются, каким одним режимом пользоваться. Т.е. клиенту без auth_mode тоже никак.
 
Последнее редактирование:

gerkimuyda

New member
Спорить не буду, т.к. предполагаю отсутствие у меня EVENT_STAMODE_AUTHMODE_CHANGE связано с station_auto_connect. Т.е. - или такого события у меня нет, или оно происходит еще раньше до получения контроля моим обработчиком. Также еще хотел напомнить, что клиент в процессе работы модуля может подключаться к разным АП с разными режимами безопасности. Т.е. все-таки наличие смены режимов у него есть.
(пс: у меня ESP8266_NONOS_SDK_V2.0.0_patch )

Т е ESP ничего роутеру до этого момента не передает.
Но переключение режима происходит,
Клиент ждет оповещения АПешки. Хотя-бы для того, чтобы знать на каком канале к ней обращаться...

зы: попробуйте без deep-sleep, а выключить wifi, а потом его включить - какие события происходят? тоже изменение режима безопасности - или нет?

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

gerkimuyda

New member
У меня dhcp и я за временем я не гонюсь, т.к. соединение держу постоянно включенным (у меня есп на 12вольтах висит, мне пару миллиампер не жалко). Поэтому такие эксперименты и замеры не проводил и данной темой не интересовался.
По поводу времени: какой вообще режим подключения у есп используется?
К примеру: если сделать полный цикл активного сканирования (перед подключением) с probe request, то это займет порядка 130мс
А если просто сидеть и слушать beacon пакеты на одном канале (посылаемые каждые 102,4мс. по умолчанию) - то 103мс.
Вот вам показатели времени для предположений... (на ваш вопрос "150 мс до готовности = это очевидно время прослушивания всего эфира для создания стека? или что-то другое?")
Т.е. имеем 103-130мс на ожидание и потом время на передачу-прием авторизации. (чуть глянул процесс подключения: клиент обменивается с АПешкой минимум двумя запросами:
WEP: Клиент делает запрос у точки доступа на аутентификацию, на что получает подтверждение, которое содержит 128 байт случайной информации. Станция шифрует полученные данные алгоритмом WEP (проводится побитовое сложение по модулю 2 данных сообщения с последовательностью ключа) и отправляет зашифрованный текст вместе с запросом на ассоциацию. Точка доступа расшифровывает текст и сравнивает с исходными данными. В случае совпадения отсылается подтверждение ассоциации, и клиент считается подключенным к сети.
 

nikolz

Well-known member
У меня dhcp и я за временем я не гонюсь, т.к. соединение держу постоянно включенным (у меня есп на 12вольтах висит, мне пару миллиампер не жалко). Поэтому такие эксперименты и замеры не проводил и данной темой не интересовался.
По поводу времени: какой вообще режим подключения у есп используется?
К примеру: если сделать полный цикл активного сканирования (перед подключением) с probe request, то это займет порядка 130мс
А если просто сидеть и слушать beacon пакеты на одном канале (посылаемые каждые 102,4мс. по умолчанию) - то 103мс.
Вот вам показатели времени для предположений... (на ваш вопрос "150 мс до готовности = это очевидно время прослушивания всего эфира для создания стека? или что-то другое?")
Т.е. имеем 103-130мс на ожидание и потом время на передачу-прием авторизации. (чуть глянул процесс подключения: клиент обменивается с АПешкой минимум двумя запросами:
WEP: Клиент делает запрос у точки доступа на аутентификацию, на что получает подтверждение, которое содержит 128 байт случайной информации. Станция шифрует полученные данные алгоритмом WEP (проводится побитовое сложение по модулю 2 данных сообщения с последовательностью ключа) и отправляет зашифрованный текст вместе с запросом на ассоциацию. Точка доступа расшифровывает текст и сравнивает с исходными данными. В случае совпадения отсылается подтверждение ассоциации, и клиент считается подключенным к сети.
Спасибо за инфу.
Но я сделал эту тему именно по вопросу энергосбережения.
Так как исследую вопрос применение автономного питания в том числе и альтернативных источников энергии в IOT.
И меня интересует минимизация затрат энергии в носимых, возимых и летающих устройствах управления и измерения.
 

pvvx

Активный участник сообщества
C deep-sleep у меня ток ноль (ниже разрешения INA c шунтом 0.1 ом)
Графики отображаются с сжатием без потери экстремумов.
Если посмотрите внимательно на графики - ось время , то легко заметите что она не равномерная.
подряд идущие нули на ней заменяются первым и последним
Считайте: 1 секунда потребления в 80 мА - это равно потреблению в 1 мА в течении 80 секунд.
У вас пауза меньше и общее потребление больше (за период).
Вы все пытаетесь доказать, что если дороже, то лучше.
Предлагаемое дешевле, если вы будете что-то делать, а не распевать песни. Причина проста - от производителя чип дешевле. Всегда можно найти любого продавца с надбавленной в сотни раз стоимости и сравнивать с ним :p

Т.е. - сначала идет запрос на подключение к АП, потом АП выдает
nikolz использует не стандартный вариант, а глюки своего роутера с AP. Нового соединения с AP он не делает, а использует старое, оборванное не по протоколу. Перед входом в deep_sleep он не делает отключения от AP роутера и не переключает режим работы ESP8266 для него в DTIM(n). Просто тупо выводит модуль в deep_sleep, затем просыпается и его роутер считает, что это время типа не было связи со станцией и никаких действий, предписанных в протоколе WiFi, не производит. Так-же в настройках роутера у него не стоит всяких циклических смен ключей сессий и прочего (т.е. требуются ещё всяческие извращения над настройками роутера)...
Т.е. сиё есть работа на глюке его роутера и его вопросы, типа почему там у него пауза с его роутером такая-то, известна только автору конкретной прошивке его роутера :)
Скорее всего, если он сделает паузу (deep_sleep) более n секунд, то и его роутер разорвет сеанс связи с не отвечающим ESP. По этому у него паузы (в deep_sleep) ограничены десятком секунд и сделать среднее потребление ниже простого LIGH sleep без нарушения протоколов WiFi он не может.

Вы же и я, описываем ему стандартную работу по спецификации WiFi, применимую с любым роутером.
 
Последнее редактирование:

nikolz

Well-known member
Считайте: 1 секунда потребления в 80 мА - это равно потреблению в 1 мА в течении 80 секунд.
У вас пауза меньше и общее потребление больше (за период).
Предлагаемое дешевле, если вы будете что-то делать, а не распевать песни. Причина проста - от производителя чип дешевле. Всегда можно найти любого продавца с надбавленной в сотни раз стоимости и сравнивать с ним :p


nikolz использует не стандартный вариант, а глюки своего роутера с AP. Нового соединения с AP он не делает, а использует старое, оборванное не по протоколу. Перед входом в deep_sleep он не делает отключения от AP роутера и не переключает режим работы ESP8266 для него в DTIM(n). Просто тупо выводит модуль в deep_sleep, затем просыпается и его роутер считает, что это время типа не было связи со станцией и никаких действий, предписанных в протоколе WiFi, не производит.
Т.е. сиё есть работа на глюке его роутера и его вопросы, типа почему там у него пауза с его роутером такая-то, известна только автору конкретной прошивке его роутера :)
Скорее всего, если он сделает паузу (deep_sleep) более n секунд, то и его роутер разорвет сеанс связи с не отвечающим ESP. По этому у него паузы (в deep_sleep) ограничены десятком секунд и сделать среднее потребление ниже простого LIGH sleep без нарушения протоколов WiFi он не может.
Суфлер не требуется.
Вы влезли в мою тему лишь для того чтобы выпедриваться.
Но все уже давно знают что пока вы не обосрете тех кто не облизывает вас вы не заткнетесь.
 

pvvx

Активный участник сообщества
Суфлер не требуется.
Вы влезли в мою тему лишь для того чтобы выпедриваться.
Ваша тема висела без ответов и форум - это не блог. Вы этого не объявили, что ответов и приветов сюда писать не надо и это будет вашим личным дневником. :)
Но все уже давно знают что пока вы не обосрете тех кто не облизывает вас вы не заткнетесь.
Вы сами всё "обосрете".
Я пока даю пояснения, что там у вас происходит, чтобы другие не путались. :p

Вас так задело, что у Espressif все замеры потребления сделаны “в изолированном бункере от внешних сигналов WiFi” при применении одного модуля ESP8266 и роутера не подключенного никуда + с определенными настройками, чтобы запросов к модулю со стороны сети не было?
Т.е. даны не реальные показания, а частный случай, не используемый на практике.

У вас ситуация аналогична и итоговые измерения можно смело кинуть в помойку. Достаточно сменить роутер и переместить всё это дело в обычную зашумленную по WiFi городскую среду со стандартными у пользователей функциями роутера.
--------
Разбирать и проверять технические характеристики чипа вы не можете, по причине недоступности функций в Espressif SDK для работы на низком уровне с оборудованием WiFi и прочих его потрохов, а так-же из-за отсутствия описания регистров управления ESP8266 чипа, что не дает возможностей написать свои функции и алгоритмы.

По этому, разбираем имеющиеся в Espressif SDK алгоритмы управления потреблением описанных в его API.

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

1) Deep-sleep c долгим просыпанием и установкой связи с AP по стандарту (от 3-х секунд активности при полном потреблении). Тут вы отказались установить минимально требуемую энергию в Дж для связи с AP и примера минимальной передачи-приема данных на удаленный внешний сервер.

2) LIGTH sleep для WiFi, дающий при частичных переходах в DTIM(10) 1.1 мА потребления, но общего долговременного среднего за 15 мА в реальной обстановке без использования специальных вариантов... Спец. варианты есть разные и они позволяют уменьшить общее потребление.

3) Отключение WiFi и переход в другие режимы sleep (не deep-sleep). Тут энергия повторного сеанса связи чуть менее чем после deep-sleep, т.к. не требуется загрузка и инициализация SDK и WiFi. Потребление в самом sleep вы так и не удосужились измерить.

Во всех вариантах пока спит ESP8266 пробуждение требует установки нового сеанса связи с AP.
Измерения времени и энергии в Дж на это не предоставлено, а говорите, что “меня интересует минимизация затрат энергии в носимых, возимых и летающих устройствах управления и измерения:)
Из режима deep-sleep ESP8266 пробуждается только по RESET с потерей времени и показания таймеров. В режиме других sleep из его API так-же имеем потерю точности хода часов и ограничения на условия просыпания - несколько GPIO и RC-таймер.
В режиме LIGTH sleep (DTIMx) и координации по TSF от AP можно восстановить время с большой точностью, но API ESP не предоставляет таких функций.

Все остальные реализации алгоритмов малого потребления, вписывающиеся в современные спецификации WiFi, требуют работы с чипом на уровне HAL и не реализованы на уровне API у ESP8266 Espressif, тем более на Arduino.

PS: Создавать уровень HAL (как и второй шаг - реализации на уровне API алгоритмов) устаревшему чипу с массой ограничений для поддержки нормальной функциональности в сфере автономных устройств никто из свободного люда не будет, т.к. уже есть достойные альтернативы среди WiFi-SoC с меньшей себестоимостью. Существует только один вариант - вынуждения производителя конкуренцией для поддержки продаж его чипа. Если вы предоставите доступный и известный прецендент на чипе другого производителя, то это может вынудить Espressif доделать П.О. к своему чипу. По этому я и не буду публиковать полных решений на RTL в открытый доступ - пусть живет какой есть ESP8266 :) А кому надо, тот всегда сможет сделать лучше, оперируя HAL на RTL или уже проторенными и описанными дорожками... :p
 
Последнее редактирование:
Сверху Снизу