DBlocker — Detect a Rogue Drone, Jam It Out of the Sky: An Anti-Drone Defense System Running on W5500

#AntiDrone #CounterUAS #CriticalInfrastructure #RFJamming #W5500 #TOE #UDP #MQTT #STM32 #EdgeAI

📚 Context: A fielded anti-drone defense system protecting an industrial complex (the repo/docs and live GPS coordinates point to the Morowali region of Sulawesi, Indonesia). It automatically detects unauthorized drones and neutralizes them with directional jamming. The point of this curation: a security system this serious trusts its entire network presence to a single WIZnet W5500. From SSH libraries to anti-drone defense, the same little chip keeps showing up at the communication core of wildly different systems — that is how broadly WIZnet is deployed.

01 — What is this project?

A modern industrial complex — a refinery, a smelter, a nickel-processing park — has to treat the sky as a threat surface. An unauthorized drone overhead can mean espionage, smuggling, or a safety incident, and the response has to happen automatically, 24/7, with no operator standing by. DBlocker is the system that does exactly that: it detects intruding drones and neutralizes them.

Here is the loop it actually runs:

1. Detect. RF-scanning detector units placed around the site sniff for drone radio signatures and report each target's position, heading, speed, and frequency.
2. Aim. For every blocker installation, the system computes the bearing to the drone from GPS coordinates (haversine), then maps that bearing onto a 60° sector.
3. Neutralize. It automatically switches ON the jamming signals for the sector facing the drone — both the GPS band and the drone's control link (Ctrl) — cutting the drone's navigation and its link to its pilot so it is driven off or forced down. All of this is logged as an automatic auto_drone_response.

Around that core loop sits a full operable system:

• Detection — RF detector devices are the primary trigger; a YOLOv8 camera vision service adds a live visual-confirmation feed for operators.
• Field controller — an STM32F411 "master" microcontroller drives the blocker/jammer hardware (seven sector channels, plus seven more on a serial-linked slave STM32) and reports analog feedback, temperature, and status.
• Backend + dashboard — a Go backend over MQTT (Mosquitto) ties the controllers, detectors, and a Svelte web dashboard together, with a live map showing blockers (red) and detectors (cyan).

And the single component that keeps each field controller on the network — for control, telemetry, over-the-air firmware updates, and emergency recovery — is the WIZnet W5500. That a mission-critical security appliance entrusts its whole network presence to one small SPI chip is the real headline here: the W5500 turns up at the comms core of systems as different as an SSH library and an anti-drone defense grid.

02 — Why one W5500 carries this whole system's network

The interesting part isn't that the controller talks Ethernet — it's that an always-on security appliance hands its entire network presence to a single small chip and trusts it. Three reasons that works:

🔷 It must never silently fall off the net — and the W5500 can be hard-reset

This is safety equipment: on link loss the firmware runs a deliberate safety shutdown and then fights to recover. Because the W5500 is a discrete chip with a hardware reset pin, the firmware can power-cycle the whole network engine as a recovery step — something a software stack fused into the MCU cannot do.

🔷 The STM32F411 has no Ethernet and no spare cycles

The Cortex-M4 master is busy with real-time I/O, CRC serial to the slave, OTA, and watchdog duties, and has no Ethernet MAC. Offloading the full TCP/IP stack to the W5500 keeps the firmware lean and the control loop's timing predictable.

🔷 Three jobs at once, on one chip

The controller runs MQTT control/telemetry, an OTA firmware server, and a UDP recovery channel simultaneously — exactly what the W5500's eight independent hardware sockets are built for. (Details in Section 04.)

That a system guarding a complex against drones rests its connectivity on one SPI part is, in the end, the strongest endorsement of where the W5500 has earned its place.

03 — System architecture

04 — Why WIZnet W5500? ⭐

🔷 The technical core: one SPI chip, a full hardware TCP/IP stack

The W5500 hangs off the STM32's SPI bus (SCK=PB3, MISO=PB4, MOSI=PB5, CS=PA15) with a dedicated reset line (PC15), and presents a complete hardwired TCP/UDP/IP stack plus a 10/100 PHY. The STM32 talks to it through the standard Arduino Ethernet library — no software TCP/IP on the MCU at all.

🔷 Modes in use: TOE TCP and UDP, simultaneously

This project is a clean illustration of the W5500's multi-socket hardware offload, using several of its eight hardware sockets at the same time:

• TOE TCP — MQTT. EthernetClient carries a PubSubClient MQTT session to the broker. The controller publishes 18 channels of analog feedback + temperature + slave-link status on dbl/<id>/rpt, subscribes to dbl/<id>/cmd, and uses an MQTT Last-Will (sta = OFF) so the backend learns instantly if the controller drops. TCP socket, hardware-offloaded.
• TOE TCP — OTA server. EthernetServer otaServer(8080) is a listening TCP socket that accepts a new firmware image, streams it into internal flash, and applies it only after a strict byte-for-byte size verification — otherwise it discards and reboots. Remote firmware update over a hardware TCP socket.
• UDP — secure out-of-band command channel. EthernetUDP on port 51515 receives short commands (SLEEP, WAKE, WAKE_RST, and an OTA trigger), each guarded by a shared secret + CRC, and replies with ACK/ERR datagrams. This is the lifeline that can wake the controller or push it into OTA mode even when MQTT is down. UDP socket.

Running MQTT, an OTA TCP server, and a UDP listener concurrently is precisely what the W5500's independent hardware sockets are built for — and it would be painful to juggle on a single software socket.

🔷 Field-hardening: the W5500 as a recoverable subsystem

What makes this a professional use of the chip is how aggressively the firmware treats the W5500 as something it can monitor and recover:

• A resetW5500() routine toggles the hardware RST line and fully re-initializes SPI, the Ethernet stack, the UDP listener, and MQTT.
• At boot the firmware tries W5500 init up to 3 times, hard-resetting between attempts, and checks Ethernet.hardwareStatus().
• It watches Ethernet.linkStatus(); a sustained link-down triggers the safety shutdown.
• A W5500 health timeout detects the nasty "connected but publishes silently failing" lockup — if no successful publish happens for 60 s while ostensibly connected, it resets the chip.
• MQTT reconnect failures escalate to a W5500 reset after a threshold; a longer outage escalates to a full reboot. An IWatchdog backstops everything.

That escalation ladder — retry → reset the W5500 → reboot — is only clean to write because the W5500 is a discrete, resettable network engine with a hardware reset pin. A soft stack fused into the MCU couldn't be power-cycled like that.

🔷 Advantages over the alternatives

A software stack (e.g. lwIP/smoltcp on an Ethernet-capable MCU) would consume flash and CPU the control loop needs, and couldn't be hard-reset independently. An ENC28J60 would force the MCU to run TCP/IP in software anyway (it's MAC-only). The W5500 gives this small STM32 a full TCP/IP offload, multiple concurrent sockets, and a hardware reset line — the trifecta this always-on safety controller actually depends on.

🔷 Verified evidence ✅

• Live, fixed addressing of a real deployment: controller at 10.88.81.3, broker at 10.88.81.16, controller ID 250002.
• Complete W5500 bring-up and recovery code in firmware (mcu_master_4.x.ino): SPI pins, reset sequence, init retries, link monitoring.
• Concurrent socket use proven in code: MQTT TCP + OTA EthernetServer(8080) + EthernetUDP(51515).
• Production tooling around it: Docker Compose deploy files, deployment/auth/port docs, OTA with byte verification, and a vision pipeline shipping a real yolov8n.onnx model.

05 — Key components

🌐 WIZnet W5500 — TOE TCP + UDP, SPI-attached full stack

The controller's sole network link. Provides hardware TCP/IP across multiple sockets (MQTT, OTA server, UDP) and a 10/100 PHY, with a hardware reset line the firmware uses for recovery. SPI: SCK=PB3, MISO=PB4, MOSI=PB5, CS=PA15, RST=PC15.

🎛️ STM32F411 master + STM32 slave

The master drives 7 output channels, reads 9 analog feedback inputs and temperature, and commands a slave (7 more channels) over CRC8-framed serial (UART, optional RS485). Failsafe pin mask + safety shutdown on link loss.

📡 MQTT (Mosquitto) + Go backend

Topic scheme dbl/<id>/{cmd,rpt,sta} with Last-Will. The Go backend bridges MQTT to a database and to operators via SSE.

👁️ YOLOv8 vision detector (Go)

A yolov8n.onnx model runs against camera streams to detect drones and broadcast detections — the "eyes" feeding the control plane.

🖥️ Svelte dashboard

Live operator UI for monitoring feedback/telemetry and issuing commands.

06 — Application scenarios

01. Unattended perimeter drone defense

A controller at a fixed industrial-LAN address runs around the clock, executing a safe-state shutdown on network loss and self-recovering its W5500 link — no on-site intervention needed.

02. Remote firmware maintenance at scale

Field units get new firmware over the W5500's TCP OTA server with byte-for-byte verification, so a fleet across a large site can be updated from the control room without physical access.

03. Out-of-band recovery when MQTT is down

The CRC-and-secret UDP channel on 51515 can wake a sleeping controller or push it into OTA mode even if the broker connection has failed — a true backdoor lifeline over a separate hardware socket.

04. AI-detection-driven response

YOLOv8 drone detections flow through MQTT to the controllers, closing the loop from "camera sees a drone" to "controller acts," all over the same W5500-backed network.

Conclusion

DBlocker Control shows what a single WIZnet W5500 buys a small STM32: MQTT control, OTA updates, and an out-of-band UDP lifeline running concurrently on hardware sockets — with a hardware reset pin that turns the network link into something the firmware can monitor and heal on its own.

• ✅ Full counter-drone control stack: edge AI, firmware, MQTT backend, web dashboard
• ✅ W5500 used in TOE TCP and UDP simultaneously across multiple hardware sockets
• ✅ MQTT control/telemetry with Last-Will over a hardware TCP socket
• ✅ OTA firmware update via a TCP EthernetServer, with strict byte verification
• ✅ Secret-+-CRC UDP command channel as an out-of-band recovery path
• ✅ Aggressive W5500 field-hardening: init retries, health timeout, reset/reboot escalation, watchdog
• ✅ Real deployment markers: static industrial IPs, Docker Compose, deployment docs, shipped YOLOv8 model
• ✅ Master/slave STM32 architecture with CRC-framed serial and failsafe safe-state

Q&A

Q. Which W5500 mode does the controller use? Both TOE TCP and UDP, at the same time. Via the Arduino Ethernet library the W5500 runs its hardwired TCP/IP: a TCP socket for MQTT (PubSubClient), a second TCP socket as an OTA server on :8080, and a UDP socket on :51515 for secret-protected out-of-band commands. The W5500's eight independent hardware sockets are what make running all three concurrently straightforward.

Q. Why hardware TCP/IP (TOE) instead of a software stack? The STM32F411 has no Ethernet MAC and its firmware is busy with real-time I/O, CRC serial, OTA, and watchdog duties. Offloading TCP/IP to the W5500 keeps the firmware lean and timing predictable — and, vitally, the W5500's hardware reset line lets the firmware power-cycle the whole network engine as a recovery step, which a fused-in soft stack can't do.

Q. What happens when the network drops? The firmware escalates: reconnect attempts → reset the W5500 → full reboot, with an IWatchdog backstop, and a deliberate safety shutdown (failsafe pin mask) if the link stays down. A W5500 "health timeout" also catches the connected-but-silently-failing lockup and resets the chip.

Q. Is the deployment real? The static industrial addressing, controller ID, Docker Compose production files, deployment/port/auth docs, OTA-with-verification, and a shipped YOLOv8 model all point to a fielded system rather than a bench demo. (Anyone reproducing it should still validate on their own hardware and network.)

DBlocker — 침입 드론을 탐지해 하늘에서 무력화한다: W5500 위에서 도는 안티드론 방어 시스템

#AntiDrone #CounterUAS #CriticalInfrastructure #RFJamming #W5500 #TOE #UDP #MQTT #STM32 #EdgeAI

📚 컨텍스트: 산업단지를 지키는 실배치 안티드론 방어 시스템 (레포·문서와 실제 GPS 좌표가 인도네시아 술라웨시 모로왈리 지역을 가리킴). 무허가 드론을 자동으로 탐지해 방향성 재밍으로 무력화한다. 이 큐레이션의 핵심: 이렇게 진지한 보안 시스템이 네트워크 전체를 단 하나의 WIZnet W5500에 맡긴다. SSH 라이브러리부터 안티드론 방어까지 — 같은 작은 칩이 전혀 다른 시스템들의 통신 심장부에 거듭 등장한다. WIZnet이 얼마나 폭넓게 쓰이는지를 보여주는 증거다.

01 — 이 프로젝트는 무엇인가?

현대 산업단지 — 정유소, 제련소, 니켈 가공단지 — 는 하늘을 위협면으로 다뤄야 한다. 상공의 무허가 드론은 정찰·밀반입·안전사고로 이어질 수 있고, 그 대응은 운영자가 없어도 24시간 자동으로 일어나야 한다. DBlocker는 바로 그걸 하는 시스템이다: 침입 드론을 탐지해 무력화한다.

실제로 도는 루프는 이렇다:

1. 탐지. 현장에 배치된 RF 스캐닝 탐지기들이 드론 무선 시그니처를 잡아, 각 표적의 위치·방위·속도·주파수를 보고한다.
2. 조준. 각 blocker 설치 지점에서 드론까지의 방위각(bearing) 을 GPS 좌표로 계산(하버사인)하고, 그 방위를 60° 섹터에 매핑한다.
3. 무력화. 드론을 향한 섹터의 재밍 신호를 자동으로 ON 한다 — GPS 대역과 드론의 조종 링크(Ctrl) 를 함께. 드론의 항법과 조종사 링크를 끊어 쫓아내거나 강하시킨다. 이 전 과정이 auto_drone_response 로 자동 기록된다.

이 핵심 루프를 중심으로 완전한 운용 시스템이 둘러싼다:

• 탐지 — RF 탐지기 장치가 주 트리거이고, YOLOv8 카메라 비전 서비스가 운영자용 실시간 시각 확인 피드를 더한다.
• 현장 컨트롤러 — STM32F411 "마스터" 마이크로컨트롤러가 blocker/재머 하드웨어(섹터 7채널 + 시리얼로 연결된 슬레이브 STM32의 7채널)를 구동하고, 아날로그 피드백·온도·상태를 보고한다.
• 백엔드 + 대시보드 — Go 백엔드가 MQTT(Mosquitto)로 컨트롤러·탐지기를 묶고, Svelte 웹 대시보드(blocker는 빨강, 탐지기는 청록 점으로 표시되는 라이브 맵)로 보여준다.

그리고 각 현장 컨트롤러를 네트워크에 — 제어, 텔레메트리, 무선 펌웨어 업데이트, 비상 복구까지 — 붙들어 두는 단 하나의 부품이 WIZnet W5500이다. 미션 크리티컬한 보안 장비가 네트워크 전체를 작은 SPI 칩 하나에 맡긴다는 것 — 그게 진짜 헤드라인이다. W5500은 SSH 라이브러리부터 안티드론 방어망까지, 전혀 다른 시스템들의 통신 심장부에 거듭 등장한다.

02 — 왜 이 시스템의 네트워크 전체를 W5500 하나가 짊어지는가

흥미로운 지점은 컨트롤러가 이더넷을 한다는 게 아니다 — 상시 가동 보안 장비가 네트워크 전체 를 작은 칩 하나에 맡기고 신뢰한다는 것이다. 그게 통하는 이유 셋:

🔷 절대 조용히 끊겨선 안 되고 — W5500은 하드 리셋이 된다

안전 장비라 링크가 죽으면 펌웨어가 의도된 세이프티 셧다운을 실행하고 복구에 총력을 기울인다. W5500은 하드웨어 reset 핀을 가진 분리된 칩이라, 펌웨어가 네트워크 엔진 전체를 복구 단계로 전원 재투입할 수 있다 — MCU에 융합된 소프트 스택은 못 하는 일이다.

🔷 STM32F411은 이더넷도, 여유 사이클도 없다

Cortex-M4 마스터는 실시간 I/O, 슬레이브로의 CRC 시리얼, OTA, 워치독으로 바쁘고 이더넷 MAC도 없다. TCP/IP 스택 전체를 W5500에 오프로드하면 펌웨어는 가볍고 제어 루프 타이밍은 예측 가능해진다.

🔷 세 가지 일을 한 칩에서 동시에

컨트롤러는 MQTT 제어/텔레메트리, OTA 펌웨어 서버, UDP 복구 채널을 동시에 돌린다 — W5500의 8개 독립 하드웨어 소켓이 존재하는 이유 그대로다. (상세는 04.)

드론으로부터 단지를 지키는 시스템이 연결성을 SPI 부품 하나에 기댄다는 것 — 결국 그것이 W5500이 자기 자리를 입증한 가장 강한 증거다.

03 — 시스템 아키텍처

04 — 왜 WIZnet W5500인가? ⭐

🔷 기술적 핵심: SPI 칩 하나에 완전한 하드웨어 TCP/IP 스택

W5500은 STM32의 SPI 버스(SCK=PB3, MISO=PB4, MOSI=PB5, CS=PA15)에 전용 reset 라인(PC15)과 함께 매달려, 완전한 하드와이어드 TCP/UDP/IP 스택과 10/100 PHY를 제공한다. STM32는 표준 Arduino Ethernet 라이브러리로 칩과 통신한다 — MCU에는 소프트웨어 TCP/IP가 전혀 없다.

🔷 사용 모드: TOE TCP 와 UDP 를 동시에

이 프로젝트는 W5500의 멀티소켓 하드웨어 오프로드를 깔끔하게 보여준다. 8개 하드웨어 소켓 중 여럿을 동시에 쓴다.

• TOE TCP — MQTT. EthernetClient가 PubSubClient MQTT 세션을 브로커로 실어 나른다. 컨트롤러는 18채널 아날로그 피드백 + 온도 + 슬레이브 링크 상태를 dbl/<id>/rpt로 publish 하고, dbl/<id>/cmd를 subscribe 하며, MQTT Last-Will(sta = OFF)을 써서 컨트롤러가 떨어지면 백엔드가 즉시 알게 한다. 하드웨어 오프로드된 TCP 소켓.
• TOE TCP — OTA 서버. EthernetServer otaServer(8080)은 새 펌웨어 이미지를 받아 내부 플래시로 스트리밍하고, 엄격한 바이트 단위 크기 검증 후에만 적용하는(아니면 폐기·재부팅) 리스닝 TCP 소켓이다. 하드웨어 TCP 소켓 위 원격 펌웨어 업데이트.
• UDP — 보안 대역외 명령 채널. 포트 51515의 EthernetUDP가 짧은 명령(SLEEP, WAKE, WAKE_RST, OTA 트리거)을 받는데, 각각 공유 비밀키 + CRC로 보호되고 ACK/ERR 데이터그램으로 응답한다. MQTT가 죽었을 때조차 컨트롤러를 깨우거나 OTA 모드로 밀어넣을 수 있는 생명줄. UDP 소켓.

MQTT, OTA TCP 서버, UDP 리스너를 동시에 돌리는 것 — 이것이 바로 W5500의 독립 하드웨어 소켓이 존재하는 이유다. 단일 소프트웨어 소켓으로는 곡예가 됐을 일이다.

🔷 현장 하드닝: 복구 가능한 서브시스템으로서의 W5500

이 칩을 전문가답게 쓴다는 증거는, 펌웨어가 W5500을 감시·복구 가능한 대상으로 얼마나 적극적으로 다루는지에 있다.

• resetW5500() 루틴이 하드웨어 RST 라인을 토글하고 SPI·이더넷 스택·UDP 리스너·MQTT를 전부 재초기화한다.
• 부팅 시 펌웨어는 W5500 init을 최대 3회 시도하며, 시도 사이에 하드 리셋하고 Ethernet.hardwareStatus()를 확인한다.
• Ethernet.linkStatus()를 감시하고, 지속적인 링크 다운은 세이프티 셧다운을 트리거한다.
• W5500 헬스 타임아웃이 "연결돼 있는데 publish가 조용히 실패하는" 고약한 락업을 잡아낸다 — 연결된 듯한데 60초간 성공적 publish가 없으면 칩을 리셋한다.
• MQTT 재연결 실패가 임계치를 넘으면 W5500 리셋으로, 더 긴 장애는 전체 재부팅으로 에스컬레이션. IWatchdog이 모든 것을 받쳐준다.

retry → W5500 리셋 → 재부팅이라는 그 에스컬레이션 사다리는, W5500이 하드웨어 reset 핀을 가진 분리된, 리셋 가능한 네트워크 엔진이기에 깔끔하게 짜인다. MCU에 융합된 소프트 스택은 그렇게 전원을 껐다 켤 수 없다.

🔷 대체 솔루션 대비 우위

소프트웨어 스택(예: 이더넷 가능 MCU 위의 lwIP/smoltcp)은 제어 루프가 필요로 하는 플래시·CPU를 잡아먹고, 독립적으로 하드 리셋할 수도 없다. ENC28J60은 MAC 전용이라 MCU가 결국 TCP/IP를 소프트웨어로 돌려야 한다. W5500은 이 작은 STM32에 완전한 TCP/IP 오프로드, 다중 동시 소켓, 그리고 하드웨어 reset 라인을 준다 — 이 상시 가동 안전 컨트롤러가 실제로 의지하는 3박자다.

🔷 검증된 증거 ✅

• 실제 배치의 고정 주소: 컨트롤러 10.88.81.3, 브로커 10.88.81.16, 컨트롤러 ID 250002.
• 펌웨어 내 완전한 W5500 초기화·복구 코드(mcu_master_4.x.ino): SPI 핀, 리셋 시퀀스, init 재시도, 링크 감시.
• 코드에서 입증된 동시 소켓 사용: MQTT TCP + OTA EthernetServer(8080) + EthernetUDP(51515).
• 주변 production 도구: Docker Compose 배포 파일, 배포/인증/포트 문서, 바이트 검증 OTA, 실제 yolov8n.onnx 모델을 싣는 비전 파이프라인.

05 — 핵심 컴포넌트

🌐 WIZnet W5500 — TOE TCP + UDP, SPI 부착 풀 스택

컨트롤러의 유일한 네트워크 링크. 다중 소켓(MQTT, OTA 서버, UDP)에 걸친 하드웨어 TCP/IP와 10/100 PHY를 제공하고, 펌웨어가 복구에 쓰는 하드웨어 reset 라인을 갖는다. SPI: SCK=PB3, MISO=PB4, MOSI=PB5, CS=PA15, RST=PC15.

🎛️ STM32F411 마스터 + STM32 슬레이브

마스터는 출력 7채널을 구동하고, 아날로그 피드백 9개와 온도를 읽으며, CRC8 프레이밍 시리얼(UART, 선택적 RS485)로 슬레이브(7채널 추가)에 명령한다. 링크 상실 시 failsafe 핀 마스크 + 세이프티 셧다운.

📡 MQTT (Mosquitto) + Go 백엔드

Last-Will을 갖춘 dbl/<id>/{cmd,rpt,sta} 토픽 체계. Go 백엔드가 MQTT를 DB로, 그리고 SSE로 운영자에게 브리지한다.

👁️ YOLOv8 비전 탐지기 (Go)

yolov8n.onnx 모델이 카메라 스트림에 돌아 드론을 탐지하고 결과를 브로드캐스트 — 컨트롤 플레인을 먹이는 "눈".

🖥️ Svelte 대시보드

피드백/텔레메트리 모니터링과 명령 발행을 위한 실시간 운영자 UI.

06 — 활용 시나리오

01. 무인 경계 드론 방어

고정 산업 LAN 주소의 컨트롤러가 24시간 가동되며, 네트워크 상실 시 안전 상태 셧다운을 실행하고 W5500 링크를 자가 복구한다 — 현장 개입 불필요.

02. 대규모 원격 펌웨어 유지보수

현장 유닛이 W5500의 TCP OTA 서버를 통해, 바이트 단위 검증과 함께 새 펌웨어를 받는다. 대형 사이트 전체 함대를 물리적 접근 없이 관제실에서 업데이트.

03. MQTT 다운 시 대역외 복구

51515의 CRC·비밀키 UDP 채널이 브로커 연결이 실패해도 잠든 컨트롤러를 깨우거나 OTA 모드로 밀어넣을 수 있다 — 별도 하드웨어 소켓 위의 진짜 백도어 생명줄.

04. AI 탐지 기반 대응

YOLOv8 드론 탐지가 MQTT로 컨트롤러에 흘러, "카메라가 드론을 본다"에서 "컨트롤러가 동작한다"까지의 루프를 닫는다 — 전부 같은 W5500 기반 네트워크 위에서.

결론

DBlocker Control은 작은 STM32 하나에 WIZnet W5500이 무엇을 사주는지 보여준다: MQTT 제어, OTA 업데이트, 대역외 UDP 생명줄이 하드웨어 소켓 위에서 동시에 돌고 — 펌웨어가 스스로 감시·치유할 수 있는 네트워크 링크로 만드는 하드웨어 reset 핀까지.

• ✅ 완전한 카운터드론 제어 스택: 엣지 AI, 펌웨어, MQTT 백엔드, 웹 대시보드
• ✅ 여러 하드웨어 소켓에 걸쳐 W5500을 TOE TCP 와 UDP 동시 사용
• ✅ 하드웨어 TCP 소켓 위 Last-Will 포함 MQTT 제어/텔레메트리
• ✅ TCP EthernetServer를 통한 OTA 펌웨어 업데이트, 엄격한 바이트 검증
• ✅ 대역외 복구 경로로서의 비밀키+CRC UDP 명령 채널
• ✅ 공격적 W5500 현장 하드닝: init 재시도, 헬스 타임아웃, 리셋/재부팅 에스컬레이션, 워치독
• ✅ 실제 배치 흔적: 고정 산업 IP, Docker Compose, 배포 문서, 동봉된 YOLOv8 모델
• ✅ CRC 프레이밍 시리얼과 failsafe 안전 상태를 갖춘 마스터/슬레이브 STM32 구조

Q&A

Q. 컨트롤러는 W5500의 어떤 모드를 쓰나요? TOE TCP 와 UDP 를 동시에 씁니다. Arduino Ethernet 라이브러리를 통해 W5500이 하드와이어드 TCP/IP를 돌립니다: MQTT용 TCP 소켓(PubSubClient), :8080의 OTA 서버용 두 번째 TCP 소켓, 그리고 비밀키로 보호되는 대역외 명령용 :51515 UDP 소켓. W5500의 8개 독립 하드웨어 소켓 덕에 셋을 동시에 돌리는 게 수월합니다.

Q. 왜 소프트웨어 스택이 아니라 하드웨어 TCP/IP(TOE)인가요? STM32F411은 이더넷 MAC이 없고 펌웨어는 실시간 I/O, CRC 시리얼, OTA, 워치독으로 바쁩니다. TCP/IP를 W5500에 오프로드하면 펌웨어가 가볍고 타이밍이 예측 가능해지며 — 무엇보다 W5500의 하드웨어 reset 라인 덕에 펌웨어가 네트워크 엔진 전체를 복구 단계로 전원 재투입할 수 있습니다. 융합된 소프트 스택은 못 하는 일입니다.

Q. 네트워크가 끊기면 어떻게 되나요? 펌웨어가 에스컬레이션합니다: 재연결 시도 → W5500 리셋 → 전체 재부팅, IWatchdog이 받쳐주고, 링크가 계속 끊겨 있으면 의도된 세이프티 셧다운(failsafe 핀 마스크). W5500 "헬스 타임아웃"이 연결된-듯-조용히-실패하는 락업도 잡아 칩을 리셋합니다.

Q. 실제 배치된 시스템인가요? 고정 산업 주소, 컨트롤러 ID, Docker Compose production 파일, 배포/포트/인증 문서, 검증 포함 OTA, 동봉된 YOLOv8 모델이 모두 벤치 데모가 아닌 현장 시스템을 가리킵니다. (재현하는 쪽은 그래도 자체 하드웨어·네트워크에서 검증하는 게 좋습니다.)