This is really an issue with driver design (and instability at very low outputs) rather than the firmware. Anudril itself uses PWM fast enough to be completely imperceptible at every step AFAIK.
I don’t see why Anudril couldn’t be adapted to a driver that solved that issue - however lights and drivers with extremely low moonlight that is flicker free generally aren’t cheap, because the drivers that can accomplish this are difficult to engineer and more expensive to produce.
The entire point of this light is to get Anduril on a AA-sized light, so not sure what the purpose of criticizing the blinky modes of Anduril (which I woud rather do without personally too) would be??
Why not? It just tells the driver “I want 1/1024 brightness” and the driver is responsible for reaching that goal. Don’t confuse bad driver design with the firmware.
Then don’t buy a light with such modes or don’t use them. This project is all about developing a driver that supports Anduril.
But it is not Anduril.
It’s all about the driver. If it can power the microcontroller, it could potentially run Anduril. Just that Anduril is developed for ATtiny microcontrollers.
See above, this has nothing to do with the firmware, but with driver design.
Maybe jon_slider refers to the recent issues with the KR4? The driver uses a FET as a linear current regulator. Its main component next to the FET is an opamp. This opamp gets it’s reference voltage from Anduril via a low-pass filter / integrator. For every linear regulator you have to set a lower and upper bound in the design. Level 1 and 2 out of 150 set the reference to 0 V. At this level the opamp is not able to maintain stable regulation.
How could this have been fixed? By using two regulators. One for very low currents, one for higher currents. But this needs more space on the PCB, increases the BOM and thus is more expensive.
You've posted this several times, in various threads, since at least last year. (I've also attempted to gently correct you before.) I don't care if you dislike Anduril (you've mentioned blinkies and complexity before which are very valid points in their own right), but I ask that you stop spreading false information about it.
It is not an Anduril problem. It is a driver problem. It is consistently difficult to achieve very low levels using the traditional 7135 and/or FET design. The lowest lows of all my flashlights are as follows:
Absolute lowest: Jetbeam RRT01
SC62(w)
Nitecore EX11.2 on 16340
FW3A and Emisar D4 (pretty even match, actual usability is indistinguishable but I'm sure the lumen count is technically different)
A bunch of other FET/7135-driver lights that don't have a dedicated 1x7135 channel for moonlight
(Note: IIRC there's one or more Manker AA/AAA lights that have a pretty low moonlight)
Notice the common factor between 1, 2, and 3? They don't use FET/7135 driver styles. (The tradeoff, of course, is that 7135/FET is very simple and cheap.)
For a more technical view of things... My understanding is that, in general, you can only effectively run these things so low. You also talk about "flicker-free" low modes, which is fun. I'm not aware of other good ways to control a single 7135's output besides PWM, but I'm starting to get out of my depth there. Anyway, as I understand it, you can only PWM it so much before you start to get some disgusting flicker going on. PWM itself isn't necessarily bad, because it can be done on the scale of thousands of cycles per second, speeds where you'd be lucky to catch it on a camera. But to get down to the ultra lows without switching driver technologies, the PWM gets into lower frequencies.
Also, the KR4 driver in particular has a further limitation on moonlight, which has been gone over a few times: some part of the driver (the MCU or the FET I think, but I'm too lazy to look it up again) doesn't officially support the current of, as I recall, the lowest two configured ramp levels. So by default it ships with the minimum ramp (and therefore lowest mode) as ramp level 3. This can be configured lower but may land anywhere in the range of "works fine what's the problem" to "just doesn't power on at that level", with a lot of in-between landing at "turns on visibly slowly, almost ramping up to the moonlight". This is, again, a driver issue rather than an Anduril issue.
Edit: SammysHP covered some of the finer points in an excellent post above.
Yeah, this. In fact it’s so difficult to design and/or expensive to build drivers that can do this properly, that LoneOceans neglected to address it in his lume1 driver “to keep this as simple as possible and to keep the BOM cost down without sacrificing on the engineering”.
Now you got me envious
I still didn’t give up on getting one of those :+1:
Hum, I guess it is not just flickering , but I do recognize that it is not like a real candle! Nothing will ever look like a real candle, specially because of the fire’s “tint” and the flame’s random movements
Well, I do like and use firefly modes, as you know from our conversations about the RRT01.
At the same time, I admit that a good moonlight level (even if not as low as the RRT01 or the Reylight) would be good in this project.
This is a personal preference and opinion, of course, but I guess the the achievement or not of a firefly level shouldn’t hinder this project from being done.
And I like anduril, I confess :innocent: Even if it is not perfect :smiling_imp:
If you’ve experienced this with the KR4 you’re not alone though. Like SammysHP said due to the driver itself very low levels can be unstable. Just how low it will stay stable depends on the individual light because of variances in the driver components.
Interested, this is a cool project.
Regarding the magnet discussion on previous page, I’d rather there wasn’t one (or as an optional tailcap) to keep it as small and lightweight as possible, and to that end, I’d also prefer not supporting protected 14500s (granted that the driver will have a LVP) to keep it shorter, but maybe that’s not possible if the the body has to stay unmodified from the SP10S.