Других вариантов у меня нет. А у Вас есть лучше предложение?У нормальных людей стоит инвертор, если есть автономное оборудование. И в розеточках ~220B. Всё равно DС-DC, вставленные в розеточки, не дают нормального КПД для аварийных датчиков.
Вас спросил - есть ли какие предложения по поводу увеличения их КПД и привел примеры использования, где это актуально. Если нет хороших решений - то значит нет.
-
Уважаемые посетители сайта esp8266.ru!
Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru -
Система автоматизации с открытым исходным кодом на базе 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.