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

This sounds a bit harsh….I think there’s nothing wrong with Quadrupel offering some of the skills needed to make a driver that he’d like to make while asking for a collaborator to fill the rest.
Maybe he won’t find such person and then it will indeed boil down to whether he wants to invest this much time to learn a new major skill.
But maybe someone will chime in.

Some time ago I posted here in BLF as Quadruppel I think he also posted the DC/DC converter based only on MCU. It is very nice idea and there is achieved in YLP Unicorn as well in LED drivers from Tamagochi user from Fonarevka. The hardware is easy to make but difficult part is software. Also AVR are not the best MCU for that. PIC mcu have better candidates for that. In simple solution you will need some MOSFET and coil and sense resistor. If we don’t use external amplifier wee will need 16-bit ADC at least for good performance. Another problem is switching frequency which will be low anyway. There will be needed chips with fast PWM with higher PWM resolution to achieve better efficiency with higher frequency and control.

The Unicorn/gekko/panda 4 use a linear driver, not DC-DC, but yes Tamagotchi’s driver is what Quadrupel was likely talking about, I don’t know if he has ever made higher power boost drivers than his H03/H04 ones, and with synchronous rectification, because his were asynchronous unfortunately.
Gate drivers will also be probably needed because I doubt the MCU can drive the mosfets without significant switching losses especially at higher frequencies (which as you mentioned an Attiny isn’t probably the best). In the end I don’t think we can really gain anything in space, cost, efficiency.
Here the buck converter I used is synchronous, all N-FETs with an integrated charge pump so it’s capable of 100% duty cycle, very high switching frequency of 2.4 MHz allowing to use a small inductor and low capacitance (I actually oversized both) while still having very low switching losses.
It might be a cool project but it’s likely a long road ahead to achieve that 95~97% efficiency without huge components.

You right. Best solution so far is to be implemented DAC and I2C support in Anduril. The freeman do you have idea if temperature sensor in 1616 is better from external one. Loneoceans use external one, I think in your driver it maybe will be better choise for large host in which PCB is large and MCU package will heat up I think very slow compared to external sensor. Also most of cases one of ground pins of external chip I think is used for thermal probe. i2c can be used for example for external DAC or ADC chips or another LED drivers. I can give you simple Idea for that. If main MCU support i2c it will be easy to be achieved PD charging with main controller. Most of USB-C enabled flashlights doesn’t support USB-C to C charging.

Meteor have high power asynchronous (Nfet + diode) driver. But didn’t saw synchronous boost (N+P mosfets) drivers on market or internet driven with MCU only. If you think to drive i2c port is more simple than direct fet go ahead. And again i hate expensive and rare dc converters. High frequency mean more distortion too.

Loneoceans used an external sensor on the driver PCB because the T1634 temp sensor is not factory calibrated and he prefers to make drivers that don’t require user calibration (rightly so IMO), the T1616 sensor is factory calibrated so on that particular point there is no need to use an external sensor. But yes that means that it can only measure the PCB temperature. There are lights that use a thermistor on the MCPCB but it’s seems to be quite rare ?

USB C to C doesn’t strictly require PD, it can work with 5.1K pull-down resistors on CC pins IIRC, I think nowadays most USC C lights support C to C charging this way and PD lights are rare.
By implementing PD with the MCU you means then to not use a PD controller ? But you would still need to use a charger IC. A few already have PD support and can be controlled via I2c or be used as standalone, which is what I’ve been looking at since I can implement it without any programming.

I removed from lume1 useless external sensor. Internal 1634 temp sensors works fine same like in attiny85. Led4power have nice MCPCB with termistor pad.

Would there be an advantage in using 3 terminal MLCCs? I think the frequency in these applications is probably too low to matter, but curious if it could make a difference in noise.

So… DAC control ended up being easier than I expected. No changes to the base Anduril(2) code needed. Even using the new Dynamic PWM logic to switch between VREFs to gain even more fine-tune control at lower ranges :sunglasses:

https://bazaar.launchpad.net/~gabe/flashlight-firmware/anduril2/view/head:/ToyKeeper/hwdef-thefreeman-lin16dac.h

Board design courtesy of thefreeman

Still need to do some config fine-tuning, but overall this works really well! Nice design, thefreeman!

I’m excited. I really need to get the equipment to flash these…

Pretty much any USB to Serial TTL adapter will work. Well, that plus my pogo-pin adapter I guess.

So integrated DAC port can be used for boost drivers right?

Yeah, I don’t think there’s any reason why it couldn’t be used. I’m not an electronics expert, though. But you can use it as input to one leg of the op-amp, assuming you’re using one to adjust the feedback voltage for the boost controller.

Glad that the driver works, and thank you so much for implementing DAC support.
:+1:

Sure, I haven’t received the boost driver boards but here is a buck driver :

Same size as last time (18mm clearance) and one sided thanks to the lower component count, though I’m getting more current than I should on the bottom of the high power range, still haven’t figured out why but is probably unrelated to the DAC control.

I bought a few CH340N USB boards to try that, very cheap, and also a few CH340N chips to use on your USB to pogo pin flasher.

I didn’t know about those, it seems that it reduces their ESL, but why would that reduce acoustic noise ? Or because they have solder points in the middle and would make the board vibrate less ?

This development is really fascinating to follow.

Mechanical dampening would be better I imagined. But I was thinking that the 90° offset of the conducting paths might have negative interference or something. I don’t know, truly… just thinking out loud

Yesterday I made a buck driver for the FWAA and installed it this morning :

I still haven’t received my gold plated brass buttons so it’s a 10mm2 (D~3.5mm) wire for now, not ideal due to the inevitable oxydation.

I sliced the 219Cs for better tint and throw.

The beam while still very floody is much more usable now, the tint is also much better, I used a lens from kaidomain instead of the original one which increased the duv quite a bit, their AR coated lenses are still purple reflecting, but don’t worsen the tint significantly, less than +0.0005 duv.

Compared with before :

Especially as soon as the FET turns on (lv4) the duv increases a lot, it’s actually very easy to see when ramping up from the 7135 to FET, I didn’t know 219Cs behaved like that, at higher duty cycle the duv comes down.

Thanks to Sunnysunsun for his FWAA’s measurements with which I could design the board before receiving the light.

Ideally I should have made some runtime measurements or at least sustained output to compare with the high efficiency buck driver, but… I was feeling lazy :weary: (and well, with the LEDs sliced it wouldn’t have worked), I should really do it at some point because while it seems it heats much less at given output, we can’t know for real without a proper comparison.

Ah I also designed a RGB aux board (hence the RGB pads) but still haven’t ordered it…

Very cool!

Since I recently got the Opple Light Master, I used it to look at my FWAA:
.

Yay!… I hope you (and or thefreeman) will
get an Opple
and post flicker results

Im wondering if the DAC approach will get rid of those pulses, shown on the bottom right side of the pic.

There is no PWM dimming in my drivers, only analog dimming, prior to the DAC control a filtered PWM signal was used to set the current, so there was in theory a small ripple at the output (not pulses!), in practice the loop isn’t very fast and the ripple was mostly smoothed out.
With the DAC the digital level is properly converted to a voltage and then to current, not ripple from there.

With a DC-DC converter there is always an output ripple though, since the TPS62867 switches at 2.4MHz there is a 2.4MHz ripple, of very low amplitude thanks to the output capacitors, 600kHz for the MP3431 (boost).

The switching frequency does decrease at low output, down to 30kHz for the MP3431 in ultrasonic mode, and ugh, around 60Hz at 5uA for the TPS62867 in my buck driver, but I have decided to not use the 1st level of the low power and high power range because the output can be unstable and flicker (for a different reason), so with a minimum of ~20uA, the min frequency is about150Hz, but contrary to the TPS61288 boost driver the output capacitors don’t discharge a lot even at this low frequency, and I don’t notice any flicker, that said I added a 70uA load to prevent the frequency from dropping below 500Hz to be safe.

About the Opple, I have an oscilloscope so I can just look at the output current waveform, that said I should buy a fast photodiode to directly measure from the light, that would be more practical in many cases.

Thanks, the DAC control is really great for making small drivers thanks to the lower component count.