I bought a 10-pack of Sparkfun bare APA102C LEDs (COM-14863, Batch #126166; via Digi-Key) to validate a design before ordering a bunch for a small production run of kits for internal use at the vocational school I’m working at.
When the package arrived, I noticed that of the 10 LEDs, only one was still in tape, the other 9 were loose in the baggie. I didn’t think much of it until they were soldered to a test PCB: 3 of the 10 LEDs do not work properly. At maximum brightness, they’re not quite as bright as the others, but when dimmed even a tiny bit, their brightness plummets compared to the rest. Additionally, instead of the ~20KHz PWM frequency an APA102C should have, the three weirdo LEDs use a frequency of just around 715Hz.
Using a solar cell as a sensor to measure the light output waveform, and a magnifier to get a look at the LEDs up close, it appears that this 10-pack of LEDs contained at least three different hardware variants:
-
larger IC die, blue LED die oriented horizontally, 20KHz pixel PWM, 500Hz global brightness PWM, ever so slightly milky epoxy (2pcs)
-
smaller IC die, blue LED die oriented vertically, 20KHz PWM for both pixel and global brightness, glass-clear epoxy (5pcs)
-
smaller IC die, blue LED die oriented horizontally, 715Hz PWM for both pixel and global brightness, glass-clear epoxy (3pcs)
(so the best performer, #2, is visually most similar to the worst performer, #3)
There are also differences in how much light the LEDs allow to escape backward through the PCB: The two #1’s allow a bit, one of the #3’s allows a lot, while the remaining two #3s and all of the #2’s allow none. So it might even be 4 hardware variants.
I think we can rule out a PCB layout problem, because it works for most of the LEDs, and I duplicated the layout twice more for testing SK9822’s, which are pin-compatible (and 99% software-compatible). I don’t think there’s a fabrication or assembly error, since the bad LEDs are receiving their commands and forwarding on the rest. It’d be one heck of a coincidence for soldering or ESD damage to occur to precisely the 3 LEDs of one variant, and to none of the other 37 LEDs I soldered.
I tried it with three different LED libraries (Adafruit Dotstar, FastLED, and NeopixelBus), which made no difference. I tried it on two different Arduino Pro mini clones, as well as on a breadboarded ATMEGA328P. All three MCUs behaved identically.
Ignoring the different color byte order, even daisy-chaining the APA102C’s before, after, or between SK9822’s is no problem, other than the 3 problem LEDs.
Using hardware SPI pins makes things behave even worse: the bad LEDs then fail to produce any blue light whatsoever. The other variants of APA102C’s around them on the same bus (and the SK9822’s) work fine.
Any ideas what’s going on here? For sure, there are undocumented different variants of the LEDs, since I can observe multiple kinds of hardware, and even among the 20KHz ones, two different approaches to global brightness. Are the malfunctioning three LEDs merely yet another variant that requires slightly different signaling to work properly? Or are they actually broken?
Thanks for any assistance you can give.
(I will say that, having spent the better part of a day monkeying with these, I think it’s really uncool to mix different variants of a product within a single batch. I could understand (if not necessarily adore) different batches being of different revisions or suppliers, but not mixed up within a bacth. And either way, it should be clearly documented. As it is, this has made this endeavor useless for component validation, since I have no way of knowing what I got, nor what I’ll get in the future.
In contrast, the Adafruit-repackaged LEDs I ordered at the same time came on tape, vacuum-packed with desiccant by Adafruit, and then vacuum-packed again by Digi-Key. )