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

[nikolz]

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

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

Нет у меня все стандартно.
стоит роутер TP-Link к нему по сети (кабелю 0 подключены через свич компы) ESP соединяется с роутером по wI-FI все как обычно. так же по WI-FI подключены телевизоры и нотбук. Программа сервера на компе который через кабель .
Если интересно могу показать пакеты.
У меня в eSP реализована настройка и подключение по WI-FI которая используется при запуске и в случае потери связи.
При просыпании настройки нет, так как я запоминаю все настройки от предыдущей активности.
Единственно что вылезает каждый раз это этот бессмысленный ARP.
Время на пакеты я смотрю в пакетах.

 

[nikolz]

сейчас попробовал Ваш рапид загрузчик.
ESP просыпается и засыпает но WI-FI перестал работать.

 

[nikolz]

Что еще заметил, что от момента начала работы программы до момента посылки пакета проходит 150 ms.

 

[pvvx]

сейчас попробовал Ваш рапид загрузчик.
ESP просыпается и засыпает но WI-FI перестал работать.

А он его отключает на время загрузки для уменьшения потребления. Нет никакого смысла его держать включенным, т.к. частоты в PLL при перезагрузке через RESET не те . Ваш вариант программы не включает WiFi - по этому он и отключен.

Что еще заметил, что от момента начала работы программы до момента посылки пакета проходит 150 ms.

И на что это время уходит? И сколько времени стартует кварц при тестируемой температуре до срабатывания счетчика в чипе, что кварц стабилен и можно стартовать?
Время настройки PLL, т.е. выхода на стабильность после смены у ESP8266 достаточно долгая... а оно переключается несколько раз, т.к. в ROM-BIOS расчет идет на другую частоту кварца... Подстройка, расчет периода таков RTC генератора организованного на RC цепи в чипе, тоже требует времени - оно используется для задания времени нахождения в deep_slеep и сильно зависит от температуры и напряжения питания чипа... В ESP нет возможности сделать калибровку RTC вторым тредом, во время исполнения другой части ПО. Но, если сильно захотеть и иметь разобранную часть этого закрытого в SDK куска, то вроде прерывание от RTC работает, а счетчик тактов всегда есть.

 

[nikolz]

А он его отключает на время загрузки для уменьшения потребления. Ваш вариант программы не включает WiFi - по этому он и отключен.

Я использую 2 режим deep-sleep и
wifi_set_opmode(STATION_MODE).
а также проверку режима wi-fi и его включение если он ноль.
Надо eще какие-то специальные команды

 

[pvvx]

Я использую 2 режим deep-sleep и
wifi_set_opmode(STATION_MODE).
а также проверку режима wi-fi и его включение если он ноль.
Надо eще какие-то специальные команды

Надо выкинуть и переписать большую часть SDK - тогда и получите указанные мной ранее 50 ms в периоде с засыпанием и просыпанием по deep_sleep (т.е. через GPIO16 с проводком на RESET).
Т.ч. вам ещё долго - у вас пока за 350 ms
Придется учесть всё:
// ROM-BIOS запускает код с адреса 0x40100000
// при опциях перезагрузки 'Jump Boot', если:
// GPIO0 = "0", GPIO1 = "1", GPIO2 = "0" (boot mode2,x))
Т.е. после первой загрузки устанавливаете GPIO в соответствии и грузиться с flash он не будет, на чем сэкономите ещё...
esp8266web/app_main.c at master · pvvx/esp8266web · GitHub

А в итоге, вы просто повторите режим sleep: LIGHT для WiFi (а он есть во всех SDK на все чипы). Там просыпание быстрее ещё быстрее (каждый beacon) и только настройка PLL, вроде 2 ms всего… По этой причине ваши ковыряния мне не поняты. Вы же не устанавливаете связь с новой AP и т.д. а поддерживаете ранее открытую сессию... Ну пинг устройства будет более 100 ms и всё.

 

[nikolz]

Надо выкинуть и переписать большую часть SDK - тогда и получите указанные мной ранее 50 ms в периоде с засыпанием и просыпанием по deep_sleep (т.е. через GPIO16 с проводком на RESET).
Т.ч. вам ещё долго - у вас пока за 350 ms
Придется учесть всё:
// ROM-BIOS запускает код с адреса 0x40100000
// при опциях перезагрузки 'Jump Boot', если:
// GPIO0 = "0", GPIO1 = "1", GPIO2 = "0" (boot mode2,x))
Т.е. после первой загрузки устанавливаете GPIO в соответствии и грузиться с flash он не будет, на чем сэкономите ещё...
esp8266web/app_main.c at master · pvvx/esp8266web · GitHub

А в итоге, вы просто повторите режим sleep: LIGHT для WiFi (а он есть во всех SDK на все чипы). Там просыпание быстрее ещё быстрее (каждый beacon) и только настройка PLL, вроде 2 ms всего… По этой причине ваши ковыряния мне не поняты. Вы же не устанавливаете связь с новой AP и т.д. а поддерживаете ранее открытую сессию...

я как-то даже и не удивился.
Но Вам надо выкинуть редми к Вашему загрузчику,
эту фразу
"Может использоваться для ускорения загрузки любого стандартного <br>
проекта на ESP8266, путем копирования в начало первого блока кода:<br>"
или написать, что это ложь.
--------------------------------------------
Ну что же, выкинем это в корзину. Очередной фитиш.

 

[pvvx]

я как-то даже и не удивился.
Но Вам надо выкинуть редми к Вашему загрузчику,
эту фразу
"Может использоваться для ускорения загрузки любого стандартного <br>
проекта на ESP8266, путем копирования в начало первого блока кода:<br>"
или написать, что это ложь.

Он работает с другими стандартными проектами. Мои проекты ускоряет и уменьшает потребление. Не работает с вашим Lua, т.к. Lua на ESP является нестандартным и до сих пор не отлаженным проектом. Из местных никто не виновен, что Lua настолько кривая и требует включенного WiFi на нестандартной частоте перед пуском. Видимо там стоит очень старый SDK с кучей ошибок... Тем более все исходники лоадера даны и можно добавить включение WiFi части на кривой частоте и для увеличения потребления по окончанию загрузки.
И в моей Lua он прекрасно работает, после правки той старой SDK. EspLua/Makefile at master · pvvx/EspLua · GitHub . А сам проект ESPLua заброшен, т.к. исправлять такое кол-во ошибок в исходном проекте надоело... Пиар Lua на ESP прошел и он, в такой реализации, оказался нужен только вам.

Ну что же, выкинем это в корзину. Очередной фитиш.

Выкидывайте что хотите, если не справились.

 

[pvvx]

nikolz - вы уже разобрались, что вы постоянно сравниваете "два esp модуля общаются между собой без установки wifi соединения" и полную установку и завершение сессии WiFi соединения по стандарту?

Выкладываю результаты исследований китайских товарищей:
....
На картинках наглядно видно время работы передатчика при UDP и при ESP-now
В результате
средний ток потребления UDP -30ма
средний ток потребления ESP-now - 6.8 ma

В режиме экономии энергии в RTL00 средний ток при соединении по полному стандарту с внешней AP колеблется от 7 mA, в зависимости от кол-ва передаваемых данных и активности сети. У ESP8266 показатели в режиме sleep: LIGHT практически схожие.
Тут и не понятно "исследований китайских товарищей" - почему у них простое использование RF части для передачи одного пакета "раз в сутки" дает одинаковые показания с режимом работы модуля с полной поддержкой протокола WiFi и передачей данных хоть через HTTPS?

 

[nikolz]

Приступил к разработке для умного дома самого маленького, самого экономичного и самого дешевого модуля в мире .
В его основе два чипа SE8R01 и AVR Tinny13.
Поначалу было сомнение в возможности запихнуть все в 1 Kбайт flash.
В результате запихнул в 600 байт.

 

[pvvx]

Приступил к разработке для умного дома самого маленького, самого экономичного и самого дешевого модуля в мире .
В его основе два чипа SE8R01 и AVR Tinny13.

Тема то про WiFi
Вот вам пример оформления замеров по питанию:
CC3200 Power Management Optimizations and Measurements - Texas Instruments Wiki
Со сравнением потребления при TCP-TLS/SSL и UDP.
Когда изучите, поймете в чем самые главные проблемы и с чем боролись TI.
Это я вам уже описывал - время старта модуля с инициализациями. Остальное зависит от внешних факторов (время пинга до сервера) и скорости обработки шифрования TLS/SSL TCP пакетов. В итоге TI получили примерно одинаковые с RTL871x времена.

Условия теста там:

1. Работа со статическим IP (если это возможно), чтобы избежать DHCP.
2. Настройте политику подключения для работы с Fast Connect, которая означает, что устройство попытается сначала подключиться к предыдущему соединению.
3. Отключить сканирование, так как в этом случае мы, вероятно, останется в том же канале и сети (AP).
4. Отключить MDNS.

Я проверял со всеми включенными опциями - поиск AP по имени на всех каналах, новое соединение с AP с полной шифрацией по последним стандартам, выдача IP через DHCP, прием-передача данных, отключение от AP (полное высвобождение её ресурсов путем подачи всех команд отключения), засыпание (deep_sleep), т.к. мне нужен такой вариант. Укоротить всегда можно.

 

[nikolz]

Тема то про WiFi
Вот вам пример оформления замеров по питанию:
CC3200 Power Management Optimizations and Measurements - Texas Instruments Wiki
Со сравнением потребления при TCP-TLS/SSL и UDP.
Когда изучите, поймете в чем самые главные проблемы и с чем боролись TI.
Это я вам уже описывал - время старта модуля с инициализациями. Остальное зависит от внешних факторов (время пинга до сервера) и скорости обработки шифрования TLS/SSL TCP пакетов. В итоге TI получили примерно одинаковые с RTL871x времена.

Условия теста там:

1. Работа со статическим IP (если это возможно), чтобы избежать DHCP.
2. Настройте политику подключения для работы с Fast Connect, которая означает, что устройство попытается сначала подключиться к предыдущему соединению.
3. Отключить сканирование, так как в этом случае мы, вероятно, останется в том же канале и сети (AP).
4. Отключить MDNS.

Я проверял со всеми включенными опциями - поиск AP по имени на всех каналах, новое соединение с AP с полной шифрацией по последним стандартам, выдача IP через DHCP, прием-передача данных, отключение от AP (полное высвобождение её ресурсов путем подачи всех команд отключения), засыпание (deep_sleep), т.к. мне нужен такой вариант. Укоротить всегда можно.

То, что Вы написали, я по-возможности делаю. Конечно в рамках SDK.
У меня другой подход нежели у Вас.
Моя концепция такая:
сеть для умных домов и производств трех уровней.
Первый уровень - это сеть типа BLE , NRF (что почти одно и то же)
Второй и третий уровень - это WIFI.
Второй - это UDP, и только третий - это глобальная сеть - это TCP.
--------------------
Судя по Вашим постам, Вы занимаетесь (в терминах моей концепции ) третьим уровнем.
А меня этот уровень в настоящее время не волнует.

 

[vad7]

В его основе два чипа SE8R01 и AVR Tinny13.
Поначалу было сомнение в возможности запихнуть все в 1 Kбайт flash.
В результате запихнул в 600 байт.

Так там кроме общение с nrf еще логика прикладного уровня должна быть, датчики всякие и т.д..

 

[nikolz]

Так там кроме общение с nrf еще логика прикладного уровня должна быть, датчики всякие и т.д..

безусловно.

 

[vad7]

Так памяти маловато, почему бы tiny85 не использовать?

 

[nikolz]

Так памяти маловато, почему бы tiny85 не использовать?

на tiny85 любой сможет.
В том то и прелесть, чтобы сделать на 13.
Пока получается и памяти еще 40% свободной.
Как минимум можно реализовать розетку или выключатель а также датчик температуры на терморезисторе.
В результате получается умный модуль по цене в 1 доллар и с питанием от батарейки на год.

 

[pvvx]

Второй - это UDP, и только третий - это глобальная сеть - это TCP.

Судя по предыдущим вашим сообщениям 2-ой уровень - это глушилки WiFi, которые никогда не соединяются и не отсоединяются по протоколу с AP и лезут в эфир когда им непопадя для создания коллизий другим?