Need help with 64x64 module p3.9

[iwanestem]

Hello sir, I have 64x64 full color rgb module, not sure the brand, the connector is

Iam use the old Raspberry pi 1 with 26 pin, and when i test with: sudo rpi-rgb-led-matrix/examples-api-use/demo -D0 --led-rows=64 --led-cols=64

the result is.....

what's wrong with this, please help me. thank you verry much sir

[hzeller]

Did you play around with a couple of --led-multiplexing options ? There are only A, B, C so it can't be a regular multiplexing that would A, B, C, D, E.

The SR though is suspicious, not sure what that is. You might want to also try --led-row-addr-type=1.

But it could well be that it might not work. It looks close, so it is probably not too hard to reverse engineer what is going on and adapt the code.

For now, I suggest to play around with various combinations of --led-row-addr-type and --led-multiplexing.

[iwanestem]

hello again sir, thaks for you reply,

i try with this combination: sudo rpi-rgb-led-matrix/examples-api-use/demo -D0 --led-rows=64 --led-cols=64 --led-row-addr-type=1 --led-multiplexing=1 sudo rpi-rgb-led-matrix/examples-api-use/demo -D0 --led-rows=64 --led-cols=64 --led-row-addr-type=1 --led-multiplexing=2 .... so on

sudo rpi-rgb-led-matrix/examples-api-use/demo -D0 --led-rows=64 --led-cols=64 --led-row-addr-type=2 --led-multiplexing=1 sudo rpi-rgb-led-matrix/examples-api-use/demo -D0 --led-rows=64 --led-cols=64 --led-row-addr-type=2 --led-multiplexing=2 and so on..

nothing hapened with the matrix module, only blank screen.

but, when i try with this code:

sudo rpi-rgb-led-matrix/examples-api-use/demo -D0 --led-rows=64 --led-cols=128

matrix like this:

[davemaster]

Greetings,

try using "--led-gpio-mapping="regular-p1" (or send a picture of your wiring) with your demo call, also, send a close picture of yout panel hub75 diagram

[iwanestem]

Hai dave, thanks for your reply,

the wiring is...

and i try with code: sudo rpi-rgb-led-matrix/examples-api-use/demo -D0 --led-rows=64 --led-cols=64 --led-gpio-mapping="regular-pi1"

the result back to...

[davemaster]

ok, can You tell me the model of your 64x64 panel? and the scan rate ? (1/4, 1/8, etc) looks like those chinese You can handle using --led-multiplexing, with my chines P10 panels 32x16 panels works the --led-multiplexing=8 option

Other thing, your connector picture is wrong. Check again the D and E lines.

[iwanestem]

Hai again dave, connetion is not wrong, the hub75 is solder side view, btw tommorow i will try with - - led-multiplexing=8.

Thanks dave

[davemaster]

ok, the important thing is the 64x64 panel, try and share restults.... also share the place you bought the panel.

[iwanestem]

hello again dave,

I just tried again with code: sudo rpi-rgb-led-matrix/examples-api-use/demo -D0 --led-rows=64 --led-cols=64 --led-gpio-mapping="regular-pi1" --led-multiplexing=8

nothing happened with the module, blank..

i am not sure with place suppliers, my office bought 12 x 4 meters with many modules like this. the brand is Unilumin, and usually use a receiving card with type Novastar MRV300.

[davemaster]

Try this

try this panel as 4 of 32x32: --led-chain=4 --led-cols=32 --led-rows=32 --led-pixel-mapper="U-mapper"

[iwanestem]

nope, nothing happened too...

[iwanestem]

and this is foto when i try code: sudo rpi-rgb-led-matrix/examples-api-use/demo -D1 rpi-rgb-led-matrix/examples-api-use/runtext.ppm --led-rows=64 --led-cols=64

[hzeller]

At this point it is clear that the culprit is the SR thing of which we don't know yet what it means.

If you have A, B, C but no D and E but an SR instad, this means that this panel has a different row addressing. Maybe it stands for 'strobe row' of some sort ? Maybe it divides the upper and lower half into two separate sub-panels, that then each are an 1:8 multiplexed ? Or maybe it divides the 5 bit into an upper and lower part ? You have to systematically reverse engineer that. E.g. by testing it with

  --led-rows=32 --led-cols=64 --led-multiplexing=<one of the values as we expect it to be 1:8>

then doing that with two experiments, not connecting SR to anything but one time you pull SR down and the other time up. If that lights up the lower and upper half of the panel, this would give a clue. But maybe it is edge triggered, then that would require some different experiments.

So systematically reverse engineer it and if you find a datasheet that would also help. Once you have figured it out, in the simplest case, you just have to write a RowAddressSetter implementation for it. If it is an upper and lower half thing, we might need a bit for that.

Since you're the first with such a panel, future users of this panel will count on you :)

[davemaster]

Greetings,

Parallel to writing a new RowAddressSetter for your panels (pls, the manufacturer and model) you can try this https://github.com/hzeller/rpi-rgb-led-matrix/issues/66#issuecomment-228372118

[iwanestem]

Hallo again dear Dave and Hzeller,

I just tried again with disconecting SR pin and "D" pin, and i use code: sudo rpi-rgb-led-matrix/examples-api-use/demo -D1 rpi-rgb-led-matrix/examples-api-use/runtext.ppm --led-rows=32 --led-cols=32 --led-chain=2 --led-multiplexing=6 the result is....

with code: sudo rpi-rgb-led-matrix/examples-api-use/demo -D0 --led-rows=32 --led-cols=32 --led-chain=2 --led-multiplexing=6

result:

the brand i think is "UNILUMIN" P3.9

[davemaster]

Greetings,

You almost done... had You tried all multiplexing options? (ie. 1-10) . Try using --led-row-addr-type=1 as hzeller indicated You. You need a little push to get "Eureka" status. The ppm runtext.ppm is a 32 pixel height text, so, the right way of panel show it is at middle top half; so, with your last command; so, try with --led-rows=16/64 height, and --led-chain=8/2

[iwanestem]

hai dave, i try with no luck, this a link panel distributor... http://www.unilumin.com/productdetail.html?ClassId=14&Id=3

[SexualMoose]

Hi, I picked up a bunch of these exact panels and would really like to make use of them. I have a few theories about some of the strangeness of these panels. Unfortunately, I don't have all the knowledge require to test/solve these problems. Hopefully, one of the friendly folks on here can lend a hand.

So, these are 64x64 Unilumin panels. Unilumin is pretty... cagey? about what information they share and they have a fairly unusual hookup system.

On commercial RGB matrix setups that I have worked on in the past, you typically daisy chain ALL or Portions of the entire panel. For Example: [>][>][>][>][>][>] [<][<][<][<][<][<] [>][>][>][>][>][>] Over-simplified, this panel would be a single chain of 18 snaked panels or 3x 6 panel arrays.

Unilumin purposely only puts 1 connector on their panels, you cannot chain them without the Hub/Spine controller that comes with these modules. It would appear that this spine takes an input and chops up a separate signal for each 64x64 panel separately. A setup would look something like this: [>]|[<] [>]|[<] [>]|[<] [>]|[<] [>]|[<] [>]|[<] [>]|[<] [>]|[<] [>]|[<] 3 clusters of 6 independent panels with 6 independent signals.

Theory 1: The SC pin may be a reference signal sync pin. Since, Unilumin doesn't seem to use a traditional control method and seems to be producing independent instructions for each panel in a cluster, I wouldn't be surprised if, much like traditional studio video equipment, the panels need a reference to keep all the panels in sync. Hypothesis A: Don't need to use that pin unless I'm attempting to sync more than one panel. Hypothesis B: I'm completely wrong and its something else entirely. Test 1: Disconnected SR pin. No observable difference in any demos or multiplexing tests.

Theory 2: Based on how many of the multiplexing/demo tests look and based on a quick look at the circuitry on the back, I would guess that the panel is electrically broken up in one of the following ways: 16 - R8xC32 Sub units 32 - R8xC16 Sub units 64 - R8xC8 Sub units

Testing: I have tried nearly every combination of R8-64, C16-64 (wont let me go as low as 8), Multiplexing0-9, and row address type0-2. Results: anything other than row address type 0 produces unbroken horizontal lines of solid color on 25-50% of the matrix, vertically spread evenly. Multiplex 7 seems to be the only one that correctly “renders” colors as expected. The most common result is an entire image broken up into as many as 64-8x8 chunks, hence my theory that it may be broken up electrically that way?

I’ve included a few images along with the settings I used to produce the result. I used the following in attempts to render this image. I had hoped to match the colored/numbered sections to what was produced on the screen -D1 -m 0 demomap.ppm

Rows=64 Cols=32 Chain=2 Multiplex=7 This seems to have rendered everything but broke it down into 2x2 pieces and stitched it back together as 8x8 chunks. All colors are correctly displayed though and all pieces SEEM to be present, just in the wrong order.

[SexualMoose]

I appreciate any help anyone can provide. Please let me know if any other images/information is needed.

[SexualMoose]

Just a little extra information, I disassembled one of the panels to get a look at the back. The main circuitry seems to be organized in a way that implies there are 8 rows and 4 columns. This would also imply 8x16 pixel sub panels.

[SexualMoose]

Is this project/thread dead? I really could use some help with this and I'm kind of running up against a brick wall here.

[fragmation]

the sr pin is E :D I have the same panel working with esp32 with this library : ESP32-HUB75-MatrixPanel-DMA-master