Noise at end of long chain of panels

1

Long description follows but the questions are:

Is there a fix for this and if so what is it?
Why is this happening?
Any other troubleshooting suggestions ?

I have been build relatively large matrix systems using the teensy 4. I have successfully build pieces with 10 and 12 panels. The teensy seems fine memory-wize but not when I go bigger than this.

On occasion, I find that when I get to a size of 12 panels, the last 2 panels, i.e. the ones farthest from the brain. (call them 11 and 12) show some noise in the image. My guess is that this is a data issue or data signal issue.

The first time this appeared, it was the last row of a 2 x 6 panel matrix of p5 panels (128 x 192px ) driven by a teensy 4. The noise was intermittent. Manifests itself as rows of pixels showing white or very close to white with variable widths starting at the leading edge of the 11th panel. Widths appear random. It seems to show up more often when there are more bright pixels involved and less often when there are more black pixels but no clear pattern. The same code runs perfectly without noise on a duplicate and similar matrix piece (teensy 4.x and 12 panels of p4, p5 and teensy 4.x 6 with panels of p3s which are 64 x 64 pix). This initially suggested to me that it was a hardware issue.

Thusly, i looked at power. I am seeing ~5.1 volts on all the panels under load. Also upping the power supply to something capable of 60 amps did not made a difference. Swapping out the 10th, 11th, and 12th matrix pieces also did not solve the issue. When I move the long data line to the 12th panel (vs the 11th) the noise persists and just moves from the 11th to the 12th panel. It seems like everything is fine up to and including panel 10 but falls apart after that.

Swapped/ replaced data cables to no avail.

I tried various settings for COLOR DEPTH , kRefreshDepth and kDmaBufferRows to no avail (I admit I do not really understand these settings).
Decreasing the brightness did not solve this either.

I shrugged and wrote this off the the angry LED godz and resolved that this particular matrix would only have 10 panels. Frustrating but a geek has to let go at some point. I had reached that point.

But then…

Then I got brave/stupid and built a mammoth sized piece with p10 panels. This beast is the same size in terms of pixels (128 x 192) but given the lower density of p10 panels (1/4 the number of pix in the same space) this beast was 4 panels wide x 12 panels tall. 48 total panels. The same thing happened starting at about the 6th row. (panel 21). This is about the same # of pixels away from the brain but 2x as many panels and data cables away. I tried all the same changes described above to no avail. so, no obvious hardware issue. I am stumped. In the short term I cut the monster down to a pair of 4 x 10 panel pieces. Would love to solve this and put the monster back together.

Any ideas?

2

Maybe your noise problem is caused by signal degradation along your ribbon cables. You could try putting a custom MatrixHardware_*.h file in your sketch to tweak some of the settings there. You’ll have to experiment but you might get better stability at a lower pixel clock speed by increasing FLEXIO_CLOCK_DIVIDER, though this will reduce your fps.

1 Like
3

thanks, I will give that a shot.

4

sorry for the late answer. There is a similar problem with the rPI lib when you have too many panels. I think what happens is that the signals that are pushed from panel to panel eventually get out of sync with the clock signal.
On the rPI lib you can tweak some variables to slow down the sync and fix the issue in exchange for a slower refresh.
You can also use the 3 channel output board that I use and have your length be 1/3rd as long, which will fix your issue.
Your code will still work out of the box on linux and compile with gcc since I ported it and made it work for my own displays.
If you go that route and need help with that, you know how to ping me directly :slight_smile:

1 Like
5

So, I changed FLEXIO_CLOCK_DIVIDER from the default value of 26 to a slightly slower value of 30 and it worked like a charm. Using a value of 38 gave horrifying results for what it is worth.

Thanks.