Turbo and thermal control

Flashlight Modding and DIY Parts
1

I already wrote about this in the firmware repository thread, but I thought it's maybe worth its own discussion, maybe not.

TK asked if anyone really cares about thermal regulation or if it's just a check box. Got me thinking about it, also because now my light is sealed up well and has fully charged batteries and it gets hot.

BLFA6 had a timed turbo stepdown. This allows you to get boost of light, beyond what is thermally sustainable, but prevents damage to surroundings in case of accidentally leaving it on. It just came down a fixed lower mode and remained there. You could tap it back up with a tap, then you presumably know what you're doing.

Bistro moved to a kind of thermal regulation. The light gets to hot, the level goes down, still too hot, goes down more, cool enough, goes up. Tom E was recently saying something about Narsil not having a thermal limit I think, because this is hard. There are delays and time scales and gains to get right and if you get them wrong you get oscillation and overshoot. This is absolutely right and is typical of any feedback problem. They're hard.

To me though, these are separate things and one doesn't replace the other. A turbo boost gives you a burst of light because you need to see something now a for a few seconds. Then there's no reason for it to dance around trying to find the highest mode it can stay on (which will be much lower anyway) after that. It can just come back to a cool running level, stop annoying me, and put me back in control. This cools the light and makes it ready for the next time I need turbo.

I wonder how other people use turbo. Do you want the light go to turbo and then after that come back down to the highest sustainable level or are those two different needs? Notice that if it does come back to the highest sustainable level, you won't be able to hit turbo again without instantly overheating, so turbo becomes a one-shot thing.

Maybe things went overboard when temp sensors came into the picture. It is possible to just do a BLFA6-like turbo timeout, but trigger it on temperature instead of time. you still just jump down to a fixed mode, and allow to tap back to turbo. The easiest thing to program (and fit) is then just to stay on turbo for the time it takes to verify the temperature (say 4 seconds) and then pop back down if it's still too high. You can have some "overshoot" on the first shot, but that can just factor into your personal calibration.

So I programmed that and I love it. It doesn't just apply to turbo mode either, any mode. The regulation thing is going crazy on this light, but this works great and is simple.

Thermal regulation is a separate neat thing to me, but I'd call it a special mode. Without changing conditions (wind etc) there's a mode you can run at constantly without going over your heat threshold. A good regulation system should zoom in on it and stay there. This is a long term mode, not a short term light boost. THIS however is very difficult. The simplest feedback gain loops must be tuned to a particular light both for gain and delay, probably both for heating and cooling and it's hard. I have some ideas, and Dr Jones has something, but it's not simple. But do we need to be complicating one issue with the other? Especially if it means including neither?

2

As far as i know Bistro and narsil go only down, but not up after cololed down
if you could manage to step up again that would be great for TA Bistro and Bistro HD

3

No bistro goes back up. But I don't find it great at all. First it goes down in annoying quick steps. Then we wouldn't be talking about going back up unless it first went farther down than it needs to to sustain the max temp (that's ok)... and for me it least, it does go farther down than that, very quickly, and much too far actually. Second though, now that it's very low, then it goes up, very quickly, until it's back in turbo and repeats. Why would I want my light bouncing up and down at random times? Just because its cool I want it full brightness again? Also it does it little rapid steps that aren't useful since in the end it's basically just a full down and full up anyway. I don't want to sound like I'm bashing TK. It was a nice idea, nice code, but even she was wondering if anyone actually likes it.

So you could say it just needs improvement, but then what's the goal. Is the goal to ahve it go to turbo and then settle on a lower sustainable level, where temp stays maxed out? To me those seem like too completely separate goals. For turbo, go to turbo so I can see now, then just come back to a cool mode. For regulation, I don't even want turbo, just zoom in on that regulatable level and stay there, a different thing.

Anyway, this temp down, tap back up feels nice to me.

4

And if you don't believe what I'm seeing, see line 848 here:

http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/head:/ToyKeeper/bistro/bistro.c

Especially the ++

5

Led4power tried a thermal regulation in the LD2 and LD3, I did a test on it and while it works good in keeping the temperature under the set threshold, there is some overshoot going on in the beginning (later on it fine-tunes itself, it seems) and the light level is visibly changing all the time.

6

I like your implementation of the temperature-based turbo stepdown. It is at least a safety measure, if the light happens to be turned on by accident.

I agree with your assessment that actual temperature regulation maybe should be like a separate mode. Usually I can implement my own “PID” control and choose a mode that will give me enough power without overheating. If the driver regulation can do this effectively, great, but the regulation in Bistro does not work well for me so I just end up turning it off. In Bistro, it is supposed to come back up after stepping down, but in the version I get from mtnelectronics, the “temperature dead window”, where the output neither goes up or down, is set to be too large, with my light setup, and it ends up just staying in a very low mode.

7

Thermal management is important IMHO since many lights are not purchased by those on BLF but by mere mortals.

The issue I have with a basic turbo timer is that it first off can step down too fast or too slow and needs a lot of tweaking for each light, I find this VERY annoying. I do NOT like fixed time turbo timers.

The second is that the mode it steps down to is not always under what would be “safe”. Even the 2nd highest mode will usually overheat a light. Generally you have to step down to something like 50% power in many small lights to keep heat in check.

All of that said I do agree that the way Bistro takes care of thermal management is a bit annoying in it’s own way. The hunting for the right level grows old along with not knowing what mode you are actually in.

The best setup is a fancy PID setup like the high end lights use for truly smooth stepless ramping (at least this is what I was told). Allowing for fine and complete control over the output and thermal levels. With the latest MCU’s we have pins left over for temp sensors as well for even greater control.

Barring that the best thing would be a combo of the turbo timer and bistro setup IMHO.

The idea of using the temp as the step down point instead of the timer is the ideal starting point. Instead of stepping down to some random mode in the ramp table, it should step down to the next mode level down, allowing you to quickly bump it back into turbo if you want to. When you bump it back up to turbo it will add say 15c to the target temp each time, allowing the light to get hotter before stepping down (all of these would be in defines naturally for the future screen flashing).

This way it would only step down to try to keep the light under whatever temp you select (I do like the menu calibration that bistro offers). If it keeps overheating then it steps down another mode. If you ever bump it back up it adds 10-20c to the max temp until the light is off for long enough to “reset” itself.

This solves the hunting for output issues while also allowing you control over how bright and hot you want the light. It also removes the timer issues and acts more as a safety feature to keep the light from overheating if left on unattended.

You could even have a big step when you bump it back up, say 30c to allow it to get much hotter. Naturally you would need some kind of absolute max thermal setting at which point it would step down in order to protect the light from damage naturally. Most likely whatever the max internal temp sensor reading is.

Now a fancy setup like the high end lights use would be great and allow for much smoother operation, it would take a lot of testing and work to get it working right though.

8

Something to keep in mind with the drivers with linear regulation is that the driver will often get hotter than the rest of the light. I observed this with the H17F. When in the 3A linear mode the output would drop sooner than when in the FET mode even though there was more current in the FET mode.

9

If you have a 7135 bank on your driver best is to get it potted

I had my revived Imalent light with TA triple channel Bistro, calibrated to 65dC, but the light seems to cool to 38dC and not stepping up again

10

It seems to me that it would be better to be temp dependent than some arbitrary time out since ambien temperature and unique host conditions play a large roll in determining where a light reaches quilibrium(or doesn’t). I’m all in favor of whatever works the way it’s supposed to rather than something that works only under the right conditions. With so much going on in driver developement in the last few years I accept that with any new driver or UI it takes literally years to beta test even seemingly minor changes but sometimes it seems that developement outpaces stability management and is the most intensely frustrating thing about modern computer software developement. This seems like a blueprint for getting lost and ending up with a slew of really cool drivers none of which work quite right. Sorry, that kind of digressed into a mild rant.

11

Ok, it sounds basically we're all on the same page here. Easyb there is no programmed dead time in bistro before going back up. That's just delay in the heat moving through the insides of your light. This is why true PID regulation si very very hard, especially if you want to achieve a smooth result. These delays have to be tuned into the system and the gain has to be known in advance, and this depends on the light. For a high end light you can get this tuned up but for a generic driver I think it's hard.

At TA, I'm not sure the 30c more thing. The idea is that the light goes down, and stays down, maybe for a long time... until you need turbo again. By then it was already cooled. You don't necessarily want a higher threshold, your'e just going for a second shot... after it at cooled at some later time when you need to see something else. This is why a minimum time on tap up would work though. That min time should be set less than overheat time assuming the temp settled. If it didn't settle, you'll overshoot, but you wanted more tubro too soon, you can feel the light, you know what you're doing. Presently that min time is 4s. That's kind of by accident of how the code works. It's a bit short. Going higher needs a different programming mechanism to avoid other issues though. But even 4s works pretty well. 15 would be better.

I'll have this scheme (temp threshold, jump down, tap up) in the next HD release. It works now(unrelased) but there's a small race condition where once in a while tap-up doesn't work. Also I think the biscotti-HD timeout has a bug in the present release.

12

Oh I agree about the issue of not knowing what mode to step down to. I'm not using the BLFA6 turbo-2.

I have a macro TURBO_STEPDOWN. At the moment I haven't moved it to the config files but it is overidable in them. The default is RAMP_SIZE/2 but of course you make crazy enough ramp where that won't work. This wiill have to be te responsibility of the modegroup designer, but of course their can be some light where turbo is 8 times more power than the light can actually handle. That's the responsibility of whoever makes such a crazy light.

The enxt question is if I will apply it to the bistro-classic-HD build. I think I will. The whole point of remerging the code base was to able to take advantage of new improvements in all the builds. If all I do is try to exactly re-recreate the original bistro, there's not much point. That build will have the same basic features and modes as classic bistro, and should work on the same hardware (not OTSM by default), but enhanced some.

13

I meant temperature window, not time. There is a temperature range where the output does not increase or decrease. At least that is my understanding. See here.

14

Ah yes, I hadn't taken much notice. There's a tiny hysteresis, but it's a whole 3 degrees. I don't think that's the main issue. Even if that was 1 it would still oscillate. It just ramps down too fast. Even after turbo is turned off the driver is likely to keep getting hotter for a little time. But you get it right for one light and it will be wrong for another.

15

Anyway, I got a minimum-turbo time logic now that actually was more efficient anyway. So every entry into turbo resets a clock. After the clock runs out, it measures temperature. If the temp is too high it jumps down (not ramps). If the temp is fine though, it stays in turbo. This is not meant to be a long like 1 minute turbo timeout. It's meant to be a conservative 10 or 15 second minimum that insures that after a tap up, you still get that much time. If your hand starts burning, you'll figure out what to do.

16

Very interesting and well written OP. Separate, sound ideal to me for at least the following reasons:

  • Turbo to help preserve battery charge. Say when someone kicks in turbo to find something, then puts the light down to pick up the object and use it. Forgetting the light is in turbo and the cell or cells are draining at a high rate.
  • Thermal control as a always-on safety measure for when you live with elderly, young, or irresponsible, or non-flashaholics. Also for accidental activation. Stepping down, but not back up.
17

Ok, I'd still call both of those what I thought of case 1 but I hadn't thought of the battery aspect. The third useful case, and you see it bike lights, is trying to get the most you can out of the light at a level that can maintain an acceptable temperature, and in the case of bike lights can react as that level changes with wind speed. That's really hard though, but I think gets much easier if you're designing for one specific light.

I think this turbo boost I'm implenting will cover your two cases just fine anyway. It doesn't go back up automatically. The whole "back up" concept is just wrong to me automatic regulation, shouldn't have come down too far in the first place. But this thing I'm dong isn't automatic regulation. It's just turbo boost and thermal/battery protection. Doing a bit of code organization so will need a little testing, might be a few days to get around to posting it. I still have the mark 1 (buggy) version in my light.

18

I think you misunderstood what I was getting at.

Here is what I am thinking at the moment:

1: You activate turbo (or any mode high enough to cause the light to overheat)
2: It runs at that mode until the temperature setting you selected / calibrated is reached.
3: It steps down to the next mode down in your normal mode group (like the A6, not like bistro)
4: If it still overheats then it steps down another mode (this could be either a timed check of the temp or I would prefer to have another temp check after the first step down that is 5-10c higher then the first in order to account for heat moving through the light.) All adjustable in the defines of course.
5: It stays at whatever level it stops overheating at until you manually turn it back up.

5A: It steps down at a very inopportune moment and you immediately bump it back into turbo knowing that it is getting hot but willing to let it.
6A:When you bump it back up within the first ~10 seconds of the step down it adds say 10-15c to the target temperature before stepping down again. This way you get more then 1 seconds at turbo before it steps down again. Plus since you just stepped it back up it knows you are holding it and thus you must know what you are doing. If you wait longer then 10 seconds before stepping it back up it does not change the temp setting.
7A: you can repeat step 6A until a max temperature is reached where it will then force it down to moon. This would most likely be the limit of the internal temperature sensor or around 125c, whatever is first.

The idea with this setup is that it stops the light from overheating in the case of it being left tail standing someplace and doesn’t hunt for the output level.

It also protects the light from damage due to extreme temps (most of the components can handle 150c for short periods without damage, I mean they are soldered together hotter then that afterall).

Yet, it still allows you to override the thermal settings, at least temporarily, if you are actively holding it (and thus can keep turning it back to turbo). I know I have had times when I want to use turbo but the thermal settings just keep fighting me every 3 seconds, it is a pain. Upping the temp so that I go at least 10-20 seconds between it stepping down would make it much more useful while still keep a good enough safety factor.

If someone is actively holding the light then they should be able to figure out if it is too hot and stop bumping it back up to high.

I do agree with no liking fixed timer settings, they are too ridged.

19

If calibration is needed could you designate one mode as the step down mode (highest output with stable temp for that light)? Any higher level that exceeds the calibrated temp steps down to that level after a 15 second delay and stays there. You can immediately tap to go back up with the same 15 second window before step down or let the light cool some to get a longer window.

20

It would need so much calibration per light this would be hard to do without the screen flashing that we are working on now. With that in play then pretty much anything like this could be set.

Although I am still very much against using time over temperature. It will take so much more calibration per light and still will not compensate for the environment. Simply increasing the max temp solves all of this.

Virtually none of us run lights near what they can actually handle anyways, they can run at upwards of 100c and be fine (external temps). So there is a large window to play with for increasing the max temp before we have to worry about damage. Just discomfort / burn risk if you touch the head.