Hello all, thanks for the kind words everyone!
Regarding the firmware, I’ve got the external temperature sensor to work and it’s a fair bit more accurate out of the box. In fact, I believe I have tested all the features of Anduril as much as possible (though I probably missed out something!), and they all seem to be working.
Answering Tom E with some updates, yes it supports smooth ramping and looks visually identical to the stock driver (see the YouTube video of the preliminary test). I’ve completed the cfg and hwdef files for this driver. There are some very slight optional modifications I made to some fsm-__.c files which I will be documenting in detail, in order to support some extra features such as the external temperature sensor. I stuck with 150 ramp levels, but the control resolution is 10bit instead of 8bit (1023 vs 255 levels), similar to the Noctigon K1. So far, I have configured the ramp tables to have the ramp for the first 3 amps, then the FET kicks in for the double-tap-to-turbo. Keep in mind Anduril isn’t just limited to 255 levels; it’s not difficult to change it to support 1023 levels as long as the hardware is capable. However, increasing the PWM resolution will reduce the PWM frequency, which can cause a little more visible flicker, though at 3.9kHz, I doubt it’ll be a problem for almost all use cases. I’ll put the firmware up on the TK flashlight repo. Just making sure it’s mostly free of bugs right now.
Replying WTF, for driver sales, if there’s a good response, I am actually considering having a small run of assembled boards be made, but I need to make sure it’s got the bugs worked out first. In addition, all files will be published so anyone can make their own as well if they’re interested. I'd also like to hear the reasoning for having additional B+- and ESW pads on the board - what use case are you planning for these? Finally, yes it's very easy to have a version without the FET at all. This can be done simply by either having a run of boards without the FETs installed, and/or flashing the board removing the hwdef for the FET pin. Meanwhile, firmware work is well underway - I actually found a few more small issues and have fixed them!
Next, Schoki knows exactly what’s going on! You’re correct this was something I did miss initially when designing the boards, and didn’t catch it until PCBs were fabricated; this was because in practical use of most designs, the BuckBoost is only operating in buck mode for almost the entirety of the drive range, and when it hits Boost mode, no reverse conduction occurs for my setup. Here's why: LVP cuts out at 2.8V, limiting the lower end of the Vin. For FW3x systems with a 3 LED config at 3A, Vout doesn’t get much more than 3V. Then the key is the bias voltage of the body diode (IIRC around 0.35+V) - together with the low Vfwd of the LEDs used, reverse conduction does not occur.. but just by a whisker. However, you’re absolutely right that a higher Vfwd LED with low Vbatt can start running into reverse conduction of the body diode of the pass fet. This has been fixed in Rev B which is the planned driver for a small mass-order.
As a side note, I’d like to emphasis that having a FET to drive an LED is strictly not a great ‘text-book’ idea, likewise with paralleled LEDs! LEDs are inherently negative temp-co devices meaning that Vfwd of LEDs decreases as junction temperature increases, leading to the LED consuming more and more current until failure. In practice though, with matched LEDs and with system losses, this all works.. but just keep in mind that it isn’t strictly best practice to do so.
Thanks again for your continued interest and support!