Reverse Engineering a Real Candle 172 points by liyanage on Jan 6, 2016 | hide | past | web | favorite | 37 comments

 The part about the harmonic oscillation frequency in the flame flicker is most interesting:"The frequency of these oscillations seems to be around 5 Hz, drifting up, and seems to be a fundamental parameter of the flame since it appears to be relatively constant in all observations."It appears that some (optical) flame detectors work by obtaining the frequency of this flicker: [1]"This flame scanner also monitors the rate of combustion by analysing the flicker frequency, or the fingerprint, of the flame... Since the flame is always burning back to the fuel source, the flame is always in motion. This motion allows the intensity of the flame to vary across a flame flicker frequency spectrum."From that link, it appears that the "flicker frequency" would be related to the exact fuel source and possible fuel/air mixture ratio, as the "flame is always burning back to the fuel source".Some other information about flame frequency-flicker: [2]"Under normal gravity conditions, the flames have a well defined oscillation frequency which is inversely proportional to the square root of the burner diameter, D, and to a good approximation can be written as f » 1.5/D½, with D given in meters."So, it would indeed seem that the flicker frequency is related to the particulars of the candle, its wick, etc.Very interesting article!
 This reminds me of the quote "How much can the ripples tell us about the object that fell in the water?"
 Or even the famous question "Can you hear the shape of a drum?", to which we have a constructive proof (under some mathematical idealizations) that the answer is " No".
 That's been simplified enough to distort the question. Real listeners are not limited to simple observation of frequencies they can move there ears around to get a more 3d picture.
 *their
 That's why I keep telling people there's no such thing as a perfect lie. People have no idea just how much information leak there is in every action they make; the only question is whether someone is dedicated enough to find the right side channel. And doing that is only getting cheaper thanks to progress of technology.
 This is awesome! Finally empirical evidence to back up what I've felt all along -- that those fake LED candles don't look anything like a real candle and are actually kind of distracting.That animation at the end really sums it up nicely.
 I wonder if it would be possible to use this data to create an LED candle with a super-sensitive microphone that would realistically flicker when "disturbed", otherwise be a mostly consistent brightness.Or are there better sensors than microphones to detect air disturbances?
 hot wire aenometers can detect even tiny air movements
 But they're bloody expensive and quite fragile. The cheapest unknown-brand ones I've seen on Chinese websites is ~ \$100.
 Oh come on. Some fine thermocouple wire wrapped around a literal hot wire would be enough, no need to use industrial grade scientific equipment.
 That wouldn't give you anywhere near the resolution of an actual hot wire anemometer. I'm fairly confident your instrument would be limited to measuring "is the wind below or above 60 mph?", and would be unable to resolve changes happening in less than ~ 10 seconds.Real hot wires have a diameter of ~ 1/100 of a millimeter, that's the only way to achieve any useful level of sensitivity.
 Ultrasonic emitter and detector could possibly detect a doppler shift.
 A pressure sensor maybe?
 Looking at the rapidly flickering LED image I imagined an engineer showing the data to his manager, "well, a real candle looks like this: kind of sedate and boring." Followed by the manager insisting that it gets a little livelier, saying something like, "if people can't see it flickering they'll thing it's broken. Make it very obvious that it flickers. I don't care if it looks real. I care that people can tell it's flickering"
 Great breakdown. The animation at the end is more convincing than any fake candle I've seen. I'll make sure to use your model if I ever need to simulate flame lighting in a game.Nitpicking, but I think this is technically data modeling and not reverse engineering.
 I wonder how you could apply something like this to transition animations. The simulated flicker ended up looking much better than the LED flicker.Sometimes I see animations in UI. Some look completely natural, and some are horribly jarring. I know there are all sorts of curves that tweening uses to time its path. I wonder if reversed engineered curves would look better.
 It's almost always the case of using linear interpolation(which is what every UX-naive developer reaches for) instead of proper ease-in + ease-out which more appropriately models physical movement.Even very subtle changes in the tangents of the curves can have drastic effects and it's frustrating to see some platforms limit them to a few preset curves.
 Sometimes you don't have bezier curves. I found a formulation of ease-in-out that gives developers no excuses. ;)
 Good idea, but that exp() function makes my inner perf-nerd twitch a bit.I'm personally a fan of pre-generating a fixed set of points that are linearly interpolated and scaled. It has a few advantages:-Extremely cache friendly, can even be cheaper than computing a spline on a lot of platforms since it's essentially just a look up table.-Your curve doesn't need to fit any specific formula(I.E. you can have a step function as part of it if you want).-You can pull data from design applications to generate the curve allowing non-developers to have control over look-and-feel if you want to get that fancy.
 Don't forget, when you use these transitions, that computation is a very small fraction of the animation as it's run once by the CPU. You can think of it as setting a uniform on a shader.The other reason I like using analytic functions is because: 1) You can easily generate a linearly interpolated point set if you want, I've done it for CSS in stylus (for spring animations that can't be represented by a single bezier). 2) With the right formulation, it's very easy to tweak the shape as it is in this case 3) You can analyze the functions easily
 FWIW, the initial loss of brightness is almost certainly due to a reduction in temperature a the fuel/air mixing piont. Blowing on a fire actually increases the oxygen available.
 Very interesting take on the subject. Of course, I think to simulate a real candle, one would have to have some way of measuring air current. If I see a fake candle flickering, and feel no air current, I'm going to be less likely to think it's a real candle.An LED candle the responds to its environment, could be "blown out" for instance would make a great little hack project.
 This is cool. Is the candle-flicker gif based on the algorithm, or the actual output from the LED? Because I assume the LED will smooth out some features. Vice versa, the LED probably needs to be driven with different data to produce the equivalent brightness variation.
 LEDs are extremely fast. The LED itself will add no perceptible smoothing. You could easily add a capacitor for low-pass filtering, but that would add cost so it's unlikely to be done.
 I love how LEDs can flicker extremely quickly. Back in the early 90s when I was working on HIPPI[1] network hardware, our crossbar switch had a 7-segment LED display on each port that indicated the current destination. These LEDs were actually updated synchronously. which worked surprisingly well as a debug tool. You could send to multiple ports and see the port numbers blended on top of each other in proportion to each ports data rate.Years later, it seems blinkenlights[2] went out of fashion and everybody started quantizing blink rates to 1s or 0.5s max. /sigh/ it's throwing out useful information for no good reason.
 I think quantized blink rates showed up around the time someone discovered that rx/tx leds as usually implemented on dialup modems of the time leaked data including passwords to anyone who could see the front panel.
 They're fast until you start trying to use them to transmit data at a few tens of megabits/s.Laser diodes, on the other hand, are fast
 What does this have to do with anything?
 It's a different perspective, I've spent a significant amount of time working with LEDs in a context where the rise time is important, and the fact that LEDs are slow (in this context) provided a significant challenge.I guess the phrase "LEDs are extremely fast" struck me the same way a pedestrian telling you "walking is the fastest way to get around" when you're stopped at a red light in a Lamborghini would
 "Extremely fast" doesn't have any absolute definition. We were talking about human visual perception, so "fast" in this context could reasonably mean "fast enough to have no visible smoothing". A typical LED is much faster than that, so in the context of fake candles I think "extremely fast" is fair. In the context of data transmission it would mean something else.
 Yeah I understand it's entirely relative. I made that comment based on my immediate reaction. Compared to an incandescent bulb, LEDs are like the Lamborghini in my analogy
 The article[0] linked as an example of constrained random walk has a video that's creepy and pretty unsettling. It's interesting how sprinkling some randomness on things we're used to can make our brains go weird on us.
 I've had breadboards like his react to air flow. Those cheap ones especially have such horrible connections that the slightest motion of flimsy part like a resistor or LED wagging in the breeze will cause a significant change in impedance where the leads meet the contacts.Since this signal is dependent upon the series resistance, the output could vary as a result.
 Reminds me of: http://tomgerhardt.com/fireLight/
 I can imagine feeding in the output of the photoresistor into char-rnn and sample from that to "randomize" the light intensity.
 I would buy an artificial candle that flickers when it detects air

Search: