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. 
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.
Definitely possible.
Yes it’s the clone. If I can finally get the code figured out it will be a three channels with 3 7135s on channel 2 and fet on channel three. The mode sets and max ramp will hopefully be throttled back to about 2.5-3amps while preserving direct drive for the double click to high option. I think max ramp/modes is separate from max double click. Atleast I’m hoping it is:)
It’s been hard to choose what direction to go hardware wise but I think I have all the geometry figured out now. Actuall won’t be that bad but will require some intricate wiring.
Ohh - you want ramping throttled but 2X click still max FET? That's exactly what we are doing in the GT, so the new NarsilM supports it -- hhmm, not yet posted I think.
Just a heads up, the M3 has been updated with built in charging and is called the U16. The head is a little bigger, I assume because of the usb input, then again, the $13 clone (JAXMNVE M3) was able to fit a USB port in the old size body. Maybe this new model host body has more internal room for a good switch?
.
Yes, exactly. If max level is defined separately somewhere it should be doable but if max ramp and max double click are the same define then it’s going to be over my head for sure:)
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. 