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

It seems like you have it. I'm not sure what your clip plug numbers are though. Going into the USBasp, the only cable I moved was the last one from position 8 to 9. I did all of the mixing and matching on the clip end. So the first wire in the ribbon cable matches up to USBasp 1, then 2 with 2, etc.

The clip plug numbers are for the 8 pin plug at the end of the cable.

I just discovered that the connection from pin 5 on the clip is broken between the tip and the little window at the side of the clip. What a bad quality!

The crimped leads seems to be easy to pull off and rearrange, so I think that I will make a straight connection between the two plugs with a 2x5 pin array and then rearrange the leads on the clip. Pin 9 on USBISP has to be handled separately.

I get exactly the same response from avrdude as you reported on nov.26. The green light (power on) is lid and the red flashes once when sending the command. There are more loose connections in the clip, that pease of sh..

I don't feel like going into micro surgery today, I am more courious of measuring on my newest light, a tiny Black Cat with Osram LED. This is my first Osram and I'm eager to see how it performs, tint-wise.

After a little (very small) soldering, and adding to the command: -P com2 -n (a little program, "USB View" showed me that USBasp was on Port2, the -n is for no writing).

I got this:

But what now ? Tido, can you help? I don't really know what this means. Is it good, or is it very good?

That looks very promising. AVRDude has successfully established a connection to the ATtiny. Now you could try flashing one of the prepared images. Go to the "Programmable" directory and call AVRDude like this:

avrdude -pt13 -c usbasp -P com2 -u -Uflash:w:BLF-VLD.hex:a -Ueeprom:w:BLF-VLD.eep:a -Ulfuse:w:0x79:m -Uhfuse:w:0xef:m

This should result in output like this:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.15s

avrdude: Device signature = 0x1e9007
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: current erase-rewrite cycle count is 18088202 (if being tracked)
avrdude: erasing chip
avrdude: reading input file "BLF-VLD.hex"
avrdude: input file BLF-VLD.hex auto detected as Intel Hex
avrdude: writing flash (1024 bytes):

Writing | ################################################## | 100% 1.88s

avrdude: 1024 bytes of flash written
avrdude: verifying flash memory against BLF-VLD.hex:
avrdude: load data flash data from input file BLF-VLD.hex:
avrdude: input file BLF-VLD.hex auto detected as Intel Hex
avrdude: input file BLF-VLD.hex contains 1024 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.35s

avrdude: verifying ...
avrdude: 1024 bytes of flash verified
avrdude: reading input file "BLF-VLD.eep"
avrdude: input file BLF-VLD.eep auto detected as Intel Hex
avrdude: writing eeprom (64 bytes):

Writing | ################################################## | 100% 0.89s

avrdude: 64 bytes of eeprom written
avrdude: verifying eeprom memory against BLF-VLD.eep:
avrdude: load data eeprom data from input file BLF-VLD.eep:
avrdude: input file BLF-VLD.eep auto detected as Intel Hex
avrdude: input file BLF-VLD.eep contains 64 bytes
avrdude: reading on-chip eeprom data:

Reading | ################################################## | 100% 0.11s

avrdude: verifying ...
avrdude: 64 bytes of eeprom verified
avrdude: reading input file "0x79"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.05s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0x79:
avrdude: load data lfuse data from input file 0x79:
avrdude: input file 0x79 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.05s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xef"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.05s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xef:
avrdude: load data hfuse data from input file 0xef:
avrdude: input file 0xef contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.05s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE

avrdude done. Thank you.

That's it, the driver should now be running the programmable version of the BLF-VLD.

Another screenshot:

Thank's Tido, Will this burn any fuses or can I program the device otherwise afterwards?

In fact I'm more interrested in making a light with fixed modes at my own levels but will try your example first if it is not destructive.

As long as you don't set any lock bits and don't disable serial programming, the chip can be reprogrammed a few thousand times. Just make sure you get the fuses right (that's what '-Ulfuse:w:0x79:m -Uhfuse:w:0xef:m' does).

Done!

So now I have a monster-driver 2.8A (8x7135) with variable setting. Exiting. But what about 1020 bytes instead of 1024 bytes?

I would want to test it without undoing my elaborate soldering work. (must try to repair that clip).

Thank's again, Tido,

I hope that brted also will be successfull.

Nothing to worry about. I just created the example output from a current development version, not the flash image in the published archive.

I got the clip. It's true not the greatest build quality, but it's pretty standard "pomona soic clip 5250" sold at digikey, etc. If any of the pins are short, you can push them out from inside the clip near the hinge.

My problem is that DX won't ship out the drivers. I should probably order some at KD.

Hi All

This is my first post in the forum, and I just want to thank Tido for his work on the flashlight driver.

Using the soic clip listed in this thread and an arduino board as a very cheap avr programmer, I have now reprogrammed my BLF AA-Y4E to have exactly the modes I like.

It has also been great fun to play around with the driver software "inventing" highly unusable modes :-)

Regards

Nicolai

Welcome nkildal. Good to have you here!

It's encouraging to hear people are having some success with this. I'll tinker around with mine some more this weekend and see if I can get it working. Nice that it works with the BLF AA Y4E, Nicolai! I always wonder how many people like you are lurking here, reading the threads, buying stuff, and yet we never know. Glad you've shown yourself.

brted - I found the following things a bit challenging:

1. My clip was of bad quality - some of the pins were pulled back a bit, making it hard to make proper contact with the pins of the chip

2. The right wires need to be connected from the AVR programmer to the connector of the soic clip. Your post with the images and tables helped me do that - thanks brted

3. Using Mac/OSX I had to download and set up a compiler environment (I chose CrossPack-AVR, http://www.obdev.at/products/crosspack/index.html) - this was easy :-)

4. Lastly I had to use the correct avrdude command line to program the chip. Tido and sixty545's comments above in this thread, helped enourmously - thanks guys.

None of the above are real showstoppers - I just had to take it easy and be careful - so good luck when you get to the tinkering :-)

Also a warm welcome from me, Nicolai!

I have an easy question for you, right away:

Does the BLF AA-Y4E have an ATtiny13 or did you put in a new driver?

Hi there

The BLF AA-Y4E uses a driver with an ATtiny13 - so it was very easy to open it up and just reprogram it.

It has very short wires from the driver to the LED, so I had to unsolder wires to get the driver out.

I have sinced replaced the wires with longer ones, so I now only need to loosen the driver board from the pill to program it.

I didn't originally plan to mess with my BLF AA-Y4E, but I had been waiting for too long, for DX to send me some AK-47's to play with :-)

Thanks for giving the BLF-VLD a try, sixty545 and nkildal. I'm very happy that finally someone else can test out my driver. It would be great if you guys could give me some feedback on the mode programming UI. I've got a new version with some new features ready, but I'm reluctant to push out a new release unless I know I won't have to rewrite the whole UI.

nkilda, have you tried using a PWM level of 1/255? I'd really like to know if the boost circuit stabilizes at such low PWM rates and if it's still running efficiently. Could you measure the current drawn from the battery?

Hi Tido

Yes - I have tried 1/255 and it seems very stable and usable (I like an ultra low low).

When using two different 14500 Li-ion cells I measure the following current at the tailcap, but please keep in mind, that my multimeter is a cheap one, so the PWM probably fools it:

DX Trustfire "Blue", sku 19626 @ 4.14V: 0.52A

DX Trustfire "Flame", sku 26124 @ 3.75V: 0.58A

I wanted to take a reading with a NiMH cell, but I just discovered, that the light does not come on at all, with any of my NiMH cells (even fully charged ones)...

I use the BLF-VLD with only 5 modes and no memory ( 255/255 -> 32/255 -> 1/255 -> Strobe -> "Soft Beacon").

Can you think of a possible explanation for the light not turning on with NiMH ?

The same here. I am waiting for 4 pc. of 101-AK from DX ordered nov.6 -shipped nov.25!

So I have now programmed a SKU: S009742 from Kaidomain ordered nov.8 arrived nov.22.

I just don't own an emitter (yet) that runs on 2.8 A. The XM-L plug-in is to expensive for me - I fear it should be caught by the P.O.

(I would really like to test that emitter) .

Actually, I bought that driver to harvest the 7135's for bringing the 101-AK's to do 1.4A, but now I will keep it for the future XM-L

I got my 8-pin clip to work after 1 hour of surgery and will now sacrifice the BLF for a better life, hopefully.