Haha, that’s a interesting idea! lol
I think that will be the main force of future design.
2 Thanks
Anduril does run on regulated drivers and the step down / LVP is done by Anduril.
3 Thanks
Anduril has supported regulated / constant current drivers since 2018.
Anduril’s LVP is implemented in software. It measures the battery voltage continuously, and when the voltage is too low, it generates a LVP event. When the light is on, LVP events cause it to reduce its brightness. Or if it’s already at the lowest level, it shuts off.
Some regulated drivers can operate well below the safe levels for a li-ion cell. Like, I have one which can light up the LED with an input voltage anywhere from 4.4V all the way down to 0.5V. It’s capable of maintaining constant brightness the entire time. But when the battery goes under 2.9V, Anduril activates LVP in order to protect the battery. It drops in brightness several times then shuts off, and this process typically takes several hours because battery voltage recovers when the load is reduced.
5 Thanks
@ToyKeeper, I always wondered, from a technical point of view, is it possible to simulate a constant output with FET driver by varying PWM intensity based on battery voltage? I know it’s not a constant ratio but if it is being measured and calibrated from factory with several data points, is it possible to at least maintain a somewhat stable output instead of letting the output drop like a slope.
So the firmware will have a 2d look up table based on mode and voltage and gives a PWM value for output, something like this:
VBatt L M H
4.0v 2% 9% 25%
3.9v 3% 11% 28%
3.8v 4% 12% 30%
3.7v 5% 14% 32%
3.6v 6% 16% 34%
3.5v 8% 18% 38%
3.4v 9% 20% 42%
3.3v 12% 22% 48%
It’s a very crude example that make a PWM based FET driver simulate a constant output driver. Would it be technically feasible, given the limited storage and memory of the controller chip and is there any interest form manufacturers or users to make it happen?
Or maybe the real constant current output hardware is cheap enough that this software solution doesn’t really make sense. However, given number of FET driven lights on the market (huge), this calibration at least makes it a bit more palatable for me to buy them.
1 Thank
It’s theoretically possible to reduce the voltage-based sag on DD FET PWM output for levels in the middle of the FET’s range, using hardcoded estimates of what the curve might look like… but it’s not very practical.
The MCU doesn’t have a way to measure the LED voltage or current. It can’t regulate those because it can’t see them. So it would have to use hardcoded estimates.
But it varies per LED type. It might get flat-ish output on one LED, but buy the light with a different LED and now the output has a weird response curve. Making one better makes the other one worse, and the firmware typically doesn’t know what LEDs are going to be used.
With careful calibration though, it could theoretically make the medium-high part of the ramp have more consistent output over time, on FET+1 style lights.
However, the levels which could potentially benefit from this are generally high enough that they’ll be limited by thermal regulation, which would override any attempts at flattening the FET. Instead, it ends up with a different type of flattening… and regulating by temperature tends to keep the brightness reasonably stable.
Recent lights are also shifting more toward regulated drivers, which makes the whole thing moot. Wurkkos already has working prototypes for a boost driver.
Personally though, I barely ever use more than 100 lumens, and when I do, it’s in short bursts. So the levels I use are already regulated (even on FET+1), and regulation isn’t as important for burst use.
2 Thanks
Thanks for the response. It makes sense. It’s just a guessing game on the MCU part so it’s not a very practical way to regulate output. An interesting thought experiment nonetheless.
Thermal regulation is better but it also suffers from inaccurate temperature reading. If the thermal sensor is integrated into the MCPCB then it can be used to accurately control the output. I see many automotive LED light have sensors right beside the emitters.
FWIW, here’s the thermal regulation pattern on a FET+1 light:
It’s not totally flat, but it’s close enough that the variance doesn’t make a big difference by eye during use.
3 Thanks
That is a lot better than most other FET lights I saw. This kind of regulation is acceptable to me.
I guess this is running at max output? Thermal regulation in medium modes might be trickier since you have to designate a temperature that is medium level?
Just have to say I love this exploratory discussion! Even if various ideas are impractical or won’t with, it’s great to see them discussed from everyone.
To avoid taking this thread too far off topic, I moved my reply to the anduril thread
1 Thank
Aww, I was hoping for a 7*CSP2323 in a nice duv-dropping mix.
1 Thank
Only compatible, or will you update it to match the new design?
I have one of the short tubes you already do, and while it works fine, the style doesn’t match, and it would be nice if it did-- that’s what I meant, was a matching short tube that comes with the light, like you do for the TS11.
1 Thank
Off the wall thought:
Any chance there might br a Non Anduril version in the future ie the “Simple” model, like the newer TS11S?
2 Thanks
The best part is this could be done just with UI, the simple UI could still be running on FSM.
That way, it can be flashed from anduril to simple and back.
1 Thank
I’ve been debating maybe adding a few extra UIs inside Anduril, so people could choose one without even flashing firmware. Not sure how much extra space it would take, but it would probably simplify production quite a bit by eliminating the need for multiple versions of the same light.
5 Thanks
Only thing I would see an issue with is that the people who might use the extra-simple UI would have issues getting to it, if it’s behind a menu or a certain number of clicks.
To be perfectly honest that would defeat a lot of the purpose of a simpler UI light for me… The same software in place just running a different “front end” that is selectable, means someone can still accidentally activate the "regular " anduril interface, and access all the settings menus and royally screw up the light. I like non anduril lights because they can be gifted or lent to Anyone without worry of how many times they accidentally click it and get into heaven only knows what menu’s.
Same hardware with a completely different software flashed to it, or an Anduril with No config menu available without flashing would be fine…
actually an interesting idea I
hadn’t thought of to try it before, i dont need the config menus any more the way i e customized A2, wonder, can I de-activate the menus being available?
Simplest I’d bet is to just burry them with needing a couple hundred or more clicks to activate… I did that with something else I couldn’t turn off becauseof dependencies, cant remember what now… maybe it as where tactical mode needs strobes available in the regular mode… something like that.
Hmm.
F1 is my favorite aesthetically.
However, more important than any of that would be a well-regulated driver. I’d be happy to pay more for it. More flashlights with drivers like the TS22’s, please.
1 Thank
The TS26 normal version would be available 2 month later. The TS26 Anduril version would be available 3~4 month later
2 Thanks
I entered the world of flashlights because of BLF.
Now I have more than 32 flashlights, more than 10 are anduril 2 and of various brands.
And it is true, the summer I was able to test the flashlights.
The anduril models are just for me, I love them.
That day I gave flashlights to the family and as in simple UI there is no Strobo (for fun) I put advanced to all.
I’m returning the flashlights!
It was chaos and I had to reset them all.
I will never again give any light with anduril to people who don’t know what they are doing.
It’s a shame but it was a real case.
I think it is missing a simple mode, that has smooth or stepped ramp and a single strobe mode.
In simple UI mode nothing happened nobody got to advanced but they asked for Strobo, this is where they messed up 
because to have strobo they have to be in advanced.
That is another option, once configured in advanced mode, a single strobe and without turbo or with turbo.
11H and H=25 seconds locks and unlocks the configuration.
This way it is impossible to reach it.
Certain button combinations would be nearly impossible for a user to hit by accident. I’m a bit skeptical of 9 clicks and a hold happening accidentally. But much longer like 100 is wild. How about 10H after screwing the tail cap in with the button held, or longer hold requirements for going to Advanced UI?
Lots of possibilities to make it less improbable, though I’d like to se more numbers on accidental 10H’s
1 Thank