For a project I wanted to make an LED flicker like a candle. I searched for the signal statistics of candle flicker, and I found no data. One student web site suggests that candle flame flicker is a 1/*f*-type random signal with roll-off of 20 dB per decade increase in frequency. Similar processes are typical for turbulence, so this student’s plan seemed reasonable. However, the student did not discuss whether the signal is Gaussian or not, and did not describe the low-frequency characteristics of the signal. 1/*f* noises may have a spectrum that follows the 1/f curve to very low frequencies, but because they would require infinite power at *f*=0 they always have some lower frequency change. I had no data.

Candles aren’t hard to get, and I already had a silicon photodiode for an absorptive smoke density measurement system I’m working on. I also had an analog-to-digital converter (ADC) in an ADS1015 on a breakout board from Adafruit. I made the very simple circuit shown below and attached it to a Raspberry Pi to sample the data. There are a lot more details, but those are later.

The voltage measured by the ADC is directly proportional to the current through the resistor. The current through the reverse-biased diode is directly proportional to the incident optical power. Very simple. I recorded a minute of data at a low 250 Hz sample rate, and subjected the data to analysis. The setup was a nominally dark room with the sensor a few inches from the flame. I flapped my hand at the candle to get it to flicker while recording.

The first graph below is a histogram of sample values.

The histogram is about normally distributed, but the right-hand tail is not Gaussian; it is too fat. In other words the candle is occasionally much brighter than normal. The time series (below) shows the same properties. There are clearly visible large excursions.

For human eyes the candle’s flicker will be well represented if the frequency spectrum of the flicker and the distribution of the flicker approximately match a natural source. The spectrum below can be thought of as an average brightness (the peak at the left), a flat spectral region out to about 4 Hz, and then a 1/*f*-style roll off at 44 dB per decade.

Numerically, we have the recipe for a flickering candle:

- Samples should be normally distributed with a standard deviation equal to 0.25 of the mean.
- The power spectral density of the signal should roll off at about 40 dB per decade with a 3 dB cutoff frequency around six cycles per second.

To make this work on the Arduino using the pulse-width modulated outputs, we can further constrain the problem:

- The maximum value cannot exceed 255 counts—or make the limit that the mean plus two standard deviations is 255.
- From this, we can derive that 2s+m = 255, use the fact that 0.25m=s to find that the mean m=170 and the standard deviation is about 42.
- A sample rate of between 30 and 120 Hz should be more than adequate to satisfy the Nyquist criterion for human vision (see Wikipedia).
- Values may not go below zero or above 255
- A second-order infinite impulse response (IIR) filter has a roll-off of 40 dB per decade

If we can find a numerically efficient way to generate a time-series of Gaussian random variables inside the Arduino, filter them with a 2nd-order fixed-point IIR, scale them (if needed) then we should be able to make a flickering candle.

Unfortunately, I have failed repeatedly to get a stable fixed point IIR filter. The cookbook solution specification above should be easy to implement, but I have not found it so. A better solution will have to wait for another post.

Did you see this? It just came up today.

http://hackaday.com/2013/12/16/reverse-engineering-a-candle-flicker-led/

No, but that is awesome. I suppose I should pull their data and subject it to my analysis, see if they get a similar spectrum. It is interesting that they identified a sample rate of about 14 Hz, considerably lower than I was willing to suggest.

If you’re interested, I put together a program for the ATtiny13A implementing a very loose approximation of the distribution you describe (I took several creative liberties based on what looked nice and I didn’t try to reproduce the rolloff with any particular fidelity). Feel free to use any parts of the code you like, I’ve placed the entire repo in the public domain. Even if you don’t care for the compromises you may find the approximate normal distribution useful – it uses only integer math and no tables, since the MCU i’m using has only 1K program flash and 64 bytes RAM.

I also played a bit with the algorithm linked from Hackaday, but I didn’t really like the version as described. The main issue was that the 14 Hz update was just painful to watch, so I implemented a simple linear fade between “frames”, which I carried over to the new version. I suspect with some tuning a similar scheme could make a decent approximation to the filter you’re seeking.

https://github.com/mokus0/avr-shake/blob/master/examples/flicker/flicker.c