If I were a person in danger of getting into a hazardous situation, e. g. living in an earthquake area or exploring caves, I would configure the light once for LVP override and won’t change it anymore. The worst case which could happen is a damaged cell, but it might save my life.
For the next BLF light we are going to have to step up to an ATMega. :disguised_face:
Are you already using compression with narsil?
I think the better idea is something like TomE suggested. It comes with a defualt setting of allowing you to override LVP by clicking the button a few times. It stays on for X mines before blinking a warning and going out again. Although the time delay could be debated, maybe a bit longer, say 10 mins?
I think that is a good balance between practical and useful.
I wounder how long the light would work in moon mode once the cells are under 3v and before the MCU shuts down?
Compression? Of what? Unless I'm not understanding, far as I know the code is executed in-place from flash that it's burned in to. I've used code/firmware compression techniques on the job in the past where firmware is stored in flash, but you use a bootloader that fetch's it from flash and loads it into memory, and decompressing it when it does -- that works well, but don't understand how to use compression in this MCU. A con for compression is additional code to implement it, of course, and in some applications, the extra time it takes.
Also used compression for data comm. links, and straight pure data compression methods for storage of course.
And behind the scenes we are working on a nice cheat sheet people can print and fold the right way to stash under the tailcap so the whole configuration method is at hand 
I think thats OK after the standard LVP-Mechanism.
The standard LVP will first step down the modes at 3V and do the next step down if the voltage is again on 3V or lower. In emergency use you can decrease the output to your minimum to have maximum time to save your life.
See Post #2 for reference: Q8, PMS SEND TO THOSE WITH ISSUES BLF soda can light - #2 by The_Miller
I wish to get the indicator LED on the switch. TheMiller wrote he has canceled this LED because of the costs to stay within $40. But I would pay 1 or 2 more dollars for an illuminated switch with indicator LED.
Yes lighted switch, light tunnels those are modding projects.
(A would gladly pay $2 more for X and B for Y and C for Z hence quality mod friendly for each to make it their own perfect light while getting a solid foundation for a good price for all)
Which is cool, but in the IT’S THE END OF THE WORLD AS WE KNOW IT scenario that folks above seem to planning for, you have to take the light apart, find the quick reference in the pitch black, reassemble the light and then you could read the manual on how to enable the mode that you need to read the manual in the first place.
Personally, if I had any fear that I might get in such a situation, I would have multiple redundant lights and spare cells for each on my person. Sooner or later, no matter what you do, the light in your hand is going to go out.
That's why I'd just do the dbl-click thing for an LVP situation - not configurable, it just works, and should be simple and intuitive. Of course it won't work if the light is in electronic lockout of course.
I worded that wrong, I meant to say optimization.
Correct, compression would not work for this.
Ohhh - some optimization, but could be improved. TK was proposing a whole different design method - more table look-up based to track states - probably more space efficient, but major re-design at this point. I gotta lot testing/debugging time in this one.
One area: using "volatile" on variables makes them more safe between interrupt and non-interrupt code, but kills code space - I probably went overboard on it's use.
Thanks for the updated driver and the work Tom E. 
Yeah, loads and stores are 4 bytes each so it adds up fast. Fortunately, you don’t always need volatile and even when you do, you can usually get much of the space back by changing the code. I wouldn’t worry too much about it at this point.
I prefer it like this.
Who prefers the batteries before the life… should use “protected” ones.
Ah, but for those with children or irresponsible adults, how many lights-left-on and dead cells are too many? must you sacrifice performance for safety? It might be more cost effective to carry a satellite “help button” 
I’m sorry, but they are called rechargables for reason. I can’t really afford killing at least $20 worth of cells for couple of lumens of light for a short time. It might come in handy sometimes (I hope it doesn’t), but I can’t see myself overriding LVP anytime but in emergency.
This is by far my favorite thread on BLF right now. Watching this collaboration is so much fun!
I’m on the list for five Q8s at #11, #12, #40, #120, and #121.
Miller, can you put me on the list twice more? That puts me at seven lights.
I love the idea of a double-click for short periods of LVP override, but I hope no one ever needs to use the feature.
Keep up the good work Q-Team and other contributors! :+1:
Could you please add me to the list for 1
Thanks
We are talking about making pretty serious tradeoffs on something that happens once per charge cycle against something that might happen once in a lifetime. If this is something that happens more frequently then you should seriously consider how you use lights.
What trade-offs are you referring to?
I don’t think a time limited LVP override is a trade off, simply an extra feature.