What would the maximum power be that this driver can handle?
You said that you’ve configured it for 40 watt max for a single cell. But if you have multiple cells in parallel you can increase its power.
The input peak current is limited to 15A with the TPS61288, for a maximum fully regulated output down to LVP it doesn’t matter how low the DCIR of the battery is since you set the output current so that you hit 15A Iin peak at Vin=2.8~3V, maybe a bit higher if you’re fine with a dip at the end. That should be arround 35~40W depending on the efficiency and the inductor value. Or if you’re fine with a basically unregulated turbo it can be a bit higher.
But if you’re going to have several cells in parallel in a bigger light then you would use a more powerfull controller/converter or put several in parallel (the MF01 uses 4 boost converters for example)
This is so nice! Where do I sign up for few?
I updated the first post with some additional photos and images, and more to come soon..
Above is a photo where you can admire the bare LED die construction.
Here's a comparison shot - what are they? Scroll to the first post to see :)
Thanks everyone for your interest and kind words.
For the converter, I purchased the TPS61288 from TI directly a few months since I built a development board for this project to fine tune the circuitry and to ensure everything works as well as possible before building a form-factor PCB. Though as pointed out, it's now out for sale on Digikey and other distributers soon. I also did a little component optimizing in terms of cost, and the BOM cost for this board is actually a good bit less than say the GXB172.
The general maximum input power is 40W if a good cell is used. One shouldn't simply look at the quoted maximum current input for the converter IC, since this maximum current depends on a lot of other factors as well such as inductor choice, switching frequency, load etc. I did some quick analysis and found it to be more a smidge more efficient across the range compared to the MP3231/29/32, and also because maybe I'm baised towards TI since I've used a lot of their PMICs and I do like their implementation. The idea of the Lume series of drivers is to create practical and reliable implementations, not to make lumen monsters, so I focused on efficiency & practicality instead of absolute maximum turbo modes.
For multiple cells in parallel, I always feel uncomfortable with consumer flashlights using inherently power dense cells in parallel or series without a BMS. It's generally OK in practice if the user uses three well matched, new, cells together, but problems quickly happen if the cells are not matched.
This driver is designed specifically for the use cases of today's high power, single, 18650, 26650 and 21700 cells. The maximum power handling capability is designed around this power source. If multiple cells are used in series or parallel, significantly more powerful drivers can be created; for example if a 4680 cell comes into consumer production, I could make something like a GXB100 for it. If multiple cells are used in series, then it makes sense to design a higher voltage buck regulator.
Agro, I'm using the Coilcraft XAL7030 inductor for this particular build, though a bigger inductor like the XAL7070, 8080, or 1060 would be better choices. This inductor choice is limited by the physical size of the driver cavity, and I reduced the maximum power output slightly for this particular build due to this reason. The 3mm value refers to the z-height of the inductor.
Speaking of which, just wanted to point out that the Lume X1 is not a particular driver, but a general design topology. I don't think this driver as-is is remotely suitable for most hobbyists to assemble at home unless you're comfortable with soldering QFN packages on a daily basis! It is also currently designed specifically for the KR1 host (25mm diameter), which is also non-ideal since the KR1 is a lousy host as-is, and I don't think most people would want to mill out their flashlight to fit a driver. Most likely, a new driver needs to be designed for a specific flashlight.
Perhaps if lots of people are interested, hopefully we can convince some manufacturer to pick it up for their light to create something special. Personally I'd like to see a compact, side E-switch, single emitter (or multiple in parallel) light made by Hank with the build quality and design he's known for (just a personal preference, no hard feelings to other manufacturers). They could offer two variants - one with the usual linear driver and 3V LEDs, and one with the Lume X1 driver and a 6/12V LED,.. but that's not for me to decide. :)
Good point - I can solder QFN on the daily but I'd really be unhappy doing it with the hobby-grade equipment I have at home...
Looks pretty cool. I’ve been wanting better resolution in low modes for quite a while. That ramp must look incredibly smooth. 
Have also wanted to get a KR1 at some point, since it’s almost as small as a D1 but has the throw of a D1S. The D1’s side switch makes more sense for a thrower though.
That’s jaw dropping, LO!
And about the attiny1616… I’ve been using it a lot lately and I’m working with some other’s on it. I’ve branched TK’s Anduril2 repo and merged in 1-Series support, just in case you’re interested in it for future builds. I also have a general 1-Series info thread here (not that you need any kind of help!)
Very impressive. And have you configured Anduril to ramp through this full range? How many steps?
I do indeed hope some manufacturer likes this well enough to work with you to bring it into production. Hank might be hesitant to move on from what is already a relatively new driver for him, and he seems to like the power handling of FET’s, but if he can find space for a taller driver, I think his lights would have just about achieved perfection.
I had not looked at the Ledil Olga before, but on seeing your picture of it, I realized the facets are angled. Looking up Ledil’s information on it, they indicate it is intended to minimize color artifacts when tint mixing.
An implication of this is if your center LED were small enough for the auxiliary LED’s to fit under the cavity in the optic, they may mix more cleanly than what we’re all used to for auxiliary LED’s.
As someone who is excited to just attempt my first simple emitter swap, this was awe inspiring. Really enjoyable to read about the planning and execution. I hope to get to the point to be able to try something like this one day.
Just saw the link to your site. Down the rabbit hole I go!
Where can I get the drivers? Will you offer these in DIY build kits also so we can flow ourself?
Where also can I get that MCPCB for AUX LEDs? It’s beautiful.
This is what we have been asking manufacturers to come up with for more than 5 years!
Truly impressive, if the bare driver ever becomes available, it will take flashlight modding to the next chapter.
I absolutely love it. Wonderful job!
Any additional info about this nearly impossible dynamic range will be welcome. It will be very interesting for many of us. I think is used also full potential of 16bit timer. With current Abduril firmware is possible to get 10bit resolution. Here we talk for something like 20-24bit resolution. It used external DAC maybe? I can’t see how it is possible to be achieved with that attiny1634. Also submicro current measurements need also high resolution or larger shunt resistor.
As gchart said, Anduril2 support is now available for the 1616 - many advantages. However the 3216 does not seem currently available in the 3x3mm QFN format - not in the specs or available from suppliers.
Here's a quick video of the general functions of this flashlight, mostly showing the Aux LEDs and how Anduril2 functions with the Lume X1.
Thanks everyone for your continued comments and suggestions, please keep it coming.
Gchart and Tome E, thanks for your efforts, most likely for any drivers or revisions going forward I'll pick up the 1-series MCUs and I do have some new ideas for them! It's so great to have talented friends like you all working on making improvements. :)
icpart and thefreeman, using a high resolution or high precision part is expensive and significiantly drives up the BOM cost, and fortunately I managed to avoid using any of those components to enable the system to have a high dynamic range; not based on component precision but by system design. thefreeman, yes! I am actually using multiple sense resistors similar to what your drawing shows! I had the thought of trying it out last year but it took me some time to build a prototype, and there are a bunch of traps I had to work through with control and stability to make the entire system work well. I encourage you to try it out and see what works well though I can't speak for the linear FET version. On this topic, check out the Thrunite T2 which someone alerted me that was another nice new flashlight similar to what I'm trying to achieve with the Lume X1.
In the photo above, what struck me was that I see a few big resistors. I don't have this flashlight so I can only guess from the photograph that they're implementing something similar... or maybe not at all... just a guess.
Will34, 94Z28, For the driver and LED aux PCB, they were designed specifically for this unusual build with a modified KR1, so I'm not exactly sure how practical they will be for most general builds. The Lume X1 is a general topology and easily adaptable to other flashlights, and I plan to design one for either a more general use or even better, if it can be incorporated in a flashlight. I'm thinking of doing some little adjustments, and trying out some new ideas with the newer AVR-1s... so I'm hoping for more to come soon (we'll see how much time I get to work on this since I've actually been super busy recently!).
ToyKeeper and iamlucky13, while the resolution is good at the low end, actually the ramp itself isn't quite as smooth as you'd think and it looks roughly the same as my regular AMC7135 drivers, mostly due to the 150 default levels.. I haven't really played around the ramp values yet I generated my ramp table like a x^3 curve. It seems like the smoothness of the ramp at the low end is is affected by the 150-level limit in Anduril (it's possible to increase the number of levels, but the ramp duration would increase, and each ramp level duration is controlled via a 'tick' in Anduril and it's not easily changeable at the moment without affecting the rest of the system (AFAIK from a cursory look at the firmware though I could be wrong). In other words, something like 1500 levels and 10x shorter tick times will make a smoother curve and the Lume X1 has the hardware to make use of it. Regardless, I'm thinking of trying out some other kinds of curves like higher polynomials or exponentials (which I think may actually like better), and will also make the gaps between the levels at the lower modes tighter and look smoother.
Yes please, especially if this is better to the solution I came up with (probably 
) :
Here this is with a linear FET topology but the same applies to a buck or boost topology (inputs of the OpAmp would be reversed and output goes to FB of the converter IC)
By turning ON or OFF Q3 the shunt resistance is either ~10mΩ (R12+Q3RdsON) for the higher current range or 5Ω for the lower current range. Here with a reference voltage of 50mV that translate to a maximum current of 5A or 10mA respectively.
We know that with this type of circuit 10bit~1:1000 dimming can produce flicker (noctigon KR4, lume1), probably due to noise as the sense voltage become so low (with a 50mV shunt/1000= 50uV). So if we stick with 1:500 dimming we can go down to 10mA on the higher current range and 20μA on the lower current range, achieving 1:250000 dimming, less than 1:10 millions sure but I mean, both are already way sufficient anyway.
Here is a simulation :
Red is current and green is Vsense.
At first Q3 is ON so we’re in the high current range, then we dim to 10mA
At 9ms Q3 is turned OFF to switch to the low current range, the reference need to be put back to 50mV, we also get 10mA
Then we can dim to 20μA.
With this we avoid dealing with very low sense voltages.
The downside to this is that a very low RdsON mosfet is required so that a variation of its resistance doesn’t influence Vsense too much. Here the Infineon part I chose has a RdsON of 2mΩ at 2.8V (the logic voltage) for a 3.3x3.3mm package, but with part variations and temperature it can potentially go up to 3mΩ maximum, if the shunt resistance goes up from 10 to 11mΩ then the current is reduced from 5A to 4.55A, not terrible but not great either.
Fitting an aditionnal 3.3x3.3mm package isn’t an issue on a linear driver, on a switching driver board space is precious for 18650 flashlights, although still not critical when using both sides.
The TI PWM chip regulates voltage on a cycle-by-cycle basis at 500 kHz, so only 8 bits of current sense measurement can develop a 1:10M range. For example 240 current levels for each of 41666 voltage levels.
Analog resolution, not digital.
For example: The Emisar D4 has a dynamic range of 16,000 to 1… 14 bits worth. But it uses only 8-bit PWM, which is 256 to 1. How is this possible? It has two power channels — one which goes from 0.25 to 130 lm in ~0.5 lm steps, and one which goes up to ~4000 lm in ~15 lm steps. Two 8-bit channels combine and produce an effective resolution of 14-bits.
But what if the low channel was smaller, and it used 10-bit PWM instead of 8? If the low channel was only 16 lm, that would increase resolution to 0.015 lm steps. 4000 lm / (16 lm / 1024) = 256,000, or approximately 18 bits of analog resolution (on hardware which is only 10 bits digitally).
If it helps, some related ideas are shown visually here:
Ignore the bottom part. It is only showing the importance of good current control to make the ramp more smooth.
On every flashlight in the repository, the bottom of the ramp has been artificially shortened because the resolution isn’t high enough in the hardware. It would otherwise end up with a ramp which looks like “1,1,1,1,1,1,2,2,2,2,2,2,3,3,3,4,4,4,5,5,6,6,7,7,8,9,10”.
But with your solution, it seems like it’d be able to hit the in-between levels at the bottom. The intended values are “1.00, 1.07, 1.15, 1.25, 1.35, 1.47, 1.59, 1.74, 1.90, 2.07, 2.27, 2.48, 2.72, 2.99, 3.27, 3.59, 3.94, 4.32, 4.74, 5.19, 5.69, 6.23, 6.82, 7.46, 8.16, 8.91, 9.73, 10.62”.
I didn’t understood that. What do yo mean? 500khz is operating frequency of the boost driver itself. It doesn’t have to do with control loop. In our case we have CC driver not CV in most of time. Also Anduril firmware must support that functionallity with second channel of dirver. Now we have simmilar idea like old FET 3 channel drivers.
ToyKeeper thanks for the detailed explanation :+1: