Скрыть объявление
На нашем форуме недоступен просмотр изображений для неавторизованных пользователей. Если Вы уже зарегистрированы на нашем форуме, то можете войти. Если у Вас еще нет аккаунта, мы будем рады, если Вы к нам присоединитесь. Зарегистрироваться Вы можете здесь.

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

Тема в разделе "Железные вопросы по esp8266", создана пользователем nikolz, 5 окт 2016.

  1. pvvx

    pvvx Активный участник сообщества

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

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

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

    pvvx Активный участник сообщества

    Сообщения:
    8.395
    Симпатии:
    1.271
    Если не умеете пользоваться - то при чем тут софт и 'лоадеры'?
    Научитесь описывать все исходные условия и параметры замера с предоставлением исходников и прочих материалов (описания), для возможности повтора замера другим.
    А то опять - нарисовали загогулину при неизвестных условиях.
    Это наверно график солнечной активности в каком-то кратере на обратной стороне Луны за прошедший вторник? :)
    Хотя-бы дали-бы примерное описание, как тут, по стадиям с исходниками:
    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 и прочих контроллеров. А это тоже не быстрый процесс…

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

    nikolz Гуру

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

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

    Вложения:

    Последнее редактирование: 26 окт 2016
  4. pvvx

    pvvx Активный участник сообщества

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

    nikolz Гуру

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

    nikolz Гуру

    Сообщения:
    4.136
    Симпатии:
    431
    вам делать нечего?
    Вам конкретно непонятно?
    что именно?
     
  7. nikolz

    nikolz Гуру

    Сообщения:
    4.136
    Симпатии:
    431
    [​IMG]
     
    Последнее редактирование: 30 окт 2016
    windalser нравится это.
  8. nikolz

    nikolz Гуру

    Сообщения:
    4.136
    Симпатии:
    431
    Теперь можно сравнить энерго эффективность протокола 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 дня.
    -------------------------------
    Примерно так
     
  9. Сергей_Ф

    Сергей_Ф Moderator Команда форума

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

    nikolz Гуру

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

    pvvx Активный участник сообщества

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

    nikolz Гуру

    Сообщения:
    4.136
    Симпатии:
    431
    Можете дать пример кода?
    Спасибо.
    10 ms - это не пинг. Пакет от eSP на комп приходит за 200 мкс.
    Это квант ОС windows (многзадачность, СЭР!).
     
  13. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.395
    Симпатии:
    1.271
    Тут не пример, а надо убивать китайцев :)
    При вызове deep_sleep ставиться задержка на 100 ms -> esp8266web/user_interface.c at master · pvvx/esp8266web · GitHub
    Т.е. переписывать закрытые функции SDK. Это вам не RTL - там такой уровень открыт.
    При чем тут квант? Это программа у вас кривая и не работает по событиям приема пакета. Представьте себе сервер с ответами через ваши кванты :) Его завалит DDS-ом один комп...
    Распределение по приоритетам с вызовом от драйвера не квантуется, а исполняется по мере поступления вызова и отработки задач с более высокими приоритетами...
    Это только в Lua можно построить опрос приема пакета для ответа на низшем уровне приоритетов исполнения с квантованием задачи опроса операционной системой :) По другому там никак :p По причине отсутствия многозадачности в Lua. Там псевдо многозадачность и совершенно убогая, что даже не назвать многопоточностью. Народ с этим мучается в Lua и выдумывает всякие извращения :)
     
    Последнее редактирование: 30 окт 2016
  14. nikolz

    nikolz Гуру

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

    nikolz Гуру

    Сообщения:
    4.136
    Симпатии:
    431
    Последние результаты работы 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.
    и все работает стабильно без зависаний.
    Чего и Всем желаю.
     
  16. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.395
    Симпатии:
    1.271
    Нельзя ничего изменить, если не патчить SDK.
    Задержка стоит для ожидания отработки (точнее обрыва на обум) посылок отключения сетевых сервисов и WiFi. Обрывать просто так связь в стандарте не принято. Так-же существуют нормативы для выхода на связь устройства WiFi и кол-ва посылок всяких Probe Request перед соединением и их интервалов. Можно это всё нарушить, но тогда это уже не стандартный WiFi, а какой-то самопальный приемо-передатчик работающий в диапазоне WiFi. ESP8266 таким и является.
    В SDK RTL-ов удалось найти и поправить на предел скорость отключения WiFi без нарушения протокола. Там драйвер ждет завершения всех транзакций, если они ещё не завершены:
    Код (Text):
    1. Deinitializing WIFI ...
    2. [rltk_wlan_deinit] Wait for RxStop
    При связи с роутерами отключение WiFi теперь происходит от 1 ms (один тик RTOS) до нескольких десятков, т.к. ожидает завершения транзакций.

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

    nikolz Гуру

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

    Полагаю, что использование стандартных стеков не сильно уменьшит время активности обмена в новых чипах.
     
  18. pvvx

    pvvx Активный участник сообщества

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

    nikolz Гуру

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

    pvvx Активный участник сообщества

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

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

Поделиться этой страницей