Troubleshooting

Last updated

Each section starts with a symptom and walks through the likely causes in rough order of probability. Everything here is rooted in the firmware's actual behaviour — there are no fabricated failure modes, but that also means this list is not exhaustive. If you hit something not covered here, email support and we'll work it through with you (and add it to this page).

"I can't reach the device on the network"

Work down this list:

  1. Power. When you power the device, all three status LEDs should briefly come up dim cyan as a boot indicator. If you see nothing, the board isn't powered — check your USB-C cable / supply, or your PoE switch's port if you're running PoE.
  2. PoE specifically. The PoE add-on is active 802.3af-compliant. A passive PoE injector won't power the board (no signature negotiation). A standards-compliant 802.3af / af+at switch or injector will.
  3. Ethernet link. If the boot LEDs stay dim cyan for more than ~10 seconds, the device is waiting for Ethernet link. Check the cable and switch port.
  4. Wrong IP. If DHCP isn't running on your network, the device falls back to 10.0.0.1 with a 255.0.0.0 mask. If you were expecting it on a 192.168.x.x address, you won't reach it without putting your computer in the 10.0.0.0/8 range too. See the network setup article for direct-cable testing.
  5. Stale ARP after a firmware upgrade. Upgrading from v6.x to v7.x changes the device's MAC address (v7+ derives a unique MAC per board instead of using the legacy hard-coded value). Routers and switches may take a few minutes — or a manual ARP-cache flush — to learn the new MAC.

"The console isn't reaching the board"

You can see the board on the network, but no DMX is going out:

  1. Wrong protocol. Check the Per-port Status field on the dashboard for that port. If it says Art-Net and your console is sending sACN, nothing arrives. Switch one or the other.
  2. Wrong universe. Defaults: Port A = Art-Net 0,0,0–3 or sACN 1–4; Port B = Art-Net 0,0,4–7 or sACN 5–8. If your console is sending sACN universe 1 and Port A is set to Art-Net, the universe number doesn't carry over — the two protocols use independent universe numbering.
  3. Subnet mismatch. Console and node need to be reachable on the same subnet (or via a router that forwards the relevant traffic). For Art-Net broadcast, console and node should normally share an L2 broadcast domain.
  4. Packet rate is zero. On the Status page, check the per-port packet rate. Zero with traffic expected means the packets aren't reaching the device at all — drop back to point 3.

"The TX LED is solid red"

Solid red on a TX LED means the port is configured for input (DMX-in mode) but the LED is positioned for output. The LED is telling you "wrong direction".

Open the port's configuration page in the web UI and switch the mode to DMX-out (or RDM-out, or WS2812 — whichever you actually want). The LED returns to its normal blip / pulse behaviour as soon as the new mode is applied.

"The TX LED is pulsing pink (or orange) and won't blip"

Pulsing pink (DMX-out mode) or pulsing orange (WS2812 pixel mode) means the port is in the right mode and looking for traffic, but no packets are arriving for any of its assigned universes. See the "Console isn't reaching the board" section above — same diagnostic ladder.

"The device keeps resetting itself"

Open the Status page and look at the Soft reset counter and Watchdog reset counter. Both persist across reboots until a clean power-on clears them.

  • Soft reset counter climbing: something in the firmware is requesting a controlled reboot repeatedly. Most often this is a config change that crashes shortly after boot.
  • Watchdog counter climbing: the firmware is hanging long enough that the hardware watchdog has to step in. Usually a symptom of network or pixel-data overload.

If the soft counter passes 5 or the watchdog counter passes 10, the firmware will restore all settings to defaults on the next boot to break the loop. This is a feature, not a bug — but it does mean you'll need to re-enter your IP, port modes, and universe assignments. See the brick-recovery section in network setup.

"The device suddenly forgot all its settings"

You've just hit the brick-recovery dance described above. Something repeatedly crashed the device, and the firmware has restored defaults to give you a known-good starting state.

Re-enter your settings, then watch the Status page on the next reboot — if the watchdog counter climbs again, the same thing that crashed it before is still present. The most common culprits are:

  • An invalid IP / subnet combination that prevents the network stack from coming up cleanly.
  • A pixel mode configured for a port whose hardware isn't connected as expected.

"The web UI loads slowly or hangs"

The full SPA is around 38 KB and is served from on-chip flash on every request. On a fresh boot, the first page load takes a beat as the network stack warms up. Subsequent loads should be near-instant.

If the UI feels persistently slow:

  • Check Free heap on the Status page. Below ~8 KB the device is memory-pressured and may struggle to serve large responses.
  • Heavy pixel-data traffic to Port A or B competes with the web UI for processor time. If you're driving 680 pixels at full Art-Net refresh, expect the UI to be sluggish — that's a known trade-off of running everything on a single core.

"WS2812 strip flickers, shows wrong colours, or only the first few pixels work"

Almost always a power problem before a data problem:

  • Voltage drop. WS2812 LEDs at full brightness draw ~60 mA each. By the time you've run that current down a long strip, the far end is brown enough to misinterpret data. Inject 5 V power every ~50 pixels.
  • Common ground. The pixel PSU's 0 V must be connected to the dualETH's signal ground. Without a shared ground reference the strip can't reliably decode the data signal.
  • Colour order mismatch. "Red showing as green" means the colour order in the Pixel config dropdown doesn't match your strip. WS2812 strips ship as either RGB or GRB; SK6812 RGBW adds a white channel. Try the alternatives until colours look right.
  • Long unbuffered data run. Past a few metres, the WS2812 data signal needs a buffer / level-shifter near the strip. Without one, you'll see intermittent flicker and dropped pixels.

"I broke something and need to start over"

You can force a settings reset without waiting for the brick-recovery counters:

  • Re-flash the firmware via the updater. Major-version flashes (v6→v7) reset settings automatically because the EEPROM struct layout changes.
  • Or, deliberately push enough bad config to trigger the auto-recovery (5 soft resets / 10 watchdog firings). Less elegant but works without USB.

If neither option is available — for instance, the unit is unreachable on the network and you can't physically access it — that's a job for support.