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

Not really.

Lumens are for capturing - they even get released outdoors.

Strobes are for hunting down and doing bad things to. Like soldering with a 500 amp welder. That works.

Or cutting up with a chainsaw...

or.......

:)

Yes, every time the light is switched on, the eeprom is written to. Given the 100000 write cycles per cell guaranteed by Atmel, you could click the light a hundred times per day and it would still take almost three years before that number is reached.

That number used to be two or three times lower with the older releases, as the cell used for recognising mode changes was written up to three times whenever the light was turned on. Femto over at http://www.taschenlampen-forum.de/ pointed this out to me and I have since added a wear levelling algorithm to alleviate this problem.

OK, I know about eeproms durability, but that was not really what I ment. For me the code seams to be repeated in loop inside main(), but I can understand that this is not the case - can you clarify for me why it only run once?

NO NEED! I got it!

while(1)
;
* mode funcs do not return, so this is never reached.

Hey, this is great stuff. I'm tempted to get some gear and start playing around. Modes are clearly a bit of a sore point on a lot of budget lights.

Do you guys think that there's any chance that these 13.5mm boost drivers from KD could be programmed? http://kaidomain.com/ProductDetails.aspx?ProductID=11063 unfortunately the pictures arn't detailed enough to really see the chips but the mode controller looks similar.

There is no way of telling from the pictures whether these use an ATtiny or a Pic. Since the Pic is more commonly used in driver PCBs, it is not really likely.

The only commonly available boost driver with an ATtiny I know about, is the NANJG-112A. But sadly that one seems to have been discontinued.

ALARM!

I just got my 4 pc. of sku7612 after 33 days from DX.

They were NOT! 101-AK as I ordered, but AK-47C. I thought that this was OK as I programmed an AK-47 earlier.

BUT THIS ONE HAS A PIC 12F629 PROCESSOR WHICH I CANNOT GET IN CONTACT WITH.

They have the 4 stars as normal for AK-47. The bags they were packed in are marked 2007612.

They were ment for programming the BLF program. I guess I have to make a complaint about this or are we going to do PIC's also?

Anyway the Strobe-killing event is off for a while... (sorry, Don and Vectrex).

Anyone else got one of theese?

That's bad news. PICs are a different platform and need their own hardware for programming. Besides, the instruction set and I/O ports are totally different, so a port would likely end in a complete rewrite.

I got my last delivery from KD a few weeks ago and they where the best batch I ever had (good voltage divider and a low drop Schottky diode for polarity protection). You should try to get your money back from DX and order these instead: http://www.kaidomain.com/ProductDetails.aspx?ProductId=10996

Can anyone guide here:

Do I claim my money back through PayPal right away or the more polite way, write to DX (do they answer at all).

Well, it depends. I used to take the polite way of trying to settle things without resorting to threats. But given the last run-in I had with DX's customer support...

Give them a chance to rectify the situation, but file a dispute as soon as they start haggling. If you get the "We can give you $2 store credit, but that's all we can do" reply, you know what to do ;)

Tido, I programmed the same program into the BLF AA-Y4E as I did to the AK-47 board, but in the AA-Y4E it only starts up in the first level and do not react to tapping. I tried to remove brown-out detection in high fuse but it did'nt help. With brown-out detection the light flashes a few times (fast) at each start-up and is then steady.

Can you think why it does'nt react on taps as the AK-47 board? (I have re-fitted the two components that were removed to make space). I suspect it has something to do with slow rising and falling of the voltage to the ATtiny due to the PAM 2803 (but nkildal's BLF AA-Y4E worked).

It sounds like the buffer cap keeps the µC running for too long when the light is switched off. Are you sure you re-soldered the components correctly? Looking at the last picture nkildal posted, the black parts on the left of the µC look like diodes. The lower one seems to be part of a voltage monitoring circuit, which would help draining the cap. If you soldered it back the wrong way around, the cap would be isolated from the circuit and retain its charge much longer.

The diode was unsoldered in one end only. It comes (with kathode) from pin 2 on tiny13 in parallel with a 100kOhm. Where they end I have not found out yet. Perhaps the tiny13 is active in draining the capacitor?. The upper diode feeds the tiny13 pin 8 from VOut on the PAM2803. The only thing I changed from the original SW was the timing (PWM appr. 1 kHz, ON appr. 15 us in lowest mode). The PWM seems to work fine all the way to the LED's negative end, only the tapping, slow or fast, does not work.

The voltage to tiny13 collapses in about 10msec so it is unlikely that the watchdog should count for 2 sec

I'm afraid that I have destroyed the solder pad under one end of the capacitor near pin 4 on tiny13. If that is the reason for malfunctioning then I apologize, Tido.

Now I have no idea of where that capacitor goes to, I can't see the trace disappearing under the tiny13. nkildal, do you by any chance have an BLF AA-Y4E open so you can help me out?

Edit: I think I have found it - it goes to the end of the diode and 100 kOhm from pin 2 on tiny13 where I found no connection before!

I'm at work right now (probably shouldn't be following the forum then :-) ) but I would be happy to investigate it, as soon as I get home.

I'm happily retired, so I can do what I want, but I know your problem Wink. As I added in my previous post I think I found it but thank's anyway, now let's see what happens:

Nothing!. Re-connecting the condenser did'nt help.

Perhaps I should try the hex-files that nkildal got to work. Can you mail me them, nkildal?. Then I could see if it's a HW or a SW problem.

Yep - I will send them to you, as soon as I get home...

Thank You for the files and the very fascinating soft-beacon function that You invented. One can almost feel the light beam sweeping by...

Your files worked right away, and mine also, after playing around with some editing - I never found out what the problem was.

About the mode shift:

I got an UltraFire WF501B with MC-E today and loved the mode shift, the mode is stored about half a second after turn-off. You don't have to think about starting a 2 sec period before You can switch to next level.

I think this is ideal in a light with only level shifts. If there are other functions, seldom used (Beacon etc.), perhaps it would be better to have no memory and start up in medium, followed by high - low1 - low2 - Beacon or whatever.

I wonder if there is time to write the eeprom during a brownout?. How do we address that?, Tido, agenthex, anyone?

Release v0.3 is ready for download, grab it here. Here is the changelog:

2010-12-09 Tido Klaassen <tido@4gh.eu>

* BLF-VLD: release v0.3

* driver.c: mode functions can now be en/disabled without rearranging
modeline offsets

* driver.c: EEPROM image configurations containing disabled mode
functions will result in compile time error

* driver.c: added support for battery monitoring and handling of low
battery voltage

* driver.c: added wear levelling to mode switching to protect EEPROM

* driver.c: added timer prescaling config option

* driver.c: added mode functions for SOS, alpine distress signal and
fading beacon

* README: added info on how to set up battery monitoring

It would take some modifications to the stock PCBs for this to work.

You could build a "simple" driver without the extended mode group and disable mode memory with the NOMEMORY #define.

This cannot be done with the brown-out detection. The BOD works by stopping the µC once Vcc drops below the configured threshold, and resetting it when the power comes back. The only difference to a normal start-up is a flag set in a status register. Besides, to use the BOD for switching modes, the buffer cap would have to be chosen with the exactly right value, which depends on things like power consumption of the µC and resistance of the battery monitoring circuit. (BTW, I did a calculation some time ago on how long a 100nF buffer cap would keep the µC running. The voltage divider alone would drain it below the µC's minimal operation voltage in about 2ms. I don't think it's possible to use BOD for mode switching on a stock 101-AK.)

The only way to get this working would be to add a really big cap (10-100µF), remove the voltage divider and add a wire from the battery to one input pin, bypassing the protective diode. This way an interrupt could be triggered when the light is switched off (battery voltage is zero, but µC can still run from the buffer cap). If the power comes back before the cap is drained, it was just a short tap. But this would take some fundamental changes to the driver software to get it working.

Hi Tido,

I think You just disencouraged me to dig further into this. But as I know myself I can't let it be.

I thought about using the Brown-out interrupt vector rather than polling the flag BORF. If I could find out how to catch Brown-out interrupt (I don't know much about this special processor) I would turn off the load and count 4 watch dog interrupts (1 sec) and then store the tap_none flag to the EEPROM. I thought that it could be that simple.

I went through my collection of lights with memory and found 7(6) that saves the mode after power-down and only 3(2) that does it after power-up:

Store mode after power-down:

TrustFires: EF23: 1 sec, F20: 0.5 sec, Z1: 1 sec

UltraFires: C3 SS: 10 sec, another C3 SS: 5 sec, 501B MC-E: 2sec

Skyray S-A1: 1 sec

Store mode after power-up:

Tank007 TK-566: 2 sec, TrustFire R5-A3: 2 sec, Romisen RC-C6: <1 sec but always go to next.

Now I should disassemble the first group and spy on the configuration, but the only thought of it......

I am not the only one that like store after power-down (=only one tap for next mode), this is from brted's review of UltraFire 501B-MC:

Pros:

  • Bright
  • Cheap
  • Mode memory works well <<
  • Nice Low