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

When this version first came out I really wanted to like it cause I am all about built in charging these days but it always seemed awkward got me. Idk? It should handle heat a little better with the bigger head and defined cooling fins. It may throw a bit better as well.

This m3 with charging is the stuf thiugh. And a custom pcb that works with the stick switch board is very possible. Makes me want to draw one up but I need to stay focused. I can only relearn one skill per month and a basic python script is taking up all the space. :smiley:

I hadn’t read one word of the gt thread til today as I haven’t been interested. So I just followed enough of your posts to catch on the the tweeted Narsil. That nearly exactly what I am looking for. There are some other things in there but the operation of a throttled ramp with db click to max is right on.

So is there now a way to do this without much trouble? Maybe there is a section of the firmware that I can just copy over to my file or is it more complicated than that?

Well, it's an upgraded version - lots of changes in header file organization, etc.

Bout the U16, I got one recently tore it down, I'll post pics in a min. Here they are:

The problem is very tight vertical space - the vertical board i the pill full height, and of course that big switch. I think we'd have to replace the stock driver and I think a lower profile switch could be used, and a vertical board mounted on the edge near the rubber boot. Maybe then a decent pair of boards could be made up on OSHPark. Maybe we could create a custom horiz. OSHPark board that would work with the stock vertical one, not sure.

Cool pics, thanks. I’ll get my U16 in a couple days still.

I also found out this “new” body style is based on the older JETBeam EC-R16. So not completely new.

Narsil would be sweet in one of these even without the charging.

Looks like i was able to make all the right changes to level_calc.py to get it to run on vers 3. The problem was the case sensitivity as tom pointed out.

In order to generate a ramp table with throttled max i will need to modify Level_calc.py to ask for channel max pwm input frpm the user on each channel. as is, it assumes a value of 255. If i am able to change the pwm max of the fet i think it will generate a ramp with user definable pwm ceiling.

TK, could you direct me if this is a simple/doable change?

I'd look at the line of code: chan.pwm_max = 255

A simple search in the source code for 255. She had a prompt for this value, but commented it out, so at one time at least it was considered.

When I use the NarsilM V1.0 3C1S for Manker U11 quad LED.
Forget to set the temperature control first.
Burned one LED. and then below 350mA can not light.
Small flashlight, poor heat dissipation, perhaps need to limit the current?

ok so i readded the comment to ask for max and then commented out the line that defines it as 255. this generated a table that i think will work. i just needed to change the last 7135 value from 0 to 255. Ill have to test it of course but cant see why it wouldnt work

Looks nice! too bad you have to rip into it. Ya, i would think you would need to set the thermal reg pretty aggressive with that set up. I have a u11 kit ready to go. only problem is i dont have a u11 to put it in. :slight_smile:

It should be very difficult to burn up a typical LED when mounted on a copper MCPCB. If they were low Vf LED's like XP-G3 or 219C's, then the risk is higher, but you have other things that can be done easy - use thinner LED wires, don't bypass the spring, use a lower performing cell, etc.

I used thermal grease on the contact points where that pill comes into contact with the housing - think it helps. But quads in a U11? Oh boy, not really made for that kind of heat - that pill design is pretty poor. I got a single XP-L2 NW in mine and love it though - it's my favorite 18650 EDC light.

Sounds like the 7135 is fried maybe...

Well i posted too soon. it works with 2 channels, but not 3.

Did you specify 3 channels in the header? Located the tables at the right place for 3 channels?

You mean the first entry in the string or somewhere in the code?

Just to be clear the script works with three channels as is but the code I modified is only working with an entry if 2 channels.

Or, I say working but I don’t know if the generated ramp is smooth or not

You are using setups-31S.h, right? Then in RampingTables.h, it has to be under the banner:

//---------------------------------------------------------------------------------------
//---------------------------------------------------------------------------------------
#elif OUT_CHANNELS == 3    // Triple Channel
//---------------------------------------------------------------------------------------
//---------------------------------------------------------------------------------------

And under 3 channels, there are two separate tables, depending on what compile switch is set, TRIPLE_3_7135 or TRIPLE_8_7135.

So, you have to have everything set up properly in the "Setups" header file you are using.

I am probably assuming wayy too much knowledge to do all this setup and configurations, but what you are trying to do is pretty advanced customization, and I did build in a lot of provisions for customizing things withkeeping the main source code in tact.

Just finished all the bug fixes and couple features/enhancements for the next release. I need to get more testing in on it, but so far all the changes tested ok.

Of course it's not everything I wanted to get in, but running out of time at this point. Here's a brief list:

  • ADDED : (from MAD777, maybe others) if strobes are disabled, a 2X click from 2X turbo should restore the previous level you were at
  • FIXED: 4X clicks in modes operation engages lockout - not supposed to
  • ADDED: operation change: make click&hold in MODES or STROBES wrap from 1st mode to last
  • FIXED: in LVP switch LED control: the LED sometimes is left on after an LVP drop, and is not blinking the way it should be. The "bug" is that I'm trying to control the switch LEDs from multiple places so it's getting turned off quickly after turned on, and left on when it should be left off. It's a timing thing, so has sort of a random pattern - sometimes left on, sometimes left off. The 8 sec LVP blink need to be qualified better, and should not be calling Setlevel() as is because it wants to control the LED
  • FIXED: temp stepdown should not happen right away from turn ON. Delay it by 15 seconds
  • FIXED: for temperature stepdown, in moon mode, a temp stepdown is actually done because moon mode is marked as special level 255, which is considered as a high level of output instead of very low. The stepdown results in the light switching much brighter. This should only happen id the temperature threshold is set to a low temp, or the light is still hot and not cooled down when moon mode is chosen. It can also result in an immediate jump to the stepdown level as soon as the light is turned on in moon mode. Might appear as a bright flash when ramping first starts.

There's more previously implemented:

  • ADDED: momentary/tactical mode via 5X clicks - only active til a power reset 2X or 5X clicks exit tactical mode (full turbo only when switch is held down)
  • full BLF GT buck driver support
  • capability of setting max ramping to less than full max FET (Hi mode), while the 2X click still goes to full FET turbo. This is being used for the GT buck driver configuration.
  • added more compile switches, little better custom configuration of the source in header files

Nice work Tom. :+1:

Yeah, great job!

Excellent!

Wow, once you drill out the driver screw holes and put decent screws in there, extend the LED wires to 67-70 mm, the Q8 is one of, maybe the easiest light around to upgrade firmware with. I find it easier and quicker than even driver retaining rings.

The 2nd round production Q8's should be easier with the screws, but looks like they shortened the LED wires in some, maybe all, so I haven't tried one of those yet.