[[ GXB20 Driver – Homemade Constant Current Programmable XHP50 Single-Cell Boost Driver! ]]

+1

Hello all, just a quick update that I've a simple write-up (in progress) of this LED driver.

http://loneoceans.com/labs/gxb20/

It's mostly a rehash of stuff on this thread though. More details to be added there as I go along. Thanks for reading!

Great writeup, very informative.

Yes, very good, thanks!
Do you intend to extend the writeup to cover GXB17 too?
You mention that you use PWM because the driver won’t be used under 200 mA. That’s not true already. Is it still PWM?
In the writeup you mention having the lowest mode at 50 mA. I notice 1 mA in this thread. Which is the latest value? Also, it would be useful to add the range of currents supported by GXB20 v2, not just that there are 256 of them.

BTW, loneoceans, have you considered something like ATBTLC1000 for BT programming?

Yes the GXB17 driver will have its own writeup. Yes the driver is running in FPWM mode, but you're confusing that with the 'regular PWM' running in the kHz range which people use to modulate brightness. The Forced PWM mode is how the boost driver is configured and how it regulates its output. In this case that PWM is running in hundreds of kHz and is the switching frequency of the boost switches. The output driving the LED is true constant current. Finally if you look at the firmware diagram at the bottom of the page, the driver has a 'moonlight' mode which drives the LED at a very low current of around 1mA. The range of currents supported are 256 constant-spacing values, but the max is determined by its desired mode of operation, e.g. running at 6V out or 9V out, and configured accordingly to your desired maximum current.

I've worked on similar parts in the past but it really seems like far too complex work for a driver like this and a bit too much overhead as well as cost.

As far as I understand: You’re PWMing power into an inductor and you could be PFMing which is more efficient at low load. I have no idea what ‘low’ is, but seeing you mention 200 mA I assumed that this number is somehow related to the limit of lowness. Since GXB20v2 bottom 200 times lower than that, I assumed PFM could be preferable at the lowest modes.

I’m not sure if it’s suitable, but ATBTLC1000 starts at $1.71 at DigiKey. I believe that many would pay even several dollars to be able to easily have perfect modes.

Moodular and Lux-RC offer such lights already, though that’s well within the high end of the market.

The SOC is cheap but there are a lot of peripheral components that need to go alongside almost all RF SOCs including a chip antenna, internal regulator inductors and passives and crystals etc. That's not even including the very limited PCB space on a 20mm/17mm diameter board. Could I make it work? Sure, but this will require much more expensive PCB fab requirements, will complicate hand-assembly, and still requires more firmware overhead... Lux-RC's optical flashing programming does look interesting though but again requires additional infrastructure on both the host and client side, which is far too much work for this particular hobby project (which I only planned to make a few for my own flashlights). However anyone is more than welcomed to add more features on to the GXB driver.

Changing FPWM to PFM is just a disconnection of the mode pin so it's really not a big deal. It's a trade-off between audible PFM at low loads with higher efficiency, or just sticking with FPWM for always quiet operation.

Flashing? I thought they used BT! Cool idea….does the phone flash back?

Is it possible to do programatically?

BTW, I don’t see a link to the firmware sources…

It's a nice idea, I might have to think about it for a future product since it just requires a small photosensor. The only requirement is the additional cost of developing an app (e.g. web-app), define a protocol, and implement it so the light can be programmed using flashing screen of a phone or a computer screen.

No unfortunately not. PFM or FPWM mode is programmed by connecting or floating the mode pin of the boost converter driver IC.

Distracted by other things I forgot to thank you for the costs explanation.
So: Thanks!

I would be happy to help with communication development, both for the app and for the MCU. I do protocols for the living.
loneoceans, this is not just an offer for you, but for anyone willing to get a hand.

So I guess it would need a switch? It may not be worth it then, though it certainly seems to have uses. It seems that the efficiency is the same at about 700 mA. Lower PFM wins. At 100 mA PWM has ~75% efficiency and PFM ~90%. That’s a massive difference. Surely other losses will make it smaller, but it will probably still be big. Though is it worth the noise? It’s hard to tell without hearing. I strongly suspect that it is worth it for me for the low mode, but not sure about the lowest actually. Because I use the lowest to light up a tent while myself and my woman are preparing to sleep. I believe there may be others who would like the extra efficiency of the low modes. Another use case: low voltage protection could switch to PFM. I think many would like to improve efficiency when they don’t have any spare and the light is already not bright enough.

The programming by flashing method has been tried and proven to work on here in the firmware thread. TK even had some early code that proved it works.

You don’t need many changes on the PCB to make it work either, basically just a trace to the LED- output from the FET to get a voltage reading off of, everything else you have already. I see the flash programming as the future. Complete adjustability and easy implementation in an assembled light.

How many times do you really need to reconfigure your lights? I don’t get how needing an extra device to change settings that can easily be changed with button presses is something to strive for. What exactly would you want to change with the phone?

The menus only allow for very basic setting changes and they are not that easy to use. First off you are limited to a pre-made set of mode groups. They don’t always have what you want. Then you have to figure out which group it is you want, count out the blinks and hope you get it right.

By flashing it you could set up the mode group exactly like you want, press a button and boom, you know it is exactly what you wanted with no guessing and annoying counting.

Plus as drivers improve we will be able to select many many more options then we do now and having all of those in the flash menu would be silly, not to mention a lot of space used on the menu alone.

For example in the future I see you being able to set the current you want the LED to see in constant current, the PWM that you want to add or subtract from that, the regulation settings, the thermal regulation points and settings, exact mode groups, custom strobe modes and more I have not even thought of yet.

Put simply is the flash programming a 100% must? No.

Is there any reason not to do it? No. You loose nothing by having flash programming except the programming time. I always come at things from a “Why not?” perspective.

I don’t count out blinks my self, I press the button X times to enter digits. If you can count it’s very easy.

Adjusting for a specific current is probably overkill for most people. I adjust the light to how ever bright I want it in a ramping style setup. Seems a bit annoying to have to grab the phone if one of the modes turns out to be a little brighter or dimmer than you actually wanted.

I do see advantages by wireless upgrade of firmware, but then you still have to flash the basic “operating system” into the MCU anyway, so why not flash it with what you want from the start? Do people really need a whole bunch of mode groups to choose between? If you have a few, pressing the button the amount of times to select it really is easy.

I know, everyone is different and has their own preferences. I ask these questions because as a hobbyist driver/firmware developer I’m always interested in developing new features if I can find personal use for them, but as it is now I’ll guess I’ll just say “why not?” like you and see what others come up with.

What is lost by having the option for flash programming?

It costs 1 extra trace and 1 pin (of which we have lots of extras on new MCU’s) plus some programming time. I just don’t see the downside. Not like people have to use it but knowing general people, they are 10x more likely to actually change a setting on a flashlight if it has a nice GUI interface then counting out blinks or clicks.

Heck even I will hardly even try to mess with the firmware in most lights, just not worth the hassle in most cases.

Plus if you will have to look up the manual to figure out what setting is what and thus be able to program the light anyways (even having used bistro hundreds of time I still don’t have the menu memorized and have to look up the manual before changing anything), I would rather just pick the settings I want while on the computer / phone anyways and then push a button to have them sent to the light. Save the middle step of me having to manually enter it.

Thanks for your answers. I can see some people finding it useful.

So yeah, why not. Go for it.

Has anyone had any luck with obtaining a boost driver to run an XHP50 from a single 18650?

Considering there are 5000K XHP-50 with CRI of 90+ (eg: SC600Fd Mk III Plus) which give better runtimes and output than the low voltage Nichias, one would assume that demand for a driver of this nature would be quite high

Has anyone besides loneoceans actually built one of these?

Ahil, Kaidomain's H1-A driver? Related: Buck and Boost Drivers, Testing, Modding, and Discussion (Pic Heavy)

By the way, where are those high-CRI XHP50s for sale?

Cheers