One of the most common communication errors in an LED project is calling every control device a “control card.” A customer may say “please change the card,” the installer may replace a receiving card, while the sales team assumes that the video processor was changed. The final symptom is then impossible to interpret because more than one layer has been modified. Understanding the three responsibilities makes troubleshooting faster and safer.
A video processor is normally between the video source and the LED sending path. It handles input selection, scaling, cropping, switching, window layout, image composition or multi-screen output. It defines how an input image is organised into one or more display areas. Different models have different input cards, output cards, layers, window counts and pixel-processing limits. The number of HDMI sockets on the front panel is not enough to prove that a processor can control a particular screen layout.
A sending card is closer to the LED data path. It may be built into an all-in-one processor or installed as an independent sending device. Its job is to send the processed image through the supported network or optical outputs and to follow the port-mapping and loading limits of that model. It normally does not define the scan mode of a particular module, the HUB data-group arrangement or every internal pixel-routing parameter. Those details are commonly held in the receiving-card configuration.
A receiving card is installed in the cabinet or cabinet rear. It receives the upstream data and distributes it to the HUB board, ribbon cables, modules and driver chain. It is closely related to the cabinet resolution, module scan mode, data group, grayscale/refresh settings, port direction and cascade order. Two cards may look similar and still be incompatible because their firmware, connector definitions, driver support or configuration differs.
Use three questions when a fault occurs. First, is the source visible in the processor preview or output monitor? Second, does the sending device show link and data on the relevant output? Third, does the receiving card receive data and have parameters that match the cabinet? If the entire screen is blank, start with the source and processor. If only one output branch is blank, move to the sending port and signal path. If only modules, rows or columns are abnormal, move to the receiver, HUB, ribbon cables and modules.
Before any replacement, record the exact model, port connections, firmware, receiving-card configuration, cabinet topology and symptom photos. Do not assume that two devices can be exchanged because they have the same brand name or both have RJ45 sockets. Cross-brand or cross-generation changes require confirmation of protocol, data rate, configuration tool, receiver compatibility and signal flow.
The handover document should show one clear hierarchy: source → video processor/sending device → optical or network link → receiving card → HUB/ribbon cable → module. For each layer, state what it controls and what it cannot fix. When customers understand the boundaries, they can provide the correct screenshots and test results during remote support.
Add a responsibility matrix to that hierarchy. The source owner confirms the file, resolution, frame rate and input cable. The processor owner confirms the selected input, canvas, layers, scaling and output scene. The sending-path owner confirms port status, loading, fiber/SFP or RJ45 compatibility and labels. The LED installer confirms cabinet direction, power, cascade and service access. The receiver/module owner confirms the RCFGX, scan mode, data group, HUB and ribbon order. A fault report that includes the wrong layer creates delay even when every person is trying to help.
The same separation is useful when a customer asks for a replacement. Ask whether the symptom is at the input, the output branch, one cabinet or one module. Ask whether the proposed replacement has the same model, hardware revision and approved configuration. If the customer wants to change from one controller brand to another, treat it as a system change rather than a one-card substitution. The receiving cards, HUB boards, configuration tools, cable topology and service method may all need review.
For training, give installers a one-page diagram and a one-page checklist. The diagram answers “where does the signal go?” The checklist answers “what must be photographed and backed up?” Together they reduce the common situation where a customer says “the controller is fine” but no one has confirmed the receiving-card status or the actual cabinet path.
Frequently Asked Questions
Q1: Can a video processor replace a receiving card?
No. They operate at different layers. The processor organises the input image; the receiving card distributes data inside the cabinet.
Q2: If the sending card fails, will every module fail?
It may affect the whole screen or one output branch, but the actual scope depends on the port mapping and topology.
Q3: Can a receiving card with the same appearance be installed directly?
Not by appearance alone. Confirm the model, firmware, connectors, configuration, module parameters and cabinet topology.
Q4: What should a customer send for remote diagnosis?
Equipment labels, software version, fault scope, indicator status, connection topology, current configuration backup and full-screen/close-up test photos.
