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

863 posts / 0 new
Last post
Tido
Offline
Last seen: 3 years 2 months ago
Joined: 05/28/2010 - 15:28
Posts: 189
Location: Berlin, Germany

nkildal wrote:

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

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

 

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 Wink

nkildal
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

Tido wrote:

nkildal wrote:

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

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

 

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 Wink

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 Smile

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 Smile

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

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?


sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

Tido]</P> <P>[quote wrote:

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.

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.  

nkildal
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

sixty545 wrote:

Tido wrote:

Quote:

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.

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"
sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

Embarassed

nkildal wrote:
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"

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

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

Tido wrote:

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.

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.

nkildal
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

sixty545 wrote:

Tido wrote:

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.

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?

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 Smile

nkildal
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

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
sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

nkildal wrote:

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 Laughing

Tido
Offline
Last seen: 3 years 2 months ago
Joined: 05/28/2010 - 15:28
Posts: 189
Location: Berlin, Germany

sixty545 wrote:

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?

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.

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

Tido wrote:

 

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

Don
Don's picture
Offline
Last seen: 11 months 20 hours ago
Joined: 01/12/2010 - 16:32
Posts: 6617
Location: Scotland

sixty545 wrote:

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

 

The numbers from my light tests are always to be found here.

https://spreadsheets.google.com/ccc?key=0ApkFM37n_QnRdDU5MDNzOURjYllmZHI...

Vectrex
Vectrex's picture
Offline
Last seen: 8 months 1 week ago
Joined: 05/01/2010 - 15:39
Posts: 2778
Location: Gemany (according to my Black Cat)

Don wrote:

sixty545 wrote:

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

 

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

Tido
Offline
Last seen: 3 years 2 months ago
Joined: 05/28/2010 - 15:28
Posts: 189
Location: Berlin, Germany

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

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

Don wrote:

sixty545 wrote:

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

Laughing

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

nkildal
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

Tido wrote:

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

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 Smile

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

Tido wrote:

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 Embarassed . The report about the light not turning on with the brown-out detection set to 2.7V got me a bit worried.

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.

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

Tido wrote:

The report about the light not turning on with the brown-out detection set to 2.7V got me a bit worried.

Don't worry more, Tido. I tried the high fuse 0xEB again and this time it started fine. I must have had a broken power lead the first time Embarassed.

I found out that a PWM period of about 1 msec is a good compromise between problems with narrow pulses (giving less than expected light) and problems with digital measuring instruments showing non-steady readout. I used 4.8MHz oscillator, clock divider = 8 (CKDIV8 = 0 ) and Timer Divider TCCR0B=1 (as in the original SW). Thus the low fuse is 0x69 and high fuse 0xEB.

Tido
Offline
Last seen: 3 years 2 months ago
Joined: 05/28/2010 - 15:28
Posts: 189
Location: Berlin, Germany

sixty545 wrote:

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.

The algorithm is quite simple. On start-up the program checks if the last time the light was on, it was on for more than two seconds (let's assume this is true for now). It then stores a marker in eeprom, saying that this time it was turned off after less than two seconds. Then it starts a timer and goes on setting up the light. This marker is removed after two seconds have elapsed.

Now let's assume that the light has been switched off before the marker has been removed. When the light is switched on again, the program finds the marker in eeprom and knows that it is supposed to change the mode.

 

So, you can only change the mode within two seconds after turning on the light and the power has to be off long enough to cause a shut-down or reset of the µC. If you want to change the mode after more than two seconds run time, you first have to tap once to start the two second timing and then again to actually change the mode.

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

Tido wrote:

If you want to change the mode after more than two seconds run time, you first have to tap once to start the two second timing and then again to actually change the mode.

Thank's, I think that really explains what happens.

Looking in the program I found this, are there writings to the eeprom all the time the light is on or am I missing something:

    // write back state to eeprom but omit the mode configuration.
    // Minimises risk of corruption. Everything else will right itself
    // eventually, but modes will stay broken until reprogrammed.
    eeprom_write_block(&state, 0, sizeof(State_t) - sizeof(state.mode_arr));
    eeprom_busy_wait();

That would eventually destroy cells in the eeprom.

Don
Don's picture
Offline
Last seen: 11 months 20 hours ago
Joined: 01/12/2010 - 16:32
Posts: 6617
Location: Scotland

sixty545 wrote:

Don wrote:

sixty545 wrote:

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

Laughing

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

 

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

 

Smile

 

The numbers from my light tests are always to be found here.

https://spreadsheets.google.com/ccc?key=0ApkFM37n_QnRdDU5MDNzOURjYllmZHI...

Tido
Offline
Last seen: 3 years 2 months ago
Joined: 05/28/2010 - 15:28
Posts: 189
Location: Berlin, Germany

sixty545 wrote:

Looking in the program I found this, are there writings to the eeprom all the time the light is on or am I missing something:

That would eventually destroy cells in the eeprom.

 

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.

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

Tido wrote:

sixty545 wrote:

Looking in the program I found this, are there writings to the eeprom all the time the light is on or am I missing something:

That would eventually destroy cells in the eeprom.

 

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.

Michael_qrt
Offline
Last seen: 7 years 6 months ago
Joined: 11/09/2010 - 20:09
Posts: 12
Location: Australia

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.

Tido
Offline
Last seen: 3 years 2 months ago
Joined: 05/28/2010 - 15:28
Posts: 189
Location: Berlin, Germany

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.

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

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?

Tido
Offline
Last seen: 3 years 2 months ago
Joined: 05/28/2010 - 15:28
Posts: 189
Location: Berlin, Germany

sixty545 wrote:

I guess I have to make a complaint about this or are we going to do PIC's also?

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

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

Tido wrote:

sixty545 wrote:

I guess I have to make a complaint about this.

You should try to get your money back from DX

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

 

Tido
Offline
Last seen: 3 years 2 months ago
Joined: 05/28/2010 - 15:28
Posts: 189
Location: Berlin, Germany

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 Wink

Pages