For an LED display project to successfully execute and achieve its intended goals, a comprehensive project plan is essential. What steps are involved in designing an LED display control system? What indicators and parameters should be considered during the design process?
The LED display control system design process primarily includes five phases: requirements collection and confirmation, solution design, solution review, solution implementation, and solution delivery. The flowchart is shown below.

Requirements Gathering and Verification
Requirements Gathering
Requirements gathering involves conducting in-depth and detailed research and analysis of the "requirements" or "needs" expressed by project stakeholders. This process aims to accurately understand the specific functional, performance, and reliability requirements of both users and the project. This process translates informal user requirements into a complete requirements definition, thereby clarifying what the system must do and providing a basis for system design, improvement, and maintenance.
Requirements gathering is a crucial step in the project planning phase, as it determines what system functionality needs to be achieved and provides clear direction for how to achieve it.
Generally, requirements are categorized into business requirements, user requirements, and functional requirements, depending on the target
Some needs are pseudo-needs and lack practical value. User needs should be screened based on the three dimensions of authenticity, value, and feasibility. This will filter out those that are false, unfeasible, or worthless, thereby distilling the user's essential needs. Understanding "why" is more important than "what" is crucial.
Needs can also be categorized as explicit and implicit. An explicit need is a specific statement by the project leader regarding the challenges, key points, and difficulties; an implicit need is a vague statement by the project leader regarding the challenges, key points, and difficulties. For example, if a user says the display quality is poor, this is an implicit need that should be explored as a explicit need. This can be guided by questions like, "What aspect of the performance do you mean?"
Taking the $APPEALS model as an example, users will have the following eight dimensions of requirements for the solution.
$:Price;
A:Availability;
P:Packaging;
P:Performance;
E:Easy to Use;
A:Assurances;
L: Life Cycle Cost;
S:SocialAcceptance.
Requirements should be ranked by importance based on the project's priorities and key areas of focus. This will facilitate the design team's rational design and equipment configuration based on these priorities.
The requirements collection process is about understanding the current project needs and the most pressing issues that need to be addressed.
Demand for LED displays typically comes from end users, contractors, or integrators. Typical requirements information is communicated to project business personnel through project tender documents, phone calls, emails, and other channels. These initial requirements are then collected and analyzed early. This early analysis process typically includes requirements confirmation and the creation of a requirements list.
Requirements Confirmation
Due to the diverse sources and methods of requirements, we need to conduct secondary confirmation and information screening of the requirements information. Secondary confirmation involves reconfirming with project stakeholders any unclear, inaccurate, or ambiguous information in the requirements description to ensure its accuracy. Information screening primarily involves comprehensive analysis and screening of user information, project information, and end-user information based on three key elements: project type, scenario, and process.
1. Determine the project type.
Different projects require different solutions and have different priorities. For example, rental companies prioritize performance and ease of use, while fixed installation companies prioritize cost and stability.
2. Identify the application scenario.
Different application scenarios require different solutions. For example, theaters prioritize the image quality of LED screens, while stage installations prioritize the functionality of ED screens.
3. Walk through the user experience.
When different implementation methods can meet the same requirement, actual user experiences and habits should be explored to allow the design team to identify the optimal solution.
Create a Requirements List
After collecting and confirming requirements information, create a requirements list and document it. Documenting user requirements has two significant advantages: 1. It ensures effective communication within the project team, reducing internal communication costs and ensuring the integrity of requirements information during transfer. 2. It facilitates the recording and archiving of requirements changes, facilitating tracking and monitoring during project design activities, and ultimately serving as a checklist for solution deliverables.
The requirements list should include, but is not limited to, the requirement name, user, timeframe, type, scenario, item, description, and priority. Furthermore, the actual usage of the item should be described, taking into account user processes and habits, and the requirements should be ranked by importance.
Requirements List
| Requirement Name | Demand users | Requirement time | Requirement type | Requirement scenario | Requirement item | Requirement description | Requirement priority |
Solution Design
After gathering and confirming the requirements, solution design is required. During the solution design process, cost, compatibility, risk management, project implementation, and other aspects should be comprehensively considered, and the functional completeness should be adhered to.
The design concept is based on the principles of reliable performance, advanced technology, easy maintenance, and resource conservation.
LED display screen design typically includes control system design, display screen design, and construction design. The control system design and display screen design are complementary and are generally the responsibility of the supplier. The construction design is typically determined through collaboration between the user and the construction company.
Currently, there are two common installation methods for mainstream LED displays: one is to splice LED modules, and the other is to build an LED cabinet. The former offers flexible solutions, diverse load types, easy maintenance and repair, and low overall project costs. The latter offers a more stable cabinet structure, quick and easy installation, improved splicing smoothness, and the cabinet design, which houses the power supply, receiving card, and various electronic components, makes it safer to use. Therefore, taking all factors into consideration, the splicing LED module installation method is suitable for most fixed display installation scenarios on the market, while the LED cabinet installation method is primarily used for large outdoor screens, high-end fixed display installations with sufficient budgets, and rental applications. Considering the relevance, practicality, and length of LED display applications, this book focuses on control system design within LED display design. Control system design typically includes receiving card design, controller design, accessory design, and an equipment list.
Receiving Card Design
For LED cabinet manufacturers, the market positioning and required functionality of the cabinet product are already considered when the cabinet is designed and released. Therefore, receiving card selection is a key consideration from the outset of cabinet design. Therefore, for control system designs that utilize LED cabinet installation, there's no need to select a receiving card or calculate its load capacity. For example, Absen's AW and DW series cabinets and Unilumin's UGN and UGM series cabinets are sold individually, with the receiving card already integrated and fully debugged. Simply power on the cabinet for normal display.
For control system designs that utilize LED module splicing, the appropriate receiving card selection must be considered based on the collected information. Key factors influencing receiving card selection during control system design include the module's data interface type, the project's specific functional requirements, and the receiving card's data group format. 1. Receiving Card Selection
1) Module Data Interface Type
The data input/output interface of an LED module is typically called a hub interface. It defines the standard "language" used when communicating between the LED module and the receiving card. Currently, there are many different hub interface types on the market, with the most commonly used being the HUB75E and HUB320. Figures 2-2-1 and 2-2-2 show two Nova Nebula receivers: the DH426 (for the HUB75E interface) and the DH436 (for the HUB320 interface).

The difference between the HUB7SE interface and the HUB320 interface lies in their definitions. Modules with a HUB75E interface typically contain two sets of data, while modules with a HUB320 interface contain four sets of data. Therefore, when selecting a receiving card, the module's HUB interface type should be the primary consideration. Incompatible interface types may render the selected receiving card inoperable or inoperable directly, necessitating the addition of a HUB adapter board to convert the interface. This increases project complexity and costs.
2) Specific Functional Requirements of the Project
Based on the information collected from the initial requirements list, we have a clear understanding of the user's specific needs and have determined whether specific functions are required. Therefore, when selecting a receiving card, it is important to carefully consider the user's specific needs and the card's functional features to determine whether a specific model or series of receiving cards is necessary to implement the required functionality. For example, in one project, the user needs to detect and locate (inspect) out-of-control pixels (dead lights) on an LED display. Taking the Nova Nebula control system as an example, the technical solution should include the MON300 monitoring card. This monitoring card can only be used with a specific model of receiving card, the MRVS60, to achieve the above requirements.

There are many other specific functional requirements, such as low latency and HDR. The specific solution requires consulting the relevant receiving card product specifications before selecting a model. If the project does not require such special functional requirements, the receiving card selection is not restricted.
Control system manufacturers carefully consider the market positioning of different models of receiving cards within the same series when designing them, aiming to provide users with more flexible options. Besides the load capacity, another important parameter for different models of receiving cards within the same series is the data group mode, which is also reflected in the number of hub ports on the receiving card. For example, the Nova Nebula DH series receiving cards include 8, 12, and 16 hub7SE ports, respectively. The hub75E is the industry standard, with each port supporting two groups of RGB signal data. Therefore, the DH7508, DH7512, and DH7516 receiving cards support a maximum of 16, 24, and 32 groups of data, respectively. 3) Data Group Mode of the Receiver Card
The data groups corresponding to each hub port are arranged sequentially from top to bottom. The first hub port on the DH7508 receiving card is numbered 1, connecting to the first row of modules and corresponding to data groups 1 and 2. Similarly, number J2 corresponds to data groups 3 and 4. Similarly, number J8 corresponds to data groups 15 and 16.

When selecting a receiving card, the appropriate model is usually chosen based on the module's height. For example, if a project uses modules with a resolution of 160x80 (pixels, all resolutions in this book are in pixels) (HUB75E interface) to create a 720P (1280x7200) display, which receiving card should be selected?
Based on resolution calculations, we know that the LED display is composed of 9 rows and 8 columns of modules. A 9-row array requires at least 9 hub interfaces to support the vertical load. However, the DH7508 receiving card only has 8 hub interfaces, which is insufficient for vertical load. Therefore, the DH7512 receiving card should be selected, using its 9 hub interfaces. The number of DH7512 receiving cards required to fully support the entire display requires further load calculations.
Receiver Card Load Calculation
Receiver card load calculation primarily depends on the total number of pixels supported by the receiving card and the corresponding data group mode used. The calculation method is as follows.
The main considerations for selecting a receiving card model are the total receiving card load capacity and the maximum supported data group mode.
First, consider the receiving card model based on the number of rows and columns of the module. This primarily considers the number of rows. For modules with up to 8 rows, choose a receiving card with 8 hub interfaces, such as the DH7508; for modules with up to 12 rows, choose a receiving card with 12 hub interfaces, such as the DH7512; and for modules with up to 16 rows, choose a receiving card with 16 hub interfaces, such as the DH7516.
Next, optimize the selection based on the receiving card load capacity. Based on the module resolution and the receiving card resolution, you can calculate the maximum number of modules that can be cascaded with a single hub interface and the total number of receiving cards required. If the calculation shows that a single hub interface cannot support a single module, consider adding receiving cards, reducing the number of hub interfaces, or selecting a receiving card with a larger load capacity. Taking the Nova Nebula DH7516 receiving card as an example, if hub interfaces 1-4 are used, the receiving card operates in 8-data mode, and the load capacity of a single data group = the total load capacity of the receiving card / 8. If hub interfaces 5-8 are used, the receiving card operates in 16-data mode, and the load capacity of a single data group minus the total load capacity of the receiving card / 16. If hub interfaces 9-16 are used, the receiving card operates in 32-data mode, and the load capacity of a single data group minus the total load capacity of the receiving card / 32.
Generally speaking, by calculating the number of modules that a single receiving card can support based on the specifications of the receiving cards and modules selected for the project, a reasonable load design can be made. Industry users typically connect as many unit boards as possible within the receiving card's load capacity, thereby reducing the number of receiving cards used and lowering costs.
Controller Design
Controllers, commonly referred to as transmitter cards, are crucial in LED display projects. After selecting and calculating the receiving card load, the model and quantity of receiving cards in the project are basically determined. Next, controller selection and load calculation are performed to determine the model and quantity of controllers in the final solution.
Controller Selection
1) Video Input Source Type
The controller's primary function is to receive video signals from a front-end video source device or computer, process them into differential signals suitable for transmission via a network cable, and then transmit these signals to the receiving card via a network port and cable for display on the LED display. Therefore, when selecting a controller, the type of front-end video input source must be considered. For example, a conference room might need to install a large industrial ED screen, and the user requires that a single camera video feed be displayed on the screen for daily use. The camera typically uses an SDI interface.
Therefore, when selecting a controller, you need to choose one with an SDI interface, rather than just any controller. Taking the Nova Cloud controller as an example, you can choose the MCTRL660Pro with one 3G-SDI interface or the MCTRLR5 with a 6G-SDI interface.

Based on the information collected in advance, we have a clear understanding of the user's specific needs and whether any specific functions are required. Therefore, when selecting a controller, we need to carefully compare the user's specific needs with the functional characteristics of the receiving card and consider whether a specific controller model is required to achieve the corresponding functions.
For example, a TV station wants to install an LED display for live broadcasts. Due to the broadcast characteristics of the station, the LED display image must be synchronized as closely as possible with the live broadcast image, and image delay that affects the broadcast quality is unacceptable. Due to the unique use case, this solution necessitates a specific functional requirement, namely, "low latency." Common controllers on the market typically experience a one-frame image delay due to their inherent characteristics. If the delays on the receiving card and LED display driver IC are factored in, the entire system experiences a 3-4-frame delay, which is easily noticeable to the human eye. Therefore, when selecting the L660 Pro controller for this solution, special considerations should be taken into account. For example, the MCTRL660Pro controller paired with the A8s/A10s Plus receiving card can reduce overall system latency to approximately two frames, with near-zero latency achieved on the controller side.










