A few months ago, I announced that I would take a closer look at the newest "SK6812" RGBW 12V model with individually addressable LEDs. Even then, I suspected that a different chip was used to market it under a more popular name because classic SK6812s also come in 12V, but they are grouped in clusters, whereas these are individually addressable.
For the tests, I will be using the latest version of Hyperk 0.0.5 (link, more: homepage). As the LED controller, I will use the ESP32-C6 mini, as I consider it to be one of the most interesting platforms currently available for around $4, alongside the classic ESP32. It will be paired with an Adafruit 6066 (3.3V to 5V level shifter) and a bench power supply using two current injections for the LED strip.
We will also assess the actual current draw of the classic 5V SK6812 RGBW, because questions like 'what wattage PSU do I need' have been popping up on my GitHub for years.
So, is it fake?
| SK6812 12V I've received |
 |
Let's examine the silicon dies of both the 5V and 12V SK6812 versions under the microscope.
| SK6812 5V | "SK6812" 12V |
 |
 |
As you can see in the microscope images, these chips look completely different. The 12V version has RGB diodes placed closer together and smaller ground pads, which also act as heatsinks.
Another thing indicating a different model is unusual LED protocol color order that differs from the traditional GRBW found in the 5V SK6812. Therefore, you must select the color order in Hyperk as shown in the picture.
| Hyperk Color Order Setup |
 |
This also means that older RGBW calibration versions in HyperSerial and HyperSPI might not work correctly, even if you correct the layout in HyperHDR. Older calibration algorithms expect a specific color sequence. You need to use their newer firmware versions, where HyperHDR calculates the white color itself (https://wiki.hyperhdr.eu/ICE-RGBW) and sends the ready RGBW data in direct mode, or use Hyperk and correct the color layout there instead of in HyperHDR. By the way, Hyperk 0.0.5 version also brings support for USB HyperSerial communication.
So we are almost certain it is a fake... but is that necessarily a bad thing? On the topic of fakes, I would like to mention my recent experience with the HD107S, purchased on AliExpress for quite a bit of money to implement and test the Infinite Color Engine. What I received behaved exactly like this:
| Fake HD107S PWM |
 |
Pathetic PWM – the original HD107S should have a much higher PWM frequency. The packaging had no markings, and they probably sent SK9822 instead. It seems that the Chinese have started counterfeiting Chinese products themselves. Anyway, who cares. If you want to know my opinion on the risk of buying an genuine HD107S on AliExpress: be assured my friend, the risk is extremely low 😉 - simply don't buy them there.
So, let's see how this fake 12V "SK6812" compares to the original.
Power consumption
With LEDs completely turned off.
| SK6812 5V | "SK6812" 12V |
 |
 |
Nice. A 30% lower standby power draw. To eliminate it completely, you'll need a power relay, such as the one built into the Gledopto GL-C-616WL / GL-C-618WL all-in-one LED controller, which is also supported by Hyperk.
Let's compare the power consumption for 300 LEDs: 5V SK6812 vs. 12V "SK6812".
| SK6812 5V White LED | "SK6812" 12V White LED | SK6812 5V Red LED | "SK6812" 12V Red LED |
 |
 |
 |
 |
| SK6812 5V Green LED | "SK6812" 12V Green LED | SK6812 5V Blue LED | "SK6812" 12V Blue LED |
 |
 |
 |
 |
As you can see, when it comes to the white LED, the power draw is comparable, but for single R/G/B channels, the classic SK6812 RGBW 5V strips are significantly better. And this brings us to a cliffhanger: power consumption for white color mixed from RGB(255,255,255)...
| SK6812 5V RGB | "SK6812" 12V RGB |
 |
 |
A "Wait! What?" reaction is entirely justified here. While in the case of classic 5V SK6812s, the power draw for such a mixed white color is the sum of the individual R/G/B channels, for the 12V "SK6812" version, it stands still like a rock.
To be sure that I controlled it correctly in Hyperk, I verified it visually, and it turned out that I had set it up properly.
| W vs RGB control |
 |
Is this a good thing? Not necessarily, though it requires further testing. My first thought was a cheap power limiter. AI added that inside the chip, it could be a series R-G-B layout on a single constant-current trace. I’m no expert on internal LED construction, but I can definitely test this experimentally.
Then I cut off the first LED, and these are the results for it alone. HyperSerial and HyperHDR ICE RGB to RGBW algorithms will never allow you to set RGBW(255,255,255,255) on default settings, as the white channel is calculated and subtracted from the RGB values. However, an experiment with this value allowed me to determine that the power for the white channel and the RGB channels are separate. This is crucial. You must keep in mind that if you are driving the LEDs using different software, in an extreme scenario like RGBW(255,0,0,255), it will consume a massive amount of current and heat up significantly. But I am getting ahead of myself here.
| "SK6812" 12V RGBW(255,255,255,0) |
"SK6812" 12V RGBW(0,0,0,255) |
"SK6812" 12V RGBW(255,255,255,255) |
 |
 |
 |
Let's verify this "SK6812" 12V power limit
A primitive power limiter combined with a classic LED design is basically the worst solution, which would completely disqualify this fake. Imagine you are displaying a red color, RGB(255,0,0) – you get a bright, deep red, and the LEDs emit the maximum light restricted only by the limiter. Then, you gradually increase the green channel: RGB(255,1,0), RGB(255,2,0)... you assume the red won't change here, right? However, due to the limiter, it will be cut down to allocate some power to the rising green channel... causing an unpleasant non-linear correlation where the color channels are coupled together.
An alternative explanation is that the diode at the maximum level of 255 always draws those 28W, but it is distributed across all those sub-diodes connected in series. Thanks to this, we get stable rendering, but if, for example, we only want to display the color red, the rest of the energy that the red sub-diode cannot emit will have to be dissipated as heat. We are therefore dealing with a paradoxical situation where these LEDs will heat up at maximum RGB levels the least when displaying white RGB(255,255,255) (since most energy is emitted as light), and the most when displaying only red, blue, or green. Exactly the opposite of classic 5V SK6812s. Additionally, if we independently add the white channel to an already active single R/G/B channel (a situation that shouldn't occur in HyperSerial RGB to RGBW conversion with default settings), it will introduce a second power channel and turn the LED into quite a heater. This might affect the lifespan of these LEDs over time.
So, I built a simple circuit using a photodiode and checked on an oscilloscope whether the intensity of the mixed channels is the sum of the individual channels, which would indicate a series circuit.
| R | G | B |
 |
 |
 |
| R + G | R + B | G + B |
 |
 |
 |
| W | RGB | RGB + W |
 |
 |
 |
This fairly conclusively shows that the channels are decoupled, which is very good news. By the way, you can observe here that the white diode is significantly stronger than conservatively assumed in https://wiki.hyperhdr.eu/ICE-RGBW as the default 1.8. From the experiment, it comes out closer to 2, but this would require more precise measurements with a different setup.
Brightness
More precise measurements will appear in the second part of the test if they happen, but let's at least measure with the photodiode and compare the RGB(255,255,255) mix of the SK6812 5V vs. "SK6812" 12V:
| SK6812 5V RGB(255,255,255) | "SK6812" 12V RGB(255,255,255) |
 |
 |
The measurement suggests a significantly lower brightness. It seems that the 60 LEDs per meter version is the recommended minimum in this situation. You must keep this in mind, especially if the strip will be positioned quite far from the wall. Also, if you like a juicy and bright ambient lighting, the classic 5V version will be a better choice.
Thermals
Let's use a thermal camera to check how hot both the 5V SK6812 and the 12V 'SK6812' LEDs get when their individual RGBW channels are driven to the maximum.
| SK6812 5V Red | "SK6812" 12V Red | SK6812 5V Green | "SK6812" 12V Green | SK6812 5V Blue | "SK6812" 12V Blue |
 |
 |
 |
 |
 |
 |
| SK6812 5V W | "SK6812" 12V W | SK6812 5V RGB | "SK6812" 12V RGB | SK6812 5V RGBW | "SK6812" 12V RGBW |
 |
 |
 |
 |
 |
 |
Since we've practically established that the SK6812 12V RGB module is a constant-current, we can identify the condition that generates the most heat: running a single R/G/B channel alongside the independent white (W) channel. In practice, you would never actually want to drive it this way, as the white diode is bright enough to completely wash out the color component regardless.
| "SK6812" 12V R+W | "SK6812" 12V G+W | "SK6812" 12V B+W |
 |
 |
 |
There is no hiding it – just as we predicted, they run much hotter than the classic model. And if you use different independent control for the white channel than we recommend, it gets pretty uncomfortable.
I am in no position to declare that these temperatures have zero impact if we stick the LED, for example, to the back of a thin OLED panel — I've been recommending using a TV frame for this purpose instead for years anyway.
PWM
I will measure the PWM at minimum brightness by placing the photodiode directly against the LED. For the medium level, I'll measure from a distance of about 2 cm to avoid sensor saturation, using a small black tube to shield it from ambient light.
| SK6812 5V RGB(1,1,1) | "SK6812" 12V RGB(1,1,1) |
 |
 |
| SK6812 5V W(128) | "SK6812" 12V W(128) |
 |
 |
| SK6812 5V RGB(128,128,128) | "SK6812" 12V RGB(128,128,128) |
 |
 |
Summary
- + phenomenal PWM
- + uses a much more practical 12V, lower voltage drop, allows building longer segments without current injection
- + lower current allows the use of cheaper power supplies, wires and edge connectors will heat up less
- + despite being 12V, they are still individually addressable
- +/- questionable power efficiency
- +/- unusual LED protocol color order
- +/- classic watt limiter algorithms will go crazy with them (use a sufficient power supply instead)
- - preliminary measurements suggest significantly lower maximum RGB brightness
- - the LEDs themselves heat up significantly at high drive levels for selected channels, although predictably under typical white channel control
- - this is a new product on the market, it's hard to judge its long-term durability
- - sold under the guise of the classic SK6812. why? where is the technical documentation?
While I might run more advanced lab tests in the future, I decided to publish these core findings now to give you a better picture if you're building a new setup. I hope this data helps you decide if they are suitable for your setup. I might expand on this topic with deeper measurements later.
Comments
Post a Comment