No, this firmware is for ‘normal’ lights with a clicky.
lumodrv is for lights with an electronic switch.
Is this a reply to my question?
I guess I just don’t understand. I’ve never had a light with last mode memory that needed multiple soft-clicks to change modes… :~
Yes, it is.
Many drivers work differently and can distinguish between a tap (half-press, soft-click) and being off for a while. But the 7135-based linear divers I know, i.e. NANJG 105, 101, 47, KD V2 etc. can’t.
DrJones
I think there is one problem with battery monitoring in your driver in moonlight mode case. In this mode the light cannot step down in brightness (formally it can but it will be darkness and no indication of low battery).
I think you should change the indication of low battery voltage.
Andy
Indeed, it steps down, but only down to moonlight level, the idea is that it never leaves in the dark. If it is in moonlight mode already, nothing happens. That already occurred to me, but until now I didn’t think it’s a problem… (mainly because it drains only a few mA then).
One could implement a short blink every minute or so.
In my opinion it is a problem. I know that most of people are using higher modes but some prefer or are using moonlight mode sometimes.
I agree with you that blinking is good solution.
How do you think is blinking adding a big problem (I mean code size in bytes)?
Andy
Hmm, I guess I need to learn more about these drivers. 
The driver I am trying to add this to is an AK-101-A1(or something like that) which came with 3 mode with last mode memory. It was able to change modes with a single soft click. Maybe I just need to implement code for the functionality or take another stab at customizing Tido’s.
My NANJG 105C draws 4ma at a value of 5 in the code for moonlight mode, measured with a 87v.
With a 3100mah Panasonic it would have a run time of 775hrs or 32.29 days left on continuous.
I don’t really see a problem with it unless used with a unprotected cell. The only problem I see is maybe using the light on high until it steps down, then using the light in moonlight mode. But you should realize that once it steps down the battery is very close to being drained already. If the battery had a useable 100ma left after the driver step down that’s still 25hrs left in moonlight mode. The battery pcb should trip at 2.5v if using a Panasonic 3100mah protected cell. If using a unprotected cell then I could see the need for a low battery warning in moonlight mode.
That Ninja Guy: Are you really sure they change modes with a single tap?
Let it run for 5 seconds and tap once, does it really change modes?
To my knowledge they don’t and no firmware can make them do it because the hardware doesn’t support it. (With one exception: You could implement next-mode memory. But who would want that…)
The original program is gone, but I will double check on my other Convoy S3 with a different driver.
EDIT
My other S3 does take a double tap to change modes. I could have swore that the one I’m working on did not, but I would guess it did.
Thank you for all your help.
One more question: I know that single tap works with next mode memory :sp, but does it also work with no memory?
No, because you need to distinguish between switching to next mode and switching to 1st mode.
Next mode memory always switches to next mode, so there’s no need to distinguish between two options and a single tap suffices.
That’s what I kind of figured. Thank you DrJones!
Hello,
I have just tried to build luxdrv3.0b but it fails
take a look
——— Build started: Project: luxdrv3b, Configuration: Debug AVR ———
Build started.
Project “luxdrv3b.cproj” (default targets):
Target “PreBuildEvent” skipped, due to false condition; (‘$(PreBuildEvent)’!=’‘) was evaluated as (’‘!=’‘).
Target “CoreBuild” in file “C:Program FilesAtmelAtmel Studio 6.0VsCompiler.targets” from project “C:UsersgeorgeDocumentsAtmel Studioluxdrv3bluxdrv3b.cproj” (target “Build” depends on it):
Task “RunCompilerTask”
C:Program FilesAtmelAtmel Studio 6.0makemake.exe all
Building file: …/./luxdrv3b.c
Invoking: AVR/GNU C Compiler : (AVR_8_bit_GNU_Toolchain_3.4.0_663) 4.6.2
“C:Program FilesAtmelAtmel Studio 6.0extensionsAtmelAVRGCC3.4.0.65AVRToolchainbinavr-gcc.exe” -funsigned-char -funsigned-bitfields -O1 -fpack-struct -fshort-enums -g2 -Wall -c -std=gnu99 -MD -MP -MF “luxdrv3b.d” -MT”luxdrv3b.d” -MT”luxdrv3b.o” -mmcu=attiny13a -o”luxdrv3b.o” “…/./luxdrv3b.c”
C:UsersgeorgeDocumentsAtmel Studioluxdrv3bluxdrv3b.c(51,14): variable ’modes’ must be const in order to be put into read-only section by means of ‘attribute((progmem))’
make: * [luxdrv3b.o] Error 1
Done executing task “RunCompilerTask” — FAILED.
Done building target “CoreBuild” in project “luxdrv3b.cproj” — FAILED.
Done building project “luxdrv3b.cproj” — FAILED.
Build FAILED.
Build: 0 succeeded or up-to-date, 1 failed, 0 skipped
UPDATE!!!
I build it successfully using AVRstudio5.1!!!
I also changed the levels to my liking and turned memory off!!!
Works great!!!
Thanks drJones!!!
Glad you figured it out, it took me hours of tinkering.
Just ignore that driver I sent you. 
Did you make sure you used the correct fuses?
Hello Ninja Guy!!!
Thanks a lot!!!
In fact you send me a better mode than the one I figured out!!!
The only thing that I managed to do is to change the 4 modes to4-20-50-100 and deactivate memory!!!
I will try now tha one you send me!!!
give me a minute to test!!! :bigsmile:
Works great!!! WEll done!!!
Man you are great!!!
Is it possible to send me the c file you moded also so that I can enable/disable memory and change modes to experiment with???
Sent.
The real thanks needs to go to DrJones, he did all the hard work, I just tweaked it for you. 
thanks to everyone guys, I have already thanked drjones, ninja guy and sixty545 In my welcome thread but I want to thank you again!!!
for me it would be impossible to make it on my own!!
Thanks for everything guys!!! you are the best!!! 
and drJones!!! You rock!!! and your driver rocks!!!
I would like to say thank you to DrJones for sharing this program. The Ramping is fantastic. The concept of wear leveling and a timer function are awesome ideas. I bet your more advance driver programs are great products.
I would also like to thank Tido, sixty545, Microa, moderator007, and the other great contributors to this area of flashlight modding.
I have implemented the BLF-VLD Programmable driver in several of my lights without issue, but I’m having a problem with my first implementation of this driver program. The issue I am having is that it takes multiple attempts to switch out of the first two modes. Generally, 2 to 3 attempts. Sometimes it takes me many click attempts to get out of the first mode. Sometimes, no light is emitted.
My set up is a C12 with Nanjg 105 (c, I think) with 10 amc7135’s driving an XLM2. I have tried:
- Clicking at various speeds,
- Different tail caps/switches,
- No tail cap and touching wire to body and battery negative directly
- Changed the “MinPWM” from 5 to 10. That seemed an improvement, but I was in a hurry to get to work at the time.
Tonight, if I get a chance, I will try to increase it to 20 to see what happens.
I read somewhere in this thread someone had a similar issue, but I didn’t see a resolution documented. Does anyone have any ideas what may be the problem?
EDIT: low fuse set to 0x75, hfuse set to 0xff. Tried 0x79,0xed with no improvement.
EDIT2: Tried 20 for minpwm. Didn’t seem to improve. Will double check driver grounding later.