Would a simple parallel R+C between the mcu pwm pin and gnd create a variable voltage controlled by duty cycle?
thefreeman’s HDR Anduril 2 high efficiency drivers - update : FWxA boost driver
Yup. That scheme has been employed by Emisar in the recent linear drivers as well as the FireFlies Lume1 drivers (LoneOceans design). But those feed the RC-filtered voltage into an op-amp instead of directly into the FET (or in the case of the Lume1, the buck regulator).
We need a right code to run mosfets in way we like. I ques its all about coding, to keep circuit simple, cheap and reliable as possible.
Have you calculated the capacitor requirements for higher output (>5 amps) with the low switching frequency from ATtiny’s? Of coarse you can use lower capacity on them but then you have a load of ripple, not a very good driver.
Seems like a bunch of work for a driver that will work worse so why bother? If you think it’s worth it, make it.
For 5A (30W!) output you will need big host with plenty space inside anyway. And its big question will you see PWM at hi output, because human eyes see no difference in bright light changes. I’d like to make it, but its all about code and i have no skills.
BTW some reading about TI buck -boost led dimming.
If you want to use SMD capacitors, then the cost of the boost ICs is replaced by large capacitors instead, only for a driver not working as good. I’m not saying it’s not an interesting idea, myself and others might at least be interested in discussing it but perhaps you should create your own thread and the discussion can continue there instead of posting this suggestion in all other driver threads.
And about about not having coding skills, I can assure you that no one here had any coding skills before they started learning how to code either.
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
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.
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 ?