TK40 memory mode

[McAllan]

Hi

Hope others can help put a little light on this one :candle:

I've got a TK40 and of course it needed to be recharged. For the fun of it I tried the following:

1. Leaving it in high mode then removed the batteries for charging.
2. Charged the first 4 which took about 1 ½ hour.
3. Put in the first 4 batteries and turned it on - it came on in high mode.
4. Put the TK40 in low mode and removed the batteries waiting for the last 4 to be ready too.
5. Put in all 8 batteries and turned it on - it came on in low mode.

I really wonders about this :thinking:
Has it remembered the mode because of a capacitor and a very low power RAM memory chip (yes they exists) or has it saved the mode in EEPROM?
From a technical point of view I really don't like lights which constantly saves mode in EEPROM as it is worn with each write And considering there's always power on the main circuitry just saving it in RAM (which is not worn) should be obvious and quite adequate from my technical correctness point of view.

 

[Moonshadow]

Probably uses flash memory rather than an EEPROM - so I don't think it's any more likely to wear out than a USB stick !

 

[AnAppleSnail]

I suspect the life cycle will turn out to be comparable to the (ridiculously long) 50,000 to 80,000 hours of use at maximum rated current of the LED.

 

[McAllan]

Thanks for replies.

Yeah. Guess it's no problem in reality it's just my inner technical nerd comes out. But IMHO it seems like a design flaw when it could have been done otherwise - even without changing anything other than a bit of firmware code. Guess saving it in RAM would even be easier to implement...(!)

The TK40 is a bit special compared to other lights as the UI is a little different. Just wondering if it was really necessary to save the mode in Flash/EEPROM since there's always power on. Seems like overkill.
Normally I don't like memory since one can easily forget which mode it comes on in and then one have to cycle through modes to get the wanted one. On other lights I just turn it on and half-presses a number of times to quickly get to the desired mode - if the high one first and I want the low one then I just turn it on with the reflector covered with my hand in order not to blind myself.

 

[Moonshadow]

I don't think it's that unusual for lights to store the settings in flash memory, and for those who do want programmability or mode memory it would be very annoying to have a light forget the settings while you were changing the battery.

Fair enough if you don't like memory, but there's a world of difference between a feature that you don't like and a design flaw.

 

[FlashlightKid]

I believe the EEPROM is only written to when the mode is changed, holding down switch to change mode.

Please correct me if there is a hole in my logic, and I am no electronic engineer.

I just thought that it works this way because if it saved the mode when the light is switched off then setting it to high from medium and removing the batteries without first turning it off would cause it to turn back on in medium not high.

Thus if you normally use the light on the same level you do not use up that many EEPROM write cycles.

Again please correct me if I'm wrong, its just me 2 cents

 

[was.lost.but.now.found]

I think it all depends on how the developers wrote it. The software could have been written to save upon mode change or it could have been written to save upon turn off. There is an easy way to test it; turn it on, change modes, unscrew it to break power/contact, re-establish contact and turn on. What mode is it in? Did it still remember the new mode? I'll try tonight if I haven't heard anything before then.

 

[McAllan]

Yes I too believe it only saves to EEPROM when mode is changed. Not when turning on and off. That would be the most logical but one can never know however.
Can try and do the little experiment tonight.

That said I have seen drivers which almost constantly wrote information to EEPROM/flash. Had a LED Lenser V6 PowerChip copy (although w. Cree Q5) originally direct drive but I decided to mod it with a multimode driver and ordered one. Couldn't one with buck/boost in the voltage range so settled on one with AMC7135 which of course is only regulated on fresh (charged) batteries but it lengthens battery and LED life. The way that driver worked was that if power was taken from it within the first two seconds or so - no matter for how long - it changed to next mode. If light has been powered on for more than two seconds and you wanted the next mode you'd have to do two halfpresses instead of the usual 1. Only way it could work like that is to write to EEPROM when powered on and again after two seconds. Technically and UI wise a very solution. Ended up giving the light to my cousin as she was very jealous seeing my light collection and all she knew about was dim and boring incans - "of course" she didn't get the more expensive ones but output from it was just as impressive. Guess I'll hear for it the day it stops working and I have to put in a new driver if not just bypassing the µC and making it a 1 mode 7135 driver or could be lucky it fails with signal to the 7135's on so it essentially is just high.
Much better with a TrustFire F22. That one seems to work like all other lights using half presses - so it only needs to write mode to EEPROM when actually changed too (again what actually happens I really don't know).

 

[Locoboy5150]

There is an easy way to test it; turn it on, change modes, unscrew it to break power/contact, re-establish contact and turn on. What mode is it in? Did it still remember the new mode?

With my TK40, I've left the batteries completely disconnected from the light over a weekend via my home made lockout piece of plastic inside (to stop the parasitic drain) and it turns back on in the exact same mode that I left it in every single time.

 

[HKJ]

Only way it could work like that is to write to EEPROM when powered on and again after two seconds. Technically and UI wise a very solution. Ended up giving the light to my cousin as she was very jealous seeing my light collection and all she knew about was dim and boring incans - "of course" she didn't get the more expensive ones but output from it was just as impressive. Guess I'll hear for it the day it stops working

I am not sure you are correct about the two writes, the way the processor detects the short off period, is because it still has power (from a capacitor).

Today's processors can typical handle 1 million writes to the eeprom, this is 100 writes each day for 27 years. I do not think you have to worry about the eeprom wearing out. A smart programmer could also add code to use the next cell in the eeprom, when the first wears out, and with 64 or more cells this approx could extend the life of the eeprom even further.

 

[McAllan]

I am not sure you are correct about the two writes, the way the processor detects the short off period, is because it still has power (from a capacitor).

No. Read again what I wrote
I said no matter for how long the power has been off if power was taking from it within the first two seconds of being powered on it would then change to the next mode. Power it on and off withing two seconds. Leave it a week even with batteries out and it'll come on in the next mode. Power it on for more than two seconds and no matter how long power has been gone it'll come on in the exact same mode. Therefore if being powered on for more than two seconds and you wanted to change to the next mode you'd have to make two half presses. If skipping two modes after the first two seconds you'd have to do three in a row.

I'm very much aware of a small capacitor is enough to let the µC write to ram that voltage is dropping and holding values in memory till the power comes up again (within a second or so in most designs). I have several lights that work that way. Perhaps not the most sexy UI but it works perfectly (for me at least) and no "guessing" what mode it'll turn on in.

Today's processors can typical handle 1 million writes to the eeprom, this is 100 writes each day for 27 years. I do not think you have to worry about the eeprom wearing out. A smart programmer could also add code to use the next cell in the eeprom, when the first wears out, and with 64 or more cells this approx could extend the life of the eeprom even further.

Yes it could. But we don't know how they designed it. An yes the best are probably able to handle 1 million writes but the average quality does only 100.000 if using the typical ones from MicroChip like 12F629. The Atmel based ones are often worse.
Well yes I can do the calculation but still nothing that appeals me from a technical p.o.v.

 

[HKJ]

No. Read again what I wrote
I said no matter for how long the power has been off if power was taking from it within the first two seconds of being powered on it would then change to the next mode. Power it on and off withing two seconds. Leave it a week even with batteries out and it'll come on in the next mode. Power it on for more than two seconds and no matter how long power has been gone it'll come on in the exact same mode. Therefore if being powered on for more than two seconds and you wanted to change to the next mode you'd have to make two half presses. If skipping two modes after the first two seconds you'd have to do three in a row.

That sound like it need two writes , that is not a smart design.

Yes it could. But we don't know how they designed it. An yes the best are probably able to handle 1 million writes but the average quality does only 100.000 if using the typical ones from MicroChip like 12F629. The Atmel based ones are often worse.

Try checking Microchip PIC12F519, it has 1 million writes on the eeprom, but even 100000 is enough for most flashlight uses.

 

[McAllan]

That sound like it need two writes , that is not a smart design.

And not only two writes with every mode change - two writes just for powering it on

 

[was.lost.but.now.found]

OK, here's the results:

Change modes and disconnect power by untwisting the head - correctly remembers the last mode.

Change modes and disconnect power by untwisting head immediately within one second of mode change - correctly remembers the last mode.

That's about all I can say; you guys' technical discussion is a little beyond me.