Two years ago I took a deeper look into the APA102. Although it was more expensive than the common WS2812, and harder to come by, it had some intriguing properties. The main benefits are a timing-insensitive SPI interface, allowing easy interfacing to standard periphery, and a much higher PWM frequency of >19kHz, making the APA102 almost flicker free.
So much about that. Considering how things with LEDs from China go, it should not take too long for clones to appear? Indeed! Recently, several comments showed up on my blog, reporting about issues with APA102 LEDs they bought. It quickly turned out that these were SK9822, APA102 clones from the same company that already brought the SK6812 to us, a WS2812 clone.
One of these people was Mike. He developed the Weblight, a WebUSB controlled RGB LED. The prototype (shown below, red pcb) worked well, but when he commissioned a small production run (black pcb), the LED started to show odd update behavior. Mike was nice enough to share a couple of boards with me for further investigation.
At a first glance, it is obvious that both LEDs use different ICs. The die used in the SK9822 is much smaller than the APA102. As a rough estimate, the APA102 seems to be 1 mm², while the SK9822 is ~0.65 mm². The smaller die likely results in a lower cost. So it is not surprising that vendors are trying to replace APA102 with SK9822…
But why are people complaining about the SK9822 being incompatible? According to the datasheet (linked here), the data format is supposed to be exactly the same. In fact, it looks like the sections in the datasheet are copied directly from the APA102 datasheet. However, even the original APA102 datasheet wasn’t too accurate when it came to the data format. For more details, please check out my post on investigating the APA102.
Probing the SK9822 quickly revealed that something was off when using it in the same way as a APA102. As shown above, the data format itself seems to be identical, and data forwarding from one LED to the next seems to work in the same way as with the APA102. However, every colour combination written to the SK9822, only was shown during the next update cycle. Some more probing isolated the issue: The SK9822 updates the PWM registers in the first cycle after the next start frame (0x00000000), while the APA102 updates the PWM register immediately after receiving the data. Since the next start frame is sent at the beginning of the next update, this means that the color update is delayed.
I can only speculate about the reason for this deviation. Possibly the SK9822 was implemented using the APA102 datasheet as a reference, and this was a misinterpretation on the, admittedly, not very accurate description of the protocol. Actually, the way the update is implemented in the SK9822 makes more sense than in the APA102, because it allows to update all LEDs at once instead of the staggered update of the APA102.
The only way to get the SK9822 to work properly is to send an additional “reset frame” of 32 zero bits at the end of the bitstream to trigger the PWM register update. Luckily there is a very easy way to implement this in a way where it is compatible to the APA102: The endframe of the APA102 can be either ones or zeroes (see here). Simply emitting another 32 zeroes at the end will not have any impact on the APA102, given that also the endframe is changed to zeros.
A protocol that is compatible to both the SK9822 and the APA102 consists of the following:
- A start frame of 32 zero bits (<0x00> <0x00> <0x00> <0x00> )
- A 32 bit LED frame for each LED in the string (<0xE0+brightness> <blue> <green> <red>)
- A SK9822 reset frame of 32 zero bits (<0x00> <0x00> <0x00> <0x00> ).
- An end frame consisting of at least (n/2) bits of 0, where n is the number of LEDs in the string.
SK9822 LED driver characteristics
To probe the SK9822 LED driver, I mounted a photodiode in front of one LED and connected it to an oscilloscope. This allowed me to directly monitor the modulation scheme of the LEDs. The exemplary image below shows both the dataline and the photodiode signal during an update from RGB=0xFF0000 to RGB=0x800000. The PWM frequency can be directly measured in the scope trace. It is 4.7kHz for the SK9822 – about four times lower than the 19.2kHz, but not even close to the 430 Hz flicker hell of the WS2812.
Something interesting happened, when I tried to change the global brightness setting. In the trace below I started with maximum brightness and reduced it to 50% by either using the global brightness register or the PWM register. As can be seen below, reducing the brightness to 50% reduces the light output from the LED, but no pulse width modulation is visible. It appears that the SK9822 uses a controlled current source to set the global brightness. This is in contrast to the APA102, which superimposed a lower frequency PWM pattern if the global brightness was not set to its maximum (see here).
This is confirmed by the trace below. Here, I activated the PWM by setting RGB=0x800000 and ramping through the global brightness setting. The global brightness setting does indeed control the driver current setting.
The implementation of a programmable current source in the SK9822 is actually a very welcome improvement. In contrast to the original, the APA102, the LEDs do not start to flicker if the global brightness is reduced. This is a very nice feature if the SK9822 is used in a display. In addition, lowering the current setting allows to reduce peak current consumption, which can be quite an issue if you have plenty of LEDs PWMed at 3x20mA.
At a first glance, the SK9822 looks like an identical clone of the APA102, but taking a closer look reveals plenty of differences, see table below.
|Update trigger||RGB data transmission||Reset frame (0x00000000)|
|PWM Frequency||~19 kHz||~4.7 kHz|
|Global brightness control||PWM at ~440 Hz||Programmable current source|
|Chip size||~1 mm²||~0.65 mm²|
In conclusion, the SK9822 is not an exact clone of the APA102. It adds some interesting features. For example the programmable current source to control global brightness and a non-staggered update. But there are also some drawbacks like the protocol incompatibility and the lower PWM frequency. The incompatibility in the protocol can be worked around by using the unified protocol proposed above.
I updated my light_APA102 library to be compatible to the SK9822. You can find it here.
28 thoughts on “SK9822 – a clone of the APA102?”
Thank you for this fascinating (and super-useful) writeup.
I’ve actually been trying out the SK9822 in a design, since the “genuine” APA102C from APA are having supplychain issues.
A friend who met with OPSCO in in Dongguan actually passed me over the ‘supplementary’ datasheet.
I’ve uploaded images here: https://www.dropbox.com/sh/7yzzh18bq7bhavl/AABvj7SlZOz47goQESz0fBOLa?dl=0
So far, the SK9822 have the same problem as Shiji’s clone of the APA102C – a distinct whine when powered over USB. Real APA102C LED dead silent on our boards, but the clones (all of which have an IC similar to the SK9822), exhibit the same problem.
My vendor for the SK9822 claims they know what the problem is and that they can build me a variant that’s quieter at the cost of a slightly higher power draw and have promised me samples within the week.
The LEDs that APA is now selling as the APA 102-2C have the same issue. I’m still waiting to get my hands on the LEDs that APA is calling the APA 102-22C.
Thanks, quite interesting! It seems that the supplementary information validates my findings.
The APA102-2C and APA102-22C that APA is selling actually seem to be the SK9822 and SK6822. It appears they are also selling the SK6812 as APA104. Maybe some crosslicensing going on? I just wish they would invest some time on creating proper datasheets…
First time I hear about the noise issue. Is this really only happening when they are powered from USB? Is really the LED the source of the noise?
I’m pretty certain that the upstream for the 102-22C is Dongguan OPSCO who I believe to be the original maker of the SK series. The APA datasheet for the -22C…is not well edi tted and in the version I snagged from their website still says ‘OPSCO’ in at least one place 😉
I don’t believe the SK6822 is one of the APA102C variants. The version of the datasheet for that part that I can find appears to have a different pinout.
My understanding of what’s going on with the genuine 102C is that there’s a supplychain issue for the IC inside and that we’re looking at May before that issue is resolved.
As to my noise issue – I’m fairly certain it’s the LED that’s singing — swapping a single clone onto a “good” board leads to that part of the board starting to sing. Populating a previously “bad” board with good LEDs quiets it right down.
My factory’s contract EEs report that switching to bench power causes the LED noise issues to go away. Locally, adding a 10k uF cap to the LED power bus also quiets it down, but that’s not exactly a…workable solutioF n.
Before admitting that they were aware of the noise problem, and had a potential fix, my SK9822 reseller recommended adding a C104 on each LED and a 4700 uF cap on the power bus at input.
All that being said, I’m very much a junior EE, having picked everything I know up on the fly in the past two years.
I don’t recall if you’re in the Bay Area, but if it’s something that you’d find interesting, I’d be happy to show you the noise issue and/or hand you some SK9822 samples, as well as some samples of two other APA102C clones that use a similar, but slightly different IC to the SK9822.
I think i also have some kind of knockoff APA102-2020 LEDs. Can you specify again how exactly the ringing appears with your boards? I have 30 LEDs on a PCB, all have their own decoupling cap 0,1uF and they induce a huge amount of noise (500mV) into the 5V supply rail! We also power them with USB from either a PC/Laptop or a USB PSU.
The only way we could “fix” some of the noise was adding a 470uF cap at the +5V rail. I tried to hear the noise as well but it’s not that obvious.
As we are using an ADC on the same board we are having trouble to get a stable reading out of it :/. Maybe you have a hint what’s going on?
This is another great review by you. I used your information on APA102 leds to write an SPI DMA library for the Due. Thank you for your effort and time.
Regarding the “brightness” bits here on the SK9822 – since it is done by current control, do you think it is possible to mux the 32 brightness values x 255 levels?
This theoretically should give 8192 brightness values although this will work on the non RGB leds only.
Yes, in principle the combination of global brightness and RGB setting could be used to extend the dynamic range. Practically there are some issues.
First, there are a lot of combinations giving identical brightness. So there will be much less than 8192 unique combinations. A second and more important issue is that the brightness of the individual emitters is not linear with the current. In fact, especially the blue and green emitters, start to become less efficient at higher current. This can be seen from the data sheet, but is a general issue with LEDs.
The latter effect means that the global brightness setting will also influence the hue of your colour setting. There may be ways to compensate for all these imperfections, but things are getting more and more complicated.
Check out this forum post on the Particle community forum for some implementations of GBC for both the APA102 as the SK9822:
Yes, I see. The low current shifting colour makes it practically impossible for an RGB type of led.
For an all-white led it seems to be more possible, but they have an efficient 765 levels anyways. This is very practical on building video lights – since the brightness curve is logarithmic, a few bits of resolution in the lower brightness levels make a difference.
This was supposed to be a reply to your last message. Sorry for messing up the flow.
Thanks for the great work! Did you by any chance characterise the efficiency curve of the global brightness setting? I did some pixel-counting from the image you attached and it seems like the slope is very close to 1, but, I can’t say I’m sure and you know your stuff.
Well, in general, LEDs show a nonlinear brightness response vs. forward current. This effect is especially pronounced for green and blue. So there is maybe 10-20% deviation, which will lead to a change in hue.
These are cool and fun to work with- but I have a question… are these LEDs making their way into commercial or industrial products?
I see them being used in many maker style applications. But since these are made by fairly small and new companies, I doubt we will see them in products by major OEMs yet.
I’ve been struggling with what I thought was an ADA102 strip but is actually the SK9822. Each time I go googling for SPI details, I find your blog post and catch up on what would take me days of research using tools I dont have. Thanks so much for taking the time to document this.
I’m leaving these two NodeMCU instructions (in Lua) here for any other NodeMCU users that might come across this blog, like the final treasure chest in an adventure game, that sets the first 3 LEDs to BGR.
> =spi.setup(1, spi.MASTER, spi.CPOL_LOW, spi.CPHA_LOW, 8,0)
> =spi.send(1, string.char(0,0,0,0), string.char(255,255,0,0), str.char(228,0,255,0), string.char(255,0,0,255), string.char(0,0,0,0))
Thanks for all the help and tips. I just found this blog. A few of us from our company were able to meet with APA Electronic in-person in Taiwan. The SK9822, SK6822, WS2812, etc are copies of their APA-104 and APA-102C LEDs. They showed us their patents and even the licensing contract WS signed but never paid. It actually took us awhile to find them, we didn’t understand why there were so many other companies or factories selling APA stuff on Alibaba but it wasn’t working as well. The president of the company James has the patent on ICs integrated into the rgb LEDs. Most of the LEDs branded as APA on Alibaba are actually not theirs. But they are starting to market their own stuff now. They have some other really cool things but they aren’t releasing them yet because of the clones and copies from China. The LEDs we have been getting directly from them have worked out well.
How about the 13-bit APA-102 chips? How hard would it be to add support for these? Are these really that different from the 8-bit ones? What happens when you send 8-bit code to 13-bit LED?
I did a little investigation and posted in the comments here: https://cpldcpu.wordpress.com/2014/11/30/understanding-the-apa102-superled/#comment-7082
Hi there. Thank you for this nice review and investigation! I’m new to these LEDS but I’ve an question. I’m struggling with all these different claims made all over the web including the problems made with the clones sold as originals. So are you sure that the left LED on the red PCB is an APA102 and not an APA102C? According to an post on an German webboard the APA102 has a square shaped lens, the APA102C a round shaped one as seen here. That’s the picture referred in the post: http://www.directupload.net/file/d/4600/rh8ep5yn_png.htm (Website down right atm.)
I bought an strip sold as SK9822 and one sold as APA102C, both seem to be exactly the same (except the wiring) and have been packaged by the same intermediary or manufactor called Mokungit(.com) or IShareLed(.com, forwaring to mokungit.com).
Any additional information would be nice.
Thank you anyway!
I’m not sure I follow how the update is simultaneous. Presumably the reset frame still needs to get clocked through all of the devices, right? In my brief experimentation with a strip maybe-made with these, it looks like sending a zero frame does not cut through the shift register chain delay.
Great read. Thanks. Do you have any more information on the photo diode you used and the configuration to measure the pwm frequency. Thanks
I think I used a BPW34s directly connected to the scope via a sensing resistor. This is neither very sensotive, nor fast, but sufficient for this task. You can measure the PWM frequency directly from the power rails with a small series resistor (or none) if you only use a single device.
So I used a BPV10 photodiode with a 22K ohm resistor and looked at some 6-pin APA102-2020 chips I got from APA’s China Mainland contact listed at the bottom of http://neon-world.com/ back around August of 2018. The PWM frequency is around 600~700Hz (yes, Hz) and the global brightness setting seems to change the driving current directly. Also interestingly the RGB setting seems to correspond with the perceived brightness rather than the duty cycle. I get around 50% duty cycle when the value is set to 200. Are the IC in those different from that in 5050 sized APA102s?
Yes, there are quite a few variants of APA102 compatible chips out now and is very difficult to keep track. One variant uses gamma correction to convert the 8 bit RGB value to a 11/12 bit PWM value.
APA neon themselves mentioned that they would redesign the chip to current dimming: https://hackaday.com/2014/12/09/digging-into-the-apa102-serial-led-protocol/#comment-4934741
I did not have a chance yet to look into this in detail.
A very interesting article Tim!
If the SK9822 achieves dimming by reducing the current instead of introducing PWM, does that mean it actually outperforms the APA102 at low brightness levels, because it remains at 4.7kHz, while the APA102’s 19kHz frequency gets reduced?