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

Ah - I guess I could have read out the lock bit setting from the BLF AA-Y4E before trying to reprogram it then :-|

Is it correct that an additional "-U lock:r:lock-dump.hex:i" to our dump command would have done this ?

There are some losses due to capacitance of the components and leads and also switching delays by the linear regulators. If you want to have a lower PWM frequency, you could either set the system clock prescaler via the fuses or change the timer/counter prescaler set in the program code. You'd have to recompile the source in both cases (update the F_CPU compiler flag if you change system clock).

I'd recommend changing the timer prescaler. Look for the line "TCCR0B = 0b00000001;" and change it to "TCCR0B = 0x02;", this will slow down the PWM frequency by a factor of 8. I already made this a #define in the current dev version.

Nothing to apologise for, this is exactly the kind of feedback I need to improve the driver.

Two seconds should be plenty of time to switch the light off. Maybe the AK-47 is equipped with very large buffer caps, so the µC won't reset if power is switched off for a few milliseconds. Will it switch modes reliably if you keep the power off for a second during switching? If so, things may improve if you activate the brown-out detection by setting the high fuse to 0xEB.

You're welcome :)

No, if program verification (AKA "dumping the flash memory") has been disabled via the lock bits, there is no way to read it. Unless DebugWire has been enabled before locking the chip, but that would be pretty pointless. It's a security measure the prevent those pesky customers from stealing the manufacturer's oh so valuable imaginary intellectual property ;)

Oh I think I wasn't specific enough in my post: I asked if it was possible to read out the lock bits from the original driver, to check what measures the manufacturer might have taken, to prevent snoops like us from grabbing his precious code :-)

On the other hand - I have no reason to go back to the original driver software, as I find your driver a much better alternative.

My friend has even asked me to just put your driver on his BLF AA-Y4E right away :-)

It's beginning to look a lot like Christmas....

The experiments with my AK-47 driver comes out rather good, I wished for:

100% - 25% - 6.3% - 1.5% but I got approx:

100% - 21% - 1.5% - glow, narrow pulses 5us on lowest, period 140us.

Changing only the low, high fuses from 0x79, 0xEF to 0x6A, 0xEF gave:

100% - 21% - 3% - 0.05%, broader pulses of 18us on lowest, period 480us. (this is near the 2 kHz Tido mentioned).

Changed the levels and ended with:

100% - 27% - 7.5% - 0.25%, Lumens measured to:

200Lm - 54Lm - 15Lm - 0.5Lm Very, very nice light, near the ideal light for me. It uses 20mA on lowest level and 1.06A on highest. The only draw-back is the click-speed. It should react on shorter clicks. How do I change that, Tido? Oh- I see now that we cross-posted..

I tried changing the SELFPRGEN bit in the BLF AA-Y4E light by writing 0xED to the high fuse but it would not change. Anybody know why?


[quote=Tido]

If I do that, the compiler (make) will not run properly, I get this message:

Building file: ../driver.c
Invoking: AVR Compiler
avr-gcc -DBUILD_FIXED -Wall -Os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=attiny13 -DF_CPU=4800000UL -MMD -MP -MF"driver.d" -MT"driver.d" -c -o"driver.o" "../driver.c"

and only one file, driver.d (empty) is made.

I just tried to change to "TCCR0B = 0x02;" - on my machine it builds without problems.

I went into the "Fixed" directory, and used the commands:

make clean
make all 
Building file: ../driver.c
Invoking: AVR Compiler
avr-gcc -DBUILD_FIXED -Wall -Os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=attiny13 -DF_CPU=4800000UL -MMD -MP -MF"driver.d"
 -MT"driver.d" -c -o"driver.o" "../driver.c"

Embarassed [quote=nkildal]

make clean
make all 
Building file: ../driver.c
Invoking: AVR Compiler
avr-gcc -DBUILD_FIXED -Wall -Os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=attiny13 -DF_CPU=4800000UL -MMD -MP -MF"driver.d"
 -MT"driver.d" -c -o"driver.o" "../driver.c"

[/quote]

Very strange, when I do exactly the same, it does'nt work. Only if I change back to 0x01.

Well, more stupid than strange - I was in a hurry and put in TCCR0B = 0b00000002 !!! Embarassed

0xEB was not good, the light never came on. I tried 0xED instead and now it reacts on very fast clicks, but it is still a lottery and I keep ending in the extended mode. How do I exclude that?

I remove #define EXTENDED_MODES I guess.

You can set the following in driver.c (line 48-50):

#undef EXTENDED_MODES      // enable to make all mode lines available
#undef PROGRAMMABLE        // user can re-program the mode slots
#undef PROGHELPER          // indicate programming timing by short flashes

Then go into the "Default" directory and do your build there.

Edit: I think we cross posted :-)

Or you could also choose to change how the "Fixed" version is built, by just editing the lines 188 to 193 to your taste:

#ifdef BUILD_FIXED
#undef PROGRAMMABLE
#undef EXTENDED_MODES
#undef PROGHELPER
#define EXTENDED_MODES
#endif

That's the one I had in mind

What voltage is the battery you are using? With my fuse settings, the µC would trigger a brown-out reset at 2.7V. Adding another 0.6V for the drop across the protective diode, your battery would have to be at or below 3.3V.

To build a driver without the extended modes group, just use the "Simple" configuration.

In this case It was a power supply, set to 4.0 V.

After enabling the prescaler in software and using 0x6A and 0xED for fuses the light is now almost perfect. Even the click response got better than before. The PWM frequency is about 260 Hz and there are no flickering to see. It is a 4 level, Simple model with outputs: 200 - 50 - 12 and 3 Lumen. There are almost proportionality between output and battery current so 1 Lumen costs about 5 mA in this light which is an Ultrafire WF-502B with R5.

Now I plan a bigger modding-event (strobe-killing) when my drivers arrives from DX, eventually.....

I have visions of you racing around the countryside hunting down strobes and killing them. ;)

I am totally on board... what do we use? Shotguns, dynamite or nukes? ;-) Death to all strobes (and low PWMs)... I don't even go in clubs and disco's any more... lol

sixty545, could you write up a small summary on which configurations you used and how well they worked? I'm a bit confused by all the information fragments scattered throughout the thread so far . The report about the light not turning on with the brown-out detection set to 2.7V got me a bit worried.

Has anyone played around with the programmable version of the driver yet? I'd really love to hear some opinions about the UI.

Is this related to Lumens-hunting (poor Mr. Lumen)?

No not yet - I would love to give you some feedback on the programmable version, but my BLF AA-Y4E board suddenly died last night (not related to your driver).

I am now waiting for some DX & KD driver boards to arrive so I can continue experimenting :-)

I went through a fast series of experiments and did'nt write them down in a protocol. I used this thread as a sort of protocol. I will not be able to recall the history of combinations (them old grey cells....) but I can try changing the brown-out bits again the next time I'm gonna program and then check if the light will start-up on the 4V power supply.

I'm trying to understand the button click functioning and timing, there are still too many non-reaction-clicks, I could use some hints here.

I found that the low frequency of PWM I have now, makes the digital lightmeter and the multimeter show varying values - I will try setting the CKDIV8 bit in low fuse back to 1 to have a faster frequency again but keep the divide-by-8 in software, let's see how that turns out.