What would be the difference between buck-boost and a dedicated buck or dedicated boost when it comes to:
?
What use cases could it serve that are not achievable with buck or boost?
Could drive largely-outdated high Vf LEDs a little higher (XP-L, XM-L2, XP-G2).
Would better support multi-chemistry lights
Am I missing something?
I didn't tell anyone to replace his/her 7135 board with this. They're always free to choose by themselves. O:)
Why would someone want to replace a perfectly working 7135 driver with this? I mean, to replace a 7135 board there is already a step in between which is a MOSFET regulated linear driver (Convoy is offering many new boards of this class, for example).
Are we untapping a firmware addiction problem for many? 
If going sychronous buck-boost with four MOSFET bridge topology, you can try to implement bidirectional converter operation with integrated battery charger and powerbank function. Everything in one PWM control chip and one inductor.
That would be awesome.
The obvious drawback is the necessity of current path switching FET at the LED side of the converter. Converter direction switching can be solved automatically by plug insertion detection. Separate USB-C controller at the plug input can realise handshake with external devices and decide to act as a sink or a source…
Interesting… So max 900 - 1200 lumens depending on emitters used in the FW3A?
What can the possible efficiency increase of this driver be over the stock AMC only ramp configuration of the FW3A?
Ohh boy, if both this and the FW1A come to realization, that would be an absolute dream light.
Seriously? How about also adding dildo functionality a vibration motor, that's gonna be cool too. :-)
What are the implications of adding that much different functionality? Is this probably going off on a tangent? Not all flashlight hosts are designed with battery charging in mind, let alone power bank function. An USB connector takes up additional space. Concerning the power bank in a flashlight stuff, it is quite a superfluous thing imho. Any standard power bank does it a lot better. 
Subbed
That is single inductor and four switches.
SEPIC uses a single switch and dual inductors (which can be coupled for 2x effective inductance):
https://www.taiwantrade.com/product/high-and-low-current-coupled-inductors-420010.html
this will for sure drive popularity of 21700’s, with 26650’s becoming true enthusiast cells. LOL
Thanks everyone for the great feedback! 
Please keep them coming.
Here’s a quick response. I’d like to hear a little more thoughts specifically involving around input requirements (1S or 2S?), and likewise with output requirements (single-die LED at 3V? 6V LEDs?).
For a buck-boost, it seems like a 1S-only requirement makes the most sense, since there will be unlikely to be a need to have buck-boost for 2S flashlights – you’ll either really want a buck driver in those cases for 6V LEDs, or a boost driver for 12V LEDs, both drivers already exists, not buck-boost. Or am I wrong here?
Agro also makes a good point, perhaps a buck-boost may not actually be that useful compared with just a buck driver (already exists)? I think the extra benefit of a boost capability is allowing the driver to run the battery to really low, or with high V_fwd LEDs… so my question to you all is – is it worth it? I know there are side cases like running a 6V / 12V LED on single cells, but there exist dedicated boost drivers for those..
I suppose an alternative idea is a super-efficient >95% 1S 5A+ community buck driver. The thing is, regular buck drivers already exist - What else could I help to add value over existing buck drivers in this case?
Finally, I think the idea of CC switching regulator (say a 5A buck) + FET for turbo is an interesting idea. Credit to Agro for his suggestion. Efficiency and regulated output on all sensible modes, with FET for turbo fun…
Meanwhile, time to spend some money to get a FW3... any recommendations for Cu or Al version and which LEDs? This will be for driver development..
Constraints
I’d like to begin with constraints. I’m hoping to design a driver which is as simple as possible, using community firmware, and hopefully as easy as possible for the hobbyist at home to build. As a result, I do not plan to incorporate additional features like microphone etc. support which I have in my other drivers. This also means sticking with community MCUs (likely 841 or 1634, whichever TK and other developers have created), and this also means likely to not have ridiculous power handling capabilities like my GX drivers.
Efficiency
I’m sure many people have seen the ‘efficiency’ curve that comes with many drivers advertising how efficient FET+1+N is. I’m not really sure I understand it since it has no axes. Regardless, here’s a quick back-of-the-envelope calculation. For a sensible S2+ sized flashlight, typical thermal dissipation limits sustained operation at about 4 to 5W. Let’s pick an LED operating current of 1500mA, and a modern low V_fwd SST40 with a V_fwd of 3.0V at that current, at operating thermal junction temperature. In a linear CC driver such as one based on 7135s, the forward voltage drop is typically 120mV. Assuming no losses in the flashlight body, the driver stops maintaining regulation at 3.12V. Keep in mind that even if we have a magic battery that maintains 3.12V from start to end, we already intrinsically dissipate 4% of power in the V_fwd of the 7135.
Let’s now take the Samsung 30Q as an example battery, which a capacity of about 10Whr when it’s depleted to 3V at 1.5A (based on charts by HKJ). For the linear driver, we lose about (based on my rough calculation of the area of the curve) about 1.4Whr. The result is a about 115 minutes of regulated run time.
With a buck-boost driver, it’s not difficult to achieve about 93% average efficiency especially at moderate 1.5A currents. This value was from very rough simulations with a typical buck-boost converter, such as a TPS63802. We can run the cell as low as 2.7V, but let’s assume we cut the cell around 2.9 or 3V, giving us a total of 10.5Whr to work with. The result is 130mins of run time, about 15% more than the linear driver, which I think is a fair amount extra of runtime. Likewise, if we use a pure buck driver, we may be able to get slightly higher efficiency, and should lead to a similar overall efficiency).
The difference is even more dramatic if a higher V_fwd LED is used, or if the flashlight is running at lower brightness levels. I do agree that typically a simple buck driver would be sufficient for most cases especially with low V_fwd modern LEDs.. Anyway, I digress!
Physical Space
There is sufficient space for FW3x driver for a decent switching regulator with excellent efficiency. I believe I can make a two channel switching driver fit, but I don't think the LED board supports dual channels.. which brings us to..
Dual Channel Switching
Thanks for bringing this up. I like the idea of tint mixing with two regulated CC switching drivers. In fact, I think it would be nice to have something like a dual channel buck/boost/buckboost 2A-per-channel driver for a small tint-mixing flashlight. I sure can fit it into a FW3x flashlight driver size, even 17mm with a little finessing, but I’d like to hear more about the usability in terms of hardware. As far as I am aware, only the BLF lantern has hardware for tint mixing. The driver PCB for that is so big there’s no difficulty in designing a system for it. Sadly, I don’t think I’m aware of any small flashlight today which has provisions for two banks of white LEDs…. If there is I’d like to know please.
Software Porting
Like I mentioned, I don’t think I am able to commit to working on porting firmware to other MCUs, and I’d like to stick with community-supported firmware. I’m happy to work together with some of those folks to make a nice driver (e.g. slight code branches to support say 10-bit control to the switching regulator + maybe a FET). I’ll leave my custom firmware for the GX series drivers.
Programming
I’ve been using my PogoProg+ for my recent designs. http://www.loneoceans.com/labs/pogoprog/ - I have listed all the specifications there, but if people prefer the other standard by HarleyQuin, I will use that instead. It has a bigger footprint, but this is a community driver, so I’d like to try to accommodate what people want.
Thermal Regulation
I prefer a dedicated temperature sensor like a specific NTC or temperature IC, which I why I have them on all my GX boards. However, AFAIK there is no external temperature support for community firmware. I’ll be happy to work with BLF firmware developers to add external temperature support, but otherwise, we’ll have to stick with what’s already written (i.e. internal MCU temperature sensing which is less accurate).
Power Levels
I don’t plan any much more than 3A drive for a Buck-Boost. Remember, this is meant to be a ‘sensible’ driver. If you want more power, that’s what my GX series of drivers are for. I think there is room for discussion if we go a pure buck route, though.
Bidirectional Converter
Suggested by Windforce, good idea, but not practical in the target driver form factor especially since there is no output USB port. Fairly easy to implement, but isn’t practical here. I think it’ll be much more useful in a bigger form factor say the BLF lantern, which I think is already supported?
they exist but buck and boost drivers are somewhat difficult to acquire, especially at 17mm. I too agree that a buck might be just as good or very much good enough IMO.
Vibration is already implemented in some serious flashlights as silent and invisible battery level indication. This function is highly appreciated among hunters. Various blinkies and overcomplicated UI are just funny and barely usable in real world. Emergency power storage is strong functionality when using EDC flashlight in remote localisations. Single 21700 energy storage capabilities make it ideal candidate for emergency mobile power source.
High Efficiency Synchronous Buck-Boost Topology
1S to 2S operation (or… 4s?)
3A constant current regulated output, NO PWM
Ultra-low firefly mode
Open-source BLF firmware
Designed to be as easy to assemble at home as possible
You preliminary idea list pretty much nailed it. For my builds I’m still doing P60 dropins. This size and output if the board with components is thin enough would allow some nice practical builds. Host like Convoy S2, S2+, S6 etc. our EDC’s very nice idea.
Led4Power’s non-open-source drivers acoomodate an external temperature sensor which he also accomodates on many or all of the MCPCBs he sells. I think it makes the most sense to have a sensor on the MCPCB, and would like to see this come to open-source drivers.
lol
Subbed. I am looking forward to this.
Honestly I have mixed feelings about such sensors.
There are commercially available flashing kits from Emisar. I’m not sure if they are of HarleyQuin design or different but I think that availability makes them the best choice for a standard.
As far as I know there is only one BLF buck driver - and it’s for 2S-4S input.
There are several buck drivers from other sources but they all come with medieval UI.
So a super-efficient >95% 1S 5A+ community buck driver would be a truly uniqe offering by itself, there is nothing more needed to stand out.
Is a moon/low/mid/high driver medieval? Let it be. See ;-) below.
Do you actually believe you know what people wants?
Many people do not know what they want, let alone what is good or bad.
I've grown tired of seeing nice stuff going retarded thanks to listening to people's feedback and letting their ideas ramble without sense out of the original creator ideas in a ball busting way or sort of.
So do what you want. Go medieval. 