Not tested, and not readily available, but I got some boards on the way, already have the parts.
Sorry to ask, you’ve probably addressed these questions earlier in the thread.
I see that you are not using the same boost IC as the GBX17 design. May I ask why you chose this one?
What kind of max output are you aiming for?
I don’t see a digi-pot in schematics you have linked to earlier in the thread. How will you control modes/output?
If your design works, would you mind if I rip it off and make a ATtiny1634 based version of it? I don’t use any other MCU now days.
I chose a MP3431, because of 19A switch limit. I’m aiming for up to 3A with an XHP35, and a bit over 6.5A with an XHP50. Don’t know if it can do that, on paper it should. I’ll try my best.
No, there is no DigiPot, the control circuit of the H2-C driver is pretty good, so I’ll use that for my driver. In short, the pwm signal from the MCU gets smoothed, divided with a voltage divider, and then compared with the current sense voltage. An OpAmp will bias the feedback loop on the boost converter to get constant current.
If you can fit an ATTiny1634 on it, sure you can. I’ll try to make a little different version though, which doesn’t need an LDO to supply the MCU, but just the PWM signal. It may be tricky to use bistro-HD like it is now.
I can answer a few of these as I helped a little in the planning stages.
1 - Boost IC is the MPS MP3431, we chose this IC as it has twice the input current limit as TPS61088, and it has a higher maximum output voltage, which means we can easily drive 12V emitters like XHP35. TPS61088 is on the threshold of working with XHP35 and can’t do much current since its maximum output voltage is 12.5V
2 - Heat transfer from driver to host will be the real determining factor for maximum output, so will vary by application.
3 - The control is done by PWM through an RC filter into the op-amp. The circuit design was ripped off from H1-A and H2-C. This method is better IMO because it allows the use of already existing firmware which control PWM.
Thanks for the answers both of you.
I can of coarse understand that compatibility with existing firmware is of interest, for me it isn’t though. I am however interested in the actual boost part of your design as it would be community tested. Loneoceans appears to have left the forum and too my knowledge no one else has actually built one of his boards, so I’m some what reluctant to start working on that design if you guys are coming up with a working alternative.
Schoki: May I ask why you would need an LDO to supply the MCU in the first place? The single cell voltage should be able to power the MCU prior to boost?
The PWM “amplitude voltage” (don’t know how to call it, but it is 0V to the max. voltage) that comes out of the ATTiny varies with the battery voltage. If there’s just a small load (which is the case), the amplitude voltage is pretty much the same as the battery voltage.
Now take a 50% PWM signal from a fully charged cell: 2.1V
And from a pretty empty cell (3V): 1.5V
So the voltage average varies, and we don’t want that. The current output to the LED would decrease, when the cell gets discharged.
But I don’t know if I can remove the LDO on the input, there’s a lot of ripple voltage (we’re pulling up to 19A from a single cell, pulsed). Maybe the ATTiny doesn’t work if there’s too much of it.
The LDO also allows 2S input to power XHP35 or other 12+V emitters. 3S is also possible if the emitter voltage is 12.6 to 16V. If you use digipot method instead of the PWM method you could remove the LDO without any adverse effects using 1S voltage, just make sure to put a decoupling capacitor very close to the MCU pins.
Yeah, but I ordered the wrong LDOs, so for now it’s 1S only. I ordered the TPS706 instead of the TPS709. They are the same, just the maximum input voltage is different.
This was also pretty much exactly the control scheme we came up with for the Texas buck. If you're going to have analog output that gets compared to an external reference (it does), of course you're going to need an LDO. Well, I suppose you could compensate PWM value for the battery voltage in software, but, and I think Schoki pointed this out in other discussion, it's likely to not be very smooth or could even oscillate, and of course you need the software, a pretty large table to get good resolution, or likely some math libraries, either way it would probably need that better chip and more work. And how do you compensate 30% battery level changes at a PWM value of 2? Probably ok if the light gets dimmer with low bats in moon you might not mind, but it's a bit sad if a boost driver can't even do moon without voltage sag.
Hey Mike C, are there any major gotchas with moving software to that chip? I assume one should review all the matchups between I/O pins and clocks, ORCX etc ADCMUX etc, mostly just header define stuff aside from possibly clock modes and speeds, Obviously there are some new sleep modes available. It doesn't seem like porting software should be painful, no?
Are you using for those this Attiny package?
Yes, the 20M1 package, but I use the tiny25v, and they seem to be rev E and F (85°C and 125°C versions) at mouser
if this driver works well with 5-6A this would be definitely worth building
BTW, that is the parts cost?
The parts cost for this buck or boost driver is likely 10€
Makes more work to place the parts on it
The tiny pins of the parts require to get a stencil for the solder paste
This would bump the price quite high
There is high and there is high. If we want near-Zebra efficiency, double output and on top of it better firmware I don’t think it’s going to be a bad deal. 
I was using the 841 before but got tired of always having to optimize my code to fit into 8kb. I’ve also found the 1634’s power down modes better, for OTSM and E-switch only drivers. However, the 841 had en advantage that I miss, the PWM channels could be configured and assigned to any IO pin. The 1634 has the PWM pins fixed.
Ultimately I chose the 1634 because it’s currently the only 20 pin 4x4mm package with 16kb programming space that is easily available to me. I find 20 pins in 4x4mm to be as small as I want to go for hand mounted hot air soldering. I don’t want to go down to 3x3mm or 24 pin 4x4mm, the pins are tight enough as they are and I’ve had a few issues with shorts so I’m not all that interested in the 1616 or 1617.
I didn’t find porting the software painful, it was just something that had to be done. I’ve been using it for a few projects and am happy with it: Project Gemini: Yet another headlamp mod. Not a cheapo this time though. and Mike C drivers: v8 series, ATtiny1634 based.
The parts cost more than 10€. I sometimes bought more parts than I needed (for example 4 MP3431, or 4 of each tiny25v version with the right package, to hopefully get rev E parts), and it cost me around 58€ (for 3 to 4 drivers). If you just buy the necessary parts for the driver, and more sets, it will be cheaper. Idk, maybe 15€ less (so 43€ for 3 drivers, without boards).
And 3 boards cost 5$, I will make it a little bit smaller for less sanding.
If you only use those, the MCU has to come off the board if you later want to update the firmware. I still think it’s better with vias on the board for acupuncture style flashing, providing that you can fit the vias. As a driver and firmware developer I make sure to fit them myself:
