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

Also, I have anew feature request.
It would be nice if the user could select between volts/tenths battcheck and 1-10 batt level via the setups file.

Just a thought. Would be nice for me, but I may be alone. Idk?

Thanks for your work Tom!

Oh yes. I also can’t find where to define the type of 7135 used. I see it referenced to in the code but can’t find where the value is set. Maybe it is a sub setting of a larger setting group defined?

Anyone have any ideas how to throttle these drivers?

Eh… no one? I guess I’ll start trying to scale the ramping tables by guessing at perceived percentages. Might take a while but I guess it should work. Atleast I’m racking up post count by conversing with myself. :stuck_out_tongue:

Ohh - sorry. Well. Have you though bout added resistance? Use 26/28 AWG long LED wires for example?

Sure you can rebuild the ramping table easy enough by running the Python script, tweaked to your needs, and redefine all the mode sets. In the source code I include the full python script options I used to build the tables (several). It's TK's pythons script: level_calc.py, in her repository.

// For FET+1: FET and one 350 mA 7135 (tested/verified to be smooth):
// level_calc.py 2 150 7135 3 0.3 150 FET 1 1 1500
PROGMEM const byte ramp_7135[] = {
3,3,3,4,4,4,5,5, 6,6,7,8,9,10,11,12,
13,14,15,17,18,20,22,24, 26,28,30,33,35,38,41,44,
47,51,54,58,62,66,70,74, 79,83,88,93,99,104,110,116,
122,128,135,142,149,156,164,172, 180,188,196,205,214,223,233,243, // 49-64
253,255,255,255,255,255,255,255, 255,255,255,255,255,255,255,255,
255,255,255,255,255,255,255,255, 255,255,255,255,255,255,255,255,
255,255,255,255,255,255,255,255, 255,255,255,255,255,255,255,255,
255,255,255,255,255,255,255,255, 255,255,255,255,255,255,255,255,
255,255,255,255,255,255,255,255, 255,255,255,255,255,255,255,255,
255,255,255,255,255,0 // 145-150
};

PROGMEM const byte ramp_FET[] = {
0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, // 49-64
0,2,3,4,5,7,8,9, 11,12,14,15,17,18,20,22,
23,25,27,29,30,32,34,36, 38,40,42,44,47,49,51,53,
56,58,60,63,66,68,71,73, 76,79,82,85,87,90,93,96, // 97-112
100,103,106,109,113,116,119,123, 126,130,134,137,141,145,149,153, // 113-128
157,161,165,169,173,178,182,186, 191,196,200,205,210,214,219,224, // 129-144
229,234,239,244,250,255 // 145-150
};

btw, DEL uses his own equation, think it's cube root, forgot. Think he gave me the Excel spreadsheet he used to implement it. Works well - the GT buck driver/NarsilM is using it.

TK's though supports multiple channels, don't think DEL's does because it didn't have to, not sure of this though...

Ok. Thanks friend. I’ll look into what that py script means.

I tried just cutting the tables short but seems there is more to it than that.
I’m also trying to figure out how to slow the ramp speed down a bit but haven’t succeeded there either.

I’ll just keep trying things. How else will I learn right? But if another week goes by, I may need to ask for some more help. I’m patient but maybe sometimes, not really. :slight_smile:

If your on a Win platform, then you need to dnld Python runtime support - not sure what I used.

Here she has ramp_calc.py - think its the same: http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper/Ferrero_Rocher/

To extend the time, that gets a little more involved, but do-able. I'm using 150 levels with a 16 msec clock, so it takes: 2.4 seconds. If you want to extend the time to 3.6 secs, then you need 225 levels to keep the code the same. There's other setting in the RampingTables.h file that need to be tweaked, but I think everything is there that you would need to tweak. Of course 225 levels takes up more RAM, but hopefully should be enough spare space.

Ooops, no. Here's level_calc_py: http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/bin/

LightRider, subtle timing changes require changing the size of the ramp array to change how many frames it takes. Larger timing changes involve modifying the number of frames per ramp step. The maximum ramp length is somewhere around 240, IIRC, depending on how many special modes are defined above that and how much ROM space is available.

is there a description of how to use level.calc.py anywhere? im guessing its common knowledge that im missing. Actually ive already done this once before on my system so i know its setup ok i just cant remember what i did. its very frustrating! Im too disappointed in myself to continue tonight so good nite. :rage:

Either copy/paste the command line from Narsil’s header files, or run level_calc.py by itself and follow the prompts.

Spent the whole day getting python to run and then chasing errors in the script. Now it’s obviously not working correctly but I have no more errors to guide me and since I don’t know how it’s suppose to work I can’t track what is wrong. Anyway, if anyone else has figured this out and has run level_calc.py on Windows please give me some tips!

This is what it does when I use toms example numbers above. Most of the errors corrected so far have been syntax errors related to using python 3 over 2.

Wonder if it's case sensitive - code checks for "FET"...

Yours looks quite strange - it generated values over 255, weird. I've done a lot of them, experimenting, etc. This is one example below. I always use .BAT files so i can capture the exact command line options:

rem for FET+1, 124 levels 4X LED's
level_calc.py 2 124 7135 3 0.3 160 FET 1 10 5000

PWM1 values: 3,3,4,4,5,6,8,9,11,13,15,18,21,25,28,33,37,43,48,55,61,69,77,85,94,
104,115,126,138,151,164,178,193,209,226,243,255,255,255,255,255,255,255,255,255,
255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,
255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,
255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,
255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,0
PWM2 values: 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
,0,0,1,1,2,3,3,4,5,6,7,8,9,10,11,12,13,14,15,17,18,19,21,22,23,25,27,28,30,31,33
,35,37,39,41,43,45,47,49,52,54,56,59,61,64,66,69,72,75,78,80,83,87,90,93,96,100,
103,107,110,114,117,121,125,129,133,137,141,146,150,154,159,164,168,173,178,183,
188,193,198,203,209,214,220,225,231,237,243,249,255

What exactly do you want to generate? Maybe I can help? Is it for a Q8? What's the estimate on max lumens, if it's modded?

Yep - just proved it -- it's case sensitive - must specify FET in all caps. I got the same results as you when using "fet".

It’s probably worth mentioning that python 2 and python 3 are different languages, not simply a version bump. Python2 scripts require python 2 to run correctly, and Python3 scripts require python 3 to run correctly.

However, scripts can often be written to support both 2.7 and 3.X… and I just pushed up a new trunk revision which does so. It also checks to make sure each channel is a recognized type, to avoid the huge values it was generating.

Ok. Thank you both. Tom, I’ll give the new file a try. I did not know 2&3 were different!

I’m using it to generate a throttled back ramp with double click to full power for the m3 clone. Anyway, I’ll report back. Thank much

You mean the $13 On The Road M3 clone. Tom E put Narsil on his genuine M3. We were talking about a future blf project using the the M3 clone with Narsil.

ToyKeeper has Anduril which might already do what you want. I don’t know much about it, though.

I've been using Python 3.6, but not sure if I had to change anything to get it to compile - I don't think so but not sure. It was an easy dnld - don't recall from where. It's got an "Idle" dev environment tool with it.

That OTR M3 is an awesome light to put Narsil on. I’m hoping that someday we can make a BLF clone of the Olight S-Mini with one of our custom drivers. It’s like the OTR M3 but even smaller, and getting it to run a BLF driver with fancy e-switch firmware would make it one of the best EDC lights ever made.

Yea, the Olight Mini was the light I really wanted to mod to install it on - I got one or two and was able to open it, but can't recall the challenges. Now we have a few guys capable of laying out an OSHPark board, so we have more resources. Of course if we want to go with a custom big run, we would have more options.

The switch mounts usually is what messes up space and real estate, but there's been some real creative modding posted here, and I've learned a lot more possibilities to handle the switch since 1-2 years ago.