Can someone tell me if my ledmatrix problems still are power related.
watch my youtube video:
I have some other videos there showing perhaps even better.
On youtube i have more extensive information about the build.
https://www.youtube.com/watch?v=gzsuoY8Qm6U
Is the flashing the problem?
No, i should post another video. I have a couple other on youtube where it’s more visible. Sometimes or very often the 7 last lines flashes randomly, and the last line almost always flicker. more visible in this: https://www.youtube.com/watch?v=v30z_j97GBg
Ah thank you. That video helps understand the problem a bit more.
Are you injecting power at each row? (Or column?)
@Anders_Erlandsson
Start by setting your whole matrix to full brightness white, no animation… Then measure the 5Vdc at various points. You must not get lower than 4.5Vdc anywhere in your matrix. If you do, you must either replace your PSU with another that can supply more amps and/or beef-up the wiring to eliminate the voltage drops.
Actually, full FFFFFF may not be realistic, but the test idea is still valid:
Put ONE high-power-draw image on the LEDs,
Call FastLED.show() ONCE and then basically halt.
Measure voltage as suggested above.
If V < 4 anywhere, it’s a power problem.
If V > 4.5 everywhere, it’s a comm problem?
Thanks, i’ll do that. But i thought it was suspicious that the same flicker shows when pulling down the brightness level to 10-15%.
Next test: put a one-second ::delay() after FastLED.show(). Watch for several minutes. Any flicker?
maybe adding some capacitors between + and - , a little keramik and a big foil capacitor. This helped me in one project a lot
Lars: I have 100nF on every led. Without them only 2 lines worked ok. I am waiting for a 40amp supply.
Ah that’s good. Maybe your psu is to weak. Maybe you should measure the voltage.
Where’s your code? Have you pulled the most recent version of FastLED where I added PL9813 timings or are you using another chipset’s timings? If you use the wrong chipset (or, if my timings are off) it can cause problems that propagate out and get worse further on down the line. Also - what controller are you using for this?
I use greatscott’s on http://instructables.com code. (it is using ws2812b timing) Can’t remember if i tried solderlabs own code. It is running on a Nano from PC. But i can try it on a Uno or Mega2560.
I cant check right now as i am home. I have the matrix in my other home 
I have not downloaded the latest fastled, but i’ll try that also.
Also - what does your code look like that you’re running on the nano? Since you’re sending data from a PC I’m wondering if you are having frames getting corrupted while reading because of the disabling of interrupts while writing out led data.
i am using this code: http://www.instructables.com/id/Make-your-own-15x10-RGB-LED-Matrix/step7/GLEDIATOR-PL9823-Arduino-Sketch/
Ah - ok, that code is way too simple. Here’s what is likely happening. You are getting a frame of data, and then writing it out. While that frame is being pushed out, for approximately 15ms, interrupts are disabled. This means that any serial data which happens to come in during that period of time will be lost. Then after FastLED.show() returns, you start reading again, and now you’ve got a partial frame, maybe shifted by one byte so things will suddenly look weird for a frame or two. Then things just happen to line up again.
This is the problem that a lot of people have with adalight/boblight/etc… and WS2812 pixels.
There’s two solutions. One is to change the protocol between the nano and the computer to one where the nano sends something over serial that basically says “Ok, start sending data!” so the other side waits until it gets that before sending led data down the line.
The other (and this is what adalight/boblight do) is to add a 6 byte header to the led data, and have your code wait until it sees that set of six bytes before starting to read the frame. See the code here - https://github.com/Wifsimster/adalight_ws2812/blob/master/Adalight_WS2812.ino - for an example of how to do this.
(The third solution is to not use leds that require blocking interrupts when writing data, e.g. APA102, and the fourth solution is to try using a fast arm platform like the teensy 3.2 which allows for some interrupts to work while writing out the led data).
I suppose another solution would be to make sure the code that’s sending data from the computer waits a minimum of 20ms after finishing writing a frame before starting the writing of the next frame, to make sure that FastLED.show has finished.
ok, well i have never programmed anything so i would not know how to do that.
Solderlabs (glediator sw) own code does not use fastled http://www.solderlab.de/index.php/downloads/file/33-ws2812-glediator-interface-v1
Strange that no-one have made a working code, i mean it is a pretty popular software to drive displays?
That code that you linked to uses a “magic value” to indicate the start of a frame (if the received byte is 1, restart reading the frame). This protects against reading a frame partially while interrupts are disabled while writing out led data.
Ah - and re-looking now at the code you linked to - it does appear to be doing that (waiting until it reads a 1 value before starting to read a frame of data - I misread it at first, and thought it was just waiting for data to be available).
So, one thing to make sure of is that the glediator output isn’t ever putting out a value of 1 for rgb values (hopefully that’s something the glediator software takes care of? I don’t use it at all).
If it doesn’t ever put out a 1, then we’re back to the wrong timings possibly being used. Have you gotten the latest version of the code and changed your addLeds line to:
LEDS.addLeds<PL9823, dataline>(leds, NUM_LEDS);
No, i have the matrix at another location where i live, and can’t try anything until i’m there. The first thing is to try the new supply and latest fastled and look over my power when it arrives. Then i’ll try the other tips here.