esp32c3 - Мутная работа с WiFi

[pvvx]

есть ограничения на мктт-ехплорере, но точно не помню, то ли 500 на топик, то ли 5000 на топик, то ли 5000 на все
вообще, бывают какие-то сбои на мктт-брокере (ну или еще вокруг него):

MQTT работает т через TCP-IP. Стоит проверить лог TCP-IP, к примеру, в Wireshark.

Если у вас ESP засыпает и снова соединяется, тогда номер порта для соединения выбирается по псевдо-рандом, а IP фиксирован. И номер порта может совпадать с прошлым закрытым соединением.

По стандарту в TCP-IP, сторона закрывшая соединение, должна выдержать 120 секунд для всех следующих запросов соединений по использованным IP и порту адресата и получателя. В этот период всем поступившим пакетам типично дается команда закрытия соединения (break)...

ИИ: Интервал TIME_WAIT — это обязательное состояние TCP-соединения.
Оно гарантирует, что все потерянные пакеты дойдут до адресата, и предотвращает смешивание старых и новых данных при повторном использовании тех же IP-адресов и портов.

В итоге некоторые соединения от EPS будут откинуты сервером и промежуточным сетевым оборудованием. При несоблюдении данного стандарта (TIME_WAIT) будут происходить проблемы по цепочке сетевых устройств (роутеров, NAT и т.д.)…

 

[pvvx]

вообще, бывают какие-то сбои на мктт-брокере (ну или еще вокруг него)

Спецификация RFC подразумевает, что локальный сокет должен оставаться активным в состоянии TIME_WAIT в течении 2xMSL.
MSL - это максимальное время жизни сегмента. RFC задает MSL как 120 секунд. Т.е. стандартное время ожидания в TIME_WAIT равно 4 минутам.
Всякие ухищрения и сокращения этого интервала = уход от стандарта TCP/IP на отсебятенный стандрат (на урезанную реализацию TCP в ESP).
Так что проверяйте, что там творится в сети у вашего MQTT сервера…
Или не делайте разрывов TCP соединений и всяких снов в ESP используя keepalive соединение...

 

[pvvx]

у меня контроллер сначала связывается с брокером, лезет в ветку с мак-адресами, по мак-адресу получает имя и уже под этим именем публикует данные. так вот, на периоде пары-тройки суток, это порядка тысячи коннектов, контроллер не получает имени и публикует несколько сообщений безымянными, просто под своим мак-адресом. мак-адреса и имена прописаны в брокере как сообщения с ретейн-аттрибутом

Это и похоже на повторное использование соединения с закрытыми IP/портами прошлого соединения находящегося в TIME_WAIT, если на каждый запрос на MQTT создаете новое TCP соединение. Первый запрос отбрасывается по TIME_WAIT, а следующий уже идет с новым номером порта…

 

[enjoynering]

простой способ решить проблему со связью на esp32-c3 - это просто развернуть антенну (смотри картинку).

у меня другая беда - чип сильно греется согласно встроенному датчику (не знаю на сколько он точный), аж до 85с при активном gpio нагруженном на оптопару через резистор на 680ом. в простое температура падает до 63c.

ну и мои первые впечатления о eps32-c3. Радиомодуль у чипа намного лучше, чем у ESP8266 - он более чувствительный. Однако сам чип такой же капризный в плане кода, как и 8266: здесь всего одно процессорное ядро (а не два, как у ESP32), да ещё и на RTOS с arduino костылями. Стоит выполнить код не в той последовательности и всё... намертво виснем. Ну и греется он прилично (если верить внутреннему датчику).

пы.сы. ESP8266 умер - последний релиз arduino framework для ESP8266 вышел в 2023 году и с тех пор не обновлялся.

 

[pvvx]

Ну и греется он прилично (если верить внутреннему датчику).

Обзор от ИИ:

Микросхемы серии ESP32-C3 (в корпусе QFN32 размером 5 × 5 мм) обладают сопротивлением теплопередачи от перехода к окружающей среде (\(\theta _{JA}\)Примерно от 40 до 50 °C/Вт, в зависимости от конструкции вашей печатной платы. Для надлежащего рассеивания тепла необходима соответствующая заземляющая плоскость с тепловыми переходными отверстиями.

Основные тепловые характеристики

Тепловое сопротивление (переход-окружающая среда)\(\theta _{JA}\)): ~ 45°C/Вт (Значения могут варьироваться от 40°C/Вт до 50°C/Вт в зависимости от степени покрытия медью печатной платы).
Тепловое сопротивление (переход-корпус)\(\theta _{JC}\)): ~ 10–15 °C/Вт.
Рабочая температура окружающей среды: Доступны стандартная (-40 до +85°C) и расширенная (-40 до +105°C) версии.
Максимальная температура перехода (\(T_{j}\)): 125°C.


По даташиту при работе WiFi на передачу пиковые токи более 0.335A (+ сам CPU и GPIO). Это выделение тепла на более чем 1 Вт.
И если окружающая среда +25С печатной платы (чип на плате без LDO), то на встроенном датчике температуры будет за +70С.

 

[enjoynering]

Ну тогда понятно. Спасибо за разяснения.

 

[nikolz]

Обзор от ИИ:
По даташиту при работе WiFi на передачу пиковые токи более 0.335A (+ сам CPU и GPIO). Это выделение тепла на более чем 1 Вт.
И если окружающая среда +25С печатной платы (чип на плате без LDO), то на встроенном датчике температуры будет за +70С.

если правильно понял вопрос,
то проблема не WiFi а при работе с GPIO
------------------
ИИ отвечает:
Нагрев ESP32-C3 до 85°C — это высокая, но допустимая температура для чипа, хотя она и находится у верхней границы нормы. Проблема, судя по вашему описанию, скорее всего, связана с перегрузкой вывода GPIO из-за слишком высокого тока.
Вот основные факты и возможные причины.
Допустимая рабочая температура
Для вашего микроконтроллера 85°C — это не критично, но это максимальная рабочая температура для многих модулей . Чип может работать до 105°C (некоторые версии), а вот плата XIAO ESP32C3 рассчитана на -40°C ~ 85°C .

• Погрешность датчика: Встроенный датчик может иметь погрешность до ±3°C в диапазоне 50–125°C .
• Важно: Датчик измеряет температуру кристалла, которая всегда выше температуры окружающей среды и зависит от нагрузки на ядро и ввод-вывод .

Перегрузка GPIO
Ваше описание (нагрев при активном GPIO, остывание в простое) указывает на возможную перегрузку по току. Выводы ESP32-C3 не предназначены для питания мощной нагрузки напрямую .

1. Максимальный ток: Максимальный ток, который может выдать один вывод, составляет 40 мА при максимальной настройке драйвера .
2. Настройка драйвера: Сила тока вывода настраивается программно. Значения могут быть такими: 0 (~5 мА), 1 (~10 мА), 2 (~20 мА — по умолчанию), 3 (~40 мА) .
3. Ваш резистор 680 Ом: При питании 3.3 В через резистор 680 Ом ток составит около 4.8 мА (без учета падения напряжения на оптопаре). Это кажется безопасным, но если вывод сконфигурирован на 40 мА, а оптопара потребляет больше, это создает избыточную нагрузку.

Что можно проверить и исправить

1. Проверьте реальный ток: Измерьте ток, потребляемый цепью GPIO + резистор + оптопара. Убедитесь, что он не превышает 10-20 мА для спокойной работы.
2. Уменьшите ток: Увеличьте номинал резистора (например, до 1-2 кОм), чтобы снизить ток и нагрев.
3. Настройте драйвер вывода: Если вы используете Arduino, попробуйте явно задать меньшую силу тока вывода или убедитесь, что она не установлена на максимум (40 мА).
4. Используйте внешний ключ: Для надежности лучше управлять оптопарой через внешний NPN-транзистор или MOSFET, чтобы микроконтроллер только подавал сигнал, а не обеспечивал мощность.
5. Проверьте питание: Убедитесь, что микроконтроллер получает стабильное напряжение 3.3 В от источника, способного отдать достаточный ток . Слабый регулятор на плате (для XIAO это 200 мА) может греться сам и греть чип .

Если вы используете плату Seeed Studio XIAO ESP32C3, помните, что она очень компактная, что ухудшает отвод тепла, и нагрев может быть более заметным .
Если уточните, какой именно GPIO вы используете, схему подключения оптопары и какой код задействован, возможно, получится дать более точный совет.

 

[pvvx]

если правильно понял вопрос,
то проблема не WiFi а при работе с GPIO

Нет, всё не правильно поняли

аж до 85с при активном gpio нагруженном на оптопару через резистор на 680ом. в простое температура падает до 63c.

Обзор от ИИ: Прямое падение напряжения на светодиоде (излучателе) внутри оптопары обычно составляет от 1.0 В до 1.5 В
Считаем: (3.3В-1В)/680Ом = 0.00338A, т.е. в пределе 3.4 мА. Это мощность от источника питания 3.3В всего 0.011154 Вт (11 мВт)
Датчик температуры в чипе не калиброван. При работе CPU без WiFi (жрет 30 мА) ES32-C3 выделяет не более 3.3В*0.03A=0.099Вт
Т.е. температура элемента измерения будет 25C + 0.1Вт*40С/Вт = +29С.

При включенном и не активном WiFi жручка уже 80 мА -> 3.3В*0.08A=0.264Вт
Т.е. температура элемента измерения будет 25C + 0.264Вт*40С/Вт = +35.6С.

При активной передаче по WiFi (+21дБм) жручка > 400 мА -> 3.3В*0.4A=1.32Вт
Т.е. температура элемента измерения будет 25C + 1.32Вт*40С/Вт = +77.8С.

 

[pvvx]

Эти 40..45С/Вт подтверждаются в даташите по параметрам рабочей температуры:


105+45 = 150C - предел до деградации кристалла.

 

[nikolz]

Эти 40..45С/Вт подтверждаются в даташите по параметрам рабочей температуры:
105+45 = 150C - предел до деградации кристалла.

в вашей методике расчета есть ошибка
Вы считаете мощность, а нагрев - создается энергией.
т е ваш рачет :
При активной передаче по WiFi (+21дБм) жручка > 400 мА -> 3.3В*0.4A=1.32Вт
Т.е. температура элемента измерения будет 25C + 1.32Вт*40С/Вт = +77.8С.
не учитывает что ток 400 мА это импульс длительностью миллисекунды. а тепловое сопротивление применяется для средней мощности т е когда поток энергии стационарен. Иначе это расчет в попугаях.

 

[pvvx]

в вашей методике расчета есть ошибка
Вы считаете мощность, а нагрев - создается энергией.
т е ваш рачет :
При активной передаче по WiFi (+21дБм) жручка > 400 мА -> 3.3В*0.4A=1.32Вт
Т.е. температура элемента измерения будет 25C + 1.32Вт*40С/Вт = +77.8С.
не учитывает что ток 400 мА это импульс длительностью миллисекунды. а тепловое сопротивление применяется для средней мощности т е когда поток энергии стационарен. Иначе это расчет в попугаях.

Я считаю нагрев кристалла, а не температуру корпуса или печатной платы...

 

[uzzzer]

вопчем.
нашлось несколько времени, немного поковырялся с платкой. все та же история: целый день молчала (без присмотра), вечером в моих руках прям ожила, работает без сбоев, лепота. но меня уже не проведешь, видел и такое. и точно, через часик все встало колом, ну ваще не соединяется. меня малость закусило. давай разбираться. при этом пришли новые-старые платки, сине-желтые, как я их для себя называю, те, что кажутся более приличными. и первая же попавшаяся - работает стабильно. лежала на столе и каждую минуту нормально отрабатывала: по умолчанию период сна стоит 1800 секунд, а с мктт она получает новое указание - 60с, т.е. если бы не законнектилась, то ушла бы спать на полчаса, а этого не было.

мысль была такая, уже ее встречал пару раз: плохой монтаж, кривые антенны, дикий КСВ, чип и греется, и захлебывается. почти все о потреблении и мощности сводят к засыпанию, но это не то. в результате нашелся метод для снижения мощности (да, фреймворка я не знаю, так бывает) - WiFi.setTxPower().
кой че написано вот тут: https://forum.arduino.cc/t/no-wifi-connect-with-esp32-c3-super-mini/1324046/10
там же заодно упоминается pin 21 issue
там же заодно и про поворот антенны говорится
там же заодно рассматриваются модули с красной антеннкой, на которые я изначально криво смотрел. выяснилось (совершенно неожиданно), что большая часть их на али - дешевая кривая подделка дешевой кривой китайской поделки. заодно узналось (с хабра), что LDO, на ней распаянный, обеспечивает 250мА, против паспортных 500мА.


в результате тупо установил мощность в 8.5дБм, завелось буквально все, что попалось под руку, и черно-красные модули, и сине-желтые (примеры во вложениях), в т.ч. один из первых сине-желтых, который почти никогда не коннектился. по ссылке предрекают, что на 8.5 сигнал не пробьет даже простую каменную стену. ну мож и не пробьет, но когда он вообще никак не работает, по-моему хуже. другие мощности не пробовал даже/пока.

по этажам не ходил, но затащил платку в специальный угол, куда 2.4ГГц очень плохо затекает, там телефоны, бывает, вифи теряют - сигнал упал с -40 до -60 (ну, +/-). а, вот даже до -70, но это я уже совсем в угол затолкал. хотя это к приемнику относится, но можно предположить, что и обратный путь к роутеру также тернист, но все худо-бедно работает
время бодрствования - около 4 сек. точнее от старта, до отправки последнего сообщения, скока потом на выключение тратит - хз. pvvx щас заругает, скажет, так жыть нельзя, все должно работать годами от 2032, но мне пофинг, тут чисто утилитарный сбор некоторых данных. заодно и нащщет жывучести попытаюсь понять.

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


самая тема - это fuxa! ))). свободная скада, на коленке делается кой-какой интерфейс, легко работает с мктт и прочей классикой. делать дикую связку для визуализации простеньких графиков на базе громоздких систем - точно не для этой задачки.

 

[enjoynering]

поудалял всякие задержки, которые

если вы пишете под arduino, то задержка нужна одна - в конце главного цикла loop(). справедливо как для esp8266, так и для esp32. подробности тут - https://elchupanibrei.livejournal.com/47610.html

пы.сы. я на esp32-c3 ставлю 11dBm, работает отлично.