Add a new panel ICN1065

[shadowpho]

Panel description

Dimensions (in pixels) : 172x86

Scan factor: 1/43

Chips on rear side: ICND1065L, MW245BC

Panel photos

Onedrive Link for Max Resolution

Specification Link

More Information

Purchase Link

I recently bought this panel not realizing it's a S-PWM panel. Should I return it or should I first try to port the code to ESP32 and try the 2153/FM6353 code? The internet led me to believe that 1065 is similar to 2153 which is compatible with FM6353.

I have a Huidu HD-WF2 (can't beat the $6) which has correct HUB75 header (works on non-pwm panels), is ESP32-S3.
I also have a pile of pico/pi/stm32 chip and boards that I can solder an adapter too, but it's probably best to stick to huidu.

I also have an oscilloscope/multimeter/logic analyzer and can probe things out if it's helpful.

Lastly, I have a MRV300-1 board, but I think it's not useful without sending card.

Seems 1065 came up a few times in the github issues but without any resolution, so not sure what's the latest on it.

[board707]

Hi @shadowpho
A very interesting panel, I have never come across matrices of this size.

Unfortunately, as I mentioned in my private message, I haven't worked with the 1065 driver yet and don't know of a library that works with these chips.
As for its compatibility with the ICN2153 or FM6353, I don't know anything about that either. Even if it were, my code for the FM6353 doesn't work on the ESP32 or HUIDU, and if you plan to use these boards, the best course of action would be to look for other panels.

[board707]

In addition...
If you have a Raspberry Pico RP2040 board, it would be interesting to try running the panel with my library, selecting the FM6353 driver settings.
Before running it, it's a good idea to find out the type of multiplexers on the matrix, which you didn't specify. The multiplexer chips are clearly visible in the photo, but I couldn't read their markings:

[shadowpho]

In addition... If you have a Raspberry Pico RP2040 board, it would be interesting to try running the panel with my library, selecting the FM6353 driver settings. Before running it, it's a good idea to find out the type of multiplexers on the matrix, which you didn't specify. The multiplexer chips are clearly visible in the photo, but I couldn't read their markings:

I do have a 2350 pico w, which I could probably adapt code to, the harder part is wiring. Maybe I’ll do a quick jlcpcb run (headers, voltage translator and connector).

Ah sorry about multiplexers. I didn’t realize there’s a third type of chips. They are DP32020A.

Btw does scan 1/43 make any sense?

[board707]

the harder part is wiring. Maybe I’ll do a quick jlcpcb run (headers, voltage translator and connector).

Your panel has a buffer chips (MW245BC) that works as voltage translators, so you don't need any others. The Pico board and HUB75 connector can be assembled without PCB. See my instruments :)

does scan 1/43 make any sense?

Why not? There's nothing surprising about scan 1/43. It's half the panel's height. However, the panel's size is unusual, and the fact that the matrix width (172) isn't a multiple of the driver's pin number (16) may pose configuration challenges.

[shadowpho]

the harder part is wiring. Maybe I’ll do a quick jlcpcb run (headers, voltage translator and connector).

Your panel has a buffer chips (MW245BC) that works as voltage translators, so you don't need any others. The Pico board and HUB75 connector can be assembled without PCB. See my instruments :)

> does scan 1/43 make any sense?

Why not? There's nothing surprising about scan 1/43. It's half the panel's height. However, the panel's size is unusual, and the fact that the matrix width (172) isn't a multiple of the driver's pin number (16) may pose configuration challenges.

Thank you! Good point on the mw245bc. It has vih of 3.3v so that’s marginal but most likely will work.

I’ll see if I have an rp2040 somewhere and solder a jig together. Is there a branch to take a look at? I can then use the same point numbers.

The fact that matrix with isn’t a multiple… should I cut down the pixels (160) or feed it more then exists and it just won’t display imaginary pixels (176)?

[board707]

Is there a branch to take a look at? I can then use the same point numbers.

I don't quite understand... if you mean a pin numbers, see any example of my library for rp2040 board

should I cut down the pixels (160) or feed it more then exists and it just won’t display imaginary pixels (176)?

Most likely the second... but it's hard to say in advance where these extra pixels will be located... usually somewhere in the middle of the matrix

[shadowpho]

Gotcha thank you! I got the SW installed and base program written. Now I am going to solder the wires and test it.

I found a RP2040 ProMicro which should work out of the box. Does this pinout make sense?

Panel labels:
(I am assuming R1,G1,B1 is actually R0,G0,B0 and R2,G2,B2 is R1,G2,B1)

UART (debugging) = 0,1
R0, G0, B0, R1, G1, B1 = 2,3,4,5,6,7 [Consecutive]
CLK, OE, SCLK = any pins, so 20,21,22 (this is for external PSRAM but it's either this or I2C pins)
A,B,C,D,E = 25,26,27,28,29 [Consecutive]

[board707]

Hi
Generally the pin numbers are OK. But make sure that this pins doesn't used by system ... for example for in-board PSRAM...

[shadowpho]

Hi Generally the pin numbers are OK. But make sure that this pins doesn't used by system ... for example for in-board PSRAM...

Sadly no cigar :(.

Can you please double check my code to make sure it's proper?

I tested with both DMD_RGB_FM6353 and DMD_RGB_DP3264. I also tested with both dmd.configure_multiplexer(DMD_MUX_TYPE_SHIFTREG); and the line commented out as well.

In all 4 tests the Panel + RP2040 draw 120 mA and whole screen is black.

I tested continuity on each pin (looks good) and probed it with oscilloscope. There's a bit of overshoot/undershoot and edges are very hard (can probably lower slew rate), but otherwise it's making bits (pretty fast too! 100ns on some pins).

#include "st_fonts/UkrRusArial14.h"
#pragma GCC diagnostic ignored "-Wnarrowing"
#pragma GCC diagnostic ignored "-Woverflow"
#include "gfx_fonts/GlametrixLight12pt7b.h"
#include "gfx_fonts/GlametrixBold12pt7b.h"
#pragma GCC diagnostic warning "-Wnarrowing"
#pragma GCC diagnostic warning "-Woverflow" 

#define DISPLAYS_ACROSS 1
#define DISPLAYS_DOWN 1

#define ENABLE_DUAL_BUFFER false

#define DMD_PIN_A 25
#define DMD_PIN_B 26
#define DMD_PIN_C 27
#define DMD_PIN_D 28
#define DMD_PIN_E 29

uint8_t mux_list[] = { DMD_PIN_A , DMD_PIN_B , DMD_PIN_C , DMD_PIN_D , DMD_PIN_E };

#define DMD_PIN_nOE 23
//LATCH
#define DMD_PIN_SCLK 21 

uint8_t custom_rgbpins[] = { 20, 4,5,6,7,8,9 }; // CLK, R0, G0, B0, R1, G1, B1

DMD_RGB_FM6353 <RGB128x64plainS32, COLOR_4BITS> dmd(mux_list, DMD_PIN_nOE, DMD_PIN_SCLK, custom_rgbpins, DISPLAYS_ACROSS, DISPLAYS_DOWN, ENABLE_DUAL_BUFFER);
DMD_Standard_Font UkrRusArial_F(UkrRusArial_14);
DMD_GFX_Font GlametrixL((uint8_t*)&GlametrixLight12pt7b, (uint8_t*)&GlametrixLight12pt8b_rus, 0x80, 13);

const char str[] = "Hello DMD_STM32!";
uint16_t bg = 0;                      // background - black
uint16_t fg = dmd.Color888(255, 0, 0); // foreground - red   

void setup() {
  Serial.begin(115200);
  dmd.init(); 
  dmd.setBrightness(10); 


  //dmd.configure_multiplexer(DMD_MUX_TYPE_SHIFTREG);

  dmd.selectFont(&GlametrixL);

  dmd.drawString(0, 0, str, strlen(str),fg);
}

void loop() {
  Serial.print("after sleep\n");
  dmd.clearScreen(true);
  dmd.drawString(0, 0, str, strlen(str),fg);
   dmd.swapBuffers(true);
 sleep_ms(100);

}

[board707]

Hi
The method dmd.swapBuffers(true); is mandatory to any output to the SPWM panels, so you have to add it at the end of setup() too. And I would to replace a sleep_ms(); to just a delay(). Despite of that the code looks correct as for me.

From what I've heard, the 1065 chip protocol is more similar to the ICN2055 than the ones you've tried.

[board707]

Additionally... just to be clear, couldn't the problem be with the pins you selected? Is there any possibility to run the example from the library with the pins that used there?

[shadowpho]

Test1: swapbuffer + delay instead of sleep: no luck
Test2: commented out SHIFTREG: no luck.
Test3: DMD_ICN2055 + SHIFTREG: I noticed current went up to 100mA!
Test4: DMD_ICN2055 + commented out SHIFTREG: current still 100mA

Tested with working display: 128x64, ICN2037 + MW245B + SM74HC04 (yes with an M). It works with off-the-shelf WF2 or esphome HUB75 default settings.

Test5: DMD_RGB, no SHIFTREG, 128x64 display regular.

Test6: DMD_RGB, yes SHIFTREG, 128x64 display regular.

Maybe my wiring isn't good? I can hookup logic tool into wireout (no display connected)

[shadowpho]

I only have enough wires for 8 pins today (will get more EOW).

Please let me know if any are shorted or dont look right (maybe I miswired something?)

Here is capture with latest test FW (basic: DMD_RGB, no SHIFTREG, 128x64 display regular.)

First 8 channels.

R1/B1/R2/G2/E are all quiet.
G1 has 24/80/160/560ns pulses
B2 has 2.6ms clock
A has 323 uS clock

last 6 channels

OE stays low
C is 1.3ms clock
D is 650 uS clock
B is 160 uS clock
CLK/Latch follow each other -- CLK is 100nS pulses, then LAT 40nS

Zoomed in: