Well i'd be happy with plain old 22mm, OG design and wired e-switch. not to complicate much.
Although KR1 thought is mmm
Question about the positive contact. In this version the pad diameter is 10mm, based on the largest spring I had (from a D4v2.5 driver, very low resistance spring), but if I want to switch all the passives to 0603 (most are 0402) to make it easier for people to build, it would be beneficial to have a smaller pad, it would also help layouting a lot.
In the Fireflies E12R they use a (bypassed) spring with 7mm diameter, it’s quite tall.
Some components on the back, but especially a lot of vias and traces that couldn't be placed with a larger spring.
BlueSwordM has small springs with a base diameter of 5.75mm, but I haven’t seen any resistance measurements in his thread.
There is the option of a button contact, can be of a small diameter and has virtually zero resistance (not counting contact resistance)
For example in a Thrunite T1, it’s 5mm, they can cram a lot of components arround it. But button contacts can cause the cell to rattle inside the tube if there isn’t enough pressure from the back spring, or even break contact when shaking the light as often seen in Thrunites. Also I’m not sure where to buy them
Looking at the KR1/4, there isn’t much space available on the back for components and vias/traces, due to the 10mm spring and switch pad, despite the fact that the PCB is larger, so a smaller pad would help.
What do you think ?
I am a pretty novice modder, never gone beyond basic LED and driver swaps, so driver design is pretty much entirely over my head. Having said that I don’t like the button contacts, I prefer low resistance low profile spring like Emisar etc. The problem with the button is exactly what you said about Thrunite, battery fitment becomes a hassle.
I do not think going from a low resistance spring to a nigh-zero resistance button contact matters much. At that point we’re talking about such a small margin of improvement it isn’t relevant in my mind. I would prioritize reliability, ease of build etc. for the positive contact… just my opinion.
The BlueSwordM springs look like a good option to me, many modders on here have built some killer FET setups with them so they must compare to Emisar/Noctigon I would think.
Well done job thefreeman!
I missed that great thread and just now saw it. I had similar idea like you to try to develope some boost driver. If you want to share your shematic and whole design we can all of us with some sort of ЕЕ knowledge to discuss how to improve the design. I think that can become first trully open hardware contributed driver here in BLF from different peoples. I think your driver is based on lume1 driver just you used boost converter? I made for myself reverse engineering of lume1 circuit, I think you are done the same?
For PCB reflowing are you used stencil for solder paste?
Sorry icpart, I’m a bit busy with getting Anduril compiled and flashed on it for the basic functionalities, as I’ve never done that before, but I’ll get back for your questions.
Lume1 based on KR1 1 channel boost driver so better to use K1 config whats what i will do. BTW I added 1 more cap for signal filtering and ordeder PCBs at Oshpark.
Schematics of pop boost drivers
I don’t know about anyone else but personally I use stencils. For double sided drivers I used to only use them on the first side but now I’ve just receive some 3D printed “PCB rests” and they make it so much easier now, massive time saver:
I used stencils yes, I put others PCBs arround it so that everything is well level, a bit of double sided tape so that nothing moves. It works pretty well IMO.
Hello, time for an update.
I’ve encountered some issues but all are solved except for one, that is Anduril compatibility with the dual sense resistor design, the functionality needed here is to be able to turn on a mosfet for a portion of the ramp, for example if there is 10 levels on the low current range, the mosfet needs to turns on from 11 to 150 (total of 150 levels). Unfortunately I don’t think I’ll be able to do this on my own as I don’t have much experience/knowledge of programming.
This is the schematic for version 0.3, the boards that I have now :
The first problem is that I wired the PWM to a pin that uses time/counter D, but there is no support for it yet, solution is to wire it to a TCA pin (e.g. PB0), which I did for testing. TCD could be advantageous for lower power consumption as Gchart Showed here.
Right now it is set at 10bit with TCA and a 5MHz clock, resulting in a 5kHz frequency, which is high enough to be filtered it with R12-C13.
Second problem, that I already mentionned, the mosfet resistance for the current sense resistor selection is higher than expected, about 4.2mΩ instead of 2.2mΩ, simple solution, just decrease R8 (from 7 to 5), but if it varies between parts it’s going to be a bit annoying to test the current for each driver. Though this is only a concern for a high output current driver, as the total sense resistance needs to be low for a low Vsense/OPA_ref (43mV on the driver I built).
One improvement for the mosfet resistance would be to use a gate driver (with charge pump) such as mic 5019 so that the mosfet is driven with a higher Vgs, but that’s 3 additional components.
Third problem, the LED flickers at very low output, more like blinking even, this is at level 1/1023, with a 3.3Ω (R7) sense resistor, about 17uA :
(Green is current, 1003.3Ω current sense for the probe)
Yep, 23Hz switching frequency, a moonlight strobe basically 
, in retrospect I should have though about this. The reason is that as the current decreases, the switching mosfet inside the boost IC reaches its minimum pulse lenght, at this point if the current continues to decrease it will start to skip pulses, effectively reducing the switching frequency. (This is opposed to forced PWM where the frequency stays constant but in this mode the efficiency goes into the trash).
At level 26/1023 (~330uA) :
(103.3Ω current sense)
Strangely enough the flicker is not visible anymore even though the frequency is still pretty low, this is probably because it’s a ripple and not a full on/off like PWM.
So this made me curious about how Zebralight manages this on the H600mkII I disassembled the other day, the first thing I did was to check whether it uses pulse skipping or not, because on the TPS63020 there is the option for both, it does, then I checked the waveform on the lowest mode :
(100Ω current sense, ~100uA)
390Hz at 100uA, no visible flicker, it makes sense that the frequency is higher because the TPS63020 switches at 2.4mHz, vs 500kHz for the TPS61288, so it has a shorter minimum pulse lenght.
This could be the reason why they have higher moonlight on their more recent lights, if the IC they use have a longer min pulse lenght than the TPS63020.
H600 driver :
I have a solution though, it’s not very elegant but it’s simple, just add a resistor between OUT and GND so that there is always enough current to keep the switching frequency high enough.
Here with 5K :
156Hz, no visible flicker and a truly low moonlight where we can see the dies structure :
Not that it is necessary, but the goal I’ve put myself to reach was H600 mkII level moonlight, 100uA at 3V, so 50uA at 6V, mission accomplished 
The cost of this resistor is a current draw of 0.9~1.3mA, power of 4~8.5mW (depends on Vf), the resistor can be a little higher though, still without visible flickering, and it can be further increased if a higher moonlight is deemed sufficient.
Here is the schematic for the version 0.4 with the necessary changes :
I removed some passives, the gate resistor, as far as I know this is necessary to prevent ringing when switching, but here we’re not doing some high speed PWM on it, just on/off from time to time. I also tested with a puldown resistor, don’t see any change. ZL don’t use any gate or pulldown resistor on their current range selection mosfets.
I also removed removed R8 (v0.3 sch), it is often present on application notes about this type of op-amp circuit, as part of the compensation network (with C12) for loop stability. I don’t see any difference without it either.
By the way, it is fully stable (no flicker) with 10bit dimming and 43mV Vsense (42uV at 1/1023), but maybe it’s just this particular one and the next won’t be,but that wont be a problem with the dual sense design as we can develop a high dynamic range with just 8 bit, (9bit if we want 20uA with 5A max).
With this the hardware is fully functional, and the design can be used with any switching regulator/converters.
for the firmware it is functional right now without HDR, for the HDR functionality it’ll have to wait, I messaged Toykeeper the other day about this and she said that she has a non finalised branch that might have functionality for this.
I made the change to the board and ordered some, I’ll try to make another version with 0603 passive instead of 0402.
I haven’t found schematics for loneoceans drivers, only the older GXB17 but that’s a more complicated design.
I started by analysing the D4V2.5 linear driver (I posted the schematic on the attiny1 thread), read some app notes about this type of circuit and applied it to a switching converter instead of a mosfet, the opamp inputs just need to be swapped, since with feedback pin on a switching converter, if current goes up, we want FB to go up, instead of down for the gate of a N mosfet.
But it wasn’t stable though (in simulations), something that was super helpful was this schematic of the Convoy XHP35 driver posted by agnelucio, many thanks to him. In which I took the idea of using the feedback voltage divider (R16-R17), the opamp just nudges FB up or down a bit, instead of freely driving it (oscillations hell), which is much more stable, that said I have doubts about the actual stability of the Convoy driver without a compensation capacitor for the op-amp.
I did take a look at pictures posted on loneoceans’ github, it looks to be basically identical (ignoring the dual sense resistor part), also reference for some interesting parts (MIC5019 and TPS706).
I already discussed this with icpart on the lume thread, I don’t think adding another RC stage is useful. At 50% output, where ripple would be the highest (edit : that’s wrong it’s not at 50% that it is the highest 
)
I don’t see any 5kHz ripple.
R=10kΩ, C=470nF, rise time to 90% ~ 10ms
I see that you use a 10mm² MOSFET for reverse polarity protection…why does the driver need something this large?
I didn’t look much at what in available for smaller PFETs, which would be 2x2mm I suppose, but I doubt their resistance will be low enough.
Also there is enough space for a 3.3x3.3 sized one.
I just found space for 1 more additional cap for second level filtering, i’ll play and see what i get. Smaller then 3x3 Pfet will burn out. Now looked at your SiSS61DN and it looks like to burn as well. It have low safe operating area in DC mode…
I measured the voltage drop across the 2x2 PFET on the H600, 104mV at 3.4A = 31mΩ
Looking at Vishay’s offering, the DC current they can take is rather limited, arround 8A max.
Are we looking at the same DS ? The Rdson limited DC current goes up to 20A, the TPS61288 caps at 15A.
Great job thefreeman!
I´ve recently take a look to 2x2 FETs and even the better ones had too high resistance and too low ampacity.
If you want to save space, placing inductor over the rest of driver components, may be a better approach.
https://www.vishay.com/docs/75322/siss61dn.pdf page 4 last graphic . At 3-4v it can take only 800mA in DC mode?
Mounting coil on top of component is Chinese crap engineering ;))
The horizontal axis is Vds, drain source voltage, not Vgs (which is negative for a Pfet, in our case it varies from –4.2 to –2.8V), Vds is very low, Vds = Rdson x I
Thanks.
Coilcraft has a series with raised inductors but their thermals are not as good and in the end quite limited in current compared to the XAL7030 equilavalent. And if something taller is to be used, I think a XAL7070 better suited.
Quadrupel : at 15A Vds ≈ 0.075V.
Understanding MOSFET datasheets: Safe Operating Area (SOA) | Video | TI.com Watch from 13:15
Im using those
I’m used to seeing reverse polarity protection before the MCU only. I guess here it’s on the power path. Why does it have to be there as well?