Troubleshooting Common PixelHue Issues (Checklist)

PixelHue is an image processing layer for LED systems requiring multiple sources, multiple layers, and direct operation. When issues arise, the effective solution is not to replace the device immediately, but to troubleshoot sequentially: source computer, cables/ports, network, processor, output card, receiver card, firmware, and finally, support logs. This article is for technicians in event stages, studios, control centers, and operations teams who are or have been using PixelHue in Vietnam.

For systems using PixelHue Q8, PixelHue P20, or PixelHue P10, common issues may share similar symptoms but differ in causes. A black screen could be due to the computer not outputting the correct resolution, a gray background might stem from a layer with no source, and sync drift can originate from a single point in the output chain. The checklist below addresses each issue, with each item including symptoms and step-by-step solutions for immediate field use by the operations team.

Why can't Triton or U3 software find the device?

Common symptoms include the software failing to scan devices, devices not appearing in the control list, or computer operations not affecting the processor. For Triton/U3, this should first be treated as a connection and service status issue, not a hardware fault. In event stage environments, control networks often pass through switches, with numerous temporary cables and multiple computers, making even a single point of failure sufficient to prevent the software from seeing the device.

The first step is to check ping, network, and cables. Confirm that the control computer and the device are on the same accessible network, network cables are securely connected, network ports are correct, and there are no obvious physical damages. If ping fails, troubleshoot the network layer first: change cables, switch ports, or recheck the computer's network configuration. If ping is successful but the software still doesn't see the device, wait for the device to come online in the service section, as some devices require time to reappear after the service initializes.

If the device remains offline, perform a controlled restart: software, control computer if necessary, then the PixelHue device. Specifically for U3, use the key combination Ctrl+Alt+Shift+T to access the ping/port check screen, then reconfirm the connection path. If network, service, and restart steps do not resolve the issue, then consider replacing the control card. This approach avoids replacing components when the actual cause is merely a cable, port, or an unavailable service.

How to handle PixelHue not receiving signal from the computer?

Symptoms of this issue include PixelHue not receiving input signals from a laptop or workstation, no image appearing in preview/program, or the computer source appearing unstable. A common mistake is for technicians to focus on the processor first, while the cause might lie in the computer's output resolution or the operating system not recognizing the display properly. For broadcast studio workflows, this issue must be addressed from the source computer before making deep configuration changes within the device.

First, change the computer's output resolution to match the input currently used on PixelHue. Then, open Display settings to check if the computer recognizes both displays, especially when one display is the laptop screen and the other is the image processing device. If the operating system doesn't recognize all displays, PixelHue won't receive the correct signal even if the processor is functioning normally. If necessary, change the computer's display mode to ensure the source is actually being output to the desired port.

Next, swap cables, ports, and test with another computer. This is a simple yet highly valuable step as it quickly isolates faults between the source, signal cable, and processor input. If the system requires automatic network provisioning for a part of the control path or configuration, enable DHCP as needed to avoid incorrect addressing. For projects using multiple processors or layers of equipment, it's advisable to record which ports were tested, which cables were swapped, and which computer provided a stable signal to avoid repeating test cycles.

Why does the LED screen show a gray background and where to check?

A gray background can be misleading as it resembles a screen or receiver card failure, but within a PixelHue system, it can originate from various layers. Symptoms include the LED screen not displaying the intended content and showing a gray background instead, which may appear full-screen or in sections. When encountering this situation in a command center or on stage, the goal is to determine if the gray background stems from the layer, the receiver card, or the output color range.

The first step is to check if the layer is set to 'No source'. If a layer has no source but is still being output, the screen might display a background error instead of a typical signal loss error. Turn off unused layers, reassign the correct source, or switch to a confirmed active source. If the system has multiple layers, check each layer sequentially to avoid a blank layer obscuring content operating underneath.

The second step is to check if the receiver card itself is set to a gray background. If the receiver card generates its own background, the issue is not entirely with PixelHue. The third step is to change the graphic output from 'Limited' to 'Full', as an incorrect color range can cause the background and dark areas to display abnormally. If these steps do not resolve the issue, consider updating the firmware according to the specific device model. For those new to the ecosystem, the article What is PixelHue? provides a clearer understanding of the processor's role in the entire LED chain.

How to fix unsynchronized output on PixelHue?

Unsynchronized output typically manifests as jerky images, screen areas not matching in timing, or multiple outputs not running on the same time reference. This is a sensitive issue during live programs as the audience can immediately notice when cameras, media servers, or LED areas are out of sync. With PixelHue, both the output card after diagnosis and the sync line between components, as well as how multiple devices share a sync reference, need to be checked.

Begin by checking the output card after diagnosis. If an output is malfunctioning, identify whether the fault lies with the card, port, or output configuration before intervening elsewhere. For the F series, synchronization passes through the sub-card/AUX connector; a single faulty link in this chain can cause sync loss. Therefore, do not just look at the final output, but check each connection point in the sync path to find the faulty segment.

In situations requiring program continuity, temporarily swap the top-left output if this helps stabilize the critical display area. This is a temporary operational measure and does not replace root cause diagnosis. If the system uses multiple devices, use a common genlock to ensure all devices adhere to the same sync reference. The article switcher vs splicer is also useful for distinguishing between switching errors, zone splicing errors, and output sync errors.

What are the steps for upgrading PixelHue firmware?

Firmware can be related to some operational errors, but upgrading should not be the first action for every issue. Before upgrading, ensure the correct model, package, and procedure are identified. For consoles, the process involves copying the .zip package (approx. 500MB) to a USB drive, opening the upgrade tool via Ctrl+Alt+Shift+I, selecting the package, and then upgrading. During this process, do not remove the USB, disconnect power, or perform overlapping operations on the device.

For PixelHue P20 and PixelHue P10, the procedure is via Advanced settings, then Device upgrade. The device will reboot automatically after the upgrade, so choose a time that does not affect the program or have a backup plan if on-site. Recording the version before upgrading, the device model, and the time of execution also helps the support team with cross-referencing if errors occur afterward.

A specific scenario in the technical documentation involves the T7 version getting stuck at 10%. When this occurs, use the log tool to clear the database and then reboot. Do not repeat the upgrade process multiple times if it remains stuck at the same point, as this does not add diagnostic information. After rebooting, recheck the device status, control software, and output signals before officially bringing the system back into operation.

How to correctly export PixelHue logs for support?

Logs are the most critical data for support from PixelHue or Luxwave, as they record device and software status close to the time of the error. A description like "lost image" or "not syncing" is often insufficient for remote diagnosis. When requesting support, include the model, photos or videos of the symptoms, a basic signal diagram, troubleshooting steps taken, and the log file specific to the device model. This helps the technical team avoid asking for background information that could have been prepared in advance.

For Unico, retrieve data from the logs folder. For P20/P10, export logs via the LCD or U Server SDK, following the path Advanced then Log export. For U5/U5 Pro, plug a USB drive into the device, go to Settings, then select log export. For Q8/D32, logs can be exported via LCD, U server, or SDK. Each model has its own procedure, so it's essential to follow the correct model's path rather than looking for a universal button for all devices.

After exporting logs, name the file according to the project, model, and time of the error for easy cross-referencing by the support team. If the issue involves signal loss from the computer, also provide information on Display settings and the cables/ports tested. If the error is unsynchronized output, include a description of the output card, the sub-card/AUX path if applicable, and the genlock status. For genuine PixelHue systems purchased through Luxwave, complete log data significantly reduces troubleshooting time compared to mere descriptions of the phenomenon.

Conclusion: Which checklist should be used before concluding hardware failure?

The practical checklist should follow the order of least risk first, with deeper interventions later. Start with the signal source: resolution, Display settings, cables, ports, and try another computer. Next, check the control network: ping, network cables, service, DHCP if needed, and controlled restarts. Then, check image configuration: layer No source, gray background from the receiver card, Limited/Full graphic output. Finally, proceed to the output card, synchronization, firmware, database, and the possibility of control card replacement.

For high-end LED projects, the main challenge is not just fixing the error, but fixing it in the correct order to avoid introducing new risks during operation. If the system is on stage, in a studio, or in a control room, meticulously record each step taken, the before/after status, and the corresponding logs. Luxwave can assist with signal diagram interpretation, selecting appropriate PixelHue configurations, and providing technical coordination for the Q and P series within the PixelHue product cluster in Vietnam, especially when projects demand stability beyond minimum configurations.