SK9822 – a clone of the APA102?

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.

sidebysidenotext

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.

sk9822logictrace

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.

Unified protocol

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:

  1. A start frame of 32 zero bits (<0x00> <0x00> <0x00> <0x00> )
  2. A 32 bit LED frame for each LED in the string (<0xE0+brightness> <blue> <green> <red>)
  3. A SK9822 reset frame of 32 zero bits (<0x00> <0x00> <0x00> <0x00> ).
  4. 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.

ws9822_update
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).

ws9822_global_vs_local

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.

ws9822_red_scale

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.

Summary

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.

APA102 SK9822
Update Staggered Simultaneous
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.

3 thoughts on “SK9822 – a clone of the APA102?

  1. 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.

        -j

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s