This programming is being more and more fun… 
Anyone have any idea how to setup two simple sets of modes, HIGH-MEDIUM-LOW and LOW-MEDIUM-HIGH (without memory, in this case) that can be accessed by user by certain tapping sequence (20 taps in short time, for example) ??? That would be a rather nice setup as users could swap indoor/outdoor sets as they want…
People gave up on this thread… too bad two years ago I was total noob in this (just a noob, now, not total noob)…
Anyway…
How to shorten memory time with this firmware ? I’m not using extra components and want to setup no memory modes but it takes rather long to lock them in (to be able to start from mode 1 again)… it’s 2 seconds or more now… how to lower it down to 1 second (or less)?
Maybe I can look, do you have a C file?
I started to dig through DrJones luxdrv first because it is shorter, easier to understand and you can change it to your needs in minutes (with building and uploading )
But this idea with “20 taps in short time” (maybe not 20 but rather 3 or 4) is something that I will require also, you need timer for that…
It’s a BLF-VLD-0.4 from the first post… latest Tido’s update before he gave up idea of scrambling more into original driver.c (as it was getting more and more complicated for noobs to mess with but also too many #ifdef’s for his taste)…
It’s actually not any more complex than Dr.Jones’s code, they just have different approaches…
are you sure there is 0.4? I see only 0.1, 0.2 and 0.3!
Link to 0.4 is in the body of the post after the first pic, older versions are at the bottom.
Look in the ISR routine, and look for "switch(ticks){". Each "tick" is 250 ms, so you can change "case 8" to "case 4" if you want to change from 2 seconds to 1 second (all of my lights are programmed at 1 second memory). But if you're using the programmable option (which I never have), then you'll have to lower the following case number as well.
I used luxdrv more often, and I forget what the stock value is, but I always change my programs to 1 second.
Oh, yeah… that did the trick… thanks…
I made 4-mode firmware and different PWM values (0,2, 4, 20% and 100%) with 750ms memory kick/reset time (no memory used)… just enough for relaxed mode switching but fast enough to lock/reset mode so no unnecessary mode change, always starts from mode 1… I do find it crowded even if each mode has it’s own purpose… I’m rather simple man in my complexity… I guess my favorite choice will be 2-mode light… MAYBE with programmable third and fourth mode (set it up to be low, high, low, high but 3rd and 4th mode to be programmable into anything else, should I desire)…
Sorry if this has been asked or discussed before in this thread, but is it possible to just edit the default modes of the stock NANJG/Qlite drivers? By default I believe they are:
Can I change the stock firmware so that the 4th star is 100% - 30% - 5% for example? I know the stock firmware is read protected os maybe someone has 're-written' a version of the stock code?
I will go back and read through this thread, but I thought I'd ask here as well just in case I miss the relevant information....which I have done before.
- Matt
EDIT: I found DrJones' NLite firmware which is almost what I need but I will contct him directly about it.
Like this? https://budgetlightforum.com/t/-/18531
Yup :) I always find things AFTER I ask the question. I know this happens, so sometimes I say "look harder first Matt". I look for days, find nothing, so post. And then 5-10mins later I find it myself. Now I just figure if I want to find something just ask because I'll find it not long after anyway haha.
Frustrating too.
It would be cool if someone could explain how to do this “default mode” setting via driver stars soldering but in code because I would like 1 mode <—> 3 modes option 
Well someone in the thread ComfyChair linked reckons that the Qlite drivers he had were not read protected but then never followed it up. IF we can get that firmware we should be able to modify it?
I wasn't able to get any of the extracted firmwares to flash back onto the drivers, and don't know the software well enough to open them up and tell if they're scrambled. They're still available if somebody wants to poke at them: http://75.65.123.78/backup_files/
It isnt that easy as you would think. I suspect that only thing that we could do if we had genuine Qlite driver sw is to use it as a backup if something goes wrong with experimental sw that you wrote so you could alway return the driver to original state, I doubt that we could change anything in Qlite code.
When you build your project compiler removes all unnecessary data from the code, all the spaces, everything that is commented etc. also your code is translated to only language understandable by machines and once that happens there is no going back to source code…
Yeah good point. I don't deal with writing code very often (I'm more hardware focused) so I sometimes gloss over the tricky stuff :)
Can someone please grab the backups I posted and try flashing them? I don't know if they didn't work for me because I don't know what the hell I'm doing, or because they're protected. The flashing process worked as normal with no oddities in avrdude but with any of them, the driver ended up with only a single low mode and nothing else.
I would but I don't have any spare drivers on me at the moment 
Cool project! Never programmed a flashlight driver before, so I jumped in an programmed one from a recent Illumination Supply order tonight:
Getting a bit late to wire it back up to the emitter and host, but it seems like everything went without a hitch.
I keep an old XML bolted to a small CPU heatsink with alligator clips on the ends of the wires for testing various stuff like that, quick & easy. Finding out it doesn't work after it's back in the pill sucks. 8)