---
title: "How to Build a Dual-Port Art-Net v4 / sACN to DMX512/RDM Node with WIZnet W5500 on ESP32-S3?"
url: "https://maker.wiznet.io/viktor/projects/how-to-build-a-dual-port-art-net-v4-sacn-to-dmx512-rdm-node-with-wiznet-w5500-on-esp32-s3/"
markdown_url: "https://maker.wiznet.io/viktor/projects/how-to-build-a-dual-port-art-net-v4-sacn-to-dmx512-rdm-node-with-wiznet-w5500-on-esp32-s3/md"
type: "UCC: User Created Content"
author: "Nguyễn Phước Thịnh"
author_url: "https://github.com/thinhh0321/ESP-NODE-2RDM"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "Nguyễn Phước Thịnh"
original_url: "https://github.com/thinhh0321/ESP-NODE-2RDM"
published: "2026-02-06"
language: "en"
tags: ["ESP32"]
hardware: ["WIZnet W5500"]
likes: 0
views: 1212
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# How to Build a Dual-Port Art-Net v4 / sACN to DMX512/RDM Node with WIZnet W5500 on ESP32-S3?

> ESP-NODE-2RDM is an ESP32-S3 Art-Net v4 / sACN (E1.31) node that outputs two DMX512/RDM ports with multi-source merging. It uses a WIZnet W5500 SPI-Ethernet.

Original author: Nguyễn Phước Thịnh (source: https://github.com/thinhh0321/ESP-NODE-2RDM)

## Components

- **WIZnet W5500** x 1 ([docs](https://docs.wiznet.io/Product/Chip/Ethernet/W5500))

WIZnet parts: W5500 ([Datasheet](https://docs.wiznet.io/Product/Chip/Ethernet/W5500/datasheet?utm_source=maker&utm_medium=project&utm_campaign=w5500), [product hub](https://maker.wiznet.io/products/w5500/))

## Article

## 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.

![](https://maker.wiznet.io/upload/ckeditor5/1045108010%5F1770632362%2Epng)

## 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.

---

Source: https://maker.wiznet.io/viktor/projects/how-to-build-a-dual-port-art-net-v4-sacn-to-dmx512-rdm-node-with-wiznet-w5500-on-esp32-s3/