This is starting to get annoying…
I get output on them after sending the fm26126A init sequence, but the output is all wrong given the line addressing having changed again. It seems that you only select one of 8 lines, and push 4 times 128 pixels to reach the other 3 rows after filling the first one.
Why, oh why do “they” have to keep changing how to do things? I got those as replacements for a perfectly working ABCDE panel
I think you need to use the PanelMapping feature. Traveling through Wednesday so I can’t help much more until I get back
Hi Louis, no worries. Honestly I wasn’t going to try and make it work at this point, I’m more a bit upset that someone found yet another incompatible way of doing this.
I’ve already contacted the seller for an exchange. I’ll probably get to keep them though due to the price/inconvenience of sending stuff back to China.
But I wanted to share a picture to show that the incompatibility insanity has not stopped.
This is really starting to turn me away from continuing to use those panels if you you can’t reliably order anything that you know will work.
It doesn’t sound like you have a /32 scan panel, despite the label saying so. It’s filling 4 rows at a time - I assume you meant per 4 rows at a time per RGB channel, so 8 rows are lit at a time - and you select one of 8 address rows, so it’s a /8 scan panel, right?
correct, if there are only 3 address lines (ABC), it must be a /8 scan panel where you push 4 rows at at time
I have a panel with 128x64 ABC addressing but still using the IC2037 chip so it works without first writing shift registers. The problem is that the ABC addressing is not working. I get all kinds of weird results. It’s not simply selecting line 0 then writing 512 pixel then line 1 and doing the same thing again.
There is some weird multiplexing going on. Do any of you have an idea how this multiplexing works?
My panel looks EXACTLY like the connector picture (down to the component number) however i tuses the IC2037 chip instead of the FM6126A chip.
ICN2037 (not IC2037) is a common shift register, such as FM6124 or ICN2038, and is not compatible or works the same as FM6126 or ICN2038S.
In any case ICN2037 is not used for the selection of the panel row, for that task other chips are used in the LED panel. If your panel uses a special row selection with some type of multiplexing, the first thing you have to do is contact the seller or the manufacturer so that he can provide you with the corresponding technical documentation. And if they don’t give you information, look at the references of the chips used by your LED panel and search Google for the Datasheet of the row decoder.
Typically, these LED panels use a shift register for the Columns and a Binary Decoder for the Rows. Your problem seems to be to understand how your panel’s binary row decoder works, and that’s not the ICN2037, another chip does.
There has been some progress on
Thanks for the link. I’m working on the ESP32 APA102 to HUB75 converter right now, and I’m making sure that the hardware can support driving these types of panels, as well as sending the reset sequence.
As an update, ABC panels turn out to only be somewhat modified AB panels where B is apparently not used.
They are now supported by rpi-rgb-led-matrix