Pinched the cap from another 105c & stacked it, but no change.
I’m loving anything off-time at the moment so if this works reliably on a stock Nanjg, that’s fantastic news. Well done! 
Make sure brown out detection is enabled by setting the correct fuse bits when you flash it. The startup time fuse bits may be important as well. I flash it with these fuse bits: low=0x79 high=0xed
Yes, I used those fuse bits when flashing.
Oh wow…so this method of doing the code could actually replace the OTC on ALL the builds correct?
Very awesome build and very very slim on the coding…
Interesting method for making the levels…
are the 0x numbers written in HEX?
Welcome to the coding fray good sir 
most importantly, welcome to the forum!
Awesome first few posts
Hmm, I have only tested this method with the nanjg 101-AK-A1. It is possible that there are hardware differences that break this method. What resistors does the 105d use for the voltage divider? Do you have any way of measuring the capacitor?
Maybe try a low fuse of 0x75, I’ve found that also works. Maybe also try raising the brown out detect voltage to 2.7V by setting the high fuse to 0xeb. Maybe some combination of these will work.
Also, has anyone else tested this with their hardware and had success or failure? I’m interested to see which drivers this works for.
Edit: Also did you compile it from source yourself or did you use the hex file I compiled?
Thanks.
I’m not sure what you mean by OTC? I think this could be used on all the builds to get off-time memory. It’s a bit of a hack and I’ve only tested it on a few drivers, so I’m interested to see if others are able to get it working reliably as well.
Yes the 0x in front makes it hex. It’s the same as 255, 64, 16, and 4.
WarHawk-AVG means “off time capacitor”.
Sorry, I can’t measure the Caps. The resistor values are the same between the 101, 105c, & 105d.
I compiled the code from source using AVR Studio 5.1
I’ll try the different fuse values & report back.
Ok - I thought I’d try your pre-compiled hex first, & it worked on the 105d.
At that point I still had the additional Cap on the board, which I removed, & tested successfully again after the removal.
Success!
What I didn’t realize though, untill re-reading your Readme & OP, is that it is off-time memory switching , rather than off-time memory.
If this method can be implemented to save the current mode as well, I’m sure there will be a lot of happy people!
Great work, oh & welcome to BLF! 
Maybe you also try the hex file I’ve uploaded on github as well? There could be a difference in the way it is being compiled.
I tried replacing the 10uF capacitor on the 101 driver I was using with a 5uF (approximate values) from a 105c and it works fine with either of them. So I don’t think it is the hardware.
I’m compiling it on linux using the commands below:
avr-gcc -g -Wall -Os -mmcu=attiny13 -c driver.c
avr-gcc -g -Wall -mmcu=attiny13 -c driver.c -o driver.elf driver.o
avr-objcopy -j .text -j .data -O ihex driver.elf driver.hex
and flashing it using:
avrdude -p t13 -c usbtiny -u -Uflash:w:driver.hex:a -Ulfuse:w:0x79:m -Uhfuse:w:0xed:m
cross-post….
Sounds good. Alexvh’s method should adapt fine to the “normal” style of offtime memory rather than “offtime no memory”. Both the cap and this new method could be considered flags: the same method of keeping track of modes used by STAR_off_time is fine.
Oops, I posted before seeing your reply. So yes, it seems they are being compiled differently. We should try to figure out what’s different so that people compiling with AVR studio have the right options set.
The flashlight terms can be a little confusing, but I think I know what you are asking. Yes mode memory can be added to this using the eeprom just like in the other drivers. I’ll upload a version with that soon. So that the light turns on in the mode it was previously left on in (unless it is a short press, in which case it comes on in the next mode). This was mostly meant to show how it works and what can be done using this method. I wanted to show that you don’t have to use the eeprom at all unless you want mode memory.
I’m certainly no expert with AVR Studio, but I can try suggestions for different settings to compile & test. I know there has been a few minor differences in versions of AVR Studio that have caused hick-ups in the past.
I figured that should be the case. This is a real nice chunk of meat for the programmers here
Good stuff! Maybe this method can’t replace the short, medium and long press with the off time cap but it will surely make the stock driver much better. Thanks for sharing.
I can confirm that this method works well, it’s what I use on all power cycle lights, and implemented on a PIC in my code example here: tterev3's PIC quickstart guide
I found off-time memory via RAM retention some months ago, too. It's a known behavour with PICs, and I've seen tterev3 use it, but less known for AVR since it requires disabling the initialization the compiler does by default.
It worked, and I was quite excited at first, planned to make an off-time version for lucidrv with it, but found that the time was a bit too short on my test NANJGs to be comfortable; it required a decisively short tap and would often not recognize a 'normal' tap. So I didn't pursue that further and instead made a version for an off-time cap.
BTW, it's the voltage divider that pulls voltage below RAM retention level so fast. One could use double values for both resistors to make it more comfortable, but then again, adding a cap is easier than that. Without the divider, the driver held the 'cookie' (the value I used for RAM retention checking) for 10 minutes.
Also, if you want memory, you still need to store the mode in EEPROM.
Edit: I didn't use brown-out detection.
Thanks for the additional info DrJones. This sounds like it may be an effective dodge for the Tiny10’s lack of EEPROM (offtime / no memory with high-value voltage divider resistors).
That said, who wants to fool with the Tiny10? :~
I think it is also not possible to tune offtime periods in firmware with this method. With the OTC method those who do flashing can easily tune the values if desired.
Here's my code with memory, based on MiniDrv:
#define F_CPU 4800000 //use fuses low:0x75 high:0xff #include <avr/io.h> #include <util/delay.h>//change modes here; just change/add/delete values
uint8_t modes={8,90,255}; //PWM values, 5…255#define NOINIT attribute ((section (".noinit")))
volatile NOINIT uint16_t cookie;
int main() {
DDRB=2; //define PB1 as output
EEARL=4;EECR=1; uint8_t mode=EEDR; //read from EEPROM
if (cookie==1338) {
mode++;
}
//else mode=0; //NOMEM
cookie=1338;if(mode>=sizeof(modes)) mode=0; //wraparound, also check if invalid
EEDR=mode; EECR=4;EECR=4+2; while(EECR&2); //write mode to EEPROMuint8_t lvl=modes[mode];
TCCR0A=0b00100001; TCCR0B=0b00000001; //PWM setup, 9kHz
OCR0B=lvl; //set PWM level
while(1) {} //endless loop
}