✌ FREEME - ASTROLUX MF01S 15000lm Flashlight Group Buy - ENDED

This reminds me, does it have the gap between “top of ramp” and turbo? Like steps 1 to 140 then jumps to 150? Will it be a small or big jump?

Yes, the ramp will end short of full turbo. This has proven to be the best setup over time for a few reasons. In this light an important one is how fast it heats up on full turbo. The top of the ramp noticeably improves the heat up time.

Far as how big the jump is, something around the last 10-15 steps sounds right. Visually it looks like what you would expect the next mode to be.

Interested.

No glue, please.

Interested

Hello Texas_Ace,

I just ask, if a 2S3P or 3S2P battery compartment were considered.

That would be only as thick, as a 1S3P compartment, just twice the length. That could be good for hand holding - but the flashlight body would lose the ‘soda can’ format.
Still, it would be a nice to have for longer runtime and less strain on batteries.

I mentioned several options along these lines but they were adamant that the basic form factor must remain the same as the first version. Not sure why.

That said there is nothing keeping future lights from being developed in other form factors. Although the triple 21700 format is not something I am itching to jump behind for a few reasons. Most were stated above, there are just not many advantages over a 4x 18650 setup and 18650’s are a lot more common. A triple setup is also a very odd voltage that is hard to use as well.

Interested!

Interested

This is the light you were asking about? I thought it was a GT variant of some sort.

There is a known bug, but it doesn’t involve slowly getting up to 100C… it’s something else entirely. The known bug is about responding quickly enough to the initial peak, and has nothing to do with what happens later.

The bug has an optional workaround called a “hard turbo drop”. However, the D4S does not use this workaround. It works fine as-is without any bandaids.

The code also seems to work fine on the Emisar D18, which is extremely similar to the MF01S, so I don’t think the issue is due to the overall type of light.

I haven’t been able to reproduce the slowly-rising-to-100C bug locally, and it doesn’t show up on any reviewers’ published runtime tests for existing lights.

I don’t have all the details, but from the limited information available, it sounds like it’s probably one or more of the following:

  • Not calibrated or configured correctly. PID systems oscillate when they’re not tuned right.
  • There could be insufficient thermal transfer from the emitters to the MCU’s sensor. If it was only sensing heat from chips on the driver, and not from the emitters, it would be inclined to drop while it has extra voltage to burn off, and then increase power when battery voltage gets close to emitter Vf. This could be the case if the driver is burning off extra voltage and the MCU is insulated from the emitter heat but not insulated from the driver’s own excess-voltage heat.
  • There could be something else related to the driver itself. I don’t know much about the driver in this light.
  • There could be something else changed in the code to introduce new issues.

Interested.

Interested depending on price

interested

Interested :slight_smile:

I asked Matemineco to fasten up the thermal response a lot this way, hope this will fix the firmware issue
a thermal Pad between MCU and copper cylinder

also clearly visible the LED shelf got thicker from the original MF01

If I understand correctly, most of the thermal transfer generally comes through the driver’s copper layers. This can happen through the LED wires and then through traces leading back to the MCU, and through the driver’s outer ring and the copper pours which lead back toward the MCU. Also from the regulator chips and their traces connecting to the MCU. Some heat can also come in through the MCU’s outer shell, but I get the impression it might be a relatively small factor. I haven’t found significantly different results when I place thermal transfer foam between the MCU and the emitter shelf, but I also only tried it once.

The behavior I heard about was a matter of oscillating gradually upward after the initial peak had passed. Oscillating is typically a sign of poorly-tuned PID, and I’m not sure what made it rise over time. I haven’t looked into it in detail because I’m not really involved in making this light and Mateminco hasn’t asked me to.

AUX LEDs can be controlled as in other firmwares like Anduril or NarsilM

Great, thank you! (I’m still learning about all the firmware options and types)

Interestede, depending on price

Yes, this is the light that was having issues, I was under strict instructions to not post anything about it, although I offered to explain it in a PM to you if it would of helped.

Ok, I stand corrected on the bug, in my defense you never gave much information on it other then to say you know about the bug :wink:

Far as the possible issues.

1: I have tried it both with the temperature calibration and without, same results. Although I am still lost as to how the temperature offset could effect the workings of the thermal system as a whole, seems like it would just offset the thermal control points.

2: I ran another test yesterday with thermal pads on the MCU giving it an almost direct connection to the body of the light and got the same results. It would of also wicked away any heat from the driver, although that is minimal.

3: The driver is the same basic layout I have been using for awhile, DEL helped me get it right so it is very stable. I also tried anduril on some other lights like the MT09R and it also overheated, just took longer since it has more surface area.

4: I have tried using the pre-made hex file from your repo for the D4S / D4 and got the same results with them as well. I also tried the changes you suggested to the code with no real change except slowing the process down. Overall the only things I changed in the code was added the new layout files, which were basically just copied D4S since they use the same pinout then changing the ramp for the higher output.

The thermal control works fine at first, it ramps down nicely and looks like it will maintain the set temp at first but then it just keeps ramping the power back up even when WELL over the thermal set point using the self reported blink out.

This is what has boggled me, why does it keep ramping the power up even when it knows the temperature is 100c via the blink out? It seems like it should lock it to the lowest output once the temperature is above the set point. If it would just lock it to the lowest mode when above the set point, or say ~10-20% above it, it would be fine.

I have tried this with thermal pads already, it actually seemed to make the problem worse as it overheated even faster then normal. Yes they are a bit higher thermal resistance then metal but still plenty to eliminate heat from the driver itself interfering with anything.

Although I doubt that is an issue since the self reported temperature from the firmware is within ~2-5c of the real temperature, and it is usually 2-5c lower then the real temp, not higher.

Indeed, the shelf is a lot thicker this time around.