grandMA3-portable-esp32

How Does Portable MAesp32 Use W5500 Ethernet to Bridge a Pocket Remote to a GrandMA3 Lighting Console?

Summary — A two-unit remote control for GrandMA3 lighting consoles that avoids venue Wi-Fi. A pocket touchscreen remote talks to a bridge over peer-to-peer ESP-NOW, and the bridge joins the console network through a WIZnet W5500 wired Ethernet port, sending native OSC commands over UDP. Firmware, KiCad sources and production Gerbers are all open (MIT).

At a Glance

What Problem Does It Solve?

In theatre and broadcast lighting, focusing means aiming and shaping every fixture from the stage. The programmer usually operates the console remotely with a tablet or phone on Wi-Fi. The author lists three problems with that:

1. RF congestion and dropouts once the venue fills up or the phone screen locks.
2. No physical buttons for fast one-handed operation.
3. Network complexity — DHCP issues, external access points, changing subnets.

Portable MAesp32 splits the job into two devices. Next to the console sits the VIOLA bridge (ESP32-S3 + W5500 + small OLED). On stage, the operator holds the GIALLA remote (2.8" touchscreen). The two talk directly over ESP-NOW with no router, and the bridge turns each command into an OSC packet that GrandMA3 executes natively, sent over a cable.

In one line: keep radio only where a person has to move, and put the connection to the console on a W5500 Ethernet cable.

Key Technical Features

1. Two units, two links

The remote and bridge use peer-to-peer ESP-NOW (about 1 ms latency per the author's README). The bridge's ESP32-S3 puts Wi-Fi in STA mode and calls WiFi.disconnect(), so the radio never joins any access point — it is used only for the link to the remote. The console side is handled entirely by the W5500.

2. "Zero-Plugin" group sync

Showing the console's real group names on the remote normally requires installing a Lua plugin in the showfile. Instead, the bridge sends inline Lua commands over OSC /cmd. They add a dedicated MAesp32 line to the console's OSC configuration with Append() (or reuse it, storing the index in _G.MAESP), and make the console send the names of DataPool().Groups[1..40] back with SendOSC. Names arrive in 8 batches of 5, 75 ms apart — about 0.5 s for all 40 — and existing OSC lines (QLab, Companion, …) are never overwritten. The showfile in use is not modified, which matters during a live production.

3. Radio and Ethernet never collide

The ESP-NOW receive callback runs on Core 0 and only pushes messages into a FreeRTOS queue (rxQueue, 16 entries). All W5500 SPI access happens in the main loop on Core 1 (code comment: "no SPI/W5500 or flash access in here"). Simultaneous traffic in both directions therefore never causes an SPI bus conflict.

4. Built for show conditions

• Link watch: Ethernet.linkStatus() is checked before every send; if the cable is out, the packet is skipped and the OLED shows "ETH DISCONN!" / !ETH.
• Remote watch: UNLINKED after 4,000 ms without a message from the remote.
• Buffer draining: before each OLED redraw, while (Udp.parsePacket() > 0) empties the W5500 receive buffer; messages to the remote are spaced 800 µs apart so the ESP-NOW queue never saturates.
• Non-blocking display: 360-byte full frame buffer, refreshed every 60 ms, no delay().
• Static memory: the remote stores the 40 group names in char groupNames[40][20] to avoid heap fragmentation.

5. A complete six-page remote

6. Open, manufacturable hardware

The repository's hardware/ folder contains the KiCad 9.0 schematic and layout, production Gerbers (ESP_ETH_Gerber.zip: 2 layers, 1.6 mm, HASL/ENIG, ready for JLCPCB, PCBWay or Aisler) and .step / .3mf models for enclosure design. The remote is an off-the-shelf CYD board, so it needs no soldering.

How Is Ethernet Used?

The W5500 is the bridge's only connection to the console network. It sits on the same switch as the GrandMA3 console (or onPC) and carries all control traffic as OSC over UDP:

On the console, setup is just In & Out → OSC: UDP, port 8000, Receive Command = Yes.

What the TOE does here

The bridge's ESP32-S3 is already running the ESP-NOW callback, the OLED, the remote-link watchdog and the sync state machine. The W5500 handles UDP inside the chip, so sending a command is just Udp.beginPacket() → write() → endPacket(), and feedback is read from the W5500 buffer with Udp.parsePacket(). The author describes the non-blocking display as leaving "99% of CPU time free to drain bursts of UDP packets from MA3".

Why wired instead of Wi-Fi?

The README does not say why the W5500 was chosen. From the code, the design needed a wired port to the console LAN while keeping the ESP32-S3's radio free for ESP-NOW; a hardware UDP stack keeps that firmware simple (inferred).

Where Does It Fit in the Market?

Professional lighting control

GrandMA3 consoles from MA Lighting are widely used in concert touring, theatre and broadcast. Remote focusing is something every production does, and the problems the author lists — congested venue Wi-Fi, no physical buttons, network setup — come up at every venue. A dedicated, wired-bridged remote is a direct answer to that daily need.

Beyond GrandMA3 (pattern)

The same structure — a low-latency handheld + a WIZnet wired bridge + a standard UDP control protocol — fits other places where radio cannot be trusted but the equipment network is wired:

• Other consoles, media servers and show controllers that accept OSC or UDP commands
• Broadcast and studio control networks (cameras, switchers)
• Exhibition and museum show control
• Industrial HMI, where the control network stays wired and only the operator terminal is wireless

These extensions are inferred from the architecture; the project itself targets GrandMA3.

What it shows for WIZnet

• A W5500 used as the "wired port" of an ESP32 accessory joining a professional AV network — a niche where cable is the norm.
• The complete package for a small product run: open firmware, a custom PCB and manufacturing files.
• Pro lighting and AV control already run on UDP protocols, so this bridge design is directly reusable there.

System Architecture

[On stage — GIALLA remote: ESP32-2432S028 (CYD), 2.8" 320x240 touch, 6-page UI, RGB LED]
        ^v  ESP-NOW 2.4 GHz P2P (~1 ms) — command / ping / IP config  <->  ACK / group names
[Control desk — VIOLA bridge: ESP32-S3 + 0.42" OLED 72x40, custom PCB ESP_ETH]
        |  FreeRTOS queue rxQueue(16): ESP-NOW callback (Core 0) -> main loop (Core 1)
        |  SPI (GPIO 4/1/7/3)
[WIZnet W5500 — UDP socket: sends OSC /cmd ,s · receives SendOSC feedback]
        ^v  RJ45 Ethernet (same switch as the console)
[GrandMA3 console / onPC — OSC input: UDP 8000, Receive Command = Yes]

Hardware and Pins

VIOLA bridge (custom PCB ESP_ETH)

GIALLA remote (ESP32-2432S028 "CYD")

Firmware: firmware/MA3_ESPNOW_VIOLA_V3 (bridge) and firmware/MA3_ESPNOW_CYB_V3 (remote), Arduino. Note: the bridge code hard-codes the remote's MAC address (yellowAddress), so replace it with your own CYD board's MAC (seen in the code, not mentioned in the README).

FAQ

Q. Why not make the bridge wireless too?
Joining the console network over Wi-Fi is exactly what causes the problems the author lists. The bridge plugs into the console's switch, and radio is used only for the 1:1 link to the remote.

Q. Does it change my showfile?
No. Group names are fetched with inline Lua over OSC; the bridge only adds (or reuses) its own MAesp32 OSC line and leaves other lines untouched.

Q. What happens if the Ethernet cable is pulled?
The bridge checks the link before sending, skips the packet and shows "ETH DISCONN!" on the OLED. The radio link to the remote is monitored separately.

Q. How do I build one?
Order the PCB from hardware/gerber/ESP_ETH_Gerber.zip, assemble the bridge, and flash the remote firmware onto a CYD board. On GrandMA3, enable OSC input (UDP, 8000, Receive Command = Yes), set the IPs on page P5 of the remote and press SAVE SETTINGS.