• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

ESP32C3 заглушка DeepSleep перестала исполняться

pvvx

Активный участник сообщества
На рис условно можно выделить несколько интервалов:
1) это импульс примерно до 4.5 мА с последующим падением примерно до 3.5.
2) участок 3.5 мА до скачка тока примерно на 8.5 мА
3) импульс до 8.5 мА
4) участок после импульса примерно 7 мА
5) спад до нуля
Все эти интервалы = аппаратный страт SoC, и в самом конце сотня команд CPU, которые не выделяются, т.к. в питании модуля есть кондер.
И всё это время даже Flash не включена и память не очищена. Т.е. никаких действий по инициализации чего либо в SoC (UART тоже ещё не включен), включая включение CLK на любую периферию CPU не включено.
В конце пробуждения SoC работает только тактирование CPU на default частоте и отрабатывает сотня команд. Далее в сон.
О да - забыл - ещё активна только ROM :LOL:
А если бы работал загрузчик - тогда половина SoС, включая Flash и т.д., уже была бы активна, да RAM распределена со всеми её регистрами управления MMU.
 

pvvx

Активный участник сообщества
В итоге после deep-sleep вам потребуется инициализировать 70% чипа и стек BLE, чтобы дойти до передачи маяка.
На это уйдет ещё несколько десятков мс при жручке тока более 50 мA. Затем 3 TX2RX для передачи маяка, что вылезет за сотню мА и не менее 3-х мс.
 

pvvx

Активный участник сообщества
Это не так.
Необходимая скорость поступления данных от датчиков в систему регулирования определяется инерцией (временем отклика) этой системы. В общем случае, теоретически, эта скорость определяется теоремой Котельникова-Найквиста.
У ПИД регулятора есть параметр постоянная времени , т е время реакции на ступенчатое возмущение. Вот это время и ограничивает скорость поступления данных с датчика.
При этом, как известно, надо брать не постоянную времени ПИД регулятора, а постоянную времени всей системы , т е включая нагреватели (если управление температурой) помещения и устройств охлаждения. Если элементы системы включены последовательно, то надо брать постоянную времени самого инерционного звена в системе.
--------------
Можете сказать , какая постоянная времени Вашей системы и обосновать Ваш критерий- "чем больше поток, и чаще - тем точнее управление" ?
У меня проблема со скоростью отклика на изменение температуры у самих датчиков, т.к. реакция остальной системы значительно быстрее в показателе градус в секунду.
Вы даже этого не учли. Из чего - вести диалог с теми кто никогда ничего не делал нет смысла.
Я не отапливаю кирпичные печки чурками, и не собираюсь нагнетать теплый воздух в ангар на тысячи кубометров с поддержанием там температуры в +-10 С.
 

pvvx

Активный участник сообщества
Вам была указана ссылка на пример использования BLE датчиков.
Там реакция системы более 1С в сек. Т.e. за цикл опроса датчиков в 10..20 секунд и дублирующей передачи BLE данных температура меняется на 20 С.
И цель всей автоматической системы управления в экономии энергии. И любое превышение тока на обогрев или охлаждение вызывает дополнительные потери на проводке и подводке электро-энергии к самой системе поддержания температуры. Т.е. цель автоматической системы управления в балансировке системы на средний ток, с ограничением импульсного потребления.
Уже давно известно, что инверторные системы потребляют меньше, чем On-Off, только за счет внешних потерь. И тут разговор не идет ещё о колебаниях поддерживаемой температуры или чего другого.
Дык вот на выходе кондиционера, уже в комнате, температуру воздуха можно менять в показателях на градус в секунду быстрее чем реакция датчика.
 

pvvx

Активный участник сообщества
И если вы там что-то считаете, но не как всегда не то, тогда сосчитайте простейший пример и сами выведите необходимое время реакции:
Возьмите входной объем площади со стандартной дверью на улицу. Пусть на улице -20С, а в помещении +22С. Открываем и закрываем дверь на N секунд . Система должна сохранить +22С.
Считайте. :ROFLMAO:
PS: а люди, использующие датчики с предоставляемой альтернативной прошивкой как раз используют в таких вариантах. Типа в гаражах-ангарах при открытии и закрытии ворот для управления тепловыми пушками... Они и пишут, что время реакции датчика слишком большое...
 

pvvx

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

pvvx

Активный участник сообщества
И дубль примера где датчики MY18B20 не успевают отрабатывать включение системы анти-обледенения внешнего блока кондиционера.
1749281622217.png
А так-же задержку дают и датчики потребления кондея.
Но в принципе с основной задачей и вписанного алгоритма в HA справляются.
И ещё не показан вариант включения авто-разморозки самого кондея. Там датчик температуры вообще тупит, т.к. изменение более 30С в сек и весь цикл (от +38С до -24С на выходе и удержания -24С, потом обратно) занимает около минуты.
 

pvvx

Активный участник сообщества
И ещё очень много бытового хлама требует достаточно быстрой реакции датчиков.
Пример простого контроля температуры в камере морозильника мелкого холодильника тупым термометром от батареек и системой теста-защиты-ограничения тока от заклинивания компрессора и прочих его выходках (отслеживается пусковой ток и его время, а также превышение потребления и т.д).
1749282701661.png
Т.е. время передачи данных по току (мощности) должно быть чаще пары секунд. И эта часть задачи уже реализуется в самом датчике тока, а передается только контрольные, итоговые замеры. Иначе Zigbee не успеет.
 

pvvx

Активный участник сообщества
Неисправность пускового устройства = частая проблема в тупых холодильниках. Итог - горелый компрессор. Особенно актуально в сельской местности и подобной, где напряжение гуляет как захочет и не стоит дорогущий стабилизатор общего электро-питания (которые выгорают ещё чаще).
 

pvvx

Активный участник сообщества
А с учетом того, что ныне используется пожароопасный фреон, то если компрессор заклинит, то с большой вероятностью будет пожар. А система контроля обходится в 400 руб = цена “вумной розетки” с Zigbee c потреблением в 5 раз меньше чем у WiFi розетки и не требующей участия глюков WiFi роутера.

И таким образом на всё сетевое оборудование у меня установлен контроль, почти до каждой лампочки (т.е. она всё равно так или иначе включена в цепь с контролем)… И управление при автономном генераторе можно переключать комплексно (и выборочно в меню телефона управления HA).
 

pvvx

Активный участник сообщества
Вот несколько возражений.
2) Про объем RAM для программы. Fast Ram ESP32С3 это 8 Кбайт, что равно свободной памяти в дешевых чипах TLSR.
Поэтому полагаю разместить там можно не мало. При этом для хранения текущих данных в активном режиме можно задействовать всю RAM.
Ничего не понятно. В TLSR 64КБ RAM, в WCH есть более 128КБ RAM.
Как это меняет решение задачи датчика?
Это же не WiFi и не Ethernet, где для нормального (по стандартам) TCP-IP стека и пары сокетов требуется от пол мегабайта.
4) Время активного режима.
Например надо измерять температурное поле группой датчиков DS1820.
Согласно док
• Converts temperature to digital word in 200 ms (typ.)
Т е никакой особенно экономии энергии при использовании чипа BLE не получится.
Копия из уже указанных вам ссылок на описания как ведется работа с 2-мя MY18B20 в TLSR825x:
Разделение на два цикла запрос, пауза измерения, считывание:
1749285856183.png
Общее среднее потребление составило 11.030 мкА.
Это с учетом третьего датчика влажности и температуры на I2C.
Т.е. опрос 3-х датчиков, контакта геркона со счетом, кнопки и выхода триггера со срабатыванием по указанным значениям температуры и/или влажности с гистерезисами, сборке и округлению замеров для записи и сама запись истории во Flash, ...
---
Замеры токов при напряжении питания 3.3В.
Ток по линии питания MY18B20, возникающий при запросе, ожидании измерения и чтении значений измерения (первые 4 мс):
1749286222910.png

Итоговое потребление по линии 3.3В датчика MY18B20 при опросе раз в 10 сек:
1749286230428.png
Потребление по линии 3.3В датчика MY18B20 между замерами:
1749286239433.png
Энергия затрачиваемая на запуск, ожидания и чтение замера с датчика MY18B20 у CPU (модуль TB-03F):
1749286289182.png
Возникающий хвост у MY18B20 по линии питания у MY18B20 после чтения измерения:
1749286298815.png
Общее потребление всей системы (модуль TB-03F + датчик MY18B20) во время сна:
1749286310005.png

5) Не вижу особого смысла забивать эфир сырыми данными, а реализовать нормальную обработку либо накопить данные , сжать их и отправить на более дешевых чипах не получится.
Отложенная передача данных никому и не для каких бытовых устройств не требуется.
Графики и прочие детализированные данные требуются для настройки системы и создания конечного продукта.
Так же если это универсальное решение - тогда требуются как можно больше данных и как можно чаше и с минимальной задержкой.
В этом случае логика управления ложится на систему управления "Умным домом", а алгоритм обработки вписывает пользователь.


@nikolz - Судя по ответам и вашим постам, напрашивается диагноз деменции. Вы не первый и не последний с таким диагнозом… Шизофрения или аутизм отличается другими проявлениями… Советую начинать применять какую-то терапию.
 

pvvx

Активный участник сообщества
Ещё замер цикла чтения замера и запуска нового измерения для MY18B20/DS18B20 (какая-то картинка из моего журнала когда лепилась программа, как и прошлые):
1749287107892.png
Всё всегда задокументировано. Иначе можно быстро забыть - разных разборок датчиков и разработок, и т.д., каждый день производится множество и через месяц уже всё забывается... В итоге уже давно за сотни гигабайт такого хлама в журналах... Можно закакать весь форум.
 

nikolz

Well-known member
И если вы там что-то считаете, но не как всегда не то, тогда сосчитайте простейший пример и сами выведите необходимое время реакции:
Возьмите входной объем площади со стандартной дверью на улицу. Пусть на улице -20С, а в помещении +22С. Открываем и закрываем дверь на N секунд . Система должна сохранить +22С.
Считайте. :ROFLMAO:
PS: а люди, использующие датчики с предоставляемой альтернативной прошивкой как раз используют в таких вариантах. Типа в гаражах-ангарах при открытии и закрытии ворот для управления тепловыми пушками... Они и пишут, что время реакции датчика слишком большое...
Отвечаю на Вашу задачку.
Только Вы додумались поставить датчик на улице, что бы контролировать температуру в помещении при открытии двери. Я бы поставил датчик именно у порога двери и проводом соединил его в систему управления. Нет надобности ни в BLE ни в батарейках.
Какой смысл измерять температуру на улице, если можно измерить ее в плоскости двери ? Не важно сколько на улице Важно сколько холодного воздуха поступит в помещение через открытую дверь.
-------------
Дарю Вам идею решения вашей проблемы открытой двери без BLE.
 

nikolz

Well-known member
И ещё очень много бытового хлама требует достаточно быстрой реакции датчиков.
Пример простого контроля температуры в камере морозильника мелкого холодильника тупым термометром от батареек и системой теста-защиты-ограничения тока от заклинивания компрессора и прочих его выходках (отслеживается пусковой ток и его время, а также превышение потребления и т.д).
Т.е. время передачи данных по току (мощности) должно быть чаще пары секунд. И эта часть задачи уже реализуется в самом датчике тока, а передается только контрольные, итоговые замеры. Иначе Zigbee не успеет.
В этой задаче нет смысла применять BLE.
Все ваши примеры - это задачи в которых нет смыcла использовать BLE и даже вообще беспроводную связь.
Без обид, но Ваше страстное желание засунуть везде BLE с батарейкой напоминает басню Крылова "Мартышка и очки".
----------------
Если нужна высокая скорость, то поставьте провод и гоните хоть миллион отсчетов в секунду.
 

nikolz

Well-known member
Относительно работы второго загрузчика и времени инициализации.
В документации на ESP32C3 написано, что время инициализации у большинства чипов ESP32 не превышает 280 us, а время старта заглушки не более 405 us. Получается что из 13000 us активности заглушки вся работа программы укладывается в 685 us. Что не так?
 

pvvx

Активный участник сообщества
Отвечаю на Вашу задачку.
Только Вы додумались поставить датчик на улице, что бы контролировать температуру в помещении при открытии двери. Я бы поставил датчик именно у порога двери и проводом соединил его в систему управления. Нет надобности ни в BLE ни в батарейках.
Какой смысл измерять температуру на улице, если можно измерить ее в плоскости двери ? Не важно сколько на улице Важно сколько холодного воздуха поступит в помещение через открытую дверь.
-------------
Дарю Вам идею решения вашей проблемы открытой двери без BLE.
Кто вам сказал что датчик на улице? Датчик в помещении, где необходимо поддерживать температуру. :p
 

pvvx

Активный участник сообщества
В этой задаче нет смысла применять BLE.
Все ваши примеры - это задачи в которых нет смыcла использовать BLE и даже вообще беспроводную связь.
Без обид, но Ваше страстное желание засунуть везде BLE с батарейкой напоминает басню Крылова "Мартышка и очки".
----------------
Если нужна высокая скорость, то поставьте провод и гоните хоть миллион отсчетов в секунду.
Зачем мне лишние километры проводов в доме и паутина из них на улицу?
Такая паутина будет стоить значительно больше, чем реализация на BLE или Zigbee. Плюс общее потребление увеличиться в десятки раз, как и оплата этой энергии.
 

pvvx

Активный участник сообщества
Относительно работы второго загрузчика и времени инициализации.
В документации на ESP32C3 написано, что время инициализации у большинства чипов ESP32 не превышает 280 us, а время старта заглушки не более 405 us. Получается что из 13000 us активности заглушки вся работа программы укладывается в 685 us. Что не так?
В сотый раз - это время работы кусков программ, а не старта SoC.
 

pvvx

Активный участник сообщества
@nikolz - Уточнение про энергоэффективность, если вы ещё ничего никогда не делали, с сортировкой по энергопотреблению на любое обеспечение соединения:

Потребление любой системы на WIFi составляет более сотни мА, а с учетом роутера – за несколько сотен мА. Т.е. более 1 Вт*ч.
Интерфейс Ethernet в текущих реализациях чипов кушает к сотне мА, и как итог – порядок от 0.5 Вт*ч.
Zigbee – это среднее потребление пару десятков мА – 0.2..0.3 Вт*ч.
При BLE – до 0.1 Вт*ч.
Если всё пересчитывать, да с учетом КПД блоков питания и потребления приемных устройств, тогда получим ещё большие цифры.
В итоге простейший WiFi датчик в год выжрет значительно более десятка кВт. А если их сотня – тогда к одному МегаBатту.
 
Сверху Снизу