DP3264S 32x32 1/8 panel works, but same chip 64x64 1/16 doesn't

[FabioRoss]

Hi! Sorry for opening a new issue, i would need help to understand how to make this panel work

I recently bought a 1/8 scan 32x32 outdoor panel with chip (DP)3264S and a 1/16 scan 64x64 with the same chip.

I can't wrap my head around on why the 32x32 works perfectly while the 64x64 doesn't show any signs of life, i can drive the 32x32 with no problems but i can't get to light up even a single pixel on the 64x64. could it be wrong wiring labelling?

panel wiring (it is written like this, with B1 shown twice):

HUB75 R1 | B1 B1 | GND R2 | G2 B2 | GND A | B C | D CLK | LAT OE | GND

there is written also R3 | G3 B3 | GND underneath, but the hub75 is not connected to those.

Observations: On the 32x32 panel with same chip and from the same manufacturer the G1 and B1 pins and G2 and B2 are swapped

I designed and printed a PCB that works perfectly with 64x64 FM6124 1/32 indoor panel and the 32x32 DP3264S 1/8 outdoor panel. When used on the 64x64 DP3264S 1/16 it makes the chip do two things which stalls it if not taken care of

the pin mapping is the following

#define R1_PIN  32
#define G1_PIN  33
#define B1_PIN  25
#define R2_PIN  26
#define G2_PIN  27
#define B2_PIN  14
#define A_PIN   16
#define B_PIN    4
#define C_PIN    0
#define D_PIN   17 // normally 2
#define E_PIN   -1 // normally 17
#define LAT_PIN 12
#define OE_PIN  13
#define CLK_PIN 15

Using an esp32 wroom 32

1) D row addressing is connected to GPIO2, on the first two panels this doesn't affect it as when powered D sits high or floating. With the new panel it sits low, making the esp enter flash mode. Solved by routing D to GPIO17 and connecting 3v3 to GPIO2, but since it wouldn't be an issue with the other two panels i think there may be something wrong with the wiring of the panel's hub75

2) LAT pin is connected to GPIO12. Again while not ideal, on the first two panels this doesn't affect the esp on startup. On the new panel it makes it prompt the following error

rst:0x10 (RTCWDT_RTC_RESET),boot:0x3b (SPI_FAST_FLASH_BOOT)
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff

solved by unplugging the panel on startup and plugging back once chip is running. The chip works after that, since it prints to serial everything correctly, but the panel is not showing anything. I may be wrong, but this makes me think that the underlying issue is that the panel pins are not doing what the labels show

Troubleshooting executed with no results:

1) Run the sketch that was working with the 64x64 indoor panel 2) Run the sketch that was working with the 32x32 outdoor same chip 3) Run PIO Test Patterns sketch 4) Reversed the cable connections (thought maybe they could have placed the hub75 socket in the wrong direction) 5) Used a different PCB, same circuit and wiring LAT to GPIO17 instead of 12

I doubt that power could be the issue as i'm using a 12V 9amp lead acid battery with a buck converter to output 5V. It has been tested with the other panels and it can power both the other panels at the same time with no issues. The panel consumption written in the data was <=20W.

it is super weird because the 32x32 panel would work when using fillScreen(), while the 64x64 seems to have no life at all...

any ideas on what i could try further? thank you to anyone who will help!

[board707]

Are you sure, that 32x32 and 64x64 panels has the same driver? Don't trust the seller's descriptions, take a magnifying glass and read the inscription on the chip.

This driver (DP3264) noted in my table as a new S-PWM type, so it's not surprising that it doesn't work. More surprisingly, the 32x32 panel worked

[FabioRoss]

turns out you were spot on, i can't see the ones in the 64x64 since it's a close shell, but the 32x32 appears to have a MP5020GP

are there any libraries that could drive a S-PWM type chip? otherwise i'll just send it back to the seller

[board707]

the 32x32 appears to have a MP5020GP

This explains it all - MP5020GP is a standard driver supported by the library, and 3264 is a new type for which no code has been written yet.

are there any libraries that could drive a S-PWM type chip?

Each S-PWM driver is special, some of them already have libraries, but I haven't seen any for 3264.

[FabioRoss]

This explains it all - MP5020GP is a standard driver supported by the library

I see...i'll have to send it back then, thank you for the answers and the help! By any chance do you have the link to an outdoor 64x64 panel whose chip is supported by the library or can you recommend me a seller that has some knowledge about this library? I don't expect you to, but i thought it was worth a shot

thanks again

[board707]

Sorry, I don't have such info

[FabioRoss]

thank you anyways, you guys are great

[FabioRoss]

@board707 is ICN2037 supported? I saw 2038S is but for what i found online they both are PWM, which leaves me confused...can you point me to a website or resource where i can check the specs of the chips without bothering you every time?

[board707]

Hi I have a small summary table of LED panel chips on my GitHub- maybe you will find it useful. Keep in mind that the data in the table is unofficial and may contain inaccuracies https://github.com/board707/DMD_STM32/wiki/Led_drivers

It is interesting that literally yesterday I received a pack of panels from the sponsor for testing. Among others, there is a panel with a DP3264 driver on the list. It doesn't mean, however, that I can be able to write a code for it :)

[vasi26ro]

I have bought some led panels for a project and all of them are with DP3264S and SM5166PF. Of course, I was 100% sure that there will be no problem :|

I am thinking of buying a LED controller or receiver board or how is called to drive these panels. It would be helpful if I get some samples from the HUB75 communication with the logic analyzer in order to understand how the PWM led drivers work?

Thank you @board707 for the list

[board707]

It would be helpful if I get some samples from the HUB75 communication with the logic analyzer in order to understand how the PWM led drivers work?

In the discussion at the link you can find several examples of reverse engineering of the protocol for S-PWM driver panels. Also you will find the code for some SPWM drivers (ICDN2053/FM6363) in my DMD_STM32 library.