WS2812 pixel mode

Each port on the dualETH-PixelControl can be switched from DMX output to WS2812 pixel mode, driving an addressable RGB pixel strip directly. The driver is bit-banged in inline assembly tuned for the processor running at 160 MHz, and supports WS2812, WS2813, and SK6812 strips (anything that follows the WS2812 timing protocol).

This article covers how to switch a port to pixel mode, the two pixel sub-modes, the per-port pixel limit, and — importantly — how to power the strips.

Switching a port to pixel mode

In the web UI, open the Port A or Port B page and change Mode to WS2812. New options appear:

• Pixel count — how many LEDs are on the strip (up to 680).
• Pixel mode — Pixel-map or 12-channel FX.
• Pixel config — colour order (RGB / GRB / RGBW etc.), set this to match your strip.
• Universe assignments — same as DMX-out mode, but multiple universes get used (see below).

Save, and the port switches over. The TX LED for that port changes language — instead of blue blip / pink pulse, it now shows green blip / orange pulse, so you can tell at a glance which ports are pixel ports versus DMX ports.

Pixel-map mode

This is the default. The pixel strip is addressed as raw RGB data: every three DMX channels become one RGB pixel, mapped sequentially across however many universes you've assigned to the port.

Each universe carries 510 channels of pixel data (170 RGB pixels × 3 channels = 510, leaving 2 unused channels per universe). With four universes assigned to a port, you get 170 × 4 = 680 pixels maximum.

The default universe layout is:

If your strip is 200 pixels long, your console only needs to send the first two universes. The third and fourth aren't required.

12-channel FX mode

In FX mode the port still drives a pixel strip, but instead of mapping raw RGB data from the console, the strip is driven by an internal effects engine. The console sends just 12 channels of effect parameters — speed, colour, mode, intensity, and so on — and the firmware generates the pixel pattern.

This is useful when:

• You want pixel content but your console can't comfortably output 4 universes of raw pixel data.
• You want to pre-program effects on the device side and trigger them from a small number of console channels.
• You're using a console that's strong on cue-stack control but weak on pixel-mapping.

In FX mode you also pick a start channel within the assigned universe — that's the first of the 12 channels the firmware reads from.

Pixel power — read this

The dualETH cannot power your pixel strip. It drives the data line; the strip needs its own 5 V power supply. WS2812 LEDs draw up to ~60 mA each at full white, so a 680-pixel run can pull more than 40 amps at 5 V at peak. That's well outside what any node could provide over its data connector.

A few practical rules:

• Size the PSU for at least pixel_count × 60 mA of current at 5 V. Round up generously.
• For runs longer than ~50 pixels, inject power at multiple points along the strip. Voltage drop along a long strip dims and discolours the pixels at the far end.
• Connect the PSU's 0 V (GND) to the dualETH's signal ground. The data line is referenced to ground; without a common ground reference, the strip won't decode the signal reliably.
• Do not power the strip from the dualETH's USB-C input. The strip will brown out the node within a handful of pixels.

Long data runs

WS2812 timing is tight (~1.25 µs per bit). Long unbuffered data wires pick up reflections and ringing, especially over 5 m. If you're running data more than a few metres from the node to the strip, fit a small data buffer / level-shifter near the strip's input.

Why 680 and not more

The driver runs on the processor's main core, sharing time with the network stack and the web UI. 680 pixels is the experimentally-set limit where the strip can be fully refreshed without disrupting incoming Art-Net or sACN reception. Pushing past it risks dropped packets and visibly choppy output.

If you need more pixels per port, the answer is more nodes, not a larger strip on one node.