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

This is really exciting. The only drawback with the FW3A and similar flashlights with linear driver is the poor efficiency. With this buck boost constant curent regulated driver that problem will be solved and the FW3A will become a real EDC tool and not just a toy. I wish Lumintop would sell a special batch with your driver.

Please note that so far none of the loneoceans driver was available for sale. Though there’s hope it will change myself I wouldn’t purchase a light before that happens.

Another great peace of work from you loneoceans :+1: . I have one simple question to that driver. Is that will be fully open source or only partial of it? I mean if you will share whole PCB project with source files with full schematic or only gerber files like in anothers of your projects.
Also the best improve over firmware for Anduril is the support of 1024 PWM levels compared to 255 which don’t allow us to use fine steps especially at low modes for LED current regulation in one channel driver.

Excellent work loneoceans. Coming from the GXB172 its hard to believe everything fits on one side of the board with so much space left over.

This driver has so many possibilities beyond the FW3A. Do you think future versions could have pads for Bat+, Bat- and an E-switch on the component side of the board?

Will there be a version of Anduril available that does not use the direct drive fet?

Could you release your preliminary firmware? A few simple modes work best in some applications.

A few people have been asking about using clicky switch firmware with this driver although it would require significant modifications to Bistro and Ramping IOS. Would the input capacitor be able to be used as an off time capacitor?

I have a question: If the IC (I assume it’s a TPS63020) boosts voltage to let’s say 5V, and your battery is 3V, how do you avoid all the current flowing through the p-fet body diode back to the battery?

Presume he used p mosfet as load switch: http://www.farnell.com/datasheets/2049687.pdf
So if it is will be trully open source hardware that will be great. We can improve it or port to another flashlight very easy.

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?