Repository navigation
Waveshare HUB75, 4 chain of 64x64 not working #5826
Description
Activity
@al3ph 64x64x4 is quite a demand even for -S3, because the driver's own pixel buffer must fit into RAM (not PSRAM) - around 128Kb. Plus another 100KB for buffers required for the WLED core.
Usually if the display stays black after reboot, it means there is not enough free RAM.
If you configure the display as a single 64x64x1, it's normal that you see the same image on all 4 panels, this is a feature of the HUB75 chipset - WLED only sees on 64x64 display in this case.
We should probably port the bit depth reduction code over from WLED-MM. This would directly reduce the driver's internal buffer size, for the cost of color accuracy.
A debug output would be helpful to see what is going on. Also please check if #5744 helps with this issue and if you see any image tearing using that.
edit:
in general, if heap is running low it should fall back to PSRAM - I recently changed some code in that regard but can't recall in what PR exactly, it may be in the one I just linked.@DedeHai I think it's the drivers own "PWM" DMA buffer - this one is the largest chunk that usually cannot go into PSRAM. But you're right, reducing RAM usage might help to keep enough free space for HUb75 output.
Reacted by Damian Schneider- changed the title
[-]Waveshare HUB75, 4 chain not working[/-][+]Waveshare HUB75, 4 chain of 64x64 not working[/+]on Aug 30, 2026 Yep, I did wonder if memory usage might be the issue, the device responds on the network and I can connect, so it's not totally dead.
Reduced bit depth would be a handy compromise, are there any options I can tweak in the UI to reduce memory usage, I tried setting transitions to 0, but that didn't seem to help.
I'll try spinning it up with debug tomorrow, is that an option in the web UI, I couldn't spot it?
@al3ph I've reproduced your problem with 16.0.1. There are two bugs actually
- off-by-one error when checking for MAX_LEDS
- division by zero in ABL code when output initialization failed (total LEDs = 0).
I'll prepare a bugfix.
Reacted by AlReacted by Will TatamReacted by Will TatamAh cool, so "might" not be a memory issue. I'll give it a spin when it's available.
@softhack007 I already fixed the first one in one of my open PRs. the second one I did not
@DedeHai thanks, i'll try to avoid merge conflicts. I'll also implement a color depth reduction for > 192x64
RAM usage with 24bit per pixel:
=== Memory Info === DRAM 8-bit: Free: 31016 bytes | Largest block: 17396 bytes PSRAM: Free: 8173003 bytes | Largest block: 8126452 bytes RTC RAM: Free: 7784 bytes | Largest block: 7668 bytesRAM usage with 18bit per pixel:
=== Memory Info === DRAM 8-bit: Free: 65804 bytes | Largest block: 56308 bytes PSRAM: Free: 8174339 bytes | Largest block: 8126452 bytes RTC RAM: Free: 7784 bytes | Largest block: 7668 bytes- linked a pull request that will close this issueHUB75: correct handling of 128x128, fix div/0 in ABL (fixes #5826) #5828
on Aug 31, 2026 - added a commit that references this issue
on Sep 1, 2026 - added a commit that references this issue
on Sep 1, 2026 @al3ph a fix is now available in the latest source code - both in
main17.0.0.-dev and in16_x16.0.1-dev.Your ticket was auto-closed by GitHub when i merged the fix, please confirm if it works for you now.
Cheers, will do once I've worked out how to compile it.
Reacted by Frank MöhleTested and working cheers for the fix.
Unfortunately the order I have to place the panels in doesn't match the layout hardwired into the 2x2 grid.
Is there anyway of controlling the pixel layout ?Currently my outer corners are in the middle or the grid.
Reacted by Frank Möhle@al3ph there might be a way, but I've never tested it.
Basically you can use the "2D setup" with HUB75, if you configure your panels as a 1x4 grid.
- LED settings: chain length 4, 4 rows x 1 column
- 2D settup: configure 4 matrix panels, 64x64 pixels each. First pixel = top left, no serpentine.
- now you'll need to experiment a bit - place panels using offsets. Rotate panels by changing "top left" to "bottom right".
This is a bit unusual for HUB75, but it should work if the HUB75 driver is configured for a layout where all panels are stacked in 1 column.
Reacted by AlYup just worked that out for myself, working correctly now ! Thanks everyone for the help
What happened?
I connected 4 64x64 HUB75 panels to my Wavershare board, using the waveshare binary 16.0.1 from the releases page, configured as a single panel but with all four attached, things worked as expected the same image appears on every panel.
But when changing the chaining value to 4, the displays are all black, using chaining with the value set to 3, it works as expected.
To Reproduce Bug
As above, it seems setting the chain count to 4, in a 2x2 grid using 64x64 panels, doesn't appear to work as expected.
I configured the panel in the 2D settingsm, as a single 128x128 array.
Expected Behavior
Panels are not black.
Install Method
Binary from WLED.me
What version of WLED?
16.0.1
Which microcontroller/board are you seeing the problem on?
ESP32-S3
Relevant log/trace output
Anything else?
Link to board in question.
https://docs.waveshare.com/ESP32-S3-RGB-Matrix
Binary installed.
https://github.com/wled/WLED/releases/download/v16.0.1/WLED_16.0.1_ESP32-S3_Waveshare_HUB75.bin
Code of Conduct