А зачем такие непонятные действия делать? И потом коммутировать перед началом записи? Типа дополнительная емкость, ну тогда нужно перед ними, на линии питания диод ставить, что бы разряд шёл только с схему, а не на другие конденсаторы и стабилизаторы (если они там будут).
Я что-то похожее делал для бистабильно го реле, что бы отключать его, если пропало питание. Они же без тока не переключаться обратно, поэтому дополнительное микрореле ставил и коммутировать его так, что бы заряженные конденсаторы отрабатывали на отключающие катушки. Вам можно сделать аналогично. Коммутация конденсатора в момент отключения питания. Реле подключено на самом входе без конденсатор в, потом диод, что бы конденсаторы не удерживали катушку реле, за диодом конденсатор базовый и следом подключаемый.
Посмотрите комментарий внизу, решение очень простое.
А ещё, самая большая проблема в том, что ваше устройство никуда данные не передаёт, ни на сервер, ни в систему умного дома, просто хранит их у себя и все. При этом вы ежесекундно считываете данные, а отображает только последние из буфера. Зачем? Почему? Какова цель? Ну хотя тогда сравнивайте текущие с предыдущим и записывайте только те, которые изменились и для корректной метки времени обязательно нужны часы типа DS3231. Потому что после перезагрузки, у вас метка времени будет кривой и она будет повторяться в вашем файле. Логгирование всегда привязано к реальному времени или к порядковому номеру, если время не важно. У вас ни того ни другого, просто таймер millis / 60000. После перезагрузки МК он обнуляется.
В чем смысл тогда логгирования. Это же просто сбор данных без возможности дальнейшего использования. А потом вы что, возьмёте SD карту и с ней пойдёте к ПК переносить инфу? А куда? В Excel? Так сейчас не 2000 год, а 2026, и у вас микроконтроллер с Wi-Fi, Bluetooth, а это такие возможности!
А SD карта, в таком режиме сдохнет через 1-3 месяца, китайская за 1,5 - 2 недели.
Вместо sd карты можно установить FRAM CY15B102J, на 2 МБит (512КБайт), этого вполне достаточно что бы хранить там метку времени на 32 бита и 3 числа типа float в количестве 16384 записи. Даже если метеостанция будет каждые 10 минут снимать показания (а это слишком много), то этого объема в 16 384 записи вам хватит на 113 дней непрерывной автономной работы без перезаписи!
Но я все таки надеюсь, что и опрос будет реже и вы все таки не будете просто хранить данные на метеостанция за весь период, а будете передавать их на хост и очищать память. А запись будет только в том случае, если нет связи с хостом, иначе непонятно, зачем вообще их хранить на метеостанции. Если для прикола только.
А теперь преимуществ FRAM-памяти (CY15B102J) перед SD-картой при записи малых объемов данных (метка времени и три числа float):
В 100 раз выше скорость работы. Запись одной пачки данных во FRAM занимает всего 0,17–0,4 миллисекунды, тогда как на SD-карту текстовая строчка пишется от 10 до 40 миллисекунд из-за долгой инициализации и работы файловой системы FAT32.
В 500 раз ниже потребление тока. В момент физической записи чип FRAM потребляет около 150 микроампер, в то время как SD-карта при перезаписи флеш-массива требует от 50 до 100 миллиампер.
Практически бесконечный ресурс. FRAM выдерживает до 100 триллионов циклов перезаписи. SD-карта при постоянной циклической дозаписи мелких строчек выйдет из строя в сотни раз быстрее из-за ограниченного ресурса ячеек флеш-памяти. А дешёвая карта очень быстро, как это бывало на Raspberry Pi.
Отсутствие лишних операций с памятью. Во FRAM можно записать ровно 16–20 байт данных. На SD-карту невозможно записать блок меньше одного сектора (512 байт), поэтому системе приходится каждый раз считывать, модифицировать и перезаписывать сотни лишних байт.
Высокая надежность при внезапном отключении питания. Во FRAM данные сохраняются физически в момент отправки последнего бита. Если питание пропадет при записи на SD-карту, файловая система FAT32 может полностью разрушиться, что приведет к потере всего текстового файла.
Экономия памяти микроконтроллера. Для работы с FRAM используется простой и легкий код передачи данных по шине I2C. Для SD-карты требуется подключать тяжеловесные библиотеки для работы с файловой системой, которые занимают много оперативной и флеш-памяти контроллера.
Просто были подобные проекты и там этих граблей было так много, и что мы только не использовали. А вот вариант с FRAM стал спасением.
Это как? Заряжать конденсаторы непосредственно перед записью, когда они уже на линии питания находятся? Ничего не смущает? Они там просто будут находиться всегда заряженные на 100%.
Факты в студию. Бла бла бла не принимаются. Я вам код программы отдал, смотрите и разбирайтесь. Это и есть логгирование, если вы понимаете написанный код. Тем более на уровне МК, в моменты начала и завершения операций. Точнее не придумаешь.
пришлю вам нормальный лог) именно лог, а не непонятную штуку, как то там посчитанную)
Рот сначала помойте, и глаза,потом посмотрите на мой код программы, потом ещё 2 раза, потому ч то с первого не поймёте (вижу что вы и с второго раза порой не понимаете),ну а когда сможете разобраться, подумайте на своими словами. И вспомните эту фразу: Вы не самый умный человек на этой земле. Вы что-то знаете и что-то понимаете, но в мире есть люди умнее и это нормально. У них стоит учиться как делать правильно.
А ваш "нормальный" лог, без кода и объяснений можете напечатать на рулоне туалетной бумаги. Что с ним делать дальше, рассказывать не буду.
Статика для любого ip устройства, это нормально, тем более если мы хотим экономить на расход аккумулятора, а утопия переводить все барахло на динамику, контролировать сложнее и тем более, если оно всегда рядом и не болтается как смартфон. Вы в своём ip поле можете сделать столько миллионов адресов, сколько вздумается, и ещё это все в одну подсесть засунуть.
Для каждого случая стоит предусматривает самые оптимальные варианты. Если статика даст экономию времени в 1 секунду, то это отлично, можно использовать. Если нет необходимости заморачиваться, пусть будет динамика.
Канал можете привязать, не проблема. Главное покажите это, без "слюней".
Так сделайте и улучшите хоть что нибудь и будет вам натуралка, а не синтетика. В чем прикол воздух сотрясать?
С вашим мнением никто не спорит, оно навсегда останется вашим. Речь идёт о том, что вы стремитесь натянуть субъективные вещи на объективные. Свой опыт на чужой, считая свой - эталонным.
Вот если бы вы сказали так: У меня, нагрев был больше, в пределах 1-1.5 градусов в моем корпусе и исполнении, а время передачи составило от 5 до 6 секунд.
Да вопросов бы не было! У вас получились такие результаты, другой чип, другой корпус, другой код и другие мозги. И это нормально!
Но вы же решили сказать, что что-то будет влиять очень сильно, не зная фактов автора статьи, а я включился в дебаты, потому как для меня эти цифры ну сверх неразумные. А ещё это выглядит так: вы умны, а все идиоты, потому что думают не так как вы.
Если логи, то у вас нормальные, а у остальных - непонятная штука, как то там посчитанная. Вы считаете это нормальным и хотите что бы к вашему мнению прислушивались? Извините, но нет! Как вы к людям, так и они к вам... Предполагаю, что с вами просто никто и никогда не спорил и вы посчитали это своей силой, но это было так: он несёт свою хрень, ну да ладно пусть несёт, главное что бы работал нормально и по углам не гадил.
1) кремниевый диод с потерей 06-07В, при полном зарядке 4.2В снизит напряжение до 3.5В,а при подсаженной банке до 3х Вольт. Вполне рабочее решение.
2) поставить AP2112K-3.3 стабилизатор с управлением сна. И с входа на выход посадить как раз кремниевый диод. В режиме сна, он потребляет 0мА а сном управляет микроконтроллер.
Если напряжение аккума упало до 3,5 вольт, то для пробуждения ему хватит и 2.8В а потом запустится стабилизатор и отдаст 3,3 Вольта и запрет диод.
И тот и другой варианты рабочие, ну и диод и AP2112K-3.3 пропускают нормальные токи (AP2112K-3.3 до 200мА, кремниевый диод поболее) времени на нагрев диода не будет, потому как микроконтроллер пробуждается 30-50мсек (зависит от МК) и после включения основной ток пойдёт через стабилизатор.
3) Можно оставить и 1 стабилизатор, но потребление в холостую 55мкА, многовато и если мы максимально экономим аккум, то варианты 1 и 2.
И таким образом можно уменьшить габариты устройства, используя прямоугольный и плоский аккумулятор.
Да, ваши размеры - это как сову на глобус натянуть, можно, но сложно. Только я не понимаю, вы просто хотели туда модуль один засунуть и просто греть его? А в чем смысл? Мы здесь про изделие говорим, вполне конкретное, поэтому я открыл datasheet на esp32 и посмотрел размеры модулей, учёл те платы, которые автор указал в схеме + аккумулятор и размеры получились адекватные, если немного с запасом, то уж нам старикам простительно, мы всегда проектируем с запасом, с 80-х годов, ну вот так нас научили!
Такое впечатление что вы суть темы даже не понимаете, просто лижь бы ляпнуть и важно, что бы последнее слово осталось за вами. Представляю как вам сложно с образованными людьми живётся...
А кто тут скандалит? Я фактами расписал, на ваши аргументы, а вам то нечего сказать, приходится просто защищаться, хоть на вас никто и не нападал.
А что касается времени, то предполагаю что у вас его больше и точно пройдёт, надеюсь перестанете голословить и начнёте понимать мир и реальность, а нам старикам внуков воспитывать и вас молодых учить останется. Пропадёте ведь без нас.
Плохие времена рожают сильных людей, сильные люди создают хорошие времена, хорошие времена рожают слабых людей, слабые люди создают плохие времена.
Мне жаль, что плохие времена уже не за горизонтом.
Понимаю тебя, девочка, ты и другого не умеешь. Кроме как критиковать, без фактов, просто на своём т.н. "опыте".
Остаётся только язвить и укалывать фразами, а ведь сами начали пустой разговор, стремясь выехать за счёт чего - непонятно. Видимо гонора и самоуверенность, хейта. Ну что же, удачи вам. Я знаю свою правду, вы генерируете свою, нас не по пути.
Вот вам размеры модулей и коробки 20х20х10 мм. (обычно, инженеры указывают размеры в миллиметрах, если вы не в курсе)
Ни один из модулей не помещается в указанные вам размеры.
Делаем вывод, вы не инженер, не умеете пользоваться документацией и datasheet-ами на модули, компоненты, радиокомпоненты. Следовательно ваши расчеты изначально неверны и обречены на провал а изделия, если они вообще работают, с высокой долей вероятности будут собраны и рассчитаны некорректно, что повлечет за собой недолговечное время работы, ошибки и выход из строя.
А вот что говорит реальный мир, не ваш, а именно РЕАЛЬНЫЙ!:
Что было сделано (да я заморочился, потому что терпеть не могу выскочек, которые кроме бла-бла ничего не делают): 1) Взят модуль ESP32-C6 Super Mini (под рукой не оказалось ESP32-C3)
2) Его USBSerial не работает нормально, поэтому тупо сел на сериал шину UART 3.3В (Программатор тоже на 3.3В уровни), Serial просто контролю монитором на другом порту.
Скрытый текст
тупо UART, ничего лишнего.
3) Точка доступа - просто телефон на раздаче Wi-Fi 2.4GHz
4) Программный код под скрытым текстом.
Скрытый текст
#include <WiFi.h>
#include <WiFiUdp.h>
#if HWCDC_ENABLED
#define MySerial USBSerial
#else
#define MySerial Serial
#endif
// Сохраненные параметры вашей беспроводной сети
const char* ssid = "HONOR_200_Pro";
const char* password = "********"; // не скажу ))
// Новые уставки сервера назначения пакетов
const char* udp_server = "10.148.118.2";
const uint16_t udp_port = 1234;
WiFiUDP udp;
const int LED_PIN = LED_BUILTIN;
// Детализированные метки времени (в микросекундах)
int64_t t_start = 0;
int64_t t_wifi_ready = 0;
int64_t t_scan_bssid = 0;
int64_t t_connected = 0;
int64_t t_got_ip = 0;
int64_t t_udp_init = 0;
int64_t t_udp_start = 0;
int64_t t_udp_end = 0;
int64_t t_total_end = 0;
void setup() {
pinMode(LED_PIN, OUTPUT);
// Стартовое мигание
for (int i = 0; i < 3; i++) {
digitalWrite(LED_PIN, HIGH);
delay(1000);
digitalWrite(LED_PIN, LOW);
delay(1000);
}
MySerial.begin(115200);
delay(1500);
MySerial.println("\n==================================================");
MySerial.println("Начинаем расширенные расчеты для esp32-C6");
MySerial.println("==================================================");
MySerial.flush();
// --- СТАРТ ЗАМЕРОВ ВРЕМЕНИ ---
t_start = esp_timer_get_time();
WiFi.mode(WIFI_STA);
WiFi.setSleep(false);
WiFi.begin(ssid, password);
// 1. Ожидаем калибровки радиомодуля C6
while (WiFi.status() == WL_NO_SHIELD) {
delay(1);
}
t_wifi_ready = esp_timer_get_time();
// 2. Ожидаем, пока чип найдет физический MAC-адрес (BSSID) вашего Honor 200 Pro в эфире
while (WiFi.BSSID() == NULL) {
delay(1);
}
t_scan_bssid = esp_timer_get_time();
// 3. Ожидаем завершения авторизации (Handshake) и фиксации статуса подключения к радиоканалу
while (WiFi.status() == WL_DISCONNECTED || WiFi.status() == WL_IDLE_STATUS) {
delay(1);
}
t_connected = esp_timer_get_time();
// 4. Ожидаем, пока системный стек присвоит плате IP-адрес (DHCP завершится)
while (WiFi.localIP().toString() == "0.0.0.0") {
delay(1);
}
t_got_ip = esp_timer_get_time();
// 5. Замеряем время на инициализацию UDP-структуры в памяти
t_udp_init = esp_timer_get_time();
uint8_t packetBuffer[100];
for (int i = 0; i < 100; i++) {
packetBuffer[i] = (uint8_t)i;
}
// 6. Отправка UDP пакета
t_udp_start = esp_timer_get_time();
udp.beginPacket(udp_server, udp_port);
udp.write(packetBuffer, 100);
udp.endPacket();
t_udp_end = esp_timer_get_time();
t_total_end = esp_timer_get_time();
// --- КОНЕЦ ЗАМЕРОВ ВРЕМЕНИ ---
// ВЫВОД ПОЛНОГО МИКРОСЕКУНДНОГО ОТЧЕТА
MySerial.println("\n=== Расширенный отчет таймингов для ESP32-C6 Super Mini ===");
MySerial.printf("1. Низкоуровневая калибровка RF-модуля C6: %.2f мс\n", (t_wifi_ready - t_start) / 1000.0);
MySerial.printf("2. Чистый поиск сети и сканирование эфира: %.2f мс\n", (t_scan_bssid - t_wifi_ready) / 1000.0);
MySerial.printf("3. Проверка пароля и авторизация (WPA): %.2f мс\n", (t_connected - t_scan_bssid) / 1000.0);
MySerial.printf("4. Ожидание ответа DHCP-сервера телефона: %.2f мс\n", (t_got_ip - t_connected) / 1000.0);
MySerial.printf("5. Выделение памяти под сокет и буфер: %.2f мс\n", (t_udp_start - t_udp_init) / 1000.0);
MySerial.printf("6. ЧИСТОЕ ВРЕМЯ ОТПРАВКИ UDP (100 БАЙТ): %.3f мс (%.0f мкс)\n", (t_udp_end - t_udp_start) / 1000.0, (double)(t_udp_end - t_udp_start));
MySerial.println("----------------------------------------------------------");
MySerial.printf("ПОЛНОЕ ВРЕМЯ АКТИВНОСТИ ДО УХОДА В СОН: %.2f мс\n", (t_total_end - t_start) / 1000.0);
MySerial.printf("Полученный IP-адрес: %s\n", WiFi.localIP().toString().c_str());
MySerial.flush();
}
void loop() {
}
5) Все сделал в Arduino IDE (так быстрее и проще), на скорость никак не влияет, кроме того, что бы написать код.
Далее, что бы не слыть некорректным человеком и не врать о том, что отправленный пакет дошел:
Ответ монитора UDP, который принял пакет и показал, от кого он, следовательно пакет вышел из ESP32-C6 и дошел до адресата за указанное время.
Пакет получен от 10.148.116.239
И подключенные устройства на телефоне (подтверждение того что устройства присутствуют в сети с конкретными адресами):
Не стал загонять его в глубокий сон. Это же нужно для демонстрации "умному и всезнающему" человеку, а не для реальной работы здесь и сейчас.
А вот и результаты (не нейронки):
Они очень близки к тому, что предоставила нейронка (Она там сильно округлила и взяла с запасом). И уж очень сильно отличаются от "теории очень умного и всезнающего" человека, который оперирует просто словами, а не фактами типа: 3-4 секунды в среднем.
Реальность еще интереснее.
И так, сделал 5 итераций подряд с разными интервалами и полным аппаратным ребутом (подключение с нуля):
1 запуск - Смотри скрытый текст ниже
Скрытый текст
18:08:45.963 -> === Расширенный отчет таймингов для ESP32-C6 Super Mini ===
18:08:45.995 -> 1. Низкоуровневая калибровка RF-модуля C6: 72.06 мс
18:08:45.995 -> 2. Чистый поиск сети и сканирование эфира: 7.37 мс
18:08:45.995 -> 3. Проверка пароля и авторизация (WPA): 1686.48 мс
18:08:45.995 -> 4. Ожидание ответа DHCP-сервера телефона: 0.14 мс
18:08:46.027 -> 5. Выделение памяти под сокет и буфер: 0.01 мс
18:08:46.027 -> 6. ЧИСТОЕ ВРЕМЯ ОТПРАВКИ UDP (100 БАЙТ): 1.026 мс (1026 мкс)
18:08:46.027 -> ----------------------------------------------------------
18:08:46.027 -> ПОЛНОЕ ВРЕМЯ АКТИВНОСТИ ДО УХОДА В СОН: 1767.08 мс
18:08:46.027 -> Полученный IP-адрес: 10.148.118.239
2 запуск - Смотри скрытый текст ниже
Скрытый текст
18:10:25.187 -> === Расширенный отчет таймингов для ESP32-C6 Super Mini ===
18:10:25.187 -> 1. Низкоуровневая калибровка RF-модуля C6: 65.78 мс
18:10:25.218 -> 2. Чистый поиск сети и сканирование эфира: 7.54 мс
18:10:25.218 -> 3. Проверка пароля и авторизация (WPA): 1677.58 мс
18:10:25.219 -> 4. Ожидание ответа DHCP-сервера телефона: 0.14 мс
18:10:25.219 -> 5. Выделение памяти под сокет и буфер: 0.01 мс
18:10:25.219 -> 6. ЧИСТОЕ ВРЕМЯ ОТПРАВКИ UDP (100 БАЙТ): 1.026 мс (1026 мкс)
18:10:25.261 -> ----------------------------------------------------------
18:10:25.261 -> ПОЛНОЕ ВРЕМЯ АКТИВНОСТИ ДО УХОДА В СОН: 1752.08 мс
18:10:25.261 -> Полученный IP-адрес: 10.148.118.239
3 запуск - Смотри скрытый текст ниже
Скрытый текст
18:12:14.975 -> === Расширенный отчет таймингов для ESP32-C6 Super Mini ===
18:12:15.007 -> 1. Низкоуровневая калибровка RF-модуля C6: 65.38 мс
18:12:15.007 -> 2. Чистый поиск сети и сканирование эфира: 7.55 мс
18:12:15.007 -> 3. Проверка пароля и авторизация (WPA): 1637.98 мс
18:12:15.007 -> 4. Ожидание ответа DHCP-сервера телефона: 0.14 мс
18:12:15.039 -> 5. Выделение памяти под сокет и буфер: 0.01 мс
18:12:15.039 -> 6. ЧИСТОЕ ВРЕМЯ ОТПРАВКИ UDP (100 БАЙТ): 1.029 мс (1029 мкс)
18:12:15.039 -> ----------------------------------------------------------
18:12:15.039 -> ПОЛНОЕ ВРЕМЯ АКТИВНОСТИ ДО УХОДА В СОН: 1712.08 мс
18:12:15.039 -> Полученный IP-адрес: 10.148.118.239
4 запуск - Смотри скрытый текст ниже
Скрытый текст
18:14:29.443 -> === Расширенный отчет таймингов для ESP32-C6 Super Mini ===
18:14:29.443 -> 1. Низкоуровневая калибровка RF-модуля C6: 62.24 мс
18:14:29.475 -> 2. Чистый поиск сети и сканирование эфира: 7.46 мс
18:14:29.475 -> 3. Проверка пароля и авторизация (WPA): 1185.20 мс
18:14:29.475 -> 4. Ожидание ответа DHCP-сервера телефона: 0.14 мс
18:14:29.475 -> 5. Выделение памяти под сокет и буфер: 0.01 мс
18:14:29.517 -> 6. ЧИСТОЕ ВРЕМЯ ОТПРАВКИ UDP (100 БАЙТ): 0.965 мс (965 мкс)
18:14:29.517 -> ----------------------------------------------------------
18:14:29.517 -> ПОЛНОЕ ВРЕМЯ АКТИВНОСТИ ДО УХОДА В СОН: 1256.01 мс
18:14:29.517 -> Полученный IP-адрес: 10.148.118.239
5 запуск - Смотри скрытый текст ниже
Скрытый текст
18:15:16.423 -> === Расширенный отчет таймингов для ESP32-C6 Super Mini ===
18:15:16.423 -> 1. Низкоуровневая калибровка RF-модуля C6: 63.92 мс
18:15:16.423 -> 2. Чистый поиск сети и сканирование эфира: 8.12 мс
18:15:16.423 -> 3. Проверка пароля и авторизация (WPA): 1185.90 мс
18:15:16.423 -> 4. Ожидание ответа DHCP-сервера телефона: 0.14 мс
18:15:16.454 -> 5. Выделение памяти под сокет и буфер: 0.01 мс
18:15:16.454 -> 6. ЧИСТОЕ ВРЕМЯ ОТПРАВКИ UDP (100 БАЙТ): 1.036 мс (1036 мкс)
18:15:16.454 -> ----------------------------------------------------------
18:15:16.454 -> ПОЛНОЕ ВРЕМЯ АКТИВНОСТИ ДО УХОДА В СОН: 1259.11 мс
18:15:16.498 -> Полученный IP-адрес: 10.148.118.239
Среднее время за 5 повторов составляет 1549,27 мс (примерно 1,55 секунды).
Это включая получение IP адреса и передачу данных. При статическом IP, время сократится.
И отдельно, я сделал пакет объемом 4096 байт и вот его итерация:
Скрытый текст
18:25:05.007 -> === Расширенный отчет таймингов для ESP32-C6 Super Mini ===
18:25:05.007 -> 1. Низкоуровневая калибровка RF-модуля C6: 70.25 мс
18:25:05.039 -> 2. Чистый поиск сети и сканирование эфира: 7.70 мс
18:25:05.039 -> 3. Проверка пароля и авторизация (WPA): 1675.95 мс
18:25:05.039 -> 4. Ожидание ответа DHCP-сервера телефона: 0.14 мс
18:25:05.039 -> 5. Инициализация буфера отправки: 0.00 мс
18:25:05.083 -> 6. ЧИСТОЕ ВРЕМЯ ОТПРАВКИ UDP (1400 БАЙТ): 1.460 мс (1460 мкс)
18:25:05.083 -> ----------------------------------------------------------
18:25:05.083 -> ПОЛНОЕ ВРЕМЯ АКТИВНОСТИ ДО УХОДА В СОН: 1755.51 мс
18:25:05.083 -> Полученный IP-адрес: 10.148.118.239
Вот что он отправлял:
Скрытый текст
const char borodino_text[] PROGMEM =
"Скажи-ка, дядя, ведь не даром Москва, спаленная пожаром, Французу отдана? "
"Ведь были ж схватки боевые, Да, говорят, еще какие! Недаром помнит вся Россия Про день Бородина! "
"- Да, были люди в наше время, Не то, что нынешнее племя: Богатыри - не вы! "
"Плохая им досталась доля: Немногие вернулись с поля... Не будь на то господня воля, Не отдали б Москвы! "
"Мы долго молча отступали, Досадно было, боя ждали, Ворчали старики: "
"\"Что ж мы? на зимние квартиры? Не смеют что ли командиры Чужие изорвать мундиры О русские штыки?\" "
"И вот нашли большое поле: Есть разгуляться где на воле! Построили редут. "
"У наших ушки на макушке! Чуть утро осветило пушки И леса синие верхушки - Французы тут как тут. "
"Забил заряд я в пушку туго И думал: угощу я друга! Постой-ка, брат мусью! "
"Что тут хитрить, пожалуй к бою; Уж мы пойдем ломить стеною, Уж постоим мы головою За родину свою! "
"Два дня мы были в перестрелке. Что толку в этакой безделке? Мы ждали третий день. "
"Повсюду стали слышны речи: \"Пора добраться до картечи!\" И вот на поле грозной сечи Ночная пала тень. "
"Прилег вздремнуть я у лафета, И слышно было до рассвета, Как ликовал француз. "
"Но тих был наш бивак открытый: Кто кивер чистил весь избитый, Кто штык точил, ворча сердито, Кусая длинный ус. "
"И только небо засветилось, Все шумно вдруг зашевелилось, Сверкнул за строем строй. "
"Полковник наш рожден был хватом: Слуга царю, отец солдатам... Да, жаль его: сражен булатом, Он спит в земле сырой... "
"И молвил он, сверкнув очами: \"Ребята! не Москва ль за нами? Умремте же под Москвой, Как наши братья умирали!\" "
"И умереть мы обещали, И клятву верности сдержали Мы в бородинский бой.";
А вот что услышал UDP на ноуте у меня:
Скрытый текст
Объем пакета передачи не сильно влияет на задержку.
Отличие 100 байт и 1400 байт, всего 424 Микросекунды!
А теперь вишенка на торте:
Статический IP адрес (), полный ребут, и пакет 1400 байт. Смотрим и удивляемся:
18:43:38.193 -> === Расширенный отчет таймингов для ESP32-C6 Super Mini ===
18:43:38.225 -> 1. Низкоуровневая калибровка RF-модуля C6: 72.71 мс
18:43:38.225 -> 2. Чистый поиск сети и сканирование эфира: 7.72 мс
18:43:38.225 -> 3. Проверка пароля и авторизация (WPA): 105.81 мс
18:43:38.225 -> 4. Ожидание ответа DHCP-сервера телефона: 0.16 мс
18:43:38.257 -> 5. Инициализация буфера отправки (ОЗУ): 0.06 мс
18:43:38.257 -> 6. ЧИСТОЕ ВРЕМЯ ОТПРАВКИ UDP (1400 БАЙТ): 1.370 мс (1370 мкс)
18:43:38.257 -> ----------------------------------------------------------
18:43:38.257 -> СТАТУС ХОСТА UDP: ОНЛАЙН (Время ответа: 37 мс)
18:43:38.257 -> ПОЛНОЕ ВРЕМЯ АКТИВНОСТИ ДО УХОДА В СОН: 338.90 мс
18:43:38.298 -> Текущий IP-адрес платы в сети: 10.148.118.5
Всего 338 мс. при статическом IP. Вот и все. Нет там ни 3х ни 4х секунд. Вас обманули! )))))))))))
Вы точно никогда не отправляли сами mqtt запрос с esp) Среднее время загрузки, подключения к WiFi и отправка запроса с SSL будет как раз около 6 секунд. Даже на 10-20 байт.
Что вы теперь скажете в свое оправдание? Вот я практически, в реальном мире, довел полный цикл передачи данных аж до 0,338 секунды (338 мс.) с передачей не 10-20 байт, а 1400 байт.
Теперь считаем тепловыделение этого модуля.
При работе 338 миллисекунд каждые 5 минут (средняя тепловая мощность всего 0,00048 Вт) значения будут следующими:
Вариант 1: Коробка 2 х 2 х 1 см (объем 4 см³)
Это экстремально маленький корпус (чуть больше самого модуля ESP32). Воздуха внутри очень мало, поэтому он нагреется чуть сильнее.
Нагрев воздуха внутри корпуса: на ~0,028 °C
Локальный нагрев платы в закрытом объеме: на ~0,09 °C
Вариант 2: Коробка 3 х 3 х 5 см (объем 45 см³)
Объем этого корпуса больше в 11 раз, а площадь стенок для рассеивания тепла значительно выше.
Нагрев воздуха внутри корпуса: на ~0,004 °C (абсолютно незаметно)
Локальный нагрев платы в замкнутом объеме: на ~0,01 °C
Как вам такие цифры? Реальность или снова скажете - вру.
Ну а что бы вообще все с доказательной базой - вот программный код.
Скрытый текст
#include <WiFi.h>
#include <WiFiUdp.h>
#include "ping/ping_sock.h"
#if HWCDC_ENABLED
#define MySerial USBSerial
#else
#define MySerial Serial
#endif
// Сохраненные данные сети
const char* ssid = "HONOR_200_Pro";
const char* password = " ***** "; // не скажу
// НАСТРОЙКА СТАТИКИ: Жестко задаем адреса
const IPAddress local_IP(10, 148, 118, 5);
const IPAddress gateway(10, 148, 118, 2); // Ставим шлюзом сам UDP-сервер (избегаем 0.0.0.0)
const IPAddress subnet(255, 255, 255, 0);
const IPAddress dns(10, 148, 118, 2);
const char* udp_server_ip = "10.148.118.2";
const uint16_t udp_port = 1234;
WiFiUDP udp;
const int LED_PIN = LED_BUILTIN;
volatile bool ping_success = false;
volatile uint32_t ping_time_ms = 0;
static void my_ping_on_recv(esp_ping_handle_t hdl, void *args) {
uint32_t elapsed_time;
esp_ping_get_profile(hdl, ESP_PING_PROF_DURATION, &elapsed_time, sizeof(elapsed_time));
ping_success = true;
ping_time_ms = elapsed_time;
}
bool pingHost(const char* ip_str) {
ping_success = false;
esp_ping_config_t ping_config = ESP_PING_DEFAULT_CONFIG();
ip_addr_t target_ip;
ip4addr_aton(ip_str, &target_ip.u_addr.ip4);
target_ip.type = IPADDR_TYPE_V4;
ping_config.target_addr = target_ip;
ping_config.count = 1;
esp_ping_callbacks_t cbs;
memset(&cbs, 0, sizeof(esp_ping_callbacks_t));
cbs.on_ping_success = my_ping_on_recv;
esp_ping_handle_t ping_handle;
if (esp_ping_new_session(&ping_config, &cbs, &ping_handle) == ESP_OK) {
esp_ping_start(ping_handle);
delay(150);
esp_ping_stop(ping_handle);
esp_ping_delete_session(ping_handle);
}
return ping_success;
}
const char borodino_text[] PROGMEM =
"Скажи-ка, дядя, ведь не даром Москва, спаленная пожаром..."; // Текст урезан в примере для краткости
int64_t t_start = 0;
int64_t t_wifi_ready = 0;
int64_t t_scan_bssid = 0;
int64_t t_connected = 0;
int64_t t_got_ip = 0;
int64_t t_udp_init = 0;
int64_t t_udp_start = 0;
int64_t t_udp_end = 0;
int64_t t_total_end = 0;
bool is_host_alive = false;
void setup() {
pinMode(LED_PIN, OUTPUT);
for (int i = 0; i < 3; i++) {
digitalWrite(LED_PIN, HIGH); delay(1000);
digitalWrite(LED_PIN, LOW); delay(1000);
}
MySerial.begin(115200);
delay(1500);
MySerial.println("\n==================================================");
MySerial.println("Запуск жесткой конфигурации статического IP...");
MySerial.println("==================================================");
MySerial.flush();
// --- СТАРТ ЗАМЕРОВ ВРЕМЕНИ ---
t_start = esp_timer_get_time();
// СТРОГИЙ ПОРЯДОК ДЛЯ ЯДРА 3.Х:
WiFi.mode(WIFI_STA);
WiFi.setSleep(false);
// Шаг А: Записываем в память чипа SSID и Пароль один раз
WiFi.persistent(true);
// Шаг Б: Принудительно скармливаем статические адреса сетевому интерфейсу
if (!WiFi.config(local_IP, gateway, subnet, dns)) {
MySerial.println("[ОШИБКА] Сетевой стек LwIP отклонил статические адреса!");
}
// Шаг В: СТРОГО ПУСТОЙ вызов begin().
// Это заставит ядро запустить ассоциацию WPA, используя config из памяти, без сброса в DHCP
WiFi.begin(ssid, password);
while (WiFi.status() == WL_NO_SHIELD) {
delay(1);
}
t_wifi_ready = esp_timer_get_time();
while (WiFi.BSSID() == NULL) {
delay(1);
}
t_scan_bssid = esp_timer_get_time();
while (WiFi.status() != WL_CONNECTED) {
delay(1);
}
t_connected = esp_timer_get_time();
// При фиксации статики этот цикл пролетит за 0 мс, так как DHCP выключен
while (WiFi.localIP().toString() == "0.0.0.0") {
delay(1);
}
t_got_ip = esp_timer_get_time();
// Проверка Ping хоста
is_host_alive = pingHost(udp_server_ip);
t_udp_init = esp_timer_get_time();
uint8_t ramBuffer[1400];
memcpy_P(ramBuffer, borodino_text, 1400);
t_udp_start = esp_timer_get_time();
udp.beginPacket(udp_server_ip, udp_port);
udp.write(ramBuffer, 1400);
udp.endPacket();
t_udp_end = esp_timer_get_time();
t_total_end = esp_timer_get_time();
// --- КОНЕЦ ЗАМЕРОВ ВРЕМЕНИ ---
MySerial.println("\n=== Расширенный отчет таймингов для ESP32-C6 Super Mini ===");
MySerial.printf("1. Низкоуровневая калибровка RF-модуля C6: %.2f мс\n", (t_wifi_ready - t_start) / 1000.0);
MySerial.printf("2. Чистый поиск сети и сканирование эфира: %.2f мс\n", (t_scan_bssid - t_wifi_ready) / 1000.0);
MySerial.printf("3. Проверка пароля и авторизация (WPA): %.2f мс\n", (t_connected - t_scan_bssid) / 1000.0);
MySerial.printf("4. Ожидание ответа DHCP-сервера телефона: %.2f мс\n", (t_got_ip - t_connected) / 1000.0);
MySerial.printf("5. Инициализация буфера отправки (ОЗУ): %.2f мс\n", (t_udp_start - t_udp_init) / 1000.0);
MySerial.printf("6. ЧИСТОЕ ВРЕМЯ ОТПРАВКИ UDP (1400 БАЙТ): %.3f мс (%.0f мкс)\n", (t_udp_end - t_udp_start) / 1000.0, (double)(t_udp_end - t_udp_start));
MySerial.println("----------------------------------------------------------");
if (is_host_alive) {
MySerial.printf("СТАТУС ХОСТА UDP: ОНЛАЙН (Время ответа: %d мс)\n", ping_time_ms);
} else {
MySerial.println("СТАТУС ХОСТА UDP: ОФФЛАЙН");
}
MySerial.printf("ПОЛНОЕ ВРЕМЯ АКТИВНОСТИ ДО УХОДА В СОН: %.2f мс\n", (t_total_end - t_start) / 1000.0);
MySerial.printf("Текущий IP-адрес платы в сети: %s\n", WiFi.localIP().toString().c_str());
MySerial.flush();
}
void loop() {
}
Вывод: уважаемый, примите тот факт, что вы были не правы, может потому что сами не знаете, что делаете ))))
P.S. Я более чем уверен, что "очень умный и всезнающий" человек обязательно скажет свое "умное слово", но теперь ВАШ ХОД и только такой, что бы это было действительно фактами, а не ваши очередные "я разрабатывал и было вот так, поэтому знаю", "5 лет делаю проекты", "...знаю...", "...вы не отправляли пакеты MQTT...". Все другое в виде слов идет лесом и полем.
Я отрисую эти размеры корпуса и размещу в нем esp32-c3, добавлю плату и вернусь, покажу вам, что это за размеры. Впечатление такое, что вы в игрушечном мире живёте, для вас влияние температуры в 1,5 (вами посчитанных градуса) это ужас как много, корпус таких размеров, что некуда размещать компоненты.
Последнее даже комментировать не буду, бесполезно...
Очень интересный корпус! 20х20х10мм, туда даже модуль не поместится, не считая обвязки. А мы говорим про конкретное устройство, которое сделал автор и там не 20х20х10 мм корпус. Вы сейчас тупо за уши притягиваете к своим ответам. Возьмите корпус побольше, адекватный 30х30х50 (я просто взял цифры с потолка, потому как в 20х20х10мм не реально затолкать все компоненты устройства, а побольше размер нужен что бы разместить и сопутствующие модули и аккумулятор, а лучше посмотрите на реальные размеры у автора) и вуаля:
*предыдущие вопросы для нейросети я взял из вашего прошлого комментария, один в один и просто изменил размеры корпуса.
А ещё один момент, у автора был модуль не esp32-c3, а esp2*. У него энергопотребление ещё меньше в активном режиме. Я его учёл в расчётах, а вот вы решили сделать свои собственные, что бы доказать свою правоту.
И вот ответ:
Если размер в миллиметрах (30х30х50 мм)
Площадь стенок увеличилась почти в 5 раз по сравнению с прошлым корпусом, поэтому тепло рассеивается еще эффективнее.
Минимальный нагрев (хороший теплообмен): 0,19 °C.
Средний нагрев (обычные условия): 0,28 °C.
Максимальный нагрев (глухой пластиковый бокс): 0,56 °C.
Это для датчика температуры даже не погрешность... На данные не влияет. Даже 2-3 градуса - это не проблема. Задача устройства - измерить влажность и оповестить о поливе. Не знаю, зачем вы открыли дискуссию по поводу температуры.
Видимо вы ещё слишком молоды, что бы признать тот факт, что вы можете ошибаться, поэтому стоите на своём, рассказывая "как космические корабли бороздят просторы большого театра"
Удачи в ваших проектах. В мире ещё много умных людей и в попытке доказать им что вы один гений, они пройдут мимо вас и вы в конце концов докажите что правы, но тому, кто в этом ничего не понимает.
Ну хорошо, только именно вы и спорите, что будет нагрев и он повлияет на изменение температуры. Начнём с гугла в режиме ИИ:
Запрос: включение esp32 на 6 секунд, каждые 5 минут. Насколько поднимется температура в закрытом корпусе?
Ответ:
При таком режиме работы (6 секунд бодрствования каждые 5 минут) в закрытом корпусе температура поднимется всего на 0,1–0,3 °C выше температуры окружающего воздуха. Вы совершенно не заметите этот нагрев, и он никак не повлияет на работу электроники.
Почему нагрев будет ничтожным?
Микроскопическая средняя мощность: Чип работает всего 2% времени (6 секунд из 300). Средняя мощность, выделяемая ESP32 за 5 минут, составит около 0,01 Вт (10 милливатт). Такое количество тепла физически не способно нагреть закрытый корпус.
Огромное время на охлаждение: За 4 минуты и 54 секунды глубокого сна плата успевает полностью остыть до температуры воздуха внутри корпуса.
Уточнение: Сделай такие расчёты для следующих чипов: Esp32-s3, esp32-c3, esp-02s и выведи коротко
Ответ:
При цикле 6 секунд работы каждые 5 минут все три чипа выделяют ничтожно мало тепла, а средний нагрев воздуха внутри закрытого корпуса составит менее 0,3 °C.
Сравнительный расчет для чипов (при питании 3.3 В)
ESP32-S3:
Средняя мощность: 0,0073 Вт
Нагрев корпуса: ~ 0,29 °C
ESP32-C3:
Средняя мощность: 0,0056 Вт
Нагрев корпуса: ~ 0,23 °C
ESP-02S (ESP8266):
Средняя мощность: 0,0053 Вт
Нагрев корпуса: ~ 0,21 °C
И вот тот самый случай, когда я не верю на слово и по вашей рекомендации спросил у гугла. Гугл разорвал вас.
Это он ещё посчитал полную мощность каждого модуля, а я знаю, что за период бодрствования он менее чем 5% времени времени будет находиться в режиме передачи, а все остальное время будет в среднем и низком режиме потребления. И вот вам подтверждение от гугла (вам уже не доверяю):
Точный перерасчет нагрева воздуха с учетом импульса
Поскольку режим максимальной мощности длится всего 0,2 секунды из 300 секунд общего цикла (0.06% времени), его вклад в общий нагрев воздуха ничтожен. Основное тепло выделяется не при передаче, а во время долгого ожидания подключения к роутеру (4 секунды при токе ~90 мА).
С учетом этого реальная средняя тепловая мощность и нагрев воздуха будут еще ниже, чем предполагалось ранее:
ESP32-S3: Максимальная мощность активна ~0,2 сек. Нагрев воздуха в корпусе: ~ 0,18 °C
ESP32-C3: Максимальная мощность активна ~0,15 сек. Нагрев воздуха в корпусе: ~ 0,14 °C
ESP-02S: Максимальная мощность активна ~0,25 сек. Нагрев воздуха в корпусе: ~ 0,13 °C
Так что извините, ваши доводы и аргументы - не принимаются.
А зачем такие непонятные действия делать? И потом коммутировать перед началом записи? Типа дополнительная емкость, ну тогда нужно перед ними, на линии питания диод ставить, что бы разряд шёл только с схему, а не на другие конденсаторы и стабилизаторы (если они там будут).
Я что-то похожее делал для бистабильно го реле, что бы отключать его, если пропало питание. Они же без тока не переключаться обратно, поэтому дополнительное микрореле ставил и коммутировать его так, что бы заряженные конденсаторы отрабатывали на отключающие катушки. Вам можно сделать аналогично. Коммутация конденсатора в момент отключения питания. Реле подключено на самом входе без конденсатор в, потом диод, что бы конденсаторы не удерживали катушку реле, за диодом конденсатор базовый и следом подключаемый.
Посмотрите комментарий внизу, решение очень простое.
А ещё, самая большая проблема в том, что ваше устройство никуда данные не передаёт, ни на сервер, ни в систему умного дома, просто хранит их у себя и все. При этом вы ежесекундно считываете данные, а отображает только последние из буфера. Зачем? Почему? Какова цель? Ну хотя тогда сравнивайте текущие с предыдущим и записывайте только те, которые изменились и для корректной метки времени обязательно нужны часы типа DS3231. Потому что после перезагрузки, у вас метка времени будет кривой и она будет повторяться в вашем файле. Логгирование всегда привязано к реальному времени или к порядковому номеру, если время не важно. У вас ни того ни другого, просто таймер millis / 60000. После перезагрузки МК он обнуляется.
В чем смысл тогда логгирования. Это же просто сбор данных без возможности дальнейшего использования. А потом вы что, возьмёте SD карту и с ней пойдёте к ПК переносить инфу? А куда? В Excel? Так сейчас не 2000 год, а 2026, и у вас микроконтроллер с Wi-Fi, Bluetooth, а это такие возможности!
А SD карта, в таком режиме сдохнет через 1-3 месяца, китайская за 1,5 - 2 недели.
Это тоже проходили и убивали карты.
Вместо sd карты можно установить FRAM CY15B102J, на 2 МБит (512КБайт), этого вполне достаточно что бы хранить там метку времени на 32 бита и 3 числа типа float в количестве 16384 записи. Даже если метеостанция будет каждые 10 минут снимать показания (а это слишком много), то этого объема в 16 384 записи вам хватит на 113 дней непрерывной автономной работы без перезаписи!
Но я все таки надеюсь, что и опрос будет реже и вы все таки не будете просто хранить данные на метеостанция за весь период, а будете передавать их на хост и очищать память. А запись будет только в том случае, если нет связи с хостом, иначе непонятно, зачем вообще их хранить на метеостанции. Если для прикола только.
А теперь преимуществ FRAM-памяти (CY15B102J) перед SD-картой при записи малых объемов данных (метка времени и три числа float):
В 100 раз выше скорость работы. Запись одной пачки данных во FRAM занимает всего 0,17–0,4 миллисекунды, тогда как на SD-карту текстовая строчка пишется от 10 до 40 миллисекунд из-за долгой инициализации и работы файловой системы FAT32.
В 500 раз ниже потребление тока. В момент физической записи чип FRAM потребляет около 150 микроампер, в то время как SD-карта при перезаписи флеш-массива требует от 50 до 100 миллиампер.
Практически бесконечный ресурс. FRAM выдерживает до 100 триллионов циклов перезаписи. SD-карта при постоянной циклической дозаписи мелких строчек выйдет из строя в сотни раз быстрее из-за ограниченного ресурса ячеек флеш-памяти. А дешёвая карта очень быстро, как это бывало на Raspberry Pi.
Отсутствие лишних операций с памятью. Во FRAM можно записать ровно 16–20 байт данных. На SD-карту невозможно записать блок меньше одного сектора (512 байт), поэтому системе приходится каждый раз считывать, модифицировать и перезаписывать сотни лишних байт.
Высокая надежность при внезапном отключении питания. Во FRAM данные сохраняются физически в момент отправки последнего бита. Если питание пропадет при записи на SD-карту, файловая система FAT32 может полностью разрушиться, что приведет к потере всего текстового файла.
Экономия памяти микроконтроллера. Для работы с FRAM используется простой и легкий код передачи данных по шине I2C. Для SD-карты требуется подключать тяжеловесные библиотеки для работы с файловой системой, которые занимают много оперативной и флеш-памяти контроллера.
Просто были подобные проекты и там этих граблей было так много, и что мы только не использовали. А вот вариант с FRAM стал спасением.
Это как? Заряжать конденсаторы непосредственно перед записью, когда они уже на линии питания находятся? Ничего не смущает? Они там просто будут находиться всегда заряженные на 100%.
Факты в студию. Бла бла бла не принимаются. Я вам код программы отдал, смотрите и разбирайтесь. Это и есть логгирование, если вы понимаете написанный код. Тем более на уровне МК, в моменты начала и завершения операций. Точнее не придумаешь.
Рот сначала помойте, и глаза,потом посмотрите на мой код программы, потом ещё 2 раза, потому ч то с первого не поймёте (вижу что вы и с второго раза порой не понимаете),ну а когда сможете разобраться, подумайте на своими словами. И вспомните эту фразу: Вы не самый умный человек на этой земле. Вы что-то знаете и что-то понимаете, но в мире есть люди умнее и это нормально. У них стоит учиться как делать правильно.
А ваш "нормальный" лог, без кода и объяснений можете напечатать на рулоне туалетной бумаги. Что с ним делать дальше, рассказывать не буду.
Статика для любого ip устройства, это нормально, тем более если мы хотим экономить на расход аккумулятора, а утопия переводить все барахло на динамику, контролировать сложнее и тем более, если оно всегда рядом и не болтается как смартфон. Вы в своём ip поле можете сделать столько миллионов адресов, сколько вздумается, и ещё это все в одну подсесть засунуть.
Для каждого случая стоит предусматривает самые оптимальные варианты. Если статика даст экономию времени в 1 секунду, то это отлично, можно использовать. Если нет необходимости заморачиваться, пусть будет динамика.
Канал можете привязать, не проблема. Главное покажите это, без "слюней".
Так сделайте и улучшите хоть что нибудь и будет вам натуралка, а не синтетика. В чем прикол воздух сотрясать?
С вашим мнением никто не спорит, оно навсегда останется вашим. Речь идёт о том, что вы стремитесь натянуть субъективные вещи на объективные. Свой опыт на чужой, считая свой - эталонным.
Вот если бы вы сказали так: У меня, нагрев был больше, в пределах 1-1.5 градусов в моем корпусе и исполнении, а время передачи составило от 5 до 6 секунд.
Да вопросов бы не было! У вас получились такие результаты, другой чип, другой корпус, другой код и другие мозги. И это нормально!
Но вы же решили сказать, что что-то будет влиять очень сильно, не зная фактов автора статьи, а я включился в дебаты, потому как для меня эти цифры ну сверх неразумные. А ещё это выглядит так: вы умны, а все идиоты, потому что думают не так как вы.
Если логи, то у вас нормальные, а у остальных - непонятная штука, как то там посчитанная. Вы считаете это нормальным и хотите что бы к вашему мнению прислушивались? Извините, но нет! Как вы к людям, так и они к вам... Предполагаю, что с вами просто никто и никогда не спорил и вы посчитали это своей силой, но это было так: он несёт свою хрень, ну да ладно пусть несёт, главное что бы работал нормально и по углам не гадил.
Есть более изящные варианты:
1) кремниевый диод с потерей 06-07В, при полном зарядке 4.2В снизит напряжение до 3.5В,а при подсаженной банке до 3х Вольт. Вполне рабочее решение.
2) поставить AP2112K-3.3 стабилизатор с управлением сна. И с входа на выход посадить как раз кремниевый диод. В режиме сна, он потребляет 0мА а сном управляет микроконтроллер.
Если напряжение аккума упало до 3,5 вольт, то для пробуждения ему хватит и 2.8В а потом запустится стабилизатор и отдаст 3,3 Вольта и запрет диод.
И тот и другой варианты рабочие, ну и диод и AP2112K-3.3 пропускают нормальные токи (AP2112K-3.3 до 200мА, кремниевый диод поболее) времени на нагрев диода не будет, потому как микроконтроллер пробуждается 30-50мсек (зависит от МК) и после включения основной ток пойдёт через стабилизатор.
3) Можно оставить и 1 стабилизатор, но потребление в холостую 55мкА, многовато и если мы максимально экономим аккум, то варианты 1 и 2.
И таким образом можно уменьшить габариты устройства, используя прямоугольный и плоский аккумулятор.
Да, ваши размеры - это как сову на глобус натянуть, можно, но сложно. Только я не понимаю, вы просто хотели туда модуль один засунуть и просто греть его? А в чем смысл? Мы здесь про изделие говорим, вполне конкретное, поэтому я открыл datasheet на esp32 и посмотрел размеры модулей, учёл те платы, которые автор указал в схеме + аккумулятор и размеры получились адекватные, если немного с запасом, то уж нам старикам простительно, мы всегда проектируем с запасом, с 80-х годов, ну вот так нас научили!
Такое впечатление что вы суть темы даже не понимаете, просто лижь бы ляпнуть и важно, что бы последнее слово осталось за вами. Представляю как вам сложно с образованными людьми живётся...
А кто тут скандалит? Я фактами расписал, на ваши аргументы, а вам то нечего сказать, приходится просто защищаться, хоть на вас никто и не нападал.
А что касается времени, то предполагаю что у вас его больше и точно пройдёт, надеюсь перестанете голословить и начнёте понимать мир и реальность, а нам старикам внуков воспитывать и вас молодых учить останется. Пропадёте ведь без нас.
Плохие времена рожают сильных людей, сильные люди создают хорошие времена, хорошие времена рожают слабых людей, слабые люди создают плохие времена.
Мне жаль, что плохие времена уже не за горизонтом.
Понимаю тебя, девочка, ты и другого не умеешь. Кроме как критиковать, без фактов, просто на своём т.н. "опыте".
Остаётся только язвить и укалывать фразами, а ведь сами начали пустой разговор, стремясь выехать за счёт чего - непонятно. Видимо гонора и самоуверенность, хейта. Ну что же, удачи вам. Я знаю свою правду, вы генерируете свою, нас не по пути.
Вы снова не внимательны, я же сказал, что взял от фонаря, но в мои размеры платы умещаются.
Вот вам размеры модулей и коробки 20х20х10 мм. (обычно, инженеры указывают размеры в миллиметрах, если вы не в курсе)
Ни один из модулей не помещается в указанные вам размеры.
Делаем вывод, вы не инженер, не умеете пользоваться документацией и datasheet-ами на модули, компоненты, радиокомпоненты. Следовательно ваши расчеты изначально неверны и обречены на провал а изделия, если они вообще работают, с высокой долей вероятности будут собраны и рассчитаны некорректно, что повлечет за собой недолговечное время работы, ошибки и выход из строя.
Вы не умеете держать удар, а в бой ввязываетесь перв-ый(ая).
Теперь факты проверены, смотрите комментарий развернутый. От вас фактов НЕТ!
А вот что говорит реальный мир, не ваш, а именно РЕАЛЬНЫЙ!:
Что было сделано (да я заморочился, потому что терпеть не могу выскочек, которые кроме бла-бла ничего не делают):
1) Взят модуль ESP32-C6 Super Mini (под рукой не оказалось ESP32-C3)
2) Его USBSerial не работает нормально, поэтому тупо сел на сериал шину UART 3.3В (Программатор тоже на 3.3В уровни), Serial просто контролю монитором на другом порту.
Скрытый текст
3) Точка доступа - просто телефон на раздаче Wi-Fi 2.4GHz
4) Программный код под скрытым текстом.
Скрытый текст
5) Все сделал в Arduino IDE (так быстрее и проще), на скорость никак не влияет, кроме того, что бы написать код.
Далее, что бы не слыть некорректным человеком и не врать о том, что отправленный пакет дошел:
Ответ монитора UDP, который принял пакет и показал, от кого он, следовательно пакет вышел из ESP32-C6 и дошел до адресата за указанное время.
И подключенные устройства на телефоне (подтверждение того что устройства присутствуют в сети с конкретными адресами):
Не стал загонять его в глубокий сон. Это же нужно для демонстрации "умному и всезнающему" человеку, а не для реальной работы здесь и сейчас.
А вот и результаты (не нейронки):
Они очень близки к тому, что предоставила нейронка (Она там сильно округлила и взяла с запасом). И уж очень сильно отличаются от "теории очень умного и всезнающего" человека, который оперирует просто словами, а не фактами типа: 3-4 секунды в среднем.
Реальность еще интереснее.
И так, сделал 5 итераций подряд с разными интервалами и полным аппаратным ребутом (подключение с нуля):
1 запуск - Смотри скрытый текст ниже
Скрытый текст
2 запуск - Смотри скрытый текст ниже
Скрытый текст
3 запуск - Смотри скрытый текст ниже
Скрытый текст
4 запуск - Смотри скрытый текст ниже
Скрытый текст
5 запуск - Смотри скрытый текст ниже
Скрытый текст
Среднее время за 5 повторов составляет 1549,27 мс (примерно 1,55 секунды).
Это включая получение IP адреса и передачу данных. При статическом IP, время сократится.
И отдельно, я сделал пакет объемом 4096 байт и вот его итерация:
Скрытый текст
Вот что он отправлял:
Скрытый текст
А вот что услышал UDP на ноуте у меня:
Скрытый текст
Объем пакета передачи не сильно влияет на задержку.
Отличие 100 байт и 1400 байт, всего 424 Микросекунды!
А теперь вишенка на торте:
Статический IP адрес (), полный ребут, и пакет 1400 байт. Смотрим и удивляемся:
Всего 338 мс. при статическом IP. Вот и все. Нет там ни 3х ни 4х секунд. Вас обманули! )))))))))))
Что вы теперь скажете в свое оправдание? Вот я практически, в реальном мире, довел полный цикл передачи данных аж до 0,338 секунды (338 мс.) с передачей не 10-20 байт, а 1400 байт.
Теперь считаем тепловыделение этого модуля.
При работе 338 миллисекунд каждые 5 минут (средняя тепловая мощность всего 0,00048 Вт) значения будут следующими:
Вариант 1: Коробка 2 х 2 х 1 см (объем 4 см³)
Это экстремально маленький корпус (чуть больше самого модуля ESP32). Воздуха внутри очень мало, поэтому он нагреется чуть сильнее.
Нагрев воздуха внутри корпуса: на ~0,028 °C
Локальный нагрев платы в закрытом объеме: на ~0,09 °C
Вариант 2: Коробка 3 х 3 х 5 см (объем 45 см³)
Объем этого корпуса больше в 11 раз, а площадь стенок для рассеивания тепла значительно выше.
Нагрев воздуха внутри корпуса: на ~0,004 °C (абсолютно незаметно)
Локальный нагрев платы в замкнутом объеме: на ~0,01 °C
Как вам такие цифры? Реальность или снова скажете - вру.
Ну а что бы вообще все с доказательной базой - вот программный код.
Скрытый текст
Вывод: уважаемый, примите тот факт, что вы были не правы, может потому что сами не знаете, что делаете ))))
P.S. Я более чем уверен, что "очень умный и всезнающий" человек обязательно скажет свое "умное слово", но теперь ВАШ ХОД и только такой, что бы это было действительно фактами, а не ваши очередные "я разрабатывал и было вот так, поэтому знаю", "5 лет делаю проекты", "...знаю...", "...вы не отправляли пакеты MQTT...".
Все другое в виде слов идет лесом и полем.
Блин, комментарий реально на статью тянет )))))
Я отрисую эти размеры корпуса и размещу в нем esp32-c3, добавлю плату и вернусь, покажу вам, что это за размеры. Впечатление такое, что вы в игрушечном мире живёте, для вас влияние температуры в 1,5 (вами посчитанных градуса) это ужас как много, корпус таких размеров, что некуда размещать компоненты.
Последнее даже комментировать не буду, бесполезно...
Это вопрос или утверждение?
Если утверждение, то оно необоснованно, если вопрос, то мой ответ: отправлял и не только mqtt. И гораздо большим объёмом.
Вы сами то делали замеры времени между операциям?
Я вот специально этим заморачиваться и выяснял сколько это по времени, потому как мне важно было уложиться во времени.
И нейронка мне выдала примерно такие-же результаты:
Глубокий сон: 294 сек, 0,005 мА, 0,00002 Вт.
Включение процессора: 0,07 сек, 30 мА, 0,1 Вт.
Включение Wi-Fi: 0,02 сек, 90 мА, 0,3 Вт.
Подключение к роутеру: 1,0 сек, 150 мА, 0,5 Вт.
Получение IP (DHCP): 1,0 сек, 90 мА, 0,3 Вт.
Сборка пакета 100 байт: 0,002 sek, 80 мА, 0,26 Вт.
Передача в эфир (Пик): 0,0005 сек, 335 мА, 1,1 Вт.
Ожидание ответа сети: 0,003 сек, 85 мА, 0,28 Вт.
Подготовка ко сну: 0,004 сек, 15 мА, 0,05 Вт.
Я даже пакет взял 100 байт!
Отправить 10 - 20 байт и закрыть соединение, на это и 0.05 секунды более чем достаточно.
Очень интересный корпус! 20х20х10мм, туда даже модуль не поместится, не считая обвязки. А мы говорим про конкретное устройство, которое сделал автор и там не 20х20х10 мм корпус. Вы сейчас тупо за уши притягиваете к своим ответам. Возьмите корпус побольше, адекватный 30х30х50 (я просто взял цифры с потолка, потому как в 20х20х10мм не реально затолкать все компоненты устройства, а побольше размер нужен что бы разместить и сопутствующие модули и аккумулятор, а лучше посмотрите на реальные размеры у автора) и вуаля:
*предыдущие вопросы для нейросети я взял из вашего прошлого комментария, один в один и просто изменил размеры корпуса.
А ещё один момент, у автора был модуль не esp32-c3, а esp2*. У него энергопотребление ещё меньше в активном режиме. Я его учёл в расчётах, а вот вы решили сделать свои собственные, что бы доказать свою правоту.
И вот ответ:
Если размер в миллиметрах (30х30х50 мм)
Площадь стенок увеличилась почти в 5 раз по сравнению с прошлым корпусом, поэтому тепло рассеивается еще эффективнее.
Минимальный нагрев (хороший теплообмен): 0,19 °C.
Средний нагрев (обычные условия): 0,28 °C.
Максимальный нагрев (глухой пластиковый бокс): 0,56 °C.
Это для датчика температуры даже не погрешность... На данные не влияет. Даже 2-3 градуса - это не проблема. Задача устройства - измерить влажность и оповестить о поливе. Не знаю, зачем вы открыли дискуссию по поводу температуры.
Видимо вы ещё слишком молоды, что бы признать тот факт, что вы можете ошибаться, поэтому стоите на своём, рассказывая "как космические корабли бороздят просторы большого театра"
Удачи в ваших проектах. В мире ещё много умных людей и в попытке доказать им что вы один гений, они пройдут мимо вас и вы в конце концов докажите что правы, но тому, кто в этом ничего не понимает.
Вы немного не внимательны. Я не писал и не пишу статьи. И у меня нет предыдущего монитора воздуха.
Ну хорошо, только именно вы и спорите, что будет нагрев и он повлияет на изменение температуры. Начнём с гугла в режиме ИИ:
Запрос: включение esp32 на 6 секунд, каждые 5 минут. Насколько поднимется температура в закрытом корпусе?
Ответ:
При таком режиме работы (6 секунд бодрствования каждые 5 минут) в закрытом корпусе температура поднимется всего на 0,1–0,3 °C выше температуры окружающего воздуха. Вы совершенно не заметите этот нагрев, и он никак не повлияет на работу электроники.
Почему нагрев будет ничтожным?
Микроскопическая средняя мощность: Чип работает всего 2% времени (6 секунд из 300). Средняя мощность, выделяемая ESP32 за 5 минут, составит около 0,01 Вт (10 милливатт). Такое количество тепла физически не способно нагреть закрытый корпус.
Огромное время на охлаждение: За 4 минуты и 54 секунды глубокого сна плата успевает полностью остыть до температуры воздуха внутри корпуса.
Уточнение: Сделай такие расчёты для следующих чипов: Esp32-s3, esp32-c3, esp-02s и выведи коротко
Ответ:
При цикле 6 секунд работы каждые 5 минут все три чипа выделяют ничтожно мало тепла, а средний нагрев воздуха внутри закрытого корпуса составит менее 0,3 °C.
Сравнительный расчет для чипов (при питании 3.3 В)
ESP32-S3:
Средняя мощность: 0,0073 Вт
Нагрев корпуса: ~ 0,29 °C
ESP32-C3:
Средняя мощность: 0,0056 Вт
Нагрев корпуса: ~ 0,23 °C
ESP-02S (ESP8266):
Средняя мощность: 0,0053 Вт
Нагрев корпуса: ~ 0,21 °C
И вот тот самый случай, когда я не верю на слово и по вашей рекомендации спросил у гугла. Гугл разорвал вас.
Это он ещё посчитал полную мощность каждого модуля, а я знаю, что за период бодрствования он менее чем 5% времени времени будет находиться в режиме передачи, а все остальное время будет в среднем и низком режиме потребления. И вот вам подтверждение от гугла (вам уже не доверяю):
Точный перерасчет нагрева воздуха с учетом импульса
Поскольку режим максимальной мощности длится всего 0,2 секунды из 300 секунд общего цикла (0.06% времени), его вклад в общий нагрев воздуха ничтожен. Основное тепло выделяется не при передаче, а во время долгого ожидания подключения к роутеру (4 секунды при токе ~90 мА).
С учетом этого реальная средняя тепловая мощность и нагрев воздуха будут еще ниже, чем предполагалось ранее:
ESP32-S3: Максимальная мощность активна ~0,2 сек. Нагрев воздуха в корпусе: ~ 0,18 °C
ESP32-C3: Максимальная мощность активна ~0,15 сек. Нагрев воздуха в корпусе: ~ 0,14 °C
ESP-02S: Максимальная мощность активна ~0,25 сек. Нагрев воздуха в корпусе: ~ 0,13 °C
Так что извините, ваши доводы и аргументы - не принимаются.