Support for MBI6024 LED driver chip (S-PWM)

[diplfranzhoepfinger]

Hi,

i bought this Panel:

typical RGB panel available for purchase

here is my Test Project:
https://github.com/diplfranzhoepfinger/ESP32-HUB75-MatrixPanel-DMA-examples-esp-idf-without-gfx

I am using a ESP32-S3-DevKitC-1-N32R8V

with a Logic Analyzer i see the Address Lines Togging (A,B,C,D)
but the R-G-B Lines all 0.

i modified the Code like this:
https://github.com/diplfranzhoepfinger/ESP32-HUB75-MatrixPanel-DMA-examples-esp-idf-without-gfx/blob/some_tests/without-gfx/main/main.cpp

and i see some toggling on Channge 12, which is R2 Line.

Some Photos of the Modules:

The Chips on the Boards read RUL6024, and there are many of them.

[board707]

The Chips on the Boards read RUL6024

Hi
Thanks for clear photos of panel.
The chips seems to be analog of MBI6024, which is a S-PWM type driver and not supported by the library.

[ergindemir]

https://www.aliexpress.us/item/3256803072136320.html
My latest module order was this one, it works pretty well.
Make sure to verify the chip before placing the order.

[diplfranzhoepfinger]

Sorry, the page you requested can not be found:(

[ergindemir]

https://www.aliexpress.com/item/1005003258451072.html
You can try this one, if not the item is not shipped to your country.

[mrcodetastic]

Sorry, the page you requested can not be found:(

@diplfranzhoepfinger - Did you buy a P4 64x32 panel? Are you in Europe?

I have a standard P4 panel that I have used for donkeys years to build this library. Perhaps we can swap?

[diplfranzhoepfinger]

Germany !

[board707]

to figure out what physical PIN of the HUB75 connector, connects to the 'first' RUL6024's 'CKI' and 'SDI' pin

Do you think these might be other pins, not standard CLK and R G B ? Why ?
The driver seems not to use a Latch pin, but beside this, its general operation principles are similar to other drivers.

I am not sure if two rows (two chains of RUL6024s) are addressed in parallel with these panels.

I am interested too, but... I see no reason to think that the selection of rows on the panel is arranged in any special way. The panel has a standard multiplexor chip SM5166 (138 type), therefore a row selection should be controlled as usual by A B C D E pins.
Although this is not visible in the photo, for reasons of compatibility with the HUB75 interface, I think that the connectors contain a standard set of color pins R G B R1 G1 B1, So the panel consists of two matrices operating in parallel, like any similar panels.
The label also speaks in favor of this - 64x32 scan 16, so the scan as a half of height.

[board707]

It's nice they kept the address lines consistent but the colour lines and everything else is totally irrelevant. Perhaps clock pin is the same... But one or two pins (if two scan) must be serial data input.

I think not a two pins, but six - R0 G0 B0 R1 G1 B1, as any other HUB75 panel. The matrix has a six parallel chains of RUL6024 drivers - three colors for top half of panel and a three for bottom. And common CLK line for all chains. However, I don’t insist...

Since the datasheet looks quite detailed, we could try to order the panel from the OP link and figure out how it works in real life :)

[daveythacher]

The interface is different, so it would never be HUB75. Overall the drivers are interesting from a PCB point of view. They use a packet notion because of this which has at most 20 percent overhead. This is different from current panels.

I did not look over it completely. However I did not see much covering multiplexing. It looks like they are counting on 16 bit PWM which could only be available in low multiplex applications. (This may flicker in some applications.) I doubt a LED Matrix will be able to handle all of that in some applications.

[board707]

I doubt a LED Matrix will be able to handle all of that in some applications.

It could be easily tested, the panel is available for $14 only

[diplfranzhoepfinger]

True. Also I could send you mine.

[mrcodetastic]

True. Also I could send you mine.

What type of panel did you buy 64x32 P4?

I might have an idea that works for both of us.

[mrcodetastic]

Since the datasheet looks quite detailed, we could try to order the panel from the OP link and figure out how it works in real life :)

I emailed the seller. But I think they'll just post whatever they have laying around in the warehouse... so they'll probably end us sending us wrong panel type for us, but the right panel type for the OP.

[DynaRobin]

Hi,

I came across this thread as I bought a big batch of these P4 LED Modules for a job (I make LED screens for theatres and operas for a living) and I had trouble getting them to work (first time ever in around 10 years I've had a HUB75 module that just showed blank with default settings).

I was pretty sure that the modules were basically working but the data from the shift registers (RUL6024) wasn't being latched across to the outputs - I knew this because I could connect a RUL6024 module first and daisy chain it to another similar module with a different chipset and the generic chipset module displayed perfectly whilst the RUL6024 module remained blank. I also know that the line drivers (32 rows A B C D E etc) were being driven correctly as if I unsoldered some of the RUL6024 and replaced them with a common shift register - ICN2028 (edit: note thats 2028 and not 2038, I'd be interested to try with a 2038 but I don't have one) - those sections of the module displayed perfectly.

I use the modules with Novastar receiving cards (the industry standard commercial driver boards). To get them working I had to change the chipset in the configuration to ICN2038.

The pinout and functionality of RUL6024 is similar to dozens of other LED drivers, obviously there's something different in the timing requirement, probably the latch signal. When I get back to my workshop I intend to put a scope on it and work out what the difference is.

I managed to get the elusive datasheet for RUL6024 from the manufacturer, it should be attached here and hopefully it will be of help to somebody.

RUL6024V6-EN-V1.0 Specification.pdf

PS I initially worried that RUL6024 was an equivalent to MBI6024 as somebody mentioned above, but it's not the case.

[DynaRobin]

Hi, I did get them working but with Novastar MRV412 receiving cards - these are what I and most of the LED display industry use to make them work as video displays - the cards are cheap (15USD ish) but you need a more expensive (200USD ish) 'sending box' to get them to work.

The problem seemed to be that the serial data was not getting latched across to the outputs, I never did find the time to analyse why but more than likely the duration of the latch signal isn't long enough. If you can apply 5v briefly (just dab a flying wire to the pin) to pin 4 of one of the RUL6024 then you'll probably see some of the data appear on at least half of the module (because it's multiplexed you won't see the proper image, it'll probably be one row of LEDs worth of data spread across multiple rows of LEDs).

[sigmafx]

I'm driving the display with my own controller and software - I'll try extending the latch signal. Certainly, if I attach another display to the output data connector I can see this is displayed correctly which seems to indicate the data is passing through the shift register correctly. But as you say, seems that the data isn't getting passed from the shift register and into the output register - this occurs via LE and OE.

[sigmafx]

I found a slightly different document on the Ruichips site: http://www.ruichips.com/npublic/opdfjs/web/viewer.html?u=1734145300469006336&fileName=RUL6024V6
Section of text on page 11 is as follows:
Inside the RUL6024 is a 16-bit shift register. Multiple RUL6024 serial data shifts. Each clock cycle CLK transfers 1 bit of data.
SDI, serial data input driver on/off control. Schmidt buffered input. When data "1" is written to SDI the switch controls the shift
Register / on the rising edge of CLK.
CLK serial data shift clock. Schmidt buffered input. All data/off control transitions are synchronized by the MSB of 1
On the rising edge of CLK, single-channel data is shifted to SD at the same time. After the rising edge input of CLK is approved, the rising edge lasts for 100ns.
The number of CLK rising edges contained in the LE high level triggers different instructions. When the LE high level contains 3 CLKs, the data in the shift register
It is latched into the latch and moved into the display register when waiting for the next display. Similarly, when LE contains 11 CLKs, the shift register
The data is written into the status register 1. When the LED contains 12 CLKs, the shift register data is moved into the status register 2. By rewriting the status
The value of the register can configure some parameters of display and blanking.
The rising edge of OE moves the value in the latch into the display register, and OE serves as a display enable. When OE is low, the display is turned on, and the data
Ports with a register of 1 will be enabled.
SDO is the output of the shift register. When the shift data exceeds 16, the first data moved in by SDI will be shifted out as the next
Chip input.

[sigmafx]

Looks like the number of clock cycles where LT is high affects the operation of the IC - possibly LT for 3 clock cycles will latch the data.

[sigmafx]

For information, I have these panels working now. The key is to have Latch high for the last 3 rising clock edges - this will latch the data in the shift register to the output registers. OE can be used as normal to set overall brightness etc.

This is referred to as a command in the documentation...
The command parser is a counter of LE length: A different length of LE indicates a different command.

Having the Latch high for different counts of clock have different effects, but I have only found documentation that refers to this for ICN2038S which seems to be an identical driver:

Command Name Number of DCLK Rising Edge when LE is High Description
-- 1&2 Reserved
DATA_LATCH 3 Transfer Serial data to buffers
-- 4~10 Reserved
WR_REG1 11 Write Configuration Register 1
WR_REG2 12 Write Configuration Register 2

There's no information on what the registers are for, although registers W_REG1 and W_REG2 can be found in other LED driver docs.

[board707]

According to included specification, it is an ordinary dual-latch driver and not a S-PWM one. This is also confirmed by the fact that the panels worked with ICN2038 configuration (the ICN2038 is standard driver, supported by the library)