An RCFGX file is best understood as a parameter map for the receiving card. It is not a generic file that can be imported because it has the same pixel pitch or a familiar filename. It may contain module scan settings, data-group exchange, row/column direction, port mapping, grayscale, refresh, control mode and display-area information. After a card or module is replaced, an incorrect file can cause a distorted image, wrong direction, colour inversion, partial display or abnormal brightness.
The first rule is to back up before editing. When the screen is working, save the current receiving-card configuration, sending-device setup, cabinet map, control-software version and screen photos. Use a project, zone, date and device identifier in the filename. Do not keep “customer A,” “temporary,” and “final” files in one folder, and do not rely only on screenshots. A screenshot cannot restore every parameter.
The second rule is to verify the target. The configuration must match the receiver firmware, module structure, scan mode, driver IC, HUB arrangement and physical cabinet. The same pitch does not mean the same module. The same cabinet size does not mean the same HUB. Even within one product family, different batches or scan structures may require different settings. The current NovaLCT user manual should be used together with the actual receiver and module documents.
The third rule is to change one variable at a time. Save the current state, select one known-good cabinet or receiver for comparison and change only one parameter. If the test configuration is temporary, save it as a new version instead of overwriting the original. A successful “send” message only confirms that the software wrote data; it does not prove that the cabinet parameters are correct.
After sending a configuration, test four groups of images: black for unwanted light, white for brightness and dead pixels, red/green/blue for channel behaviour, and grayscale/gradients for low-gray performance. Then test text, a grid and moving content for mapping and refresh behaviour. Camera acceptance requires the actual camera, shutter and brightness conditions. Record the file name, operator, time and result.
During remote support, request the RCFGX filename, receiver model, firmware, software version, affected cabinet location and before/after photos. State whether a point is confirmed, likely or still requires factory/site confirmation. If the file may come from another project, stop the write operation and return to the original backup. Never use another customer’s RCFGX as a trial.
The final handover should contain the configuration backup, a configuration-change log and the cabinet/port map. When a module, receiving card or controller is replaced in the future, the engineer can compare the evidence before changing anything.
The configuration record should also state what the file does not contain. A receiving-card file does not repair a damaged power supply, a broken ribbon cable, a wrong cabinet cascade or a controller that is not sending data. A processor scene does not automatically define the receiver’s scan mode. This simple note prevents customers from expecting one file to solve a fault at another layer.
When a configuration is sent remotely, request a screenshot of the exact project, receiver model, number of selected cards and send result. Ask for a short video after the write operation using grid, black, white and RGB patterns. If the display has multiple independent zones, identify the zone before sending. Do not send a file to every receiver simply because one cabinet shows an error; isolate the target first.
If the display is working with an older configuration, preserve that working state while compatibility is investigated. Software version and controller/receiver firmware are separate items. A customer may be using an older but stable combination, and changing the firmware “to see whether it helps” can create a second problem. A controlled service record is more valuable than a fast but untraceable configuration change.
When a project uses a reseller, keep the configuration package understandable to a third party. Use English filenames, a short readme, a cabinet map and a list of equipment versions. Do not send only a raw RCFGX file with no explanation of the target screen. A future engineer may not know whether it belongs to the centre screen, a side screen, a spare receiver or a test cabinet.
Frequently Asked Questions
Q1: Why is the screen still distorted after an RCFGX import succeeds?
A successful write does not prove compatibility. Check firmware, module, scan mode, HUB, data group and port direction.
Q2: Can we download a configuration for the same pixel pitch?
It is not recommended. The configuration must match the actual module, receiver and cabinet.
Q3: After replacing a receiving card, is sending the configuration enough?
No. Also check address, cascade order, firmware compatibility, power and ribbon cables, then test the cabinet.
Q4: How should configuration versions be managed?
Name them by project, screen zone, date and device identifier. Keep the original, test and rollback versions separately.
