NarsilM - configurable e-switch firmware for Multi channels, v1.3

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. :slight_smile:

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… :wink:

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.

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.

@LightRider:
You might have set wrong fuse on last programming.

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 :slight_smile:

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.