64x32 1/8 Issue

Hi,

As far as i know there isn’t a kPanelType for 64x32 1/8, only for 64x32 1/16, how can i edit the ones already exists so it can work with my panel?

This is my panel:
dualshop.com.br/modulo-painel-led-p5-rgb-2727-smd-64x32px-18-scan-hub75-uso-externo-k2531
resolution: 64x32
Scan rate: 1/8 Hub75
It uses 2727 SMD chip.

The Hardware:

The problem:
kPanelType = SMARTMATRIX_HUB75_16ROW_MOD8SCAN;
does not work properly.

I am using the FeatureDemo Sketch with the following setup:

#define GPIOPINOUT ESP32_FORUM_PINOUT
#include <MatrixHardware_ESP32_V0.h>
const uint16_t kMatrixWidth = 64;
const uint16_t kMatrixHeight = 32;
const uint8_t kPanelType = SMARTMATRIX_HUB75_16ROW_MOD8SCAN;

those are the lines i added or edited, i didnt touch the rest of the code.

My result:

Hope you guys can help me ! Thank you !

Hi, there’s instructions here: https://github.com/pixelmatix/SmartMatrix/wiki/Multi-Row-Panels

@Louis Thank you for the fast awnsware!

I got the unrap idea, i just dont know how to set these variables acording to my pannel:

const uint16_t kMatrixHeight = 4;
const uint8_t kPanelType = SM_PANELTYPE_HUB75_4ROW_MOD2SCAN;
//const uint8_t kPanelType = SM_PANELTYPE_HUB75_8ROW_MOD4SCAN;

I should add this line to the example to make it more clear:

//const uint8_t kPanelType = SM_PANELTYPE_HUB75_16ROW_MOD8SCAN; // Use this to reverse engineer mapping for a MOD8 panel

I believe you need these values for reverse engineering your panel:

#if (SKETCH_MODE == MODE_MAP_REVERSE_ENGINEERING)
const uint16_t kMatrixWidth = 128;        // must be multiple of 8
const uint16_t kMatrixHeight = 16;
const uint8_t kPanelType = SM_PANELTYPE_HUB75_16ROW_MOD8SCAN; // Use this to reverse engineer mapping for a MOD8 panel
#endif

I can’t thank you enough.

It’s working properly.

Now i will keep going in this unwraping stuff so i can map it out!

@Louis
After testing the map i made it’s like this, even when i try sketches i saved and that i know is working.
What do you think, hardware damage? libraries mess?
I tried running Blink and its ok but i think maybe some digital port may be damaged.
Help pls :stuck_out_tongue:

It’s not working even if you remove all the library changes you made and run a sketch using an existing panel map?

Exactly.
I removed the library and put a new one and it’s still displaying those two lines only, If I remove from USB and connect on a power supply it starts blinking like crazy.

Sorry, it’s hard to diagnose what’s going on. It doesn’t look to me like the panel is being refreshed, it’s just stuck with some LEDs on with a single address. If you had spare ESP32s or panels I imagine you would have tried them already, that’s what I would try.

@matbks try this

const PanelMappingEntry panelMapP5_2727_64x32[] = _ {
{0,64,64},
{8,0,64},
{0,0,0}
}
from the following link:

Thank you!
But that’s exactly what i did


{0, 64, 64}
{8, 0, 64}
{0, 0, 0} // last entry is all zeros

i am very confident that some digital port was damaged by the code, i will use another esp32 and if it work again ill see if i missed any row by running the mapping code again.

I made all the tutorial, very calm, i’m pretty sure i made all right :confused:

Yeah, i was right, the esp32 got damaged when i run the map test somehow.
I put another in place and now the reverse engeneering is working again.
Please, analyse the files below and tell me whats wrong, i commented it just for be easy for u to analyse, the original one is not commented.

@Louis @technikfreak

@matbks
Hello Mateus, I used your files on a teensy 3.2 and teensy 4.0, both work for me, I don’t have an ESP32 to test.

Problem is when you use in ur code the panel type I made. As map testing.

I don’t see anything wrong with the mapping you added. I’ve never had an ESP32 board damaged while trying unstable code on it. It seems unlikely that the code broke it. It’s possible to damage a pin by driving a pin connected to GND on the panel with 3.3V (e.g. the D and E address lines which aren’t used by the panel and are probably grounded, but I’ve never seen this happen and I’ve driven panels with the wrong config). I think it’s a coincidence that you tried some code and the ESP32 broke, but I could be wrong. Does the ESP32 program and run code? If it’s just one or two pins that are damaged, you could swap the pins used in the MatrixHardware config file and use pins that are working.

I used another esp32 and it worked just fine when I run the reverse eng. Sketch. Then I played again the map testing sketch and the new esp32 entered in the same mode that before, two fixed red lines and can’t compile unless holding boot. but this time I did not switched to power supply for testing (probably the step that damaged a port before.)

Did I forget of editing some anothler file?

two red lines and can’t compile unless holding boot

I think that’s more or less normal with the FORUM_PINOUT, as some of the lines that drive the panel are also used to select the boot mode during reset. You might have better luck with a different pinout. I’m used to holding the boot button or sometimes holding boot and pressing reset before programming with the ESP32 depending on the circuit I’m using.

I’m not sure if this is the complete list of pins that ideally should be left floating during reset, but it’s at least most of them (copied from another project):

// IO12 (MTDI), IO15 (MTDO), GPIO0 • GPIO2 • GPIO5 are used for boot strapping, so shouldn't be driven during boot

entered in the same mode that before, two fixed red lines

I don’t know why you’re seeing this. I just added your config to my local SmartMatrix Library, and tried it and I’m seeing a partial image, not just two red lines. I’m using a circuit with a latch, not bare wires though

What am I supposed to see during map test?
Isnt it the red dot going from pixel to pixel In a linear way? Or is it a image? Cause I used to see those red rows when trying to run in usb a sketch that demands more power than USB can give, but if it’s just a red pixel moving it should be just fine in USB as well as reverse engeneering sketch runs.

I ask cause I don’t want to burn another esp32 ports (if that’s what rly happened)

Yes, just one dot at a time

Your update worked @Louis

But looks like the ESP32 can’t handle that much current.
The component showed below starts smoking as the demo sketch runs.
Any idea of how i can handle this ?