A Flashlight Story

Back in May of this year, in preparation for a campout, I bought a nice looking LED headband flashlight at Walmart. It's a Garrity light and it ran me about $13. I used it on the campout and fell in love. It was incredibly light-weight and I soon forgot it was on my head, yet it was plenty bright (click these images for larger versions).

After the campout it sat in a drawer for a few days before I had occasion to use it again. When I pulled it out of said drawer and pushed the button to turn it on, nothing happened. Saddened, I figured it must have been bumped and turned on while in the drawer or maybe one of my boys had found it and left it on. I bought new batteries and used it while performing some bicycle maintenance in my dimly lit garage late one night. I put it away high on a shelf away from any bumps or curious hands afterwords. A few days later, the batteries were dead again. I've gotta return this defective thing to Walmart, I thought to myself, but never found the time. Here it is 6 months later, I have not package nor receipt, and I'm afraid I still don't have the desire to venture back into Walmart only to be rejected for my $13 return.

Instead, I decided that there was a remote chance I could fix it myself. Even with my basic EE knowledge and caveman electrical tools (Radio Shack multi-meter) I should be able to figure this out, I figured. It's just a flashlight. The obvious thing would be a short, right? I extracted the light from the headband:

And opened up the back.

Probing the battery connections, I discovered that with the flashlight sitting off there was 77.5 kOhms of resistance between the two pads, not a completely open circuit, right? That's gotta be it. I inserted some new batteries with the multimeter in series and there was no current draw. Hmm. Well, it takes two CR2032 batteries for a voltage of 6V. I don't know what to use for their internal resistance, but even assuming none, V/R give us:

6V / 77500 Ohms = 77.4 microamps.

My meter doesn't exactly go into the microamp range so maybe... Another thing to consider is this isn't a mechanical switch so maybe that's not a straight up resistance I was measuring anyway. I found a datasheet online just for furn and read that these little batteries have a 220 mAh capacity. I believe the calculation for two batteries supplying 77.4 microamps would be (Note the correction: two batteries in series does not double the current. Thanks, Nols):

(.220 * 2 Ah) / .0000774 amps = 5684.75 2842.38 hours

So that could be draining the batteries while the light is off, but it would take more than a couple days. Maybe that's not actually the problem. For fun I measured the current used when the light was on. The numbers weren't as memorable and I wasn't thinking blog entry at that point, so I didn't write them down. I think it was about 60 milliamps on the low setting and 100 milliamps on the high setting. Nothing outrageous.

I decided to take it apart. It was a tight little package with no screws, and no good place to pry. After a few minute of frustration I hit it with a blunt object and out popped this black plastic piece:

Then I pried out the circuit board.

And at this point I'm kind of at the end of my EE rope. I don't see any obvious shorts sucking current out of my batteries (and my multimeter didn't find any either). I see some transistors, resistors, and caps that are likely the constant current driver circuit for the LEDs (maybe similar to this one, even), and then a blob of epoxy covering something else mysterious but probably benign, and that's about it. No fix, but at least I have some really bright LEDs to play with.

If you have any suggestions on how to debug or fix my battery sucking flashlight feel free to chime in down in the comments. If you are from Garrity, I will blog about how amazing it was that you found my blog and how nice you were to send me a new flashlight. :-)

Comments

Victor said…
I've got a light from Petzl for about $40 and it works ok.



No clues to solve your problem, though...
November 26, 2008 at 11:54 PM
Nolan said…
The resistance of an active circuit is very difficult to measure, and probably impossible to do with a handheld DMM. It's still good to look for shorts that way though :)

When DMM's measure resistance, they turn on a very low constant current source and then measure the voltage and then use Ohm's law to figure out the resistance. This will cause the active circuit to behave a lot differently than putting a 6V battery on it. And you may get a much different amount of leakage with the batteries than the DMM. Whether your DMM can measure it or not, that is another story. And even if it is low like around 1mA, that would change your calculations to how fast it will drain... I realize this wasn't much help, but it may point you in the right direction.
December 2, 2008 at 2:33 PM
Post a Comment

Popular posts from this blog

SystemVerilog Fork Disable "Gotchas"

This is a long post with a lot of SystemVerilog code. The purpose of this entry is to hopefully save you from beating your head against the wall trying to figure out some of the subtleties of SystemVerilog processes (basically, threads). Subtleties like these are commonly referred to in the industry as "Gotchas" which makes them sound so playful and fun, but they really aren't either. I encourage you to run these examples with your simulator (if you have access to one) so that a) you can see the results first hand and better internalize what's going on, and b) you can tell me in the comments if this code works fine for you and I'll know I should go complain to my simulator vendor. OK, I'll start with a warm-up that everyone who writes any Verilog or SystemVerilog at all should be aware of, tasks are static by default. If you do this: module top; task do_stuff ( int wait_time); #wait_time $display ( "waited %0d, then did stuff" , wa...
Read more

'git revert' Is Not Equivalent To 'svn revert'

I just learned that if you have some changes in your working tree that you want to get rid of, you don't type 'git revert' like you might guess. No, that's what cvs, subversion, mercurial, and bazaar (to name a few) use revert to mean, but not git. With git, revert is used to undo actual commits. Thankfully, you can undo your revert with another 'git revert', I just learned. So let me repeat to be clear, if you have changes to your working files that you want to abandon, DO NOT do this: git revert HEAD That will undo your last commit. Do this instead: git reset --hard HEAD I'm glad I have that straightened out now. I'm wondering if /etc was really a good place for me to start out playing with git. UPDATE: Nearly two years later and I'm still getting comments on this. I'm glad I've been able to help people out this way. The discussion in the comments is good, and one thing I'd like to point out is that I now always use...
Read more

SystemVerilog Streaming Operator: Knowing Right from Left

SystemVerilog has this cool feature that is very handy for converting one type of collection of bits into another type of collection of bits.  It's the streaming operator.  Or the streaming concatenation operator.  Or maybe it's the concatenation of streaming expressions (it's also called pack/unpack parenthetically).  Whatever you want to call it, it's nice.  If you have an array of bytes and you want to turn it into an int, or an array of ints that you want to turn into an array of bytes, or if you have a class instance that you want to turn into a stream of bits, then streaming is amazing.  What used to require a mess of nested for-loops can now be done with a concise single line of code. As nice as it is, getting the hang of the streaming operator is tough.  The SystemVerilog 1800-2012 LRM isn't totally clear (at least to me) on the details of how they work.  The statement from the LRM that really got me was this, "The stream_operator <...
Read more