APA102 first speed run reports. With a strip length of ~100 leds, I can run them at 20Mhz. More than that, I have to go back down to 12Mhz. I can run 360 leds at 12Mhz quite happily though.
What does that translate to in real numbers? How about Cylon, with all delays removed, 360 leds, running at 930 fps. (~90 would be the best you could get w/WS2811) - and I can’t wait to play with parallel output with these fuckers, I suspect I can get similar data rates with the parallel output. Folks wanting to do POV with high density strips (you can get these things at 144 leds/meter) - I think you’ve found your toy
Also - the library doesn’t have to disable interrupts with these chips.
Support has been in the library for months now However, i initially did it at the 1200kHz data rate described in the data sheet. I’ve just checked in code bumping that up to 12Mhz.
Yup - and because these things have a 2.5kHz refresh rate, that means the (reasonable) max frame rate you can update them at is ~2500Hz (vs. the WS2812’s which are capped at 400Hz)
I’ve seen multiple APA102 datasheets - claiming between 400-2500Hz refresh rates. The brightness adjustment i’ve only ever seen on one data sheet, but not on any others - but from a quick test it does appear to be in there. I’m going to have to give some thought to how to incorporate it into the library’s brightness management (the library actually manages brightness on an 8-bit scale for each of R, G, and B independently of each other - this is just a 5-bit brightness scale applied to everything).
It’s kind of fascinating to run one of my gradient test apps with FastLED.setBrightness(8) and setting the APA102’s brightness to 1
I think exposing the coarse brightness levels of the APA102 could be useful, for say, wearables, where you can just flip a switch for “indoor” vs. “outdoor” mode (separate from the library’s normal brightness/color management code)
The real test (of both our dithering code and things like this brightness support) is going to be when we start providing 16-bit RGB support instead of the current 8-bit.
Also - a major difference between these and the WS2812’s, when it comes to refresh rates. With the WS2812s, if you push data at > 400Hz to them, they start to glitch out and you have Weird Shit[tm] start happening. With these, I can drive them at over 5kHz, and they don’t react badly at all - which means you don’t have to worry about that whole “don’t write data too often!” garbage that you have to with the WS2812s.
Err, sorry - I mis-spoke above. I’ve driven these things at over FIFTY kHz and they don’t show any signs of glitching. Is there a max refresh rate that it makes sense to run at (otherwise, you’re just wasting updates)? Sure, probably. Do you have to, realistically, care about it? Doesn’t look like it
Hey Daniel … I sended those apa102 , 101 already to you ONE year ago … I know on data technical this Company is very " non accurered" . But there leds are good , i was in hk last month to visites them . The apa 104 and 104 's is out and should be also fast . There is a apa 105 coming with not 8 bit but 10 bit color …i Will send you datasheet off the apa 104 … Thanks for inplementing in fastled .
The APA-104, like the WS2812B before it, is anything but fast. I doubt i’d recommend that anyone consider using the APA-104 - though it does seem slightly cheaper than the WS2812B, so it might make a decent replacement for projects that are already using that.
The last time I saw a data-sheet for the APA-105 it looked like it required a signaling mechanism that would require extra hardware for use off of arduino/hobby MCUs, which is going to make it a bit more irritating to support.
