Master Bug: HUB320 support

[davidkessler-ch]

So all the matrices listed use HUB75, but for bigger matrices there is the similar HUB320. Are there plans to support that?

I have a 256*128 pixel matrix with HUB320, a 1/64S see here

[wata-net]

There is nothing the library can do about it.
All you have to do is make a conversion cable.

However, most HUB320 LED panels use driver chips with built-in SRAM.
This library does not support driver chips with built-in SRAM. (This is not related to the HUB320 issue.)

[Keniis0712]

There is nothing the library can do about it. All you have to do is make a conversion cable. However, most HUB320 LED panels use driver chips with built-in SRAM. This library does not support driver chips with built-in SRAM. (This is not related to the HUB320 issue.)

I have a special driver chips withnot built-in SRAM and I only find the library for HUB75. How can I use this kind of library to control a HUB320 screen?

[krambs]

Anyone able to get this library working with HUB320 and 256x128 yet? Thanks!

[marcmerlin]

@krambs it's a new setup, new chip, new way to drive it and new cable. Unless you write it yourself or pay someone to write it, it's probably not likely to happen unfortunately.
Also, note that panels that do not have an output plug, cannot be chained, so you'll really want an FPGA card with lots of output cables to run a bunch of those.

[sub-zerohm]

I've looked into this myself, if you lookup Kevtris on YT he has a video of how he reverse engineered one to work with jumpers soldered the NT Mini's NES cartridge pins (with a cart adapter as to not ruin the actual NT) and the open FPGA with his own custom gameboy core....but those are 26-pin connectors, and the pi only has 40 pins. 19 of which are actually not ground pins, but that means you need 38 pins to get one panel working, leaving The possibility for two panels When the clock and ground pins get broken out, which would require a new hat or splicing a jumper. I wish I knew more about designing boards because I would just design the hat with two hub 320ports.... But then you'd run into the obstacle of the sram on the boards

I want to port the library to an NES emulator but I don't think the pi4 can handle it, waiting patiently for the library to come to the pi5 🙌 hzeller is the man. I've forked my own repo of dak0r's GearBoy RGB Matrix because there were updates to SDL that broke the controller inputs. I fixed them but specifically for the ibuffalo SNES clone controller, reason being that it uses axes for the d-pad. I'm a total noob at c++ As well as sdl so I haven't programmed anything on the d-pad yet

Otherwise I've been also looking into vhdl to try and get this on. Mr. Fpga since it has both an fpga and an arm processor. You could run the emulator with arm and send the data with fpga Gates, but you'll probably need the memory upgrade and that only leaves you with 40 pins. Again, same problem the pi has for HUB320 but it could be useful for the other ports

[sub-zerohm]

Actually was wondering if these have sram. Can't tell by looking. I ordered them direct from the supplier. If not I could run jumpers off the raspberry pi pins but would need to mess with the HAT type. They're 1.25 pitch panels, 256x128 resolution. 2 of them would make a perfect retro game screen

It looks like they're using address type c which basically clocks each color twice to achieve the scan rate, but refresh rate that the panel can support is cut in half. I chained two 128x64 panels that use this same addressing type together and you have to go kind of basic on the content or else it will flicker

[rxchit]

I'm also working with one of the panels with HUB320 connectors but the pinout is slightly different, can you guys point in any direction to get it working with pi4/5

[sonycman]

>@sub-zerohm

Actually was wondering if these have sram. Can't tell by looking. I ordered them direct from the supplier. If not I could run jumpers off the raspberry pi pins but would need to mess with the HAT type. They're 1.25 pitch panels, 256x128 resolution. 2 of them would make a perfect retro game screen

It looks like they're using address type c which basically clocks each color twice to achieve the scan rate, but refresh rate that the panel can support is cut in half. I chained two 128x64 panels that use this same addressing type together and you have to go kind of basic on the content or else it will flicker

So is there any luck handling these large 256 x 128 panels?
Could you, please, post some quality photos of your panel, so i could see the chips its using?
Would be appreciated a lot!

[sonycman]

@rxchit

I'm also working with one of the panels with HUB320 connectors but the pinout is slightly different, can you guys point in any direction to get it working with pi4/5!

Hi! Would you be so kind to also repost a better quality photo of panel PCB?
Guys, what a potato cameras do you use!

[sonycman]

@wata-net

Regarding the panels of 256 x 128 pixels (320 x 160mm), HUB320.
Asked vendors on aliexpress, and they have all the different chips:
1: DP3364S
2: ICN1065
3: FM6363C and FM6565C

The first have good datasheet, but without registers description, of course.
For the second i've found nothing.
The third - FM6363 used successfully somewhere here and no problem, dont know about FM6565 though...

But chinese vendors could not guarantee exact chipset with all the panels they sell (its random), so there is no go for now for these big 256x128 panels, am i right?

[martodg]

Hi everyone,
I purchased a 256X128 P1.25 LED module with a HUB75E interface. The chips appear to be DP3364S, DP245D and RUL5158E
I bought the unit from AliExpress:
https://www.aliexpress.com/item/1005006086019360.html
Any idea on how to get the panel to display? I've used other panels in the past and have gotten them to work with variations of the led panel type, gpio slowdown, etc.
Look forward to a response.
Cheers.

[marcmerlin]

@martodg why are you posting in a HUB320 bug when your panels are HUB75E?
It also does not look like you read the documentation
https://github.com/hzeller/rpi-rgb-led-matrix?tab=readme-ov-file#panels-supported
you will find your answer there that your panel does not look supported, and in the future please do not hijack an unrelated bug, please.

[martodg]

Sorry @marcmerlin
I had no intention of hijacking a bug or upsetting anyone. There weren't may posts on 256X128 panels.
Thanks for the update

[marcmerlin]

@martodg you're supposed to make a new issue, not to post in a random unrelated one.
But there aren't posts indeed because those panels aren't supported as per the README.
As of right now, I have not seen a single 128 line panel work with the existing libs, and it's likely because without using PWM the refresh rate would be terrible, and PWM chips are completely different, and unsupported, until someone writes a driver for one of them. No one has offered to do so as of today.

[sonycman]

@martodg
Hi. Successfully running similar panel (DP3364S + RUL5258 + HUB320) on custom hardware (FPGA).
Now just received same panel as yours - DP3364S + RUL5158 + HUB75E.
Seems almost the same both of them, except less data channels on latter, thus it might need higher clock or dual data rate for DP3364...