[ GXB172 - 50W Single Cell 17mm Boost Driver! ]


Lexel you're absolutely right! The XAL7070 and 7030 have essentially identical pads so I made the pads fit both inductors, so you can choose whatever you want. Some pills like the Convoy S2+ have a lot of space so it definitely makes sense to go with the big inductor. Others have less space and I've verified it works OK with the smaller inductor too. But like you mentioned, the 7070 helps in reducing DC losses (and thus also less likely to cause the inductor to drop inductance due to heat), and that we can use more inductance for less ripple and less RMS current losses and switching losses!

As for the capacitors, yes definitely larger and higer voltage rating with better dielectric is more desirable. In fact I did change some of the pads to 1206 before I sent it off for fab last week. Since the inductor is so fat, it's also possible to stack MLCCs on top of each other. Currently I have 94uF on both the input and the output at 16V, though we could do something like a 138uF 10V on the input and 66u 25V on the output, and more with stacking. Finally, I also found some nice bronze springs from Kaidomain which have a ~5mm top and ~8mm bottom. The high drain cells all have fairly large flat tops so I'm planning to try to use those springs in reverse (since my spring pad is very small to save space), but I suppose it doesn't really matter since we'll need to bypass them anyway.


Well the way I have it set up should work just fine I hope with perhaps a change in a resistor or two. The LDO max input is above 2S, and my battery voltage divider also takes this into account so it's a simple firmware change to have it running with 1S or 2S with auto-detection. The downside however is that because this driver is fairly specialized for the application, for best performance ideally one really needs to configure it for either 6-7V out or 12-14V output. For example, if I really wanted to drive a 6V LED hard, I'd choose input and output caps specifically for that purpose which would not work well for a 2S input. Likewise for 2S operation, I can choose a larger value inductor for less ripple and a more regulated output with lower peak switch current. So in short, it can work, but it will not be near optimal. That said, if you're just planning to run at fairly low power levels (<20W), I see no major problems.


Hello Clemence! Yes thanks also for your help in getting Nichia LEDs to the community! I ordered some from you recently so hopefully I'll get to pair one of the 144s with this project.

Thanks for your kind words! For soldering, it depends! Typically for stuff like this I use a stencil and reflow it in an oven, but for one-off small boards like these (at least for now), I typically use hot air for the stuff with pads underneath, or in this case, the big indutor too. The rest I either use hand-placed solderpaste with a needle and hot air it, or use a tiny tip soldering iron and needle tweezers. Typically I do this under magnification.

Thanks MRsDNF! I hope to get this inside a flashlight soon when the host and boards arrive, and when I finish whatever firmware I'm working on right now.

In which mode are you running the boost IC?

Wow, so much reading to catch up on this thread, hope I can find time to catch up at some point.

If you want to get my design files for private use only I have it in Diptrace the others seem to use Eagle for their drivers

Schoki, I tested both pulse frequency modulation / pulse skip mode as well as ultrasonic mode (USM) - one of the cool features of this IC. Once the output current (with a 6V LED) drops to about 75mA or less, the pulse group frequency drops to below 20kHz (with my set-up). As a result, running it in really low modes or moonlight will result in audible noise with PFM/PSM. For example, at 10mA output drive, the pulse frequency is well under 2kHz. So anything below ~60mA or so results in a (quiet) but definitely audible sound. This is absent in USM mode where the group frequency is kept above ~23kHz but at the expense of only slightly lower efficiency at those low values.

After some evaluation I decided to just go with USM mode since this allows us to float the mode pin (fewer components), and I'm pretty sure nobody wants a moonlight / nightlight flashlight beside your bed making this tiny high pitched sound, even if it has better battery life. For example, based on the datasheet with a 4.2V input 9V output and 1mA output, PSM vs USM is about 60% vs 40% efficiency. At 10mA, this becomes 93 vs 83% efficiency. It's a significant efficiency decrease, but I think it's worth the trade off, and still reasonable in practical run-time duration.

good news as my design has same floating ground for USM mode

could you test together with an MCU already if the chip needs the LVP pin populated with 2 resistors, this is really a pain to integrate with all 0603 components
I had later a design adding 2 resistors but then later have to make a wire bridge as absolutely no space to place a via for V+

While well out of the loop I agree with your decision, that is the trade off I would have made.

When you are talking about a mode that will run for months in either setup, it really doesn’t matter much lol.

BTW can anyone share the MP3431 datasheet with me? I got troubles getting it from Monolithic…

Impressive driver! What host could even handle that much heat? A C8 light is the biggest thing that comes to mind.

ICSK, from a practical point of view, I am the first to acknowledge that the driver doesn't make sense , since heat will be the biggest issue. However, this is intentional! Moreover, it will be able to drive 50W for a short period of time, before thermal regulation kicks in; and if you turn it down to say 10-20W, then you've got a much more practical but still powerful driver. I've got a prototype PID thermal control firmware tested and it seems to work OK, just need to put it in an actual light to fine-tune the variables. However, you're right that the C8 is likely one of the larger lights that still uses a 17mm driver. I'd imagine that having a C8 and swapping out the XPL HI with a XHP35 HI would produce some pretty nice results , even if the XHP35 HI die is a little bigger than the XPL HI.

Yes, the XHP35 is a great upgrade from the XP-L in every way. More lumens, more throw and generally better tints from what I have seen.

I don’t agree it makes no practical sense.

  1. If you lack distance to shine it where you want, you can use a turbo or walk. I consider the former to be a practical option.
  2. Aside from ultimate power it offers superb efficiency.
  3. Larger variants will find use in larger hosts.

NarsilM v1.2 for the GT brought a good feature ramp to a certain percent like 80% and Turbo only by double press to 100%

I am not sure what you are referring to.

loneoceans said this is not a practical driver - that’s what I disagree with.

Problem that if your host could carry for example 10W, after 50W boost you need a great step down to normalize temperature. And in most cases illuminance difference between this 2-3W and 10W is times bigger than between regular 10W mod and 50W boost.

Hello everyone,

Quick post to share some updates ^_^. I was out of action (caught a flu!) for a while but I'm better now and managed to complete the preliminary firmware for the GXB172. So far I'm happy to say everything is working pretty well! I'll get into this in a bit more detail later on but yes, I've reviewed Bistro and it should port over easily (with some changes specific to the GXB172, and likewise with Narsil), but I've also added a bunch of new features to the current firm as previously mentioned, such as accurate PID temperature control with a dedicated temperature IC (no fudging around with NTCs!), several fun optional modes like candle-flicker or strobes, and smooth brightness transitions which help reduce eye strain and ease mode transitions without blinding the user immediately!

Anyway I put some boards together and I'm happy to report that the only mistake I found was a single silkscreen error, but electrically it all turned out good! Here's how it looks like, top and bottom.

Above is it pictured sitting in a Convoy S2+ brass pill which is my candidate flashlight for this driver. Note the big pads for + and - to the LED, as well as programming header pads, E switch pad, two additional jumpers, and one more auxiliary pad which can be use to power an extra LED or something else (e.g. I used this for a debugging LED during firmware development!).

Above shows a side view of the driver. The big inductor can be easily swapped out for a smaller shorter (3mm tall) one if your host doesn't have space for a ~7mm tall inductor. Using a bigger inductor allows better performance though with a higher inductance (desirable) and lower DC resistor (desirable).

But does it work?

First I had to solder on a spring. It looks a little funny but it works just fine with an inverted spring and solder wick for bypassing.

To test the driver, I paired it together with a Nichia 144 90CRI LED. Now this is not the most efficient of LEDs in terms of being a lumen-monster! Djozz has tested this E1000 LED and it 'only' puts out ~2500 lumens at a 6A ~6.4V drive.

But I really wanted to make a high-CRI flashlight while still being very bright! Don't worry, I have a J4 XHP50 up next for a >4000 lumen light

... and it works exactly as expect with all the modes and functionality working!

I'll be testing this extensively in the field since I'm sure this preliminary firmware needs a bit more tweaking, but much more to come soon!

Because I've configured this light to be a 'shorty' build, having it run at 6A output would lead to a ridiculous ~3 to 4+ minutes of runtime (thermal throttling will kick in before that though), so I changed the modes for a more reasonable 4.2A LED output (measured and verified on the scope) for about 2250 lumens of beautiful CRI 90 Nichia light.

For those interested, here's the current version of the firmware, with one particular mode structure shown.

Obviously the number of modes, memory, special effects, battery cut-off, thermal regulation etc can all be adjusted to whatever you want!

So far it's not quite the same as can be done in some single-button programmable UIs, but I'm planning to iron out any kinks in the core functionality first before moving on to more firmware development. Hopefully when more people get to try out this driver, more talented firmware engineers here can help write better firmware ^_^.

Meanwhile I'll document my build of the flashlight above in another thread (there are a bunch of tricks to do to make the system work well, plus some cool new features!) so I can keep this thread more focused on the GXB172 driver proper.

See the thread here: https://budgetlightforum.com/t/-/50373 for more information on that build.

More to come and thanks again for reading!

Very nice! Can’t wait to see this project progress.

What size are those components? They look smaller then 0402?

I am also very interested in seeing your bistro and Narsil ports. I wish there was a way to program the 1617 and 1616 mcu’s easily (maybe there is now, been a few months since I checked), it would be nice to step up to one of these MCU’s but sadly not an option if we can’t program them.

Do you have schematics and parts list available?

Where can we buy this driver?

From u?:slight_smile: