Is 1Mhz the low limit of the DATA_RATE_MHZ argument in FastLED.addLeds?

Is 1Mhz the low limit of the DATA_RATE_MHZ argument in FastLED.addLeds?

I’m using 2,000+ pixels of APA102 and still getting data loss / flickering towards the end of the length even at 1Mhz. I’m interested in trying to limit the rate even further.

Thanks for any advice.

There’s a DATA_RATE_KHZ macro you can use instead.

Awesome, thanks. Still a good bit of flicker, but it helped!

Any reason to not split up the strip, then?

Just from a programmatic standpoint. I would like the simplicity of using one Photon for the code.

Right but your data rate is way below what can be gotten with bit banging - so why not use multiple sets of output pins and split up the strip?

My understanding was there was a limitation in the Photon that prevented being able to do that. I’ve done that with a Teensy in the past using the Octo board for instance. Maybe I’m mistaken about the Photon.

I mean, you’ll only be able to use hardware spi on one pair of pins and it’ll bit bang the rest, but I bet that bit banging apa102 output on the photon is in the 3-6Mhz range anyway.

Do you know of any resources/examples on how to do that? I would be defining separate data/clock pins and then how do I instruct the Photon which pins to use for which set of pixels?

https://github.com/FastLED/FastLED/wiki/Multiple-Controller-Examples talks about using multiple strips.

Awesome. Thank you.

I’ve seen several posts that talk about the degradation of the clock signal as you go out on longer runs of apa102 chips. Some are data rate sensitive like the post below, but some of the degradation will get you even at lower refresh rates. See this Why APA102 LEDs Have Trouble At 24 MHz

https://plus.google.com/100269408062723355546/posts/BjYGDqApnVE