Got the final open issues for ramping done and pretty much tested now. I have the new Narsil installed in 3 lights:
The timing for one full ramp was taking about 3.6 secs, so I reduced it now to ~2.8-3.0 secs, and looks much smoother now with no noticeable flicker. I increased the # of steps to 142 (was 64 steps).
I admire your skills Tom. It all sounds exciting.
Hi, sorry, I’ve been avoiding this thread until I had a day free. I’ll just put all my replies into one, for now:
No, it’s not expected to work correctly on smaller higher-powered lights. The code is configured for the BLF X5/X6 project. If you want to use it on something higher-powered in a host with less heat capacity, you’ll need to modify the code accordingly. The thermal code is pretty bad though, so don’t be surprised if it does weird things like bouncing back and forth across the place where it should settle.
Running it at 4MHz, you’ll probably need to change significantly more details to make it work correctly. Everything will run half as fast, including thermal regulation, blinky modes, ramp-up, etc. And you’ll likely get an audible whine on most of the output levels. You can fix a lot of the timing by cutting “BOGOMIPS” in half though.
Sorry, I’ve really procrastinated about that. I know better methods are possible, but I haven’t done it because I’ve been a bit overloaded lately. Also, thermal regulation is kind of a pain in the ass to test.
It can be pretty frustrating at times.
Wait, does your ramp automatically reverse at the end? It’s much more common to stop at the end, or at least stop temporarily before turning around. I personally prefer to just stop at each end instead of ping-ponging.
Er, nevermind. Just read your next post. It was turning off, not reversing, and you fixed it. 
I’m looking forward to trying this.
What about this instead?
“Hold” ramps in the same direction as it was ramping before, unless you release and hold again within 1 second, in which case the ramping direction will reverse. This way you can turn around quickly and easily to get to exactly the desired level, without having to go all the way up or all the way down first.
My Ferrero Rocher UI does that sometimes, and I consider it a bug. Holding from off should probably go to moon and stay there, requiring a release-and-hold-again to ramp up. I haven’t fixed it yet because I ran out of space, but was planning to fix it next time I mess with ramping.
I had the same happen on my first clip. I had some pins push back / recess themselves a few times before that, and was always able to pull them back out… but the sprung-out pin was harder to fix. It’s working again now, but it motivated me to buy a couple extra clips.
Those are two of the reasons why I made everything in bistro use the ramp instead of doing it with mode group levels like STAR or BLF-A6. It was kind of a pain refactoring everything, but afterward it made a lot of things easier.
Agreed, I don’t see much point using FAST on a 25/45/85. It would run at 31 kHz, which is faster than needed to avoid being audible, and fast enough to reduce PWM stability on low modes. Slower PWM is more stable and more consistent.
I’ve been using PHASE for moon mode even on tiny13, to make it less voltage-sensitive, but on the 25/45/85 it can use PHASE for everything. It’s nice.
I’m curious. Why 142 exactly?
Also, did you have to manually tweak the values at the point where the FET kicks in, and at the highest few modes? If I use the values my ramp calculator produces, I get less-smooth results at those two points. So I’ve been meaning to at least fade the 7135 out at the top instead of going directly from 255 to 0, to reduce the brightness “pop” between the two highest modes. Not sure exactly how to smooth out the channel transition in the middle though.
It sure is a PIA - haven't gotten to it myself yet, but looks like I'm gonna have to.
Yes, stops at max, but when at max, a hold will reverse ramp (hi->lo) and stop at moon.
Yes, I saw your post or two recommending this - I copy/pasted in my notes. I really want to implement it that way, but I'm being accused of having too complex UI's as it is, so not sure if it complicates things or not... Still undecided, but I like it
OK, this one is on me. I totally mis-understood what you wrote up here: https://budgetlightforum.com/t/-/72707/19, and also blueb8llz wrote up here: https://budgetlightforum.com/t/-/72707/10. Both of you were describing it the same way, and mis-understood it both times. I'll have to consider this, maybe work it in sooner rather than later. It kind of changes things though, and will be more likely to get crossed up with my current quick click-hold to display battery status, so may have to change that.
Same here. I always keep a full spare handy now.
142 is just how it turned out. I used the 64 levels, but bumped only 1/3 WDT's to get about 3 secs. Problem was a noticeable flicker, and also thought the 3 secs (actual ~3.5 secs) was too long, so I took the frist 29 levels on the 7135, multipled by 2.5, and the remaining levels by 2, so:
29*2.5 + 35*2 = 72.5 (72 used)
I filled in all the in-betweens with mid-points, etc. to get it somewhat balanced, and looks real smooth now. I did notice the lack of an overlap between the 7135 and FET levels, which I thought odd since you overlapped the A6 levels. Hard to say there's a noticeable jump, or anything.
142 should take ~2.3 secs, but I'm finding it seems to really take 2.8-3.1 secs, and I dunno why. The WDT should be 16 msecs, but seems to actually take longer in this case, but I'm not really understanding that. There's something goin on I can't track down maybe, or the 16 msecs is not as accurate as I thought.
As with everything else I mentioned, it’s just my personal preference. I like being able to reverse without going all the way to the end first.
It’s really a matter of what you want it to do… I don’t see why it would interfere with “click, hold”, but I haven’t looked much at the code either. It basically just needs to set the ramping direction to “down” when it came from an “off” state, so it wont ramp up.
Oh, okay. I didn’t think about the timing.
You filled it all in by hand? There’s a tool to generate those numbers.
I just updated the ramp calculator today, so it’ll handle any number of channels:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/tiny25/view/head:/bin/level_calc.py
Here’s how I’d invoke it for 142 levels on a FET+1 quad XP-L:
> ./level_calc.py 2 142 7135 3 0.3 140 FET 1 10 4000
1: visually 0.67 (0.30 lm): 3.00/255, 0.00/255
2: visually 0.78 (0.47 lm): 3.31/255, 0.00/255
3: visually 0.89 (0.69 lm): 3.71/255, 0.00/255
...
42: visually 5.09 (131.92 lm): 240.43/255, 0.00/255
43: visually 5.20 (140.48 lm): 255.00/255, 0.37/255
44: visually 5.31 (149.41 lm): 255.00/255, 0.96/255
45: visually 5.41 (158.70 lm): 255.00/255, 1.57/255
...
140: visually 15.66 (3839.17 lm): 255.00/255, 244.39/255
141: visually 15.77 (3919.04 lm): 255.00/255, 249.66/255
142: visually 15.87 (4000.00 lm): 0.00/255, 255.00/255
PWM1 values: 3,3,4,4,5,6,7,8,9,10,12,14,16,18,21,24,27,31,35,39,43,48,53,59,65,71,78,85,93,101,110,119,129,139,149,161,173,185,198,211,226,240,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,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,0,0,0,0,0,0,0,1,2,2,3,4,4,5,6,7,7,8,9,10,11,12,13,14,15,16,17,19,20,21,22,24,25,26,28,29,31,32,34,35,37,39,41,42,44,46,48,50,52,54,56,58,60,62,65,67,69,72,74,77,79,82,85,87,90,93,96,99,102,105,108,111,114,118,121,124,128,131,135,138,142,146,150,153,157,161,165,170,174,178,182,187,191,196,200,205,209,214,219,224,229,234,239,244,250,255
It probably needs the last few 7135 modes ramped down to 0 though, instead of dropping directly from 255 to 0. I haven’t put a smooth down-ramp into the calculator yet.
If I leave the 7135 channel on, it reduces the turbo output a bit. So I turn it off during turbo, but then it makes the ramp jump visibly between the final two modes. So it seems like the ideal solution is to ramp it down smoothly at the high end.
Just fyi, I'm really doing the ramping for the Q8 SRK project, as was requested, but no specs to go by, so I want it simple, but not lacking. A difficult compromise to obtain as you know, with one switch, one LED for biofeedback.
The click-hold UI interference is meant as a usability issue - unintentional actions, I'm trying to avoid. If a click goes to moon, then most likely the user would want to quickly proceed with a hold to ramp up, thus possibly stumbling on a click-hold for battery status.
Yes, filled in the values manually. The bump in brightness at the max was actually useful - visual que you made it there. I did realize what was causing it. Actually, was think'n to make it more pronounced .
Hey thanks for the advice Sharpie. I’ll look into those components.
Ok - finally got a python setup on my Win PC!!! 
I used https://www.python.org/downloads/windows/, and downloaded the level_calc linked above, and can run it fine. This should help big time, because might be tweaking the 142 levels down a little more. Thanks TK!!!
Good news, did you install python 3.5.1?
I doubt I’ve updated all my scripts to python 3… some might still want python 2.7.
I dnld'ed the latest, 3.6.0a1. The level_calc code ran fine.
Awesome. I wasn’t sure, since python3 made some pretty significant changes including syntax of common built-ins. Python 2.7 mostly supports the syntax of both (to help people make the jump), and is still in common use despite python3 being out for 8 years now.
Boy, for the ramping level calc, I used this targeting the Q8 SRK, thinking this was about right:
--> 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
For testing though, I'm using a M2-Z with one XPL, and it doesn't look good at all. When ramping up, it ramps quickly in the beginning, seems to pause at one level, then goes up slowly.
Of course the table was created for a 4X LED with good cells, while the M2-Z is 1 LED and running on a Pana B 3400 cell at 3.8v. But still, didn't expect this. Gotta try it in the target light (I got one modded up from a junker SRk 4X). I donn't think it will be much better based on the values in the table - too litle 7135 levels, too many FET levels - that would explain how it functions.
Anything you see here wrong, either the way I did it or the resulting values?
Nope, that looks exactly like what it should be doing… and what you described is exactly why the ramp needs to be re-calculated depending on how many lumens each channel can produce. It doesn’t work much at all like a single-channel driver where a single curve looks pretty okay no matter what the total output is.
If you want to concentrate more of the levels toward the low end, go to the bottom of the script and change the function it uses for the ramp shape (power() and invpower()). The default is cube/cube-root, but you might get better results with a fifth-root. It’ll decrease the distance between levels at the bottom, and increase distance between levels at the top. Or if you want to make the effect pretty extreme, try the e^x curve.
Or, for a test light with only one emitter, you could simply give it accurate parameters… like a max of 1300 lm instead of 5000 lm.
So, if I were to calculate a FET+1 visually-linear ramp for a single XP-L, here’s how it would look using that same ramp on a quad or on a lower-powered single-emitter light. The original has linear brightness spacing, but if I put it on a quad it’ll have an “elbow” where it suddenly starts ramping up a lot faster. Or if I put it on a lower-powered light, the elbow will bend the other way and the ramp slows down.
I think the one on the right is what happened when you calculated for 5000 lm then used it with only 1300 lm.
Incidentally, the middle image shows how I expect the new E14/S41 is going to behave, since (as far as I’ve heard) it used the old BLF-A6 code unmodified.
Tom
There is ample space for code
Why not 3 ramping modes?
1 500-1500 lumens light
2 1500-4000
3 4000+
You described how it seem to be slowly ramp through certain parts of the range.
Maybe three different rampmodes would prove very cool if using a different rampmode then what the light has as output makes the two other mode show somewhat strange behaviour. It could just work out so that users like to have the ramp go slower on the low or med of higher modes and even use a ramp mode for 4000+ lights on a smaller EDC with just 650 lumens for example
Q8 is just 1 light Narsil is for 
Well, what's look'n good right now on the modded M6 (4500-5000 lms) is this:
level_calc.py 2 128 7135 3 0.3 150 FET 1 1 1500
So it's set to only 1500 lumens max, so basically, the lower I went on max lumens, the better it's been looking. But I think you may be right TK - changing to a fifth root may improve this. I could see the pattern - the lower I made the max lumens, the more levels were given to the 7135.
Now this is all perception, and all my testing is indoors, so there could be some significant problems in my perception. I also should sanity check a measurement of 7135 max only. Also, the little blink at the high end went away, and I think it's because the high end is much smoother now, but that's also where it's very hard to tell it's still ramping
Ahhh - bout the BLF-A6 driver, yes, they are being bought for all sorts of applications. No one, or not many, understand these potential issues.
The Miller - yes, multiple tables could be done. For 140 levels, it's 280 bytes for one table set alone, not to mention the extra management code. I still have 2300 bytes free though.
Here's the code for the table I'm using, I reformat it out to 16 values per row:
#define RAMP_SIZE 132
#define TURBO_DROP_MIN 102
// min level in ramping the turbo timeout will engage,
// level 102 = 105 PWM, this is ~43%
#define TURBO_DROP_SET 92
// the level turbo timeout will set,
// level 92 = 71 PWM, this is ~32%
// Ramping Modes, 132 total entries, 128 generated, 4 more '3's added for 7135:
// level_calc.py 2 128 7135 3 0.3 150 FET 1 1 1500
PROGMEM const byte ramp_7135[] = {
3,3,3,3,3,3,3,4, 4,5,5,6,7,7,8,9,
11,12,13,15,17,18,20,22, 25,27,30,33,36,39,43,46,
50,54,58,63,68,73,78,84, 89,96,102,109,115,123,130,138,
146,155,163,173,182,192,202,213, 223,235,246,255,255,255,255,255, // 49-64
255,255,255,255,255,255,255,255, 255,255,255,255,255,255,255,255, // 65-80
255,255,255,255,255,255,255,255, 255,255,255,255,255,255,255,255, // 81-96
255,255,255,255,255,255,255,255, 255,255,255,255,255,255,255,255, // 97-112
255,255,255,255,255,255,255,255, 255,255,255,255,255,255,255,255, // 113-128
255,255,255,0
};
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,1,3,4,5,7,
9,10,12,14,15,17,19,21, 23,25,27,29,31,33,36,38,
41,43,45,48,51,53,56,59, 62,65,68,71,74,77,81,84, // 81-96
87,91,94,98,102,105,109,113, 117,121,125,129,134,138,143,147, // 97-112
152,156,161,166,171,176,181,186, 191,197,202,208,213,219,225,231, // 113-128
237,243,249,255
};
With many and large tables it might save program space doing the calculation in driver firmware. Doing this the user could tweak calculation parameters in configuration mode for almost unlimited variations.
True Mike, but w/floating pt. math, oh boy...
TK - just noticed the app doesn't create a max 7135 entry, no FET. That's strange, but may just be how it works out?
Also trying it in a couple more lights. Got a 50 7135 (49+1) SRK V2 MtnE driver in a 5X SRK, and it definitely has a pause or something, but that's obvious now that I look the script and data -- driving 49 7135's at PWM level 1, 2, 3, 4 (maybe 5 and 7) probably won't do anything.
Edit: It's in a total of 5 lights now: M6 fully modded, Fing 5X fully modded, 4X Securitylng w/stock MCPCB, M2-Z, and a Zy-T11 clone. Looks good in all accept the 5X, but fullt explainable there.
Wauw Tom sounds great!