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

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

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.

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.

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.

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.

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.

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

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 :)

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.

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.

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.

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

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.

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.

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?

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.

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.

No, I can only record the time the light has been switched on.

Currently, you have the watchdog timer set to 2 sec and clearing clicks after this. As a practical matter, maybe using 1 sec for this and mode mem is a workable trade off?

If more than one timer is possible, or something to similar effect, you can also set a shorter timer to count the number of consecutive short ON periods (decrement clicks if longer) as a reasonable approximation of fast clicking. I can't think of non-pathological use cases that would violate this, especially with reverse clickies. I suppose in the worst case this also works if we're willing to give up mode memory.

I don't mind buying a cheapo USBasp like the one above, but buying another $20 clip seems a bit excessive for just this one project (especially too many what-if's with drivers from dx). How many of the pins are active for programming? Would it be possible to just use a few generic probe/hook type clips?

Sure, it would be possible to record, for example, that the light was turned on 1, 2 or 5 seconds the last time. But if we started making distinctions, we'd end up with something like "turn light off within a short period of time to do A, and to do B, turn it off within another, but different, period of time". That would be very confusing.

The problem is that the same action is used for different things. Turning on for a short time (let's call this a 'tap' for now) means either changing modes or, if done repeatedly, going into programming mode. Maybe a single tap shouldn't immediately start changing modes, but instead be used for shifting functions? Let's say, a single tap does nothing. Two taps get you into mode shift, where you can cycle through the programmed modes, four taps let you cycle through all available modes and six taps get you into mode programming. The main problem with this approach is that people unfamiliar with this UI will be very confused.

ISP programming uses four control/data leads plus power and ground. If you're willing to temporarily dedicate a driver PCB to development (and have a steady hand), you could just solder leads to the pins and terminate them in ATMEL's standard 2x5 ISP plug. This way you could simply plug it into the USBasp. Or if you just want to play around with the program logic, you could use something like this:

(ignore the upper half of the board, that's a loftover from a different project). I'm using a normal DIP ATtiny13 for developing the program logic and only use the driver PCB for testing with real light levels. Keeps the risk of being blinded by accidental mode changes to a minimum

The problem is that the same action is used for different things.

What I meant was short-click detection just makes the entry point to the programming state less ambiguous (which you described as a problem). A "short-click" is just a practical timed cut-off for each click before the code resets the count var, not anything to be measured time-wise. I don't mean to change the general paradigms discussed.

So, IOW what I proposed is still:

1. select mode you want to re-program

2. signal 6 shortclicks to enter programming

3. click through mode options just like any other mode light and stop on the one you want

4. signal 6 shortclicks to set and exit

Same as before, but you won't enter 2 as easily by accident which I agree is possible with the existing way count is done. The problem with the above might be that 4 needs to be disambiguated from possibly clicking through the modes quickly in 3. Should this be a problem, perhaps replace "6 shortclicks" with some other sequence (short-long-short?), but make it the same sequence so the user has to remember just one special signal to program the light.

To summarize, I think this minimizes the principles the user has to remember. It's basically down to:

2 states, general use state, and programming state

1 signal to enter or exit programming state

click to move to next light mode.

That's all they have to know, more or less.

The main challenge is a signal that is unambiguous, not impossible to tap out, and allows us to know which mode they were in before they started signaling.

If anything above doesn't make sense, please feel free to PM me and we chat over IM or something.

---

So I suppose step-through debugging works well with your tools? I can't imagine trying to write that program without it, especially with printf's in morse. :)