You can use it as you want for free - unless you want to make money with it.
To make things a bit clearer I changed the license to CC-BY-NC-SA (NC: non-commercial use only, SA: share-alike).
I'm reluctant to remove the NC, since I don't like the idea of someone else earning money with my work (yes, there's some egoism involved).
Awesome, thanks for clarifying that! Using an existing vetted license makes things a lot more straightforward. 
Do you have any similar clarifications for your other projects? In addition to LuxDrv, I also currently include the code for MiniDrv, MiniMo, your variable heartbeat effect, and a .hex for NLITE. I’m happy to include others too, if there are any you’re willing to share.
I see, thanks for the answer. I don’t think I’ve ever used CC for code and would rather stick to Public Domain for my first small driver. Is it something specific in luxdrv-0.30b you consider worth not releasing to the public domain? I’ve ripped out half of the code now and am down to 137 lines with comments so it’s not that much left. Should I rename functions too? Rewrite comments? Take away features (not that much left anyway)? My driver is only having lo-mid-full-strobe so it’s very simple.
I’m still waiting for my flasher so not tested but this is the code so far: tacdrv.c - Pastebin.com
I will continue to rip out code and rename and so forth until you’re happy to release it to the public domain. IMHO there should be at least one small driver released as public domain, Star is so bloody big. Cutting down more lines will be difficult now as I don’t think it gets any smaller than this but I could rename variables and functions if you want. As I learn a bit more I’ll try to add even more comments.
You can add as many comments as you want, compiler will throw out everything unnecessary when you make .hex file.
Er, copyright doesn’t really work like that… If you start with someone else’s work, you have to respect their copyright. The smallest copyrightable work is a haiku (approximately), so if you can get it under 17 words then maybe you can ignore the license. But it wouldn’t do anything useful any more.
Anyway, just saying… please respect the author’s wishes.
Of course, I meant as help to others. This is meant as a stripped down hello world for newbies too. And release it to the public domain means that people can use whatever license they want later on, even closed ones and semi-closed ones like CC.
I’m trying to do just that. BTW, luxdrv-0.30b seems to be quite old. The copyright may soon expire anyway. 
I am doing a school project and I need a driver with a strange mode of operation.
-I need to have input of 2 Lithium primaries *(would like 2-4 lithium primaries or 1-2 Li-ion as a an option if this is possible).
-I need output max of 2.5-3 amps, but with special thermal regulation; I need to attempt to regulate LED Tj with the driver. I want to adjust current up or down automatically to maintain LED temp, the pill or metal between them should be maintained at 90-120 degrees Centigrade.
*Driver will be attached to LED thermally by either pill or internal light construction but solic thermal path between the two.
I prefer higher efficiency
I can made physical adjustments if there is a sort of ‘remote temp diode’ (thermister??) and palce the diode on the LED die (this would mean I prefer a higher temp range of 100-130 deg C).
When low temp is not achieved then I want to run max current to increase temp, when temp is achieved then I would like to raise and lower temp to maintain temp within specified range.
I really need something that can do this but since most people don’t want to intentional degrade and abuse test their own LEDs I cannot find such a setup.
I hope you can help me on this but either way I appreciate your response and feedback or advice if you have any, thanks for your time
Joseph Pizzolatto
RMM and JonnyC worked together on a driver with thermal sensing and step-down — both the code and the hardware, I think. You want want to peruse JonnyC’s github repositories for the code and check at mtnelectronics if a driver or other parts might be available.
If I understand correctly, you just attach the temperature sensor to one of the extra pins on the attiny13a, and also to the inside of the pill for thermal contact, and the code should provide an example of how to read the temperature and adjust output.
I had a go at thermal sensing with a standard Q-lite driver without additional components. It worked but I never incorporated it because I couldn’t be bothered to deal with the calibration process: ATTiny13a tempurature monitoring without additional components.
The code should be fairly easy to adjust for your needs though… as the temp goes up, lower the output. However, you would have to do a lot of trial and error before you find the sweet spots. And if you can’t make changes to code and flash the MCU yourself, then this is definitely a no go.
I just received my programmer and have an soic clip on the way, but in the mean time I’m trying to set up my perfect UI.
What I want, is :: Turn on to LOW always, 2nd mode HIGH, third mode STROBE, fourth mode RAMPING, fifth mode BEACON with no memory, so if i want high I would go tap-click, and then if i turn the light off it will come back on in low the next time. I also want to have it to where if I am in HIGH for a few seconds, and then switch modes again from high it will go back to LOW instead of advancing to STROBE.
so Click > LOW
Tap Click > HIGH
Tap Tap Click > Strobe
Tap Tap Tap Hold > Ramping
Tap Tap Tap Tap Click > Beacon
and in any mode when power is cut revert to LOW again
Also, the LOCKTIME… if I am in a mode long enough for that to activate, will the light then revert to low instead of cycling to the next mode when power is cut?
I believe I have the code correct this is from LUXDRV .3 and the screenshot shows all I have changed.
Yes, locktime works that way. It all looks good to me. The ultimate verification is to download it and then test it. Hopefully you have a good setup to test the modes out before having to button it all up in a light.
The MINPWM value of 5 is good for 7135's. You can go as low as a PWM value of 1 if the driver is FET based.
Awesome, thanks for looking at it for me. The driver it will be loaded onto is a qlite nanjg 3.04a with the 7135’s.
Working on setting up the software packages and tool chain right now, hopefully I will have this driver in my light soon!
My current light is a solarforce L2N with the intl-outdoor XPL v6 3c dropin, it is amazingly bright and this UI will make it perfect for my work.
Does anybody know how to change the low battery shutdown voltage?
I would like the ability to make it higher or lower.
My understanding in reading the code is limited. But I think the following code is managing the battery monitoring.
#define BATTMON 125 //enable battery monitoring with this threshold
#ifdef BATTMON //code to check voltage and ramp down
adcread();
if (adcresult<BATTMON) { if (++lowbattcounter>8) {mypwm=(mypwm>>1)+3;lowbattcounter=0;} }
else lowbattcounter=0;
#endif
}
Do I only need to change the first line?
I think you could probably do it just by changing 125 to something else.
You can also measure what values correspond which what voltages by using battcheck.hex, so you won’t have to guess.
Thx for your reply, I will look into battcheck.hex
Problem is I don’t own a variable constant voltage supply. So I have to drain batteries to my desired voltage. Will this be a problem for getting the right value? (Batteries drop voltage with a load )
Will this also work with a zener mod? Or is the only possible method changing the rezisters?
If you get one high measurement and one low measurement, there is a battcheck.py script to guess at the values for an entire charge curve. I find it’s actually more accurate than measuring each individual level with an adjustable power supply.
The script assumes a voltage range of 2.5V to 4.4V though, and so does the source code of most drivers. A zener mod makes this a little weird. You basically have to adjust the resistors to bring the voltage back into the attiny’s measurable range (RMM’s spreadsheet helps), then measure charges at 2X or 3X the value you tell the MCU it actually is, and possibly adjust the PWM levels too. I hear that 7135 chips can burn up with too much voltage, and may need their PWM levels dropped to compensate.
But I’ve done virtally no higher-voltage builds and am only repeating what I’ve heard elsewhere.
Oh, um, this might all be a lot easier with luxdrv though, since it only uses a single value and only for LVP. If I recall correctly. So you don’t need a full calibrated voltage spectrum.
It’s also in the firmware repository linked from my signature… firmware, browse, drjones, luxdrv.