[Oshpark] HQ 15mm/17mm programmable boost driver with ATtiny13A

A collection of 15mm and 17mm boost driver boards based on the PAM2803 boost circuit with a PWM controlled FET and an ATtiny13A microcontroller (MCU) for mode programming.


Update Nov 2018

The advent of the Convoy T2 revived my interest and I shared 2 new drivers, the HQB17C and the HQB17D, that are made specifically with the T2 in mind. Both are 17mm drivers.

There a some design changes.

Both drivers feature vias for a programming key, to allow true ISP.
I added a gate resistor (R4) between Pin6 and gate, can’t hurt to have one.
All 3 resistors went onto the spring side, that allowed to make the connection between PAM pin5 and LED+ without vias. That way the complete boost circuit is on one side of the board. The BAT+ pad is still 8mm, that’s ample space.

The C version is the ‘classic’ version, with SOT23 mosfet and up to 4.3mm inductor. There’s enough space for a SOIC clamp to program the Attiny.

The D version is the ‘deluxe’ version with all the bells and whistles: LFPAK33 mosfet and up to 5.6mm inductor. Together with the BAT60A this should make a very efficient driver. Here, a programming key is imperative.


Some time ago @wight spawned the idea of this kind of programmable boost drivers. This led to some development and I thought it might be helpful to consolidate my Oshpark boards and the information about them.


Boost Driver






HQB15 v1




first successful build

HQB15 v2




tweaked and shared

HQB15 v3




more layout improvements





ATtiny13a-MMU / NXP Mosfet


HQB17 v1




17mm version of HQB15 v2

HQB17B v1




straight swap of FT boost driver

HQB17B v2

proof of concept



voltage divider at pin7

HQB17C v1





HQB17D v1









Boost Controller PAM2803
MCU ATtiny13A
Diode (3A) BAT60A
Mosfet IRLML6244TRPbF
Mosfet NXP PSMN2R4-30MLD
Inductor Coilcraft XFL5030
Inductor Wurth 744316220 5040

Circuit Diagram

This is the basic schematic for the shared boards.
Version 17C and 17D have an additional gate resistor R4.


Partlist Overview

This partlist overview is based on the recommendations in the PAM2803 datasheet and the parts that are used in the FastTech driver.

Boost Controller
Diodes Incorporated PAM2803

Inductor (L), min. 2.2µH, 4.7µH recommended
DC resistance (Rdc) as low as possible, 2A current rating, size according to PCB used
All commercially available driver with PAM2803 seem to use 2.2µH

Schottky-Diode (D), min. 2A, Vf as low as possible
size according to PCB used

Input Capacitor (Cin)
min. 2.2µF, X5R or X7R recommended
I recommend 10µF

C2 / C3
Output Capacitor (Cout) and Decoupling Capacitor for MCU
I added C3 in parallel to allow easier adding of capacitance
Combined value: more than 10µF, 18µF seem to work, 22µF recommended,
(datasheet says: min. 6.8µF for the boost circuit, but even 10µF are not enough for working reliably with MCU)
X5R or X7R recommended
SMD0805 (C2) / SMD0603 (C3)

Current Sense Resistor (Rs / R)
~0.120 Ohm for 750mA (2cell)
The PAM2803 datasheet has a table for Rs/output ratio

Microcontroller Unit (MCU)
Package 8S1

SOT-23-3 or LFPAK33

Resistor between LED+ and GND, derived from FastTech driver
(and value might vary with production batch)
150 kOhm (“18D” / “154”)

Pulldown Resistor between gate and source
(value is definitely varying with production batch)
33 kOhm (“333”) / 10 kOhm (“103”)

R4 (only 17C and 17D)
Gate Resistor between Pin6 and gate
~33 Ohm

OTC (optional)
1µF, X5R or X7R


Board Design Goals in Eagle

- leave enough space for the Pomona programming clip

- place LED wire pads straight across each other

  • no components on spring side


Board Size
Oshpark boards are not covered with copper to the very edge of the board, the fab leaves a rim of 0.3mm bare PCB. That’s why all my boards have their radius increased by these 0.3mm. The boards are 15.6mm and 17.6mm in overall diameter, so the actual copper ground ring is 15.0mm and 17.0mm.
The boards have to be sanded down, but having copper right to the edge

- makes soldering GND to a pill much easier

- helps a press fit driver to make better contact and

  • helps with current and heat.


Assembling a driver
I recommend a reworking station, I use a - quite cheap - Youyue858D+. I consider hand soldering a real challenge on these boards.
This is mainly because the 0805 and 0603 parts are not standard eagle-size but custom made with a reduced footprint. When creating the brd-files I quickly realized that there is not enough space for standard parts.
And when harvesting the components from the FastTech driver a rework station is ideal anyway.

Always check for continuity, or to be precise: check there isn’t continuity where it’s not supposed to be. The parts are really packed together tighly, they only just avoid clearance errors in eagle. So there is a risk for shorts.


Low Voltage Protection (LVP)
Toykeeper hinted that Eneloops get damaged when drained completely, so an LVP might be useful. The boost circuit continues to suck energy from the cell even if the LED does not light up any more.
LVP comes in 2 flavours: warning and cutoff. Cutoff being the crucial part here. So far the ideas are

- cutting PWM to the Fet

- shutdown the PAM2803 (Pin4 SHDN) via the ATtiny

  • shutdown the PAM2803 with a voltage divider at Pin4
    With primaries (lithium, alkalines…) a cutoff is of course unneeded, as these cells are meant to be drained. So we need the sweet spot where the LED does not light up any more (when even primaries are not of use in the light) and the Eneloop is yet unharmed.

The boost circuit stops boosting at around 0.9V, the LED starts blinking at this point.
At first I thought this is a kind of warning but it seems it’s simply the controller stopping, the cell regaining some voltage, controller starts boosting again, the cell sags voltage under the load and the controller stops again.

The blinking (together with the obvious dimming of the LED long before this point) is why I think we don’t need an LVP warning. It’s obvious when the cell is low.

So a cutoff at some point below 0.9V would be good to save an Eneloop as long as possible.

But any cutoff would still not be complete, but eat some (reduced) energy: The ATtiny in sleep mode, the PAM2803 in ShutDown, even the voltage divider is an open circuit to the cell. We only buy some time to realize the light is off, but still powered. For now I’ve abandoned the idea.


Moon mode
This looks tough for now.
Even at PWM=1 I can’t get lower than this:
I tried 3 frequencies and it’s the same as with linear driver, the higher the frequency the lower the output on low levels.
4.7 kHz (fuse 65) : 25mA
18 kHz (fuse 75) : 15mA
37.5 kHz (fuse 7a) : 9mA
This is with fresh cells of course, and no difference between 1AA and 2AA.

The brightness is fading, naturally, as the cell(s) is(are) drained. Down to <1mA at the end. But this is not what I call Moon. It’s not even a low Low in my book.

37.5 kHz seems to be the highest the ATtiny13A can offer as frequency and I never used it in a driver before. At least whining should then be no more issue. Any other downsides with this high frequency? Other ideas for a lower Low? Suggestions welcome.

Edit: @fixed it made several suggestions in this post.

Off Time Capacitor
Only yet tested at my Nanjg110 conversion. Should work.
Some timing adaption will surely be necessary as the value of C2 (and C3) will interfere with OTC timing.

For now it’s quite low on my priority list.
For a 2 mode light it’s not needed (and the lack of Moon does not really suggest more modes on a 1xAA light… sheesh).
For a simple off-time-memory (2 timeframes: short/long) the brownout detection should be sufficient anyway, then no OTC is needed.


I started with an adapted Dr. Jones MiniDrv firmware.
Frequency changed to 18kHz, on-time-memory, 9 modes. This works fine.

The 9 modes were for testing the behaviour of the boost circuit at low PWM levels.
Simply adapt the modes line to something like {1,8,255} for a practical result.



I know some of you out there are hoping for nice firmware implementations, we will surely need help on that. For now I’m trying to lay grounds for the hardware stuff. A fancy UI is way out of my league.

But I already reserved this whole post for firmware and will gladly fill it up with all you can offer. :laughing:

Some History


This was my first successful test to combine a boost circuit with an ATtiny13A.
I hooked up a stock Nanjg110 to an ATtiny13A and a capacitor, both remainder of a Nanjg AK47. I added an OffTimeCap between Pin-2 and GND. And I used an IRLML0030TRPbF as FET. I placed the FET on the pads for a 7135, cut the traces and rewired (better: re-blobbed) for the PWM signal from Pin-6.


I flashed a it with an offtime firmware with 4 modes.
And there was light.

At 18kHz PWM values of 2 – 10 – 40 – 255 resulted in 12mA – 102mA – 198mA – 404mA with a single full and resting Eneloop.


With 2xAA the boost controller died (blew a tiny fan of smoke) at one of the first mode changes. It’s surely the controller that died, I swapped this single component from a new 110 and everything was working again (with 1AA).
That’s when I took a closer look at the Fasttech boost driver (who has a controller for modes) and the two resistors there seemed to serve as protection.


In the meantime I found a replacement diode for the large SS14/SS24. As I looked for 2A diodes I stumbled upon the BAT60A.
Even rated 3A, only 370mV forward voltage, and SOD-323 package. It’s the teeny-tiny component on the right, where the cathode line uses up almost half the component.
I hooked it up in replacement and drained 5× 1AA and 6× 2AA (Eneloops) on this driver, while monitoring input and output current. Works perfectly fine. Even increased output current in 1AA config and efficiency in 2AA config (needs a lower input current to reach the 920 mA).


Then I reworked the FastTech driver (comes in blue now instead of green).
MCU changed to Attiny13a (which was pre-programmed)
Some MCU-traces cut (Pins1/4/5)
Rewired: Pin6 to Fet-Gate (red wire)
MCU+ is already connected to V+out
Rewired: MCU- to GND
MCU- of the original driver is connected to Fet-Source/PAM3. This did not work with the Attiny, it wouldn’t change modes.
Rewired MCU- to GND (black wire) and voila: 3-mode boost driver that did survive several 1AA and 2AA drains.


The first Oshpark board HQB15 v1 successfully built.
2× 2AA and 3× 1AA (Eneloops) drained, about 200 mode changes, all good.
It’s a HQB15 de-luxe with Coilcraft inductor and high value capacitors.
Partlist with used values and the firmware in this post.



Driver height with this inductor is 3.7mm (0.2mm less than with the FT inductor). Now take the new Oshpark 0.8mm boards and you’re down to 2.9mm. That’s 3.0mm less than a Nanjg110.

Enough space around the Attiny13a for the clip after driver assembly.


I took the experience from building v1 (it’s really, really tight) and tweaked the design. I skipped sharing v1 and went straight to HQB15 v2.

All future Oshpark boards will be introduced in this thread.

This is really great thread. I feel that it wrong for me to make this post as this thread so well put together. But, on the other hand, I don’t feel it would be right to not express a big thank you. Thank you HQ for you continuous efforts to make programmable boost driver solution available to us all.

Thanks HarleyQuin. Amazing efforts.

I’m not a builder. Can someone build these for sale? Mtn electronics?

Thx. My pleasure.
Here is the next version of the 15mm boost driver


HQB15 v3

It’s still the basic circuit (including R2 and R3, no LVP)
I think this is as much as I could get out of this 15mm design, so for now there is no v4 planned.
It’s about time for building and testing.

Notable changes from v2 to v3:

- more GND vias

- GND plane slightly increased

- 3 plus vias moved outside the L1-pad

- some copper pads increased over stopmask

  • MCU moved slightly inwards

It’s still 15.6mm outer diameter, so the copper GND ring is 0.3mm smaller than it does look on these pictures.


Oshpark Link


When installing into a light it’s crucial that D1, R3 or the FET don’t get electrical contact with the flashlight body/pill. This might be tight and could risk shorting the light.
Same goes with the LED leads (LED+/LED-). Both must avoid GND.
Pin1 on the ATtiny (RST) has no pad on purpose. That way I could move the whole component slightly down to keep pin1 of the ATtiny (VCC!) away from the side.


Parts size
(more on parts and values see partlist overview in post#2)

Switch: PAM2803, SOT-23-6
L1: max 4.3x4.3mm
D1: BAT60A, SOD323
C1: 0805
C2: 0805
C3: 0603 (optional)
R1: 0805
R2: 0603
R3: 0603
MCU: ATTiny13A-SSU, 8S1
OTC: 0603 (optional)
FET: N-Channel, SOT-23-3


It’s a bit early for that, Gunga, since so far only one prototype has been made so no beta testing with several to see what problems arise and what needs fixing. If interest holds then it’s possible RMM or 3tronics will pick them up. Since you and I can’t fix very much we need these to be more thoroughly worked up before it’s worth it for those who can to try more than a few at a time.

^ This

I’m shelling out all I can to give others options to step in.
But I consider these far from ready.
I tried to point out the lines where we stand in the “4 OPs”

Atm I can spare more time at the PC than at the rework station, so there are more boards than testing on my side.
Toykeeper’s motto is: release early, release often. I’m working on it. - nod -

It is beautiful :slight_smile: Both the finished v1 board and the layout for v3. They make me wish I had the time and equipment to build one, even though I don’t understand half of what is going on in there and wouldn’t know what light to put it into :smiley:

Thank you for the in depth history, I for one find it both interesting and helpful in furthering my understanding. Why the change in capacitors from the FastTech board? I understand the reasoning on the inductor but is it just to get better quality caps or to be more certain if the values?

Oh sorry. Desperate for a good driver and jumping the gun. :slight_smile:

Thx. And we’ll find a light for you to put it in :wink:


I just wanted to play it safe.

  1. Wight himself wasn’t sure whether Cout (=C2) of the boost circuit is enough to act as decoupling for the ATtiny. That’s why I added C3 in 0603 footprint to at least give the option to add some capacitance.
  2. The FT driver has (iirc!) 10µF as C2. PAM2803 datasheet says for C2: 6.8µF min., 10-22µF recommended.

So for the first build - to rule out any errors from possible lack of capacitance - I populated C2 and C3 and pushed in the highest values I had for 0805 (22µF, measured ~20µF) and 0603 (4.7µF).
In the next build I wouldn’t mind to use 10µF for C2 and either leave C3 empty or take a 1µF or 2.2µF.

I already consider to remove C3 from the board to get some space if needed (LVP resistors perhaps), but I tend to implement LVP in 17mm boards first for further development and only when we have a solution there I will start to see what can be put into 15mm.


In OP I redubbed “released” to “shared”.
Just to avoid a misunderstanding that we have finished, tested, evaluated, ready-for-industrial-production boards.
We haven’t.
Just some boards I cobbled together for personal use and did not mind to share.

It is just proof of concept code but you could try this:

#define F_CPU 4800000UL 
#include <avr/io.h> 
#include <util/delay.h> 

#define FET_PIN PORTB1

int main(void)
while( 1==1 )
/* Empty the gate. */
DDRB |= (1 << FET_PIN);
_delay_ms( 1 );
DDRB &= ~(1 << FET_PIN);

    for( uint16_t i = 0; i &lt; 150; ++i ) 
        /* Charge a bit. */ 
        PORTB |= (1 &lt;&lt; FET_PIN); 
        PORTB &amp;= ~(1 &lt;&lt; FET_PIN); 
        _delay_ms( 200 ); 


It's a slow ramp on the FET gate charge which repeats forever. It goes from 'invisible' to 'a bit too bright to look at directly' on a BLF-A6 FET+1 driver. From the spec sheet, your small FET should charge much more quickly as the gate charge is about 1/8th. You can avoid the higher end by reducing the '150' loop counter. Slow down the ramp by increasing the '200' delay. If the steps are too large, a CPU frequency of 9.6 MHz instead of 4.8 MHz should help. And if it's still too bright, PWM could be done with some work. Oh and keep an eye on the FET if you run this, it could get fairly hot at moderate output.

How this would behave with a depleting cell depends on the output voltage of the boost circuit at near zero load (ie. I don't have a clue). On a li-ion setup I can compensate for the lower voltage with more charge. Could perhaps do something similar here if there was a voltage readout, which I understand would be tricky to fit in there. The other "fix" is to just have more modes.

Also, I've never tried this but the weird code could be probably replaced with regular PWM and a resistor of the right value between the PWM pin and the FET gate. I'm not sure about the component sizing (not my domain and seems very tight) but ideally, I think you could keep pin 6 as it is and connect pin 5 to the FET gate via through a resistor, or the other way around. That would make one PWM channel pulse the FET full on for the high modes and the other give the FET only partial charge for the low modes. It would be much easier to adapt current dual-PWM firmware that way. A simple matter of disabling output of the unused PWM pin for any given mode.

A completely different option would be to keep the "full on" short FET pulse but with lower frequency to reduce the PWM duty cycle. You can get N times lower output by decreasing PWM frequency by a factor of N. But it will become ugly at some point. It is also somewhat annoying to code, like what I posted above.

Anyway, this long rambling post is just to say there are options so don't worry too much about current lack of a very low mode. I hope I didn't write anything too crazy :)

Ordered some of each board. Hopefully, I will have the time to join in on the testing. Has anyone identified a low cost source for the inductors in the US?

I just ordered my allotment of boards from OshPark and forgot to order the 17mm set of these. :frowning: Will have to get a set on the next order, wanted to test in a P60! These look very interesting.

Good work!

There seem to be a lot of inductors on eBay but the nice short ones HQ used might be only mouser/Digikey.

I just don’t have the time right now to read all the separate threads on this topic. Mostly, I just want to know what range of smd footprints will work with these boards.

Regarding inductance rating. I see recommended above 4.7uH. In another thread there is a pic that says it has a 2.2yH, Coilcraft XFL4020 used. Was yH a typo? Sorry for the newbie questions but I haven’t spent any quality time with inductors and don’t have time right now to do so. I only understand what they do at a high level.

guys, thats me: :laughing:


@fixed it
That sounds promising.
I admit I understood only every second word of what you said, but i’ll dig into it.
I’m no firmware guy but I usually can adapt what others come up with.


Here in EU these Coilcraft inductors even increased in price about 70% in the last 12 months. They were expensive back then, they need to be weighed in gold by now.

Any other inductor with the µH-specs and size should do, I tried several (look at my 3rd pic in post#4).
The other (non-Coilcraft 2.2µH) inductors have mostly higher DC-resistance and thus are less efficient, like, losing some 5-10% output in 1AA and (some) runtime in 2AA.
All inductors I tested (same board, swapped inductors, same cell, measured output current; very humble and unprecise testing scenario) did work on the Nanjg110. Only difference I experienced was efficiency.

Datasheet does not say above 4.7µH, it says minimum 2.2µH, 4.7µH recommended. All commercial driver of this kind I recollect have 2.2µH inductors. I tried 4.7µH and the only difference was that they were less efficient at similar size (as they have by design a higher resistance than the 2.2µH). 4.7µH might/will have advantage in other terms (saturation?) but i wouldn’t know anything about it. I’ll stick with 2.2µH. You can take the inductor from the FT-driver for starters.

y makes for µ on a keyboard without a µ.


Allow for 12-15 hours and you get another 17mm driver board to choose from.