LED Wall Processor Planning

How an LED processor works: sending cards and receiving cards

On the output side of the processor (sometimes called the controller) sits a sending card: it scales and maps the incoming picture onto the wall's full pixel canvas, then splits that canvas across its gigabit data ports as packetized LED data. A source (a switcher, a media server, a laptop) sends one video signal into that processor. Every cabinet on the wall contains a receiving card that listens for its own slice of pixels on the chain and drives the LED modules behind it.

One sending card feeds many receiving cards.

Here is the useful mental model. The processor thinks in pixels. The cabinets think in panels. Planning is the work of reconciling the two. Capacity is quoted per port on the sending side and per card on the cabinet side, so once you know how those numbers add up, sizing a processor stops being guesswork.

Build the pixel-capacity budget before you pick a processor

Pixels are the core planning unit. Panels and cabinets are not. You are really building two budgets. The wall's total pixels go against the processor's total capacity; each port's pixels go against its per-port budget. Start with the whole-wall total, because it tells you the floor for how many ports the wall demands.

Total wall pixels = (panels wide x panel width px) x (panels tall x panel height px)
Example, 60 panels (10 wide x 6 tall) of 256 x 256 px:
  width  = 10 x 256 = 2560 px
  height = 6 x 256  = 1536 px
  total  = 2560 x 1536 = 3,932,160 px
Per-port planning budget: roughly 650,000 px on a gigabit port at 60 Hz, 8-bit
Bandwidth floor = 3,932,160 / 650,000 = 6.05, round UP to 7 ports

Between the bandwidth floor and the real count sits a gap, and that gap is why the per-port check matters as much as the total. A port has a pixel budget; each panel spends part of it; fine-pitch panels exhaust a port after only a handful of cabinets.

For the full per-port formula, with worked examples for coarse and fine pitches, see the per-port daisy-chain math.

How many ports and processors will the wall need?

Turning the budget into a hardware count is a short, repeatable procedure; run it once for a first pass, then refine against the real datasheet numbers:

1. Get the wall's total pixel count: multiply the full pixel width by the full pixel height.
2. Divide by the per-port planning budget (roughly 650,000 px on a gigabit port at 60 Hz, 8-bit) and round up. That is the bandwidth floor on ports.
3. Reality-check against chain geometry: a run can only snake through so many cabinets before the cable route or the per-port panel count runs out, which usually raises the port count above the floor.
4. Divide the required ports by the ports per processor (a datasheet number for your model) and round up to get the processor count.
5. Add headroom: leave ports and capacity spare for a refresh-rate bump, a bit-depth change, or the row of panels production adds after the render is approved.

One trap. A processor caps the total pixels it can drive across all its ports as well as per port, so a wall can fit every processor's port count and still exceed its total-capacity ceiling, which forces a second unit.

Check both ceilings, and treat the datasheet as the source of truth for each.

Plan backup ports and processor redundancy

Redundancy on an LED wall comes in layers, and each layer has a hardware cost you should size in preproduction rather than on load-in:

• Loop or backup data ports feed each chain from both ends, so a mid-chain cable or panel failure does not black out everything downstream of the break; the cost is capacity, because on many platforms a redundant loop occupies a second port for the same cabinets, so the processor's usable pixel capacity is effectively halved.
• Backup processor (hot backup) runs a second controller mirroring the main and ready to take over if the primary fails; it roughly doubles the processor hardware for the same wall.
• Redundant source and cabling upstream of the processor matter just as much: a flawless backup port does nothing if the single feed into the processor dies.

Choosing a platform: what to verify before you commit

Processors get searched for by brand (Novastar chief among them). Every platform publishes per-model capacity that varies by product line, by firmware, by output settings. There is no single number for a brand. Plan against a datasheet instead of a reputation. Whatever platform you land on, verify the same short list:

Put the processor plan in the show documents

A processor plan that lives in one tech's head is not a plan. Three things belong in the documentation you hand the crew. Which port feeds which cabinets. Where the backups sit. What input resolution and frame rate the wall runs at.

WireFlow's LED wall builder does the mechanical part.

Pick a panel and set the wall size; it computes cabinet counts, pixel map, power load and data paths against processor port limits from its panel catalog (a public tool with no account required).

From there the wall drops into the wider show plan. The same project carries the pixel map and the power calculation and the signal-flow diagram feeding the processor, so the data plan, the power plan and the show's video path live in one set of documents.

For the product reference on how port limits are applied, see processor limits and data paths; for the wall basics, start with the LED wall overview.

Frequently asked questions

What is the difference between a sending card and a receiving card?

The sending card sits at the processor output: it takes the source video, maps it onto the wall's pixel canvas and pushes the data out the gigabit ports. A receiving card sits inside each cabinet: it listens for that cabinet's slice of pixels and drives the LED modules. One sending card feeds many receiving cards. Capacity is quoted per port on the sending side and per card on the cabinet side.

How many LED panels can one processor port drive?

It depends entirely on the panel's pixel count and the port's capacity. There is no single number. Divide the port's pixel budget by the pixels per panel and round down. Use the datasheet number for your model as that budget, or roughly 650,000 px on a gigabit port at 60 Hz and 8-bit as a planning figure. The full worked math, including why fine-pitch panels chain shorter, is in the daisy-chain article.

How many pixels can a Novastar processor handle?

There is no one figure for the brand. Capacity depends on the specific model, on firmware and on your output settings. That is exactly why Novastar publishes per-model tables. Plan a first pass against the roughly 650,000 pixels per gigabit port figure. Then confirm the real total and per-port numbers on the datasheet for your model at your refresh rate and bit depth.

Does adding a backup port cut my capacity?

On many platforms, yes. A redundant loop commonly occupies a second port for the same cabinets, so the processor's usable pixel capacity is effectively halved and you may need more ports or a second unit; how much it costs varies by platform, so confirm on the datasheet and always budget capacity with redundancy switched on.

Do I size the processor by cabinets or by pixels?

By pixels. Cabinets and panels are convenient to count. But the processor and its ports are limited by pixel bandwidth, and two walls with the same cabinet count but different pitches carry very different pixel loads. Compute total pixels first. Then translate to ports and processors.

Calculate your LED wall in WireFlow

Pick a panel, set the wall size, and get cabinet counts, pixel map, power load, and data paths, before anything ships to site.

Open the LED wall calculator · See a finished wall plan