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.
Yay, another mini-project with the ATtiny10!
A while ago I devised a scheme to drive an electronic dice with only two IO lines. I finally found the time and motivation to build up a small design using this as an entry for the hackaday 1k compo. Please find project details on the hackaday.io page or the github repository.
The ATtiny102 and ATtiny104 are Atmels newest addition to the AVR ATtiny family. They are a bit different to most of the other devices in that family, since they are based on the AVRTINY CPU core, which was so far only used in the ATtiny4/5/9/10/20/40. I have previously done several projects on the ATtiny10, so I was naturally excited to see another addition to this family. Both new devices are clearly targeted at the lower end, with only 1kb of flash.
Two interesting new features compared to the ATtiny10 are self-programming capability and an integrated UART. Naturally, this asks for a serial bootloader. Since no bootloader is available for this device I set out to work to work on one.
The current state can be found at the Github repository linked below.
Gloun Github repository
Right now it is able to upload and execute user programs on ATtiny104 and ATtiny85, but it is far from being optimized. I stopped working in Gluon for various reasons, but may be picking it up again at some point.
During the last months, a new WS2812 alternative appeared on the market: The SK6812. I finally managed to get my hands on some of them to take a closer look. In most aspects these devices are basically clones of the WS2812. What is interesting however, is that the manufacturer came up with a couple of new variations of the stock 5050 RGB LED.
As with many components from mainland china, it seems very difficult to identify the actual manufacturer of these devices, as vendors tend to rebrand data sheets. It appears that at least one of the original manufacturers is Opsco Optoelectronics. However, it is likely that there is more than one manufacturer is using the SK6812 brand, which does possibly only refer to the controller chip itself. The “SK” prefix, on the other hand, is normally used by Shenzhen Sikewei Electronics, which seems to specialize on speech ICs and similar low-cost applications. Are they connected? No idea…
Two years ago, I spent some time analyzing the algorithm used in a candle flicker LED as commonly found in cheap artificial candles. I reverse engineered the algorithm from the flickering pattern and recreated the algorithm in software. Turns out this is of interest for many people who are searching for artificial candle algorithms – there is a surge of traffic every year around December. However, I just reverse engineered one of the controller ICs – this does not mean that this is a good approximation of a real candle.
But how to get there? First, we need to understand how a real candle behaves. In a recent comment, Gary made the excellent suggestion to record a real candle on video and analyze the data. I noticed something similar could be done in a very quick-and-dirty way, by connecting a photodiode to a digital storage oscilloscope.
I recently bought a very low cost electronic dice kit on an impulse. Assembling it was good retro-fun for a while. The circuit design is was purely 70ies style: A CD4017, a NE555 and a couple of transistors. Of course, this got me thinking: How would it be done today in a most efficient way? Of course this means using a microcontroller, and, of course this means using as few resources as possible. Will an ATiny10 with 3 I/Os pins do?
A couple of weeks ago I reported about a new type of RGB-LED with integrated controller, the APA102. One of the interesting new features of this device is a two-wire SPI interface instead of the proprietary one-wire protocol of the more common WS2812. Many microcontrollers have hardware SPI functions, which allow easy control of these LEDs, as opposed to timing critical bit banging. But it turned out this was not the end of the story. As pointed out by Bernd in a comment, there is some discrepancy between the datasheet and the actual behavior of the devices when it comes to the “end frame”. Reason enough to subject the APA102 to more scrutiny.
The diagram below summarizes the APA102 protocol as found in the data sheet.