Lume1-FW3X: Constant Current Buck-Boost & FET Driver with Anduril1/2 + RGB Aux

For most switching designs, the power path goes through the main switching transistors and inductors; so for the case of this driver, the reverse-polarity power-path goes through the main buck-boost IC, through reverse body diodes in the switches, and through the inductor. As expected, this will cause the magic smoke to escape from the buck-boost IC, which is exactly what appears to have happened. Adding RPP will necessarily add resistance in this power path.

Gchart is right in that it's easy to add some reverse polarity protection, and there is in fact space on the board to do so, but at the cost of reduced DD-FET performance. I'll be happy to add that in for future versions if there is sufficient demand, but in initial discussions, the desire was to have the maximum amount of lumens in turbo mode...

Thanks for the reply guys. I’m certain that if there was a simple solution that it would have been thought of and implemented. Just trying to learn more in this area. For this driver, I like the decision to forgo RPP for the sake of efficiency.

….protection will decreases perfomance like ….1% or more? Maybe 1,4%? ;)) 20cent protection can save whole 25$ device.

we’re still talking about flashlight drivers, right?

Sure. Can you calculate losses? Turbo 5A, PFETs RDS On 7momh.

Depends on the LEDs. At 5 amps and 7 mOhms, that’s 0.035 volts being dropped. It really depends on the LED but for the sake of discussion, let’s say we’ve got a triple SST-20 4000K (this is a FW3A driver, after all).

I’ll use maukka’s data

  • At 5 amps that’s 1.67 amps per emitter with a total output around 467 lumens x3 = 1400 lumens
  • That’s ~3.058 forward voltage
  • If the PFET dropped 0.035 volts that leaves us 3.023 volts at the LEDs now
  • At 3.023 volts that’s now around 429 lumens x3 = 1287 lumens
  • 1400 - 1287 = 113 lumens lost

In this example, we lost around 8% of output (assuming I did any of this correctly). Not a huge loss, but for the enthusiasts in the crowd (the target for this driver), it’s not a small loss either.

I’ll step out of this particular discussion after this, but I’m responding to the stated values that range from ~5-25mOhm. At the regulated max of 3A ( which is the range I actually care about), that equates to roughly 50-250mW of waste. Running a triple SST20w (2.92Vf@1A), that’s a range of power loss between 0.5% and 2.5. Hypothetically the driver operates at 90 efficiency at this level/config, that would mean an increase in losses ranging from 5% to 25%.

It’s a matter of perspective, preference, and opinion. I’m just thankful loneoceans graciously contributed such a driver to the community and think it’s a great product any way you slice it. I look forward to future development of a range of high efficiency, open source, high power drivers.

Thanks again!

Flashlight that works on unprotected flattop high drain batteries without RPP ?!
You are crazy)
I just happy that get it for free and it already burned out without damage.
This is complete crap and not a driver. And thermalcontrol sucks here too. Thre is no LVP too.

Stabilisation?
Can not see any advantage of buck-boost.
Stock driver. 2.8A with cooling, ~3300cd

Lume 3A with cooling ~3100cd

Is there any other stock and lume driver efficiency comparisons?

I think my Lume1 might be defective.

When I turn it on in turbo it fairly quickly and abruptly steps down in a single giant step (dropping maybe to 50% output). Not gradual at all. Even on a fresh VTC6 or VTC5A it will only stay in max turbo 20 seconds at most. And sometimes much less than that. When it steps down from turbo it’s not a normal rampdown. It literally steps down in a single tick… no ramping at all. Double-clicking after this step-down results in the light turning to last memorized mode rather than going back up to full turbo.

I thought the problem might be a bad ground connection, but I took the head and tailcap apart and cleaned all surfaces with deoxit gold. This had no effect. The problem persists.

I thought the problem might be temp sensor settings, but I tried recalibrating them and resetting several times. This did not fix it. Also, I don’t think it is a thermal rampdown issue since if that is the case, there would be a smooth rampdown (even if over a very short period of time) rather than a single step.

It’s not as bad as some of my defective Zebralights, which occasionally stepped down in a similar manner sometimes in 10 seconds or less of being turned on.

But at the same time this behavior isn’t desired. And it’s also considerably worse than the stock FW3A driver. When I turn on my Lume 1 light alongside an FW3A with stock driver, the FW3A maintains turbo brightness MUCH longer, because the FW3A does not have that big stepdown.

I’m thinking of stripping the Lume1 out of my light and replacing it with the original stock FW3A driver since the stock driver just seems to work better.

It seems “normal” work I had turbo ~10sec on Lume with the same cd as on stock driver.

I have seven FW3 series lights.

And with the stock driver none of them ever exhibited a giant jump down like the Lume10. If I run any of those lights side-by-side with my Lume10 light all the stock driver lights stay considerably brighter longer. Only the Lume10 has that big step down that kicks in before the temperature regulation reduces output.

Thanks for calculation , so “120” lumen lost (but flashlight saved ) In reality you will need measuring tools to notice that . Specially in turbo splash for 20 sec. And if you need badly those “120” lumen you can always overcome Pfet with simple wire ;))
BTW. Spring looks good, but did someone test it with magnet :laughing:

Many thanks to everyone for the constructive feedback and criticism! I'm sorry to hear that some of you have had undesirable experiences with the driver; personally I only had one FW3 on hand when I made this driver (which was meant to be a fun personal project when I started!) and only later got another one, but it's good to hear feedback from different points of view. For the stepdown, this is likely due to thermal or ramp configurations, since the focus of the use case was more for the lower regulated modes instead of Turbo.

This driver doesn't PWM the FET by default which the regular driver does, which likely explains the behavior Firelight2 saw. I'll take a closer look at the thermal operation characteristics. The driver uses the base Anduril thermal throttling, with knobs to adjust in the cfg files. I've also had requests from people who didn't want Turbo modes, so it's a balancing act to figure out a default configuration that most people are OK with.

Yes, in next version, direct Nfet can be changed to protective Pfet ;))

Sorry my English.) I mean I had turbo during 10sec , with Lume driver.
Using stock driver turbo works much longer .

I made test of termal control of Lume1 configed on 60C

It works very slow. Reaction on fast temperature changes took about 5-10 min.

Please don’t forget that PID in anduril has been changed/improved couple of times. To compare stock fw3 driver to lume1 both should have the same version of software.

Perfect , thanks buddy

That sounds like it could be the problem.

With the stock driver, when the light begins to ramp down from turbo, the FET is PWM’d I think. So at the very start of thermal rampdown you get a gradual almost unnoticeable reduction in brightness before the reduction really picks up as the driver gets hot and the thermal sensor starts to massively reduce output.

But without PWM, the Lume 1’s turbo is basically FET on/off. The slightest reduction in output due to the thermal sensor turns off the FET and goes to much lower output regulated modes. This might be seen as a large jump down in output, followed by normal expected behavior.

Seeing as this was explained a few times in the thread, is in the datasheet, etc I think it’s normal expected behavior the entire time.