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

I was looking at Pfets the other day. SiSS63DN looks good for 3.3x3.3 yea?

Im talking about power patch, for mcu… whatever.

See Loneoceans answer two posts after.

I see, thx Mike.

Loneoceans post explains it well, basically it does this :

Plus probably through the logic circuits as well.

Since we need to protect the power path we need a power mosfet. High side PFET is the easy way,here the SISS61DN has max DC current of 20A and max Rdson of ~5mΩ at the voltage we’re driving it, with 15A in still means a voltage across it (Vds) of 75mV and 1.125W of power lost.

We can also use a low side NFET which have better characteristics than PFETs, but this means that the circuit GND and batt- are different, the layout is bit less simple, it’s quite practical to have a GND/batt ring around the circuit, some drivers use a NFET, I saw pics of an Armytek driver and they used one.

Or we can use a high side NFET with an ideal diode controler (a gate driver with a charge pump) but that’s more components.

It looks slightly better indeed, good find.

Those are interesting links but they don’t contradict what I said.
You seem to be confused about what Vds means since you want it at 3~4V (battery voltage ?)
The drain source voltage is the voltage across the mosfet. It is that high when the mosfet is off (very high resistance) and the rest of the circuit is at 0V. But when we drive it below Vgs=–2.8V the resistance drops very low, below 5mΩ, it’s like a resistor and the voltage across this resistor is our Vds.
If we’re drawing 10A then Vds will be 0.005 x 10 = 50mV. This is simply ohm’s law and this is what the Rdson limit line is.
At some point though we hit the thermal stability limit for DC, which for SISS61DN is 20A, same for 63DN.

What is the rest of the diagram for then ? Linear mode, that is when when have a higher Vds due to a higher Rdson.
An example is a linear led driver, when we want to drive an LED at 5A with a 3.2Vf and a battery voltage of 4.2V, then Vds = 1v (4.2-3.2V) and Rdson = 0.2Ω. In that case it would not be in the SOA of the 61DN and it would blow.

Now imagine drawing 10A with a Vds of 4V, that’s 40W in the mosftet, of course it’s going to blow!

OK… whatever( i do not understand and i wont ;)), but my choice is Pfet with higher safe operating area in DC mode .

Fasltad’s mosfet models have high resistance by default, change beta to ~90 to simulate a ~5mΩ PFET : https://tinyurl.com/yhsmyjqr

Oh yesss!

I managed to make anduril works with HDR ^:) I used the LED2_ENABLE function, normally it just mirrors LED_ENABLE. To change that I copied the code for enabling the LED channel 1 only for a portion of the ramp in fsm-ramping.c. Now I can put in cfg :

LED_ENABLE_PIN_LEVEL_MIN 1 //boost enable
LED_ENABLE_PIN_LEVEL_MIN 150

LED2_ENABLE_PIN_LEVEL_MIN 18 //high range enable
LED2_ENABLE_PIN_LEVEL_MIN 150

The high range mosfet turns on level 18 (for example).

There is one issue, that I kind of knew would happen, it blinks at full power when the mosfet turns on. When we are on top of the low range, that is 1023/1023, the RC filter needs some time to settle to 1/1023( about 10ms to 90%, ~20ms to 99% with the current RC filter), so when the mosfet turns on the output is very high and falls to the expected power in ~20ms, hence the blink. Reducing the capacitor of the RC filter would help but it will only do so much since it can’t be too low for filtering the PWM signal.

For now I have added one buffer 1/1023 level before the mosfet turns on, obviously not ideal since if you stop ramping exactly on it you’ll find yourself in moonlight (0.01lm) instead of a low mode (~3lm). The actual solution would be to add a delay to the mosfet, something like 40ms should be plenty, not sure how to do that though.

But for now this a good enough solution.

I’m so happy to have it now fully working after so much time developing it :D

I received the 0.8mm PCBs, they look quite sturdy, I roughly cut a ring in a 1mm copper sheet :

With this the XAL7030 only stick out about ~1.9mm above the ring, probably low enough to fit in a D4v2, KR1, or other linear/fet lights with shallow driver cavity.

I ordered 0.8mm 2oz cooper option too. It will perfectly fit in to D10 headlamp ;))

If you decide to go with the DAC option instead of PWM and RC, I can help you out with 1616 DAC code. I won’t do Anduril conversion but once you know how the DAC code works I think you’ll not have much troubles.

Thanks but I don’t think I’ll be able to modify FSM for this, if Toykeeper decides to add support for the attiny1’s DAC at some point then I’m sure your code will help. The DAC looks like a good option to have so yeah support for it in FSM would be nice.

No worries. I’ll hand over DAC code to Toykeeper if she asks for it.

Hello all,

First, wanted to drop a note to Mike C for sending me an email to notify me about his (excellent) work on his driver, which also brought me to this thread. I've been caught up with some extremely busy commitments recently which explains why I've been away for a while, and I've had to take a step back from BLF/Flashlight projecting. I'm not quite sure how long this will take (maybe several more weeks or a few months?).

Meanwhile, I'm really glad to see so many great talent and development on some new drivers. Keep up the great work thefreeman, MikeC, gchart, and everyone else working on this.

I haven't had the time to go through all the threads so here's some of my comments in no particular order, and I apologize in advance if it has already been discussed somewhere else.

The 1616 is a nice IC, especially since it comes in a 3x3mm package allowing it to fit onto small form factor PCBs. For my Lume X1 driver, I actually made an updated version earlier in the year with the 1616 after suggestion from gchart and his work in porting Anduril over for the 1616. I like how it only needs 3 pads for UPDI as well.

I agree with MikeC about the internal DAC part and I'm happy to see that he used it, which was what I also switched to for my 1616 Lume X1 design.

When moving from the 1634 to the 1616 on my version two Lume X1, I swapped the brightness control from PWM to use the internal DAC as a reference voltage setpoint for the switching regulator. The problem with PWM control was transient response from the PWM's low pass filter, and I found that using the internal DAC (as a reference voltage) allowed for faster transient brightness performance for effects, and when switching between ranges. I also found (just a guess) that the Zebralight uses a similar approach as well, using the internal DAC and internal op-amp of their PIC MCU for their switching designs.

For my original Lume X1 based on the 1634, I had to do some trickery in the code to adjust for it to make a visually smooth ramp with PWM control. I maintained the ramp at 150 levels since each level is based on Andruil's internal 'tick' and I didn't want to change too much of the code to change this 'tick' interval. I wrote a simple script to generate a ramp table for visually smooth ramping and it worked out really well as you can see in my original Lume X1 video.

I tried different polynomials as well as exponentials but I found x^4 to work visually well.

For the 'Ultra-dynamic-range', it's exactly as thefreeman described, but instead of two, I used three different sense resistors each, each 2 orders of magnitude different. The key is to use a carefully chosen N-FET for the lowest sense resistor (highest current) since I take the R_ds_on of that Mosfet into consideration for the sensed current. Instead of focusing on the lowest R_ds_on, I picked one which is the most consistent at the driven gate voltage. I also played around with switching the reference voltages for the internal DAC to achieve more dynamic range too. Another note is that the DAC output is not quite rail-to-rail so you need to take into account for the lowest output voltage of internal DAC for the lower voltage ranges.

I removed the external temperature sensor since the 1616 seems to have a more accurate factory-calibrated internal sensor which the previous MCUs did not have to the same degree (though I can't find any manufacturer data of the exact accuracy tolerance). I'd also recommend ensuring the MCU has a good thermal path so the sensed temperature is accurate. Remember to disable the temperature re-write during Anduril's factory reset.

Due to the fact that the system now uses a higher current sense voltage, the other important aspect (especially since I'm hoping to design a driver that is economical to produce as well), is to use a less precise op-amp, saving a fair bit of BOM cost. I chose the much cheaper MCP6V66 with excellent results, but I suppose most other similar ones will work as well.

I got a few questions on compensation - compensation for the TPS61288 regulator itself should be fairly simple (the datasheet provides a good way to calculate it), but the op-amp compensation is a little more tricky if you're optimizing for lowest noise, EMI, and stability at all expected inputs and output loads. This compensation depends on the exact parameters of your circuit so it doesn't really make sense to port from design to design (and especially for op-amps - esp. the GBW and how it is set up internally since a lot of the precision op-amps are choppers) since it is also partially layout dependent; I'd encourage you all to play around with different values. I build dev boards for all my driver designs to help with this.

For the Lume X1, I chose a 'conservative' 40-ishW output since I wanted the driver to perform at its expected output across the entire battery range (as opposed to claiming that it was a 50-60W driver, but only with a fully charged cell at ideal conditions). I could increase this a little if I had full reign with the flashlight design as well to optimize for larger passive and magnetics, and flashlight power path.

Since then, I've managed to design one to fit an Amutorch E3 with 3S output configuration, and overall performance is really nice (main limitation being the inductor, and I've adjusted the output to be lower as a result to prevent inductor saturation)! thefreeman, your copper ring design looks great; it's a nice way to fit in a larger inductor (I had to use a flatter, lower power one for the E3).

Finally, I don't have any real thoughts between the MP and TPS part, both seem to be decent, but I do prefer the TI part for its lower Rdson FETs and because I've had a good amount of experience with other TI parts and they control system seems really well designed. The MP part has a 'higher' current limit, but the real-life power limit is determined by maximum junction temperature, which is based on other aspects of the system. Note that MPS just released the MP3432, though it's unclear to me at first glance what the key differences are between the previous versions; most likely some adjustments to the control logic.

Keep up the great work everyone and looking forward to seeing what you all come up with until I have more time to get back to the flashlight projects!

Hi Loneoceans, thanks for passing by and the kind words

Yeah the DAC is nice, especially since it removes the need for the LDO (and consequently the battlevel divider) and the PWM RC filter.
But since I have no programming skills I could only design a driver working with what is currently supported by FSM/Anduril (PWM). Actually I needed to add support for turning on the FET at a ramp level, I sort of miraculously managed to do that, I still need to add a delay on the FET enable due to the RC filter needing some time to fall when switching to the higher range. In the next version I reluctantly added a capacitor to delay the FET in hardware in case I don’t manage to do it in software.

For strobe modes, it seems that only the party strobe has issues (I haven’t tested the slowed version), but personally I couldn’t care less about those modes. That said I still don’t see any 5kHz ripple on the waveform so I might try lower capacitance for the filter to make it faster.

I’m also guessing that it is possible to have lower power consumption from the MCU with the DAC compared to PWM ?
The disadvantages that I see are the 8 bit limit (not really a problem with 3 sense resistors, I really prefer to only use two though) and that there is only one DAC, for a dual LED channel driver we would have to use PWM.

So it means you added DAC support in FSM ? Could you share your branch ?

I’m still working on the ramp so thanks for that.

In the version I built the FET is driven by the MCU at 2.8V and at that voltage the Rdson is a bit too high (~4.2mΩ) and probably not very consistent between parts. In the next version I’m driving it with the regulator’s internal LDO (4.8V), I wasn’t sure if it would negatively interfere with the regulator or not but after testing it doesn’t seem to be the case. With this the Rdson is about 1.1~1.2mΩ and I hope will be much more consistent between parts.

In Mike C’s thread we also discussed about using a mux to remove the FET resistance from Rsense.

It is indeed cheaper, about half the cost of TLV333 and still with pretty good specs, good find

For the regulator I took the values from Webench, for the op-amp I used 1nF (instead of 470pF in my schematic), I bought an oscilloscope recently and it looks stable at any output, I still need to learn how to record transient with it.

I’ll try with different values and see what happens, but yeah I knew I should have made a dev board, swapping tiny components and adding mores with tiny wires was a bit tedious to say the least.

Yes I prefer that approach too.

The advantage that I see with the MP is the ultrasonic mode, no risk of audible noise and it prevents switching frequency going so low as to make the LED flicker at very low output. I had to put a resistor across the output to have a minimum load for preventing that low frequency, did you use a similar solution ?

That’s great, E3 is easily moddable and has good thermal dissipation for its size. Will it work with B35AM in 3P configuration if someone makes a 20mm triple MCPCB for it? Its R9080 version should be as efficient as LH351D CRI90 at ~1000 lumens, but with much higher turbo power.

Why are Anduril lights with constant current drivers so hard to find? Cost?

A “slowed down” 5ms on time for party strobe will still reach the desired effect of freezing motion. I use the Anduril party strobe and 5ms strobe on a non-Anduril flashlight for light painting photography.

First of all I'll say that while Andúril may sound cool to some, the name of a phantasy sword is not exactly a common way to name flashlight firmwares. This is just the way I see it, of course. Then…

Average Joe or average chinese seller or manufacturer's answer: What is Andúril?

After checking it out: Whoa! That software is fairly sophisticated/complicated. We'll pass…

Andúril is meant for ATtiny MCU's and “FET” drivers. ATtiny MCU's are not really that common for the aforementioned fellows. Then, “FET” drivers are unregulated, their brightness is adjusted using a PWM signal from the MCU. Regulated drivers adjust brightness changing a MOSFET gate drive voltage (for variable load regulated linear drivers, like the SST40 types from Convoy), or by adjusting a buck/boost or boost-buck switching engine output voltage somehow… from a sense voltage signal (in both cases).

What does this mean? Software porting and conversions. This costs money, particularly if whoever does the software screws up (like someone from the driver manufacturing company to which Convoy entrusts and makes requests, long ago with the 12-groups Biscotti clone firmware and the SST40 drivers which couldn't save the software settings). This lack of care in the software meant lots of losses due to recalled products. When you write software for devices which can't be upgraded easily (and even in this case if you ask me), it pays off to do it carefully, taking whatever required time, and ensuring perfection.

So cost is one factor, but also interest (or lack of thereof).