Энергосбережение в устройствах с WIFI

[nikolz]

На Lau это не актуально - можете забыть и забить.
С режимом сна она не работает как надо. По времени соединения к внешней AP RTL87xx (с условием использования SDK) на два шага впереди (по времени и по потреблению за это время). Скорости передачи данных у них примерно одинаковы (1 мегабайт в сек).

У меня пока не RTL. Получу, буду изучать.
Но ESP на СИ меня устраивает, а LUA -это очень простой способ проверить алгоритмы, да и для умных домов, LUA - выше крыши, проще чем дурила а результат такой же( т е лампочка мигает, а температуру в унитазе видит весь мир на публичном сервере. Что еще надо чайнику?)

 

[pvvx]

По времени от включения после сна до возможности запуска WiFi при не китайском SDK, а с rapid-‘лоадером’, предел у ESPк 30..40 ms с потреблением сильно за 70 mA, т.к. нет возможности отключения вывода кракозяб в UART на кривой скорости из Boot-ROM. Цикл в 50 ms : 30 ms старт и 20 полный sleep с последующей загрузкой уже демонстрировал где-то... давно это было... У RTL беды с UART и отключениями вывода туда не наблюдаются. Скорость загрузки с flash у RTL около 16 мегабайт в сек (CLK CPU / 10 при SpicDualBitMode).
Стандартный китайский SDK и особенно их лоадеры или лоадеры для Arduino (!) не позволяют по просыпанию сразу перейти на измерение с датчика и если показания в диапазоне - сразу заснуть до следующей проверки. Про Lua и говорить нечего - там старт с жручкой (за 80 mA) более нескольких секунд, до выполнения первой команды Lua.

 

[nikolz]

По времени от включения после сна до возможности запуска WiFi при не китайском SDK, а с rapid-‘лоадером’, предел у ESPк 30..40 ms с потреблением сильно за 70 mA, т.к. нет возможности отключения вывода кракозяб в UART на кривой скорости из Boot-ROM. Цикл в 50 ms : 30 ms старт и 20 полный sleep с последующей загрузкой уже демонстрировал где-то... давно это было... У RTL беды с UART и отключениями вывода туда не наблюдаются. Скорость загрузки с flash у RTL около 16 мегабайт в сек (CLK CPU / 10 при SpicDualBitMode).
Стандартный китайский SDK и особенно их лоадеры или лоадеры для Arduino (!) не позволяют по просыпанию сразу перейти на измерение с датчика и если показания в диапазоне - сразу заснуть до следующей проверки. Про Lua и говорить нечего - там старт с жручкой (за 80 mA) более нескольких секунд, до выполнения первой команды Lua.

Я читал Ваши результаты. Спасибо.
Я собственно это знаю и меня это не смущает.
Пока использую ESP в основном без WIFI.
так как RTL сделали после ESP то по энергопотреблению вполне возможно лучше.
Но как говорится из песни слов не выкинешь, если передатчики в ESP и RTL имеют один и тот же КПД, то кушают они при одной и той же мошности излучения одинаково. Или в RTL кпд WIFI больше?

 

[pvvx]

так как RTL сделали после ESP то по энергопотреблению вполне возможно лучше.

Где-то лучше, где-то хуже. Чипы разные и у каждого свой подход. Зависит от программной реализации функций.
На ESP большая часть информации 'закрыта' или приведена реклама, не соответствующая реалиям. Пример - потребление дано без учета потребления внешней Flash микросхемой...
У RTL8710AF (по первым тестам) при повышении CPU CLK на 166MHz потребление больше, чем у ESP на 160MHz. Но тест делал без учета внутренней периферии - может там что тоже поднимается при переключении CLK и вызывает повышение потребления выше нормы...
У ESP передатчик не выключается от Reset и при перезагрузках, или при стартовой загрузке вызывает лишнее и не хилое дополнительное потребление, при этом работая на не правильной частоте и гоня шум в эфир. Ужасный баг чипа и сертификацию он не должен проходить.
ESP8266 работает при понижении питания до 1.71 В, RTL - только в нормативе от производителя - 10% 3.3В. При медленном подъеме (или опускании) питания срабатывает защелка на 2.1 В и чип не работоспособен (возможно, что плохо отрабатывает BOR).
Модуль RTL00 c RTL8710AF при CLK CPU 83MHz:

Данные из PADI IoT Stamp Resources – PINE64
Всё совпадает с реальными замерами, что не сказать о 'листках рекламы' от Espressif.

 

[pvvx]

В результате тестирования выяснилось следующее:
Время установления соединения по WIFI с компом должно составлять не менее 1 секунды.

Это чтобы батарейка села как можно быстрее "В результате тестирования NodeMCU" ?
Если уж пошли на UDP и Lua в NodeMCU (там объем передачи ограничен пару байтами в час ), то зачем вам вообще соединяться с внешней AP?
Формируйте пакет WiFi и передавайте в небо эти пару байт на выбранном канале, а приемной WiFi ловите. Гарантии у UDP всё равно нет, так тоже нет, но всё намного быстрее...

 

[nikolz]

Это чтобы батарейка села как можно быстрее "В результате тестирования NodeMCU" ?
Если уж пошли на UDP и Lua в NodeMCU (там объем передачи ограничен пару байтами в час ), то зачем вам вообще соединяться с внешней AP?
Формируйте пакет WiFi и передавайте в небо эти пару байт на выбранном канале, а приемной WiFi ловите. Гарантии у UDP всё равно нет, так тоже нет, но всё намного быстрее...

обнаружил что eSP после сна рассылает Broadcast


В результате посылка пакета задерживается на 1 секунду.
как от этого Broadcast a избавиться, кто знает?

 

[Victor]

как от этого Broadcast a избавиться

Скорее всего, ESP8266 как проснется, то активно сканирует WiFi.
Возможно, что это стандартный [inline]PROBE REQUEST[/inline] пакет - он нужен для того, чтобы доступные точки доступа ответили пакетом [inline]PROBE RESPONSE[/inline]. Есть альтернативный вариант, когда устройство ничего не сканирует, а получает информацию о доступных точках доступах из [inline]BEACON[/inline] пакетов. Но вся эта логика находится на втором MAC подуровне модели OSI всего семейства протоколов 802.11 и недоступна для управления напрямую из SDK - тут может помочь только замена библиотек на свои, как у @pvvx
Для более точного ответа нужен более глубокий парсинг пакета (далеко не все драйвера WiFi карт это позволяют, кстати)

 

[nikolz]

Скорее всего, ESP8266 как проснется, то активно сканирует WiFi.
Возможно, что это стандартный [inline]PROBE REQUEST[/inline] пакет - он нужен для того, чтобы доступные точки доступа ответили пакетом [inline]PROBE RESPONSE[/inline]. Есть альтернативный вариант, когда устройство ничего не сканирует, а получает информацию о доступных точках доступах из [inline]BEACON[/inline] пакетов. Но вся эта логика находится на втором MAC подуровне модели OSI всего семейства протоколов 802.11 и недоступна для управления напрямую из SDK - тут может помочь только замена библиотек на свои, как у @pvvx
Для более точного ответа нужен более глубокий парсинг пакета (далеко не все драйвера WiFi карт это позволяют, кстати)

В результате наблюдения за трафиком выяснил, что этими бродкастами ESP определяет IP станции и IP роутера.
Удалось уменьшить это время до 0.3 с.
Время на бродкаст удалось уменьшить путем явной записи конфигурации IP ESP.
Как прописать явно в NODEMCU конфигурацию роутера пока не нашел.
Резюме:
NODEMCU обеспечивает режим экономии энергопитания со следующими параметрами:
Минимальное время активности для передачи пакета по UDP с приемом ответа от компа через роутер в локальной сети составляет 0.3 секунды, средний ток при этом 65 ма.

 

[nikolz]

Всем привет!
Написал на СИ софтину включение ESP в различные режимы энергосбережения.
Режимы:
1(настройка WIFI при выходе из сна),
2(выход без настройки)
4(WIFI выключен).
--------------------------------
Результаты следующие:
минимальный интервал каждого режима разделен на участки постоянного потребляемого тока.
-----------------------------------------
Режим 4 ( 200 ms, средний ток 17.5 ma) 3 участка
1) I=16 ma(30 ms)
2) I=26 ma(70 ms)
3) I=12 ma(100 ms)
=============================================
Режим 1 ( 360 ms, средний ток 69.5 ma) 6 участков
1) 4.1
2) 4.2
3) I=120 ma +140 ma( скважность 2 ) (60 ms)
4) I=55 ma(20 ms)
5) I=220 ma(2 ms)
6) I=55 ma(178 ms)
=============================================
Режим 2 ( 300 ms, средний ток 40.5 ma) 5 участков
1) 4.1
2) 4.2
3) 1.4
4) 1.5
5) I=55ms(78 ms)
------------------------------------------

 

[pvvx]

обнаружил что eSP после сна рассылает Broadcast

DHCP, MDNS?

 

[nikolz]

DHCP, MDNS?

 

[pvvx]

Посмотреть вложение 2379

DHCPDISCOVER - запрос "Хто там?", "я типа DHCP с MAC:...."
Не знали, что DHCP в прошивке есть?

 

[nikolz]

DHCPDISCOVER - запрос "Хто там?", "я типа DHCP с MAC:...."
Не знали, что DHCP в прошивке есть?

На Си я вижу, что он подключается, на луа его не видно.
Но на луа еще и мултикаст врубается по адресу 224.0.0.1. Во как!
Не знаете как бы это все вырубить.
-----------------------------------------
Иначе , кроме времени включения при старте, которое ,не как Вы писали - составляет 50 ms, а реально , как я написал выше от 200 до 360 ms, к нему добавляется время подключения к роутеру и обмен пакетами - это еще 150 ms.
Получается, что начальная загрузка, та которую Вы уменьшали с 50 до 20, не делает никакой погоды в реальной работе модуля.
--------------------------------
Резюме:
Для реального модуля с режимом sleep следует брать минимальное время активности 400 ms при среднем токе 18 ma (без WIFI) и от 40 до 70 с WIFI.

 

[pvvx]

На Си я вижу, что он подключается, на луа его не видно.

Он в либе c Lwip.

Получается, что начальная загрузка, та которую Вы уменьшали с 50 до 20, не делает никакой погоды в реальной работе модуля.

Это в Lua всё совсем безразлично А у других как раз эти ms погоду делают. При просыпании и опросе датчика. Зачем каждый раз модулю выходить на связь? Как можно смотреть графики с выпадающими точками снятых и не отфильтрованных замеров? Ну и т.д.
Главное, что в Lua вы можете переключить что-либо, только дождавшись полной загрузки SDK и инициализации WiFi при потреблении от 70 mA и более (до 200) в течении первой секунды. А тут уже через 30 ms возможна коррекция - полное отключение WiFi и прочих неиспользуемого оборудования с понижением потребления к 15 mA или чуть более, если проц переключить на 160 MHz для ускорения решения задачи "просыпания", что тоже дает экономию по общей картине питания.
Самый эталонный пример - питание от солнечной батареи. Модуль проснулся и выяснил, что Солнышка не было и быстро включил максимальное время до следующего "просыпания". В вашем случае - всё - крах, батарея выжрана загрузкой Lua и всё скончалось на много-секундной инициализации spiffs...

 

[pvvx]

Ну Вы опять не прочитали внимательно.
Я же написал, что сейчас я делаю все на СИ. И данные такие же как на луа.
Т е 450 ms при обмене пакетами и от 200 до 360 ms без обмена, просто инит и в колбеке таймера переводим в сон.
Никаких 30 ms и близко нет.

Там предел в том, что заряженная емкость в 4700 мкФ в питании на 3.3В у вас не хватает для работы (принятия решения процом что делать). А что-то более - это большая цена или превышает габариты самого модуля...

Я же написал вот замеры:
Написал на СИ софтину включение ESP в различные режимы энергосбережения.
Режимы:
1(настройка WIFI при выходе из сна),
2(выход без настройки)
4(WIFI выключен).
--------------------------------
Результаты следующие:

А вам на это ответил - deep_sleep лучшее лекарство от выедания батареи.
Rapid_Loader/ESP-01-StartSignals.gif at master · pvvx/Rapid_Loader · GitHub
Есть ещё "финт ушами" - тогда время старта до своего кода сокращается менее 30 ms за счет ошибки в ROM-BIOS (она даже ничего не выводит в UART!). Но он требует не трогать чип-селект и не снимать питания с проца (нужна загруженная до этого память - RAM).
PS: По большому счету ESP8266 уже умер. Его полностью победил младший RTL87xx...

 

[pvvx]

Вы не все изучили.

?
До того, ка заставить ROM-ВIOS выводить на один символ меньше при старте, т.к. это ms тупого ожидания в цикле конца вывода в UART с полной жручкой CPU ROM-BIOS-a написанного тупыми китайцами...

Там есть три участка работы процессора

Больше. Пик потребления за 80 mA при очистке RAM.
Так-же вы многое не учли. Стандартный загрузчик, из ROM-BIOS, загружает с flash на низкой частоте CPU и самом медленном режиме работы SPI. В итоге загрузка лишних пары байт первого участка (бутлоадера) из Flash сжирает к сотне ms у китайцев (это наверно ваши 70). Rapid-loder для того и сделан - он всего сотню байт и дальше грузит всё остальное (15..30 кило) за время быстрее, чем грузил его (эти сотню байт) ROM-BIOS.
Во вторых ROM-BIOS грузит всего один сегмент и пишет одну надпись... Там ещё в третьих и ... но ESP уже умер.
Если хотите решить вопрос - берете емкость (электролит) и находите минимальное значение емкости, с которой запустится CPU и к пример до переключения какого порта и заснет снова. Расчет может сделать сами - параметры: напряжение заряженной емкости пусть 3.5В - далее разряд процом до 1.75В. В этих пределах ESP благополучно живет и должен успеть сделать задуманное...

 

[pvvx]

Т е Вы согласны с моими измерениями?
Ваши 20 или 50 ms - это абстрактный интервал, который реально бесполезен.
Но никаких 80 ма в приведенном мною режиме не существует.

Плохо смотрели.
У ESP только CPU жрет к 70 mA, если не простаивает на спец. команде в распределителе процессов в ROM-BIOS.
И скорее всего измеряли неверно - не учли утечки, вплоть до полной запитки модуля от входов-выходов UART и т.д. включенных к внешним устройствам со своим питанием и не согласованным для данного замера.
Для точности вам дана методика - заряжаете емкость и вперед - сколько Lua на ней исполниться

Вы опять впали в депрессию и в этом виноваты китайцы ( а почему не пендосы?) Наши патриоты обычно их ругают, а Вы все китайцев.
А RTL не напомните, кто сделал?
Опять китайцы?
Надо же!

Тут есть разница. ESP писали бестолковые китайцы, испортили неплохую разработку железа, а RTL писали уже обученные...

 

[pvvx]

Измерил я правильно, так как мерил ток потребления модуля на землю.
Все утечки идут на землю. (или есть сомнения?)

Без сомнения идут. Это на + может быть меньше, т.к. там возможен толерант к +5В (но плохо реализован в ESP).

70 ма это при включенном приемнике WIFI, а без него 12-15 ma .

Припаяйте ещё фараду к модулю и включите его на 1 сек, а потом меряйте
На разных модулях стоят разные номиналы емкостий и ESR у них разный. Всё это зависит от источника питания. Если он прецизионный, то будет и 1A пики на заряд емкостей модуля
Если 15 mA - CPU стоит 99% на команде ожидания прерывания. Некий sleep. Какой смысл тогда вообще в данном CPU? - кормить бездельника?
Вы же знаете, что все графики по основным командам уже приводил, но вынудить и сюда их всех свалить не выйдет

Но собственно,я знаю все, что Вы скажите про китайцев. За два года Вы уже все оних сказали и теперь лишь повторяете свое мнение.
Т е ничего нового Вы мне не скажите.

А и не выудите. И что с ними поделать, если у них школа программирования только формируется?

 

[pvvx]

Зачем мне паять фараду, когда у меня батарейка на 3.6 вольта включена а USB отключена.

Как-же вы отследили где и какой "участок" без мониторинга хоть символов в порту ?
Может квац кривой и плохо заводиться - значит первый участок до вывода первого символа полностью зависит от погоды (точнее от температуры) и какой стоит счетчик до стабилизации (тиков) генератора и какая опция ему дана, далее, как выскочили регистры у WiFi блока, включен он вообще или нет - тоже зависит от погоды у ESP, т.к. брак - не завязан с RESET ...
В общем задача вам по вашей же теме объяснена и предельно понятна:
Все остальные режимы работы модуля после инициализации и т.д. полностью зависят от задачи поставленной модулю и всегда имеются возможности изменить алгоритм в этих процессах.
Но "холодный" (и после deep_sleep, но там есть различия) старт - загрузка и инициализация ПО модуля есть всегда в любой разработке и чем меньше он, тем лучше.
По этому ваши выкрутасы - "я чё-то там померял, как мне захотелось" не интересны. Хороша ложка к обеду, но обед уже закончился. Занятия некромансией (или некромантией) с умирающим ESP8266 уже не актуальны... Там произошел переход в сегмент “обслуживания” – каждый держатель большого пакета встроил ESP8266 в свою систему и предлагает услуги для начинающих... Остались одни потребители полностью готового "продукта". Что либо менять в данных "продуктах" и вы уже не будете.

Что Вы х...ю пишите. Опытный Вы Наш.

А я не опытный. Мне это не требуется.

 

[nikolz]

Как-же вы отследили где и какой "участок" без мониторинга хоть символов в порту ?
Может квац кривой и плохо заводиться - значит первый участок до вывода первого символа полностью зависит от погоды (точнее от температуры) и какой стоит счетчик до стабилизации (тиков) генератора и какая опция ему дана, далее, как выскочили регистры у WiFi блока, включен он вообще или нет - тоже зависит от погоды у ESP, т.к. брак - не завязан с RESET ...
В общем задача вам по вашей же теме объяснена и предельно понятна:
Все остальные режимы работы модуля после инициализации и т.д. полностью зависят от задачи поставленной модулю и всегда имеются возможности изменить алгоритм в этих процессах.
Но "холодный" (и после deep_sleep, но там есть различия) старт - загрузка и инициализация ПО модуля есть всегда в любой разработке и чем меньше он, тем лучше.
По этому ваши выкрутасы - "я чё-то там померял, как мне захотелось" не интересны. Хороша ложка к обеду, но обед уже закончился. Занятия некромансией (или некромантией) с умирающим ESP8266 уже не актуальны... Там произошел переход в сегмент “обслуживания” – каждый держатель большого пакета встроил ESP8266 в свою систему и предлагает услуги для начинающих... Остались одни потребители полностью готового "продукта". Что либо менять в данных "продуктах" и вы уже не будете.
А я не опытный. Мне это не требуется.

Объясняю, как я отслеживаю участки.
Подключаю осциллограф.
Программа работает в цикле. Устанавливаю время сна минимальное 20 мс. делаю на осциллографе внешнюю синхронизацию.
В период сна -ток, а следовательно и напряжение от него практически ноль.
В момент просыпания появляется фронт начала работы. От него синхронезируемся. Устанавливаем развертку 50 мс в см.
Наблюдаем все интервалы, которые я указал выше. По осциллографу измеряем напряжение на интервалах.
По закону ома определяем потребляемый ток.