Суфлер не требуется.
Вы влезли в мою тему лишь для того чтобы выпедриваться.
Ваша тема висела без ответов и форум - это не блог. Вы этого не объявили, что ответов и приветов сюда писать не надо и это будет вашим личным дневником.
Но все уже давно знают что пока вы не обосрете тех кто не облизывает вас вы не заткнетесь.
Вы сами всё "обосрете".
Я пока даю пояснения, что там у вас происходит, чтобы другие не путались.
Вас так задело, что у 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 или уже проторенными и описанными дорожками...
