Electronics > Projects, Designs, and Technical Stuff
Cheap Chinese Cree XM-L T6 modification
<< < (4/6) > >>
Rick Law:

--- Quote from: 0xdeadbeef on December 13, 2015, 12:40:08 pm ---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.

--- End quote ---

Actually, 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...
0xdeadbeef:
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.
Rick Law:

--- Quote from: 0xdeadbeef on December 14, 2015, 12:01:18 am ---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.

--- End quote ---

I am relying on wear leveling to take down the risk.  The wear leveling does update by WriteNew[atIndex+1] then EraseOld[atIndex].   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.
0xdeadbeef:

--- Quote from: Rick Law on December 14, 2015, 01:30:02 am ---I am relying on wear leveling to take down the risk.  The wear leveling does update by WriteNew[atIndex+1] then EraseOld[atIndex].   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.
--- End quote ---
Just 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 am ---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..
--- End quote ---
You 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 am ---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.
--- End quote ---
For 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 am ---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.

--- End quote ---
You 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.
mikerj:

--- Quote from: 0xdeadbeef on December 14, 2015, 12:01:18 am ---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.

--- End quote ---

Are 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.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod