Great idea, good luck with project. I find high-efficiency like Zebralight very interesting
Subscribed. Very interested in this driver for headlamps and especially for those very low vf leds like e21A. If tint mixing can be implemented these would be awesome with clemence’s quadtrix boards.
A super-efficient >95% 1S 5A+ community buck driver would be great!
Subscribed!
What I like most about buck-boost drivers is the predictable, flat output they produce. Keeping it "sensible" sounds good. Souped-up performance is a low priority for me.
That said: a high current powerbank that re-uses the inductor would push it to another level. 
Hello all,
Thanks again for the feedback.
Regarding thermal regulation, the on-board MCU as used in most firmware does have enough precision, but as Agro mentioned, it has poor out-of-factory accuracy (10 deg C). The firmware overhead to include a sensor (both flash space and code) is very minimal though, and I have some ideas of some very low powered and easy to use sensors. The MCP970x is one such example, among others. This 25 cent part can easily be a no-stuff option to really keep the cost down, though.
For programming, I see the re-flashing kit provided by Intl-Outdoors. I’ll be happy to implement that support in this driver, instead of my pogoProg+, but it definitely needs a bit more documentation before it becomes a standard, and it would be good to include some protection on the programming as well. At the very least, there needs to be a simple recommended pad drawing and tolerances. I’ll be happy to follow up with Intl Outdoors for the specifications.
For power-bank functionality, like I mentioned, not difficult to implement, but not quite relevant for this particular product. I think this would be a better feature in a larger form factor, say in lantern.
Regarding tint mixing, it requires sufficiently different hardware that I’ll reserve that discussion for a separate thread and product. Fairly straightforward to build a two channel buck driver even on a 17mm PCB, but also requires community firmware support, some new ideas about UI, and dedicated MCPCBs to support. I’d like BLF to imagine a nice compact E21A tint mixable flashlight that gives super high CRI from 2700K to 6500K, though.
Based on the feedback I’ve got and discussions with some members here for feature-set and firmware support, I’ve a game plan for this project. For now, keep the suggestions coming!
I have some candidate flashlights on order and a little more feature-set refinement to do on my part. Hopefully in the next update in the coming weeks, we’ll have a prototype driver that you all will enjoy. I hope to be able to send a few of them out for evaluation and feedback, before finalizing on a version 1 design.
Cheers
Make a 14.x to 17mm AA NiMH/14500 buck boost that can run on BLF firmware. There’s already hundreds of posts on just one such light.
BLF firmware w/ constant output and no PWM would basically make it unmatched in the market. At least as far as i’m aware.
Thanks for the link contactcr!
I looked through the post, looks like a fun exercise. There's lots of ways to go about building that driver, don't think there are any particular difficulties.
In fact, given how large the driver cavity is to accommodate the switch, I don't see any issues implementing a dual-chemistry constant current switching topology. There are few ways to go about doing this but would be pretty easy to fit say a Anduril-compatible ATtiny (which should again be quite easy to determine the cell chemistry and adjust power modes accordingly), and run say at 1W for AA/NiMH in boost, and 3-5W for Li-ion in buck mode.
One example solution (this is just my immediate reaction with no additional homework) is to use a low voltage synchronous buck-boost e.g. MP28164, and we'll only need a single current-based feedback to the LED regardless of chemistry mode. Startup voltage can be supplied via a separate very small low voltage boost or charge pump, of which there are many on the market with very high efficiency and very low quiescent current with low cost. This also powers the MCU, and a little bit of optimization with the design should allow for very good standby life. Should be easily capable 3+W output with a Li-ion cell. Total PCB space is minimal.
If double-sided assembly is OK with a 4 layer PCB, I think it's possible to get away no components on the switch board. I mean you could even add a FET for an extra 'boost' mode on lithium chemistry if regulated output is not enough. The flashlight will definitely overheat real quick, though. There are other issues then, such limited thermal coupling between the MCPCB and the driver, for example..
So, I think that's a project for another topic. I think the issue is that on paper it looks really interesting and has a lot of features, but I'm not quite sure on how portable it is to other designs both electrically and mechanically, given that such a design is necessarily constrained to one particular form factor (i.e. AA-size), and actual use case for dual chemistries, not to mention the associated extra cost for the driver, and extra development work for the firmware, which again may not be very portable.
This seems like a great exercise for a specific driver, but not so much as a community driver. But what do I know? 
I suppose I can see some use cases though. I don't think I'll be able to focus on so many drivers at the same time though, so we'll see how it goes. If nobody wants to pick it up, maybe I'll give it a go sometime.. for now, likely makes more sense to work on this driver first.
-I want you to :D
Not longer relevant
loneoceans ninja edited his post 
Would using a Hall effect sensor to measure output current and using the Attiny instead of an op amp to do the feedback loop make sense?
It would remove the current sense resistor losses and the output current could be changed in firmware.
Thanks for the suggestion!
Well I don't see why it can't be made to work, though this method doesn't really remove the op amp since there's still an amplifier inside the hall effect sensor, and my guess is another amplifier is needed for integrating feedback to the switching regulator. However, with much additional propagation delay in the feedback loop, there may be stability issues. Though it is possible to 'roll your own' switching regulator in the MCU, at the cost of additional MCU load and firmware development, likewise with additional overhead in quiescent current, and increase in BOM cost.
Will consider all these ideas and do some cost benefit analysis to figure out the most elegant solution. :)
Guess there is still development to be done with Hall effect current sensing, doesn't it?
What are the actual limits of using sense resistors? The signal to noise ratio maybe? As a possible example, the LD-29 linear driver (10mΩ sense resistor, ≈30mV sense voltage) can have some difficulties driving the emitter when the current is set under 20mA or so (it may not light up). 
Is it possible to implement user adjustable max output… so the same driver could be used for various LEDs from 219b to SST20 to 3V XHP50.2?
led4power has that control in his proprietary drivers. So, it’s definitely possible. But, in that case, it was limited to a range of possible output current, so he made a few versions of the driver to cover different ranges of current output.
Yes, that's not difficult to do. For example, in my GXB drivers, I typically have solder jumpers to allow selection of mode groups without reprogramming.
As mentioned, I'd like to keep the targeted firmware as stock as possible with minimal modification. If not possible / easy to set max output in the UI, would folks prefer solder jumpers (e.g. 2 jumpers can provide 4 different max levels), or a small trimmer resistor? The candidate MCU should have sufficient pins to support all these features I believe.
A small trimmer resistor? Isn't that probably too big?
I think the most space saving solution would be adjusting a resistor divider by swapping or adjusting one or two tiny surface mount resistors, given the corresponding drive current formula. This is not very different than soldering jumpers, standing out by providing very precise or exact current adjustment with minimum board space requirement. 
It is also not very different than replacing or stacking sense resistors, but sense resistors are more rare and more care is required to properly place them.
Or so I believe. O:)
Not sure if this has been covered, but:
- do consider keeping parasitic drain low for e-switch uses. Not sure if you are targeting e-switch or power switch designs.
- The EDC05C is an example of a small dual channel output light, 14500 cell with a main LED and bank of 2nd channel LED's.
This sounds like a great project! Good luck! I'm very much interested.
Good to see you kicking around again Loneoceans.
This project sounds really interesting for mods. I am a massive fan of boost / buckboost drivers and want to see a viable “BLF Designs” made.
Although I do have to side with people saying that 3A-5A is a very niche market now days.
You would have a hard time getting basically any manufacture to use it for a normal light since it would make it significantly less lumen output then competing options with basically no advertiseable upside that would matter to 95% of buyers. An extra 15% runtime is great, but buyers will almost always buy the light with 2-3x the lumen output over the light with 15 minutes more runtime.
That said, there is still a place for a design like this, for lights like the lantern for example, or headlamps that need good sustained output. Not to mention custom mods for people that appreshiate good long term performance over peak lumens. So I still want to see it developed for sure.
I am still hoping for the 20A boost driver to be finished and made compatible with BLF firmware. THAT is a driver I would use over and over again.
I love that sample light you sent me BTW, just wish it had firmware I am used to as I would turn it into my EDC in a heartbeat if it did. In fact that reminds me, I still need to try a high CRI XHP50.2 in it.
When working on the Texas commander drivers ( a linear regulator based driver).
We were able to adjust the output via PWM from the MCU really easily. We were going to add a menu option to limit the max PWM but then abandoned the driver.
Toykeeper has already implemented this into anduril more or less though, you can set the max non-turbo PWM in the menu options IIRC. It should not be hard to tweak this to whatever you would need to allow the user to adjust the output from within the menu I would think.
Now for bistro / clicky firmware, the feature would need to be added to the menu but one way I got around it was to simply create a bunch of mode groups the user could pick from in the menu. Then I limited the output on some of them. Not super refined but it works.
Crescendo would be a better option for a clicky firmware anyways if it was finished.
It looks like just pasting in a new ramping table around line 60 in spaghetti-monster/fsm-ramping.h wouldn’t be too hard, not sure which one of the three would be in use.
A new ramping table could be created using level_calc.py, http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/head:/bin/level_calc.py
Just need to modify “chan.pwm_max = 255” in “for chan_num in range” to the new maximum level. Then copy and paste into the correct ramping table.
Hopefully Toykeeper pops into this thread at some point. I see she’s been working on the 1634 and 841. I’m not sure if she would prefer one of those or the 85 be used.
If the 85 is used Narsil can be used, its a lot easier to follow, modify and compile.
If setting max current in hardware requires a soldering iron it means the driver needs to come out. In that case I’d prefer a couple sense resistor pads near the outside over solder jumpers. Undoing a solder jumper in the middle of a populated 17mm driver risks nearby components and BLF firmware doesn’t currently support it.