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

Flashlight Modding and DIY Parts
21

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?

22

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

23

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

24

I've contacted one supplier in china, and he's now offering SOIC 8 clips in 1pc quanties for $10 shipped. This comes with the 10pin cable which is perfect for the USBasp's, and it's about half the price of anything else on ebay.

http://cgi.ebay.com/ebaymotors/ws/eBayISAPI.dll?ViewItem&item=400171159037

25

On avr programmers, it looks like the dragon board is probably the cheapest for anything with debugwire. In your opinion, is it worth getting debug capability for playing around with this or other simple projects?

26

So far I didn't need the Dragon's debugging functionality for this project, or, since this is my first µC project, for anything else. The code execution path is simple enough (always ends in an infinite loop somewhere) that it's easy to spot when it goes wrong somewhere. I'm sure I'll soon be using it for some other, more complex project coming along, but for this it would be overkill. One feature I did need was high voltage programming to unbrick the chip after setting the wrong fuses.

So, if you plan to do other things with it than just this project, get the Dragon, it's terrific value for money. Otherwise you'll probably be fine with the USBasp (as long as you always make double-sure the fuse bits are set correctly ).

On another note, I tried out the mode programming sequence you suggested. The first part (start from the mode you want to program, click x times, then select new mode from the extended list) works and is intuitive, but I'm not sure about the part where you store the selected mode by clicking again x times. I still think acknowledging should be done with some sort of timed sequence.

27

Nice find on the clip, agenthex! I might have to give this a try. What do I need to run Tido's software?

28

Fascinating post, Tido! Very well done. Frontpage'd and Sticky'd.

29

What do I need to run Tido's software?

Easiest way is you need that clip to go from the chip in the light to something to propgram it. The cheapest programmer is the USBasp linked above for ~$10. Or the USBTinyISP for about the same, or the Pololu for ~$20. I think I might get the latter (or the AVR Dragon) because it claims to be directly compatible with AVR studio, the official Atmel tool.

The software for this is free. For the toolchain, you get WinAVR (tool/compiller collection) + AVRStudio (gui/ide) for the dev environment. Studio can program the dragon or pololu (supposedly clones an AVRISP), or you use AVRDude that comes with WinAVR to program the two cheaper programmers.

I think the above is correct from my web browsing, but I'm a little behind Tido with zero ucontroller projects under the belt :).

30

but I'm not sure about the part where you store the selected mode by clicking again x times. I still think acknowledging should be done with some sort of timed sequence.

I thought a bit today about this today, and I still think it's possible to make this work as long as there are no technical hurdles. The essential part is down to tuning the timing. For example, when a user is just clicking through real modes, they're likely to at least pay attention to what the level/mode is. That means they're unlikely to stay in every mode for less than 1 sec that many times in a row (human reaction time is like ~1sec). On the other side of that range, you also don't want to require users to click furiously just to get into the programming state. I think a <1/3-1/2 second limit may be too demanding. So setting the ON timer to somewhere in between 0.5 and 1.0 seconds seems best.

Another angle to the above is to find reasonable cases where the user might accidently drop out of programming (the other case of entering into is taken care by the fact they have to click/cycle through the equivalent of all modes twice to get into programming). For example, if there are loads of the same type of levels (like >10 continuous levels), the user might habitually click through all of them quickly to get the highest or whatever. I think this might be mitigated by squeezing from both sides. One is to limit the number of continuous modes; the other is to increase the number of continuous clicks required. A reasonable solution might be to limit the number of selectable continuous modes to 7-8, and increase the number of clicks to 8 (conveniently giving the user 4 normally selectable modes).

Of course it's possible that all the above combined might not work for whatever reason. I thought about what would be an intuitive signal. Requiring the two "changes" in timing like 2short clicks, 2 long, then 2 short seems like difficult acrobatics. 1 change seems reasonable, for example 4short 2long. This kind of requires measuring on time, at least to 2 levels, so I'm not sure how you do that. Maybe set the timer again after first callback? One issue is that the counting can be confusing to users, especially given the way it's implement; it's doubly so if they use fwd clicky vs. reverse clicky. Regardless, I still strongly believe there should be one signal that they learn, and it should be the easiest one that can work. Conceptually I think the right way to picture this is that there's ideally a recessed programming state button on the flashlight, but we're doing this because we only have 1 button to work with and have to find some replacement/alternative for that second button.

Welcome to the world of UI design, where everyone has their opinion and the way to get it right is to keep iterating :).

BTW, do these guys keep the chip at the default 1 mhz, so you're getting like 4khz on the pwm? Surely it's lower?

31

I thought a bit today about this today, and I still think it's possible to make this work as long as there are no technical hurdles. The essential part is down to tuning the timing. For example, when a user is just clicking through real modes, they're likely to at least pay attention to what the level/mode is. That means they're unlikely to stay in every mode for less than 1 sec that many times in a row (human reaction time is like ~1sec). On the other side of that range, you also don't want to require users to click furiously just to get into the programming state. I think a <1/3-1/2 second limit may be too demanding. So setting the ON timer to somewhere in between 0.5 and 1.0 seconds seems best.

Having taps of different length is no problem. The watchdog triggers repeatedly, so we could set it for 250ms and count the ticks in the ISR. To get the kind of tap, we just have to store a marker for "short tap" in eeprom on start up. When the ISR reaches 4 ticks, it overwrites the marker with "long tap" and at 8 ticks it clears it altogether.

The current development version uses 2n (where n is the number of programmable slots) taps to mark a mode slot for programming and go into extended mode selection. There you can cycle through all available modes. Staying in one of those modes for more than two seconds will select it as the new chosen mode. Next time the light is turned on, there is a timed sequence where the new programming can be acknowledged or discarded before the light returns to its normal mode of operation.

This sequence could be quite inconvenient for people who, for example, use a strobe mode from time to time, but don't want to waste a mode slot on it. They could just go to the extended selection, use that mode and abort the programming afterwards. The problem here is that the next time the light is turned on, they have to wait a few seconds before it can be used in the usual manner. By using a tapping sequence like short-short-long-short, this wait could be eliminated. When returning from extended mode, mode switching would immediately work as usual and only if the sequence is used, the slot is reprogrammed. The chances of accidentally hitting this sequence would be quite small, as people tend to switch through the modes at a constant rate. I think I will give this a try.

Welcome to the world of UI design, where everyone has their opinion and the way to get it right is to keep iterating :).

Yes, I know. That's why I kept to things like hardware architecture, low level drivers, automation and networking protocols at uni and stayed well clear of anything needing direct user interaction. It's such a drag to spend hours on something that doesn't really do anything of the interesting stuff ;)

BTW, do these guys keep the chip at the default 1 mhz, so you're getting like 4khz on the pwm? Surely it's lower?

It depends on the batch from which your driver comes. The first I got ran at 1MHz. The second I don't know, as I never managed to read the fuses and the latest batch ran at 9.6MHz. I set mine to 4.8MHz, as this makes ISP programming easy, delivers very high PWM frequency and guarantees reliable MCU operation down to ~2V.

32

Okay, I've got this new programming scheme working and it looks like a winner to me. The extended mode list is hidden in normal use, but can be accessed without too much hassle. At the same time it's nearly impossible to reprogram a mode slot accidentally. It was even very hard to do it on purpose without counting the seconds on a watch, until I added some visual timing aid when leaving the extended mode selection.

I think I'll clean up the code a bit and release it as v0.2. I hope you guys will get your programming hardware soon, so we can discuss the further development based on real experience instead of all the theoretical musings.

33

I went ahead and bought the clip and programmer today. Should arrive in a couple of weeks and then we'll see what happens. I already have an extra AK47 driver to test. Once we get this running it will be good to put together a complete tutorial on how to do it, software and hardware needed, etc.

34

I'm a week ahead of you, ha ha

and ordered 4x101-AK too.

exciting...

35

Good! I'm going to need some help.

36

Version 0.2 of the BLF-VLD is ready for download here. There have been some substantial changes, especially for the programmable version of the driver. Light levels are not freely programmable anymore, but can be selected from a predefined set of nine logarithmically spaced levels and a few strobe modes. The programming procedure has been simplified a lot, thanks to agenthex's suggestions.

The driver can also be built in two non-programmable versions. The first gives access only to a subset of modes defined at compile time. The second version also has a fixed subset of modes in the standard mode group, but can access all modes defined in the extended group by switching modes x times in a row (configurable at compile time). This way a flashlight may have just three or four default light levels, but special modes like moonlight mode or strobes are still accessible without getting in the way on everyday use.

37

Thank's for the new SW, Tido.

I expect my programming equipment at my door in about one week.

I have calculated a little (or more) around the actual output from the emitters taking into account the degrading of output with temperature. There is quite a loss at full power.
I presume using a NANJG 101-AK with 1050mA for XR-E, 1400 mA for XP-G and 2800 mA for XM-L and that the LEDS reach about 125 degree C at full power. If DC was used instead of PWM one woud have to degrade also from the fall in efficacy with current.
That gives the following result if you want a doubling of light for each step:

XP-E Q5 at max 1046 mA:
Flux(LM) mA output code
191 1046 255
96 446 109
48 210 51
24 103 25
12 51 12,4
6 25.2 6.1
3 12.6 3.1
1.5 6.3 1.5
XP-G R5 at max 1395 mA:
Flux(LM) mA output code
341 1395 255
171 606 111
85 288 53
43 141 26
21.3 70 12.7
10.7 34.6 6.3
5.3 17.2 3.2
2.7 8.6 1.6
XM-L T6 at max 2790 mA:
Flux(LM) mA output code
629 2790 255
315 1127 103
157 527 48
79 256 23.4
39 126 11.5
19.7 63 5,7
9.8 31 2.9
4.9 16 1.4

Ofcourse you have to round the output code.

(corrected to PWM).

38

In "pwm" the current is pulsed at max with the given % duty cycle so it's close to a completely linear relationship. The cree graphs are for a steady current, not any waveform with given average current density.

39

I agree. In PWM the output versus current curve can not be used, only the point for the drive current, which leaves the degradation due to temperature. I will have to re-calculate for PWM. But linear it is certainly not.

I have now corrected the numbers in the former mail.

40

How are you assuming the junction temperature?