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

What I mean is
The lamp is off: I click 5x and I am in tactical mode.

The lamp is switched on: I click 5x and I am in tactical mode.

Yes lamp is the main LEDs

"%x" must be a typo - as said in other places, it's "5X" clicks.

No bout the super fast morse code currently.

I see I'll have to remove the 2X clicks to exit tactical mode - way too easy to inadvertently hit, but the 5X is not as easy to trip up on. Dunno - maybe I could just remove the 5X click method to exit, then yes, it would work like Andúril then - power cycle to exit.

If this is preferred, it's basically removing code - easy to do.

Ok, understand now -- Yes, you can enter tactical mode via 5X clicks when the main LEDs are ON or OFF.

Also the 4X click lockout works with the main LEDs ON or OFF, as does 3X and 2X clicks.

Looks like there are two ramp table .h files. One for high performance lights(high power/output) and one for standard. No ramp tables for three channels in HP but three channels has ramp tables in the standard file. To throttle back the ramp ceiling looks like I would just chance ramp_size to less than 150?

Will there be troubles anywhere else if I change the rampsize to 200? I know I would have to make a number of changes to the start levels and also I will need to generate a new ramp table but other than that, looks like no other changes need to be made?

Oh, what sets the output value of the 2x click turbo? Is it hard coded to pwm 255 or is in codes to ramp max?

To clarify: what I’m thinking on doing is generating a ramp table to 225 levels using level_calc.py and then setting ramp_size to 200 or so. Then I would have a longer ramp time, ramp max level less than turbo, and turbo via 2x clicks? Is this correct? Sorry, lots of questions…

Yes - that should all work. The high performance files are for lights like the 27K lumens MT03 or 37K 18 XHP50 lights, so yes - don't use them.

Nowadays, 6K or 12K lumen lights are common -- go figure.

TK mentioned a limit above, forgot what the limit # was, and not sure where the limit is imposed - maybe in the Python script?

In your setups file, you need to have this set:

#define TURBO_LEVEL_SUPPORT // set if you want a max turbo level above the max ramping level

Then in the ramping tables file, you need to set RAMP_SIZE to 200, and generate the table for 225. So the last entry at 225 should be 0 for the 7135, 255 for the FET. You can delete all the points after 200 since they won't be used -- this will free up some space.

It's also important to set these in the ramping tables file:

#define FET_START_LVL 68

#define TIMED_STEPDOWN_MIN 115 // min level in ramping the timed stepdown will engage,
// level 115 = 110 PWM, this is ~43% (for 350's)
#define TIMED_STEPDOWN_SET 102 // the level timed stepdown will set,
// level 102 = 72 PWM, this is ~32% (for 350's)

I did everything you listed besides Define turbo level support and change the last entry to 0.
And I got the error messages below. So I’ll give it another try later tonight and do as you describe as I’m not at my pc now.

Actually, I am unsure about where to put the “0”. My 190th(I used 190 instead of 200) entry is 255,255,90. I also set all the last entries in mode sets to the same 255,255,90.

Do I need to have the 190th ramp level use only the fet? I would have to guess where it would mesh with the ramp. Probably around 145? Anyway, I need to try what you have said and see if my error messages go bye bye.

That should be defined in ModeSets.h:

// Common Output Settings:
#ifdef GT_BUCK
#define MAX_BRIGHTNESS 255,255 // for GT-buck
#define MAX_7135 255,25 // for GT-buck, about 117 mA
#define BLINK_BRIGHTNESS 100,25 // for GT-buck, about 50 mA
#define CLICK_BRIGHTNESS 50,25 // for GT-buck, about 25 mA
#define OFF_OUTPUT 0,0
#else
// output to use for blinks on battery check mode
// Use 20,0 for a single-channel driver or 40,0 for a two-channel driver
#define MAX_BRIGHTNESS 0,255
#define MAX_7135 255,0
#define BLINK_BRIGHTNESS 40,0
#define CLICK_BRIGHTNESS 20,0
#define OFF_OUTPUT 0,0
#endif

Ok. I’m sure there is a value there so that means I probably need to check my file path’s

I'm taking down the NarsilM v1.2 files - need to fix the tactical mode to ignore all fast multi-clicks: 2X thru 5X clicks. I'll post an update in a few mins hopefully.

:person_facepalming: I just managed to build a .hex file with my changes. let me know which files will need to be updated. :slight_smile:

Tom
please edit the typo in

from %X to 5X

This

is an option for compiling?

This [quote]

ADDED : (from MAD777, maybe others) if strobes are disabled, a 2X click from 2X turbo should restore the previous level you were at
[/quote]
does not replace the old: 1X for OFF and 1X for ON. It’s a second way to do it, when strobes are disabled?

Yes, max ramping is compiling option.

1x on and 1x off has not changed. If the user double clicks to get to turbo, this is saying he can 2x clicks to get back to the mode that was switched from.

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

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

  • And for max 7135 there are runtime numbers.
    Thorfire says: 44h @160lm (and I assume with 3500mAh batteries) so with 3000mAh it should be 38h.

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.

  • Brightness should be over 1000lm to 2000lm
    The 32 percent from timed stepdown would be also OK.

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).