I have some issues with the new master of FastLED + ESP8266 2.3.0 (Arduino

I have some issues with the new master of FastLED + ESP8266 2.3.0 (Arduino 1.6.5)

If I try to address 1024 APA102 LEDs with ESP8266 (both, 80 and 160 MHz MCU clock) - the last 200+ LEDs are flickering and noisy.

Do you have any idea - what the problem could be?

The power is feed in every panel (8x16 Pixel) and there are 8 panels in chain.
Data & Clock lines are chained through all panels.

Hope someone has a good hint for me.

Thank you guys

Try lowering the clock rate for the SPI output - but that said, most folks I know have run into issues with long chains of apa102 pixels - something degrades the signal over long stretches, and it doesn’t appear to be related to voltage drops.

Sometimes the issue can be resolved with using a lower data rate. I’m trying to remember whether or not a level shifter to bring the signals up to 5v ever helped or not.

Thx @Daniel_Garcia for the fast reply. I will try to use lower clock rate tomorrow. But I thought I already try to use something like 5MHz…
Levelshifter is a good hint - but I think it is not needed, because the first ~900 LEDs are stable without flickering…

Can you tell me - if the Hardware SPI support will come to ESP8266 - or only for the next one (ESP32) ?

Hardware SPI support isn’t going to come before I finish the RGBW/RGB16 work - since I’m trying to focus on finishing that, and I only have so much time. However, given that hardware SPI will likely drive things faster – that may actually exacerbate the problem. (And is part of the reason why I haven’t really bothered chasing down hardware support for SPI yet).

For my own projects, my solution has been to limit the maximum length of my APA102 runs to no more than a couple hundred leds.

Good to know. I really love the idea of bringing FastLED to RGBW world.

Maybe I’ll try to do the 1024 LEDs with Teensy 3.1/3.2 and hook the ESP8266 just on serial for controlling over WiFi…

But first, I’ll try your first hints (slower rate and levelshifter)

The teensy 3.x was where I first discovered these issues, because at the time, the teensy 3.x had the fastest hardware SPI available - so I was having fun running my 768 APA102 led board at 24Mhz SPI - but then quickly found that most apa102 strips (and a handful of panels as well, but I don’t have many of those to test) have problems with higher clock rates the more APA102’s you have.

Oh man - good to know that. So what can I do to run 1024 LEDs?
Is it possible to split them of two data lines? Or is this feature not available for ESP8266?

Since APA102 output on the ESP8266 is bit banging right now anyway - you could put two strips on two separate pairs of pins :slight_smile: So yes, you could do that and have to 512 led lines most likely.

And yeah, this is irritating. It’s one of a number of problems I have with the APA102 that’s taking some of the shine off of how great they are from a data rate/refresh rate standpoint.

(The other one being that my APA102 strips seem to enjoy dying at the slightest provocation - whereas I can’t remember the last time I lost a WS2812B strip/led).

Yes, you are right - they are bit banging on ESP8266. Ok so I have another scenario to try out tomorrow. Hope one of them will work for me :smiley:

Btw. on my LED panels there are also some pixels died :confused:
Thought the APA102 quality is very poor.

Next panel I will try the “new” SK9822 LEDs. The company I got the APA panel from told me, that the SK9822 are more stable and longer life time. Hope they are right…

Thanks again for your fast and perfect help Daniel. What a wonderful and good working community

I changed my sketch to use two data/clock ports with 512 LEDs each. It seems to work more stable now. But I can’t test it in complete, because some of the LEDs are dead and I have to reopen the profile case and change the dead once. Next time I’m in the hackerspace I’ll fix them and test again.
But I think using multiple ports is a great idea. Thx again