How To Build a Flashlight With Perfect Modes (picture heavy)

Flashlight Modding and DIY Parts
1

So, you want a flashlight with modes that are just right but can't find the one, no matter how hard you look? You are especially craving for a light that can be programmed with light levels ranging from hardly visible to full blast can't-see-anything-but-dark-spots-for-a-few-minutes when accidentally shone into your eyes? Onna stick In a P60-style host? Well, today's your lucky day.

Building It

First, you will need to organize a few parts. From left to right, the NANJG 101-AK pimped with a fourth AMC7135 (other µC-controlled driver PCBs might also work), an XP-G R5 and a P60-style reflector with brass pill from KD.

Next, you sit down and write your own driver for the micro controller on the PCB. If you are lazy and have a PCB run by the ATtiny13, you might get the brand spanking new Budget Light Forum Versatile LED Driver and skip this step.

Now you flash the µC with your program...

...and assemble your flashlight.

Et voilà!

Testing It

Now let's take this baby for a test drive. First, highest output, picture taken with ISO 100, f/3.5, 1/25 sec.:

Nice!

Next up, lowest mode, same camera settings:

Is this thing even turned on? Let's take a look:

Well, maybe we need a longer exposure time. 30s should be plenty, right?

Hmmm well, let's just say it's really low.

Conclusion

Okay, I'll admit it, I'm just plugging the new open source driver for ATtiny13-controlled driver PCBs I just released. Since I got the idea for this project while reading BLF, I named it the Budget Light Forum Versatile LED Driver. I hope it can live up to its name. Some technical Notes: It can be built in two ways, either as programmable, like the Akoray K-106, giving you up to ten user programmable constant light modes (no strobes, SOS etc.). If built as fixed, up to ten modes can be defined at compile time, including all the fancy blinking stuff. And yes, it does a really low low mode. During testing it took my eyes almost a minute to adapt enough to the darkness just to find the spot on a white wall less than two meters away. If you think you might have a use for this, fetch your copy here and tell me what you think. All constructive criticism is welcome.

Edit: Updated links to the current version. Links to older versions: v0.1 v0.2 v0.3


2

That is some seriously sexy stuff!

Now I just have to learn how to flash µC's ^_^

3

So you can re-program the ATMEL chip while it is still in place? How much for the board? I guess it's USB? Seems like you could make some money selling custom drivers. People love the K-106 just for the programmable modes, so if you can program that in there (with ramping and everything?) then you've really got something.

Have you got it where it can have mode memory?

. . . . Later on a Wiki was started to help get people started on this:

http://flashlight-wiki.com/AVR_Drivers

4

Very impressive! Where do you find a "flasher" like the one you use? And which drivers can we use?

5

Yes, it’s in system programmable (ISP). As long as the security fuses aren’t set, it can be reprogrammed this way.

The programmer is an AVR Dragon with the Dragon Rider extension board on top of it. This combo can be bought for around $90, but it is a system designed for development and education. Simple ISP programmers cost less than $20.

Unless you’re living in Germany, where it takes insane amounts of paperwork to sell anything in a commercial manner :wink:

Yes, modes can be user-programmed like the K-106 (at least the way I think it is done there, I don’t own one). Whether the driver provides mode memory or starts up in the first mode slot can be determined at compile time by setting or unsetting a #define in the source code.

6

You can find ISP-capable flashers for AVRs for a few bucks on ebay (search for AVR and ISP), but it takes a bit of knowledge to set up the necessary tool chain. Don’t expect to just plug the thing into an USB port and press a button. Also, if you don’t want to solder leads to the chip’s pins, you’ll need a debugging clip like the one I use. One of those will cost twice as much ($18 shipped from Hong Kong) as the cheapest programmer you can find :wink:
In theory this driver should work with any ATtiny13-based board that uses the µC solely for regulating the light output via PWM. I’ve developed and tested it on the NANJG 101-AK. Another likely candidate is the AK-47, but I don’t have one here to test it.

7

Hey Tido. I see that you used a bunch of conditional #def's to get the right functionality (to the point of changing function headers). Is this done for any inherent reason or just a preferred embedded programming style? Seems like the way you split functionality to Programmable vs Standard, it's almost better to to have two programs/mains (if memory is an issue) that #include any standard functionality.

Also, have you tried or considered using the brownout detection for mode mem? I actually like the way you do memory better because it makes sense to me, but I think memory in many of the chinese lights set when you have the light off for a certain period, and I'm not really sure how they pull that off with just the brownout detection (ie discriminate between a short brownout and long one, do they use a cap to keep controller on but "browned out" or something?).

Thanks a bunch for doing this and releasing the code.

8

Well, I answered one of my own questions. I looked at the hex files and you're pretty close to the 1k limit. Seems programmable + other modes is out unless you get clever, like define the blinking modes as a short set of parameters and incorporate them into the same pwm set function.

9

Things aren't set in stone, this is an alpha release, probably even more of a demonstration of what can be done. I'm not really happy about the programmable/fixed situation, but it was the only way to cram all the functionality into the tiny program flash without writing separate drivers.

Right now I'm not sure if I really want to keep the programmable light levels. After all, it's very hard to see a difference between, let's say, 75% and 80%. What is so attractive about the programmable light is probably not the fine grained control over light levels, but the ability to arrange the modes in a preferred order. Maybe it would be better to offer a number of fixed modes spaced at reasonable levels (e.g. 1%, 5%, 15%, 30%, 50%, 75%, 100%, strobe, beacon, whatever), from which three can be chosen in any order and stored into the mode slots (and the others could still be made available through a special click sequence). I'd be happy to hear some opinions on this.

Edit: Mode switching through brown-out detection is not planned so far. This would depend on the specs of external components (namely, the buffer cap) and right now I'm trying to keep this dependent only on the micro controller used.

10

Awesome!

I downloaded from here and managed to make an identical hexfile to yours in the folder Fixed Modes, so something must be right. Can this one be used to flash it into an AK47?

I would like to make a driver with a logarithmic scale of levels such as:

12,5% - 25% - 50% - 100% or one with:

11% - 33% - 100%

Thanks, Tido

11

The programmer looks usable and at $11.50 delivered you're not taking much of a risk anyway. I don't know if the AK-47 is locked down, so you'll just have to try.

As for the modes, you might want to start lower. I used a PWM value of 16/255 for MODE_LOW, which is about 6% of maximum, and for me it is on the upper end of what I would want as a low mode. Of course the AK-47 uses only 3x 7135, so output would be about 25% lower than on the 101-AK. Just experiment and play around with the values a bit, that's what open source is for :)

12

Erleuchtete Grüße Tido,

I have already seen some of your posts on messerforum.net and geocaching.de, cool stuff you are doing with your µC-programmer.

Keep on going, maybe we can find a flashlight manufacturer to implement one of those programmable drivers of yours into a custom BLF light.

MrLite comes to mind, since they offer a reprogramming service for almost all their lights.

13

Mode switching through brown-out detection is not planned so far. This would depend on the specs of external components (namely, the buffer cap) and right now I'm trying to keep this dependent only on the micro controller used.

Do you know at least how they do it? According to a brief glance through this http://www.atmel.com/dyn/resources/prod_documents/doc1051.pdf, it seems the brownout reset would be triggered regardless. So I presume the program counter (part of general registers?) is retained through the brownout so they can discriminate by the entry point after power is resumed?

Also, where did you get the right clip? I think I have a wider/larger one somewhere but it might not fit on that circuit/pitch. I haven't done any real electronics stuff in a while.

As for picking modes, a big list of fine pwm ratios (you can stack them more densely in the eeprom, or just calcuate them) in programming mode that you can pick up to 3 from (using a n-click UI you already have) would be really nice. For example, I can envision doing the 6click to get to programming mode, clicking through the many modes, and 3clicking to pick out up to 3 modes consequtively. Since you write to a mode slot in eeprom and increment every time, it's safe to stop halfway through to re-pick just the first mode so it's not tedious. You can even stack on SOS modes in the programming phrase but that would still spill over 1k unless it was optimized a bit more.

14

My bad. I just found the doc folder with the readme, which kind of helps. :) You've already implemented the multiple slots. It wasn't clear just looking at the code.

I think the UI to do the programming is a bit tedious. Even what I described above is unnecessary. The programming can be done based on what mode/slot the user was already in.

For example, I'm in a mode/slot, and I'd like it to do something else. I 6click or whatever to go into programming, move through the modes to one that I like, 6click to leave programming, and that last level/mode I was in should be what I choose. Might need to be a tad clever (need x-click to be multiple of # of modes or something) to discern what mode I was in originally, but this UI would be simple and easy to remember.

15

I have a spare AK-47 here... it looks like this... received 2 or 3 weeks ago from DX... do you think it would be programmable Tido?

ATMEL 1022

TINY13A

Δ SSU

16

I think the programming UI needs to be a bit complex to prevent accidental re-programming. If you can re-program by just clicking away, you will end up with garbled modes more often than you'd like. Especially with the time-switched-on kind of mode switching, where it doesn't matter for how long the light has been switched off. It's easy to end up in programming mode by repeatedly using the light for less than two seconds, let's say for finding the key hole every day. I think the light should behave completely different the moment it enters programming mode and changing anything must require some sort of timed action by the user. If he just keeps clicking or does nothing, programming has to be aborted. This may make programming a bit tedious, but how often are you going to re-program the modes?

As for the brown-out switching, from the programming point of view, the only difference between a normal and a brown-out reset is the set BORF-flag in the MCUSR register. You can check at start-up whether the flag is set and act accordingly.

I got the programming clip from ebay, but the vendor I got it from isn't offering them any more. Search for "SOIC8 clip", there are a few available from other vendors.

17

Vectrex,

there's an ATtiny13 on the board and it's connected to the 7135s via PB1, so it should work with my program. The only question is whether the chip is still programmable. The only way to find out is to try it.

18

Sorry I don't have the code in front of me, but can you use a mechanism to time the consequetive clicks? Like 6 clicks within 3 sec or something, which doesn't seem like typical user behavior. I personally think it's bad idea to require a manual for programming a flashlight. My experience is that people tend to avoid complex UIs.

Where did you get your nanjg? dx or kd? I just bought from dx.

Also, can you check if maybe a SOIC 16 clip would fit, clearing the other components?

19

Very, very cool.

I can only speak for myself here but that is exactly what I want. I really don't need a gazillion different modes (which hasn't stopped me from buying lights that have about a million and one modes, but I digress) and even though I appreciate the ability to have absolute control, I don't really need that either. I know people who won't dare play with their (programmable) K-106s for fear of losing their moonlight/really darn low mode after they managed to get it just the way they wanted it. Having a bunch of reasonably spaced defaults would probably go a long way to improve usability.

20

3 seconds in "absolute" time (on and off)? No, I can only record the time the light has been switched on.

DX. Although they seem to sell board of different specs over time. One I bought over a year ago and used for several tests and projects is flashable. From the two I bought a few months ago, only one can be flashed and even that took a lot of tries initially. The other one won't even be recognized by the programmer. The two from the latest batch I received a few days ago gave me no problems at all.

I don't think a SOIC-16 clip will work. I tried moving the SOIC-8 clip two pins to the left and right and it won't clear the chips on either side.