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

Understand, and thanks for checking. I guess there is no service equivalent to Oshpark for PCB assembly in small quantities?

I’ll be following this thread to see if a perhaps a group buy is ever possible.

I know he’s using a p-fet. I worked on something similar and used a p-fet as well. I ran into the problem that the current of the boosted voltage goes through the body diode back to the cell, rather than through the led. I found a solution to that, but I can’t see how he is doing it on his board.

Hello all, thanks for the kind words everyone!

Regarding the firmware, I’ve got the external temperature sensor to work and it’s a fair bit more accurate out of the box. In fact, I believe I have tested all the features of Anduril as much as possible (though I probably missed out something!), and they all seem to be working.

Answering Tom E with some updates, yes it supports smooth ramping and looks visually identical to the stock driver (see the YouTube video of the preliminary test). I’ve completed the cfg and hwdef files for this driver. There are some very slight optional modifications I made to some fsm-__.c files which I will be documenting in detail, in order to support some extra features such as the external temperature sensor. I stuck with 150 ramp levels, but the control resolution is 10bit instead of 8bit (1023 vs 255 levels), similar to the Noctigon K1. So far, I have configured the ramp tables to have the ramp for the first 3 amps, then the FET kicks in for the double-tap-to-turbo. Keep in mind Anduril isn’t just limited to 255 levels; it’s not difficult to change it to support 1023 levels as long as the hardware is capable. However, increasing the PWM resolution will reduce the PWM frequency, which can cause a little more visible flicker, though at 3.9kHz, I doubt it’ll be a problem for almost all use cases. I’ll put the firmware up on the TK flashlight repo. Just making sure it’s mostly free of bugs right now.

Replying WTF, for driver sales, if there’s a good response, I am actually considering having a small run of assembled boards be made, but I need to make sure it’s got the bugs worked out first. In addition, all files will be published so anyone can make their own as well if they’re interested. I'd also like to hear the reasoning for having additional B+- and ESW pads on the board - what use case are you planning for these? Finally, yes it's very easy to have a version without the FET at all. This can be done simply by either having a run of boards without the FETs installed, and/or flashing the board removing the hwdef for the FET pin. Meanwhile, firmware work is well underway - I actually found a few more small issues and have fixed them!

Next, Schoki knows exactly what’s going on! You’re correct this was something I did miss initially when designing the boards, and didn’t catch it until PCBs were fabricated; this was because in practical use of most designs, the BuckBoost is only operating in buck mode for almost the entirety of the drive range, and when it hits Boost mode, no reverse conduction occurs for my setup. Here's why: LVP cuts out at 2.8V, limiting the lower end of the Vin. For FW3x systems with a 3 LED config at 3A, Vout doesn’t get much more than 3V. Then the key is the bias voltage of the body diode (IIRC around 0.35+V) - together with the low Vfwd of the LEDs used, reverse conduction does not occur.. but just by a whisker. However, you’re absolutely right that a higher Vfwd LED with low Vbatt can start running into reverse conduction of the body diode of the pass fet. This has been fixed in Rev B which is the planned driver for a small mass-order.

As a side note, I’d like to emphasis that having a FET to drive an LED is strictly not a great ‘text-book’ idea, likewise with paralleled LEDs! LEDs are inherently negative temp-co devices meaning that Vfwd of LEDs decreases as junction temperature increases, leading to the LED consuming more and more current until failure. In practice though, with matched LEDs and with system losses, this all works.. but just keep in mind that it isn’t strictly best practice to do so.

Thanks again for your continued interest and support!

I think we should start a sign-up google doc for these. I think the method clemence is using for this Skilhunt GB is a nice way to manage it.

And keep the discussion going folks! I love it :+1:

Thanx for the info! Oh boy, you went way deeper than what I meant, but it's all good. I think I was the one that came up with 150 levels originally for NarsilM (I could be wrong), but I only chose 150 because of the timing. With the levels changing every 16 ms, 150 levels means a full ramp takes 2.4 seconds and I thought that was just right for a light like the Q8, not too quick, not too long.

Just to make it clear, so this driver has buck/boost regulation up to 3 amps, and only ramps up til 3 amps? So it doesn't PWM the FET at all and turbo is assigned to max FET? If so, this is much more smoother than existing Anduril/NarsilM drivers that are FET based.

So if you adapted this design to a much larger Q8 size driver, you could use larger components that could regulate to higher amps? Not sure if you looked at options in detail yet, but might you know how high it can go keeping the cost within reason?

The reason I’d like bat+ and bat neg on the component side of the board is that I’m planning on putting this driver in something other than a FW3A as well as making testing easier. I have some 20+ 2835 and 5730 led battery powered lights that this driver would be perfect for. The vf on the leds is high enough to make them dim before the batteries are discharged and getting rid of the blue and red blinky modes would be nice. The spring side of the driver would be facing the heat sink and spacing it up to clear the wires would push the driver into the battery compartment. I can get by without the pads, should be enough space to solder wires to the input capacitor or scratch some solder mask away in the right places.

I’m excited.

It looks like three amps is maximum output for the buck/boost controller. He could put multiple controllers on one driver but the outputs would have to be separated which would require modding the mcpcb. The other thing is the direct drive fet is a p-fet which have more on resistance than n-fets and likely a sense resistor in the circuit as well. You’d be trading off a lot of turbo output for a little more regulated run time.

Ideally loneoceans gets time to finish his 100 watt boost driver and you find a way to wire the leds 2s2p. You’d get high efficiency at low power levels and stupid amounts of output on turbo.

Tom E, yes I figured the 150 levels was chosen as a generally good balance between ramp duration and ‘smoothness’. The only time when the ramp is a little less smooth can be in muggle mode where the ramp length is truncated.

The Buck Boost (at least for the FW3x board) is good up to 3 amps - mostly due to PCB constraints and to keep the design cost down. The FET control pin can also be PWMed, so it’s pretty easy to configure the ramp files to extend the ramp to PWM the FET as well. However, the thing about the FET drive is that it’s literally unregulated. If using a combination of FET + regulated, there will be some sort of jump between maximum regulation and some sort of PWMed FET drive, which will vary depending on the LED and battery used. The same applies to 7135 + PWMed FET.

The idea of unregulated FET drive still is concerning to me from an EE point of view, so I thought it would be best to leave it as a single turbo level. Regardless, this is easily adjusted in the cfg file, so you can certainly transition from max regulated level to some sort of PWMed FET ramp. I have experimented with using a 8bit 15.6kHz PWM and a 10bit 3.9kHz PWM for the Buck Boost (and also for the FET), and I think I prefer the 10bit 3.9kHz PWM – note this does not translate to PWM for regulated output (there’s a caveat for the low moon modes but that’s a different thing), and I think 3.9kHz for most purposes is just fine (only if using FET in PWM mode). This can also be changed in the hwdef file. I’m really not sure what people will prefer, I guess.

Oh and I should mention, the Attiny needs to be able to support >8bit PWM if you want to have 10bit PWM of course... IIRC, the Attiny85 only has 8bit TCPWM blocks, while the 1634 adds a 16bit PWM block. This is why most other drivers have only 255 levels of PWM resolution for their 7135s. I suspect going forward with more 1634s in drivers, we may see more 1023-level PWMs, but potentially at the cost of lower PWM frequency - can be mitigated with a faster external clock, though..

If I had more board space, it’ll be easy to scale up the buck boost (or just use a buck or a boost, quite easily done for very high power levels) and we should be able to get full regulated output with much higher power handling capability. I built a buck converter for one of my high voltage projects which handles about 52kW peak, for example, but that’s another story. I’m not familiar with the Q8 though, and I’m not sure if I have plans to work on that just yet. The 100W boost driver is working, but it's very expensive. The GaN FETs used are $7+ per piece in 1x quantity, and you need 2 of them, plus the rest of the BOM cost. I'm not sure if it's worth it for most people. I had to bypass the entire flashlight body with a copper ribbon from a Samsung 30T cell. The general point of the GXB drivers was to boost from a single cell at very high power levels. If the flashlight was 2S or more, there are a lot more practical, less silly designs, and much cheaper designs that can be done .

Pretty keen for this, especially if there’s a small run of completed drivers available. The primary issue with the DIY method is economies of scale in getting the components (as well as hoping a solder stencil would be available), then throw in being on the “wrong” side of the world… ouch.

Very aware that economies of scale is a double-edged sword though - getting a manufacturer to make a bunch would bring the costs down, but at the same time, they’d need a guaranteed MOQ to make it worth their while. Then you throw in quality control…

Having the hwdef ready is a BIG plus :slight_smile:

Just did inventory check and it looks like i'd need 7 of these drivers

Unregulated FET drivers are also an issue for me. 3 amps of high efficiency regulation is enough power in any 18650 light I own. I think my lights get used on moonlight and ~30% most of the time, so high efficiency and user interface options are much more important than sheer lumens.

I’m not sure where I stand exactly on this FET issue. I’m aware that it’s not a ‘proper’ design, but as a BLF corrupted enthusiast, I like having a direct drive Max option in most lights. I’ll rarely use it myself in my EDC, but the few times I do still makes it valuable to me. I’m used to matching cells with emitters to optimize useful runtime and limit peak output, so this doesn’t bother me personally. Lastly, it’s hard to argue with the cost and simplicity of packaging for really high output.

With that said, there is a practical limitation to ‘turbo’ power in a torch like the FWnx. 8A would be extremely sufficient in this light on strictly a thermal basis. Add in the low power capability of many of the ultra high CRI LEDs that find their way into such a form factor, and it becomes a requirement. This makes me wonder if using a linearly regulated FET like the new Sst40 drivers from Convoy makes sense? Could it fit? I’m not an EE, but I feel like there’s enough real estate to cram a few more passive components to support such a configuration. I might be way off base though!

For larger lights and our “toy” builds, DD-FET isn’t going anywhere soon. But I could say goodbye in this application.

Thanks again! Looking forward to it either way. I’ll officially sign up for two, and reserve more if it’s affordable to me.

Sounds exciting! Would there also be a way to limit turbo/fet?

I'm with JaredM on this - still much interested but agree about the FET designs here on BLF. The good thing is this driver does have the FET, so best of both. I personally might want to mod this Anduril setup for ramping through the FET though, but only if there's a clear UI distinction between max regulated, and start of FET ramping. Anduril supports that, think couple ways - one way thru an AUX LED, other with a pause/flicker (I think so anyway).

I'm not a fan of the FW1x/FW3x family though:

  • gave my wife a customized FW3A and the accidental activations rendered it useless for her
  • I'm not a fan of a tail switch, never was
  • also not a fan of smooth, slippery designs
  • doesn't give thermal design even a wink - ok, to be fair, not many of our BLF lights do though as this light's priority is compact size and light weight carry
  • lacks the AUX LED for Anduril's control

I prefer the EDC18 and it's been my true Every Day Carry for months now. Though I haven'd had a look, it supposed to have the same driver as the FW3A. So for me, the EDC18 would be my preferred host for this driver, and hoping I could get the switch LED wired up as the AUX LED for Anduril.

Tom, if you haven’t tried the o-ring switch mod, you really need to. I was one of those who watched the FW project from the original post. Bought four as soon as I got the code. A week into owning them, I quit carrying it because of accidental activation. I developed that mod and it changed everything. E-lockout or mechanical lockout was not going to fly for me - no way. I am partial to a tail switch though, especially on longer lights, so we differ there. Though under 100mm side switch gains ground fast ergonomically.

I agree on the slippery design as well. This is something that really bugs me about most EVERY light these days. I miss the days of the old Nitecore ‘road-rash’ knurling. I think it looks awesome as well. Another thing is the clip. Damn me for not knowing why after all this time we’ve worked with manufacturers to build custom lights why every BLF light doesn’t have a real, quality, deep carry clip. Convoys as well… still missing good clips in 2020. YMMV

AUX leds are something I’ve not yet gotten into, nor see a purpose for. I feel lighted tailcaps/switches are practical as a beacon or charge indicator, and can serve as a nice reminder to lock lights out before storing them. AUX are cool though, especially tune-able RGB. I’m willing to change my opinion if there is a practical use.

Back on topic, I do think this driver can be hugely popular, and having a design for side e-switch (first) and a clicky version will also be in demand.

Strange bout the big lights better with tailswitch - heavy lights are easy one handed operation with a properly placed side switch - tail is awkward at best, worse requires 2 hands.

Ooops, by AUX LED I mean same thing as switch LED. Again, 'AUX' was a term we used to indicate an auxiliary LED, where-ever it's mounted.

A side switch LED can be seen with the light off, whether it's standing on it's head or tail.

Totally agree bout the deep carry clip - I just don't get it...

Let me clarify that the ‘long’ was still within the realm of EDC lights. So things like a Convoy M2 or S21A at the largest. FW1A is the lower limit in length for me to distinctly prefer a tailswitch. Anything longer than a “tactical” ~150mm or fatter than a single cell is back to side switch for sure. I’d really like a lighted side switch with charge indicator and adjustable beacon brightness.

And yes, “AUX” technically could mean any location. Thanks for clearing up what you meant.

FET/DD may not get you an “A” on your EE project :smiley: , but it’s inexpensive, compact, and reliable even for very high power builds (as long as the emitter/battery combo is chosen well). IMO that makes it an elegant solution.

I mostly agree…though for me to call it elegant it should have a linear mode. :wink: