Strange image on one of four panels (MBI5124 driver chip)

[DerMaulwurf]

I have four boards whith different combination of chipsets. Three of them run fine on the dev-library (thanks for the excelent work). Sadly, one panel does not work. After rebooting the ESP32 the panel ist completely white in most cases. Sometimes it does display some picture with strange horizontal echoes (32 bit long). The panel is working with another library I tried, so it's not defective. It is populated with MBI5124 drivers. Has anybody come across an effect like this? Any advice is welcome.

[mrcodetastic]

Like the sun rises each day, a new chip from China is born.

The blurring looks to be an issue with the OE toggling of that chip. Perhaps play with this new function @vortigont implemented:

https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/issues/64#issuecomment-768095551

[mrcodetastic]

Looks like this chip / panel has configuration registers as well - so not a straight-forward dumb shift register only panel.

Try and apply the FM6126A sketch example logic as part of the startup sequence. Perhaps it may work for this panel. Otherwise you may need to swap this panel out.

What's the other library that works. PxMatrix?

[mrcodetastic]

5a542453754da.pdf

DataSheet.

[DerMaulwurf]

The library is github.com/VGottselig/ESP32-RGB-Matrix-Display. It seems that project is no longer maintained. The framerate is slow, and the code has some issues, but it's quite simple and it runs all the different panels I got.

I'll try the OE and FM6126A tips and give feedback.

BTW be carefull with static charge. While fiddeling around with the cables I must have zapped a chip of the working panels. Now half a column of LEDs go red instead of green. Maybe I need to swap two boards now...

[DerMaulwurf]

I tried both recommendations, but they had no effect. I thought, I'll try to figure out, why the 3 years old library ESP32-RGB-Matrix-Display works with these new chips (apart from the flickering). It can't know about any new (magic) initialization procedures. I hooked up the scope and took some measurements. Turns out, it's not that obvious (at least to me). Why are there so many LAT and OE cycles per every pixel row address?

In case you are interested, I'll attach some screen copies as PDF below. Please excuse the noisy signal traces in the pictures. The whole thing is plugged together on a breadboard and the cables are long and tangled.

timings.pdf

[vortigont]

@DerMaulwurf

Why are there so many LAT and OE cycles per every pixel row address?

this is expected, this lib uses time division to render higher color depth, so it could "draw" a single row several times depending on color bit weight Could you try and zoom-in timings for CLK/LAT signals? I've checked datasheet for that chip and I suspect that there is some issue with timing LAT/OE/CLK signals. Seems that either LAT or OE must be properly timed relative to CLK rise/fall signal. It's just my idea...

[mrcodetastic]

The three year old library switches at a super slow speed hence why it probably works with these chips.

Some of these old chips just can't handle the frequency the ESP32 pumps out with DMA. MBI5124 looks to be a 2014 chip.

[DerMaulwurf]

I'm happy to measure the timings, but to get any precision I need to clean up the sloppy cabeling beforehand. The signal edges look like molehills, not like rectangles.

[DerMaulwurf]

I had less time this weekend than I had hoped. The more accurate measurement had to wait, unfortunately. But I was able to make a recording with a logic analyser. There are a few limitations with this:

• The logic analyzer actually only has a bandwidth of 24MHz. Mine even manages 48MHz, but even that is too little to sample the 10 MHz CLK signal accurately. But it is good enough for an overview.
• What you see is not the real signal (the molehills) but an artistic processing. It is what the logic analyzer understood (an idealized representation).

panel.zip

You can open the file with the open source program PulseView. If you don't have it yet: I can only recommend the combination of PulseView and a cheap 7$ USB logic analyzer. Video tip for this (long but good): https://youtu.be/dobU-b0_L1I

Many greetings, Markus

[mrcodetastic]

Edit: This actually works.

@DerMaulwurf, I would suggest reducing the output frequency / transfer rate of the ESP32's GPIO DMA output, the library defaults to 10Mhz, but I got it down to 1.25mhz! You will have a very flickery panel, you can almost see every line being displayed one by one.

In esp32_parellel_dma.c line 204 change to:

    dev->clkm_conf.clkm_div_num=128; //80000000L/(cfg->clkspeed_hz + 1);

If this problem panel starts working however, this might be the explaination... The DMA output transfer bitrate needs to be reduced more.

Thanks for the tip. I might buy one of these cheap signal analysers.

[vortigont]

@DerMaulwurf as I see in your file those pulses were obtained using this lib, not the old one (working), right? Actually logical analyzer is not much of a help here, I'm more interested in timings than in logical state of the outputs. My idea is that an old lib due to significant delays between setting/reseting pins could set proper signal sequence for the matrix on the contrast to DMA lib that sets all signals almost synchronously.

[DerMaulwurf]

@mrfaptastic: You can't watch that effect for long, it's really bad for the brain. Unfortunately it didn't help for the sick panel. It has the same fault, just with flicker on top. @vortigont: I'll do some propper measurements on the old lib.

[mrcodetastic]

@mrfaptastic: You can't watch that effect for long, it's really bad for the brain. Unfortunately it didn't help for the sick panel. It has the same fault, just with flicker on top.

Well, that's bad news for that panel as clearly that chipset cannot handle the parallel nature of this library, which can't be changed. You're going to have to replace this panel.

Looking at the 'old library it's pretty simple and changes stuff in series. Totally different way of operation to this library.

void IRAM_ATTR ESP32RGBmatrixPanel::drawRow()
{
    gpio = GPIO.out;
    SetPinFast(OE, HIGH);
    GPIO.out = gpio;
    SetPinFast(CH_A, row & 1 << 0);
    SetPinFast(CH_B, row & 1 << 1);
    SetPinFast(CH_C, row & 1 << 2);
    SetPinFast(CH_D, row & 1 << 3);
    GPIO.out = gpio;

    for (column = 0; column < COLUMNS; column++)
    {
        SetColorPin(R1, pixels[row][column].r);
        SetColorPin(G1, pixels[row][column].g);
        SetColorPin(BL1, pixels[row][column].b);
        SetColorPin(R2, pixels[row + 16][column].r);
        SetColorPin(G2, pixels[row + 16][column].g);
        SetColorPin(BL2, pixels[row + 16][column].b);

        //SetPinFast(CLK, 1);
        GPIO.out = gpio;
        //SetPinFast(CLK, 0);
        //GPIO.out = gpio;
        GPIO.out_w1ts = ((uint32_t)1 << CLK);//SetPinFast is to fast!? wtf!?
        GPIO.out_w1tc = ((uint32_t)1 << CLK);
    }
    SetPinFast(LAT, HIGH);
    GPIO.out = gpio;
    SetPinFast(LAT, LOW);
    GPIO.out = gpio;
    row++;
    if (row >= 16)
    {
        row = 0;
        layer += layerStep;
    }
    if (layer + 1 >= layers) layer = layerStep - 1;

}

[tsctrl]

hi,

is there any benefit reducing the dma speed for the new chip? such as possible more stable refresh rates or chance to lower flickers. other then changing the freq it in the lib. do i have to change dma config the esp config files if there is? just to try. i would say lower speed library like rgb matrix panel by adafruit are quite stable too..

sometime, i would prefer lower speed that i could use with reason to be safe. lower rams allocation to save resources etc.

[mrcodetastic]

No there is no benefit. DMA speed has no impact on resource usage.

What commercial product are you trying to build with this library?

[tsctrl]

hi @mrfaptastic, thank you.

small notification boards projects for my free time.

thank you

[DerMaulwurf]

Hi @vortigont, some time ago, you had asked for some zoomed in pictures of CLK, LAT and OE of the old library. Sorry, it took me a while to get this done. The signals aren't very clean, as the circuit is sitting on a breadboard. I hope you find this usefull. CLK-OE-LAT.pdf

[vortigont]

@DerMaulwurf yeah, this looks interesting. According to datasheet those ships should be fast enough to be clocked at 10MHz at least. Seems that LAT in that chip doesn't like CLK toggling. Not sure if any change or only rising/falling edge. So you say that panel stays always blank while and shines at full power, right? If you want to experiment you can try to patch esp32_i2s_parallel.c a little bit. Find those lines

    //ToDo: Clk/WS may need inversion?
    gpio_setup_out(cfg->gpio_clk, sig_clk);

and add the following code on the next line GPIO.func_out_sel_cfg[cfg->gpio_clk].inv_sel = 1;

Pls, test using that single panel only attached to ESP32, not sure how panel chaining could influence to SDO/CLK signaling.

[mrcodetastic]

@vortigont - Nice work.

@DerMaulwurf out of pure boredom I have created a sketch to be able to set the start and ends of the Latch and two OE's.

By default the library does a latch at the last pixel (if 64 pixels wide panel, that's '63') and a OE either side at pos 62 and 0.

Play around with this. Perhaps setting OE (as in output off) to 58-63, 0-10 and a LATCH on 60-63 or something. Who knows.

Also as @vortigont, drive this problem panel directly from your ESP as the first and only device as well.

https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanelTest

[vortigont]

Looks like a nice trail-light effects to me :) :+1:

[DerMaulwurf]

@vortigont Bullseye! The sick puppy is working great and the other panels look OK too. There is a faint green line on row 31 or 32 but it is less visible for the naked eye than it appears in the picture.

Next I'll try the sugestions from @mrfaptastic. I'll give feedback on that too. And I need to rearrange the panels...

Thank you both very much for your great help!

[mrcodetastic]

Looks like a nice trail-light effects to me :) 👍

Hahahah! Funnily enough if you play about with the LAT timings you get some cool effects. No need for a graphic library either Ha!

@vortigont Bullseye! The sick puppy is working great and the other panels look OK too.

Great work @vortigont. Always pays to have a Russian in the team ha!

[vortigont]

Bullseye! The sick puppy is working great and the other panels look OK too

Awesome! So my guess was true - while LAT is high rising edge clock resets the register. Yeah... Chinese IC designers are full of surprises - none of chips are like the others :) OK, I think I will implement clock phase setup into config struct the same way as it works for FM6126 chips, pretty easy and costs nothing with current design. :)

Great work @vortigont. Always pays to have a Russian in the team ha!

Thanks, man! :) yeah, sometimes it worth one's while (if we are not too busy chasing bears, ha-ha :)