Pixel Control: LED Strip, SPI and DMX Explained

You bought an LED strip, the box says “DMX”, and nothing happens when you plug it into the console. Or the opposite: the strip works, but everything past a certain point is dead and the far end drifts yellow when you call white. Pixel work involves two worlds that look alike but are not the same, and most faults come from mixing them up.

Two protocols, two different worlds

DMX512 is a field bus: differential signalling over RS-485, noise tolerant, good for hundreds of metres, with every device holding its own address. SPI is the board-level interface the chip inside the strip actually speaks: one-way, at TTL voltage, degrading after a few metres, with no concept of an address at all.

	DMX512	SPI (WS2812B, SK6812, APA102…)
Electrical layer	RS-485, differential pair	TTL level, single ended (3.3–5 V)
Distance	Hundreds of metres	3–5 metres in practice
Addressing	Every device has an address	No address, only position
Direction	One way (two with RDM)	One way
If one pixel fails	The others keep working	Everything after it dies
Speed	250 kbit/s	800 kbit/s typical
Cable	2×0.22 mm² shielded, 120 Ω	Short, low capacitance

A “DMX strip” and a “pixel strip” are not the same product

Two different things sit on the same shelf. What gets sold as a DMX LED strip is an ordinary analogue strip; the driver at its head takes DMX and turns the whole strip one colour. It uses 3 or 4 channels no matter how long the strip is. A pixel strip gives every LED its own chip; data flows down the chain and each LED can be a different colour. The first speaks DMX, the second does not.

How you actually connect an SPI strip to DMX

Something has to translate. There are two usual builds: a DMX-to-SPI decoder on small jobs, and a proper Art-Net/sACN pixel controller on large ones. Both do the same job: take addressed data and turn it into the pulse train the strip understands.

Console / media server
     |  Art-Net or sACN
  Pixel controller  (or DMX -> SPI decoder)
     |  SPI (short, TTL level)
  Strip 1     Strip 2     Strip 3
  (170 px)    (170 px)    (170 px)
     ^           ^           ^
  power injection every ~2 m

• Set the chip type. WS2812B and APA102 are not the same setting; get it wrong and the strip flickers randomly.
• Set the colour order. WS2812B ships in GRB order; choose RGB and red and green swap places.
• Share the ground. If the controller’s GND is not tied to the strip’s, the data line has no reference and the strip stutters.
• Keep the data run short. The gap between controller and first pixel should be as small as possible; if it must be longer, add a buffer or line driver.

Why 170 pixels?

A DMX universe is 512 channels. An RGB pixel eats 3 of them, and 512 ÷ 3 = 170.67. So a universe holds 170 RGB pixels with 2 channels left over. The number stops there because you cannot split one pixel across two universes.

Colour layout	Channels per pixel	Pixels per universe
RGB	3	170
RGBW	4	128
RGB at 16 bit	6	85
Single colour (dim)	1	512

A five metre strip at 60 LED/m is 300 pixels — two universes. Ten strips on a facade puts you at twenty universes, and at that point you are no longer running one DMX line; you are running a network.

Power: where most of it goes wrong

On pixel jobs most faults are about power, not data. A WS2812B LED draws roughly 60 mA at full white. At 60 LEDs per metre that is 3.6 A per metre, so a five metre strip wants 18 A at full white.

• Power injection. Feed the strip from one end only and the voltage drops along the copper; the far end goes dim and white turns yellow. Add a feed roughly every two metres.
• Pick the right voltage. 5 V strips drop fast; over any distance a 12 V or 24 V strip makes life much easier.
• Do not load the supply to its limit. Leave at least 20% headroom over your calculation.
• Common ground. With more than one supply, tie the grounds together — never the positives.

Refresh rate: the invisible limit on pixel count

A WS2812B takes 24 bits per LED, which costs 30 microseconds. With 170 pixels on a line the frame takes about 5 ms, so 200 Hz in theory. Put 1,000 pixels on that same line and the frame stretches to 30 ms, capping you at 33 frames per second. Slow fades hide it; fast chases and video mapping show it as stutter.

• Spread pixels across controller outputs instead of stacking them on one line.
• For video mapping, aim for at least 30–40 fps.
• APA102/SK9822 and similar chips with a separate clock line are far faster — prefer them on camera.
• As universe count grows, measure the load on the switch and the controller.

Common mistakes

• Trying to wire a pixel strip straight onto a DMX line.
• Forgetting to set colour order (GRB/RGB) on the controller.
• Feeding from one end and then blaming the product for a “bad end”.
• Mixing strips from different batches on the same surface; the whites will not match.
• Skipping the common ground.
• Keeping the universe map only in software. Leave a printed copy in the panel.

Related articles

• DMX Universes: Going Beyond 512 Channels
• RGB, RGBW and RGBAW+UV Channel Structures in LED Fixtures
• DMX512 in Architectural Lighting: Facades and Outdoor Installations