A large LED matrix can look perfect on the bench and become unreadable when you increase panel count, refresh rate, brightness, or cable length. Flicker, ghost pixels and uneven brightness are usually not mysterious software bugs. They come from timing, current delivery, signal integrity, multiplexing, or a combination of them.
Start with the display architecture
Most large RGB matrix panels are multiplexed. The controller does not power every LED continuously. It selects a row group, shifts pixel data into driver registers, blanks the outputs, latches the new data, selects the next row, and enables the LEDs again. This cycle repeats fast enough that the eye perceives a steady image.
That means apparent brightness depends on peak LED current, PWM duty cycle and the fraction of time each row is active. Adding more scan rows or increasing color depth without preserving enough refresh bandwidth can reduce brightness or create visible flicker.
1. Refresh rate is too low
If a complete frame is refreshed too slowly, the eye or a camera can detect the scanning. The problem becomes more obvious with peripheral vision, dim PWM levels, moving eyes, or video recording.
Do not judge refresh quality only from a static phone photo. Measure the row timing with an oscilloscope or logic analyzer. Determine the full-frame refresh rate after accounting for row scans and PWM bit planes.
2. Output enable changes at the wrong time
Ghosting often occurs when LEDs remain enabled while address lines, shift data, or the latch signal is changing. For common HUB75-style panels, the safe sequence is conceptually: disable output, shift/latch the next pixel data, change the row address, allow signals to settle, then enable output.
If output enable overlaps a transition, the panel can briefly display old column data on a new row or new data on the previous row. The result is faint duplicate pixels or horizontal ghosting.
3. Row-address timing is marginal
Large matrices use row address signals such as A, B, C, D and sometimes E. Those signals need valid setup time before the LEDs are enabled. Long cables, level shifters, GPIO drive characteristics and chained panels can slow edges enough to make timing that worked on one panel unreliable on several.
Use a logic analyzer to compare the row-address transition, latch pulse and output-enable window. If ghosting changes when you reduce clock speed or insert a short blanking interval, timing is a strong suspect.
4. The power supply is sized for average current, not worst case
RGB matrices can draw large pulsed currents. A supply that looks adequate from an average reading can still produce voltage droop during bright patterns. That can reduce brightness, corrupt logic or reset the controller.
Measure voltage at the panel power connector while displaying demanding patterns such as full white. Measuring only at the power-supply terminals hides cable and connector losses.
If the controller itself resets under display load, use the same power-integrity reasoning described in our ESP32 brownout and random-reset troubleshooting guide.
5. Power injection is inadequate
Feeding several panels through one thin cable or daisy-chaining all current through board connectors creates voltage drop. Panels farther from the supply may appear dimmer or change color because the red, green and blue channels do not respond identically as supply voltage falls.
Use appropriately sized conductors and distribute power to multiple points rather than forcing the entire display current through one long path. Keep grounds common and low impedance.
6. Logic voltage levels are marginal
Many microcontrollers use 3.3 V GPIO while some matrix-panel logic is designed around 5 V logic families. Whether 3.3 V is reliably interpreted as HIGH depends on the actual input device and its datasheet, not on the fact that one prototype happened to work.
For a robust design, inspect the panel’s buffer/driver part numbers when possible and compare their VIH/VIL requirements with the controller’s VOH/VOL specifications. Use a suitable level translator or buffer when the logic margins are inadequate.
7. Fast signal edges are ringing
Clock, latch and output-enable lines can behave like transmission lines when edges are fast relative to cable delay. Ribbon cables, adapters and long daisy chains add capacitance, reflections and crosstalk. A clock line that rings across the receiver threshold can be interpreted as more than one edge.
Probe the signal near the receiving panel, not only at the microcontroller. Shorter cables, a solid ground reference, sensible connector pinout and source-series termination can improve integrity. Choose resistor values from measurement rather than copying an arbitrary value.
8. The software cannot feed the panel deterministically
High-resolution RGB PWM requires precise repetitive timing. If refresh is generated by blocking application code, network activity, interrupts or task scheduling can stretch the scan interval and produce brightness modulation or flicker.
Use hardware peripherals, DMA and timer-driven refresh where the platform and library support them. Keep application work separated from the time-critical display engine.
9. More color depth consumes refresh budget
Binary-coded PWM commonly gives higher-order color bits longer display intervals than lower-order bits. Increasing PWM depth improves theoretical color resolution but consumes more timing budget per frame. On a large panel chain, pushing color depth too far can reduce refresh rate below an acceptable level.
Trade color depth, panel count and refresh rate deliberately. A stable 8-bit-looking display can be better than nominally higher precision that visibly flickers.
10. Panel chaining exceeds the practical timing margin
Every added panel increases the number of bits shifted per row. At a fixed shift clock, that increases the time needed before the next row can be displayed. Raising the clock can recover bandwidth, but eventually signal integrity becomes the limiting factor.
When a one-panel system works and a four-panel system does not, do not immediately rewrite the drawing code. Compare shift duration, clock waveform, latch timing, supply voltage at the last panel and the effective full-frame refresh rate.
A diagnostic sequence that avoids guessing
- Display solid red, green, blue, white and black test patterns.
- Measure supply voltage at the first and last panel under full-white load.
- Check controller reset/brownout logs.
- Capture CLK, LAT, OE and row-address signals with a logic analyzer.
- Calculate full-frame refresh rate from the measured scan sequence.
- Temporarily shorten the data cable and reduce the panel chain.
- Reduce shift clock; if artifacts improve, investigate signal integrity.
- Increase blanking around row/latch transitions; if ghosting improves, investigate timing.
- Test with networking and other high-load firmware features active.
- Repeat the test after the display has warmed up.
Do not “fix” electrical faults with random delays
A delay can hide a marginal timing or signal-integrity problem, but it also reduces refresh bandwidth. If a delay improves the image, treat that as diagnostic evidence. Measure which setup, hold or settling interval was marginal and correct the underlying design.
Primary references
- Texas Instruments SN74HC245 datasheet and logic-level specifications
- Espressif ESP-IDF RGB LCD timing and DMA documentation
Bottom line
Large LED matrices are real-time mixed-signal systems: software timing, digital signal integrity and power distribution all affect what you see. Flicker points first to refresh timing and scheduling; ghosting points to blanking, latch and row-address timing; brightness loss across a panel chain points strongly to duty cycle or voltage drop. Measure those three domains separately before changing code.