Everyone loves, and should respect, lithium-ion batteries. They pack a ton of power and can make our projects work better. I’ve gathered a number of tips and tricks about using them over the years, based on my own hacking and also lessons I’ve learned from others.

This installment includes a grab-bag of LiIon tricks that will help you supercharge your battery use, avoid some mistakes, and make your circuits even safer. Plus, I have a wonderful project that I just have to share.

Hot-swapping Cells

When your device runs out of juice, you might not always want to chain yourself to a wall charger. Wouldn’t it be cool if you could just hot-swap cells? Indeed it is, I’ve been doing it for years, it’s dead simple to support, but you can also do it wrong. Let me show you how to do it right!

Recently, a new handheld has hit the hacker markets – the Hackberry Pi. With a Blackberry keyboard and a colour screen, it’s a pretty standard entry into the trend of handheld Pi Zero-backed computers with Blackberry keyboards. It’s not open-source and the author does not plan to open-source its hardware, so I want to make it absolutely clear I don’t consider it hacker-friendly or worth promoting. It did publish schematics, though, and these helped me find a dangerous mistake that the first revision made when trying to implement LiIon battery hot-swap.

It uses BL-5C cells, which are widely available as aftermarket batteries for Nokia phones. It’s a smart choice, though it’s worth remembering that vendors constantly inflate the capacity on the label, and my gut feel is that the more inflated the number is, the more shady the cell you’re getting. Remember, there’s a physical limit to the capacity you can shove into a certain cell volume, with 18650s limited to about 3500 mAh, as the market offerings show. (And if you try to put more capacity into a cell of certain volume, you get the Galaxy Note 7. Ahem.)

The batteries in the Hackberry Pi should be hot-swappable – no supercaps, they’re just in parallel with nothing in between the cells. Nothing in between? Question – what happens when you connect two batteries, one charged and one discharged, in parallel? Remember, LiIon batteries can give out a ton of current, and phone batteries doubly so due to the GSM modem peak current requirements. Decent voltage difference, very low resistance – you get a lot of current flowing, discharging the full cell needlessly or causing a brownout at best, and charring PCB tracks at worst.

The easy solution is to use PTC resettable fuses in series with the positive or negative terminal, either between each cell, or just one between two cells. If current surges sharply, the fuse will heat up and increase its resistance, limiting the current.

But remember, a fuse’s current rating is deceiving, and a 2 A fuse won’t actually trip at exactly 2.1 A. This is beneficial for you, though – while doing hotswap, one cell will have to produce twice the current than normally, even if for a short moment. Also, remember to size the cell protection fuse not just for device consumption, but also the charging current it will receive!

It’s certain that the new Hackberry Pi revision will fix this, and if you have the first revision, just swap batteries carefully and you will be 100% fine. Hotswap doesn’t have to be complicated – now you all know how to do a very simple form of it. Oh, and, having adding the fuse, you can easily get a good few extra features with only a few components, like, say, polarity protection!

The Polarity Hacks

With 18650 holders, it’s easy to insert a cell the wrong way by accident – I’ve burned out a good few boards like that, spending precious hours and dollars replacing burned out components. A 18650 cell holds a ton of energy and can burn out a lot of silicon very easily. Or if you’re using pouch cells using JST-PH connectors, you have to watch out for two polarity conventions. In short, polarity reversal is a real risk. How do you protect from it?

The reverse polarity crowbar circuit is a dead simple way to add polarity protection – all you need is a diode across the battery, placed after the fuse, flipped in a way that it will conduct when the polarity is wrong, tripping the fuse before any circuitry is damaged. The diode’s rating has to be higher than the fuse’s trip point – otherwise, the diode will burn out before the fuse trips, negating the circuit. I’ve tested this, it works, it’s now being manufactured in hundreds.

You might also want the user, whether you or someone else (especially someone else!) to quickly notice that the polarity is flipped. The solution is simple – add a LED and a resistor flipped in a way it lights up when the cell is reversed, before the fuse. Use a red or orange LED to make it crystal clear that something is wrong; don’t use green or blue, or any colours that often mean “the device is working normally”; add silkscreen markings to indicate that this is a “wrong polarity” LED.

Back to cells with JST-PH connectors. Are you developing a project that will get into hackers’ hands, and you don’t want to have them rewire their entire LiIon cell arsenal just for your device? Thankfully, 0 R resistors save the day; it’s dead simple to add two pairs of 0603 0R’s next to a JST-PH 2-pin connector. Make one polarity the default, and leave the option of switching the polarity in there. Again, this goes before the fuse, and before the reverse polarity LED, too. Of course, your users will have to make sure the red wire goes to positive, but at least you’re helping them get there.

This quickly, we have dealt with a number of polarity problems, using barely any components, all of them cheap, no fancy ICs. Your boards deserve to be fail-proof, serving you no matter the mistakes you make.

A New 18650 Holder Enters The Scene

Leaf contact holders are great. Unlike spring holders, they’re low-inductance, high-current, resillient to shocks, reliable, and cheap to find. Unfortunately, the leaf often catches on the cell’s heatshrink ends when you unplug the battery, slowly tearing it off piece by piece, and at some point even causing the positive terminal protective ring to detach – which risks a massive short-circuit as you unplug the battery or just drop the holder hard enough. Not great!

I’ve developed a pretty unique holder for 18650s, that I currently use for a pretty substantial portable device project of mine. It’s got all the advantages of spring holders, but it wraps around the battery fully, protecting it from shocks and the elements, and closes with a twist-on locking cap. Plus, it’s belt-mountable, thanks to a 3D-printed holder. It lends itself wonderfully to hotswap, too! Most of all, it’s fully 3D printable. All you need is some threaded inserts and some leaf contacts from Keystone that I found on Mouser – a baggie with 25 of them is quite cheap, and worth the money. (Remember to scroll through categories for things like battery contacts, you will find cool stuff!) There are definitely drawbacks to this type of holder, but it’s seriously great.

It’s parametric, designed in FreeCAD, so you can change a fair few parameters without breaking a sweat. The holder is designed for quick swap – just twist the cap and the battery falls out. Swapping 18650 cells is a cakewalk. High current consumption: tested; portability: tested; not damaging the cell wrappers: tested. I’ve been actively using these holders for about nine months now – they fulfilled their purpose and far more.

There’s something that makes it feel like military equipment, but I can assure you that it’s not designed by the lowest bidder. Put these on a belt, screw these into a project, or slap two of them together back to back – maybe even lengthen it and use three cells in series! Thanks to someone’s advice from Twitter, there are also vent holes at the positive terminal’s place.  (Of course, if your cell starts venting, you have a big problem on your hands no matter what you’re using.) Still, it’s got these holes, in addition to ten other features. And it’s printable vertically with no supports.

Are there possible failure modes? Absolutely. The main one is the cylinder breaking across the layer lines under pressure, especially if you drop it. I’ve tried printing the holder laying down, so that layer lines are aligned differently, but cleaning the tube from internal supports is damn brutal and the tolerances for the 18650 inside are pretty tight. I’m going to pick up a roll of PLA-Plus, since it supposedly is more strong, and print a new set of holders. If you print it, let us know!

Another failure mode is the spring’s compressing over time. I might be overcompressing the metal, so I just ought to check the datasheets and adjust the width. Of course, strong compression is a plus, but it’s of no use if the holder starts being super bump-sensitive after a few months of use. Last but not least, the positive wire is a failure point, though the channel i’ve recently introduced mostly fixes that.

More To Come

There are a few additions in the queue for the v3 holder. One is unifying the threaded inserts so that you don’t have to buy too many different ones, and improving mounting for the belt holster to limit the molten plastic backflow. Another is adding strips on the side that’d be a base for a long metal plate, which would acts as extra backing for the 18650 holder. The only problem is finding a suitable metal plate – flat, 70 mm long, about 4 mm wide, with screw holes alongside, or, at least, on both ends. Anyone have any ideas, especially if it’s something commonly found that can be repurposed?

I’m currently working on a custom PCB for this holder – involving protection, fuse holding, reverse polarity protection and warning LED, and maybe even an opamp circuit for roughly measuring the battery voltage. In short, including all of the tips shared here.

What are your favorite tricks for using lithium batteries?

Last time, I gave you an overview of what you get from I2C, basics like addressing, interface speeds, and a breakdown of pullups. Today, let’s continue looking into I2C capabilities and requirements – level shifting, transfer types, and quirks like combined transfers or clock stretching.

Level Shifting

Today, the overwhelming majority of I2C devices are 3.3 V logic. but this wasn’t always the case. If you work with old tech or with I2C on VGA/DVI/HDMI ports, you will see 5 V I2C networks, and if you work with very new tech, you will see 1.8 V I2C networks; rarely, you might even see 2.5 V networks!

Interfacing 5 V devices with a 3. 3V controller, it might not be necessary to level shift. You need to a) wire pullups to 3.3 V, and b) win the device input tolerance lottery. Same goes interfacing 3.3 V devices with 1.8 V hosts – wire up pullups to 1.8 V and pray to the stars. It can work in production – here’s Adafruit taking the 3.3 V-pulled-up Raspberry Pi I2C bus, and connecting it to a 5 V-powered MCP23017 chip that drives a 5 V-connected HD44780 display.

If your arrangement is different, or you’re experiencing a problem, you will want a level shifter circuit. At their simplest, two N-FETs like 2N7002 will do wonders. If you want smaller PCB footprint, better parameters, or more channels, there are level shifter chips, with many of them wonderfully suited for I2C (read the datasheet!). As we’ve featured before, some shifter ICs are too smart for their own good, while others will do just fine – if in doubt, remember to use your logic analyzer judiciously.

Two Ways To Talk

There are two kinds of I2C transfers you could expect to perform – I’d call them “simple transfers” and “register transfers”. With simple transfers, you send an address, and after the device ACKs, you either send or receive a single byte – it’s just like working with a shift register. With register transfers, you send an address, then a register number, and the device sends you the “contents” of that register – it’s more like working with an SPI display.

The PCF8574 is an I2C GPIO expander that does simple transfers. It has eight GPIO pins, and it only does simple transfers. How does that work, given it does both input and output? Well, the PCF8574 has only three possible states for all pin, with two of them combined together. The “Low” state (writing 0) is a hard pull down to GND. The “High” state (writing 1) is a weak pull to VCC – which also makes the pin work as an input with a pullup enabled. To check the input state, just read the expander state, and see if any of the pins you’ve set to 1 are now reading as 0. You can’t do a lot of high-side driving, sure, but you can still drive LEDs and check buttons, plus, this scheme is dead simple and covers a ton of use cases.

A good few I2C devices use simple transfers – the LM75 temperature sensor, for instance, only has to return temperature. You can read out multiple bytes at once, of course – simple transfers aren’t inherently limited to a single byte! PCF8575, the 16-bit sister of the PCF8574, has 16 GPIOs, I’ve used simple transfers with an ATMega328P keypard controller I created at some point – it would return keycodes, taken from a ring buffer. However, at some point, I decided to add more features to it, like ADC reading to help out a Pi Zero it was connected to, and had to upgrade it to register transfers.

The MCP23017 is a GPIO expander that uses register transfers. It has 16 GPIO pins, and a ton of features, each with their own register. Since one register contains 8 bits and we have 16 GPIOs, there are two registers per feature, and as such, there are two registers for pin directions, two for enabling integrated pullups, two for reading out input states, two for setting pins as outputs, and so on. They can even be arranged in two different ways, one backwards compatible with a different chip, by changing a bit in the status register! It’s a fair bit more complex chip than the PCF8574, but the complexity pays off where you need it.

I2C EEPROMs work with register transfers, too – some use 8-bit addresses, which allows for up to 256 bytes of storage. Higher-capacity EEPROMs use 16-bit (two-byte) addresses, where you’re expected to send in two bytes before you can read data out; if you try to read from such an EEPROM using two-byte addresses, you will just read back zeroes, so beware!

Quirks

But what if the device can’t keep up with the multi-byte transactions that your microcontroller is asking for? Maybe you have an EEPROM that needs time before it can read out a value from its internal memory so that it your MCU can receive it, maybe it’s a sensor that needs to average some values quickly and it just can’t catch up with even the lax timing requirements of 100 kHz I2C.

There’s a solution – it’s called clock stretching, and it’s basically an I2C device holding SCL low after receiving a byte, extending ACK state for a long time, until it can actually return meaningful data. As long as SCL is low, the controller should wait for the device. It’s essentially a way for a device to say “wait, not yet, I need some time before I can give you what you’re looking for”.

Raspberry Pi didn’t support clock stretching for the longest time due to a silicon bug. Every single Pi version before Pi 4 couldn’t handle clock stretching, including all of the Pi Zero versions released at the time of writing this article. The workaround, if you need one – use software I2C. It consumes more CPU since you have to use a kernel driver that bitbangs the bus, but it does have functional clock stretching. And of course the Raspberry Pi isn’t alone: if you are likely to need clock stretching, make sure that the microcontroller hardware peripheral supports it properly.

Next time, we dive into the physical layer, look at logic analyzer traces, understand how communication happens, and the ways it can break despite our best intentions.