Attiny25/45/85 FW Development Thread

1911 posts / 0 new
Last post
Hoop
Hoop's picture
Offline
Last seen: 2 days 21 hours ago
Joined: 12/20/2012 - 05:33
Posts: 1003
Location: Spokane, WA

Does the voltage of the PWM signal from an Attiny chip vary with the battery voltage?

Tom E
Tom E's picture
Offline
Last seen: 17 min 2 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13414
Location: LI NY

Sorry, I can't answer that in any certainty, but total guess is yes, because I don't think anything in the MCU is boosting or regulating voltage, but really dunno. Do you think it makes a difference to the FET or 7135's, because it just acts as a ON/OFF switch, not used directly as power out of the FET or 7135's?

Hoop
Hoop's picture
Offline
Last seen: 2 days 21 hours ago
Joined: 12/20/2012 - 05:33
Posts: 1003
Location: Spokane, WA

I’m considering the limitation of the PWM signal being strong enough only to control ~32 7135 chips. I am thinking that if the PWM signal went to a fet whos output was connected to the PWM pins of the 7135’s, an unlimited number might be able to be switched.

Tom E
Tom E's picture
Offline
Last seen: 17 min 2 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13414
Location: LI NY

Hhmm, don't think the waveform of the signals are the same - the gate input, and the FET output, but I could be wrong. I have a modded MtnE 7135 SRK driver with the full up 32 7135's, and 18 more piggybacked, total of 50. I got it in a Fing 5X, getting like 18A out of it, which is close or at the max. It works great, up to 8 PWM modes using PHASE PWM (I don't use FAST mode anymore), running on a 85. Not sure, but might not have tested it for LVP operation...

Hoop
Hoop's picture
Offline
Last seen: 2 days 21 hours ago
Joined: 12/20/2012 - 05:33
Posts: 1003
Location: Spokane, WA

Nice. Yea, I was thinking a FET might be fast enough not to mess with the waveform too much but idk. Another option might be to use two MCU pins PWM’ing in parallel to a bank of 7135’s.

Tom E
Tom E's picture
Offline
Last seen: 17 min 2 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13414
Location: LI NY

Got the final open issues for ramping done and pretty much tested now. I have the new Narsil installed in 3 lights:

  • Supfire M6 (Indicator LED, FET+1, 3 U3's, does about 5,000 lumens)
  • SupFire M2-Z (FET+1, C8 size side switch, modded with an XPL)
  • ZY-T11 clone (indicator LED, FET+1, XM-L2 T6 4C)

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

MRsDNF
MRsDNF's picture
Offline
Last seen: 22 hours 52 min ago
Joined: 12/22/2011 - 21:18
Posts: 13431
Location: A light beam away from the missus in the land of Aus.

I admire your skills Tom. It all sounds exciting.

 

djozz quotes, "it came with chinese lettering that is chinese to me".

                      "My man mousehole needs one too"

old4570 said "I'm not an expert , so don't suffer from any such technical restrictions".

Old-Lumens. Highly admired and cherished member of Budget Light Forum. 11.5.2011 - 20.12.16. RIP.

 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 10 hours 20 min ago
Joined: 01/12/2013 - 14:40
Posts: 10614
Location: (469219) 2016 HO3

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:

Flashy Mike wrote:
Is this the right thread for comments regarding Bistro firmware?

I am currently testing a bistro driver with cpu clock lowered to 4 Mhz, built into a S2+ triple, and so I also checked temperature control. It didn’t work as suspected, first I assumed a dependency to the clock change, but there was another reason in code: when over temperature is detected, the output level is ramped down 1 step each 8 seconds!
This means, coming from highest level it lasts 80 seconds to reach a FET output of 50% and even 160 seconds for 25%. My triple will be melted then.
Is this solution really expected to work with any smaller light pulling more than 3 amps?

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.

Tom E wrote:
PID algorithm …

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.

Flashy Mike wrote:
manufacturers … I doubt they know what they are doing …

It can be pretty frustrating at times.

Tom E wrote:
ramping mode … I tried 2 seconds at first, but could not stop at moon mode.

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

I’m looking forward to trying this.

Tom E wrote:
hold ramps up, accept if it is on hi. If on hi, hold ramps down all the way to moon in 3 seconds, and stops there

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.

Tom E wrote:
From OFF:
  • hold ramps up from moon to max level

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.

Tom E wrote:
Then a blue Pomona failed on me – one of the pins sprung out of the plastic tabs holding it in, and just couldn’t get it to stay.

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.

Tom E wrote:
Couple things still To Do:
  • turbo timeout (currently only works in normal mode sets, not ramping)
  • Low Voltage Protection – needs to be modified to lower levels (currently only steps down modes in a mode set)

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.

Tom E wrote:
… using PHASE PWM (I don’t use FAST mode anymore), running on a 85.

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.

Tom E wrote:
I increased the # of steps to 142 (was 64 steps).

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.

Tom E
Tom E's picture
Offline
Last seen: 17 min 2 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13414
Location: LI NY

ToyKeeper wrote:
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 sure is a PIA - haven't gotten to it myself yet, but looks like I'm gonna have to.

ToyKeeper wrote:
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. Smile I'm looking forward to trying this.

Yes, stops at max, but when at max, a hold will reverse ramp (hi->lo) and stop at moon.

ToyKeeper wrote:
Tom E wrote:
hold ramps up, accept if it is on hi. If on hi, hold ramps down all the way to moon in 3 seconds, and stops there
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.

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 itwink

ToyKeeper wrote:
Tom E wrote:
From OFF: * hold ramps up from moon to max level
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.

OK, this one is on me. I totally mis-understood what you wrote up here: http://budgetlightforum.com/comment/823798#comment-823798, and also blueb8llz wrote up here: http://budgetlightforum.com/comment/822785#comment-822785. 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.

ToyKeeper wrote:
Tom E wrote:
Then a blue Pomona failed on me - one of the pins sprung out of the plastic tabs holding it in, and just couldn't get it to stay.
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.

Same here. I always keep a full spare handy now.

ToyKeeper wrote:
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.

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 10 hours 20 min ago
Joined: 01/12/2013 - 14:40
Posts: 10614
Location: (469219) 2016 HO3

Tom E wrote:
ToyKeeper wrote:
“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.

I’m being accused of having too complex UI’s as it is, so not sure if it complicates things or not…


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.

Tom E wrote:
ToyKeeper wrote:
Holding from off should probably go to moon and stay there …

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.


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.

Tom E wrote:
ToyKeeper wrote:
Why 142 exactly?

142 is just how it turned out. … 3 secs (actual ~3.5 secs) was too long, so …


Oh, okay. I didn’t think about the timing. Smile

Tom E wrote:
I filled in all the in-betweens with mid-points, etc. to get it somewhat balanced, and looks real smooth now.

You filled it all in by hand? There’s a tool to generate those numbers. 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/h...

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.

Tom E
Tom E's picture
Offline
Last seen: 17 min 2 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13414
Location: LI NY

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

Hoop
Hoop's picture
Offline
Last seen: 2 days 21 hours ago
Joined: 12/20/2012 - 05:33
Posts: 1003
Location: Spokane, WA

Hey thanks for the advice Sharpie. I’ll look into those components.

Tom E
Tom E's picture
Offline
Last seen: 17 min 2 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13414
Location: LI NY

Ok - finally got a python setup on my Win PC!!! smile 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!!!

Microa
Offline
Last seen: 1 day 12 hours ago
Joined: 06/29/2011 - 21:20
Posts: 238
Tom E wrote:

Ok – finally got a python setup on my Win PC!!! smile 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?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 10 hours 20 min ago
Joined: 01/12/2013 - 14:40
Posts: 10614
Location: (469219) 2016 HO3

I doubt I’ve updated all my scripts to python 3… some might still want python 2.7.

Tom E
Tom E's picture
Offline
Last seen: 17 min 2 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13414
Location: LI NY

I dnld'ed the latest, 3.6.0a1. The level_calc code ran fine.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 10 hours 20 min ago
Joined: 01/12/2013 - 14:40
Posts: 10614
Location: (469219) 2016 HO3

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.

Tom E
Tom E's picture
Offline
Last seen: 17 min 2 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13414
Location: LI NY

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?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 10 hours 20 min ago
Joined: 01/12/2013 - 14:40
Posts: 10614
Location: (469219) 2016 HO3

Tom E wrote:
level_calc.py 2 124 7135 3 0.3 160 FET 1 10 5000

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.

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

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 10 hours 20 min ago
Joined: 01/12/2013 - 14:40
Posts: 10614
Location: (469219) 2016 HO3

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.

The Miller
The Miller's picture
Offline
Last seen: 11 months 3 days ago
Joined: 12/14/2015 - 12:08
Posts: 9908
Location: Charente France

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

Tom E
Tom E's picture
Offline
Last seen: 17 min 2 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13414
Location: LI NY

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
};

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 1 week 3 days ago
Joined: 01/14/2016 - 16:38
Posts: 1222
Location: Germany

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.

Tom E
Tom E's picture
Offline
Last seen: 17 min 2 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13414
Location: LI NY

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.

The Miller
The Miller's picture
Offline
Last seen: 11 months 3 days ago
Joined: 12/14/2015 - 12:08
Posts: 9908
Location: Charente France

Wauw Tom sounds great!

MRsDNF
MRsDNF's picture
Offline
Last seen: 22 hours 52 min ago
Joined: 12/22/2011 - 21:18
Posts: 13431
Location: A light beam away from the missus in the land of Aus.

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

 

djozz quotes, "it came with chinese lettering that is chinese to me".

                      "My man mousehole needs one too"

old4570 said "I'm not an expert , so don't suffer from any such technical restrictions".

Old-Lumens. Highly admired and cherished member of Budget Light Forum. 11.5.2011 - 20.12.16. RIP.

 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 10 hours 20 min ago
Joined: 01/12/2013 - 14:40
Posts: 10614
Location: (469219) 2016 HO3

Flashy Mike wrote:
With many and large tables it might save program space doing the calculation in driver firmware.

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 10 hours 20 min ago
Joined: 01/12/2013 - 14:40
Posts: 10614
Location: (469219) 2016 HO3

Tom E wrote:
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?

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. Smile
(is also why I put in some commented-out presets for different curve shapes)

fixed it
Offline
Last seen: 9 months 4 weeks ago
Joined: 12/08/2015 - 14:27
Posts: 396
Location: Canada

Sharpie wrote:
Ps: fp on an integer system, without an fp alu would need a good library.

LUT I think easier. And easier to fine tune, with no compilation increase.


avr-libc looks decent but probably too large to be useful here. A simple float multiply is a function over 200 bytes. Add pow, divide, etc and you’ll quickly use up more program space than the tables.

Fixed point could be made to work within a small footprint. I agree that LUTs are better here as long they get the job done. But if there’s some interest, I can take a stab at the fixed point math. I’ve done much worse things before Smile

Tom E
Tom E's picture
Offline
Last seen: 17 min 2 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13414
Location: LI NY

I dunno - I'm pretty happy with how the current table is performing across 1400 - 5000 lumens. Only thing that has to change is for a 7135 bank vs. a FET, as far as I can see. I'll do more testing tonight though.

Pages