Wiznet makers

Project intro

ESP-NODE-2RDM is a “network DMX node” that receives lighting data over Ethernet/Wi-Fi and outputs it as two independent DMX512/RDM ports. It targets professional environments (stage, architectural, broadcast, theatre) where you need deterministic output timing, multi-controller workflows, and remote configuration.

On the network side, it supports Art-Net v4 (UDP port 6454) and sACN (ANSI E1.31) with multicast capability—two common ways consoles/media servers deliver DMX universes over IP.

On the DMX/RDM side, it implements:

• DMX output at ~44 Hz, 512 channels per port
• DMX input monitoring
• RDM master + responder features (discovery, parameter get/set, responding to queries)

The “pro” part is the merge engine: up to 4 simultaneous sources per port, with merge modes HTP / LTP / LAST / BACKUP and a configurable source timeout (2–10 seconds). That’s what lets you do real show workflows like primary/backup consoles, multiple controllers, or priority-based control without random output jumps.

Technical analysis: why W5500 matters for reliability

This project’s hardest requirement is not “parse UDP” or “output UART.” It’s maintaining stable DMX/RDM behavior while network packets arrive in bursts and from multiple senders.

1) Deterministic UDP ingest for Art-Net + sACN

Art-Net DMX frames are UDP packets to port 6454. sACN often uses multicast, which can increase packet fan-in when many universes are subscribed. In real venues, you also see packet bursts (scene changes, console refresh alignment, switch behavior).

Using WIZnet W5500 as the primary interface (SPI) is a practical way to bound the worst-case impact of those bursts. The W5500 is a hardwired TCP/IP Ethernet controller with:

• 32 KB internal packet buffer (useful for smoothing burst receive patterns)
• 8 hardware sockets (useful for separating traffic types if needed)
• SPI up to 80 MHz, which helps drain RX quickly into the ESP32-S3

The repo’s pinout also shows an optional W5500 INT line (GPIO 9), which is exactly the kind of design choice that improves reliability: interrupt-driven RX reduces polling jitter and helps you service bursts promptly.

2) Merge engine correctness depends on stable per-source tracking

A multi-source merge engine is only as good as its source accounting. The README explicitly supports 4 sources per port, multiple merge modes, and timeout-based failover. If the network layer drops packets unpredictably, your “LAST” or “BACKUP” mode can flap, and HTP/LTP decisions can oscillate.

W5500 helps here by making packet reception more predictable (buffered RX + fast SPI readout), so timeouts (2–10 s) are driven by actual source loss, not MCU overload.

3) Clean separation between “network timing” and “DMX/RDM timing”

DMX512 is 250 kbps over RS-485, with a frame structure (break, MAB, start code, up to 512 slots) that must repeat continuously for fixtures to behave. RDM rides on that same physical link but is bi-directional, so direction control and turnaround timing become critical.

This project’s hardware mapping reflects that reality: each port has TX/RX pins plus a DIR pin (direction control) to drive half-duplex RS-485 transceivers. With W5500 taking “wired Ethernet duties” as the primary link, you reduce the chance that Wi-Fi stack variability interferes with the tight output loop—while still keeping Wi-Fi as a fallback path.

Architecture explanation (conceptual, based on repo documentation)

Note: I can access the README and top-level structure, but GitHub’s file browser for subfolders is blocked in this environment, so the flow below is architectural (not code-quoted).

1) Network Manager (connectivity + failover)

• Bring up W5500 Ethernet over SPI as primary.
• If link/lease fails, fall back to Wi-Fi STA, and finally to Wi-Fi AP for configuration.
• Support Static IP or DHCP per configuration.

2) Protocol Receivers (Art-Net + sACN)

• Listen for Art-Net (UDP 6454) and sACN (multicast/unicast).
• Validate packet headers and extract universe mapping and channel payload.
• Maintain per-port source tables (up to 4 sources) keyed by sender identity and last-seen timestamp.

3) Merge Engine (per port)

For each port, apply selected merge behavior:

• HTP for intensity-style channels (highest wins)
• LTP (as documented)
• LAST (most recent packet wins)
• BACKUP (primary/secondary failover using timeout)
• Enforce 2–10 s source timeout to drop stale senders and stabilize outputs.

4) DMX/RDM I/O layer

• Drive DMX output at ~44 Hz with 512 slots.
• Use UART TX/RX plus DIR pin per port for half-duplex RS-485 transceivers.
• Provide RDM master/responder features for discovery and parameter operations.

5) Web UI + device ops

• HTTP configuration portal, WebSocket live DMX monitor, RDM panel, network statistics, and OTA updates.
• Persistent settings stored in LittleFS (per README architecture diagram).

FAQ

1) Why use WIZnet W5500 instead of Wi-Fi-only for Art-Net/sACN nodes?

Wi-Fi can work, but show networks punish variability: interference, crowded 2.4 GHz, and bursty latency can destabilize merge decisions and timeout-based backup logic. This project explicitly prioritizes W5500 Ethernet as the primary link, then falls back to Wi-Fi. W5500 adds buffering (32 KB) and a socket-based hardware offload path that helps keep UDP ingest consistent when multiple universes/sources arrive together.

2) How do you connect W5500 to the ESP32-S3 in this project?

The README provides a concrete GPIO mapping: CS=GPIO10, MOSI=11, MISO=13, SCK=12, and an optional INT on GPIO9. That’s the core of making W5500 reliable: use fast SPI transfers, and if possible wire INT so receive can be interrupt-driven (less polling, better burst handling). The project uses ESP-IDF v5.2.6, which is relevant because ESP-IDF has established SPI/Ethernet integration patterns.

3) What role does W5500 play in the merge engine’s stability?

The merge engine supports up to 4 sources per port and modes like LAST and BACKUP with 2–10 s timeouts. If packet reception is jittery, you can falsely “lose” a source and trigger unnecessary failovers. W5500 reduces that risk by providing a buffered Ethernet receive path and fast SPI drain capability, making packet handling more consistent under load—so timeouts reflect real network loss rather than MCU starvation.

4) Can beginners build and debug a W5500-based Art-Net/sACN → DMX/RDM node?

It’s doable, but it’s not a “weekend blink” project. You’re combining: UDP lighting protocols, multi-source arbitration, continuous DMX framing (~44 Hz output), and RDM bidirectional timing over RS-485. The beginner-friendly path is incremental: first bring up W5500 link + IP, then receive one universe, then output DMX (no RDM), then add merging, then add RDM discovery. The repo’s explicit pinout and clear feature list help a lot.

5) How does W5500 compare to RMII PHY Ethernet (LAN8720) or ENC28J60 designs for this use?

RMII PHY designs use the ESP32’s internal MAC plus an external PHY; they can be excellent, but they add RMII clocking/trace constraints and still rely heavily on the MCU/network stack. W5500 integrates MAC+PHY and offers a socket-style hardware interface over SPI, which can simplify board design and make UDP reception more deterministic. Compared with ENC28J60-class controllers, W5500’s “hardwired TCP/IP + sockets + buffering” approach tends to reduce firmware complexity for embedded nodes like this.