It’s not so much that the internal sensor is bad. After calibration, it’s pretty decent. The main issue is that my algorithm isn’t very good. :confounded:
Lone Oceans used PID Library V1.2.1 by Brett Beauregard in his GXB172 driver, who claims to have adapted an existing robust pid control loop to Atmel controllers. Might be worth a peek the next time working with thermal regulation sounds fun.
Is the Anduril/1634 firmware ready for general release or just a few specific applications?
I took a look a while back when the code was released. It isn’t exactly a drop-in replacement for what FSM uses. It would require either rewriting the entire library or removing a bunch of other code to make room, and would also require rewriting all the code and abstractions used to control the main LEDs.
So I’ve been thinking about how to rewrite things with different abstractions, and how to implement more fine-grained linear control over the output instead of working in an abstract perceptual ramp. That’s the first step. After that’s done, the actual PID bits of the code are relatively easy… except that testing and calibrating everything is very time-consuming so I hope to make a simulator instead of having to do it all with real hardware.
Basically, there are two hard parts — the abstractions and the simulator. What’s in the library is the easy part.
(In more detail, a regular PID system needs to work in a linear power space but FSM uses a curved perceptual brightness space instead… and the curve is different on every light. One perceptual step could change the power output by anywhere from ~1mW to ~3W, so it has a difficult time deciding how far to adjust. Additionally, the thermal algorithm doesn’t actually control the output… it just sends suggestions to the UI. And those suggestions are rate-limited, which can also make things more complicated. So the entire thing probably needs a rewrite involving some fairly deep structural changes.)
Hmmm… this is a thought!
What about jumper/solder-points for maximum voltage and current limit?
A 6V jumper leads to 3-4-5 amp selectors
12V to 1-2-3 amp selectors
Something that can be easily set via hardware, like I seen on these Star drivers I spotted somewhere
Don’t know if it may be possible, but it’s an idea
Thanks KnHawke for the great idea. In fact my previous drivers do have solder jumpers for exactly this sort of functionality. :) I'll always try to break out unused pins for this reason; however they do require firmware modification, and the firmware needs to support it. The challenge is maintaining such a standard, if the target firmware is a stock community one.
I know thermal regulation takes a lot of your time and isn’t much fun for you, I was hoping for a bit snarkier reply.
Goa has two other drivers he has talked about releasing. A one hundred watt single cell boost driver that will need finely tuned temperature management and a sound controlled linear driver, possibly with voice recognition. Its going to get interesting around here if he can get enough spare time to release them.
well bugger! That does put a wrench in the works!
Of course, ya already thought about adapting your current design for the GXB172 and 202 to run on a standard Atiny MPU?
100 watt!! That’s double of existing boost drivers. Are you sure about that? Maybe they are really large drivers like in the astrolux mf01 and mf04s?
I was thinking the other day, that its surprising we dont have a wireless charging driver in the aftermarket/moding world.
I would love to see a simple solution for wireless charging.
What do you mean, inductive charging like a cell phone? I don’t think it works through metal. So you’d need a plastic flashlight. :confounded:
Not exactly.
He probably means something like in the tailcap.
Would not be good for charging efficiency though, along with speed.
@Jason, he is using top of the line GAFETs. These things are absolute beasts for their size, since their working internal resistance(not interconnects) is much lower than traditional MOSFETs.
So yeah, it is a beast of a driver.
Now that the FW1A is out, I’m really hoping a more stable driver like this comes to fruition. I’d love it to be able to drive a beefy 12V XHP35 HI, but even steadier output at 3V would be awesome.
So your talking about small drivers like under 22mm? I recall that burnt traces on the pcb tended to occur when the amperage go too high. I don’t think the gafet would have any effect here. Maybe he’s using more expensive really thick traces?
Not really actually.
See here:
Nice project!
My suggestions, well, preferences would be something like the following:
1/2S - because I'm thinking about the 2 * CR123/16340's mainly and 2 * 18350 compatibility (the CR123 primary Lithium's because of their shelf life and the 16340/18350's because.. they just fit, so.. why not)
I'd say a buck only driver would do just fine ? Although I've no preference if it'll end up being a buck/boost and taking anything from Alkaline primaries to Ni-Mh/Ni-Cd and up to 2S Lithium secondaries..
Efficiency and the a BLF UI like Anduril ? "Of course! I'll take two!" (well.. maybe a couple) Myself, I'm not aware of any Buck, Boost, or Buck/Boost driver/s running Anduril, Or Narsil or such FW's.. Are there any ?
Simple bi-color LED Batt. Lvl. indicator on the driver's PCB that would be lit Green > Lime > Yellow > Orange > Red > Blinking Red when the light is on, for either 5 seconds from On, or constantly On.
I know that there's a voltage indicator function in the Anduril or Narsil FWs, but that's only accessible while the light being powered Off and not really user friendly and seamless for the average non flashaholic.
Not interested in over 3 Amps myself or direct FET drive for Turbo, I'm more interested in being able to drive something up to a regular XP-L/XM-L and down to an XP-G/XP-E without the risk of frying them.
Also interested in having control over the max current, as previously mentioned, via shorting some pads on the driver (shorting serial current sensing resistors I'd take it ?) - Something like 1/1.5/3A maybe ?
As for the size, I'd say a common small size like 17mm would do just fine and also make some adapters like the Convoy 17 to 21mm adapter, but for more commonly used sizes, up to 28mm ? Or.. even cheaper..
The way I've fitted a 17mm BLF A6 driver to my Civictor T5 20mm driver, was taking a 20mm tail switch PCB and since the BLF driver was single sided as well, I've just sandwiched it on the switch's PCB..
So I'm thinking maybe you could make this driver single sided as well and some PCB adapters in different sizes with only the spring pad and a hole in the middle to make it easier to bind/solder the two of them ?
USB charging - I don't think this would be feasible - for starters, because as you've mentioned, there's no USB port cutouts on most hosts and also fuel compatibility would be limited to 1S (?)
About the temp. sensing.. not sure about the external sensor - I could do with or without it as long as the sensor in the MCU is decent enough - After all, the general consensus was around 3 Amps tops ?
Also about the temp. sensor calibration, I'd say the "hold until hot" route would be making the factory calibration irrelevant anyways ? As we'd only be interested in the max temp. that we'd be comfortable with ?
Not sure if this would be FW only related, but could we have a LVP cut-off Voltage configurable from ~2.8V to around 3.3V ? Some would comfortably run the cell dry, and some would be wary about the voltage.
Thanks everyone for the great feedback! Please keep them coming, and watch here for updates 
3.3V cutoff?
If the aim is to be able to utilize as much energy from the cell as possible a high cut-off is completely undesirable. I must also say that, according to my experience and corresponding beliefs, (little?) nothing is to be gained with a high cut-off; maybe a small stress reduction for the driver, if anything. Since the actual voltage input into the driver is cell voltage minus path (springs, switch, etc.) times current voltage drop, I would instead lower the cut-off even more if possible, to 2.7V or just the lowest driver feasible and li-ion acceptable figure (like 2.5V).
This is not at odds with 80T's suggestion anyway.
Just my point of view, of course. 
I'm not sure what the goal is regarding yields per cell, but I know one of the goals it's power losses cut-down, efficiency, thus, for any given capacity this driver should waste less power than a linear one. Where a high cut-off wouldn't make sense at all would be when using primaries, although if the driver would be recognizing cells by voltage, then we could have cut-offs by cell types. My opinion is that the more option, the better. Myself, I just don't like to run my cells dry.. usually.
About the current path losses, with some decent springs and this driver not being high power, I'm not sure how much would that be a concerning if at all relevant factor.
Subscribing! My 2 cents…
Output: I’m probably in minority here, but I fully support the 3-5A limit. I much prefer a constant current output instead of the FET “wow” factor that gets the flashlight blazing hot and then needs to step down right away. Sure, 3000 lumens in a tube light is neat for 25 seconds, but give me 1000 lumens for several minutes any day. For this, our traditional 7135’s aren’t bad, but regulation is limited by the voltage drop and their linear nature (no buck/boost). I’ve also used the QX7138 lately with an external FET - so far, so good, but I haven’t fully tested them yet.
Programming: I really like the simplicity that 3-pin UPDI programming brings, but that’s limited to the newer AVR chips (0 and 1 series). While I (and Mike C) really like those new chips, we’ve otherwise seen almost no traction in their adoption. It’s too bad… they’re great to work with.
I do have firmware rocking for e-switch lights using the 1-series. I’ve got some custom stuff written, but I’ve also ported TK and Tom E’s excellent RampingIOS over and it’s working flawlessly - I’m using it in my Convoy H1 (stock driver with new MCU), Emisar D1S (custom driver), Sofirn D25 headlamp (stock driver with new MCU) and others. I also hope to have Anduril ported over soon-ish, but I just need to get re-engaged on that effort. As far as clickies go… I just designed a new clicky driver using the 1-series, but found that I couldn’t use our tried-and-true noinit trick to detect fast presses. The SRAM was taking around 45 minutes to decay instead of the ~1/2 second that we’re used to. So in order to use the 1-series with a clicky, you either need to use on-time memory (yuck), OTSM (as Mike C is doing), or an OTC. To be continued…
So I have an idea/suggestion for simulating the benefits of having like 8x 7135 with just the FET. But it’s so simple I don’t know why I haven’t seen talk of it.
Currently if you want to maintain a brightness that’s 60% (of maximum), you stack 8x 7135 and send them a 60% PWM signal. As the battery voltage falls, the 7135 maintain a constant brightness down to 60% battery.
Well space is limited, so why not do it like this:
Let the code monitor battery voltage. If the battery is fully charged, PWM = 60. If the battery is 60 PWM = 100%. Now for smooth transitions you want to use a multiplier instead of just if/then statements. And the perception of brightness comes into play. But with the extra code space of the new drivers, this seems quite feasible and should free up a LOT of board space on the drivers. And lower cost.