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

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.

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.

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.

I'm a week ahead of you, ha ha

and ordered 4x101-AK too.

exciting...

Good! I'm going to need some help.

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.

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

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.

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.

How are you assuming the junction temperature?

The assumption is that at full power the junction reach 125 degr.C. That of course depends heavily on the construction of the light. Perhaps 125 is a little too high looking at Don's measurements from turn-on until 2 min. (this looks more like 90-80% as for 100-120 deg.C)

The Cree curves output vs. current give the output at full current before degradation from temperature.

Using the Cree curves for nominal output vs. temperature I find the derate values at 1/4 - 1/2 - 3/4 - full power (AVG. current) corresponding to 50 deg, 75 deg, 100 deg and 125 deg C.
Then I use curve fitting to find the formula for nominal output vs. avg. current.
To find Lumens from this you just have to multiply with the actual bin's nominal Lumen output.

Now I just have to get my programmer board and clip and 101-AK to try it out.
Ebay and DX, come on!
Can't wait...

My drivers are stuck in pending at DX. Dammit.

But...Kinect computer drivers are out (no obfuscation over usb, it seems), so that's something very very cool to play with. $150 for probably the most advanced piece of equipment you can have in your house.

I just received three 101-AKs and a NANJG-106 from KD (took only 13 days from ordering to get to my doorstep!) and all of them are flashable.

Let us know if the NANJG 106 is really 2.8A as it should be. Also I know you will be flashing them, but it would be good to know how the modes are spaced by default and whether they can be changed by soldering to the stars. That could be a really great driver for P7's, MC'E's, and XM-L LED's.

I can't test if it really delivers 2.8A because I don't have any LED capable of handling such a current. It does have 8x AMC7135 in parallel, so it should be a able to regulate at 2.8A. I'll test the modes once I removed the 4 "spare" 7135.

I'm not convinced this will make a good MCE/P7/XM-L driver, as it can only be used with a single Li-Ion cell. There are also no buffer caps for the 7135, which are needed according to the datasheet.

Yes, it will run out of regulation rather fast and act as direct drive, only less effective due to the AMC's own voltage drop.

Hm, I think they may be only needed when used with a switching power supply?

I just did a quick test and the stars work just like they do on the AK-47. You get exactly the same mode groups.

One version of the datasheet states that a 0.1µF ~ 1µF buffer cap should be added to the output pin if the LED is not mounted on the same PCB. It's probably true that this will only have an effect if the supply current is not steady, but with PWM we're having a switching frequency of up to 20kHz.

I'm just a software guy, so when the datasheet strongly recommends adding this caps, I try sticking to it. Do we have an EE around here who could comment on this?

That is so awesome! Thanks for checking, Tido!

The capacitor is used to limit oscillations that can occour when switching large currents through inductive paths like a long wire. The oscillations produces voltages that could be destructive for the components and/or violates EMC regulations. EMC = Electro-Magnetic Compatibility. This concerns noise disturbance of other electronic equipment. A driver without the capacitor could make a "dirty" light.