Here's the latest NarsilM v1.2 files: https://drive.google.com NarsilM v1.2
You will find a readme.txt file listing the .HEX pre-configured files there.
The tactical mode is now invoked only from ramping from a fast 5X click with the main LED(s) ON or OFF. It can only be disabled from a power cycle. It is very quick, very responsive, and very fast clicks can be used even for a manual strobe.
There's still no updated manual. I still consider it a BETA release for testing.
Thanks Lightrider for your answers.
Nice Tom,
I hope someone can make use of it.
(I allways thougt the tactical mode for the BLF GT is when you use it as a mace)
So, lets figure out what to add for 6x clicks.
Maybe a staged ramp?
You enable two stops in RAMPING at ca.150lm and 1500lm with 6x.
So when you ramp with the main LED off:
Moon -> ramps up -> stops at 150lm-> you have to click&hold again -> stops at 1500lm -> you must click&hold again -> stop a max. brightness.
Backwards also two stops.
If you want get rid of this mode: 6x clicks and you are in normal ramping.
The two stops can be set while compiling.
BLF gt tactical use is under baseball bat mode. 
Just NarsilM.c
I'm assuming the 150 lumens stop is the max 7135 setting, but 1500? Well, 1500 lumens is different in many lights, it's light specific. I got 1200, 1800, 6000, 10000, 25000, 37000 lumens lights running NarsilM, plus many more. I could use a specific PWM value representing a percentage of max.
Could be done that way, or could simply pause the ramping for a moment, allowing the user to stop there - similar to what is done for moon mode when ramping up from OFF.
I've been looking for a decent UI method to get to the max 7135 setting while in ramping. Of course the 150 lumens varies - it's more like 180 lumens in some multi-led lights.
Tom, it is not about a certain lumen number.
It is about useful levels for a certain lamp.
The first lower stop
- that is sth usefull in a small room
it can range from 25lm to 150lm
- it can be the max 7135 level but not necessarily
- I like it because it is also enough light for me outside and its the only point in the ramp I can find.
- Two users asked me if NarsilM has a shortcut to max 7135 like the Emisar v2
The second stop
- is some useful without getting the lamp to hot.
- it is to light up a room in tailstand. With hours of runtime. So room temperature 20 degree Celsius and you can always touch the lamp without burning you.
- that is if you had to work in an shed without electricity or power out and you had to light up the kitchen.
- I think djozz run a proto 4h with 2000lm in tailstand. So from that I can do estimations about runtime.
I guess I don’t like pauses.
I think it should stop and flicker (like when reaching end of the ramp) or stutter (like bike strobe <- this can be the sign for the user he is using the stops) in order not to press the button 9sec which would you lead to settings.
I can overshoot them, and it’s a timing thing, you had to watch the lamp.
Narsil has already a lot of things which are time sensitive. We had quite a few people to tell “click that command faster” or “try harder with other pauses”.
And I want to switch the stops on and off via a shortcut not via settings.
So if I want light from the first stop and the lamp is in normal RAMPING I do
6x clicks and a click&hold till it stops ramping.
I don’t know if people would like these stops.
If the user don’t want the stops anymore click 6x again.
So somebody can argue you get sth. similar to MODES, but you keep the UI from RAMPING, all shortcuts are there. You can reach: Moon, memorized level, stop1, stop2 and MAXIMUM/TURBO.
And you can ramp.
If the user wants to change stop1 and stop2 he had to edit the code.
Oh boy, don't have time to read this all right now, but I do agree - this is a potential nice feature! Liek I said I always wanted to integrate something into ramping where you can get to the full 7135 (~150 lumens), and the other possible steps of say 25% or 50% would be useful as well.
For the stops and timing issues, yes - agree it's challenging for some. Hoping I can find time to consider it all.
I’m new to the programming side of flashlights, but do some industrial automation for a living. I’m curious, has a PID loop ever been considered for Turbo/high settings for flashlights like the Q8 or GT? Is it an issue of enough storage space to hold the bits or enough processing power? Thanks for any insight!
PID for temp regulation? Yes, it's been done in flashlights. Not as simple as grabbing an algorithm, little copy&paste, though. Dr Jones has a PID in some of his drivers, and I believe TK more recently developed one in her latest e-switch driver -- not sure though.
For one thing, a better qual external temp sensor would be wayy better than using the ATtiny internal one, then you need to do either a lot of tweaking, or modeling/measuring the thermal dynamics of the system, and decide an an approach of ranging, frequency of updates, etc.
Dr Jones did this a few years back, and he's very good and took him a lot of time to develop and test, then I hear it's still not great.
Really the only reason I haven't pursued it is time and priorities. Though I'd rather pursue a better MCU with more I/O pins first, then leverage the extra code space and I/O pins for a PID using external temp sensor (or 2 sensors).
The Emisar lamps with the v2 UI has to my knowledge two D-parts in seriel.
The problem is the thermic loop is f… slow and the sensor is in the µC.
You should really ask Toykeeper (often TK for short) in the Emisar D4 thread about this. She had a few simulations running to get the settings right. It should be on the first 40 pages, I guess. 
What other companies like Nitecore do when they print thermal regulation on the box, I really don’t know.
Interesting. I wonder if they are slow because the PID isn’t optimally tuned. For instance, if the p-gain is set overly conservative (low) the changes will be very small and might take awhile for any change to be noticed. I would think there would be enough space in the GT for an external sensor. Something to think about in my spare time for sure.
I saw some Zebralights advertise some sort of PID. I wonder how they have it implemented.
Thanks guys!
Well the big problem is availability of I/O pins. If the GT doesn't use a switch LED, then one pin would be available. For the Q8, 1 pin, a different pin, is available because it doesn't use an external voltage divider. Many lights I use NarsilM on though don't have an available pin, in fact they fall 1 pin short of what I'd like to use. The Q8 uses 2 output channels, and the GT buck driver needs 2 I/O pins to control the output circuit, but a triple channel driver eats up 3 I/O pins just for the main LED(s), and total of 5 I/O pins, it's not good.
I can’t report how its implemented because I don’t know, but I can say that it works incredibly well in those lights, better than any other thermal regulation that I’ve experienced. It responds very quickly to both rises and drops in temp. You can tailstand a Zebra on turbo and as it warms up you’ll start to notice very very faint step-downs, the sort of thing you won’t even really see unless you’re watching for it. Then after a few minutes when its good and hot, add some sort of cooling (even just grabbing it with your hand), and watch it reverse, stepping back up in very faint steps. Its cool to watch happening.
But then those lights also have tightly regulated boost drivers and other more advanced features than most of the lights on the market. They’re really smart lights…with a very divisive UI that some folks love and some hate. Someone should port NarsilM to one of their drivers. I’d flash all of mine. 
Definite advantages to smart buck/boost drivers, which also explains why they cost more. Usually of course they will have limited output because it's hard or expensive to do high amps with those designs. For us, it's a huge EE design project, and then we would also have issues with real estate and parts count, probably have to drop to 0402 size parts, then it gets more and more challenging to use the cheap PCB fab houses like OSHPark, and be able to reflow the boards ourselves. When you are planning on full manufacturing, you got a lot more options.
Ideally you want a smart buck/boost combo, then a separate output channel for a high amp direct FET -- best of both!
Not your grandfather’s flashlight to say the least…
I flashed my version of narsilm and was unsuccessful at creating a ramp ceiling less than max turbo. My ramp table is configured for 225 levels and is set to “#define RAMP_SIZE 190”
In the main .c file the code looks like this:
#define MAX_RAMP LEVEL (RAMP_SIZE)
#ifdef TURBO_LEVEL_SUPPORT
#define TURBO_LEVEL (MAX_RAMP LEVEL+1)
#else
#define TURBO_LEVEL (MAX_RAMP LEVEL)
#endif
So I’m my case turbo level would be 190+1 or 191
Level 191 is not max output so how does this set turbo to level 225 or 255pwm?
Should I just change define turbo level to something like:
define TURBO_LEVEL (225)
I guess I just don’t get the +1 in the define?
Everything else seems to be working. One weird action is when I do a click-clickhold-click the main led and the indicator shut off?
Oh, I should note that the output is reduced. Using my test led it sets a max at about 2amps. However a 2x click goes to about the same level. Maybe a few ma more which makes me think it is just going to the next ramp level of 191 on gone ramp table.
I decided to just give some things a try. However I was unable to successfully reflag the MCU.
I kept getting this error:
avrdude verification error first mismatch at byte 0x0000
0x00 != 0xa0
content mismatch
I disconnected some parts of the circuit as I added the led and switch board sinse the first flash and then retried three or four times. Now the MCU is not responding to any command. :cry:
I think I may have to give up on this one for a while. It’s been trouble the whole way. Idk? If anyone has suggestions I’ll give them a try but I may need to start over if I’m gojng to make this one happen. Oh well…
If I wanted to flash this to the BLF GT driver is it the same process/setup/hardware as doing the regular stuff to tiny13 micros? Or are any hardware/software changes needed (besides selecting the tiny85 micro)?
VOB people got pointed to the “how to flash AT13 topic” when asking hiw to flash AT85 and when Tom send me then list of things I needed I think it was the same as for 13.
Tom, from the Q8 thread
How about an extra setting for side switch led where people can set brightness?
*
Oh boy, hard to keep up here.
For the 85 in on the GT or Q8 drivers, yes - same ol process as we use for 13's, but of course, specific to the 85. For th AVRDude commands, you must specify the MCU, for example:
This dnld's the firmware:
rem 85NarsilM - downloads NarsilM (Tiny85 Multi-channel e-switch UI configurable)
rem
avrdude -p attiny85 -c usbasp -u -Uflash:w:\Tiny254585Projects\NarsilMulti\Release\NarsilM%1.hex:a
This sets the fuses:
REM BOD enabled at 1.8V:
avrdude -p t85 -c usbasp -Ulfuse:w:0xe2:m -Uhfuse:w:0xde:m -Uefuse:w:0xff:m
So using "attiny85" or "t85" says it's an ATtiny85 MCU. For 13, 25, 45 -- same thing.