NeoPixel Matrix doesn't work correctly

[Alex P]

Build: ESP_Easy_mega_20240331_neopixel_ESP32s2_4M316k_CDC assembled a 32x8 matrix, When displaying a static image, everything is fine, as soon as scrolling is turned on, the top 4 lines run normally and the bottom 4 lines run in a different color from the garbage.

[TD-er]

Yep, the neopixel timing is extremely critical.
I still have to look into this especially as the way how we can address these addressable LEDs using ESP-IDF5.1 (thus ESP32 LittleFS builds) is completely different and even more timing-critical.

However it might be that the interval of sending a new "frame" may need some extra delay when using more pixels.

Can you test with using half of the pixels as a test? Then the next 128 LEDs should show the "previous frame", but at least without garbage.
If this does work, then I guess we simply need to make the time between frames more dynamic based on the number of pixels.

[Alex P]

ESP_Easy_mega_20240331_neopixel_ESP32s2_4M316k_LittleFS_CDC I didn't start at all. if you make a 32x4 matrix, then half of the font runs in 4 lines, the bottom 4 are empty. When outputting via neomatrixcmd, settext, in the rules of different lines not running, everything is fine. tell me how to check.

[Ath]

A few remarks:
- Have you installed a level-converter between the ESP and the Neopixel matrix? As that matrix is supposed to run at 5V and the high-level of the ESP is too low to properly trigger the Neopixel. This might get worst with longer strands
- A matrix of 32x4 is not actively supported, you won't be able to display text on it correctly, as the smallest font is 8 pixels high. A working matrix could be 16x8, or even 8x8

I assume you have studied the documentation for P131 ? The examples are quite elaborate, and the Signal wiring chapter is sort of a required read...

[Alex P]

I haven’t used a level converter yet, I just installed a resistor. I tried the same controller with a different firmware, the creeping line comes out correctly. I reduced the matrix for testing on the advice of TD-er, perhaps he meant something else. I don’t understand what the software difference is in displaying static images once and 1s and a creeping line at the same speed? As far as I understand, the output signal is regenerated in each LED, so it should not depend on the number of LEDs.

[TD-er]

My intent of reducing the grid size is to see if it is a timing issue.
Let's assume N pixels can be sent in a single burst.
So if the chain is too long, it will be split into separate bursts which might be interrupted by background tasks like WiFi activity.
Depending on the type of addressable LED and ESP board this split can be in the middle of a LED.

So it can be that reducing the number of LEDs may appear to fix this corruption.

[Alex P]

How to change the grid size? I tried changing the dimension of the 32x8 matrix to 32x4. But before that it worked for the top 4 lines. But I don’t want to cut the tape for a different configuration yet.

[Ath]

How is your matrix configured? Do you have a manually assembled matrix of 32 pixels long, and 8 high, or are you using pre-assembled 8x8 modules?

[TD-er]

Since it is not intended to be used like this but just to check if you get corrupted colors, you can also try 16x8.
Anything you will be sending to the display may be misaligned, but like I said it is just to check if sending the data in smaller chunks may be a fix.
If it is, then we can implement this as a software fix.

[Alex P]

Understood. But to do this you will have to cut and resolder the tape. Now I have it from 8 pieces of 32 LEDs.

[Ath]

Without cutting the tape you can still configure it for 32x4 or 16x8, the only thing we want to determine is if your issue is caused by timing or not, so we 'give' it half of the neopixels to control. Then it's less timing-critical.

[TD-er]

And since the LEDs are forwarding their data to the next pixel, you will end up with the "unaddressed pixels" also being updated.
At least that's the idea.
Not sure if these LEDs will detect some 'timeout' and thus not forward their data after such a timeout.
But if they do, then sending in chunks may be a proper fix for this issue.

[Alex P]

I already tried 32x4, I don’t understand how to make 16x8 without cutting and resoldering. I tried to put 32x16 although in fact I have 32x8 and 1 line started working fine for me. It turns out that the second half always does not work when running the line starting from 32x4.

[Ath]

I already tried 32x4, I don’t understand how to make 16x8 without cutting and resoldering. I tried to put 32x16 although in fact I have 32x8 and 1 line started working fine for me. It turns out that the second half always does not work when running the line starting from 32x4.

Reading back the messages in this issue, it seems you always have trouble addressing past the 32x4th pixel. Maybe there is a wiring/soldering issue, from the 4th to the 5th line?

[TD-er]

What I meant is just a setting in the software.
And sure the displayed image/text will be garbage, but it is a test to see whether this is a software issue.
What I hope will happen is that you will at least see the correct color on each pixel instead of missing 'bits' and thus completely wrong colors.

No need to start soldering, just send less pixels at once.
And the second 'image' will then be moved in and thus moving the previous image to the yet unaddressed pixels.

[Alex P]

I've already done all this. And he told about the results obtained. Pay special attention to the last result with 32x16.

[TD-er]

But setting it to 32x16 isn't less pixels, or am I missing something?
16x8 is less than what you had and sure it will probably mess up your intended picture, but it will send less pixels in a burst.

[Alex P]

In fact, I have 32x8. I tried the 32x4 and 32x16 options. I can't do 16x8 without soldering.

[TD-er]

It is not needed to solder, just try the 16x8 (or 8x8) as setting.

[Alex P]

This is not possible, the matrix consists of 8 pieces of tape with 32 LEDs connected in a zigzag, it is impossible to get an image on 16x8 or 8x8. And when you rotate the display 90 degrees, the ticker works fine, but the screen still remains on 1 line. I think the problem is not related to the number of LEDs or time intervals. I need to start simple, install a level matcher.

[Ath]

I need to start simple, install a level matcher.

That, and also check the wiring & soldering from the end of line 4 to the start of line 5, as from line 5 on it's not working as intended.

[Alex P]

OK, thank you. There is still a question about rotating the display 90 degrees, what will happen to the lines? With a 32x8 rotation, how many lines should there be?

[TD-er]

I still think we do not fully understand eachother.
Either you don't understand me, or you do and then we don't understand you.

Just consider all LEDs as a single string of LEDs which happens to be laid out in a specific pattern.
When considering the specific pattern, you may think about 'rows'.
But when laid out like a single long LED strip, it probably becomes more clear what the issue might be.

I think (assumption) that when considering it as a single long LED strip, you see the correct colors only in the first N LEDs counted from the ESP side.
If that's the case, then it might be some timing issue. (N.B. not using a correct level converter may also cause timing issues)
And if it is a timing issue, then this might be fixed using some tricks in software.

However when the LEDs with wrong colors are happening only at certain intervals on the long LED strip and inbetween the LEDs show the correct color, then there may be something else completely wrong (no idea yet what as I don't think this will be the issue)

Now back to the actual pattern of the LEDs as it isn't a long straight LED strip but more like a zig-zag layout.
How are the LEDs laid out? In what pattern?
I assume -based on your remark about missing lines- it is like this:

Code: Select all

31 ... 0
63 ... 32
95 ... 64
127 ... 96
...

So if you would "rotate" the display (in software), I think the same physical pixels will show issues.

Either there is some soldering issue between pixel 127 and 128, or it is a timing issue.
As you mentioned, you can show a full static image, which makes it less likely that there is a soldering issue. (still possible though)

So my question is, how are the LEDs connected?
What is the order of LEDs?

[Alex P]

0 ... 31
32 ... 63
64 ... 95
96 ... 127
128...159
160...191
192...223
224...255
This is a zigzag structure. When I asked about display rotation, I meant lines or (lines of text). How many should there be for my matrix? neomatrixcmd,settext,2,text cannot be displayed?

[Ath]

Can you show the configuration settings of your plugin? (a screenshot, as an attachment in the forum, is fine)

[Alex P]

Yes. Certainly

Снимок.JPG (69.21 KiB) Viewed 453 times

[Ath]

With that configuration it should work as intended, so it probably comes down to some technical (or timing) issue.

NB: With this configuration, rotating the display by 90 degrees, can be done by setting "Matrix start-pixel" to "Top/Right", and Rows/Columns mode to "Columns".
But that won't give you 4 rows of (short) length, but 1 quite high row where you can display a single 4x font-size line of text. Rows/Columns are actually based on 8x8 matrices like shown in the documentation (didn't order the somewhat odd-sized 5x8 also shown there), as most fonts used are also 8 pixels high.

NB2: Do you have another type of ESP available for testing? As the ESP32-S2 is somewhat of an odd-ball model, with lots of technical quirks, that has practically been replaced by the ESP32-S3. That other ESP type for testing can be anything from an ESP8266 or another type of ESP32 (Classic, C2/C3 or S3).

[Alex P]

After installing the level converter, the main problem went away, only periodically appearing colored artifacts remained throughout the field. It is also not clear why there are not 4 text lines when rotating, since the matrix is a multiple of 8x8?

[Ath]

After installing the level converter, the main problem went away, only periodically appearing colored artifacts remained throughout the field.

Great.
Those odd artifacts may be caused by general timing issues of the S2, as said, that's not the most stable ESP32 chip

It is also not clear why there are not 4 text lines when rotating, since the matrix is a multiple of 8x8?

Text lines are based on the Tiles dimensions, not on the matrix(size). That's by design of the used library. But as you have built your own matrix, you can still re-wire them into 8x8 matrices

[Alex P]

Thanks for the explanation. Now I understand that the rows are based on tiles and not the size of the matrix.