LEDs Turn The Heat Up On Flameless Pumpkin Lights


When tea lights just won’t do, why not move up to a 5 channel LED candle simulator?

Halloween is fast approaching. Peter’s local hackerspace, The Rabbit Hole had a meeting to carve pumpkins and talk Halloween hacks. After seeing how poorly a tea light illuminated a medium size pumpkin, this hack was born. We’ve seen LED jack-o’-lantern hacks before, but this one was worth a second look.

In true hackerspace style, [Peter] used what was available to him. A PIC12F508 is the heart of the project. The 12X508/9 series has been around for at many years, and is still a great chip to work with. We remember using the ‘C’ version of this chip to bypass region locks on original PlayStation systems. [Peter] created a simple circuit with two basic modes. In “value mode” the 508 drives LED’s directly from its I/O pins. This limits the total output to 60mA. In “premium mode”, some 2N3904 NPN transistors are brought in to handle the current.  This allows the PIC to drive up to 5 LEDs.

Candles can be tricky to simulate with LEDs. [Peter] used 5 independent 16 bit linear feedback shift registers to generate pseudo random bit streams. The effect is quite impressive. A “wind simulation” completes the illusion of a real flame.

One pin of the micro is used to switch between value and premium mode. One mod we’d love to see is taking back that I/O pin and hooking it up to a wind sensor – possibly a microphone, or airflow sensor. Use the sensor to trigger wind mode for an even more realistic candle simulation.

19 thoughts on “LEDs Turn The Heat Up On Flameless Pumpkin Lights

  1. Though about adding a sound / motion sensor to trigger the wind effect but was time bound (we need to have our raw card orders in by tomorrow to get them back in time for the pumpkin carving on the 25th) so scaled back the features… Also slightly IO bound 5 IOs drive the leds and the remaining IO is used to select the output level (active high or active low). But could split the firmware into 2 loads and use that input as the sound / motion input. Other than that had about 25% of the flash left and 3 byte of ram (yea the LFSRs and timers chewed up most of it) so should be doable from the code side.

    1. I’m curious why you used 5 LFSRs (one for each LED) since they’ll have the same period if they’re the same bit-size. I would have saved the ram and gone with a single 32-bit (should be faster than computing multiple 16 bit LFSRs) and sampled that for every single LED each round. That could easily free up the ram for doing something like adding some kind of motion sensor (pretty easy to rig up a 12V security sensor that just trips a relay/fet).

      1. when I was coding it up I actually did it as 5 PWM channels where each channel take the lower x bits (think I ended up with 6 bit dimming) for the level and x bits from the high order of the previous led channel for the dwell time. Was trying to simulate how a candle will sort of level out at a given brightness for a bit then flicker to something else. Once I got one channel looking good just duplicated to all the rest. May have been better off with one big LFSR but was on a time table and was late by the time I got this version wrapped up. Code space and ram are not the limitations for the motion sensor just IOs. But If I drop the option to choose the output levels could easily add in a case where wind enables when the IO changes state. (in fact I could free up a few bytes if I did not have to randomly generate when the wind starts and how long it lasts.)

          1. Yea I saw the different seeds, that’s why i asked :). Makes sense then as to why you’d do it that way. For future versions then you might want to consider combing this with a TPIC6C595 or something like that. Not much more than the 5 transistors (finding the registers for $1.00 each). That’d free up the MCU to have far more inputs, but I’m not entirely sure what they’d go for other than the motion sensor, so maybe just freeing up that one pin would be useful. It would let you handle up to 8 leds though, which ought to let you do say a campfire better.

          2. @simcop Was trying to keep the total cost down on the low end model and had to work with what I had on hand. (Literately got handed this request late Friday night as I was walking out the door and had to have a working prototype the next day. Made it with a few hours to spare :) If I had to do it over again my first change would be to move to a newer PIC. Forgot how difficult timings can be when you have no interrupts available. Lucked out and this part had a timer with prescaler but that was about it. Guess I have gotten spoiled in my later years remember when micros with integrated EEPROM / flash came out. Man that was the best thing ever no more waiting 15 – 30 minutes for the UV eraser to do it’s thing and having to count cycles and replace chips else beat your head against a part who’s eprom was just worn out.

          3. I’d definitely say I’m spoiled in that regard. I grew up in the era of $200 basic stamps and such that were (as i understand) a little on the atrocious side to work with, if you wanted to get started there as a hobby. The recent “revolution” in cheap easy to program microcontrollers has made my desires feasible (that and not being a kid and actually having a job). I’d definitely want a timer of some kind for doing a candle simulation.

            For something whipped together so quickly, I’d say it looks awesome. The result of the wind effect makes it look fairly convincing, that’s where I’d bet the real work went into this, figuring out what would be a convincing flicker.

  2. I did this once upon a time using 12F629’s. But I just had the outputs and four resistors acting as crude DAC and then a very long repeating loop that would turn the outputs on and of to make it seem random. It actually worked very well and I still have the “candles” I made in some of those foam pumpkins you can buy and carve yourself. I put them out on my steps every year. The hard part about actual randomness is that it is random! Which means “off” some some of the time, and “off” for a long time, so your candles may appear to “go out” and then suddenly relight themselves, or just get stuck on “full on” for a while. So effort has to be made to make it behave like a real flame. I found that loop was just way easier to control without all of the other issues of a software RNG or all of the extra parts needed for a “true” noise generator.

    1. Yep saw exactly what you described in my testing as well. I am using a PWM based dimming (think I ended up with a ~61Hz rate) The way I worked around it was two fold. 1.) Multiple LEDs running independent LFSR seeds. That way while one is in long off the rest are more than likely on at some state. 2.) Minimum and maximum level masks. For “non wind” conditions I allowed from full brightness to moderately dim and for “wind” I did a medium brightness to off. That seem to be the most realistic to me while only using a single LED.

  3. I wonder if anybody did an actual brightness plot of a real candle, because I get the impression most people make such things from just eyeballing candles in their daily life.but there could be some sort of subtle pattern in a plot that would make it even more realistic, and simpler to emulate even – maybe.

    1. Yea started in assembly on PICs over a decade and a half ago and never felt the need to move to C/C++ for them. With such a short list of commands (23 I think) it’s almost easier to do these in assembly. Also I don’t have to worry about the optimization doing something funky to my code:)

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.