Developing a customizable driver

Flashlight Modding and DIY Parts
1

Hello, folks. I’m new here. I basically run a small electronics design and manufacture shop (by small I mean I’m the only tech and I got two guys doing assembly 4 days a week) in the US and decided a few months ago that I’d try building a flashlight driver. I’ve gone through a couple concept prototypes and will shortly have some 17mm disc PCBs of a functonal design in hand. I have a 501b body and a small zoomer in hand to play with, as well as a handful of XM-L2 U2 LEDs. I’m new to the culture so please excuse my lack of familiarity with terminology.

What I’m working on uses a voltage-mode buck regulator intended to pull from a single 18650 and provide up to 2.5A of current to the LED. I know that’s not a lot for some of you guys but it means around 800 lumens from an XM-L2, which I think would be pretty good for a single-cell pocket light. Current is monitored through a small series resistor and current sense amplifier and periodically sampled by a microcontroller’s ADC. The microcontroller adjusts the buck regulator output on the fly, initially to ramp up to target current and then to calibrate it as conditions (LED temperature, battery voltage) change over time. The buck driver is capable of 100% duty cycle so it goes into direct-drive mode when battery voltage is insufficient for desired current.

I haven’t coded in mode switching yet but it’s possible. Last-mode memory is also possible. Strobe modes will be fairly trivial as the micro can set the voltage arbitrarily lower than LED’s Vf and then snap it back to a target setpoint quite rapidly. Toggling the buck controller’s enable line would be simpler but would be wasteful due to output capacitor discharge. Brightness is directly controlled by adjusting LED current without the need for linear regulators or PWM FETs so it should be quite efficient and flicker-free.

The microcontroller can also monitor battery voltage and completely power down the buck driver when it reaches a minimum threshold.

I’m currently designing around a PIC12F1571 but the 1572 has twice the code space and would therefore be more desirable for anyone wanting complex modes. The PCB as designed has some test points for easy in-system programming of the microcontroller.

I plan to get some efficiency curves from various cell voltages and current setpoints, which should help make predictions about battery life under various conditions, once I have my PCBs in hand. The design prioritizes efficiency and reliability.

Eventually this will become a commercial product (firmware source will be available, but written in assembler because it’s better), assembled in and sold from my shop in Missouri, and at that time discussion will shift to the appropriate area of the forum. For now it’s just an R&D project and I figured I’d seek advice on desirable features and such from people who both know and care more about flashlights than I do. I think this is the right place, but if it’s not feel free to move this thread.

If it goes well, I may try and learn more, work on higher-current versions for larger lights. Might see what I can do with a buck/boost for stable brightness in the bottom half of the battery’s discharge curve. Who knows.

So, any opinions? Criticisms? Anything I’ve foolishly overlooked? Anything I’m doing wrong?

2

Welcome to the forum sidehack. :beer:
There are many around who wouldn’t consider 2.5A from 18650 light to be enough - but also many who would find it plentiful, some even consider that excessive.
The market is not rich with buck drivers so there’s definitely some space for a driver like yours.

As to the UI - next mode memory is widely considered wrong and people go to great lengths to remove it. :slight_smile:
Strobe is also a bit controversial - some want it, some hate it. I think the latter group is much larger among enthusiasts but most don’t care as long as it’s hidden well enough not to be encountered by accident. I should note that the most loved UI recently has been Andruil - which is super rich yet does not include the typical strobes.

I would suggest a major change to the driver though which would IMHO add a lot of value to the more advanced users. And may add a lot for others as well.
That change would be MCU selection.
BLF is rich with open source firmwares. Different firmwares for different needs. A few general purpose ones. Clicky? E-switch? Both are well supported. But all these firmwares run on ATTinys MCUs. By adapting attiny85 you could include some commonly liked and field tested UI without any coding - as well as make it easy for your users to replace firmware when they have specific needs. Like MtnDon has done in this year’s Old Lumens competition, using some 2014 firmware that just fit his needs well.
And for e-switch, trying to compete with Andruil is really a lot of work - and you surely won’t recoup the time investment.
I should note that attiny is not needed to succeed. Led4Power uses a different MCU with closed source firmware and he gets customers anyway. But I believe that complying with our local de-facto standard you’ll make things better both for you and for your users.

3

I for one would be happy to see more lights without Andruil. That statement probably won’t win me any popularity contest but, it matters very little.

I like wikedly simple UI’s. 3 or 4 mode. Now if those modes could be set to any brightness level I want. That would be ideal. Being able to toggle on and off mode memory would be okay. Pleasing everyone I’m sure. Disco modes could be done away with all together if it was up to me.

A simple fill in the blank and turning off and on of features using an app or PC/MAC software would be nice. Sort of like the software CHIRP. It’s a dead simple and easy solution to programming VHF/UHF radios. If something like that could be implemented for a flashlight or not is beyond my scope of understanding.

4

I hate strobe modes myself, which is a lot of what prompted the project. I was looking for a decent flashlight meeting a very specific set of criteria some years ago and found pretty much exactly one offering at the time that met it. Stock single-mode is apparently rare, which seems ridiculous to me.

I have no interest in leveraging other people’s work, especially with the code. I right now have a functional prototype single-mode that can be set to arbitrary brightness which is continuously measured and maintained, from a few hundred lines of assembler. Not many more lines and I could integrate mode switching and memory. I like to keep things simple. It’d probably take longer to gut and re-code an existing interface than to do everything from scratch.

If we nix strobe modes (which require leveraging internal timer routines) and stick to brightness modes, changing settings would be as simple as updating a few values in the code, recompile and reflash.

Your attiny85 is also overkill. The smallest package I can find covers almost twice the quite limited board area and leaves me with a dozen or so empty GPIO lines. Looks like there are a few ATTiny as compact as my PIC, so it’s an option, but I’ve been working with PIC for some years and that’s what my toolchain is set up for so that’s what I default to. But it could change, especially if the customer base already has AVR flashing tools - as have I, they just don’t get used often.

5

hello Mr sidehack, welcome to blf! It is always good to see new project from forum members! Have you seen these different drivers?

mtnelectronics has some buck drivers similar to you: Buck
loneoceans making a buck boost driver here: Lume1-FW3X: Constant Current Buck-Boost & FET Driver with Anduril1/2 + RGB Aux
lexel make a lot of different kind of driver here: Lexels driver compilation

Many driver use open source firmware which is actually easy to change to just single or multi mode with a code definition I think.

6

One of loneocean’s projects was pointed out to me yesterday, but not that one. Glad to see he focused on efficiency. I had done some reading and was confused to see how prevalent linear regulators were in high-power drivers, since that’s just about the worst option for efficiency and made no sense for items where I assumed minimizing heat and maximizing runtime would be desirable.

If my little pocket lights do well, I may look into larger and possibly multi-cell units, but one favorite part of my job is working on what I want to work on. I don’t need to squeeze 5A out of a single 18650, and I don’t need 800 brightness modes, and I don’t particularly care to leverage someone else’s fancy-feature interfacing, so that’ll take a very back burner to just making something that runs a long time and doesn’t break. My design philosophy is Simple, Durable, Reliable. Y’all enthusiasts probably have different priorities than us normies.

7

PWM on small currents has the advantage that the tint does not get ugly with low currents, most LEDs suffer from it
Also a true DC moonlight current ages the LEDs quite significant compared to higher currents, you can read up the physics,
many manufacturers write in their projector lamp LED line up (like CFT90 500mA) a minimal current to stay within lifespanof the LED

Also in PWM-ed CC on very low currents you can achieve a lower output brightness with better efficiency and stability staying out of the DC voltage drift of the OPAmp

8

Right, I understand the issue of color drift with low-current low brightness. One of the first buck drivers I looked at to build around was fairly robust for efficiency and PWM modes but it’s hard to find anything designed to work below 4.5V

I did not know about increased wear on the LED during low current use. Seems counterintuitive given the assumption of heat as a primary failure mode, but as you say, can’t beat physics. I have only prototyped a low-current build of my driver (waiting on the PCBs for a full-current test) but the driver, since it’s optimized for higher currents, gets a bit twitchy at low currents. Since voltage regulation is independent of the LED’s current path, a more complex driver could integrate a FET for PWM and use something like occasional mid-pulse measurements (possibly with pulse stretching if necessary) to maintain stable voltage such that on-time current remains constant over time.

But to do that on a 17mm driver while keeping low resistances for efficiency would probably require moving some things to the PCB underside. Right now it’s all a single-sided board, 2-layer, all passives 0603 and up so pretty easy to assemble with the equipment I have. My robots are supposed to handle 0402 but parts that small are hard for humans to work with so setup, testing and rework would suck.

One of my guys specifically wants a low-brightness (~25-50lm) version for using around the house at night, so I figured on tweaking parameters a bit for lower currents and using a different LED (max 240mA) that I already have a whole reel of.

9

I do hand assemble small components like 0402 on all my driver sales,
the key are very nice tweezers (the BT-15) and a very bright work light and rest your wrist on the working surface
My last 17mm design contains only 0402 passives plus nice big power parts

I would always go double-sided on 17mm it gives you enough room to place a nice big inductor on it,
I have seen drivers pushing 25W through a 4x4mm inductor but you simply lose efficiency
And room for some nice 1206 input/output capacitors size matters here a lot

at DC currents of 2.5A you can get along with a SOT 323-3 MOSFET
A sort of low moonlight 1mA or less is very desirable

10

Time is probably more of a factor for me, since I have to pay people to work, so I prefer 0603 parts. I hand-assembled hundreds of boards for a couple years before I could afford a robot.

I’m using a 5x5mm inductor, DCR 29mOhm.

Once I have something working I’ll look at a more complex setup with two-sided boards, if it’s necessary. As designed it’ll do everything I want it to do, and then some. The only concern would be how it handles low brightness.

11

Yes very low output is a thing that is on 17mm a challenge, often you are MCU limited with only 8Bit output so minimum is 1/255 while the buck or boost chip can handle 1:5000 dimming
Or you can’t use a nice buck chip without a small charge pump to supply it 5V operating voltage, there are for example Buck/boost chips that have sort of small caps on both sides of the inductor to supply it internally with a higher voltage than the battery can deliver to drive the switching MOSFETs to get low internal resistance

I have not posted it yet but I am about as far as with the 17mm buck with a 17mm Buck/Boost that can deliver in buck mode up to 4A and boost 2.5A

12

I considered a charge-pump to get above 4.5V but the good compact drivers didn’t separate power-in from control-in.

The microcontroller on my test board uses a 10-bit ADC to measure current and a 10-bit PWM to set output voltage. The compact PIC I’ll be using has a 16-bit PWM but I haven’t determined yet its speed versus resolution so I’m not sure how granular it’ll be on the final product, but even 10 bits is 0.1%

Nice, TPS63020. That’s the same part I was looking at for a potential buck/boost driver.

13

Hi, this sounds like an interesting project. I’m happy to hear the plan includes making the source code public.

People can be very picky about user interfaces. As you said, UI issues are much of what prompted this project… and different people like very different interfaces. So if possible, I’d suggest trying to make sure the driver has code available and can be reflashed pretty easily.

That concern may be a bit lower-priority for this though, if the goal is to make a tactical-style light with just one or two modes on a rear clicky switch, with a minimum of 25 to 50 lumens. There doesn’t seem to be a lot of overlap between the tactical crowd and the fancy firmware crowd.

It would probably be a good idea to include low-voltage protection though, and possibly thermal regulation too. Zoomies and P60 hosts like the WF-501B don’t have very good thermal dissipation, so 2.5A sustained could cause damage.

14

The microcontroller I’m planning to use does have an internal temperature indicator. It’s not terribly well calibrated so would be best as a threshold monitor rather than a continuous-range thermometer. Provision for ramping down power or even a full disable above a certain temperature would not be difficult. A more complex driver could utilize an external sensor on an I2C bus but that would require a micro with more IO.

For my own use, I’ll probably stick to single-mode or, at best, a two-mode with low and high. My code commenting is thorough so adding or editing brightness modes as a third party should be fairly simple. I’ll probably code in a strobe mode as an example but won’t use it past testing. Implementations with single-mode, multi-mode brightness and multi-mode including strobe modes will be available for customization.

When you say “tactical-style”, what exactly does that entail? I’m really just looking for a particular size that’s handy to put in a pocket. I don’t like all the modes and I don’t like all the jagged protrusions things specifically advertised as “tactical” seem to require. If I did go in on a batch of something like the 501b bodies I’d see about custom-maching the bezel to get rid of pocket-snaggers.

I’m finding it difficult to locate a zoomie light body with a smooth bezel also. The one I have to test with has an aluminum pill that threads into place so it should be better than the P60 at transferring heat to the body. That insert in the 501b has me worried about its ability to clear heat. But I won’t be able to do burn-in tests until my PCBs are in hand. Just found out they’re completed but haven’t shipped yet.

Regarding fancy firmware: feature creep is not my friend.

15

Right, there’s more than one definition of “tactical”… but I’m not talking about “tacticool” with sharp edges everywhere designed to hurt people. I just mean something with a mechanical tail button for overhand or cigar grip, and a very simple UI. Usually these have forward clickies (tap while off for momentary use) instead of reverse clickies (tap while on to change modes), but not always. Usually they have one mode, or a small number of modes without memory, with high first.

The entire category of P60 lights is a popular type of tactical lights. They were originally designed to protect incandescent bulbs from shock and insulate the user from its heat, while also making it easy to swap out the light engine. With LEDs though, the P60 design has become far less popular and many people migrated to smaller designs with integrated pills for faster thermal transfer.

As for what is popular these days… er, Zak and /r/flashlight maintain a nice list of popular lights.

If SolarForce was still around, I’d suggest looking there for P60 hosts. They made some of the best, and for pretty decent prices… but they closed and I’m not sure if anyone is making quality P60 hosts any more. It seems like most of that market moved to tube lights like the Convoy S2+.

About zoomies, the best one I’ve used is a Jax Z1. It may be a bit large though, and zoomies in general are typically somewhat specialized instead of general-purpose. I mostly use mine to scare away noisy owls without disturbing the neighbors.

16

Simple tailswitch, simple UI, sounds about right.

If I’m looking at the right thing, that Z1 is definitely without sharp edges, but my pocket won’t accomodate a two-inch bezel. The lights I have to play with are in the 25-30mm neighborhood which is pretty comfortable so I’d like to stay in that size range.

It’s probably pretty crappy by y’alls standards but back around 2012 I picked up a couple of single-mode lights in some branding or other (I believe Small Sun ZY-C84) of this body. One was stolen and the other burned out but I still have the body and it was about the only thing I found that fit all my criteria for size, general appearance, function and non-stabbyness.

I wouldn’t mind being able to offer a fixed reflector option as well in a similar form-factor. P60 body is just what I have on hand to mess with (and also what I know I can acquire in bulk) but isn’t a design requirement. I lack the machining infrastructure to make my own at present, but maybe someday.

17

I would guess, based on your linked list of popular lights, that 18650 “Duty lights” would be most likely the category I’d try to work in. “Simple operation” and “reliability” are two of my favorite things to design for. My best friend is a first responder, daughter of a cop and an ambulance driver, and she’s already asking about getting some lights for volunteer firemen and as door prizes at fundraisers. I would enjoy being able to offer customizable packages for her people.

Also got word my prototype PCBs should arrive on Monday so I’ll get to start testing next week. Still need to adjust my code for the different microcontroller but that shouldn’t take long.

18

Hi Sidehack, welcome to BLF!

19

Is your initial design for 1S?

20

Yeah, single-cell only.

Couple sample bodies arrived from the factory yesterday so hopefully soon I’ll get a board populated. It’ll take a few hours to update the program for the right microcontroller but hopefully next week I have something working.