Interested. Thanks.
I’m in for one, please.
PM sent and updated the list 
Hi, Tom pointed me at this thread today… because I just rewrote all the thermal code and was running tests on a bunch of lights to make sure it works right.
Here’s a link to all the test results, but I’ll summarize what I found for MF01-Mini below. Long story short: If you want stable regulation, that can probably be accomplished with a firmware update. But if you want longer runtime on high modes before it regulates down, adding more heat sinking should help.
MF01-Mini: I tested both turbo and the ramp ceiling, because man of light noticed regulation problems at the ramp ceiling level. Here are the results for both. I let the second test run until the battery was empty, to see how the rest of the graph would look:
Aside from the stable level being strangely low for a light this size, everything looks pretty close to optimal. It’s just strange that it could only sustain ~400 lm on a full battery instead of the ~1200 I get from a D4S. They’re almost the same size, shape, and power level… but one is a lot brighter than the other, at the same temperature.
Also for some reason (maybe the same reason?), this light gets the “brighter on a low battery” thing a lot worse than most. Maybe it’s getting an unusually large portion of its heat from the driver instead of the LEDs? I’m not sure why, but it’s the same pattern I’ve seen on every MF01-Mini test.
If anyone was wondering about those small but sharp-looking stairstep adjustments later on in the graphs, they’re not actually sharp. Here’s a close-up of one. It took 32 seconds to adjust output by about 3, moving up one small step (0.39) every 4 seconds:
Each of those 8 steps is the smallest adjustment possible using the hardware’s PWM controls. The changes are not visible by eye during use.
MF01 Mini is difficult as the AMCs are a source of additional heat, its not so easy to compensate this in firmware, but a hardware solution is best with new Anduril code
Sounds like the same issues with the FTO3S link FREEME ✌ ASTROLUX FT03S SBT90.2 4500lm 1428m 26650/ 21700/ 18650 Flashlight - EXPIRED I guess that would be a good starting point.
I haven’t been involved in the FT03 at all… and I’m getting tired of companies completely ignoring the code’s license. It’s a “share and share alike” type of license, meaning anyone who distributes products using it must also make sure the exact source code they used is available to anyone who wants it… and is easy to find.
It’s not hard to comply with the license, and it costs basically nothing, but people still don’t do it. 
That’s the reason I only give to the manufactures files to test the basic functions on prototypes
and tell them to deal with you for license, my code not for sales lights
They got the drawings and 3D files for the copper/aluminum heat sinks and I hope they get that into production
and for future lights listen to me to make a plate that cools the AMCs in the design phase
Really best to avoid 7135's altogether. I thought there's enough designs around that do so?
Interested in 1 (one) piece.
Im interested in 1
So if we want to flash to this firmware, how do we go about doing it? Curious as to how it works in combination with the copper mod.
Updated OP (#1) and post #2, mainly information on the availability.
Most members who were on the list in post # 2 were supplied. I have now removed the list because there is only a small remaining quantity available. If you are interested, please contact me via PM.
you can also flash the driver to be FET+1 to avoid massive heat up by AMCs
I wish there would be a firmware UI on/off for this
Basically, get a flashing adapter and some free software, and the flashing takes just a few seconds. I think the adapters may be available from Lexel.
I don’t recall that ever coming up before. On a FET+N+1 driver, would people actually want to remove the “+N” part and make it less efficient?
This would eliminate the heat from the 7135 chips on this particular driver allowing for longer runtimes at more common brightness levels and no need to use this custom metal heatsink. Now that there are no more heatsink batches planned people might want a solution, even though it will be less efficient. Going FET+1 might even improve tint.
TK has shown some thermal improvements in her latest Andruil build. Is not not enough to count as a solution?
If no - maybe going with something like 50% PWM one the N array would be better than fully disabling it?
I haven’t tried so I don’t know for sure, but I suspect that disabling a bunch of FET chips wouldn’t help. Running in FET mode is less efficient overall, so it increases the total amount of heat generated for a given brightness. The main thing it changes is it moves some of the heat from the driver to the LEDs.
Adding copper inside increases the thermal mass, so it takes longer to get saturated and can stay on bright modes longer. However, it appears to stabilize eventually to the same level with or without the extra heat sink, since it doesn’t change the host’s ability to shed heat.
It would probably help to use higher-Vf emitters though, or a buck driver. Low-Vf with a linear driver mostly just means more extra voltage gets burned off as heat.
I've configured TA FET+N+1 drivers to be FET+1's before, just didn't populate the bank. On over powered lights, the bank is a problem. The FET's we use run as cool as a cucumber, but can't say the same for the Chinese knockoff's - TA did some testing on those, not sure how they do thermally, but he thought they performed acceptably, just not as good, but could be hit & miss.
There are 2 different factors here.
1. The 7135 chips are directly overlapping the MCU causing it to heat up prematurely.
2. The MCU software seeing the rapid heat increase and predicting it needs to lower the power.
Regardless of any software changes, the issue of the MCU thinking the flashlight is getting hot (when it’s not) is still going to cause the early stepdown. The only fix I see that makes sense is to physically reduce the premature heating of the MCU (deactivating the 2nd channel, physically removing the chips overlapping the MCU or adding the heat spreader).
I believe the software changes TK made are more focused on eliminating the pogo or oscillation effect of the brightness level, aka not reduce brightness too much then have brightness ramp back up. I think her new code has it drop a more reasonable amount and then be much more level.
As far as setting the 2nd channel to max out at 50% of its ability in order to reduce heat output, I dont know. If it makes the 7135 chips heat up half as much then maybe it would help. You could probably test it by setting the top of ramp to a lower level. Stock is 31 clicks, so maybe set it with around 50 clicks? This might require measuring the amp draw, unless TK or Tom knows what step would halve the output of channels 1+2. Once it’s set, you just test it out and see if you get a premature stepdown. If it works, you would need to change the Anduril code to limit output on channel 1+2 and bring in the FET sooner to compensate. I can’t modify Anduril code and I’m not sure the average person can either so I’m not sure how feasible this solution would be (assuming the tests results were good).