Других вариантов у меня нет. А у Вас есть лучше предложение?У нормальных людей стоит инвертор, если есть автономное оборудование. И в розеточках ~220B. Всё равно DС-DC, вставленные в розеточки, не дают нормального КПД для аварийных датчиков.
Вас спросил - есть ли какие предложения по поводу увеличения их КПД и привел примеры использования, где это актуально. Если нет хороших решений - то значит нет.
-
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
Энергопотребление ESP(новое)
- Автор темы nikolz
- Дата начала
pvvx
Активный участник сообщества
Чем ещё, как не работой SDK?
Вы про нештатную, не по спецификации, работу WiFi?
По штатной там не менее 6-ти фаз:
0) Объявление о выходе в WiFi эфир.
1) Активный или пассивный поиск по всем каналам AP (время тут кол-во каналов * 1 сек в среднем, чтобы найти к примеру AP с неафишируемым именем)
2) Соединение с AP (время тут зависит от роутера, но в большей степени от качества ПО в модуле по обработке шифрации. Если аппаратное, и роутер не дешевый, то значительно быстрее)
3) Получение IP в сети (бывает до 0.7 сек)
4) Получение через DNS IP сервера по запросу имени (тут зависит от DNS)
5) Соединение с внешним сервером (Зависит от удаления сервера и пинга к нему)
...
6) Отключение от AP.
На вашей диаграмме, нечто похожее имеем в начале:
https://esp8266.ru/forum/attachments/upload_2017-10-14_18-45-10-png.4808/
Но там и половины протокола не задействовано. Т.е. работа не по стандарту WiFi.
Не вижу там xxx ms, а вижу xx секунд.
Пример замеров с учетом всех описанных пунктов на чистом SDK без изысков: Тест на требуемую энергию для соединения модуля RTL8710BN с внешней AP в SDK 4.0b.
Остановка всех процессов RTOS (и её самой), переход в sleep, выход из sleep, запуск RTOS и передача 1 пакета в WiFi на RTL занимают до 1 ms (с вычетом времени проведенного в sleep).
Аналогично и у ESP-32S, но у него нет расширенной PMU и жрет CPU при старте больше. Т.е. не умеет делать некоторые необходимые для уменьшения потребления вещи в таком алго-режиме. Надо хакать, начиная с ROM-BIOS и выкидывать всё, что сейчас наработано на него. А у RTL серии "B" - такие возможности даны в базе и базовом SDK.
Последнее редактирование:
----------------------------
Все, что Вы перечислили у меня происходит в первом сеансе связи, при включении питания модуля либо при потере связи с сервером. В этом случае общее время активности составляет от 1 до 3 секунд.
--------------------------------
В последующих сеансах пункты 1,2,3,4,5 не исполняются, так как в них нет надобности.
Пункт 6) исполняется после отсылки сообщения серверу т е после этих 150 мс (от импульса в начале до первого импульса в конце).
Сервер у меня внутренний - т е комп. и ответ от него приходит после этих 150 мс , как правило время ответа от 2 до 10 мс.
------------------------------------
Вопрос остался открытым как уменьшить интервал 150 мс и зачем он нужен?
Или как внутри него отключать приемник скажем на 100 мс, а потом процессор и ждать прерывание от приемника?
pvvx
Активный участник сообщества
Никак - это время работы инициализации китайского SDK с WiFi.
Он не может просто восстановить работу блока WiFi. Он его инит по полной. В Espressif SDK нет такой функции и любых описаний на блок WiFi. Вы и сами это написать не сможете.
В режиме DTIM(x) модуль должен принять beacon от AP и только далее действовать...
Через время вы должны подтвердить режим сна с DTIM(x). Это опять будет тысячи ms с пиками за 200 mA.
А ещё через время, у вас выйдет потеря связи. Например по периоду смены ключа у AP роутера. Вы же не слушаете AP и нарушаете протоколы WiFi (игнором всего что можно на модуле ESP8266). Роутер обязательно выкинет такое соединение или через несколько DTIM
будут идти длинные переключения и никаких ваших 150 мс...
Последнее редактирование:
beacon это 100 мс а зачем еще 50?
Если смотрю пакеты в сети на сервере, то ответ сервера посылается через 94 мкс после пакета от модуля.
Может быть что-то посоветуете как подглядеть (установить ) фактически куда идут эти 150 мс.
Может быть в ESP установлен какой-то таймер и жестко задан этот интервал.
Например, если в конце deep-sleep поставить "waiti 0" то время перехода в сон у меня уменьшилось на 30 мс .
----------------------------------------------------------------------------
Может еще что-то в консерватории исправить?
pvvx
Активный участник сообщества
А как он спящий (в режиме DTIM
) может послать пакет? Нашли очередной глюк в ESP?
Варите глко-кашу для вашего роутера? С этим никто вам не поможет.
Измените настройки LPS (Leisure Power Save) и IPS (Inactive Power Save), включите wakelock wlan и будет вам счастье на любом другом модуле имеющем управление этими режимами. Даже deep_sleep не потребуется - будет жрать меньше ESP8266 c deep_sleep и всегда активен. Т.е. реакция,например на кнопку у модуля к серверу, будет в один baecon при среднем потреблении менее 1.5..2 мА.
Последнее редактирование:
1) Не понял про спящий. Вне зависимости от того сколько спит 2 секунды или 20 секунд у меня время сеанса не меняется (если не теряем сервер) т е чистое время без старта 180 мс.А как он спящий (в режиме DTIM
Нашли очередной глюк в ESP?
Чтобы гарантированно принять beacon надо 101 мс. Но принять мы может и в 1 мс и в 101-ю.
По-умному надо, если приняли в 1-ю, то во 2-ю посылаем письмо серверу. И таким образом сеанс будет максимум 10 мс.
Если в 101 то соответственно максимум 110.
А имеем тупо 180.
Хочу, чтобы было адаптивно.
pvvx
Активный участник сообщества
Это уже сделано - Есть режим сна для станции у ESP8266 LIGHT. Он просыпается к приходу beacon (на окно приема).
Откройте спецификации WiFi и не выдумывайте свой личный глюко протокол для вашего глюко роутера...
Последнее редактирование:
Вы не поняли меня.
Если я не критикую вас, когда Вы рассказываете очевидное или написанное в документации, это не значит, что я этого не знаю.
Режим ligt - это не то что мне надо.
Более того, Вы как прусский офицер - "если в уставе сказано спать в окопе, то спать в окопе".
режим ligh существенно не снижает потребления. Проверял.
Я же говорю об управлении включением и выключением приемника без его перестройки. Никаким инструкциями это не запрещено.
pvvx
Активный участник сообщества
Такой функции в SDK нет, есть только включить
:bool wifi_set_opmode (uint8 opmode)
Parameters:
uint8 opmode: WiFi operating modes:
0x01: station mode
0x02: soft-AP mode
0x03: station+soft-AP
Как Вам такое решение?Можно не возиться вообще с WiFi, а нанять кого - пусть в журнал пишет
Проблема есть и надо как-то ещё решать. DC-DC не умеет работать на такой диапазон нагрузок с нормальным КПД.
Регулировка нагрузки при разных условиях нагрузки приведена в таблице ниже. Входное напряжение во время этого теста был 350 В постоянного тока.
110VDC: Pin=2.3W, Vout1=12.07V/0.062377A, Vout2=12.04V/0.06655A, Vout3=5.8V/0.06A,Efficiency: 82.7%
380VDC: Pin=2.622W, Vout1=12.06V/0.0623A, Vout2=12.02V/0.06645A, Vout3=5.8V/0.06A,Efficiency: 72.4%
есть еще такое решение:
PMP20637 RevA
Test Report 390V – 48V/1kW high frequency resonant converter
950kHz resonant frequency with less than 210g weight
Utilize TI HV GaN FETs as input switches
Optimized LLC SR conduction with UCD7138/UCD3138A
Achieve peak 97.6% efficiency
Power Stage dimension: 2” x 2.1” x 1.7”
PMP20637 RevA
Test Report 390V – 48V/1kW high frequency resonant converter
950kHz resonant frequency with less than 210g weight
Utilize TI HV GaN FETs as input switches
Optimized LLC SR conduction with UCD7138/UCD3138A
Achieve peak 97.6% efficiency
Power Stage dimension: 2” x 2.1” x 1.7”
Вложения
Хочу узнать Ваше мнение по следующему моменту.А как он спящий (в режиме DTIM
Вот график тока ESP в режимеLoRFCalParam .
Выбран интервал, когда подстройка не осуществляется.
До 130 - это старт.
После 280 - это обмен по UDP.
Меня интересует область от 130 ms до 280 ms .
Ход мыслей следующий.
Так как eSP выходит из deep-sleep в произвольное время (интервал сна 2 секунды) то никакой синхронизации в это время
с роутером нет.
Тем не менее, все временные интервалы на активном участке работы eSP постоянны.
Поэтому можно предположить что они задаются внутри ESP
--------------------------
Интервал от 130 до 150 мс - это очевидно период подстройки передатчика и он в данном случае отсутствует т к задан режим подстраиваться не каждый раз. и фактически его можно было бы для этого случая сделать равным нулю.
---------------------
Таким образом, в интервале от 140 до 280 работает приемник и нет никаких сигналов передатчика.
Следовательно роутер ничего не знает о том что ESP спал и ничего не следил.
Поэтому сигнал синхронизации от сервера поступит на интервале не более 100 ms.
При это никаких сигналов ESP не посылает.
Но интервал до готовности связи с момента включения приемника равен 150 ms.
ВЫВОД - это время задано для включения передатчика в режим готовности к работе
и определяется программно в ESP
и WIFI к этому интервалу не имеет никакого отношения.
Теоретически оно может быть равно нулю.
Т е лишь участок от 280 мс до 290 мс является интервалом связи по WIFI и действительно необходим.
======================
А теперь ВНИМАНИЕ, вопрос к знатокам.
Как уменьшить интервал от 130 до 280 мс до минимального значения?.
Спасибо
А это Вы почему пропускаете?
• 1: RF initialization only calibrate VDD33 and Tx power which will take about
18 ms; this reduces the current consumption.
• 2: RF initialization only calibrate VDD33 which will take about 2 ms; this has
the least current consumption.
Я использую всегда либо 1 либо 2 и никогда 3.
-----------------------------------
И как по Вашему согласовывается это утверждение в 200 мс c графиком выше на котором 150 мс.
И как тогда будет выглядеть график в режиме 2 (2 мс)
pvvx
Активный участник сообщества
Зачем гадать что-то с вашим безликим графиком (?), если существует logUART и терминал пишет что происходит с метками времени? Так сложно вставить в код метки вывода событий хотя-бы "1", "2" и посмотреть ход отработки старта?
Есть и элементарные Saleae анализаторы до 200 руб, по которым построен график Rapid_Loader/ESP-01-StartSignals.gif at master · pvvx/Rapid_Loader · GitHub
В инициализации китай-глюко-Espressif SDK инициализируется не только RF часть и время этого процесса вам не известно. По вашему безликому графику скорее всего это оно и есть.
Кто вас знает - может у вас там ваша любимая Lua и инится пустой блок SPIFFS?
Исходник то нема и не будет, вы же скрываете всё. Может и сам график нарисован от руки или с массой ошибок в измерении по дискретности времени и вообще замеру в каком месте питания и ...
Последнее редактирование:
Ну и зачем Вы это все написали?
Сначала из документации строчку списали ( т е очевидное излагаете)
Но выбрали то, что ближе к ответу
Потом рассказывать о том как Вы измеряете .
Я Вас разве об этом спросил?
Не нравится мой график?
Покажите на своем время прошедшее от старта до ответа по WIFI и объясните его.
На Ваших картинках этого нет
И не надо ляля про ваши приборы.
Просто сказали бы что не знаете ответ и такие данные видите впервые.
А что Вы намерили за 200 рублей -там нет вообще что-либо про работу WIFI.
Короче, не знаете, а сказать об этом стесняетесь. Бывает..
pvvx
Активный участник сообщества
Я не обладаю каналом телепатии к вашим модулям и что вы там насобирали. Может это вообще у вас не ESP8266.
На свои замеры я подробно описываю и/или даю исходники для любых уточнений. Устройства для измерений я тоже привожу самые доступные, чтобы любой мог повторить и только тогда могут быть какие-то обсуждения. А пока занимаемся гаданием "на кофейной гуще" - ваших наскальных рисунках.
Пример: В RTL-ках есть функция считывания регистров блока WiFi, используемая при переключениях режимов работы WiFi блока. Время восстановления регистров части чипа с WiFi запомненными значениями составляет время работы шины к данной периферии CPU и кол-ву регистров. Как вы дуамаете, сколько будет в мкс восстановление пусть пары сотен значений регистров?
Последнее редактирование:
Кто о чем, а вшивый о бане.Я не обладаю каналом телепатии к вашим модулям и что вы там насобирали. Может это вообще у вас не ESP8266.
Я что спрашивал Ваше мнение о моих модулях?
Я же тоже не знаю на чем Вы там свои картинки рисовали и сейчас всем лапшу на уши вешаете по RTL
Потому что никто не подтвердил Ваши картинки.
Я Вас спросил знаете ли Вы время которое проходит от старта до начала связи по WIFI в ESP
и привел Вам свои результаты.
Нет у Вас других результатов?
ну тогда причем здесь телепатия?
Не знаете, не надо мне цитаты из документации или из вики писать я и сам это могу прочитать.
pvvx
Активный участник сообщества
Это сделали и вы, сняв график работы примера в GitHub - pvvx/SDKnoWiFi: ESP8266 Open SDK without WiFi (startup < 30 ms to complete the flash cache)
Я вам отвечал - в Lua это время бывает и за несколько секунд, т.к. это время инициализации Lua до пользовательского вызова WiFi если стоит SPIFFS и он сильно фрагментирован.
В других случаях с Espressif SDK время от старта (срабатывания RESET) до рабочего пользовательского вызова работы с WiFi (инициализации всей системы, включения LwIP, таймеров и прочего необходимого) измеряется от 200 ms. Не менее.
Описанная у Espressif калибровка WiFi - это один из сотни процессов инициализации до работоспособности SDK.