sm16208s+sm5166 panel, ICN2037BP+RUC7258D panel

[j-g00da]

I need to buy an outdoor panel and want it to work with the library.
I asked sellers and sent them list of supported ICs asking for panels that use the same ones or similar and got recommended this panel, seller says it uses sm16208s and sm5166. They also say that "Equivalent to 138 lines decoding It is the most commonly used line decoding".

Will it work? If not, can I get a recommendation on some 160mm high outdoor screen that is tested and will work?

I also can report on some other panels I already tested:
This 80x40 flex screen does work well (I have a chain of two) with mxconfig.driver = HUB75_I2S_CFG::DP3246_SM5368; setting. I would use it but I need outdoor version...
This 80x40 outdoor screen doesn't work at all, it's all black no matter what settings I use. Can't tell what ICs it uses as the board is waterproofed.

Edit:
Chips on the working (flex, indoor 80x40) panel:
DP245D
DP5125D
3018SDP
It works with DP3246_SM5368 driver config.
You can safely add these to the supported ICs section.

[board707]

sm5166. They also say that "Equivalent to 138 lines decoding It is the most commonly used line decoding".

true, sm5166 chip is a "type138" line decoder

Will it work?

It's impossible to say for sure.
Any of outdoor panels, even with supported chips - need to configure the order of the pixel output, which is not so easy to do in this library. I configured such panels for several people and described the scheme of the geometric function in the discussion #622.
Most panels are quite easy to configure, but sometimes there are very complex cases; it is impossible to predict the result without testing on hardware.

[j-g00da]

I can manage fixing the order of pixels - if that's the only problem. The main thing I'm afraid of is if I can display anything at all, I don't want to end up with the same problem as with this panel, where absolutely nothing is displayed (maybe chips there can't process 3.3V signal? Idk).

[board707]

I don't want to end up with the same problem as with panel, where absolutely nothing is displayed

This Aliexpress link does not indicate which drivers are used on the panel, so I can't say what is the reason why the panel did not work. Unfortunately, matrices with unsupported drivers are increasingly common on the market and the probability of getting such a panel is quite high.
In the case of your new panel, the chips (sm16208 and sm5166) allow us to hope that the panel will work, although it is impossible to give a full guarantee.

[j-g00da]

I will probably buy few different models and test which one works best.
I also got response from another seller, they have solutions with ICN2037BP+RUC7258D and LS9930CS+RUC7258D. Are these combinations worth checking?

[board707]

they have solutions with ICN2037BP+RUC7258D and LS9930CS+RUC7258D. Are these combinations worth checking?

The first option should work, the second definitely won't, LS9930CS - unsupported driver

[j-g00da]

Ok so seller informed me that they have two versions of the 80x40 outdoor module I talked about in the first comment. One is ICN2037BP+RUC7258D and the second one is LS9930CS+RUC7258D, and you get a random one... They sent me pictures of ICN2037BP module and it has slightly different pcb layout so it makes sense that mine must be LS9930CS, and that's why it doesn't display anything...

[j-g00da]

Got the ICN2037BP+RUC7258D panel - it works but as expected, the order of pixels is messed up. Was such order observed before (might save me some time)? I will try to configure it.

The module is 80x40, it goes by 16-wide lines, two at the time, renders half of the screen, then stops (probably renders off-screen), then proceeds to re-render the top side (Idk if you can see it on video, but pixels get a bit brighter), then it proceeds to do the same to lower half.

IMG_2787_480p-2.mp4

[board707]

please show the code that produced this video

[j-g00da]

I drew it with such function:

void testPixels() {
  virtualDisp->clearScreen();
  int h = virtualDisp->height();
  int w = virtualDisp->width();
  for (int i = 0; i < h; i++) {
    for (int j = 0; j < w; j++) {
      virtualDisp->drawPixel(j, i, RED);
      delay(100);
    }
  }
}

Screen init part:

HUB75_I2S_CFG mxconfig(
  panel_x,
  panel_y,
  rows * cols);
dmaDisplay = new MatrixPanel_I2S_DMA(mxconfig);
dmaDisplay->setLatBlanking(4);
dmaDisplay->begin();
dmaDisplay->setBrightness8(200);  // 0-255, values higher than 200 may introduce ghosting
virtualDisp = new VirtualMatrixPanel((*dmaDisplay), rows, cols, panel_x, panel_y, chain_type);
virtualDisp->clearScreen();
virtualDisp->setCursor(0, 0);

panel_x = 80
panel_y = 40
These don't matter, I use VirtualMatrixPanel only because I used a chain before testing the new screen:
num_rows = 1
num_cols = 1
chain_type = CHAIN_BOTTOM_RIGHT_UP

[board707]

Please show a full code

[board707]

I use VirtualMatrixPanel only because I used a chain

No, it is not correct. You must use a VirtualMatrixPanel even for a single panel if you have a i.e. QuarterScanPanel type. What is the scan factor of your 80x40 matrix?

[j-g00da]

I use VirtualMatrixPanel only because I used a chain

No, it is not correct. You must use a VirtualMatrixPanel even for a single panel if you have a i.e. QuarterScanPanel type. What is the scan factor of your 80x40 matrix?

I know, what I meant is for now it doesn't do anything, doesn't change what is rendered.

Panel is 1/10 scan, so a "quarter-scan". It's part of larger code so I think I will make a minimal example instead of sharing that, tested and produces the same output:

#include <ESP32-HUB75-MatrixPanel-I2S-DMA.h>
#include <ESP32-VirtualMatrixPanel-I2S-DMA.h>

// Display settings
#define PANEL_RES_X 80
#define PANEL_RES_Y 40
#define NUM_COLS 1
#define NUM_ROWS 1
#define PANEL_CHAIN NUM_COLS * NUM_ROWS
#define VIRTUAL_MATRIX_CHAIN_TYPE CHAIN_BOTTOM_RIGHT_UP

// Colors
#define WHITE virtualDisp->color565(255, 255, 255)
#define BLACK virtualDisp->color565(0, 0, 0)
#define RED virtualDisp->color565(255, 0, 0)
#define GREEN virtualDisp->color565(0, 255, 0)
#define BLUE virtualDisp->color565(0, 0, 255)

MatrixPanel_I2S_DMA *dmaDisplay = nullptr;
VirtualMatrixPanel *virtualDisp = nullptr;

void testPixels() {
  virtualDisp->clearScreen();
  int h = virtualDisp->height();
  int w = virtualDisp->width();
  for (int i = 0; i < h; i++) {
    for (int j = 0; j < w; j++) {
      virtualDisp->drawPixel(j, i, RED);
      delay(100);
    }
  }
}

void setupScreen(int panel_x, int panel_y, int rows, int cols, PANEL_CHAIN_TYPE chain_type) {
  HUB75_I2S_CFG mxconfig(
    panel_x,
    panel_y,
    rows * cols);

  dmaDisplay = new MatrixPanel_I2S_DMA(mxconfig);
  dmaDisplay->setLatBlanking(4);
  dmaDisplay->begin();
  dmaDisplay->setBrightness8(200);  // 0-255, values higher than 200 may introduce ghosting
  virtualDisp = new VirtualMatrixPanel((*dmaDisplay), rows, cols, panel_x, panel_y, chain_type);
  virtualDisp->clearScreen();
  virtualDisp->setCursor(0, 0);
}

void setup() {
  setupScreen(PANEL_RES_X, PANEL_RES_Y, NUM_ROWS, NUM_COLS, VIRTUAL_MATRIX_CHAIN_TYPE);
}

void loop() {
  testPixels();
  delay(2000);
}

[j-g00da]

In mxconfig I changed panel_y to panel_y/2 - now it render continously, doesn't go "off-screen" half way through as before. Still renders in two places at the same time.

[board707]

now it render continously,

Could you show the video after the change?

[j-g00da]

Here: mxconfig set to panel_x, panel_y/2. Only other change is delay 100->10.

IMG_2816_480p.mov

I also tried to set set mxconfig to panel_x*2, panel_y/2, now it renders only one pixel at a time as it should, but only left side (with masonry shape in the middle) was rendered.
Then I tried following #622 - set mxconfig to panel_x*2, panel_y/2 and used setPhysicalPanelScanRate to use my own code:

        if ((coords.y & 10) == 0)
        {
            coords.x += ((coords.x / panelResX) + 1) * panelResX;
        }
        else
        {
            coords.x += (coords.x / panelResX) * panelResX;
        }
        coords.y = (virt_y / 20) * 10 + (virt_y & 9);

It left unrendered horizontal strips.

[j-g00da]

Here is the change I mentioned above:

void setupScreen(int panel_x, int panel_y, int rows, int cols, PANEL_CHAIN_TYPE chain_type) {
  HUB75_I2S_CFG mxconfig(
    panel_x*2,
    panel_y/2,
    rows * cols);

  dmaDisplay = new MatrixPanel_I2S_DMA(mxconfig);
  dmaDisplay->setLatBlanking(4);
  dmaDisplay->begin();
  dmaDisplay->setBrightness8(200);  // 0-255, values higher than 200 may introduce ghosting
  virtualDisp = new VirtualMatrixPanel((*dmaDisplay), rows, cols, panel_x, panel_y, chain_type);
  virtualDisp->setPhysicalPanelScanRate(FOUR_SCAN_40PX_HIGH);
  virtualDisp->clearScreen();
  virtualDisp->setCursor(0, 0);
}

Change in library code, after FOUR_SCAN_16PX_HIGH code:

    else if (panel_scan_rate == FOUR_SCAN_40PX_HIGH)
    {
        if ((coords.y & 10) == 0)
        {
            coords.x += ((coords.x / panelResX) + 1) * panelResX;
        }
        else
        {
            coords.x += (coords.x / panelResX) * panelResX;
        }
        coords.y = (virt_y / 20) * 10 + (virt_y & 9);
    }

Result:

img_2817_480p.mov

[j-g00da]

OK! I'm close now, had to change math a bit, since the resolution is not in powers of 2.

    else if (panel_scan_rate == FOUR_SCAN_40PX_HIGH)
    {
        if ((coords.y / 10) % 2 == 0)
        {
            coords.x += ((coords.x / panelResX) + 1) * panelResX;
        }
        else
        {
            coords.x += (coords.x / panelResX) * panelResX;
        }
        coords.y = (coords.y / 20) * 10 + (coords.y % 10);
    }

IMG_2818_480p.mp4

[j-g00da]

I've set the pixel base to 16.

uint8_t pxbase = 16;
if ((coords.y / 10) % 2 == 0)
{
    coords.x += ((coords.x / pxbase) + 1) * pxbase;
}
else
{
    coords.x += (coords.x / pxbase) * pxbase;
}
coords.y = (coords.y / 20) * 10 + (coords.y % 10);

Almost there:

IMG_2819_480p.mov

[board707]

Amazing results :)
Just a little bit left to success.

[j-g00da]

Yeah, I fixed that and then tried to display some multicolor image and realised that the shift is different on different color channels, which is very weird.

[board707]

I fixed that

Could you explain how did you fixed it? Show the code?

[board707]

According to the video, it's seems that the data is lagging by one pixel, as if the first CLK edge or first data pulse was lost.
Probably it could be fixed by changing a data output parameters, say clkphase or tuning the line

dmaDisplay->setLatBlanking(4);

May be @mrcodetastic could help

[mrcodetastic]

clkphase setting?

[board707]

sorry, I don't know.
this is just a guess

[j-g00da]

I'll be working on it later today. Will give update on that. I'm using a custom board that has matched length for RGB lanes and works perfectly on other, indoor display.
My guesses are:

1. Power - I'm using 5V3A psu, on other board I observed some ghosting on parts of the screen, after hours of tinkering I decided to turn the voltage adjustment knob on the psu - it started working perfectly on about 6V. I tried doing the same on this board, some pixels aligned but other stayed shifted. Maybe I will try adding a capacitor?
2. Damage - I think it's rather unlikely but to mount the custom board (it plugs directly to hub75) I had to remove some of the black plastic on the back, maybe it damaged the panel's pcb?
3. Quirky panel, will try changing clkphase and if it doesn't work I will try to modify code to only shift red...

Edit:
As you can see on white text, only red channel is shifted.

[j-g00da]

Update on power - for some reason my PSU outputs 5.7V on lowest V adj. setting. Maybe this is too far from the 5V?

[mrcodetastic]

Do you have a 3.3->5v logic level shifter between the ESP32 and the panel? Sorry if this has been asked before.

[j-g00da]

No, I asked if it would have any benefit in #703

[board707]

In your case we need to test everything, so it could be worth to test a using of level shifter...

.... although I see a little chances that it will help, judging by the picture.

[j-g00da]

I'm almost certain it is the power, when I turn the voltage ajdustment potentiometer, the pixels shift, but I can't turn it lower than 5.7V. I will have a new power supply tomorrow.