Cheap Chinese Cree XM-L T6 modification - Page 1
Forum section: electronics / projects

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: December 10, 2015, 11:29:14 pm
content: Well, call me eccentric but I really dig cheap Chinese flashlights. Most of them are the Cree Q5 type which take a single AA NiMH battery as they have some kind of boost converter built in,but recently I bought some slightly larger ones called Cree XM-L T6 that need a single 18650 cell.Anyway, while all of my Q5 type flashlights are single mode (on/off), the T6 flashlights are usually multi-mode.Which by itself isn't necessarily a bad thing, but nearly all of them have an annoying strobe mode.Now I got my hand on two Ultrafire XM-L T6 flashlights with three modes: high, low, strobe.The bad thing is that the things remember the last mode for a real long time. So if you used high mode, put the flashlight aside and switch it on a few minutes later, it will switch on in low mode.Even worse: if it was in low mode before, you turn it on in strobe mode. And that's really the most annoying strobe ever.Actually the type likely to trigger an epileptic seizure.So I took the thing apart and found surprisingly few parts inside. The main part is a P-FET, namely a Fairchild FDS9435A with the marking P51QJ and a mystery SOT-23 with the marking HA4E.Typical highside switch configuration where the FET connects the load to the battery voltage.The gate of the FET is connected to the SOT-23 and there's a 3k resistor between gate and source (VGS=0 -> off) which again is connected to the battery's positive pole.Last but not least, the resistors drain is connected to the anode of the LED (L+) through four parallel 1Ohm resistors.The LED's cathode (L-) is directly connected to the common ground which is connected to the minus pole through the case and the mechanical switch.So it's quite clear that the mode handling and PWM/strobe creation is done by the SOT-23. I measured the gate in all three modes to see if the high mode used a PWM - which it didn't:high: 100% DClow: 75% DC, 230Hzstrobe: 50% DC, 7.7HzSo one solution would be to bypass the SOT-23 and connect the gate directly to ground.However I assumed that storing the mode was only possible through the capacitor (~1.6µF) and tried to remove it.Unfortunately, this didn't really improve the situation much. So I replaced it by a 22k resistor. Thiseffectively converted the flashlight to a single mode one. Yet it felt wrong to remove the capacitor completelyand I wondered if adding a resistor in parallel would still allow to use all three modes but reset the stored mode faster,so the flashlight would always switch on in high mode after a few seconds off.So I put the capacitor back and botched a 22k resistor in parallel on top. With this modification, the mode is alwaysreset to "high" after about 2-3 seconds off while before it "remembered" the last mode for minutes or even hours.The two other modes are still available if you switch the lamp off/on faster than the 2-3seconds needed for resetting the mode.I guess I might try 10k resistor the next time to reduce the off phase needed even a bit more.

author: Vgkid
author_rank: Super Contributor
timestamp: December 11, 2015, 12:21:16 am
content: Thanks for this post, I always contemplated getting one of those XML-t6 lights, but never did.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: December 11, 2015, 12:45:51 am
content: They are pretty cool and quite a bit brighter than the Q5 type with a much broader beam. Still I think the Q5 type is the best compromise between size, brightness and usability. These are also much cheaper even though they have more complex electronics (boost converter). Besides. the 18650 cells frighten me a little bit - even though they are available with protection. For the moment, I use LiFePO4 cells but they have lower voltage and capacity compare to Li-Ion.Anyway, be aware that there are quite a few different types of XM-L T6 flashlights available. Most have 5 modes (low, mid, high, strobe, SOS) and while I assume they can be modified with a similar approach, you can never be sure what kind of surprise another flashlight model will unveil. Also my version didn't have the dents in the LED module, so it was a bit tricky to unscrew it.Side note: I found it surprising to see that the P-FET (FDS9435A ) used in my flashlights is not really specified for voltages below 4.5V. The RDS will be quite a bit higher for typical Li-Ion voltages and even worse for LiFePO4.I tested the module with a bench power supply at 3.7V and the current increased from like 350mA to slightly over 500mA. Still, while the P-FET got a bit warm (around 45°C or so), it didn't look critical and the main heat source is the LED anyway.

author: nukie
author_rank: Frequent Contributor
timestamp: December 11, 2015, 01:38:39 pm
content: They use whatever they could source cheap, ie fish of the dayYou will also notice some pcb designed to accept multiple footprints.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: December 11, 2015, 03:36:39 pm
content: Hey, that's part of the adventureActually, I ordered dozens of Q5 flashlights over a longer period - most of them as presents for relatives, colleagues etc.And every time I got slightly different ones: different switches, with/without dents to unscrew the LED module, with/without silver foil as reflector, even the size and other mechanical details differ.It seems there was a base model that all the clones are based on, but probably in the meantime everybody forgot what the original wasAnyway, I really wonder who came up with that multi-mode idea. Two or three brightness levels can make some sense but I find it hard to imagine when someone would need a fixed strobe mode or even a SOS signal on his flashlight.

author: Rick Law
author_rank: Super Contributor
timestamp: December 12, 2015, 02:46:31 am
content: Quote from: 0xdeadbeef on December 10, 2015, 11:29:14 pmI did exactly the same mod to mine with a 99K resistor (just happen to be at hand). But I was still not happy with the way the flashlight works, I don't like turning on always at HIGH because that assures you loose your night-vision. I rather it turns on at LOW - or with memory to always turn on where I left it.So, I got the Nanjg 105c which uses a Tiny13A. I took the opportunity to learn how to work the AVR. It remembers the current mode and power up with that. It has two modeFiles, one 4 levels of brightness, and the other 6 levels of brightness. It blinks out the battery voltage at my command. 3 HIGH blink followed by 6 LOW blinks would mean 3.6V.The volt-blinker also serves as a user menu. Every 8th voltage blink, it display another blink sequence - a choice number blink.- Turning off during 1st choice flips between ModeFile 1 & ModeFile2,- turning off on 2nd choice flips an acknowledgement blink (when mode memory changed)- turning off on 3rd choice flips the acknowledgement type - single blink or the mode number.I was out of code space so I left it there. Accidentally yesterday, I blew the Tiny13A on my bench, so I don['t have my development platform until I get the Tiny85V as replacement. I am upgrading to the 85V for the 8K flash instead of the Tiny13's only has 1K flash for the code.Apart from the opportunity to code MCU outside the Arduino environment, I found the flashlight rather fun to play with.

author: bingo600
author_rank: Super Contributor
timestamp: December 12, 2015, 06:58:35 am
content: Any pointers where to buy a small flashlight , with a Nanjg 105c inside ??Size should fit a small pocket (need it for a hiking trip)I'd like to play around with the Atmel MCU , and possibly replace it with a T85Or maybe even just a link to the flashlight , and a pointer/link to a Avr driverboard that mounts inside/Bingo

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: December 12, 2015, 11:32:11 am
content: Quote from: Rick Law on December 12, 2015, 02:46:31 amFascinating. There's even a wiki describing the details:http://flashlightwiki.com/AVR_DriversStupid question maybe, but how does the Tiny detect the "clicking"? I figure it has an internal bandgap reference, so I guess it's just detecting a drop on the voltage monitored through ADC?I guess you could develop fascinating things like a full range PWM control where the LED would slowly become brighter and you could set the desired level by clicking and then store it in EEPROM.Anyway, it seems the Nanjg 105c sold on Fast-Tech has a 17mm diameter while the PCB in my flashlight has more like 20mm. Well, and programming through a SOIC 8 clip seems like a bit of a hassle as well.Ok, I see there is a solution for the 17mm-20mm problem, even though it makes the "upgrade" even a bit more expensive...http://www.ebay.de/itm/2-Pcs-x-17mm-To-20mm-Brass-Adapter-Ring-For-CREE-LED-Flashlight-Driver-/130992009627?hash=item1e7fbb719b:g:SGIAAOxykMpTGYz3

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: December 12, 2015, 01:02:30 pm
content: For the protocol: I measured the unmodified driver module again and it draws about 948mA at 3.6V. Note that it ramps up slowly from slightly below 900mA.I guess the forward voltage decreases with temperature. Which makes the result a bit uncertain as it depends on the time and temperature.The forward voltage of a XM-L is specified as 2.9V @700mA (typical) and it increases with higher voltages. So let's assume a 3V forward voltage for the moment.The four 1Ohm resistors in parallel form a 0.25Ohm resistance. The P-FET is a bit harder to estimate as Rds is specified only for VGS = -4.5V (-> 80mOhm).Looking at the tables, I would assume the Rds for -3.6V @1A should be at least 100mOhm. Taking into account the resistance of the wiring etc. let's say thecomplete resistance would be around 0.4Ohm (0.25 resistors + 0.1 P-FET + 0.05 for wires/switch etc.).So the voltage drop between battery (3.6V) and LED (3V) is 0.6V and the resistance is 0.4Ohm -> I = U/R = 1.5AThat's close to what I measured, so I guess either the forward voltage is still a bit higher than 3V or the resistance in my measurement setup was slightly higher.Anyway: this goes to show what a crappy design this LED driver is: the current through the LED depends on several factors like the battery voltage and theforward voltage and is only limited by a somewhat uncertain resistance where the Rds of the P-FET is the largest contributor as it's used outside its specifiedvoltage range.This alone makes me wonder if I shouldn't replace the PCB. At least with a single mode board with some AMC7135 current regulators. Something like this:https://www.fasttech.com/products/0/10017778/3647303-1400ma-1-mode-led-flashlight-driver-circuit-board

author: Rick Law
author_rank: Super Contributor
timestamp: December 12, 2015, 07:07:30 pm
content: Quote from: 0xdeadbeef on December 12, 2015, 11:32:11 amDetecting the clicky: You don't. But you know if it got turn off, and the chip has EEPROM to save that.I am sure there are many good solutions. As challenge, I made myself figure out how. This is the flow I use:- Set the bit in eeProm, flash the led to indicate choice number for wait for X times.- If after X times and the flashlight is still ON, I know that choice was not made- I reset the selected bit in eeProm and move on to the next step which would be the next choice or done.It is a bit of a mind twisting making choices by turning it off. It takes a while to get your programming brain to adapt to such thinking. It beats up on the EEPROM rather hard, so having a wear-leveling routine is almost a must. I use 40 bytes to store just one byte. So instead of 100,000 write cycles, I have 4 million write cycles.There is also a hardware modification (adding a capacitor) so you can detect how long the flashlight was off based on how far the capacitor bleed down. You don't need that if you merely want to detect "double click" to advance mode.If you are a beginner, don't make that your first project. Start with the Arduino UNO or NANO first. You have more examples and room on the chip to learn. (32K flash...)The Nanjg 105c's Tiny13A has only 1K flash (code space), 64 bytes of ram, and 64 bytes of eeprom. So you can't do much. But learning that challenge is educational. Besides the two mode files and battery voltage display (via blinking), I put in a turbo mode timer and eeprom wear leveling and I am flat out of flash space. By the way, turbo timer is to limit the time on full power then switch to low. So I can put on a high-power light on the cheaper/smaller flashlight with less-than-good heat dissipation.I blew my t13A a couple of days ago but I am not exactly crying. I have been kicking around with the idea of upgrading to the Tiny85V (8K but will require some leg bending to fit) or Tiny25V (2K, no leg bending). The t25v and t85v even have build-in temperature sensor. Blowing the t13A kind of forced my hand with giving the Tiny85V a go.If you are interested in doing your own, you need to learn programming. As I said, Arduino may be a good place to start, and Arduino makes a good ISP programmer for the Nanjg105c. The only additional hardware you may need would be an SOIC clip. Software wise, beyond Arduino, you will need to learn how to use WinAVR/AVRDude. There are lots of examples on the web on doing that. I recommend searching for "STARS" by JonnyC, and "Dr. Jones Minimalist driver".Good luck, and join the fun.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: December 12, 2015, 07:44:39 pm
content: Quote from: Rick Law on December 12, 2015, 07:07:30 pmWell, writing to EEPROM in a situation where you are about to lose power is certainly a bit risky.Without further checking, I'd assume the 100k cycles are most probably not given for worst case conditions (like high temperature and low voltage).Besides I still think that with a proper circuit design, it would be possible to detect the click without undervoltage/reset.E.g. larger capacitor for the tiny's VCC separated by a diode so it only supports the tiny.Quote from: Rick Law on December 12, 2015, 07:07:30 pmHm, if you'd knew how funny this is

author: Rick Law
author_rank: Super Contributor
timestamp: December 12, 2015, 09:05:04 pm
content: Quote from: 0xdeadbeef on December 12, 2015, 07:44:39 pmNo no... I didn't take the approach of brown-out detect to write. The EEPROM is written before the choice-blinks are on. It then blinks N times each lasts over 1 second. If it didn't get turned off (ie:did not select), then it proceed to write the original state back.Quote from: 0xdeadbeef on December 12, 2015, 07:44:39 pmHmm... Now you have me curious. What can I bribe you with so you tell me? I can part with a 1 Mega Ohm metal film 1/4W resister. A whole million ohms! Million! With 6 zeros after the one. Even if you use 100 ohms a day, it will last you a life time. Send to a Swiss account of your choice so it is untraceable.(I think you mean you are already experienced programmer or hacker. But I can't forgo the chance of making a joke...)

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: December 13, 2015, 12:24:18 am
content: Quote from: Rick Law on December 12, 2015, 09:05:04 pmAnyway, if the Tiny is switched off more or less immediately when the flashlight is switched off, this could happen during an EEPROM write. And that's pretty bad for data integrity, most probably also for data retention.I mean, OK, it's just a flashlight anyouknow when you shouldn't switch it off, but I'd had my concerns to bring something like this into production.Quote from: Rick Law on December 12, 2015, 09:05:04 pmWell, letting aside that I'm into programming for >30years and that I design and develop embedded software for a living since nearly 17 years, but most importantlyI lost my interest in AVR developmentyears before the first Arduino board was developed

author: Rick Law
author_rank: Super Contributor
timestamp: December 13, 2015, 02:20:18 am
content: Quote from: 0xdeadbeef on December 13, 2015, 12:24:18 amCan't think of better ways to "click select" with just an On Off button. The sequence is:- write the select bit into eeprom- blinkLow N times for choice N then Stay HI for 2 seconds, turned off to select- rewrite the original byte resetting the select bit- Increase N and reloopSo I am indeed exposed to the light being turned off while writing. If it has just one more button...Quote from: 0xdeadbeef on December 13, 2015, 12:24:18 amHats off to you!Really. I thought you were just starting off with the Arduino. Most less matured or less "nice" individuals (regardless of age) would have taken the opportunity to "set me right" or "dress me down" since I talked to you as if you were a beginner. You acted in ways I wish I do. So hats off to you.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: December 13, 2015, 12:40:08 pm
content: Ok, while I guess the EEPROM approach could be made pretty robust to also cover (undervoltage) resets during writing, I still wonder if the EEPROM is really needed with the according circuit.I understand that using the EEPROM is the common solution for the Nanjg boards, so take this as merely academic comment.I attached a simplified circuit of what I have in mind. It would all a bit easier to imagine if the switch would disconnect the plus pole, but usually the minus pole is disconnected which kinda leaves the ground floating.Nevertheless, I guess it should be possible to supply the Tiny from its "own" capacitor for a while after the flashlight was switched off. In the grossly simplified circuit diagram I attached, the Tiny is represented by the 1MOhm resistor. Which is a bit optimistic obviously, but just to get the idea. The problem is obviously that the charge stored in the capacitor would be used up by the rest of the circuit - mainly the LED of course (again massive simplification with a low current LED and 1k resistor for current limitation). So we need a diode that forbids that. But since the minus pole is switched, we need it between the capacitor's virtual ground and the ground used by the rest of the circuit.Obviously the diode's forward voltage will introduce a voltage drop on the capacitor and thus also on the Tiny's supply voltage. However using a Schottky diode and considering the rather low current flowing through the diode, the voltage drop should be acceptable. I understand the Tiny works down to 1.8V, so even a voltage drop of 0.4V would mean it would work until the battery voltage drops below 2.2V - which would be a seriously dead Li-Ion. Anyway, the diode also influences the voltage measurement as the Tiny's ground reference will be like 0.4V above that of the battery -> voltage difference has to be measured physically and considered in the Tiny's calculation.So let's say we have a 3.6V battery voltage and a 10µF capacitor: this means the charge is 36e-6 Coulomb or 36e-6 As. Which can be read as 36µA for one second.Now the Tiny is said to consume 190µA at 1.8V when active (1MHz) but that seems to be only possible with an external oscillator. With the internal 4.8Mhz oscillator, it's probably more in the 1mA range.Probably above that due to driving pins, ADC etc.Still, I guess the Tiny could survive a voltage drop for seconds if would switch to idle mode when it detects the dropping voltage (through ADC) fast enough.I must admit though that this approach would need additional parts (increased costs and space needed) and id probably trickier to implement that the EEPROM solution.

author: Rick Law
author_rank: Super Contributor
timestamp: December 13, 2015, 09:33:26 pm
content: Quote from: 0xdeadbeef on December 13, 2015, 12:40:08 pmActually, the Nanjg 105c appears to have such a capacitor already (C1 in attached schematic from tracing, first pass, not yet confirmed to be correct). I cannot measure C1's capacitance in circuit.I am not sure if the Nanjg's original firmware does brown-out detection, or is C1 there for other reasons. If it is for other reasons, it certainly should be usable for brown-out as well. I don't have the codespace to do it on the TINY13A (along with the stuff that I really like). I am going to experiment with brown-out detection once I get my TINY85V with more codespace.For my TINY13A, my thinking is, since the eeprom is just storing current options (which modeFile, mode-stored acknowledgement), if it got corrupted, I will just re-made all the option selections.Your post just now gave me renewed vigor to pursuit this - once my 85V arrives, I will bend its legs and shoe-horn it into the Nanjg's 13A smaller space as others had done.EDIT: insert the wrong jpg at first...

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: December 14, 2015, 12:01:18 am
content: The diode is marked "inverse polarity protection" and I guess that's what it is. It can't really protect the capacitor from discharging as the switch is on the minus pole and the plus pole is always connected.Then again I must admit I forgot to consider the forward voltage of the LED regarding the capacitor discharge. The current through the diode will stop is the voltage goes down to about 2.9V (XM-L).Assuming the protection diode is a Schottky type, there should be around 2.5V in the capacitor when the current through the LED stops.Which means that at this point the capacitor is only discharged through the µC, the voltage divider and parasitic resistance in the cap etc.However the voltage divider alone would sink 105µA @2.5V (2.5/(19.1e3+4.7e3)). Even for a 10µF capacitor at 2.5V, the voltage divider would lower the voltage below 1.8V (Tiny brownout) in 80ms.And I kinda doubt they used a 10µF capacitor. Probably it's just a 100nF bypass or maybe something in the 1-2µF range.So yeah, most probably using the EEPROM is the only choice for this circuit.I guess you'd need a higher resistance voltage divider and/or a higher value capacity.Anyway: with a proper wear level routine and some robustness means, the EEPROM approach should work. My main concern would be data retention in case of brownout during writing the eeprom.Unfortunately, typically the available data sheets don't cover stuff like this. The manual just says "Writing the EEPROM at VCC below 1.9 volts might fail.". But could the content of the cell written below 1.9V also change after a day or so? Typical robustness means would be to put a complement for each byte (but this might reduce the write cycles) or at least to handle unexpected values.

author: Rick Law
author_rank: Super Contributor
timestamp: December 14, 2015, 01:30:02 am
content: Quote from: 0xdeadbeef on December 14, 2015, 12:01:18 amI am relying on wear leveling to take down the risk. The wear leveling does update by WriteNew[atIndex+1] then EraseOld. The Read looks for the first non-0xFF byte. So my exposure is only acute if Index hits end of buffer and got reset to 0, or if it failed the Erase but erased the byte partially.With the 85V with more code space, I can afford to check ADC before Write and before Erase. If I understand right, it takes the Tiny13A only 14 milli seconds for an erase or a write (haven't check the 85V yet). So 80ms or even 40ms should be adequate.At first, I just wanted to tinker with the driver electronics. But I am glad I got into this custom driver writing thing. I had wanted to look under the hood of the Arduino but there was not the impetus to do it. The custom driver development made me learn to live outside the Arduino IDE. Now I feel I know the AVR a lot better.That said, writing for 1K of RAM is like trying make a fry chicken dinner in the back seat of my car. It can be done but every move I made, I run into space limitation. One wrong move, I get a burn. When my this is done, I am going to be glad to write some junk for the Arduino like a "Good morning" when I turn the lights on, show it on the TFT screen with the real-time clock running showing me date, time, software version, Serial.print it to the PC as well, and all with extra RAM to spare.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: December 14, 2015, 10:18:13 am
content: Quote from: Rick Law on December 14, 2015, 01:30:02 amJust make sure to handle unexpected states. Also maybe it makes sense to define states with distinct patterns. Don't know how much states you have, but if you have like 16 or so, maybe it makes sense to give them more complex binary patterns than simply 0,1,2,3,..15. Like a maximum hamming distance kind of approach. This makes it more likely to detect corrupt cells.Quote from: Rick Law on December 14, 2015, 01:30:02 amYou should try to measure the voltage and timing though. I would assume that the voltage on the LED would rapidly go down do ~2.9V after the switch was opened (switched off) and that the voltage would sink much more slowly from that point. Keep in mind that the voltage measured on the Tiny will be lower due to the protection diode. Bit hard to estimate the forward voltage as it depends on type and current, but I guess it should be in the 0.4V range or lower for such low currents.Quote from: Rick Law on December 14, 2015, 01:30:02 amFor me this "looking under the hood" is the main thing that makes microcontrollers interesting. I love to write my own low level drivers and would hate to be limited by some Arduino abstraction layer. Letting aside the lack of debugging possibilities. And now that I can finally use JTAG/SWD in my private projects, I sure don't want to go back to serial reprogramming.Quote from: Rick Law on December 14, 2015, 01:30:02 amYou mean 1k of ROM and 64 bytes of RAM - which is inded a bit limiting. Reminds me of the PIC 16F84 in the nineties - then again these PICs were meant only for assembly programming.Anyway, with such limited space it could make also sense to think about assembly.

author: mikerj
author_rank: Super Contributor
timestamp: December 14, 2015, 10:35:00 am
content: Quote from: 0xdeadbeef on December 14, 2015, 12:01:18 amAre EEPROM write errors really a problem for this application? If the flashlight starts up in a different mode to the one you expect, it's really not a big deal, it just takes a few more clicks.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: December 14, 2015, 11:22:24 am
content: Quote from: mikerj on December 14, 2015, 10:35:00 amSure. But if you don't consider a write error in your design you could as well be stuck in an "unexpected state" forever. It's always better to do a proper design than to be surprised by a bad one.

author: Rick Law
author_rank: Super Contributor
timestamp: December 14, 2015, 05:54:49 pm
content: Quote from: 0xdeadbeef on December 14, 2015, 11:22:24 amI thought about that during the initial coding. The worst I can expect is all the modes get set in different than intended. So I made sure that my "safety related" features are not software controlled.Software controlled are:- Which set of modes, set 1 or set 2.- Should it blink to acknowledge saving current mode as default start up- What kind of acknowledgement? Blink the mode number or just one quick blink.Hardware controlled (shorting one of the "Stars" to ground)- Bypass turbo timer and let full blast go forever at the risk of overheating- Bypass low battery mode (drop down to moonlight level only when <= 2.7v)The low battery mode doesn't do a full off but goes to 10 of 255 pwm. So, in case of power outage, I have the option to "trade the life of the battery for a bit more light."

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: December 14, 2015, 10:55:40 pm
content: Even though I'd prefer some kind of power latch approach where the µC could measure on and off times of the switch (e.g. combined with soft power on/off), some people seem to have come up with ideas to store at least the information that the switch was currently on (or the other way round: to say that it was off for a longer time):This site provides "off-time" firmware versions that make use of an additional 1µF capacitor on one of the port pins (star 4) as flag:http://drjones.nerdcamp.net/And here is some code that claims to use an SRAM cell to store the information that the switch was one for 500ms:https://github.com/alexvanh/basic_off_time_driver/blob/master/driver.cWhich is not completely impossible as SRAM consists of flip-flops which need only very little energy to keep their state.Problem is that this is probably not very reliable. Like it might work on some controllers, but not on others.BTW: another site with custom firmware - looks like an EEPROM only approach:http://jcapsolutions.github.io/blf-firmware/

author: nukie
author_rank: Frequent Contributor
timestamp: December 15, 2015, 05:12:22 am
content: I have used the write at switch on approach since 2006 with an Attiny13 with one of an early Luxeon star. Never a problem with 10uF bypass cap with two AA nimh.There are other ways to detect mode change without EEPROM, the chinese are pretty good with PIC chips.

author: Rick Law
author_rank: Super Contributor
timestamp: December 17, 2015, 03:52:04 am
content: Quote from: 0xdeadbeef on December 14, 2015, 10:55:40 pmI credited my knowledge to them: Dr. Jones and JohnnyC (jcapsolutions). Apart from studying the datasheets, I studied their work to figure out how things are done as I wade into AVR without Arduino. I use their work as a cheat sheet and reference.After I got my replacement ATTINY85 on my test setup (replacing the blown ATTINY13), it just occur to me that I don't need any fancy timing/brownout detect type things here.Since my approach consist of two EEPROM related steps:OldIndex = Index++;if (Index>=MaxIndex) Index=0;WriteNewData(Index);EraseOldData(OldIndex);If it didn't complete the WriteNewData(), EraseOldData() never got done.If EraseOldData() did not start or started but did not complete, upon power up, that oldData or partially erased oldData would be found to be the first un-erased byte. Upon boot up, it would think that is the new data, but the bits may be partially erased.So, after finding the Index for the byte, assume this may be partially erased and see if there is data at "the other / older" Index (Index during write before Index++, adjusting for wrap around index). If there is, the erase did not occur or did not finish, so use the data at the "other Index" and forget this partially completed mode change.Good thing about it being "just a flashlight". Worst case is, what it mess up is just a mode change. Now that my ATTINY85 is working, I have more code space to work with. I can begin playing around with more things.

author: chefslot
author_rank: Contributor
timestamp: October 26, 2018, 04:35:15 pm
content: So in regards to just having a strobe effect how would you accomplish this??Regards

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: October 26, 2018, 06:02:39 pm
content: You mean with the original design? IMHO this wouldn't be easily possible unless the strobe effect would be the default mode. Since all my modification did was to reduce the time the little SOT chip could remember the current mode before it reset to the default mode (which was high in this case).I guess the best approach for permanent strobe would be to remove the SOT, put an oscillator circuit or even a small microcontroller (to create your few Hz PWM) in its place and connect it to the gate of the FET. Note: in the original circuit, the gate has to be pulled to GND, so you need some kind of open drain circuit or to configure a µC pin to "open drain" mode (which actually disables the highside of the push/pull output stage). Dunno if this would be worth it as the original design is somewhat crappy anyway. Probably it would make more sense to completely exchange the PCB (either buy one with a Tiny or design your own PCB with any small µC).As a side note, in the meantime I replaced the PCB in most of my XM-L T6 flashlights. I think I have only one of these flashlights with botched PCB left.

author: Rick Law
author_rank: Super Contributor
timestamp: October 27, 2018, 01:29:13 am
content: Quote from: 0xdeadbeef on October 26, 2018, 06:02:39 pmBesides the issues0xdeadbeefalready mentioned, you need to check the clearance if any added parts are thicker than original. I've mod eight T6/18650 based flash lights (from different sellers), some have extra clearance and some have none. On about half of them, I had to add additional O-Rings just to get the extra clearance to fit the thicker-than-original (MCU based) driver into it.So,before you start any modification, check how many dimes or pennies (or any different metal coins) you can put between the battery-minus and the spring and can still close the flashlight tube. That will give you an idea on if additional clearance is there at all. Otherwise, you have to factor in the cost/trouble of needing to get some O-Rings.On one of them, there was no room to do anything at all! I ended up just "killing the memory" by removing the capacitor so it always power on to HIGH instead of sometimes starting out with the annoying strobe mode.