just had an idle thought sitting at my bench - do 12V drivers have similar programmable Atiny chips? I was day dreaming about upgrading a microscope light source (currently halogen) with a high CRI LED and wondered if there was anyway to vary light of the LED by ramping. I’m not entirely sure it’s necessary as I only ever use mine at one level, just curious.
It would certainly save me being pestered every month or so by a student wondering why they can’t see anything through their microscope 
Okay, so I have made a few modifications, and I ended up with an unexpected result. I changed these lines:
const PROGMEM byte modes={ 0, 255,51, 254, 251, 252 };
(High, Med, Ramp, Strobe, Beacon)
case 251: mypwm=255; while(1){ PWM=mypwm; _delay_ms(15); PWM=0; _delay_ms(45); } break;
(faster strobe)
if (ticks==LOCKTIME) eepsave(1);
(memory off)
I used these fuses:
0x75 0xff
What happened:
High and Med work as expected. Strobe is “blank” No light when this mode is active. Beacon only works as a beacon, the battery monitor flashes are invisible. Ramping only works after the first three or four lowest steps have passed, and the first one or two visible ramps are EXTREMELY dim.
Any ideas?
I have only tried this program once, as after I flashed the chip, I installed it (semi permanently).
Maybe it’s a bad driver? I did install an additional 7135, and I suppose I could have overheated something… But I don’t know exactly what would cause this. The 105c with extra chip pulls the expected 3+ amps on high.
Strange. None of these changes should cause that behaviour.
Lowest missing ramp levels indicate a wrong CPU frequency; maybe verify the fuse settings.
Missing strobe: Have you adapted the “#define RAMPMODE 4” line to 3?
Missing battery indicator: have you deleted/commented out the “#define BATTMON 125” line? The battery indicator depends on it.
My suggestion: Restart with the original luxdrv03 and test that; if that works as intended, apply the changes you posted (and RAMPMODE) and test again.
Hello DrJones, i started with your driver just to create a falshlight driver for my parents 
As i wanted High Med Low Strobe Modes, i did customise it like that:
const PROGMEM byte modes={ 0, 255,51,10, 251 }; // with ramping
// dummy main modes ramping, ramped mode, strobe, beacon, timer
//#define TIMER 5 //use timer (5 min, max 6 in this setup)
//#define RAMPING //use ramping
#define MINPWM 5 //needed for ramping
#define RAMPMODE 4 //the number of the ramping mode (254) in the modes order; e.g. ramping is 4th mode -> 4; not counting dummy
#define LOCKTIME 12 //time in 1/8 s until a mode gets locked. 12/8=1.5s
#define BATTMON 125//enable battery monitoring with this threshold
In order to compile it without error i had to add const. and outcomment “Timer 5” and “#define Ramping”
the only problem is, if the flaslight is turned on it start with the last stored mode BUT:
it does: high med low high med low high med low strobe high med low strobe….
it takes a couple of cycles to get the modes right and to have strobe again, maybe a firmware bug?
there are some wired modes inbetween, do i have to flash the eeprom inside the atiny as i only flashed the .hex file?
Can you add oscillating strobe mode? just to get this as a weapon led driver
I use luxdrv 0.3 a lot and don’t know that problem.
Try switching faster; luxdrv uses short-cycle memory: if you use a mode >locktime, memory kicks in AND the next mode after that will be reset to 1st mode. That feature allows to have many modes without the need to always cycle through all of them. Very effective if you have your most used modes at the beginning of the list.
Sorry if you already knew that and meant something else.
After a few other attempts since the original failure I posted above, I determined a few interesting things:
The missing strobe was exactly what you had stated. I forgot to change “#define RAMPMODE 4” to 3. Simple enough.
I’m almost certain that the cpu frequency is not being set correctly, as you mentioned above. I also assume this is causing the rest of the problems. Now that the strobe is again working, it appears to be at approximately double speed. Also, when attempting to flash the chip, I noticed there is an error afterwards, when verifying the program there is a data mismatch. I tried reseating the connector numerous times, but couldn’t get past the error. Is it possible for the fuses to be locked and unable to be modified?
As a make do solution, I changed all the lowest PWM level from 5 to 10, and everything now works, aside from the data mismatch still comes up when flashing. I’m wondering if this may cause future problems… if the cpu is running too fast, it may not operate properly at low battery levels?
Can you somehow read out the fuse settings? 0x75 0xff should be right (4MHz). Indeed, running 8MHz at low voltages may cause instabilities.
I have odd problem with nanjg 101-ak-a1. To be more precise battery monitor/level does not work, as it goes to beacon mode led is off for a few seconds then it resumes in beacon mode. I tried 100% working hex/eep/fuse that I previously used on 101-ak-a1 driver, checked voltage divider resistors values and adc pin connection(pb2/adc1)
I suspect that either adc is faulty or perhaps adc1 channel connection to mux is faulty. In that case I could try to use another ADC pin but I need help to set it in code…
Solved !
False alarm… PWM value was set too low to excite this particular XM-L…
Chief, I have run into that same issue a couple times now. In my case I have a sneaking suspicion it has something to do with the fuses not setting correctly, and the attiny13 running at the wrong speed.
I doubt it as i checked (several times) that fuses are set to 0x75 and 0xff and all other (clock dependable) functions are operating at expected speed (strobe/beacon) Default PWM value is 5 and I had to raise it to 8 to get light output.
Perhaps there is something wrong. I just checked, pwm frequency is approx. 8.4kHz instead 9.4kHz
I used this line to “flash” attiny
avrdude -pt13 -c usbasp -u -Uflash:w:lampa.hex:a -Ueeprom:w:lampa.eep:a -Ulfuse:w:0x75:m -Uhfuse:w:0xff:m
I’m completely sure that those values were verified…strange…
Strange indeed. Did you make any hardware changes to the NANJG101AK1?
I recently used a lot of them for drop-ins and they all worked at PWM value 6 (tested). I didn’t test 5, but I’m quite sure they light up with that, too. I also use 0x75 0xFF, and 8kHz sounds fine (the ATtinys are often a bit slower than they should).
No, not at all. Perhaps those attiny13a chips are lets say “low grade” 
I won’t bother with it for now as flashlight works properly but I have more of those drivers and I’ll check again on next build.
I improved the luxdrv 0.3 source code a bit. It is now much more easily configurable. I also removed the timer, since most don’t have a use for it (and it often sometimes makes the code too big; it’s still in 0.22, so you can copy it from there if you really need it). I updated the original post.
Thanks DrJones for your excellent work
Can the way modes are switched be changed (1 soft-press instead of 2 soft-presses) or it that linked to the memory?
Hello dr Jones,
I have just seen tha you updated the program…
I will download it 2morrow and test if I can make it work!!!
Thanks a lot!! I hade the older version that is why i could not find the lines you told me…
That’s because of the driver hardware: The driver can not measure how long it was off, i.e. not distinguish between a short tap (half-press) or being off for longer. That’s why every kind of memory (or no-memory) kicks in after being on for a certain time (instead of being off for a certain time). That’s the same for all AMC7135 based drivers I know.
Somewhere in Tido’s thread is described how to add some hardware (capacitor, resistor, diode) to add that functionality, but the firmware has to support it; only Tido’s does.
Is there a thread how to make electronic switch for nanjg 105c for example
(because this firmware works only if flashlight has a electronic switch, right!)?