Not only was this my first project to recharge its own batteries, it also had the special requirement that it had to handle the batteries safely with zero user intervention.
Lithium polymer batteries are pretty delicate. Unlike most non-rechargable batteries where you can just run them until they die, lithium polymer cells have minimum voltages under which they are not to be discharged. Overdischarging lithium cells can have a detrimental effect and severely shorten their lifespan. My batteries had the following specs:
So in addition to limiting my discharge current to 9mA, I also had to be very careful not to allow the battery's voltage to drop below 3V. This is not a trivial task. I've made a number of gadgets before that go to sleep to save battery, but even in a super low-current sleep state, a microcontroller will still slowly drip energy out of a battery plunging it further into the sub 3V range.
These sort of details are usually handled by a special battery protection IC which closely monitors the battery's voltage, current, and even temperature, and disconnects the battery from the circuit if these stray too far from nominal. Since I had such a well-controlled load, I only really had to worry about over and under voltage protection, and I could even pass off the over-voltage protection to my specially made charger.
A lot of online battery retailers give you the option of adding a battery protection PCB to your battery when you order, but I opted out because I wanted as many options as possible when it came to cramming this battery into a small case.
Shopping around for battery management ICs, I settled on the Seiko S-8241ABPMC-GBPT2G. Phew, that's quite a part number. The datasheet reveals a huge table of dozens of different ICs with just slightly varying values for under/over voltage or over current protection.
I found it really difficult to find a part that suited my needs as many of these units had over-discharge voltages reaching far below 3V. When I ordered my part, I thought it had an over-discharge voltage of 3V, but that was actually the "release voltage" meaning that after disconnecting the battery at 2.5V (the real over-discharge voltage), it waits until the battery's voltage rises to 3V before reconnecting it back to the circuit.
Thus prototype one:
Oh no, wait a second. That's the prototype that didn't work because I forgot to connect the hall effect sensor to the microcontroller (more on that later). Let's see if I can ...ah! here we go!
(this image was taken after some reworking and robbing of components for later prototypes)
It's at this point that I started a reddit thread on the topic and learned that battery protection ICs aren't really meant for what I was trying to do. They're meant to be used as a last-ditch safeguard to protect the battery (or user) from catastrophic damage. They aren't really intended to be invoked every time the device is used.
I've always had this irrational fear of working with lithium polymer batteries, but it quickly became apparent that I would need to dive in head first and create my own battery protection solution.
The off-the-shelf battery protection IC is meant to be used as follows:
The two FETs are responsible for keeping the battery connected to the circuit. During an over discharge situation DO falls and switches off FET1 disconnecting the battery from the rest of the circuit (EB+ and EB-). CO performs a similar task for over charging events.
So all I needed was an NFET connecting the circuit ground to the battery's negative terminal. This FET would then be controlled by my microcontroller which would detect when the battery's voltage drops below 3V and turn off the FET essentially committing suicide in the process.
After discovering that the battery protection IC wasn't cutting it, I was left with a PCB that already had an NFET in place (FET1 in the above diagram), so I started playing around with some careful rewiring.
My original strategy was to make a circuit like this:
The idea was that when normally operating, a GPIO pin would pull up on the gate of the NFET keeping it turned on. The FET would pull its drain down and keep the GND pin of the microcontroller close to the negative terminal of the battery.
When the gate was forced down by the GPIO pin, it was supposed to shut off the circuit. Afterwards, if the + and - pins were connected to an external power source, the microcontroller would come alive and be able to pull up on the gate again.
In practice, this circuit didn't work as planned. As the microcontroller started to drive the gate down, the transistor started to shut off and the drain voltage rose. With the drain voltage (and therefore the ground pin of the microcontroller) rising, there was no way for the micro controller to pull the gate down far enough to shut it off. The end result was a sort of equilibrium where the FET was half way off, and the ground pin of the microcontroller was hovering somewhere around 1V.
Still playing around with this circuit board, I tried this solution:
The idea here is that since the microcontroller has a direct connection to both the gate and source of Q2, it should be able to turn it off completely. Since Q2 is the only thing providing a voltage to the gate of Q1, shutting it off was supposed to shut Q1 off as well and kill the circuit.
This solution appeared to work. When the microcontroller sent the command to kill the circuit, the current draw of the circuit dropped to near zero. This was good, as the rework job was starting to get out of hand:
Tired of soldering, I decided to keep the design and start on a new rev of the board without giving it much more thought. I tested this new board a number of times and confirmed that when it decided to switch off the battery, current consumption dropped to zero:
My multimeter always shows around 0.1A when it isn't connected to anything (yes, I realize that the above picture looks like I'm shorting the probes together, but this wasn't the only test I ran). It wasn't until after I already had both earrings fully incased in their Sculpey cocoons that I started to see a problem.
The circuits weren't shutting off! Rather than switching straight to black, the red LEDs inside the earrings started to grow dimmer and dimmer, and I knew they were dropping below their 3V shutoff point.
Carefully cutting the circuits out of their cases, I set to work figuring out what was going on. After what must have been 5-6 hours (it was very difficult to work with batteries that had to be continuously charged and discharged), I discovered that I had a problem similar to what I had with my first solution.
Most of the time when the microcontroller sent the kill signal, things shut off as normal, but if the conditions were just right, it seemed that the circuit could fall into some sort of stable half-on state where it continued to draw current far below the 3V shutoff point.
I was going about it all wrong. I was bound to have problems in any situation where I was trying to drive the gates of FETs from a device that's powered by those FETs. Instead, I needed to make a solution where the FETs will naturally shut off when they are left alone. This is when I came up with this:
(The battery is in parallel with C2.)
The idea is that the line leading off the left side of the image runs to a GPIO pin which pulls down to keep the circuit alive and then just releases (becomes a high-Z input pin) when it's time to kill the circuit. R12 and R13 then take over and make sure that the FETs switch off. Because they're pulling straight off the battery's rails, they have none of the problems that my microcontroller solution had.
Of course, switching the code to go high-Z instead of pulling up required me to reconnect my programming header. That was a pain:
But the end result was good! It was so good in fact, I was genuinely curious why I didn't think of it earlier. Pull-up and pull-down resistors are very common solutions for issues like this. The really funny part is that by using a pull-down resistor on the gate, I could have totally stayed with the original single-FET solution and saved myself some board space. Certainly would have been easier to rework.
I was so perplexed by my decision to go down the dual-FET route that I performed a quick experiment on a breadboard halfway through writing this blog post just to make sure that there wasn't any inherent problem with that solution that I came across the first time and somehow forgot about.
Nope, it works great.
Next time I do this, I'll make sure to do it this way. UPDATE: No, it doesn't work great. Details here.