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

[pvvx]

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

Именно про это и написал – поставьте другие каналы осциллографа на TX с синхронной декодеровкой символов, и на прочие выходы... Тогда и будет примерно ясно, что происходит в какой части и где эта часть.

У дешевых псевдо-осциллографов слишком мал динамический диапазон для точных замеров питания (8 бит на диапазоне до 10 MHz - это ныне не осциллограф, а игрушка).

У нас максимум 250 мА и минимум в 2..10 мкА. Если взять нормальный осциллограф, то на указанном диапазоне там обычно всего 14 бит, что тоже не хватает для точного вычисления за период замеров динамически использующих разные sleep режимы...

 

[pvvx]

синхронизировал осциллограф от RST
В режиме с отключенным WI-FI получился следующий график потребляемого тока:
Посмотреть вложение 2424
Y -ток ma, X - время в ms от сигнала RST .
----------------------------------------------------------------
Применение rapid_loader не влияет на данный режим работы.

Если не умеете пользоваться - то при чем тут софт и 'лоадеры'?
Научитесь описывать все исходные условия и параметры замера с предоставлением исходников и прочих материалов (описания), для возможности повтора замера другим.
А то опять - нарисовали загогулину при неизвестных условиях.
Это наверно график солнечной активности в каком-то кратере на обратной стороне Луны за прошедший вторник?
Хотя-бы дали-бы примерное описание, как тут, по стадиям с исходниками:
SDKnoWiFi/Power_SdkNoWiFi.gif at master · pvvx/SDKnoWiFi · GitHub
Это замер примерно* по исходнику SDKnoWiFi/user_main.c at master · pvvx/SDKnoWiFi · GitHub
(примерно*) по причине что что-то там изменил, а картинка старая... но большая часть подписана - могут измениться только периоды...
----------
Так-же не забываем, что для входа в полный контролируемый deep_sleep у ESP8266 необходимо:

1) Вычислить и установить дельту частоты внутреннего RC генератора для RTC при текущей температуре и питании (на это уходит много времени)

2) Отключить flash (дать и ей команду sleep), что тоже требует времени на передачу этой команды по SPI с ожиданием вывода...

3) Отключить все внутренние потроха (WiFi, таймеры и прочее)

Если применялся какой-то из глубоких режимов sleep (на ходу или с перезагрузкой), то по выходу из него требуется полная инициализация всего, включая PLL и прочих контроллеров. А это тоже не быстрый процесс…

Из этого выходит, что использование глубоких режимов сна имеет смысл только на большие периоды.

 

[nikolz]

Итак, исследования энергопотребления заканчиваю.
Выкладываю последний график потребления для режима передачи пакета и приема ответа по протоколу uDP.
Полученный график потребления полностью соответствует временным интервалам полученным в программе.

Полагаю, что на этом графике все наглядно видно.
Начало оси времени соответствует сигналу WAKEUP, который приходит на RSP с GPIO16.
Минимальное время обмена пакетами по UDP составляет 430 ms.
Это время не зависит от языка написания программы что на СИ, что на LUA.

 

[pvvx]

Итак, исследования энергопотребления заканчиваю.

Очень хорошо, т.к. никакого смысла пока не дает.

Полагаю, что на этом графике все наглядно видно.

Наглядно для кого? Другим ваши условия замера неизвестны.

Минимальное время обмена пакетами по UDP составляет 430 ms.
Это время не зависит от языка написания программы что на СИ, что на LUA.

Т.е. можно вообще ничего не писать в Flash? Это замер обмена по UDP у ESP8266 с пустой flash?

 

[nikolz]

Если не умеете пользоваться - то при чем тут софт и 'лоадеры'?
Научитесь описывать все исходные условия и параметры замера с предоставлением исходников и прочих материалов (описания), для возможности повтора замера другим.
А то опять - нарисовали загогулину при неизвестных условиях.
Это наверно график солнечной активности в каком-то кратере на обратной стороне Луны за прошедший вторник?
Хотя-бы дали-бы примерное описание, как тут, по стадиям с исходниками:
SDKnoWiFi/Power_SdkNoWiFi.gif at master · pvvx/SDKnoWiFi · GitHub
Это замер примерно* по исходнику SDKnoWiFi/user_main.c at master · pvvx/SDKnoWiFi · GitHub
(примерно*) по причине что что-то там изменил, а картинка старая... но большая часть подписана - могут измениться только периоды...
----------
Так-же не забываем, что для входа в полный контролируемый deep_sleep у ESP8266 необходимо:

1) Вычислить и установить дельту частоты внутреннего RC генератора для RTC при текущей температуре и питании (на это уходит много времени)

2) Отключить flash (дать и ей команду sleep), что тоже требует времени на передачу этой команды по SPI с ожиданием вывода...

3) Отключить все внутренние потроха (WiFi, таймеры и прочее)

Если применялся какой-то из глубоких режимов sleep (на ходу или с перезагрузкой), то по выходу из него требуется полная инициализация всего, включая PLL и прочих контроллеров. А это тоже не быстрый процесс…

Из этого выходит, что использование глубоких режимов сна имеет смысл только на большие периоды.

А Вы можете просто спросить то, что Вам надо? Без назидательного тона.
Я уже отвечал, что выкладываю то, что хочу. я никому ничего не обязан.
Если Вас что-то интересует -спросите вежливо.

 

[nikolz]

Очень хорошо, т.к. никакого смысла пока не дает.
Наглядно для кого? Другим ваши условия замера неизвестны.
Т.е. можно вообще ничего не писать в Flash? Это замер обмена по UDP у ESP8266 с пустой flash?

вам делать нечего?
Вам конкретно непонятно?
что именно?

 

[nikolz]

 

[nikolz]

Теперь можно сравнить энерго эффективность протокола UDP и ESP-NOW.
Для передачи одного короткого сообщения,
а именно такими сообщениями и обмениваются устройства в умном доме,
требуется по UDP примерно 32 ma*s, а для протокола ESP-NOW 16 ma*s, т е в два раза меньше.
Это более скромный результат, чем приведенный в начале темы результат китайского товарища.
---------------------------------------------------
Теперь давайте прикинем на какое время хватит батарейки.
Я например сейчас использую 3.6 v емкость не менее 280 mah.
Максимальное число сообщений без подзаряда составит 3600*280/16=63000 сообщений.
Если будем передавать 1 сообщение в час, то на 7 лет.
Если будем передавать 1 сообщение в минуту, то на 43 дня.
-------------------------------
Примерно так

 

[Сергей_Ф]

@nikolz а при использовании двух мизинчивых батареек типа ААА, получится примерно 3600*1000/32 =112000 сообщений при UDP или 13 лет и 80, дней соответственно.
При ESP-NOW в два раза больше.
Получается что при 1 сообщении в час батарейки и аккумулятор раньше сдохнут от саморазряда, потому смысла выбирать протокол нет.
При 1 сообщении в минуту - уже актуально. Интересно проверить практически, и подобрать/рассчитать максимальную частоту посылки сообщений и для разных источников исходя из работы в течении года без смены батарей.

 

[nikolz]

@nikolz а при использовании двух мизинчивых батареек типа ААА, получится примерно 3600*1000/32 =112000 сообщений при UDP или 13 лет и 80, дней соответственно.
При ESP-NOW в два раза больше.
Получается что при 1 сообщении в час батарейки и аккумулятор раньше сдохнут от саморазряда, потому смысла выбирать протокол нет.
При 1 сообщении в минуту - уже актуально. Интересно проверить практически, и подобрать/рассчитать максимальную частоту посылки сообщений и для разных источников исходя из работы в течении года без смены батарей.

Согласен.
--------------------
меня сейчас интересует возможность уменьшить интервал активности, так как по результатам замера активность WIFI много меньше.
Например, ответ от компа ( UDP с подтверждением) приходит не позднее 10 ms (это квант ВИНДЫ) после отправки пакета, а ESP переходит в сон через 100 ms.
Т е зачем то сидит активным еще 90 ms.
--------------------------------------------------------
Вообще-то 340 ms активности слишком много. Пока копаю в направлении уменьшения этого времени.

 

[pvvx]

Т е зачем то сидит активным еще 90 ms.

Это скорее всего калибровка RTC и выключение периферии.
Меняйте порядок вызова калибровки RTC или используйте фиксированные табличные значения для разной температуры и напряжения питания, полученные заранее.
И 10 ms ping в местной сети - это очень много. Что-то не то.

 

[nikolz]

Это скорее всего калибровка RTC и выключение периферии.
Меняйте порядок вызова калибровки RTC или используйте фиксированные табличные значения для разной температуры и напряжения питания, полученные заранее.

Можете дать пример кода?
Спасибо.

И 10 ms ping в местной сети - это очень много. Что-то не то.

10 ms - это не пинг. Пакет от eSP на комп приходит за 200 мкс.
Это квант ОС windows (многзадачность, СЭР!).

 

[pvvx]

Можете дать пример кода?

Тут не пример, а надо убивать китайцев
При вызове deep_sleep ставиться задержка на 100 ms -> esp8266web/user_interface.c at master · pvvx/esp8266web · GitHub
Т.е. переписывать закрытые функции SDK. Это вам не RTL - там такой уровень открыт.

10 ms - это не пинг. Пакет от eSP на комп приходит за 200 мкс.
Это квант ОС windows (многзадачность, СЭР!).

При чем тут квант? Это программа у вас кривая и не работает по событиям приема пакета. Представьте себе сервер с ответами через ваши кванты Его завалит DDS-ом один комп...
Распределение по приоритетам с вызовом от драйвера не квантуется, а исполняется по мере поступления вызова и отработки задач с более высокими приоритетами...
Это только в Lua можно построить опрос приема пакета для ответа на низшем уровне приоритетов исполнения с квантованием задачи опроса операционной системой По другому там никак По причине отсутствия многозадачности в Lua. Там псевдо многозадачность и совершенно убогая, что даже не назвать многопоточностью. Народ с этим мучается в Lua и выдумывает всякие извращения

 

[nikolz]

При вызове deep_sleep ставиться задержка на 100 ms -> esp8266web/user_interface.c at master · pvvx/esp8266web · GitHub
Т.е. переписывать закрытые функции SDK.

Спасибо за ссылку, будем смотреть.
Но никак не въеду в следующее. Если При вызове deep_sleep ставиться задержка на 100 ms то почему ее нельзя изменить на 10? Это же какой нибудь из таймеров, меняем его квант.
---------------------------------
Я так делаю на винде, чтобы время реакции на событие уменьшить с 10 до 1ms, если надо.

При чем тут квант? Это программа у вас кривая и не работает по событиям приема пакета. Представьте себе сервер с ответами через ваши кванты Его завалит DDS-ом один комп...
Распределение по приоритетам с вызовом от драйвера не квантуется, а исполняется по мере поступления вызова и отработки задач с более высокими приоритетами...
Это только в Lua можно построить опрос приема пакета для ответа на низшем уровне приоритетов исполнения с квантованием задачи опроса операционной системой По другому там никак По причине отсутствия многозадачности в Lua. Там псевдо многозадачность и совершенно убогая, что даже не назвать многопоточностью. Народ с этим мучается в Lua и выдумывает всякие извращения

Ну Ваши эмоциональные рекомендации как всегда радикальны и потому практически бесполезны.

 

[nikolz]

Последние результаты работы ESP в режиме deep-sleep и короткими пакетами с сервером через роутер.
------------------------------------
На сервере стоит прогрмма на луа, которая принимает с ESP строку текста в виде НомерПакета;ESP_test и отсылает эту строку обратно ESP. ESP принимает эту строку и переходит в сон. при просыпании через 1 секунду устанавливает связь с роутером и посылает пакет серверу. Если сервер не работает, то ESP посылает три раза пакет и идет спать.
-----------------------------
Сервер принимая пакеты печатает время между пакетами и принятую строку в виде:
1.391;154;ESP_test
1.391;155;ESP_test
1.391;156;ESP_test
1.391;157;ESP_test
1.391;158;ESP_test
В итоге, время активности ESP составляет 391 мс.
Хочу заметить,
что я ничего не ломал в SDK ,
а использую лишь официально описанные функции SDK.
и все работает стабильно без зависаний.
Чего и Всем желаю.

 

[pvvx]

Спасибо за ссылку, будем смотреть.
Но никак не въеду в следующее. Если При вызове deep_sleep ставиться задержка на 100 ms то почему ее нельзя изменить на 10? Это же какой нибудь из таймеров, меняем его квант.

Нельзя ничего изменить, если не патчить SDK.
Задержка стоит для ожидания отработки (точнее обрыва на обум) посылок отключения сетевых сервисов и WiFi. Обрывать просто так связь в стандарте не принято. Так-же существуют нормативы для выхода на связь устройства WiFi и кол-ва посылок всяких Probe Request перед соединением и их интервалов. Можно это всё нарушить, но тогда это уже не стандартный WiFi, а какой-то самопальный приемо-передатчик работающий в диапазоне WiFi. ESP8266 таким и является.
В SDK RTL-ов удалось найти и поправить на предел скорость отключения WiFi без нарушения протокола. Там драйвер ждет завершения всех транзакций, если они ещё не завершены:

Deinitializing WIFI ...
[rltk_wlan_deinit] Wait for RxStop

При связи с роутерами отключение WiFi теперь происходит от 1 ms (один тик RTOS) до нескольких десятков, т.к. ожидает завершения транзакций.

В RTL-ах, на сейчас, пока не добавил возможности отключения и ограничения посылок Probe Request при включении WiFi. Т.к. не знаю, может, стоит подождать официальной адаптации SDK для энерго-эффективных устройств – у них это быстрее и лучше происходит, чем вписывать свои “патчи”. Сейчас там не всё в порядке и при старте посылается от 8-ми до 16-ти Probe Request и на это уходит время и батарейка…
Время выхода в deep_sleep в RTL находится в открытой части SDK и запросто меняется на пару us.

 

[nikolz]

Нельзя ничего изменить, если не патчить SDK.
Задержка стоит для ожидания отработки (точнее обрыва на обум) посылок отключения сетевых сервисов и WiFi. Обрывать просто так связь в стандарте не принято. Так-же существуют нормативы для выхода на связь устройства WiFi и кол-ва посылок всяких Probe Request перед соединением и их интервалов. Можно это всё нарушить, но тогда это уже не стандартный WiFi, а какой-то самопальный приемо-передатчик работающий в диапазоне WiFi. ESP8266 таким и является.
В SDK RTL-ов удалось найти и поправить на предел скорость отключения WiFi без нарушения протокола. Там драйвер ждет завершения всех транзакций, если они ещё не завершены:

Deinitializing WIFI ...
[rltk_wlan_deinit] Wait for RxStop

При связи с роутерами отключение WiFi теперь происходит от 1 ms до нескольких десятков, т.к. ожидает завершения транзакций.

Меня интересует не стандартный протокол, а нечто подобие протокола NRF.
Во внутренних сетях, таких как умные дома нет надобности поддерживать пакетные протоколы.
А выигрыш в энергопотреблении огромный. Поэтому я хочу сделать внутреннюю сеть,
которая при надобности через стек TCP/UDP выходит на стандартную сеть.
Сеть умных домов - это сеть коротких пакетов реального времени (это моя концепция таких сетей).
Сейчас у меня трафик обмена по UDP составоит из трех посылок
Первая посылка - самая дурная -это broadcast ARP ESP собственного MAC.
Возможно кто-то знает как прописать МАС ESP в его ARP таблицу, чтобы он не посылал в пустоту этот запрос.
На этот запрос уходит 10 ms.
Потом идет посылка пакета от esP к компу на это уходит 80 мкс
Потом идет ответ компа к ESP на это уходит 130 мкс.
В результате полезная работа WI-FI составляет 0.21 ms,
А весь интервал активности составляет аж 390 ms.
------------------------------
Полагаю, что использование стандартных стеков не сильно уменьшит время активности обмена в новых чипах.

 

[pvvx]

Меня интересует не стандартный протокол, а нечто подобие протокола NRF.

Это не всегда годится, т.к. часто требуется связь со стандартными WiFi устройствами. В таких случаях и возьмите NRF.
У пользователя обычно есть web броузер, грузить всякие сторонние ПО ныне опасно, а соединения по UDP браузеры не поддерживают, кроме сложного специализированного протокола, на который ещё нет общей схемы javascript для всего разнообразия устройств...

Первая посылка - самая дурная -это broadcast ARP ESP собственного MAC.
Возможно кто-то знает как прописать МАС ESP в его ARP таблицу, чтобы он не посылал в пустоту этот запрос.

А смысл? Если используете DHCP то это его запрос... Не используйте DHCP.

 

[nikolz]

Это не всегда годится, т.к. часто требуется связь со стандартными устройствами. В таких случаях и возьмите NRF.
У пользователя обычно есть web броузер, грузить всякие сторонние ПО ныне опасно, а соединения по UDP браузеры не поддерживают, кроме сложного специализированного протокола, на который ещё нет общей схемы javascript для всего разнообразия устройств...
А смысл? Если используете DHCP то это его запрос... Не используйте DHCP.

Я не использую DHCP, так как пишу статический адрес IP.
Но ESP посылает пустой, вернее сказать Gratuitous ARP для самого себя.
----------------------------------
Относительно NRF.
я их получил недавно по цене 30 центов и сейчас буду издеваться над ними,
на основе nRF делаю совсем маленький модуль,
который способен годами ничего не кушать.
ESP или что-то другое (скоро придут и RTL и CC) буду использовать как узлы mesh.
----------------------------------
Следующим этапом буду уродовать SDK,
чтобы уменьшить 390 ms ,
хотя бы раз в 5 или 10.
-----------------------------

 

[pvvx]

Вообще не понятно, каким образом, без выделения каналов, ресурсов на AP, схемы связи и прочего вы пытаетесь соединиться с внешней AP? Через грубый хак, работающий только на ваших устройствах?

У меня вообще не требуется никакого времени при периодической связи через несколько beacon периодов (у вас указанно - в 1 сек, можно и больше), с некоторыми WiFi свистками. Для них связь типа не разрывалась и аутентификация отключена. Соединились с AP по стандарту и засыпаете, просыпаетесь и продолжаете сессию… Но это не всегда работает, т.к. надо синхронизироваться и использовать тупой неполноценной WiFi-свисток.
При множественных устройствах такая схема не годиться - будет много коллизий. А как раз для множества устройств вы и делаете...