چرا ارتباط ESP32 در محیط صنعتی قطع و وصل می‌شود؟ | از افت تغذیه و نویز EMI تا Beacon Timeout، Watchdog و بافرها

اگر با ESP32 کار کرده باشید، احتمالاً این صحنه برای شما آشناست: برد روی میز آزمایش ساعت‌ها درست کار می‌کند، اما بعد از نصب داخل دستگاه یا تابلو برق، ارتباطش نامنظم می‌شود؛ گاهی خودش برمی‌گردد و گاهی فقط با خاموش و روشن کردن دستگاه زنده می‌شود.

در یک پروژه صنعتی روی ارتباط Motherboard و برد رابط، همین اتفاق مسیر عیب‌یابی را از «حتماً باگ نرم‌افزاری است» به بررسی هم‌زمان Firmware، Hardware، Power، Noise و Timing برد. نتیجه روشن بود: چیزی که از بیرون شبیه قطع ارتباط دیده می‌شود، الزاماً مشکل شبکه نیست.

ممکن است ESP32 Reset شده باشد، Socket قبلی اعتبارش را از دست داده باشد، Buffer پر شده باشد یا تغذیه هنگام ارسال رادیویی افت کند. قبل از عوض کردن Router، Baud Rate یا معماری برنامه، باید سؤال درست را بپرسیم.

۱. قطع ارتباط را با Reset اشتباه نگیریم

اولین کاری که پیشنهاد می‌کنم، ثبت Boot Log و Reset Reason است. در ESP-IDF می‌توان با تابع esp_reset_reason() علت آخرین راه‌اندازی را خواند. اگر در Log پیام Brownout، Task Watchdog، Panic یا Guru Meditation می‌بینید، مسئله شما قبل از آن‌که «Wi-Fi» باشد، یک Reset سیستمی است.

وقتی ESP32 Reset می‌شود، ارتباط بی‌سیم، TCP Socket، MQTT Session و State داخلی برنامه از نو ساخته می‌شوند. از بیرون فقط چند ثانیه Offline شدن دیده می‌شود؛ اگر علت Reset ثبت نشود، ممکن است اشتباهی سراغ تنظیمات Access Point برویم.

• در هر Boot، Reset Reason، زمان روشن‌بودن دستگاه و حداقل Free Heap ثبت شود.
• Logها فقط روی Serial Monitor نمانند؛ برای محصول واقعی بهتر است شمارنده خطا در NVS، Flash یا سرور ذخیره شود.
• اگر Reset تصادفی است، قبل از هر تغییر نرم‌افزاری ریل 3.3V و پایه CHIP_PU بررسی شود.

۲. متهم شماره یک: تغذیه‌ای که روی مولتی‌متر کاملاً سالم است

ESP32 هنگام فعالیت رادیویی مصرف ثابتی ندارد. در لحظه ارسال Wi-Fi، جریان می‌تواند جهشی شود و اگر رگولاتور، مسیر PCB، کابل تغذیه یا خازن‌های محلی پاسخ مناسبی ندهند، ریل 3.3V برای زمان کوتاهی فرو می‌ریزد. این افت ممکن است آن‌قدر کوتاه باشد که مولتی‌متر عدد 3.3V را کاملاً عادی نشان دهد، اما Brownout Detector آن را ببیند و تراشه Reset شود.

راهنمای طراحی سخت‌افزار Espressif برای ESP32، منبع 3.3V با توان تأمین حداقل 500mA، خازن حداقل 10µF در ورودی اصلی و Decoupling نزدیک پایه‌های تغذیه را توصیه می‌کند. همین سند هشدار می‌دهد که در زمان ارسال، افزایش ناگهانی جریان می‌تواند باعث افت ریل تغذیه شود. این یعنی خازن 100nF تنها، مخصوصاً وقتی رگولاتور چند سانتی‌متر دورتر است، همیشه کافی نیست.

افت لحظه‌ای ریل ۳٫۳ ولت هنگام ارسال Wi-Fi و عبور از محدوده خطر Brownout

برای تست، پروب اسیلوسکوپ را نزدیک پایه 3V3 ماژول و با Ground Spring یا اتصال زمین کوتاه قرار دهید. اندازه‌گیری روی خروجی منبعی که نیم متر کابل با برد فاصله دارد، تصویر واقعی پایه تغذیه ESP32 را نشان نمی‌دهد. هم‌زمان بارهای صنعتی مثل رله، شیر برقی، موتور و کنتاکتور را قطع و وصل کنید و ببینید افت ولتاژ با زمان قطع ارتباط هم‌بستگی دارد یا نه.

• رگولاتور را فقط با جریان متوسط انتخاب نکنید؛ پاسخ گذرا، ESR خازن و پایداری Loop مهم‌اند.
• مسیر 3V3 و Ground باریک یا طولانی می‌تواند افت و Ground Bounce ایجاد کند.
• پایه CHIP_PU باید مسیر کوتاه و ایمن در برابر نویز داشته باشد؛ پالس نویز روی این پایه می‌تواند Reset بسازد.
• در ورودی صنعتی، حفاظت ESD/Surge و فیلتر مناسب را از Decoupling محلی جدا ببینید؛ هرکدام وظیفه متفاوتی دارند.

۳. EMI؛ نویزی که هم از سیم وارد می‌شود، هم از هوا

در محیط صنعتی معمولاً چند منبع نویز هم‌زمان داریم: VFD، موتور، کنتاکتور، رله، منبع سوئیچینگ، کابل‌های بلند و زمین‌هایی که واقعاً هم‌پتانسیل نیستند. بخشی از این نویز به‌صورت Conducted روی تغذیه و کابل‌ها حرکت می‌کند و بخشی به‌صورت Radiated روی آنتن، مسیر Reset یا خطوط دیجیتال اثر می‌گذارد.

Wi-Fi در باند بدون مجوز کار می‌کند و باید با تجهیزات دیگر همان باند کنار بیاید. پژوهش‌های صنعتی جدید نشان می‌دهند موانع فلزی، تداخل رادیویی و سطوح بازتابنده، Packet Loss و تأخیر را به محل نصب و کانال وابسته می‌کنند؛ حتی جابه‌جایی چند ده سانتی‌متری می‌تواند شرایط Multipath را تغییر دهد.

شیلدکردن کورکورانه راه‌حل مهندسی نیست. مسیر ورود نویز را پیدا کنید: آیا با قطع موتور مشکل رفع می‌شود؟ خطا فقط هنگام سوییچ‌کردن کنتاکتور رخ می‌دهد؟ برد با منبع آزمایشگاهی ایزوله پایدار می‌شود؟

۴. آنتن، RSSI و اشتباه معروف «سیگنال دارم، پس لینک خوب است»

نمایش چند خط آنتن روی گوشی یا دیدن RSSI قابل‌قبول، تضمین نمی‌کند ارتباط صنعتی قابل‌اعتماد است. RSSI فقط بخشی از داستان است؛ نویز زمینه، SNR، اشغال کانال، Retry، Hidden Node و Multipath هم روی کیفیت لینک اثر دارند. ممکن است RSSI ظاهراً خوب باشد، اما Packetها چند بار Retransmit شوند و تأخیر بالا برود.

در ماژول دارای آنتن PCB، ناحیه Keep-out را جدی بگیرید. صفحه فلزی، کابل قدرت یا دیواره تابلو می‌تواند الگوی تشعشع را تغییر دهد. در محفظه فلزی، ماژول U.FL و آنتن خارجی معمولاً نتیجه قابل‌پیش‌بینی‌تری می‌دهد.

• RSSI را در طول زمان Log کنید، نه فقط یک‌بار هنگام نصب.
• Packet Loss و Round-Trip Time را زیر بار واقعی شبکه اندازه بگیرید.
• کانال Access Point را ثابت و با RF Survey انتخاب کنید؛ Auto Channel همیشه برای دستگاه ثابت صنعتی بهترین گزینه نیست.
• اگر چند AP با SSID یکسان وجود دارد، Roaming و تغییر BSSID را در Log لحاظ کنید.

۵. Beacon Timeout و Reason Code؛ سرنخی که نباید دور ریخته شود

در ESP-IDF، رخداد WIFI_EVENT_STA_DISCONNECTED فقط نمی‌گوید «اتصال قطع شد»؛ ساختار Event شامل Reason Code است. مستندات Espressif توضیح می‌دهد این رخداد می‌تواند به علت پیدا نشدن AP، Timeout احراز هویت، از دست رفتن متوالی Beaconها، تغییر تنظیمات امنیتی AP یا خارج‌کردن Station از سمت Access Point ایجاد شود.

پس Event Handler نباید فقط یک esp_wifi_connect() صدا بزند و تمام. ابتدا Reason Code، RSSI قبلی، BSSID، زمان اتصال و تعداد Retry ذخیره شود. اگر همه خطاها را با Reconnect فوری جواب بدهیم، هنگام خرابی شبکه یک Reconnect Storm می‌سازیم؛ ESP32 پشت‌سرهم Scan و Connect می‌کند، مصرف و ترافیک بالا می‌رود و عیب‌یابی سخت‌تر می‌شود.

۶. وقتی Wi-Fi وصل است اما داده ردوبدل نمی‌شود

گاهی Wi-Fi وصل است اما Server داده نمی‌گیرد. Socket خراب، DNS Timeout، Session منقضی‌شده یا بسته‌شدن TCP پس از یک Disconnect کوتاه از علت‌های رایج‌اند. طبق مستندات ESP-IDF، LwIP هنگام قطع Wi-Fi معمولاً اتصال‌های TCP را پاک می‌کند؛ بنابراین Socket قدیمی بعد از برگشت شبکه ممکن است دیگر قابل استفاده نباشد.

راه درست، طراحی State Machine برای Connectivity است. حالت‌های Wi-Fi Connected، IP Ready، Transport Connected و Application Session Ready را از هم جدا کنید. مثلاً در MQTT، گرفتن IP به‌تنهایی به معنای آماده بودن Publish نیست. این تفکیک ساده، جلوی بخش بزرگی از رفتارهای مبهم را می‌گیرد.

پنج لایه اصلی در عیب‌یابی ارتباط ESP32: تغذیه، EMI، RF، Firmware و شبکه

۷. Watchdog، Taskهای بلاک‌شده و اولویت‌بندی اشتباه

گاهی ارتباط به این دلیل می‌خوابد که Task مربوط به شبکه فرصت اجرا پیدا نمی‌کند. یک Loop سنگین، پردازش طولانی بدون Delay، Critical Section بزرگ یا Callback نامناسب می‌تواند CPU را درگیر کند. در این حالت ممکن است Task Watchdog فعال شود، یا بدون Reset واضح، زمان‌بندی شبکه و پردازش Eventها به‌هم بریزد.

خواندن سنسور، پردازش پروتکل، کنترل خروجی و ارسال شبکه را در یک Loop بزرگ نریزید. Queue و Taskهای جدا مسیرهای زمان‌حساس را تفکیک می‌کنند؛ اما Stack، Priority و Core Affinity باید با اندازه‌گیری تنظیم شوند.

• در Callbackهای Wi-Fi و Timer کار سنگین انجام ندهید؛ فقط Event را تحویل یک Task مناسب بدهید.
• مدت اجرای Taskهای اصلی را اندازه بگیرید و نقاطی را که صدها میلی‌ثانیه CPU را نگه می‌دارند پیدا کنید.
• اگر Watchdog را صرفاً غیرفعال کنید، معمولاً علامت هشدار را پاک کرده‌اید، نه علت را.

۸. Heap و Buffer؛ مشکل آرامی که بعد از چند ساعت خودش را نشان می‌دهد

بردی که ده دقیقه تست شده، هنوز تست پایداری نداده است. Memory Leak، Fragmentation یا پرشدن Queue ممکن است بعد از چند ساعت یا چند روز ظاهر شود. ESP-IDF صراحتاً هشدار می‌دهد که تمام‌شدن Heap می‌تواند رفتار تعریف‌نشده ایجاد کند و تنظیم تعداد Bufferهای Wi-Fi و پنجره‌های TCP باید با مصرف حافظه برنامه متعادل باشد.

Minimum Free Heap و Largest Free Block را هم Log کنید. ثابت‌بودن Free Heap همراه با کوچک‌شدن Largest Block می‌تواند نشانه Fragmentation باشد. در ارسال پرترافیک نیز نتیجه send() یا sendto() را بررسی کنید؛ پرشدن Buffer ممکن است ENOMEM بدهد و بدون Retry داده از دست برود.

• نرخ تولید داده را از نرخ واقعی انتقال جدا کنید و بینشان Queue محدود داشته باشید.
• برای Telemetry صنعتی، حذف کنترل‌شده داده قدیمی گاهی بهتر از انفجار حافظه است.
• برای پیام‌های حیاتی، ACK، Sequence Number، Timeout و Retry در لایه Application طراحی کنید.

۹. اگر مشکل ارتباط بین ESP32 و برد دیگر است

در ارتباط ESP32 با برد دیگر، مشکل می‌تواند از لایه فیزیکی یا پروتکل باشد. UART TTL برای کابل بلند و محیط نویزی مطمئن نیست. در فاصله بیشتر یا اختلاف زمین، RS-485 ایزوله یا CAN منطقی‌تر است؛ البته بدون Termination، Bias، حفاظت و کابل مناسب، آن‌ها هم پایدار نمی‌مانند.

Byte خام را Packet معتبر فرض نکنید. Frame بهتر است Header، Length، Command، Sequence و CRC داشته باشد و Parser پس از داده ناقص دوباره Sync شود. همین جزئیات تفاوت «دمو» و «محصول» را می‌سازد.

جدول سریع تشخیص علامت و علت احتمالی

روند عملی عیب‌یابی؛ از حدس به اندازه‌گیری

فلوچارت پیشنهادی برای عیب‌یابی مرحله‌به‌مرحله ناپایداری ارتباط ESP32

در هر مرحله فقط یک متغیر را تغییر دهید. تغییر هم‌زمان رگولاتور، Reconnect، کانال و آنتن شاید مشکل را پنهان کند، اما علت را نشان نمی‌دهد. تست قبل و بعد باید با نرخ ارسال، فاصله، بار صنعتی و مدت یکسان انجام شود.

فلوچارت پیشنهادی برای عیب‌یابی مرحله‌به‌مرحله ناپایداری ارتباط ESP32

چک‌لیست قبل از تحویل دستگاه

• تست حداقل ۲۴ ساعته با ثبت تعداد Disconnect، Reset، Packet Loss و Minimum Heap انجام شده است.
• دستگاه هنگام روشن و خاموش‌شدن موتور، رله، کنتاکتور و VFD آزمایش شده است.
• ریل 3.3V نزدیک ESP32 با اسیلوسکوپ و در بدترین شرایط بار بررسی شده است.
• Reason Code قطع Wi-Fi و Reset Reason در محصول قابل بازیابی است.
• Reconnect دارای Backoff است و در خرابی شبکه Scan/Connect بی‌وقفه ایجاد نمی‌کند.
• Socket یا Session لایه Application بعد از قطع شبکه به‌درستی بازسازی می‌شود.
• آنتن داخل ناحیه Keep-out قرار دارد و از فلز و کابل قدرت فاصله مناسب دارد.
• برای ارتباط بین بردها، CRC، Timeout، Sequence و بازیابی Frame ناقص پیاده‌سازی شده است.
• یک مسیر Fail-safe تعریف شده است؛ قطع شبکه نباید خروجی خطرناک یا تصمیم غیرقابل‌کنترل ایجاد کند.

نتیجه‌گیری

قطع ارتباط ESP32 در صنعت معمولاً تک‌علتی نیست. افت کوتاه تغذیه می‌تواند Reset بسازد، Socket را از بین ببرد و Reconnect نامناسب شرایط را بدتر کند. عیب‌یابی باید سیستمی باشد؛ Hardware، Power، RF، Firmware و Network کنار هم دیده شوند.

برای من مهم‌ترین نکته این است: قبل از آن‌که چیزی را «نویز» یا «باگ ESP32» بنامیم، باید آن را اندازه بگیریم. Boot Log، Reset Reason، Wi-Fi Reason Code، RSSI، Packet Loss، Minimum Heap و شکل موج 3.3V معمولاً خیلی سریع‌تر از حدس‌زدن ما را به علت واقعی نزدیک می‌کنند.

ESP32 می‌تواند در محصول صنعتی پایدار کار کند، اما نه با همان ذهنیتی که یک Demo روی Breadboard ساخته می‌شود. پایداری نتیجه مجموعه‌ای از تصمیم‌های کوچک و درست است: منبع تغذیه مناسب، Layout تمیز، آنتن اصولی، پروتکل مقاوم، مدیریت خطا و تست طولانی‌مدت.