Today someone released a Magic Smoke from lume1. Looks like this advanced driver have no simple reverse polarity protection!??
Hello Quadrupel, sorry to hear that happened. Unfortunately, precisely because this is an advanced driver specifically for hobbyists with an interest in DIY and modding, a conscious decision was made to not include reverse polarity protection. This is a simple add-on, yet looking at the effort people go to in order to maximize turbo brightness (spring bypass, choosing specific batteries with high V_fwd under load / lower internal resistance, etc), this will detrimentally affect the performance of the Turbo Direct-drive FET mode and introduce more resistance in the power path.
As I've mentioned before often, personally I'd prefer a driver without unregulated direct-drive mode, and additional features. However, at the moment I haven't got sufficient interest to build such a driver since these kinds of driver often don't have as much wow-factor on the spec list... hopefully we'll see more interest in the future and I'll be happy to work on something like that.
Wasn’t me , but i guess it should be written in manual to be cautious about it.
I was curious about this. After staring at the Lume1 boards for a while, I couldn’t figure out where RPP was happening.
I recently put together buck-only (no FET direct-drive mode) driver (completely untested at this point) and was on the fence on how to handle reverse polarity protection. I ended up putting in a SOT-23 PFET right up front in the power path. That’ll add ~26.5 mOhms of resistance. For my purposes, I’m willing to accept that. But if you were to do the same thing with a direct drive channel (and assuming my math is right… questionable), at 10 amps of draw with the same PFET, you’re talking about a 0.265 voltage drop across the PFET. So you’d be dropping a fair amount of voltage, not to mention the additional 2.65 watts of power that the PFET would need to be dissipating. Granted, if you have the board space, you could move up to a slightly bigger and more expensive MOSFET like this that has RDS (on) around 5 mOhm. Better, but as loneoceans said: any added resistance decreases performance.
I’m not an EE here guys, so be prepared for this to be a dumb question. Would it be possible for just critical components to receive RPP? Like a diode on the VCC/gnd pins of the MCU ? In other words, the RPP diode/pfet is on a parallel branch to the main current path?
I guess I’m in the dark about what components are going to give up the ghost when reverse biased in the present design. Any clue what’s going to fry and what’ll be safe?
Also not an EE but I’ll voice what I think I understand. In some drivers, like a lot of the direct driver or linear ones… absolutely. We protect only the MCU; pretty much everything else (FETs, 7135’s, etc) survives reverse polarity just fine. In a switching regulator (boost, buck, buck/boost), the controller needs protected, but frequently the control circuity’s power feed is shared with what gets piped to the inductor and thus to the LEDs. So you would end up needing to protect the whole thing, which is going to add some level of resistance in the power path.
Ouch! That driver is toast.
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.
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.
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
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.