- Role: Drives each cabinet's modules from processed image data
- Sits between: Control system and module driver electronics
- Capacity: Each card supports a bounded resolution per cabinet
- Spares: Keep matched cards on site for fast section recovery
What a receiving card actually does
Every cabinet in an LED wall contains at least one receiving card. The card receives image data that the control system has already formatted, unpacks the portion of the picture belonging to that cabinet, and drives the module electronics that light each LED. It also applies the correction data recorded during factory calibration, so the cabinet matches the colour and brightness of its neighbours.
The card is therefore where calibration lives. A wall's uniformity depends on cards loading the right correction data every time they power up, which is why firmware and data management matter as much as the hardware itself. When a wall shows a section with wrong colour or wrong brightness after maintenance, the cause is often correction data, not LEDs.
Where receiving cards sit in the signal chain
The chain runs from player to video processor to sending hardware, then across cables or fibre to the receiving cards, and from each card to the modules behind it. The processor and sending side decide what the picture is; the receiving side decides how faithfully every cabinet renders its slice of it. Understanding the split helps diagnosis: a fault visible in one cabinet points to its card or modules, a fault visible everywhere points upstream.
This layering is also why card choice follows the control system. Receiving cards and sending hardware are designed to work as a family, with matching protocols and configuration tools. Mixing families creates exactly the compatibility problems that keep a screen dark while two suppliers each blame the other.
How many cards a project needs
In the common design each cabinet carries one card, so card count follows cabinet count. Higher-resolution cabinets, or designs that pack more pixels into a small area, can exceed what one card drives, and the cabinet then carries two. The supplier calculates this from cabinet resolution and card capacity; the buyer's job is to see the calculation written into the proposal, in place of a line item with no reasoning.
Ask how the wall behaves when one card fails. In a serial data path a single failed card can blank everything downstream of it, while looped or parallel paths isolate the fault to one cabinet. The topology decision is made at design time and costs little to get right, so raise it before the design freezes.
Failure modes and spares planning
A failing card announces itself clearly: a section of the wall goes dark, freezes, or loses correction and shows wrong colour. Cards fail more often than modules in many installations, which is good news for repairability, since swapping a card is minutes of work in place of module surgery. The repair speed depends entirely on whether a matched spare is in the site drawer.
Plan the spares kit at purchase time: cards matching the wall's firmware and family, stored with the configuration files, and one spare per several dozen cabinets as a working baseline for critical sites. Record which firmware version ships on the wall, and keep the configuration backup with the spares, so a replacement card loads the right data in one pass.
Firmware, compatibility and documentation
Cards of the same family can carry different firmware versions, and a wall with mixed versions can behave unevenly: sections that refresh differently, or cards that refuse configuration from the management tool. Standardise the version across every cabinet at commissioning, and record it in the handover documentation.
Documentation closes the loop. The handover pack should name the card model and firmware, the cabinet-to-card mapping, the configuration files and the correction data backups. With that pack, any competent technician can restore a dead section without reverse-engineering the wall, which is the difference between a ten-minute fix and a support ticket that spans time zones.
| Stage | Decision | Record to keep |
|---|---|---|
| Design | Card family matched to control system | Model and family in the proposal |
| Count | Cards per cabinet from resolution maths | Capacity calculation |
| Topology | Serial versus looped data path | Failure behaviour statement |
| Commissioning | Firmware standardised across the wall | Version and configuration backup |
| Operation | Spares kit matched and on site | Spares list and storage location |
A colour fault traced to the card
A wall showed uneven colour that looked like bad panels. The cause was mismatched receiving cards against the processor; aligning the cards fixed it without touching the diodes.
Mixed firmware, ghost symptoms
A site ran two firmware versions on the same wall. Cabinets behaved differently and faults moved; standardising firmware made the wall uniform and diagnosable.
Steps for a project: receiving cards
- Match cards to the control system Receiving cards must speak the protocol of your sending hardware and processor. Mismatched cards cause refresh and colour faults that look like panel defects.
- Size honestly against cabinet resolution Count how many cabinets and what resolution each card drives. Under-sized cards force awkward splits; over-sized ones waste channels.
- Standardise firmware Keep every card on one firmware version across the wall. Mixed versions cause behaviour that varies cabinet to cabinet and is hard to diagnose.
- Hold matching spares Store spare cards of the exact model and firmware. A fault becomes a drawer swap only if the spare matches what is installed.
Misconceptions about receiving cards
“Receiving cards are just internal parts.” — They decide refresh cleanliness, failure behaviour and repair speed. The layer between processor and LEDs is where image quality and recovery time are set.
“Any spare card works in a fix.” — A replacement must match the model and firmware or it introduces new faults. Holding exact-match spares is what makes a fault a quick swap.
A short verification list for receiving cards
- Ask for the card capacity calculation behind the proposal
- Confirm the wall isolates a single card failure
- Standardise firmware across every cabinet at commissioning
- Ship a matched spares kit and keep it with configuration files
- Record model, firmware and mapping in the handover pack
A note for the supplier: receiving cards
Receiving cards are the layer where a wall's image quality, failure behaviour and repair speed are decided. Match them to the control system, size them honestly against cabinet resolution, standardise their firmware, and keep matched spares on site. The hardware is inexpensive; the planning around it is what turns a fault into a ten-minute fix.