Trying to understand a simple flashlight circuit

I wanted to see if I could get a little insight on how these mode switching flashlight circuits work. The ones I'm referring to are typically powered by a single lithium ion cell and control a 1W to 10W LED. They come in different variations, some a little more complex than others, but they usually aren't much more than a micro controller, a mosfet, a diode, and some resistors and capacitors.

I probed one of the more simple ones and tried to draw a schematic. The components shown as a dashed line were unpopulated. I believe everything is accurately laid out except for the PWM pin(s). Pin 3 of the micro controller drives the mosfet, but I'm also seeing the same 176Hz square wave on pin 2 even though it doesn't appear to be connected to anything.

What I'm most interested in is how this circuit switches modes (Hi-Med-Lo-Strobe-SOS). When the light is on, quickly switching it off and then back on again changes to the next mode. My theory is that the diode not only protects against reverse polarity, but it also allows the capacitor to only discharge back into Vcc of the micro when power is cut off. The capacitor is relatively large (1206 package), which indicated to me that it could have a high capacitance if the voltage rating is only 6.3 or 4 volts. It could be as much as 100uF. I was thinking that this would allow the micro to remain powered up while it reads the change in voltage on one of its other pins. The problem is, all the other pins appear to be floating.

I'm completely new to micro controllers, so I apologize if this is a dumb question, but is it possible that the Vcc pin itself is sensing the drop in voltage?

To follow up a little bit, I connected channel one of the oscilloscope to the Vcc pin and channel 2 to the main switch. When power is cut off, it looks like there's roughly 45 milliseconds before the voltage at Vcc drops below 1.8V. I think that disproves my little theory since the micro controller will often change modes after a full second has passed.

Well that's about all I got. If you can help shed a little light, I'd really appreciate it. At some point once I get the hang of things, I'd like to duplicate this circuit with an ATTINY45 and stick it in a modded flashlight.

Hi Mike,

Good on you for taking the time to build a schematic from the components :slight_smile:

Mike_S:
What I'm most interested in is how this circuit switches modes (Hi-Med-Lo-Strobe-SOS).

Most microcontrollers have built-in timers which is what they would be doing to generate the SOS sequence. If it didn't have timers, you can also generate the sequence using delays.

Mike_S:
I'm completely new to micro controllers, so I apologize if this is a dumb question, but is it possible that the Vcc pin itself is sensing the drop in voltage?

Some microcontrollers can sense a drop in voltage in which they power themselves down to prevent any issues that can occur, but in this case as I mention above it wouldn't be the case.

The diode and 20K resistor I suspect are acting as a very cheap regulator for the microcontroller along with the capacitor to keep things stable when the LED turns on. The PWM is used so they can vary the intensity of the LED.

Mike_S:
To follow up a little bit, I connected channel one of the oscilloscope to the Vcc pin and channel 2 to the main switch. When power is cut off, it looks like there's roughly 45 milliseconds before the voltage at Vcc drops below 1.8V.

That would be the effect of the capacitor.

Mike_S:
Well that's about all I got. If you can help shed a little light, I'd really appreciate it. At some point once I get the hang of things, I'd like to duplicate this circuit with an ATTINY45 and stick it in a modded flashlight.

It should be relatively easy, you can use a timer or delays to switch on the mosfet they like are doing. You can try this out on the Arduino too before trying it on the ATtiny45.

Good luck,
Alex

electricteardown:
The diode and 20K resistor I suspect are acting as a very cheap regulator for the microcontroller along with the capacitor to keep things stable when the LED turns on. The PWM is used so they can vary the intensity of the LED.

I would agree. D1 would drop about .5 to .7v, and the rest would drop across the resistor R3. So, if your battery is a 3.2V battery, you would get 2.5V going to the micro.

The missing R1 was probably there to trim the actual voltage, but left out because precision trimmed resistors are much more expensive than normal values, and the micro works within a certain range of voltages anyway, so it didn't need to be exact.

Populating R2, I am not certain about. The only affect I could see would be to split the current?

The missing components (C2 and R6) appear to be a low-pass filter which would convert the PWM to an actual voltage. But that is redundant (in practial purpose) with the mosfet. Perhaps it was there for a lower cost way to do it, but it wasn't reliable enough?

It would appear that all the magic is in the code in that micro.

I realize that your most important question of course is how it senses mode changes between power off... My guess is the brown-out detection. This works by setting a flag when the voltage drops below a certain point. However, the fact that the micro will typically run even at a lower voltage than the brown-out threshhold (and it doesn't cause a reset, it just sets a flag) you can watch that flag to know when to switch modes. The cap likely keeps it running long enough to not completely shut off between button presses.

BOD detection is usually used to signal your controller that power is becoming unstable and it should finish anything sensitive being done (like writing to an EEPROM or flash.) It typically cuts off the write enable so no further writes can be done (but a current write in progress will finish within the EEPROM or flash itself.)

And then there are also other oddball tricks such as powering the micro through a pin other than VCC (yes, this is possible and is done more often than you might think especially in cheap chinese circuits.) So, it could be running the supply voltage through an analog compare pin or a normal analog pin. As the cap discharges, the voltage at that pin would drop and either trip the comparator or the code watching the analog value would trip at some threshhold.

In either case, since the power was only removed temporarily, the code would just keep running and could detect these events. It is likely the brownout detection. The only reason to do it the other way is if there is no brown-out detection on that micro.

BTW, this would also explain the need for the R1 to really fine-tune that BOD threshhold vs. minimum supply voltage.

Thank you both for taking the time to answer my questions and explain the circuit to me. I didn't even consider the diode/cap/resistor arrangement as a voltage regulator, but now it's more clear.

So I'm going to have look more into this brown out detection and flagging. Obviously my understanding of micro controllers is very basic and the idea that I had in mind was to build a similar circuit with the diode and high value capacitor on Vcc, but then use a separate pin to read the state of the switch. Does that sound feasible? When the switch is suddenly turned off, use digitalRead or analogRead to watch for the change in voltage. Then tell the PWM pin to change its duty cycle when power comes back on?

It doesn't need to have a memory feature like many of these mode switching circuits tend to have. If it always started with "low" when you turn it on, and then cycled through medium and high as you clicked the switch, that would be perfectly fine. Eventually, once I learn more I would incorporate the memory feature.

Actually, I spoke incorrectly. In the AVR, the BOD does generate a reset. So in the case of the AVR, it would not function as I described. One would have to set the current state to EEPROM, then upon a reset, check that state. Though, you would eventually wear out the eeprom this way.

The way you are planning would work better for the AVR. As a suggestion, use the analog comparator (AIN0 and AIN1) to monitor your voltage which will generate an interrupt when the voltage drops. Otherwise, you have to keep polling the analog pins and hope you catch the drop fast enough before the cap discharges to the point of resetting the AVR.

Excellent :slight_smile:

Thanks, Retroplayer. I'm getting excited about building this.

Today I put together a little test circuit with the Attiny 85 (8MHz, internal oscillator, BOD disabled), and uploaded a sketch so that it would output a 50% duty cycle on digital pin 4. The circuit was laid out basically how it would be in its final state. I included the schottky diode, cap, 1 watt LED, a couple of resistors and a logic level mosfet. The only thing missing was the switch monitoring pin since I haven't tried to write that part of the sketch yet.

The Attiny seems to draw about 4.5 to 6.2 mA with an input voltage between 3.1 and 3.8V (~0.4V drop from diode included). With a 470uF capacitor and a battery voltage of 3.5V, the Attiny stays active for at least 250 milliseconds when the main switch is turned off. That's probably just barely enough time for someone to switch the flashlight off and then back on again. That window extends to almost half a second when the battery is fully charged. Unfortunately, I might have to go with an expensive tantalum cap to keep the footprint as small as possible.

Based on my parametric search, the ATTiny43U is probably the best processor for this. It operates .7v and 5.5v, and is one of the picopower processors (very low current)

The only real drawbacks are that it has only 256 bytes of RAM , so you may have to write assembly (your code is so simple, I don't think you would have trouble with that), and it doesn't come in a DIP package (but does come in a SOIC package.)

Also, as a tip, the slower your clock frequency, the less power the AVR will consume. And make use of the sleep() function as much as possible.

All in all, the Arduino core is not ideal for this application, really. You might use it for development, but for a final application, I would look at writing assembly code.

Ah I didn't read the part about the switching modes of the LED.

I agree with Retroplayer about using interrupts and going to sleep whenever you aren't toggling the LED. Also sometimes if you enable pull-ups on the pins you don't use (so they aren't floating) this can reduce power consumption too.

  1. Flashlight powers on, micro checks current mode setting
  2. Micro increments the mode setting in eeprom
  3. Micro waits ~5 seconds
  4. Micro sets the mode setting back to current setting in eeprom

In other words, if the user turns off the flashlight before five seconds have elapsed then the next mode setting will be sitting in the eeprom, and if they don't then it rewrites the eeprom back to the current mode setting.

It is kinda excessive on the eeprom writing/rewriting, but you're only storing 1 byte anyway. You could also set a counter in the next two bytes of the eeprom to record how many times the mode byte has been written, and if over "X" many writes then you could jump to the next three bytes. But I can't imagine a flashlight being turned on/off more than a few thousand times in its lifetime.

Retroplayer:
Based on my parametric search, the ATTiny43U is probably the best processor for this. It operates .7v and 5.5v, and is one of the picopower processors (very low current)

The only real drawbacks are that it has only 256 bytes of RAM , so you may have to write assembly (your code is so simple, I don't think you would have trouble with that), and it doesn't come in a DIP package (but does come in a SOIC package.)

Also, as a tip, the slower your clock frequency, the less power the AVR will consume. And make use of the sleep() function as much as possible.

All in all, the Arduino core is not ideal for this application, really. You might use it for development, but for a final application, I would look at writing assembly code.

Wow, Vin down to 0.7V. That could work with a single AA light. I'll definitely keep that one in mind. The large footprint could be a problem, though.

I didn't have time to play with it much today, but I took your advice and switched it to the 1MHz internal oscillator for a quick test. I just wanted to make sure that the PWM frequency stayed at roughly 490Hz with the slower clock. It did, and the current consumption dropped to 1 to 1.32 mA, which is great. Thanks for the suggestion.

electricteardown:
Ah I didn't read the part about the switching modes of the LED.

I agree with Retroplayer about using interrupts and going to sleep whenever you aren't toggling the LED. Also sometimes if you enable pull-ups on the pins you don't use (so they aren't floating) this can reduce power consumption too.

Thanks, I'll definitely look into the sleep function and pull up's. We might be on track to getting a cap that's well under 100uF.

Chagrin:

  1. Flashlight powers on, micro checks current mode setting
  2. Micro increments the mode setting in eeprom
  3. Micro waits ~5 seconds
  4. Micro sets the mode setting back to current setting in eeprom

In other words, if the user turns off the flashlight before five seconds have elapsed then the next mode setting will be sitting in the eeprom, and if they don't then it rewrites the eeprom back to the current mode setting.

It is kinda excessive on the eeprom writing/rewriting, but you're only storing 1 byte anyway. You could also set a counter in the next two bytes of the eeprom to record how many times the mode byte has been written, and if over "X" many writes then you could jump to the next three bytes. But I can't imagine a flashlight being turned on/off more than a few thousand times in its lifetime.

Thanks for explaining the memory. That's an important part that I want to add later on. I wasn't aware that the EEPROM could be worn out over time.

RESET does not normally affect RAM contents. And memory contents does not decay quite as fast as a BOD-reset will occur. I would guess that after poweron, the code checks for a particular pattern in memory. If it's (still) there, it assumes that the power was only off
"briefly", and steps to the next mode. Otherwise it assumes that it's the first time on (in a while) and sets up the pattern in memory, and goes to the first mode.

This is essentially "free" in hardware costs, assuming you have enough room in the code.

Mike_S:
Thanks for explaining the memory. That's an important part that I want to add later on. I wasn't aware that the EEPROM could be worn out over time.

Atmel quotes it at 100,000 write cycles but I've read of tests that passed a million so you can take it as a conservative number.