If there is interest, I could add a no-FET build and possibly a version which uses the FET for more than one level. But first I should probably confirm that the base config works.
A no FET build would be amazing! Will save me 4 days trying to work out how to do it myself.
Great for my custom E21a builds. Ive seen tiny smoke before when ive grabbed the wrong light 
A Buck/Boost E21a with a 18500 tube is the dream!
Yeah, still 219B freaks here would go with reduced FET anytime
Hopefully there isnt actually a technical limitation to PWM FET as discussed before.
Ive got even more 219b FW3As than e21a, though often im using the 18500 2000mah cells which do a good job already without the PWM.
My kingdom for a 5A Buck/Boost driver with no FET 
Yes. Unfortunately due to the nature of the slightly complicated naming convention that osram uses, a few shorthand ways of referring to these emitters have come about. W2.2 = 2mm² 4040 aka Boost HX aka HX aka CULPM1⌠Iâm sure there are more.
Good, im not missing out 
. Mine are stuck in slow covid chinese mail though 
Yes it difficult to remember the codes. Owebon made an excellent graphic guide. 
.TG = White (6000K-65000K)
.23 = Red (612-630nm)
.14 = Blue (450-480nm)
.13 = True Green (513-545nm)
.F1 = Pure Green (554-566nm)
.FY = Yellow/Amber (580-595)
S = 3030
U = 4040
N = 1mm²
P = 2mm²
CSLNM1.TG - 3030 â1mm² -WF1
CSLPM1.TG - 3030 - 2mm² -WF2
CULNM1.TG - 4040 - 1mm² - Boost HL
CULPM1.TG - 4040 - 2mm² - Boost HX
That would be useful for me too.
Thanks for linking this. Couldnât find it earlier.
If you determine more than one level for the FET is workable, then awesome. However, if you try it out and observe unexpected behavior, be aware of the following, taken from the datasheet (page 13):
A no FET and a patial - PWM FET, if technically possible, would be great for people that use 219b. Unless full FET is deemed safe for a 219b setup with this driver.
Agreed, prtial and off would be great.
But as someone suggested above, 5A no FET would be a dream driver.
[quote=pol77]
A no FET and a patial - PWM FET, if technically possible, would be great for people that use 219b. Unless full FET is deemed safe for a 219b setup with this driver.
[/quote]
Actually, if you noticed, I've been running my original Lume1 build in a FW3C, with the 219B 'rosy' LEDs since the beginning of this project, and I haven't had any issues with Turbo mode at all (direct FET drive). However, I did make sure to reflow the LEDs as well as possible, and I made sure heat-sinking between the MCPCB and copper shelf was good by removing any burrs I found on the shelf, and replacing the thermal paste with a good quality one.
In fact, I usually do out-of-flashlight tests with a single Cree XML LED on a large heatsink - I found that Turbo on that single LED actually leads to phosphor damage. I can't guarantee that your 219B setup will work with direct drive, but it certainly hasn't caused any issues for me in my FW3C. I use a Samsung 30Q (pink) battery for this flashlight.
Huge thanks to ToyKeeper for rolling in the Lume1 modifications to Anduril2! I'll get started testing it out, and I'll be happy to provide config files for disabling the FET - this is indeed the easiest thing to do if you want to remove the Turbo feature.
For PWMing the FET, the Lume1 driver uses a tiny charge pump to drive the FET gate, resulting in a high performance Turbo drive. However, this causes a limitation in FET PWM which while not affecting things like 'party strobe' or 'tactical strobing', will limit the ability to PWM at high frequencies. As a result I do not recommend having PWMing on the FET, even though it is possible (with reduced PWM frequency) - this will require some config lines the config files to change the TCPWM for the FET line.
Finally, you all are also right that there is currently no software support for the four aux solder pads. I think it's worth playing around with the firmware to see if I can enable those solder pads to enable easy changing of features - at least disabling / enabling direct drive.
I always reflow the LEDs very well, making sure they have a perfect contact and no excess solder underneath. I use high quality PC CPU thermal paste. I have not used my FW3x lights on Turbo a lot, but the original FW3A used to be an XP-L and I have 219b emitters on it for ages, with the firmware it came with - no issues.
It seems like good reflowing and good thermal paste do make a difference.
I am now wondering if it is worth it losing the FET altogether, since PWM on the FET is not good. I will probably keep the lights running full FET 
Now hearing this i'm thinking the same, going full throttle.
As for heatsinking, i have soldered MCPCB directly to a copper shelf on 2 FW3C and 1 FW3B. I think it has a good heat transfer :)
219B
Whatâs your preference contactc? Sliced dogfarts?
High CRI is my only preference. I have 219B lights, hell I modded a 219B Emisar D18 but youâd think they were like ancient artifacts that need white gloves to handle. If someone kills one with one of these drivers you probably learned a good $9 lesson in modding and can simply buy more and learn from whatever mistake was made.
I canât help but see it as a distraction. The first thing people want from our hardware and software gurus is a way to bastardize an excellent driver before it has even been tested for what it is.
Iâll end my rant with that though. I know people are very attached to their LEDs and donât want to risk ruining them it just doesnât resonate with me. Iâve ruined so many things modding that this seems like a non issue, it comes with the territory.
I havenât done it yet⌠thatâs a few steps ahead. Hereâs how the plan looks at the moment:
- LoneOceans created a nice new driver.
- LoneOceans got Anduril working on the new driver, using an old branch of the Noctigon K1 code.
- I isolated the changes and adapted them to a current version of the FSM branch. (was necessary because the ADC and thermal code have been completely rewritten since the K1 came out)
- Test on real hardware to make sure adapted code works. <â weâre here now
- Merge changes into upstream FSM branch.
- Merge changes into Anduril2 branch.
- Test again on real hardware. (optional; changes should be pretty straightforward and low-risk)
- Finish Anduril2 (mostly just needs more documentation).
- Merge Anduril2 into upstream FSM branch.
- Publish builds for enthusiasts to try, and get more widespread testing.
- Merge into trunk.
- Send builds to manufacturers.
This would probably all be done already, but Iâve had very limited time to work on things lately.
Thanks for the clarification, will work on the updated branch :)