Since it will be using Narsil with ramping you can set it to any power draw / lumen output you want pretty much.
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.
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 4× 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.
I REALLY want to use Anduril firmware on this light but …
This is the light you were asking about? I thought it was a GT variant of some sort.
Texas_Ace wrote:
slowly get up to 100c+ … a bug in the code itself that TK has known about for some time. She was able to bandaid the issue for the D4S but for a large light like this it seems the bandaid does not work.
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.
I REALLY want to use Anduril firmware on this light but …
This is the light you were asking about? I thought it was a GT variant of some sort.
Texas_Ace wrote:
slowly get up to 100c+ … a bug in the code itself that TK has known about for some time. She was able to bandaid the issue for the D4S but for a large light like this it seems the bandaid does not work.
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.
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
I asked Matemineco to fasten up the thermal response a lot this way, … a thermal Pad between MCU and copper cylinder
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.
Lexel, will the aux LEDs be adjustable or be able to be completely disabled from the main firmware, or only from the trimmers on the aux board? And if it’s just the aux board, they better make sure not to glue it!
AUXLEDs can be controlled as in other firmwares like Anduril or NarsilM
Lexel, will the aux LEDs be adjustable or be able to be completely disabled from the main firmware, or only from the trimmers on the aux board? And if it’s just the aux board, they better make sure not to glue it!
AUXLEDs 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)
I REALLY want to use Anduril firmware on this light but …
This is the light you were asking about? I thought it was a GT variant of some sort.
Texas_Ace wrote:
slowly get up to 100c+ … a bug in the code itself that TK has known about for some time. She was able to bandaid the issue for the D4S but for a large light like this it seems the bandaid does not work.
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.
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
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 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
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.
That’s a really interesting test, especially with the thermal pads involved. I wonder how it would behave with newer code, because it has changed a lot since then.
The Samsung INR18650-30Qx2 I have been ordering through BLF Banggood offer (page20) says flat top unprotected but the BG page says protected but the length are short, so that is just a fault right?
The Samsung INR18650-30Qx2 I have been ordering through BLF Banggood offer (page20) says flat top unprotected but the BG page says protected but the length are short, so that is just a fault right?
The Samsung INR18650-30Qx2 I have been ordering through BLF Banggood offer (page20) says flat top unprotected but the BG page says protected but the length are short, so that is just a fault right?
I’m pretty excited about this one, great grouping of features with the AUXLED and Anduril. I think the SST20 should manage to output a very postive runtime.
I’m not concerned that the MF01S isn’t the brightest or smallest soda can on the block. I already own an Acebeam X80 with 12x CREE XHP50.2,2x CREE XPE2-R2 630nm, 2x CREE XPE2-B4 475nm, 2x CREE XPE2-G3 530nm, 1x Nichia 233A 365nm. I’ve also got 4 ROT66 with SST-20, XPL-HI, and 219b emitter groups. IMO it’s really about features in this classification.
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?
Texas Ace Lumen Tube and JoshK Sphere calibrated with Maukka lights
Click this to go to signature links. I'm still around, just not reading many new threads.
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.
Texas Avenger Driver Series
My LED Test series - XP-L2 V5 - Nichia 219C 90+ CRI - Latticebright "XM-L" - XHP35 & PWM efficiency - XHP50 - XP-L V5 - XM-L2 U2 - XP-G3 S5 - XP-L HI V2 - Oslon Square & direct comparison to Djozz tests - Nichia 319A - Nichia 219B 9080 CRI - Nichia 219C D320 - Nichia 229AT - XHP70.2 P2 - XHP50.2 J4 - Samsung LH351D
Easy comparison tool for all my LED tests
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 4× 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.
Texas Avenger Driver Series
My LED Test series - XP-L2 V5 - Nichia 219C 90+ CRI - Latticebright "XM-L" - XHP35 & PWM efficiency - XHP50 - XP-L V5 - XM-L2 U2 - XP-G3 S5 - XP-L HI V2 - Oslon Square & direct comparison to Djozz tests - Nichia 319A - Nichia 219B 9080 CRI - Nichia 219C D320 - Nichia 229AT - XHP70.2 P2 - XHP50.2 J4 - Samsung LH351D
Easy comparison tool for all my LED tests
Interested!
FL Newbie
Interested
Nokoff..still Made in China 山寨主義
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:
Interested.
Interested depending on price
interested
Interested
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
[Reviews] Miboxer C4-12, C2-4k+6k, C2, C4 / Astrolux K1, MF01, MF02, S42, K01, TI3A / BLF Q8 / Kalrus G35, XT11GT / Nitefox UT20 / Niwalker BK-FA30S / Sofirn SF36, SP35 / Imalent DM21TW / Wuben I333 / Ravemen PR1200 / CL06 lantern / Xanes headlamp
[Mods] Skilhunt H03 short / Klarus XT11GT, XT12GTS / Zebralight SC50+ / Imalent DM21TW / colorful anodisation
[Sale]
Drivers: overview of sizes and types
DD+AMC based drivers Anduril or Bistro OTSM 12-24mm, S42, 24-30mm L6, Q8, MF01(S), MT03, TN42
Anduril or Bistro 8A buck driver for 20-30mm, MF01/02/04, TN40/42, Lumintop GT, MT09R
UVC and UVC+UVA drivers
programming key
Remote switch tail DD board with FET
Aux boards:
Emisar D1, D1S, D4, D4S, D18, Lumintop FW3A, Fireflies ROT66, Astrolux MF01, Tail boards like S2+
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
[Reviews] Miboxer C4-12, C2-4k+6k, C2, C4 / Astrolux K1, MF01, MF02, S42, K01, TI3A / BLF Q8 / Kalrus G35, XT11GT / Nitefox UT20 / Niwalker BK-FA30S / Sofirn SF36, SP35 / Imalent DM21TW / Wuben I333 / Ravemen PR1200 / CL06 lantern / Xanes headlamp
[Mods] Skilhunt H03 short / Klarus XT11GT, XT12GTS / Zebralight SC50+ / Imalent DM21TW / colorful anodisation
[Sale]
Drivers: overview of sizes and types
DD+AMC based drivers Anduril or Bistro OTSM 12-24mm, S42, 24-30mm L6, Q8, MF01(S), MT03, TN42
Anduril or Bistro 8A buck driver for 20-30mm, MF01/02/04, TN40/42, Lumintop GT, MT09R
UVC and UVC+UVA drivers
programming key
Remote switch tail DD board with FET
Aux boards:
Emisar D1, D1S, D4, D4S, D18, Lumintop FW3A, Fireflies ROT66, Astrolux MF01, Tail boards like S2+
Great, thank you! (I’m still learning about all the firmware options and types)
List of my reviews over at 1lumen.com
~~~~~~~~~
oweban.org
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
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.
Texas Avenger Driver Series
My LED Test series - XP-L2 V5 - Nichia 219C 90+ CRI - Latticebright "XM-L" - XHP35 & PWM efficiency - XHP50 - XP-L V5 - XM-L2 U2 - XP-G3 S5 - XP-L HI V2 - Oslon Square & direct comparison to Djozz tests - Nichia 319A - Nichia 219B 9080 CRI - Nichia 219C D320 - Nichia 229AT - XHP70.2 P2 - XHP50.2 J4 - Samsung LH351D
Easy comparison tool for all my LED tests
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.
Texas Avenger Driver Series
My LED Test series - XP-L2 V5 - Nichia 219C 90+ CRI - Latticebright "XM-L" - XHP35 & PWM efficiency - XHP50 - XP-L V5 - XM-L2 U2 - XP-G3 S5 - XP-L HI V2 - Oslon Square & direct comparison to Djozz tests - Nichia 319A - Nichia 219B 9080 CRI - Nichia 219C D320 - Nichia 229AT - XHP70.2 P2 - XHP50.2 J4 - Samsung LH351D
Easy comparison tool for all my LED tests
To this thermal pad thing:
I tried silicone thermal pad with Andúril in my D1 long time ago. Here is the thread about the results.
Reviews: Olight Seeker2 pro, Lumintop GlowI, Sofirn SP36, Convoy 4X18A, Convoy M21C, Brinyte SR8 Rescue Angel, Astrolux MF01 mini, Astrolux FT03S, YLP Sherp S15, Sofirn SP40, YLP Panda 3R and Unicorn, Armytek Prime C1 Pro, Acebeam M50, Imalent MS18, Convoy M3, Nitecore TIP2, Imalent RT70, Wuben T70, Sofirn SP32A, Thorfire VG15S, Thorfire VG10S, Thorfire TG06S
Mods: Imalent MS18 dedoming, Astrolux MF01-20K, Small sun T08 MT-G2, Eagle eye X6 triple XPL, Ultrafire F13 MT-G2, Convoy C8 XHP70, Solarstorm T3 triple XP-L HI
Big flashlight measurement and beamshot collection
3D printing stuff for flashlights
My flashlight related Instagram
My Flashlight related Youtube channel called Zozzlights
Maybe there is time to step up with another atmel with more I/O pins and use external NTC placed on the MCPCB like on led4power led stars.
Reviews: Olight Seeker2 pro, Lumintop GlowI, Sofirn SP36, Convoy 4X18A, Convoy M21C, Brinyte SR8 Rescue Angel, Astrolux MF01 mini, Astrolux FT03S, YLP Sherp S15, Sofirn SP40, YLP Panda 3R and Unicorn, Armytek Prime C1 Pro, Acebeam M50, Imalent MS18, Convoy M3, Nitecore TIP2, Imalent RT70, Wuben T70, Sofirn SP32A, Thorfire VG15S, Thorfire VG10S, Thorfire TG06S
Mods: Imalent MS18 dedoming, Astrolux MF01-20K, Small sun T08 MT-G2, Eagle eye X6 triple XPL, Ultrafire F13 MT-G2, Convoy C8 XHP70, Solarstorm T3 triple XP-L HI
Big flashlight measurement and beamshot collection
3D printing stuff for flashlights
My flashlight related Instagram
My Flashlight related Youtube channel called Zozzlights
That’s a really interesting test, especially with the thermal pads involved. I wonder how it would behave with newer code, because it has changed a lot since then.
The Samsung INR18650-30Qx2 I have been ordering through BLF Banggood offer (page20) says flat top unprotected but the BG page says protected but the length are short, so that is just a fault right?
BG page
30q are not protected, i guess wrong yea..
...where Frugal meets with Flashlight!
つ ◕_◕ ༽つ
You can buy protected 30Q if you want to, but this particular ad just seems mislabeled.
Texas Ace Lumen Tube and JoshK Sphere calibrated with Maukka lights
Click this to go to signature links. I'm still around, just not reading many new threads.
Interested, hopefully orange or clear.
Interested
I’m pretty excited about this one, great grouping of features with the AUX LED and Anduril. I think the SST20 should manage to output a very postive runtime.
I’m not concerned that the MF01S isn’t the brightest or smallest soda can on the block. I already own an Acebeam X80 with 12x CREE XHP50.2,2x CREE XPE2-R2 630nm, 2x CREE XPE2-B4 475nm, 2x CREE XPE2-G3 530nm, 1x Nichia 233A 365nm. I’ve also got 4 ROT66 with SST-20, XPL-HI, and 219b emitter groups. IMO it’s really about features in this classification.
Nokoff..still Made in China 山寨主義
Interested.
My reviews:
ROFIS R3 Multipurpose light , ROFIS MR50
Pages