Awesome library, but can you help with natively controlling a panel?

[MarqueIV]

While this is an amazing library, to get a better understanding of how these panels work, I’m trying to understand the native protocol.

Looking at the pin out, it seems like it’s just a straight-up ‘shift-in-on-clock, then latch, then repeat for each row’ Your typical matrixy stuff where you’re basically treating the row data the same way you would with a straight-up shift register, but flipping through each row fast enough to give you a POV effect.

So, if I’m right, theoretically if I ground all the row selector pins (I have a 64x64 so that’s A-E) I should be controlling the first and 33rd row (since it’s a 1/32 scan) with whatever I shift in, then latch. However for the life of me, I cannot get this to light a single thing!

I’m doing basic bit-banging on the data, clock and latch pins, I can’t get anything to display! I’ve tried OE both high and low, both raising/lowering it, then shifting data, then lowering/raising it, I’ve tried shifting the data, then toggling it high-low-high/low-high-low, and I’ve tried raising the latch at the beginning, then falling it at the end, and the reverse. No matter what I try, I can’t light a single LED.

Now I know from some ST LED drivers (mostly those that do PWM natively), the latches don’t work like typical shift registers where you just ‘toggle’ it at the end of the data. Instead their latch is timed with a certain number of clock pulses to perform the latching or executing a command. For instance, opening the latch for three clock cycles, then closing it shifts in the PWM data whereas latching it for four-five cycles sets some other ‘control’ settings. Is that how these work? I’m highly doubtful, but I can’t think what else would be doing this, and one other vendor’s panel does do something like that.

So again, can you help explain how to blink some LEDS bit-banging? Again, the ultimate goal will probably end up using your library, but I just like knowing how things work.

So... can you help?

Thanks!

M

[hzeller]

First of all: does you panel work with this library ? (because if not, then there might be other reasons).

If you have confirmed that: typically the panels don't like if you just output data to one line, they have an overcurrent protection to not overload single LEDs; so they typically want you to do the scanning, otherwise they switch off the LEDs. Same if Output-Enable is on for too long.

In general: you clock in the data with RGB=data and clock being the shift register clock. Then you need to wiggle the latch to put the clocked-in line to the output. Then pulling Output enable low will switch on the line.

You find the relevant code in this loop in framebuffer.cc

[MarqueIV]

Interesting about the overcurrent. Didn’t even know that was possible. But it does make sense. Still, as you were saying, it does appear to just operate like a standard shift register.

One thing you said that has me questioning the logic behind it. You said it doesn’t like it if you only shift in one row. Wouldn’t simply tying the other five to ground be sufficient? After all, a black screen is a valid screen.

Speaking of ground, Do all the grounds pins have to be connected, or is connecting one of them enough? Unfortunately my multimeter’s battery is dead or else I would simply as a continuity tester to check that.on a typical panel, do all the ground pins have to be connected, or is connecting one of them enough? Unfortunately my multimeter’s battery is dead or else I would simply use a continuity tester to check that, And ironically I don’t have any standalone legs that I could use as well.

And no, I have not yet tried my specific board with your library because I didn’t have any of the Adafruit boards, but I have now put one on order. I bought my panels from Amazon.

Can you confirm thing like clock polarity, OE polarity, and things like that? For instance is OE high or low for showing the data?

[hzeller]

You don't need a board, you can also manually wire things. But sometimes still voltage converters are needed.

Some boards don't work at all unless initialized with some init sequence, this is why I suggest to first test it with the library.

Ground pins: depends on your panel, but typically they are all connected.

Polarity

• ~OE low means 'on'. Typically in the range of 100's of nanoseconds to a few milliseconds
• Clock: positive edge
• Latch, aka Strobe: positive edge.

[MarqueIV]

Aaah! I already have my board wired up like that. Didn’t know I could simply use your library that way. Things are just getting better here!

Question, I have some 5v boards but they’re 32u4-based ones like the Arduino Leonardo. Pretty sure they don’t have enough memory to be able to drive one of these panels in RGB. Can you use your library to just do a single color without shading to perhaps take the mem footprint down to 1/72 the size?

If not, I do have some Teensy boards, including the new Teensy 4, and I’m pretty sure I have some level shifters somewhere.

By the way, where did you learn about the protocol? Or did you just treat it like a shift register? You mentioned some initialization so that is definitely not in the realm of a pure shift-registers-in-parallel design.

[hzeller]

If you want to run the code on a Microcontroller, you'd have to implement that directly there. This library here is too big to fit there and also makes very specific accumptions of the GPIO layout of the Raspberry Pi.

When I first got a panel (in 2012), I quickly wrote a few lines of code that just did 8 colors, and that was sufficient for the memory there.

Protocol learning: moslty educated guesses :)

[MarqueIV]

Well can you help with the ‘education’ part of that? For instance, thinking they’re just simple shift registers appears to be incorrect as code that works with a shift-register-based breadboarded design doesn’t work on this. Plus, I read somewhere that the outputs are by default ‘off’ and you have to configure the chip to enable them, then even when you do, the latching code is somehow synced with the clock, not simply latched at the end, again, like a normal shift register. That’s what we’re struggling with... knowing if that is a) true, and if it is, b) what the protocol for that is. Can you comment?

[hzeller]

Educated guess essentially means: you start out with an assumption 'how would I implement such a device if you do it yourself', then verify if this assumption is true or needs to be modified. You get hints by looking at what kind of signals are there, and if they are named, how. Then deduce from previous knowledge (CLK typically means 'clock') what this could mean. So the 'educated' part is essentially the experience gained from having done such thing before or dissecting other devices that do something similar to then help have a more directed approach in figuring out how things work.

In our case, we need to clock in the data (this is what CLK and the various RGB data is), and once done, we somehow need to tell the shift register to output everything to the parallel output, and indeed, we find that there is a LATCH line that does that). That is functionality that is found in shift register. And yes indeed, you need to sync the latch to only trigger once you clocked in all the data.

Now to control individual brightness beyond just binary on/off, we need to switch the LEDs on; for such a set-up, we only can do Binary Code Modulation if we want multi-bit resolution, so we need some sort of output enable that allows to set the LEDs on for a specified time ... and this is where the ~OE line comes up.

To simplify construction, it can be assumed that there is some sort of multiplexing, so lines that are called A..D are suspiciously indicating that.

So assuming how tings would be implemented with something just looking at the name of the signals and a bit of experimenting the helps to figure that out.

The initialization codes needed for some panels can be found in datasheets if they are available. Unfortunately, the whole world of LED-matrixes is not very well documented. The 'all LEDs are off initially' is for instance a property of the FM6126A chip that is used in some recent RGB matrix. And it took some people who have access to the panel to figure out the details.

[MarqueIV]

Of course! As you just pointed out, which echoed what I had already pointed out, you’d think it acted like a collection of shift registers except you have to manually do the row scanning. But as I had also pointed out, code written for a shift-register design didn’t work with the panels because the latching of some seems to be in sync with the clock (i.e. for a few clock cycles as the last data is still being shifted out as opposed to latching after the data had all been shifted out.) We’ve seen things that show latching during the last three or four clock cycles handles the actual outputs, while holding open the latch for a little longer... five or six clock cycles... instead gets into configuring the output enables per-pin as opposed to per-chip on the OE pin. A longer clock-cycle at the end sets the ‘current balancing’ per pin so you can tune each panel accordingly. Again, it’s not a simple ‘shift in these x bits, set the row-select, then latch which would be the case for a plain shift register design. In our case, even manually bit-banging the data, clock and latch pins along with the correct row-select pints (there is no OE on our panel) results in nothing being displayed. We were, for instance, trying to illuminate a single color of a single pixel (top left) but couldn’t get it to light. That’s why I was reaching out here... to see if you knew of the ‘special sauce’ that would be above and beyond what someone would do with a simple shift-register design would need as it seems HUB75-based panels do need that little extra config to get them to work.

No worries... I’ll keep looking, but thanks for taking the time to write what you did.

[hzeller]

What you are describing sounds more like some of the newer chipsets that include higher-level logic in the protocol (such as the FM6126A). For these, it is best to try to source a datasheet, but unfortunately, they often don't exist.