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?
Recently, I encountered an interesting problem: How do you measure the length of a WS2812 programmable RGB-LED string electronically? That is, just using signals that are already there. This can be useful if you want a LED controller to adapt its pattern according to the string that is connected to it, or simply for diagnostic reasons.
WS2812 strings are usually controlled by using one serial output signal only. The LEDs are daisy chained and you simply push out data for all LEDs without any feedback. If there are fewer LEDs on the string, the data for the last LEDs is ignored.
An intuitive approach to counting the number of LEDs is to feed the output of the last LED of the string back into the microcontroller. According to the WS2812 protocol, the output of LED number n is low until data for n+1 LEDs has been pushed to the string. To count the number of LEDs, data is fed to the string until a rising transition is detected on the output. A relatively easy way to implement this is by using a pin change interrupt on the AVR, or a similar feature on other microcontrollers.
While this works nicely, it has the disadvantage of requiring another wire. Can we do it without introducing any additional connections? Continue reading
I previously reported on reverse engineering a candle flicker LED. My approach was to extract the “flicker” pattern from the input current variation and to deduce the algorithm from statistical analysis.
Reverse engineering the controller chip
Of course there is another, more involved, approach. And that is to reverse engineer the circuit directly from the die. Andrew Zonenberg from Siliconpr0n decapsulated and imaged the controller chip from one of my LEDs. You can find his report here.
He managed to obtain very high-resolution optical microscopy images of the top-level metal. It turns out that the controller chip is manufactured in a relatively coarse CMOS process with one metal layer and 1-2 µm resolution. This is 1980ies technology. But of course, that is all that is needed for a circuit as simple as a flicker-LED.
WS2812 LEDs are amazing devices – they combine a programmable constant current controller chip with a RGB LED in a single package. Each LED has one data input and one data output pin. By connecting the data output pin to the data input pin of the next device, it is possible to daisy chain the LEDs to theoretically arbitrary length.
Unfortunately, the single-line serial protocol is not supported by standard microcontroller periphery. It has to be emulated by re-purposing suitable hardware or by software timed I/O toggling, also known as bit-banging. Bit-banging is the preferred approach on 8 bit microcontrollers. However, this is especially challenging with low clock rates due to the relatively high data rate of the protocol. In addition, there are many different revisions of data sheets with conflicting information about the protocol timing. My contribution to this was the light_ws2812 library V1.0 for AVR and Cortex-M0, which was published a while ago. A V2.0 rewrite of the lib was in order due to various reasons. And, to do it right, I decided to reverse engineer and understand the WS2812 LED protocol to make sure the lib works on all devices.
Let’s reverse-engineer a LED, pedantic mode.
Lately, cheap electronic candles seem to be everywhere. I never paid much attention to them until recently it came to my attention that they actually use a special type of light emitting diode with integrated “candleflicker” controller. Now this is something different – who doesn’t like obscure LEDs? Half an hour later I had managed to score a bag of candleflicker-LEDs from the chinese manufacturer.
Very nice, you can not do that with real candles. But the interesting part is of course: How do they work? Considering that they literally sell for a few cents a piece, there can not be very expensive electronics involved. This raises another question: Are these cheap LEDs really worse than all the self-made microcontroller based LED-candles around the web?