MF01 Mini / MT07- Mod/Upgrade - Copper Heatsink Cover Plate

ibeQuint · 2020-03-10T16:06:31.000Z

I’m in for one if there’s any still available!

man_of_light · 2020-03-11T08:18:35.000Z

ibeQuint:

I’m in for one if there’s any still available!

PM sent, updated list.

Guines69 · 2020-03-13T19:26:42.000Z

Interested. Thanks.

bird_eye · 2020-03-15T11:01:54.000Z

I’m in for one, please.

man_of_light · 2020-03-15T14:04:01.000Z

Guines69:

Interested. Thanks.

bird eye:

I’m in for one, please.

PM sent and updated the list

ToyKeeper · 2020-03-19T04:38:49.000Z

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.

Lexel · 2020-03-19T06:14:48.000Z

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

4492011 · 2020-03-19T19:25:44.000Z

ToyKeeper:

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.

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.

ToyKeeper · 2020-03-19T23:07:57.000Z

4492011:

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.

Lexel · 2020-03-19T23:54:03.000Z

ToyKeeper:

4492011:

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

Tom_E · 2020-03-20T00:02:18.000Z

Really best to avoid 7135's altogether. I thought there's enough designs around that do so?

aggalitsas · 2020-03-20T15:59:15.000Z

Interested in 1 (one) piece.

Darkspace · 2020-03-22T03:37:23.000Z

Im interested in 1

YogibearAl · 2020-03-23T08:37:36.000Z

ToyKeeper:

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.

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.

man_of_light · 2020-03-23T13:01:36.000Z

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.

Lexel · 2020-03-23T14:17:29.000Z

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

ToyKeeper · 2020-03-24T00:56:47.000Z

YogibearAl:

So if we want to flash to this firmware, how do we go about doing it?

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.

Lexel:

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

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?

JasonWW · 2020-03-24T01:57:15.000Z

ToyKeeper:

Lexel:

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

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.

Agro · 2020-03-24T10:17:05.000Z

JasonWW:

ToyKeeper:

Lexel:

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

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?

ToyKeeper · 2020-03-24T11:41:50.000Z

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.