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

Энергопотребление ESP(итоги)

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

  1. pvvx

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

    Сообщения:
    8.969
    Симпатии:
    1.301
    Для получения минимального потребления с передачей нескольких значений в минуту или час по WiFi существует уже проверенное решение. Оно заключается в передаче одного стандартного пакета 802.11 или типа и приема его на другом оборудовании. Прием можно организовать и на ESP8266 используя только стандартные функции SDK и Arduino.

    К примеру, среди стандартных функций, не ограничивая работу AP или STA, на ESP8266 есть функция оповещения приема пакета ‘Probe Request’. Логирование можно осуществить и на многих роутерах, установив OpenWRT.

    Передача стандартного пакета ‘Probe Request’ занимает не более 1 мс (прием на СВЧ диоде около модуля):
    Detected_WiFi_frame_probe_request.gif
    Далее, на примере использования пакета ‘Probe Request’:
    1. Включение модуля (аналогично после deep_sleep), загрузка программы и инициализация. На ESP8266 с использованием RapidLoader – 30..40 мс при 60..75 мА. На других модулях зависит от режима: из sleep - до 1 мс, из deep_sleep - порядок до 10 мс.
    2. Модуль с датчиком, с самого первого старта, опрашивает датчик, упаковывает значение в MAC поле блока ‘Probe Request’. Время исполнения зависит от датчика. Возьмем опрос ADC, что составит 1 мс при 20 мА.
    3. Включает тактирование и питание RF части, переписывает в её регистры записанные заранее значения и ждет инициализации RF части. Она аналоговая и требует время на это, как и на стабилизацию PLL. Данная процедура занимает пару мс при > 70 мА.
    4. Включает передачу блока ‘Probe Request’. Время исполнения 1 мс при 150..200 мА.
    5. Отключает RF и переводит чип в deep_sleep состояние. Если используется SPI Flash, то необходимо подать команду sleep и к ней. Время исполнения процедуры менее 1 мс при 25 мА.
    В итоге:
    Лог в UART на стороне модуля с датчиком:
    Код (Text):
    1. ...
    2. ID:0x0018   ADC:0x0237
    3. ID:0x0019   ADC:0x023c
    4. ID:0x001a   ADC:0x0234
    5. ID:0x001b   ADC:0x023c
    6. ID:0x001c   ADC:0x023c
    7. ID:0x001d   ADC:0x023c
    8. ID:0x001e   ADC:0x023b
    9. ID:0x001f   ADC:0x0237
    10. ID:0x0020   ADC:0x023b
    11. ...
    Лог в UART на стороне ESP8266 работающего к примеру с прошивкой "web-свалки":
    Код (Text):
    1. ...
    2. WiFi event(7): Probe Request (MAC:02:00:37:02:18:00, RSSI:-47)
    3. WiFi event(7): Probe Request (MAC:02:00:3c:02:19:00, RSSI:-47)
    4. WiFi event(7): Probe Request (MAC:02:00:34:02:1a:00, RSSI:-47)
    5. WiFi event(7): Probe Request (MAC:02:00:3c:02:1b:00, RSSI:-48)
    6. WiFi event(7): Probe Request (MAC:02:00:3c:02:1c:00, RSSI:-47)
    7. WiFi event(7): Probe Request (MAC:02:00:3c:02:1d:00, RSSI:-47)
    8. WiFi event(7): Probe Request (MAC:02:00:3b:02:1e:00, RSSI:-47)
    9. WiFi event(7): Probe Request (MAC:02:00:37:02:1f:00, RSSI:-57)
    10. WiFi event(7): Probe Request (MAC:02:00:3b:02:20:00, RSSI:-65)
    11. ...
    Из этого получается, что время активности, когда модуль исполняет нужные нам действия составляет 4..5 мс, в которой среднее потребление около 110 мА из-за работающего RF. Самая большая и критичная часть – это загрузка. У всех ESP это самая долгая и потребляющая часть из имеющихся WiFi-SoC, которую удалось сократить всего до 30 мс и уменьшить стартовый ток в 2 раза используя RapidLoader. При этом это не всё время когда происходит потребление при старте, ему предшествует время старта генератора CLK на кварце…

    На других WiFi-SoC старт из sleep происходит за 1 мс. Т.е. вся активность составляет до 6 мс, с средним потреблением 80..100 мА. А в режимах sleep с потреблением 0.1..3 мА у них активны все прерывания и остаются рабочими контроллеры, такие как UART, ADC, ... Что позволяет осуществлять передачу значений по мере их поступления с датчиков, с задержкой не более 5 мс от события.
     
    Последнее редактирование: 23 фев 2018
  2. pvvx

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

    Сообщения:
    8.969
    Симпатии:
    1.301
    @nikolz - не знаю, что там у вас выходит, но на RTL8710BN получается примерно такой график зависимости потреления от времени между посылкой значений от ADC:
    LowPowerSendPR.gif
    Для DeepSleep (перезагрузка):
    • Потребление в активном режиме 100 мА
    • Время активного режима 0,016 сек
    • Потребление в sleep 0,0065 мА
    Для Sleep (без перезагрузки):
    • Потребление в активном режиме 100 мА
    • Время активного режима 0,006 сек
    • Потребление в sleep 0,185 мА
    Если вы реализуете описанное CNLohr то в пределе, получите:
    LowPowerSendX.gif
    А сейчас у вас в сотни раз хуже. (Не забудьте, что шкалы на графиках логарифмические.)
     
    Последнее редактирование: 23 фев 2018
  3. Evgeny D

    Evgeny D Новичок

    Сообщения:
    72
    Симпатии:
    0
    У меня тоже 18.8 оказывается! На макетке к 3.3 была подсоединена только что купленная Attiny85... тремя выводами. Кушала 500мкА.

    Спасибо за помощь!
     
  4. pvvx

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

    Сообщения:
    8.969
    Симпатии:
    1.301
    Вот замер на WebRtl INA219 решения от CNLohr на моей сборке SDK к ESP8266 (его код доступен на github):
    Снимок4.gif
    Среднее за 100..105 мс активности 35 мА (3.21..3.25В), deep_sleep 10000 мс при 23 мкА.
    Замер на моей макетке в 100 сеансов (10 сек цикл) дает Average 0.00036 A при 3.30В (без провалов), deep_sleep у испытуемого модуля ESP-12E взятого из коробки новым: 23..24 мкА (зависит от температуры!).

    Полное соответствие с графиком при параметрах:
    Потребление в активном режиме 35 мА
    Время активного режима 0,1 сек
    Потребление в sleep 0,023 мА

    Снимок5.gif
    Про фейки расскажите себе. Уж насмотрелись их от вас.
    И так-же ничего нестандартного я в RTL не использую, включая и прием лога, который происходит на ESP8266 со стандартным SDK. Я просто не люблю быть первым - оставляю молодым - им отвечать я не мне :) Пришлось ждать 2 года...
    Про Tplink и прочее - обращайтесь к CNLohr. :) Может ему нравится другой WiFi пакет для передачи данных...
    И заметьте - старт с нуля тоже 100 мс 35 мА у него, не ваши 5..10 сек + полчаса времени настройки пользователем :)
     
    Последнее редактирование: 24 фев 2018
  5. pvvx

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

    Сообщения:
    8.969
    Симпатии:
    1.301
    И очень интересует что не стандартного в ‘linux wireless extensions’ Version : 22 16.3.07 ?
    Что оно не поддерживается в ESP? На Андроиде есть.
    И что вы называете стандартным SDK? Arduino? Вот в ней нет никаких стандартных общепринятых методов работы с устройствами WiFi и изучать Arduino не имеет никакого смыслу.
     
    Последнее редактирование: 24 фев 2018
  6. nikolz

    nikolz Гуру

    Сообщения:
    4.930
    Симпатии:
    454
    --------------------------------------
    Где Вы у меня видели "5..10 сек + полчаса времени настройки пользователем"
    Может перестанете херню всякую трындеть про других, а будете лишь про себя писать?
    А то какой-то старческий маразм у вас наблюдается.
    Вы либо давайте мои цитаты, либо прямо указывайте, что это Ваш бред, который Вы приписываете мне.
    --------------------------------------
    И зачем вы рисуете среднее на 10 секунд.
    Приведите данные для одного активного режима.
    Вы уже написали что в deep-sleep 23 мка.
    -------------------------------
    И не надо сюда еще сваливать RTL. У CNLohr на ESP8266 и плюс костыли к роутеру.
    При этом страт за 120 мс никуда не исчезает.
    Тогда и основной режим работы в 180 мс тоже никуда не исчезает (посмотрите его осциллограммы)
    Т е речь идет лишь о том, полезете Вы в первый импульс передатчика, либо в нормальную посылку UDP.
    Разница в потреблении будет не существенная.
    Если желаете действительно сравнить результаты, а не хвалить свое и гадить на других, то приведите один активный цикл ESP подробно как у меня в начале темы.
    Я вам это уже не один раз предлагал.
     
  7. pvvx

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

    Сообщения:
    8.969
    Симпатии:
    1.301
    А как ваш вариант настраивается на Роутер?

    Даю ваш цитаты:
    Где вы такое увидели?
    https://esp8266.ru/forum/attachments/snimok5-gif.5851/
    Это график зависимости потребления от времени между посылками (времени цикла просыпания - передачи - засыпания - ожидания в deep_sleep). Об этом описано ранее, в предыдущем сообщении.
    Я понимаю, что у вас тяжело с графиками и математикой, вы это вчера уже демонстрировали на решении линейного уравнения...
    Приведены полностью с графиками. Тыц
    Дубль-ссылка:
    [​IMG]
    B точке измерения (передача пакета): 195.4 мА 3.21В.

    В доке Espressif значится 20 мкА. Пока ни один модуль не смог столько показать при 3.3В питании.
    Замеры даны на ESP8266, программа взята у CNLohr путем скачивания, трансляции и заливки в ESP8266. Изменений не производилось, кроме номера COM порта для заливки.
    Мой описанный вариант с RTL и ESP8266 работают без костылей к роутеру.
    Так-же пашет на Андроиде.
    Старт на графике виден и соответствует заяве в RapidLoader, который линкуется по умолчанию в мой MinSDK для ESP8266, который и использует Автор.
    Кто это такой?
    В доке Espressif написано 2 мс. Реальные больше.
    Там сами передаем всего один пакет WiFi. Больше для передачи данных не требуется. Резерв у CNLohr куда работать есть - 20 мс лишних включен приемник RF до включения deep_sleep, + 20 мс лишних на калибровку RC генератора RTC, + не отключены опцией в mSDK сообщения, на которые уходит ещё к 10 мс. Вот с такими недоделками и замерено.
    В десятки раз. Пробуйте с просыпанием через час и со стартовым циклом от включения питания. Т.е. в реале, а не в синтетическом тесте с подтасовкой результатов.
    Он приведен.
    Но вы слепы или больны.
    Или прикидываетесь ничего не понимающим дурачком, т.к. ваше решение в сотни раз хуже.
    По этому и гадите?
    Расписать до журнала мурзилки с картинками для безграмотных? :)
    Вам broadcast пакет послать по WiFi?
     
    Последнее редактирование: 24 фев 2018
  8. nikolz

    nikolz Гуру

    Сообщения:
    4.930
    Симпатии:
    454
    pvvx,
    я вам скажу по секрету, что у вас неправильно написана прога deep-sleep.
    Поэтому и ток 23 мка.
    Возьмите deep-sleep из SDK и получите ток 18 мка.
     
  9. =AK=

    =AK= Гуру

    Сообщения:
    1.231
    Симпатии:
    100
    CNLohr делает измерения так редко, что короткие импульсы вполне могли оказаться не на графике.
     
  10. pvvx

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

    Сообщения:
    8.969
    Симпатии:
    1.301
    Я измерял из SDK deep-sleep и из Arduino. Разницы нет, что 3 года назад, что сегодня.
    И измерял не китайским тестером у которого на режиме измерения в мкА сопротивление шунта более 500 Ом на котом падает напряжение и модуль неверно стартует и криво работает.
    В доках написано типовое 20 мкА при менее 2.5В на чип, а не на модуль. Espressif всегда врет.
    На большинство Flash написано 1..5 мкА в Power-down Current ICC2 /CS = VCC, VIN = GND or VCC.
    20+5 = 25.
    Хорошо хотя бы что исправили в том году доки с 10 мкА при 3.3В, на 20 при 2.5 В :) Завтра ещё поправят...

    Поменял правильно опции mSDK и программу CNLohr - пока вышло его произведение так:
    Снимок6.gif
    Цикл активности стал уже 83 мс. Ещё дырка есть в 20 мс - тоже надо грохнуть...
    Данный график с INA219, а она быстрее 963.3 замера в сек не умеет при 12 битах...
    Осел включать лень.

    Дальше оптимизировать не буду. Нафиг это всё надо на ESP8266 - там всё равно загрузку и старт SDK не исправить, как и кривые дрова WiFi не отлепить от LwIP и прочей ненужной шняги, но так любимой Espressif c её гулюко чипом с сотнями аппаратных ошибок :)
    Та и дрова ESP не передают любые блоки в WiFi. Там тоже какая-то фигня кривая встроена... Копайтесь сами :)
    ------
    Замер тока на ESP8266 с опциями 3 сек deep_sleep:

    Измерялось этим:
    https://esp8266.ru/forum/attachments/20180225_123421-jpg.5874/
     
    Последнее редактирование: 25 фев 2018
  11. nikolz

    nikolz Гуру

    Сообщения:
    4.930
    Симпатии:
    454
    На сегодня получил следующие показатели работы ESP по WIFI UDP.
    Время активности 265 мс затраты энергии 0.05 Дж.
    upload_2018-3-17_20-31-59.png
    Работать с датчиками можно и в загрузчике и в основной программе. При этом потребляемый ток 12 ма.
    upload_2018-3-17_20-37-36.png
    -----------------------------
    И все это без каких либо ковыряний в SDK и софте роутера.
     
  12. nikolz

    nikolz Гуру

    Сообщения:
    4.930
    Симпатии:
    454
    Поясняю еще раз для дебилов.
    Беремdeep-sleep которую сварганил pvvx и ставим ее в прогамму. измеряем ток в deep-sleep получаем 22 мка как и рассказывает pvvx.
    А теперь вызываем эту программу из SDK и измеряем ток. получаем 18 мка.
    Еще раз для дебилов медленно.
    Ничего в железе не меняем лишь выкидываем дерьмо от pvvx и ставим из SDK получаем 18 мка вместо заявленных pvvx 22 мка.
    pvvx, вам все понятно?
     
  13. nikolz

    nikolz Гуру

    Сообщения:
    4.930
    Симпатии:
    454
    Уверен, что Вы найдете оправдания очередным своим глюкам.
    Но все же объясняю Вам следующее:
    Берем Ваш пакет MinEspSDKLib и ставим в нем вашу deep-sleep
    вот так:
    void ICACHE_FLASH_ATTR user_init(void) {
    ets_printf("test\n");
    system_deep_sleep(1000000);
    }
    И измеряем ток получаем такую картинку: (Т е масштаб этой картинки соответствует масштабу всем моим картинкам)
    upload_2018-3-17_21-34-16.png

    Теперь следите внимательно за моими объяснениями, а то опять не поймете.
    1) Вы утверждали что у Вас время старта 30 мс и кивали на вывод сообщения при старте - типа оно во всем виновато.
    А я утверждал что время старта не может быть меньше 80 мс и это сообщение влияет мало.
    Смотрим на Ваш результат - время старта 90 мс!!! где обещанные 30 или хотя бы 50 ?
    Посмотрим на мой график
    upload_2018-3-17_21-40-24.png


    Время старта те же 90 мс.
    Я в отличии от Вас ничего не оптимизировал и не создавал кучу софта, а использую все стандартное.
    ==================================

    Теперь смотрим дальше.
    На моем графике видно лучше первый импульс в 110 мс - это тот самый ответ в который CNLohr запихал свой ответ.
    Поэтому длительность его варианта не менее 110 мс.
    При этом замечу, что исходники библиотеки lwip теперь выложены в стандартном SDK.
    ================================
    Поэтому вашей заслуги в решении CNLohr никакой.
    А его решение не имеет практического значения, так как в этом решении нет возможности отодвинуть ответ для работы с датчиками.
    Т е надо еще докавыривать Ваш оптимальный.
    ========================
    И последнее:
    В моем решении затраты энергии на сеанс связи 0.05 дж.
    Вариант CNLohr по моим прикидкам затрачивает 0.015 дж.
    т е выигрыш в три раза.
    Но остается проблема с током потребления в основной программе при работе с датчиками и необходимость ковыряния в софте роутера.
    =======================
    У WIFI UDP ESP есть еще резерв - это интервал от 120 до 240 мс а также режим ESP-NOW.
    ================================
    В итоге pvvx лишь продекларировал 30 мс старта, а CNLohr ему поверил и пропиарил его вранье.
     
  14. pvvx

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

    Сообщения:
    8.969
    Симпатии:
    1.301
    Для дебилов тот-же CNLohr привел графики и описал, что весь цикл у него до 100 мс на ПО, написанном более 2-х лет назад.
    Вы же приводите 263 ms в одиночном и выбранном замере, спустя более 2-х лет :)
    Что-то туго у вас с усвоением того, что сделано давно.
    У вас впереди ещё освоение минимального цикла в 30 мс загрузки и выхода с включением deep_sleep, продемонстрированным 3 года назад с описанием что надо сделать для этого. :)
     
    Последнее редактирование: 18 мар 2018
  15. nikolz

    nikolz Гуру

    Сообщения:
    4.930
    Симпатии:
    454
    1) Для дебилов я объяснял как получить ток deep-sleep 18 мка.
    Но Вы так и не поняли почему у Вас в deep-sleep ток 23 мка.
    2) Вы опять не поняли Я написал что у меня 263 мс а у CNLohr 110 мc.
    3) У CNLohr время старта такое же ка у меня т.е не менее 80 мс и это можно сделать без Вашего repidloadera на основе rbood.
    4) Если я правильно понял,
    то CNLohr вставляет свой пакет в посылку калибровки RF,
    но работать ESP с его шедевром не хочет.
    -----------------------------------------
    ets Jan 8 2013,rst cause:2, boot mode:(3,6)
    load 0x40100000, len 108, room 16
    tail 12
    chksum 0x84
    csum 0x84
    Ѓўтк¬X«‰ьь
    Error wifi_config! Clear.
    с(µ$v-‰dмR§l кt‡-µСl`HЁ„µХ,µ—X8ct

    т е опять вещь в себе и надо кывырять непонятно что. и так все ваши поделки сделаны.
    ---------------------------------------------
    Ну и где здесь стандартная SDK?
     
  16. pvvx

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

    Сообщения:
    8.969
    Симпатии:
    1.301
    Для не умеющих измерять всё было разжЁвано: у вас тестер имеет внутренний шунт в 1 кОм при замере и просачивается питание по выводам RX/TX. Замеры делайте в SDK, а не в чем-то другом. Замеряйте модуль отдельно, с подключенными только питанием 3.3В.
    Он уточнил - до 100 мс в тексте, в последней версии, которую вы смотрели :p
    Его надо модифицировать!? До аналога rapidloader-а. Есть ли в этом смысл - что от него останется - название? :)
    (если разбираться полностью с rboot, то он нарушает опубликованную им лицензию, не приводя авторов использованных решений, исключая мои, т.к. они всегда даны без лицензий и с желаемым требованием не упоминать меня, что относиться и к вам. CNLohr такого не допускает...).
    И время загрузки стандартного SDK у rapidloader не 80 мс, а в два раза меньше. Даже у первой версии (43.2 мс с сигнала RESET):
    [​IMG]
    Работает без проблем. И там тоже не его решение - он указал от куда его взял. Читайте внимательнее то, что вам дают.
    А где она у вас, если вы к ней включаете сторонние компоненты и берете решения из rapidloader-а и прочих "первопроходцев", но так и не можете уже годы достигнуть желаемого или повторить уже достигнутые другими параметры?
    И ещё раз: Мои поделки/проделки сделаны не для "телепузиков". Для этого есть "сфера обслуживания", например - вы (или igrr и прочие фанаты ESP). Вот ваша задача и является донести, подготовить, обернуть в касивую обертку чужие решения и положить в рот потребителям, да ублажать их. Или вы думаете чего я с вами вожусь?
    Вы у нас тут на форуме, самый большой фанат ESP. Дурики типа =AK= и подобные, никогда не выкладывают никаких решений для других и подходят только для наполнения контекста и развлечений толпы… В итоге остаетесь вы один, но вас надо ещё научить выкладывать решения в правильной обертке для потребителей.
     
    Последнее редактирование: 19 мар 2018
  17. nikolz

    nikolz Гуру

    Сообщения:
    4.930
    Симпатии:
    454
    Вы внимательно читали?
    повторяю в сотый раз
    Схему измерения не меняем
    Но если поставить вашу функцию deep-sleep то ,eltn 23 мка
    а если из SDK то 18 мка
    и не важно что и куда втекает и вытекает так как это не меняется
    а заменяется лишь функция ( так называется программа )
    Дошло?
     
  18. pvvx

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

    Сообщения:
    8.969
    Симпатии:
    1.301
    Т.е. в стандартный SDK надо впихнуть функцию из моих проделок многолетней давности? :D
    Я измерял стандартный SDK, без "прибамбасов" - о чем вы и писали.
    Дошло?

    Вы бы объяснили, с какой целью надо в стандартный SDK вставлять что-то, чтобы проверить на соответствие документации на него? Вот в документации и описано, что типичное 20 мкА при 2.5 В.
     
    Последнее редактирование: 19 мар 2018
  19. nikolz

    nikolz Гуру

    Сообщения:
    4.930
    Симпатии:
    454
    на rboot если убрать лишнее все то же самое.
     
  20. pvvx

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

    Сообщения:
    8.969
    Симпатии:
    1.301
    Что от него останется?
    Длительная загрузка первого блока SDK и увеличение до его старта как раз на ваши 40 мс?
    Он грузит в IRAM и SRAM (rodata) до 3-х блоков в общей совокупности от 25 килобайт с Flash в режиме SIO и при этом ещё тратит время на вывод сообщений об этой загрузке в logUART.
    Т.е. он станет чисто лишним промежуточным звеном между стартом ROM и загрузкой SDK.
    RapidLoader на загрузку блоков в 25 кило в IRAM тратит 3.3 мс в режиме QIO через аппаратный XIP.
    В него не вставлено переключение на 80 МГц шины, т.к. иначе загружаемый стандартный SDK вообще балдит со скоростями UART. В свою сборку можете встроить переключение на 80 MHz, что ещё ускорит данную часть. Но дальнейшая структура уже не должна переключать PLL заново - на это требуется время. А т.к. переключение PLL находится в самом SDK, по этому его не вставлено в базовой версии, чтобы не получить двойную задержку на устаканивание PLL. Замер что быстрее - два раза переключать PLL на 80 MHz показал, что не стоит это того и не дает ускорения.
     
    Последнее редактирование: 19 мар 2018

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