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

I tried to take a reflow video but I forgot to set the quality to max :

1 Thank

The video is still clear enough. Very nice. How do you reflow the components on the battery side of the driver, hot air?

I use a handled infrared heater I made a while back with a car cigarette lighter for the second side, but yeah hot air would work as well if not better. This particular driver only have an optional additional PFET on the back, so it can be redlowed with the hotplate only.

1 Thank

Thanks!

I finally assembled the light :

I tried using cyan+warmwhite+pink, I think I prefer the good old RGB though.

FWAA 219C sliced with boost driver vs FW1AA on li-ion :

1501cd vs 5675cd
670cd vs 3150cd on NiMH

I find the beam of the FW1AA much more usable.

1 Thank

Exciting news. What optic is that?

It’s a Gaggione LLC22N.

LLC22N (Petit)

The spot looks very good with it but the outer part of the spill has some diamond shaped artefacts, the datasheet recommends putting the center of the LES 0.4mm under the optic whereas here its at 0mm, it’s possible the artifact will disappear at 0.4mm and maybe the intensity will increase as well.

I also made a new version with cost optimisations :

Using the TPS62867 buck converter (cheaper and also a bit better than the MP2145 previously used) and a less costly boost converter for VCC.
it’s still a rather costly driver though, I’ll order the boards and test, then maybe do a small production run.

5 Thanks

Very excited about this!!

Great work! where can I buy your drivers fully assembled?

Nowhere at the moment.

I did a couple of runtime tests with BST21 in D4K (sm453 dd). Optimized thermal parameters in Anduril along the way towards long turbo and stable output. The output was approximated with a lux sensor and shall only give an idea, if it is stable. Temperature was measured at head of flashlight.

The 40W+ turbo can be held for ~30sec, if a slight overshoot in host temperature is accepted. For turbo I think this is fine.

As time passes output stabilizes very well! Temperature fluctuates by +/-1 degrees Celsius with a slight tendency to slowly decrease.

Ramp Ceiling (~12W LED power) can be held for ~7-8 minutes, before thermal regulation kicks in.

Overall thermal regulation seems to work pretty reliably, well done freeman :wink:!

6 Thanks

Good job!

1 Thank

This is a more technical post about Anduril code and maybe interesting for @gchart, @ToyKeeper, @loneoceans, @thefreeman and @Haukkeli :grin: . I tried to make it as simple as possible, so that more people can understand what this is about.

To achieve proper thermal regulation with next generation drivers, which utilize a DAC and a dynamic VREF (e.g. freemans, lumes), it can be necessary to introduce changes into the thermal regulation code of Anduril 2.

PROBLEM

During gradual ramping the output changes gradually towards a given target ramp level. These gradual steps can actually be smaller than ramp steps, because DAC0_VOUT is changed in steps of +/- 1. So if the current DAC0_VOUT is smaller than the one of the target level, DAC0_VOUT is increased by 1. Otherwise it is decreased by one.

Now let’s say upon start at ramp ceiling the light gradually regulates down towards smaller and smaller target levels to not overheat. At some point a level might be targeted, which utilizes a smaller VREF and a very large DAC0_VOUT. Then DAC0_VOUT will be gradually increased towards that new large value, while VREF is still unchanged. Hence flashlight goes to turbo and thermal regulation becomes unstable.

Here is a sketch to somewhat illustrate how DAC0_VOUT and VREF change along the ramp in these new drivers. Towards higher ramp levels VREF is stepped up and DAC0_VOUT “restarted” (lets assume there is only one sense resistor). This output control scheme is not yet fully supported by Anduril 2.

SOLUTION

When gradual ticking, check if actual level and target level have the same VREF. If not, still decrease/increase DAC0_VOUT and at some point transition to new VREF level. Here is the fix

It’s only used, when specified in hwdef / cfg and the transition point is defined by two variables.

Please feel free to copy this fix into Anduril! Any plans to move development to GitHub? :sweat_smile:

6 Thanks

Have you had a chance to test these?

1 Thank

Actually I’m looking for a FW3A version.

Is this the driver being used in the new Emisar D3AA?

Physically it’s different, but the topology used is the same, with a few other changes (different MCU) and additions.

4 Thanks

So. Any chance for a run e can use in the Fwaa? That and a series connection mcpcb…

2 Thanks

I think this driver is missing the inner tube contact ring.