thefreeman’s HDR Anduril 2 high efficiency drivers - update : FWxA boost driver

I think you didn't formulated this question correctly, and so you may want to reformulate it.

In my opinion there's interest in regulated output designs. All regulated output designs ensure constant current output (and so PWM-less standard modes), for as long as the input requirements are met. A regulated output design ensures an led cannot receive overcurrent, even if emitter is low Vf, all current paths are optimized and battery resistance is low (high discharge batteries).

Current limits can also be raised for regulated drivers, particularly for linears or variable load drivers, by the way. This is done by modifying the sense resistor or sense resistor stack.

I was inferring from Quadrupel’s post that cost wasn’t the main hinderance thus leaving demand as the limiting factor.

It doesn’t have to be, some of Sofirn’s lights have it, and they don’t exactly break the bank.

But if you’ll recall this thread, when the SP32 evolved with a more usable, regulated driver, it lost some lumen bragging rights, and that’s a turn off for some, if not a lot, of people.

I don’t think Sofirn has any regulated Anduril models.

They don’t; was speaking of regulated lights in general.

And as explained above, Anduril isn’t really congruent with regulated drivers, at least without some work, and I don’t think what it brings necessarily justifies that sacrifice.

I don’t count myself among those calling for Anduril any and everywhere, because I do value regulation, and the two are at odds, at least in the marketplace.

Anduril doesn’t care about the type of driver as long as it accepts PWM or analog input.

Count me in as interested in regulation, and also in using a CPU with more code space than the small AVR’s, even if it adds some cost.

While not exactly related to this, I'll post here a message I submitted to ToyKeeper recently (≈2 days ago):

This passiveness could mean lack of interes, although I'll keep listening. :-)

I wanted to say this because among other things ToyKeeper created Andúril and many of these sophisticated firmwares. ;-)

Concerning moonlight modes, I'll share with you a nice idea.

As the technically inclined among you already now, the very low current required for moonlight modes usually causes some trouble with the either the low resolution of MCUs (mainly), sense amplifiers, low or super low sense voltages (which are a must for high power and efficient designs), switching noise… or a combination of any of these.

There's a cheap way to solve this despite using low resolution MCUs, at least for linear or variable load regulated drivers. This is to use an alternative output path, a resistor in parallel with the standard driver output, for a moonlight mode. This way, fully closing the MOSFET gate in regulated linear or variable load drivers would only allow the very low current of the resistor in parallel from input to output to go through. Since a “3V” led has ≈2.5V of Vf at super-low currents, it is easy to calculate a resistor for a regulated linear driver presuming ≈3.6V of input voltage. R = V / I, and so a moonlight mode resistor for, let's say, 100µA moonlight, would be Rmoon = (3.6V - 2.5V) / 0.0001A = 1.1V / 10−4 = 1.1V × 104 = 11kΩ. This moon mode would not be constant current, with moon current varying from 154.5̅4̅µA with 4.2V at the input, the no-load voltage of a fully charged li-ion battery, to 45.4̅5̅µA with 3V at the input, the no-load voltage of a technically depleted li-ion battery. But this is a minor complaint, imho. The moon current would be flowing at all times into the emitter.

Hope this is of service. O:)

Like you said it would be always on so I don’t like this idea, with a small FET an resistor you can add another low power channel on a linear/FET driver, dimmable with PWM but the output will vary with the input voltage, I don’t really like this either as you can’t make a smooth ramp all the way up this way, which is kind of the main feature of Anduril is it not ? Plus I’m more interested in DC-DC converters.

The dual sense resistor solution only needs a <50$c NFET (if there is full Anduril support, otherwise an hardware delay is needed adding some components).

Converting Convoy drivers to community firmware should be possible, for those that use uncompatible MCU (most of them), they could be replaced by a small 1616 on an adapter like Gchart has done for the SP10S, the drivers take a PWM signal in so no problem on that side. A e-switch solder pad could be added on this adapter to use Anduril. Though there might be some quirks there and there. Like on the XHP35 driver the Vbatt voltage divider is after the LDO so it can’t read the whole batt voltage range. Probably other weird stuff too that one might see by reverse engineering them.

Emisar (Linear+FET) and FF (buck+ FET) lights use CC drivers with Anduril firmware.
Cost ? Sure, especially for DC-DC converters, also 7135+ FET design are super cheap, super simple, barely any knowledge needed, hence why they are also popular within the community where Anduril originates from.
Power density : a FET driver can achieve ludicrous power in small size and lumens sell.

You’re underestimating the impact 15$ parts has on the manufacturer’s margins.
Also I want to point out that a buck driver doesn’t mean efficiency. I measured the efficiency of the Skillhunt H04 driver and got arround 80% in high (less than 1A), that’s bad, linear (in average) driver bad, it uses an asynchronous buck converter and probably cheapens out on components.

True, but sometimes there might be some quirks that needs some actions from the MCU in order to mitigate them, which are not supported in Anduril, more on that later.

(sorry for the lack of updates)

Oh! Well, concerning simple regulated linear drivers you could feed the moon resistor from an onboard LDO (3kΩ for a 2.8V LDO presuming a Vf of 2.5V), and switch it on/off with a tiny MOSFET. ;-)

For switching drivers the dual sense resistor is great, but there's a need to switch off the bigger conductance sense resistor efficiently.

You would be connecting the output of the LDO to the batt+. This would require some isolation like how the output of the buck is disconnected with a FET whent the DD FET is ON in the Lume1 driver.

There is no efficiency cost in my dual sense resistor circuit, since the FET resistance is part of the sense resistor. I changed the FET for one that gives me a more realiable Rdson (~2mΩ), it’s also significantly less expensive.

Ok, your right, I should handle the criticisms more gracefully, I apologize for that. It's over.

I must correct myself here, the resistor channel being in parallel the linear channel just adds up on top of it so no issue for making a smooth ramp, not sure why I said that especially since I started designing a linear+resistor driver a while ago (never finished it).

Barkuti, re the ATtiny13A board: ToyKeeper is of course the Queen of Andúril and I’m just a newbie, but I’ve been studying the code some. The ATtiny13A has only 1k of program space and it would be hard to fit many Andúril features into it. There are some references to the ATtiny13A in some of the older(?) Andúril source trees but TK’s current tree doesn’t seem to support it. You’d also have to do some reverse engineering of the board to see how the pins are connected up, and adjust the Andúril code accordingly. Plus you have to know how the driver works and make sure the code reflects that too.

This is an awful lot of effort if you just have a light that you want to mod. If there are a lot of them involved, then it might be worth it. If you are looking to make new boards, spend a few more cents and use a bigger version of the cpu, that can hold more code.

Had a few words with ToyKeeper via pm recently. In my inquiry I mentioned Crescendo for the ATtiny13A in Simon's ramping SST40 driver. Among other things, she told me “… I tried to get Simon to use BLF firmware, but he does not seem to be interested. He has a local friend doing all his drivers and firmware for him, and I doubt that is going to change.”

Wellp, things can change, after all Simon has ordered various custom products for by the BLF crowd, see for example the 8A buck driver which is marketed for the CULPM1.TG. In my honest opinion, by the way, such driver at 8A is toasted, overcooked for the (4040 2mm²) CULPM1.TG; I once made a custom (3030 2mm²) CSLPM1.TG build and decided to set it at 6.5A, according to my measurements there was nothing to be gained beyond that current in that build.

What Forsyth P. Jones said.
Anyhow this is a bit off-topic.

Please start a new thread on your topic Salvador, it’s all interesting stuff but you are getting way off in the weeds here.

Sorry for the off-topic thingie, I was just sounding out the stuff. I could post about it in the Convoy thread, but… :-/

Concerning the words I had with ToyKeeper, she's with a serious health problem in case anyone's wondering; will take some time for her to consider getting back with firmware development.

End of off-topic.

TK is very actively involved in SW development: see the current dynamic PWM thread for example. It is brilliant.

Regarding the new driver board: I realize this is BLF but given that this is a custom development, I’d rather have a board without compromises even if it costs a lot, than yet another cheap light that Aliexpress is already full of. So I’d want dacs and constant current drivers for flicker free dimming down to super low levels, a low power channel for the moon modes if that’s how it’s done, several aux channels for e.g. RGB pushbutton or rotary control, plenty of code space and cpu so that ramping can be calculated on the fly instead of with lookup tables, and also enough space for a USB communication stack and boot loader to make configuration and reflashing simpler. These are once again amazing times to be a flashlight modder.

So to give an update, I received and built updated boards a while ago, I used 0603 and up passives as opposed to the 0402 of my first design :

(Don’t mind the poor solder job, I swapped some components here and there )

One issue that bothered me is the whine at low loads, the first driver I built also had some but it was very faint. The 2 others were more audible, I’m more sensible than the average person because I have hyperacousis, hence for me this is unacceptable.
As mentionned in the previous page at low loads the regulator starts to skip pulses for higher efficiency, at some point the frequency enters the audible range and vibrating components (inductor, MLCCs) can make audible noise. In this case the noise comes only from the capacitors and not the inductor.
There are several articles about MLCC noise : for example
They list several things that can influence the intensity of the noise such as :
Mounting orientation, vertical or horizontal internal layer, which are impossible to know in caps with a square section (the vast majority), vertical mounting is more noisy.
Solder filet size : too much solder leads to more noise.

Those two can explain the variation between the 3 drivers I’ve built, I verified the orientation thing by testing a few capacitors on the two orientations and indeed that affects the noise.

I also built drivers based on the TPS61178, but never heard anything despite it also having a pulse skipping mode, the reasons I think are that smaller cases make less noise, I used 0805 caps because I’m running it at a higher frequency, also because it has a shorter minimum pulse lentgh (being able to switch at 2MHz vs 0.5MHz for the TPS61288), so the transients are less energetic.

As mentionned in the article there are special MLCCs with less acoustic noise, the problem is that they are pretty rare, more expensive, don’t exist in 1206 case and up (AFAIK), I did try making those caps on interposer by adding a copper spacer under each terminals (as seen in the pics) it is as annoying to do as it works, additionally after finding the right orientation for the caps the driver makes barely any noise, not a realistic production method though, probably poor reliability too.

They also mention that when mounted on the opposite side of the board the vibrations can cancel out each over, that might be worth a try, along with trying caps with a rectangle square section to identify the internal layers orientation.

Another point is that the TPS61178 TPS61288 can’t maintain 5A@6.5V for long before it starts overheating and hiccuping, that is before the firmware even starts to throttle down, even on 2oz PCB with decent copper pours, in that regard my first design was better because the regulator was located closer to the edge where I could place a lot of thermal vias to a large copper pour on the back, though when located in the center in my second design the layouting is much simpler, by using a smaller batt+ pad (brass button only) I could place more vias. 4A seems to works fine.
I assume that the small size of the TPS61288 doesn’t help for thermal transfer either.

Anyway due to those issues I designed another driver based on the MP3431 and also built one a few weeks ago, the MP3431 has an ”ultrasonic mode” in which the frequency doesn’t drop below 23kHz (more like 30 in reality), hence no acoustic noise, there is also no need to apply a minimum load with a resistor in order to prevent flickering at very low currents.

(The through hole resistor was for a test)

Unfortunately it was still noisy on the low range, for another reason : unstability :( . I put it aside to work on other things for a change, I got back to it recently and tweaked some values to make it stable by slowing down the Op-Amp, which leads to another issue : a current spike at startup, mostly visible at the bottom of the high range, I believe this is due to the Op-amp output now taking too long to rise at startup (if OPA output is low > FB is low > regulator thinks the output voltage is too low > need to rise the voltage > more current). This is something that Mike C warned me about and apparently that was an issue on the GXB172 too.


A solution is to delay the HDR FET at startup, there is still a small bump in brightness but it is much less pronounced since the higher value sense resistor limits the maximum current during the spike. Preferably this would be done in software just like the delay needed for the HDR FET when ramping from the low to high range In order to prevent a flash, I explained In detail why this delay is needed here.


Since I don’t have the skill to do that I added the delay in hardware which unfortunately requires 4 components because the delay needs to be only when the FET turns ON and not OFF (otherwise it flashes when ramping down...).
Additionally I improved the layout a bit for better thermal, also did some cost optimisation by using an inexpensive LDO and a better suited HDR FET that is also less costly. I should receive the boards in a few weeks.