Attiny25/45/85 FW Development Thread

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

You filled it all in by hand? There’s a tool to generate those numbers. :slight_smile:

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

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 :wink:

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!

Amazing work Tom. Thanks. Are you charging by the hour?

Would be nice, but the code to generate the tables… isn’t very small on an attiny. It’s all floating-point and uses functions which cost a lot of space like cube roots, while the attiny only does integer math so it’d need to either load a floating-point library into ROM or manually simulate things with fixed-point.

However, it could probably be cut almost in half by adding a restriction and an inflection point. While the 7135 channel is ramping up, the FET is all zeroes. Then while the FET is ramping up, the 7135 is all 255s. These could be combined into one table with the repetitive bits removed, with a bit of extra logic added to handle it differently. It’d save space when the ramp is large, but it’d cost space when the ramp is small.

It doesn’t attempt to alter the ramp shape to exactly hit the boundary between channels. I’m thinking of perhaps making it do that, when it can, but I’m not sure I want to mess with it. It’s usually fairly simple to wiggle its parameters a little until it’s close, then tweak a few PWM values manually to make it exact.

I’m thinking it might be good to estimate the maximum lumens on the low side, since it’ll drop with voltage anyway. Maybe it does 5000 lumens on full cells, but only 2500 at 3.6V? So maybe it’d look better with a curve calculated for 2500.

There’s also debate about what the best curve shape is. Selfbuilt insists it’s a cube root, but I find that a logarithm tends to be really nice, and there are other curves between (fifth root, seventh root, etc). Some people even prefer a square root, but I find it’s not steep enough.

The only way to tell for sure is to try it, and that’s what you’re doing. :slight_smile:
(is also why I put in some commented-out presets for different curve shapes)