Looking around a little more, I think I might have found a potentially-useful approach. Thermal regulation is rather unpleasantly like trying to steer a really heavy ship. The high degree of inertia makes it hard not to over-steer. Bistroās solution is to steer very very slowly.
This looks promising:
I know it doesnāt do much good either with or without source, but INFERION claims to have implemented PID in the Indigo 5.x firmware. Indigo 5.0, ŠøŠ»Šø "Š½Šµ ŃŠ¾Š²ŃŠµŠ¼ ŃŠ¾ŃŃŠ¼Š½ŃŠ¹" Š“ŃŠ°Š¹Š²ŠµŃ? (Š§Š°ŃŃŃ 2) | ŠŠ°ŃŃŠµŃŃŠŗŠ°Ń: INFERION
Hopefully I wonāt put my foot in my mouth, but it seems to me that PID shouldnāt require a lot of space. Here is an Atmel document on the subject (with code provided in a zip), as linked from the ATtiny85 docs page. Atmel claims that their PID function compiles to 534 bytes.
Well, I do have some true PID code for my reflow oven. It runs on a MEGA2561 and uses floating point code. It is pretty much the same PID/fan control code I used my GPSDO (GPS Disciplined Oscillator) temperature stabilizer. I have seen it control temperature with a 24 hour RMS error of 1 microdegree, with peak errors of less than 5 millidegreesā¦ Might be a bit much for a flashlight.
A simple temperature control PID is not much more complex than Daleās code. Implementing the I (intergral) term can be a bit trickyā¦ you have to handle āintegral windupā where the integral (long term compensation) value keeps accumulating in the same direction and āruns awayā
Tuning a PIDs control parameters is always a pain. Most simple method is to start with P/I/D values at 0. Increase the P value until the output starts oscillating and then increase the D value to stop the oscillation. Then adjust the I value to minimize long term drift. My oven / GPSDO code has some auto-tuning code to that does a lot of the work.
Hmm, 534 bytes. Not bad at all. Certainly better than the ~5k bytes one I looked at. 
Iāve got a copy of the Indigo 5.2 firmware, but itās a little ā¦ opaque. Assembly code with sparse Russian comments. I think Atmelās version will be a more useful reference, and another Kalman link I found which deals specifically with compensating for situations where one or more values lag behind.
It wouldnāt be a big deal to devote an extra ~500 bytes to PID on a tiny45/85. I wonder how much the response curve can be improved with PID and/or Kalman instead of the āsteer really slowlyā approach, and if it can anticipate over-heating conditions and start to correct for it in advance. I also wonder if itāll need to use the full 10 bits of precision instead of 8, since temperature measurements are rather coarse so far.
Too many questions/unknowns. I need to just do it and find out. ā¦ ā¦ after I get more parts and some time.
Belive me, you donāt want to go down the Kalman rabbit hole. Insanity awaits those foolish enough to enter that dark realm. Iāve been there and barely escaped with my life. Bits of brain still ooze out of my nose whenever I think about it.
+++1 here! Sorry been behind here but Mike - you have some real original work goin on and always enjoy following you.
Been away climbing for a while, sorry for late replies.
It works very well, Iāve been using it in several lights. Itās all just voltage measuring, and deciding what to do with the measured values.
Individual pins with groups. AMC7135 groups are PWM, 1, 2 and 4. Another pin for the voltage input and the last pin Iāve put on either a FET or a larger group of AMC7135s. Iāve looked at using external components to avoid mucking around with the reset pin but on Iām all out of space for the solutions I could find. Iām not that knowledgeable with these things though, any good suggestions I could look at?
Thanks! In regards to board design I wouldnāt know why Iām not having the same issues. No funky stuff with the layout. And as far as I have been able to tell, these issues with the FET / moonlight you have been having have not been able to be resolved by firmware coding. What is the FET you are using? If it has the same footprint I could always build a test driver with one of them (if itās not the one I use).
Iāve been workān on a few older mods with the wight FET+1 driver v009 and a Attiny85 and noticed not all had issues. Couple didnāt need anything extra, while others needed the FET gate resistor and the 0.1 uF cap across the +/- input to the MCU. I use about always the SIR800DP FET, where itās been reported by others to be prone to the flash problem. Read somewhere that someone simply replaced it with a different P/N FET and the flash went away - donāt recall where or which FET it was though.
I tried pretty much everything in firmware to fix it, TK has also, and we couldnāt fix it.
I do have interest in temperature control. Currently I have temperature calibration and step down, and have a few first tests of temperature controlling. What advantages would a PID controller have? My testing consists of running a ālearningā routine where the light heats up, shuts off and does a few things, all timing how the heat behaves in response to turning off and so on, and then storing the values into the EEPROM. My main issue is that with some hosts the difference between doing this routine while holding the light as a lot different than doing it while it is laying on the table. Care to write a few lines on how a PID controller could be used to make all this a little easier?
Ahh, OK. That one was harder to get in Europe, I think thatās why I went with the NXP PSMN3R0-30YLD. Iāve not used another one. If I remember correctly the SIR800DP has a diffferent footprint so I wouldnāt be able to test without changing the board.
The advantages, in theory, are a faster response to excess heat without ābouncingā the output. Perhaps it could even detect when the temperature is rapidly approaching the ceiling and start the step-down in advance.
The method Iām using now doesnāt care if the light is being held or not, but it steers slowly enough that it could still overheat before the step-down is low enough to help. The calibration is only one value, the ceiling temperature, and itās a little tricky due to the lag involved in getting heat from the emitter to the pill to the MCU. It tends to exceed the ceiling for a little while before settling on the maximum usable output for that temperature.
Itād be nice to ālook aheadā a little and start the adjustment early, to compensate for lag, and also to allow it to steer faster if it can be done without bouncing.
For those of you intrepid souls that want to wander down the Kalman filter rabbit hole, this is a fairly gentle introduction:
http://academic.csuohio.edu/simond/courses/eec644/kalman.pdf
Thatās what my timing is for. As I time how long it takes before the light starts to cool down after the LED is off I can use this time to start lowering output in advance, and also take into consideration the lag time the sensor would expect to see the results of lowering. Iām thinking Iād use the timing when on the table, in still air and in room temperature would be a bench mark as the slowest reaction time to lowering for each host. Reaction time would be faster if holding or mounted on a bike while riding fast. Iām still just testing, but it looks like have come further with it.
So you do your lowering only once the temp reaches the ceiling? Is your lowering visible, like a mode change, or do you slowly fade?
I wrote it in another thread so I might as well write it here tooā¦
Iāve just made a version of my FET driver (Mod: My take on the convoy S series with side switch mod.) with the PowerPAK SO8 footprint and ordered from OSH Park. I canāt get the SIR800DP but Iāll get a couple of SIRA00DPs. I donāt know if they are good for this purpose, but Iāll stick āem on and see what happens anyway.
FWIW, the SIR800DP has the same footprint, but no exposed tab on the back, so you need the LED- pad extended to solder to
Nope. I use a VIA for LED- located right beside the FETās tab. Footprint is not the same as the FET I normally use (NXP PSMN3R0-30YLD with LFPAK56 footprint). Itās about the same size though.
Are you saying the LFPAK56 is different from the S08? I think most people here use them interchangeably. Thatās why I didnāt think they were any different.
I think they are interchangeably, but they are not the same. The footprint I made for the PSMN3R0-30YLD works perfectly for that FET, but the measurements and space between the pins are not the same as the S08. I know as Iāve just made my own S08 footprint for the SIRA00DP using the datasheet measurements.
Well sounds like youāve got a handle on it then 
Iām going to have to take this backā¦ I just put them over each other and they are basically the same. The SIRA00DP has a different looking tab, and the footprint for that could be made differently, but the pins align perfectly with the PSMN3R0-30YLDā¦ So I actually didnāt have to make another footprint. Oh well, whatās done is done.