Compability with non-ABC/D/E panels?

Good morning! I’m working with a 32x32 DIP/1R1G1B panel made up of 2 parallel chains of 4 16colx8row panels each, vertically mapped. It’s a used Optec panel with a board from around 2009, and I’m using rpi-rgb-led-matrix to try and control it since the software it came with doesn’t allow you to do much and is made unnecessary when you can just unplug the controller part and plug in your own.

So far, I haven’t been able to get anything other than scattered/garbled lights using different wiring configurations and cl flags for the demo. I’m thinking this might have to do with the fact that there’s no A, B, C, D, or E on the HUB75 for this board (the colors aren’t labelled 0, 1, or 2 either). I also have doubles of some of the pins. Here is what I’m working with:

R    R
G    G
B    B
OE   OE
GND STB
GND CLK
GND CLK
GND STB

So far, I’ve been treating the RGB on the left side as 1 and the RGB on the right side as 2. I’ve tried a bunch of different wiring configurations, some yielding better results than other but never producing a clearly legible image. I’ve left ABCDE pins on the Pi untouched to avoid trouble. Is there any way this would be able to work?

Thanks in advance.

Not a great answer, but this is basically a very old panel using a different protocol that doesn’t seem supported, and probably won’t be written by someone else. I’m afraid you’d likely have to write your own support for it from a data sheet.

Oh, understandable. What should I be on the lookout for? (Am new to this thing)

I’m not sure what you’re asking for. Those are very old unsupported panels, there is no code for them, and if it’s important for you to get them working and worth your time, you’ll have to learn how to write a driver for them.
There is no step by step process for this, except get the specsheet, read the existing code, and write the missing code :slight_smile:

Oh, of course, I meant where to look for the specsheet. I was handed this project by an older member who said the provider didn’t provide much information.

In the meantime, I’ve been able to mess with it enough to tell that each 16x8 panel acts like it’s two 8x8s but cannot be separated physically without destroying them. It’s far from victory, but at least a step if I need to write this anew.

no idea, sorry, google will be your best friend :slight_smile:

It worked out! Turns out I wasn’t paying enough attention to pull request #1200 and, after adjusting MultiplexMapperBase to allow different values for row and column stretch factor (and remapping the provided coordinates for my board), I was able to get this working and with less wiring to be (it turns out the R2/G2/B2 lines aren’t needed in this one for some reason). Many thanks for this project!

Is there any potential harm (aside from image quality) from running this without the OE wire plugged in? I’m looking for better solutions, but I’ve suddenly faced a huge flickering problem I can’t get rid of without either reducing pwm_bits to 1 or leaving OE unplugged.