Getting 20% Duty Cycle From a 555 Timer

I want to stress-test some LEDs for the long-stalled bike taillight project with a high current / low duty cycle drive. The usual specs give something like 100 mA at 10% duty cycle in a 100 μs period, but maybe they’ll withstand more abuse than that; I don’t have any specs whatsoever for these LEDs. The usual DC rating is 20 mA, so 100 mA at 20%, say 2 ms in a 10 ms period, should give the same average power as the DC spec. I plan to run them continuously until some failures to pop up or it’s obvious they’re doing just fine.

Although this would be a dandy Arduino project, a classic 555 timer IC makes more sense for something that must run continuously without changing anything. The usual 555 circuit restricts the duty cycle to more than 50% for high-active pulses, a bit over the 20% this task calls for. The simplest workaround is a Schottky diode across the discharge resistor to separate the two current paths: charge uses the upper resistor, discharge the lower, with the diode forward drop thrown in to complicate the calculations.

Rather than putz around with calculation, a few minutes iterating with Linear Technologies’ LTSpice IV produces a reasonable result:

NE555 pulse generator
NE555 pulse generator

In round numbers, a 1 μF timing capacitor, 2.7 kΩ charge resistor, and 13 kΩ discharge resistor do the trick. Given the usual capacitor tolerances, each resistor should include a twiddlepot of about half the nominal value: 1 kΩ and 5 kΩ, respectively.

I’m thinking of repurposing those Wouxun KG-UV3D batteries for this task and found a 7.5 V 3.5 A wall wart in the heap that will be close enough for the test rig. The 555 output should drive a logic-level MOSFET just fine, although even an ordinary FET would probably be OK for the relatively low current required for LED toasting.

11 thoughts on “Getting 20% Duty Cycle From a 555 Timer

  1. Interestingly, I just grabbed a 555 for my latest project. I needed an audio output that changed with frequency (not a precision voltage-to-frequency conversion, just audible feedback). Originally, I used the venerable LM331, which is designed for the purpose, for breadboarding. Worked a treat. But the final version needs to be tiny, and the LM331 isn’t available in a surface mount package. I ended up using a 555 instead, which is a little trickier and less linear, but is easy to find in all sorts of tiny packages (the 5-lead SOT-23 is adorable and would look nice next to the LV321 op-amp, but doesn’t have the needed pins).

    1. a little trickier and less linear

      Ah, but if you surround it with enough other parts, you can make it work perfectly! [grump]

      The 555 will never die; in the day when we figure out how to build starships, they’ll have 555 timers doing something indispensable, probably right next to all the dust-mote x86 CPUs running embedded doodads.

  2. Curbside Classic refers to some cars being the “cockroach of the road”, in that they’ll never be gone. I guess the 555 counts as such in IC-dom.

    Merry Christmas to all!

  3. What advantage do you get running the LEDs at a higher current and lower duty cycle? Reducing the power loss in a current-limiting resistor / linear charge-control system, or something else?

    1. The main advantage happens in dimming, where the apparent brightness varies very linearly with the duty cycle. It doesn’t vary quite so directly with current, which is why linear dimming doesn’t work quite so well.

      PWM also simplifies the drive circuitry, because the LED is either on or off. A cheap MOSFET switch and a resistor, plus a stable power supply, may be all I need for wide-range dimming: no fancy current sensors needed. In real life you would use a dedicated current-mirror driver, but the same principles apply.

      I want to experiment with staggering the on phases of several LED strings, which should give the same illumination with a lower peak battery current than turning them all on at the same time. Batteries seem to prefer pulsed loads, but I’m not convinced that’s a big win and I’d rather reduce the peak current in the wiring. There’s no clean way to do that with a bare Arduino, but a few external shift registers should do the trick…

    2. … and then forgot the main gimmick: dotted lines!

      This will eventually become a bike taillight, where conspicuity counts for almost everything. The 100 Hz blink rate provides excellent flicker fusion in a stationary eyeball, but turns the LEDs into dotted lines during eye movement due to either normal saccades or just scanning the scenery.

      The high-power LEDs in most car taillights run much faster than 100 Hz with a much smaller duty cycle, but I figured this would be a good start with cheap LEDs. If they survive a month of 100 mA @ 20%, I’ll try 200 mA @ 10%…

    1. Now that’s a nice application!

      Digikey seems to be rolling up a bunch of design tools and EE-flavored sites, with the intent of supplying exactly the parts you’re simulating or reading about. Can’t argue with that…

      But I still think many of the failures we see arise directly from believing that the simulation represents reality, that you’ve correctly modeled all the factors, and the real world won’t present any surprises. The more complex and detailed the simulation, the better the results… and the more spectacular the failures!

Comments are closed.