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.
Hhmm. I get this quite often - usually a bad clip engagement. Sometimes cleaning the MCU pins and clip pins with isop. alcohol does the trick.
Hmm? That weird. I soldered leads to each leg of the MCU straight to my programmer. It worked the first time but not the second and I had left the leads soldered on as I anticipated reflashing a couple times. Huh. I’m starting over anyway.
I still didn’t get the double click to turbo working. I can get the top of the ramp reduced but then a double click only goes up about 300ma or so. Do you have that option working on any light yet?
Thanks Tom! I wish We had a way for you to share the tech support load! I’ve been thinking of some ideas but don’t know if anyone would engage or not. Anyway if you coule just answer the do you have the “reduced ramp with 2x click to turbo working for sure” question, that would be helpful.
It works well on the BLF GT, actually, I think - pretty sure. Hhmm, I had to test it out somehow without having a GT buck driver light though, so tested on something - think a 2 or 3 channel test light. Ohh, trying to recall, think I modded up a header file to use only the first 130 or so levels of the 150, then 2X click went max, and ramping stopped at the 130 level.
Maybe you can send me your files you changed, or ZIP up the whole project? Probably be easy for me to find a problem.
Very generous of you! PM sent with a link to my zipped project 
Tom, in v1.2, what should I edit if I want a faster response for double clicks to turbo? It seems like double clicks to turbo has a bit slower (pauses at memorized level about half a second). compare to v1.0
Thanks.
Yes, intentionally so. I've answered this question before but dunno where. It's not as long as 1/2 sec, it's definitely quicker.
If I didn't delay it, when you do a 3X, 4X or 5X click, you would get flashed with max/turbo every time. I did not want to delay the 1 click operations, so decided to start it at 2X since the flash of max/turbo is annoying.
From what I can tell, the delay is 0.288 seconds, as defined below. If you change it to be less, you will make the multi clicks tighter timed and might get difficult:
# define SHORT_CLICK_DUR 18 // Short click max duration - for 0.288 secs
Thanks Tom :+1:
This is now updated in the repository.
Thanx TK! 
Does narsilm without voltage dividers require the 85v 10Mhz?
Yes, at least two of us have implemented it now, and there is some code for it in the repository. It’s included in the Emisar lights, Crescendo, and the FSM toolkit… and I’ve been dragging my feet about patching something into Narsil.
While not PID, Narsil already has thermal step-down. It was tuned for the Q8, but didn’t respond fast enough for use on a D4 (much smaller, similar power level). This is what I measured on a D4v1 light (which was way too hot from about 30s to 4m):
Yeah… these things take an inordinate amount of time to test, and I’ve found it tends to be really sensitive to small changes.
I tested a DrJones H17F driver’s thermal response recently, and it looks like his solution was to make the regulation response relatively slow and gradual. In my test, it took almost 8 minutes to reach a stable state… which was fine on the heavy copper host I used, but would be way too slow for something like an Emisar D4. However, it was very smooth and had no significant oscillations or noise. It merely stepped down one PWM level at a time, one channel at a time, until it was no longer overheating. And when ice was held against it afterward, it stepped back up just as slowly. I wouldn’t really say it’s a PID algorithm though, since it didn’t act like one. The I term seemed to be zero, I couldn’t tell if there was a D term or not, and if there was a P term it seemed to have only two states — two steps per second, or one step per second.
My attempts to make a more responsive PID regulator have been less than ideal. It works, but I’m not totally happy with it. After reaching a stable state, it’s still more noise-sensitive than I’d like, and occasionally I’ve measured rather undesirable behavior like oscillations. The response is proportional though, and fairly heavy on the derivative term so it can anticipate and “steer into” the turns, but I’ve mostly only used the integral parts as a way to reduce noise. And, as already mentioned, it’s still not at a point where I’m happy with it. Sensor readings are low-resolution and noisy and subject to thermal lag due to having the sensor in the MCU, and my attempts to deal with the lag have made it even more noise-sensitive.
Here’s FSM’s behavior compared to a H17F:
So… long story short: Yes, but it’s still a work in progress.
No, the "85V" version is not necessary.
Does double click to turbo go to turbo in mode sets as well as ramping?
I was able to get narsilm with throttle control working in ramping configuration so i assumed it was working in mode sets. However, today i was testing out the rest of the options and realized the 2x click in mode sets is not working for me. two clicks simply advances the out put two levels. Is this just me or is this the way it works?
I have the ramping mode stopping at 2amps for normal operation of the M3 clone. then a 2x click and “BAM!” IN YOUR FACE 7amp Max turbo. I like it! 
No, I don’t think you can jump to turbo while in mode sets.