Chaining light screen panels into one display

Two things have to be right before several panels behave as one screen: how you wire them, and how you describe that wiring to the app. Get the wiring right and the wrong mapping, and you get a perfectly bright, perfectly scrambled picture.

Written by the people who design these panels and their controllers, and we write the apps. Last reviewed July 2026.

Three LED matrix panels laid out on cardboard and chained together with three-wire link cables. A small controller board with three separate outputs sits beside them, fed from a bench power supply, and each panel has its own power feed taped and labelled 5V at the injection point. — Our own bench setup. Note the three-output controller, and that every panel has its own 5 V feed marked at the injection point rather than drawing current through its neighbour.

Data travels along the chain. Power does not — and the app has to be told the arrangement before any of it looks right.

The one mistake that causes most problems

Data chains from panel to panel. Power must be fed into every panel separately.

It is tempting to treat the link cable between panels as though it carries everything. It does carry the signal onward, but you cannot run the current for three panels through the first panel's traces. Each one needs its own feed from the supply.

This is not a refinement for large installations — it is how these panels are meant to be wired from two panels upward. On our own test bench every panel has its own 5 V feed marked at the injection point, and that is what we do before running anything.

What you see when power is under-fed is distinctive, and it is worth learning to recognise because it looks like a fault:

Colour drifts across the assembly. Whites go warm or pink the further you get from the feed. That is voltage sagging, not a colour calibration problem.
Brightness falls off panel by panel. The last panel in the chain is noticeably dimmer than the first at the same setting.
It only misbehaves on bright content. A dark image with a few lit points looks perfect; a full white screen flickers, dims or resets. Current draw scales with how much is lit, so the fault appears and disappears with the content.
Random flicker or restarts on the far panels. The supply voltage at the end of the run has dropped below what the control chips need.

If any of those describe what you are seeing, add power injection before you change anything in the app.

Full white is the worst case, and it is what you should test with

A matrix panel's current draw depends entirely on how many LEDs are lit and how brightly. A photograph with dark areas might light a third of the panel; a plain white screen lights all of it at full output on all three colours.

So test with full white at full brightness, across every panel at once. If the assembly is stable there, everything else is easier. Sizing a supply against a dark test image is how people end up with a screen that works for a week and then browns out during the one bright scene they actually wanted.

The three chained panels under room lighting, each filled with a solid colour: the left panel entirely red, the middle and right panels entirely blue, with the controller and its three link cables visible alongside. — Solid-fill testing. Driving one panel red and the next two blue confirms the addressing boundaries land where you expect, and a solid fill is also the closest you get to worst-case current draw before trying full white.

Filling each panel with a different solid colour, as above, is worth doing before you test white. It does two jobs at once: it shows you immediately whether the addressing boundaries fall where the physical panel edges are, and it loads a whole panel at a time so you can watch for sag panel by panel rather than all at once.

If a fill spills across a seam — part of the second panel showing the first panel's colour — the panel size or count in the app does not match the hardware, and no amount of power will fix that.

Telling the app how the panels are arranged

Once the wiring is sound, the second half of the job is describing the physical arrangement in the app. This is the step that surprises people, and it is where a working assembly still shows a broken picture.

The controller sends one continuous stream of pixel data down the chain. It has no way of knowing where you physically put each panel, or which way round you mounted it. Two panels sat side by side and two panels stacked vertically receive exactly the same data — so you have to tell the app which arrangement is on the wall.

In the app you set, for each panel:

Order — its position in the sequence, matching the order the data cable actually visits them.
Orientation — which way that panel is facing, since a panel rotated or flipped during mounting receives its slice of the image the wrong way round.

Panels carry printed numbering along the edges to make this straightforward: you read the arrangement off the hardware and enter the same thing in the app rather than working it out from first principles.

The chained panels lit in a dark room, showing a single pixel graphic in blue, orange and white that runs continuously across the seams between panels. — Mapping correct: one graphic crosses the seams without a break.

The same panel assembly displaying a different pixel graphic, with the image spanning several panels and the unlit portions of each panel visible around it. — The same assembly, different content. Only part of the display is lit, which is why current draw varies so much with what you show.

Reading a scrambled image

When the mapping is wrong, the failure is usually specific enough to point at the cause.

What you see	Usually means
Image is complete but the panels are in the wrong places — right-hand chunk showing on the left	Panel order in the app does not match the order the data cable visits them
One panel's section is mirrored or upside down while the rest is correct	That panel's orientation setting does not match how it is physically mounted
Image is squashed into the first panel and the rest is dark	The app thinks the display is smaller than it is — panel count or total size is short
Image runs off the end and part of it never appears	The app thinks the display is bigger than it is
Every other row within a panel is reversed	Scan direction setting does not match how that panel is wired internally
First panel correct, everything after it dark	Data is not reaching the second panel — check the link cable and its direction

Work these one at a time with a test image that is obviously asymmetric — text, or an arrow. A symmetrical pattern hides mirroring, which is exactly the fault you are trying to find.

Single panel or combined

You are not obliged to treat the assembly as one canvas. The app can drive a single panel on its own, or the whole set as a combined display.

Both are genuinely useful:

Single-panel display suits small graphics and text that would be lost across a wide assembly, and it is the sensible mode while you are testing one panel or checking a suspect one.
Combined display is what you want for one image across the whole width — a picture, a long scroll of text, an effect that travels the full span.

Worth knowing while planning content: an image spread across a combined display gets the resolution of the whole assembly, but text sized for one panel becomes small relative to the total width. Wide assemblies suit scrolling text better than a single static word.

Physical alignment

Electrically the seam does not matter. Visually it is the thing people notice.

Keep the pixel pitch continuous across the join. A gap wider than the spacing between LEDs inside a panel reads as a visible line through the image. Butt the panels as close as the housings allow.
Align rows before fixing anything. A panel a few millimetres high or low makes a diagonal line look stepped. Run a straight edge along the top of the assembly.
Support each panel independently. Do not let one panel hang off its neighbour, and do not let the link cable take any weight.
Leave slack at every connector. Cables pulled taut between panels work their connectors loose over time, and an intermittent data link on panel two takes out everything after it.

How many panels can one controller drive?

Two separate limits apply, and the lower one wins.

The data limit is how many pixels the controller can address in total. Past that point extra panels either stay dark or repeat what an earlier panel is showing.

The refresh limit arrives sooner in practice. The more pixels on one output, the longer each frame takes to send, and animation that looked smooth on one panel starts to judder. If motion is stuttering on a large assembly while static images look fine, you are past the comfortable limit for that output rather than at a fault.

This is why our controllers provide several independent outputs rather than one long chain — splitting the assembly across outputs divides the work and keeps the refresh rate up. If you have a choice between one chain of six and two chains of three, take the two chains.

For the specific limits of the controller you have, check its documentation or ask us — the numbers differ between models and we would rather give you the right one than a general figure.

A working order for the whole job

Lay the panels out flat in the arrangement you intend, before mounting anything.
Chain the data cables in a deliberate order, and note that order.
Feed power to every panel individually.
Test with full white at full brightness, all panels lit, before you mount anything.
Set the order and orientation in the app to match your layout, and check with an asymmetric test image.
Only then mount it, aligning rows and leaving slack at the connectors.

The reason for that order is simple: every problem in this list is easy to fix on a table and awkward to fix on a wall.