Single-cell Li-Ion Powered UPS for Raspberry Pi

A simple yet complete UPS solution for most Raspberry Pi embedded applications, using a single-cell Li-Ion Battery.

Similar projects worth following
This UPS (uninterruptible power supply) is designed to provide at least 2.5A @ 5VDC to provide power to a Raspberry Pi (or other) single board computer. It keeps power available until the Pi issues a shutdown command or the battery is exhausted. It will also automatically restart when power becomes available again. These seem like simple things, but there are few commercial products available that have this performance and functionality.

There are 3 versions: One using a 14500 (AA size) Li-Ion battery and another using the 18650 size battery. The third version is a "Hat-like" unit for the 14500 battery that plugs into the 40-pin header and outboards the battery.

Please Don't Like or Follow This Project -- There is a newer/better version: The Ultimate Single Cell Lithium UPS for Raspberry PI (U1LiUPSRPi). Check it out.

I started out trying to modify the super capacitor UPS system, but it quickly became apparent that was not the right approach -- too many components and too many constraints that did not apply to the Li-Ion case. I enlisted PaulV as co-conspirator and together we were able to reduce the solution into a pretty small, but effective, package.

This is what the UPS must do:

  1. Provide power to the output ( the Pi power input) when external power is lost by drawing from the battery source.
  2. Let the Pi know that this has occurred, so that it can do a proper shutdown at an appropriate time before the battery is exhausted.
  3. Accept a shutdown command from the Pi and handshake to confirm the shutdown command was received, and after shutdown is complete, switch the Pi off by disconnecting the power.
  4. Reconnect the power to the Pi, which causes the Pi to boot, when the external power returns.

Functional Overview:

The basic organization of any UPS is shown in the following diagram.

The AC-DC converter can output almost any voltage, but it is usually a voltage larger than the required input voltage of the load (the Raspberry Pi). Many UPS systems use 12VDC or 24VDC and then use a step down, or buck converter, (or heaven forbid…linear regulator) to produce the required 5VDC output to the RPi. If the AC power fails, the Power Management block automatically switches over to the the stored energy source to keep providing power to the load. There are lots of variations on this theme, but the usual method is to have a switch mode converter that provides a constant 5VDC output and switch its input between the AC-DC converter output and the Energy Storage by using a simple diode selector. So what you have during normal operation is a cascade of switch mode converters, each with its attendant power loss and noise generation due to the switching action.

This UPS is a bit different than most others. Here’s the block diagram:

The AC-DC converter (the wall wart) outputs slightly more than 5VDC, say 5.15-5.25V, which is at the top end of the acceptable voltage range of the RPi. It is connected to the UPS output at all times — even when there is no AC power. The Energy Storage source is a single-cell Li-Ion battery with a typical voltage range of 3V to 4.2V and requires a boost converter to convert the battery voltage to the 5VDC required at the output. The boost converter is also connected to the output at all times but has its target output voltage set slightly below the wall wart output voltage. There is no diode selector because the boost converter manages the power switchover event at the UPS output. When the wall wart is providing power the UPS output voltage is held above the boost converter target voltage so the boost converter is inhibited from switching. When the AC power fails the wall wart simply changes state and becomes a relatively high impedance (something between 1megΩ and 500Ω, which is not much of a load). As the UPS output voltage falls below the boost converter target voltage it begins to switch and takes over providing power to the output. This switchover event needs to happen quickly in order to prevent any glitch from disrupting power to the load.

There are several advantages to this approach. It is inherently low power and low noise when operating on AC power (ignoring the required wall wart losses). The only power loss is some small overhead in the associated management system — about 500µA, or 2.5mW. The booster doesn’t make any noise if it’s not switching. It is low complexity, but the boost converter requires a bit of care to prevent any significant glitches at the output.

Index of Logs:

I have had a complaint that it is difficult to find information in the log files. Therefore I'm including a log index with a brief explanation of contents....

Read more »


Latest schematic of the HAT-Like version of the UPS -- with the LED charge indicator.

JPEG Image - 404.16 kB - 04/02/2018 at 18:46


This file contains all of the gerber files to make the UPS-14500-OS-HAT-LED PCB. You can upload this zipped file to OSH Park and order the PCBs from them. There is also a TopPaste.gbr file that you can upload separately to OSH Stencils to get a stencil for applying the solder paste (highly recommended because of the weird TPS61236p package).

Zip Archive - 53.52 kB - 04/02/2018 at 18:43



The Bill of Materials for the UPS-14500-IS-HAT-LED design. I have annotated it will some of the sources (mostly Digikey and eBay) that I use to obtain parts.

application/ - 13.50 kB - 09/10/2017 at 04:48



This is the PIC assembly code for the HAT version. The changes are to reverse the ACPR signal from negative edge to positive edge, and to lower the low battery threshold from 3.0V to 2.75V.

asm - 17.41 kB - 07/22/2017 at 19:45



The Bill of Materials for the UPS-18650-NS design. I have annotated it will some of the sources (mostly Digikey and eBay) that I use to obtain parts.

ms-excel - 12.00 kB - 07/02/2017 at 04:46


View all 12 files

  • Final Python Code...we're finished.

    Bud Bennett09/10/2017 at 19:43 0 comments

    This is (hopefully) the last log. The project is complete at this point.

    There are some bits of code that is necessary to get the UPS working properly. Paul Versteeg upgraded the code to include a logging capability and also provided a service file for systemd so it runs nicely in the background. 


    # Name:
    # Purpose:
    # Author:      Bud Bennett (modified by Paul Versteeg)
    # Created:     31-08-2017
    # Copyright:   (c) Bud Bennett 2017
    # Licence:     <your licence>
    This program monitors the status of the UPS via the i2c interface and
    manages the Raspberry Pi shutdown when the UPS signals that the battery
    is exhausted. It lets the UPS determine when the battery is exhausted.
    If the UPS battery voltage (VBAT) is greater than 3.2V, the status is checked
    every minute. If VBAT < 3.2V then the checking interval is shortened to 1 second.
    When the UPS asserts BATLOW = 1, the UPS will wait 5 seconds for the Raspberry Pi
    to acknowledge by setting the SHUTDN bit. If the Pi sets SHUTDN = 1 then the UPS immediately
    begins a 20 second timer to terminate the power. If the Pi has not set the SHUTDN bit
    within the 5 second period then the UPS begins the 20 second timer irregardless.
    So the Pi must initiate it's shutdown sequence immediately after receiving the BATLOW
    signal from the UPS and sending/confirming the SHUTDN acknowledgement. The Pi can also
    shutdown the UPS at any time by sending the Shutdown Command (0x04) to the UPS.
        from smbus import SMBus
    except ImportError as e:
        print("Python module smbus not found, install it first")
        # Install the i2c interface using the following instructions:
        # sudo apt-get install i2c-tools
        # sudo apt-get install python-smbus
        # sudo raspi-config , goto Interfacing Options, enable i2c
        # sudo reboot # to make the i2c interface active
        # now check to see if the USB i2c device is present at address 36
        # sudo i2cdetect -y 1
    import time, os
    from datetime import datetime
    import logging
    import logging.handlers
    import traceback
    import sys
    # Global flag to print more information
    DEBUG = True
    # If this script is installed as a Daemon by systemd, set this flag to True:
    DAEMON = True # do not send stuff to the console
    i2c = SMBus(1)  # set interface to i2c-1 (newer RPi's)
    ups_address = 0x36
    command = 0x00
    VBAT = 5
    bus_fail = 0
    pgood_flag = 1
    #--logger definitions
    # save daily logs for 7 days
    LOG_FILENAME = "path-to-ups_mon.log"  # log file path
    LOG_LEVEL = logging.INFO  # Could be e.g. "TRACE", "ERROR", "" or "WARNING"
    logger = logging.getLogger(__name__)
    handler = logging.handlers.TimedRotatingFileHandler(LOG_FILENAME, when="midnight", backupCount=7)
    formatter = logging.Formatter('%(asctime)s %(levelname)-8s %(message)s')
    def  write_log(mode, msg=""):
        Create a log file with information during the running of this app.
        Log information with a qualifier to easier sort it.
        if mode == "info" or mode == "message" or mode == "trace" :
        if mode == "debug" :
        if mode == "error" :
        if mode == "warning" :
        if mode == "critical" or mode == "exception" :
        # catch all
        if (DEBUG) and (not DAEMON) : print( "---catch all---"), mode
    def read_ups_data(address=0x36, cmd=0x00):
        bus_fail = 0
        if (DEBUG) and (not DAEMON) : print('Sending command {0:02x}'.format(command))
        # write_log("trace", "Sending command {0:02x}".format(command))
            word = i2c.read_word_data(ups_address, command)
        except Exception as e: # except all exceptions
            if (DEBUG) and (not DAEMON): print('I2C exception')
    Read more »

  • Testing the 14500 HAT-like UPS supply with high current demands

    Paul Versteeg09/10/2017 at 14:55 0 comments

    First of all, let me clarify that with normal 14500 cells in general, a heavily loaded (with attached USB devices) or tasked (running all cores to the max) Raspberry Pi Model 3 will not run for long on these cells, if at all. Regardless of the capacity (between 700 to 900 mAh) available for these cells, they cannot supply the required current levels.

    I measured that with these standard cells, the cell voltage will collapse within seconds with currents approaching 1.5A, which is no good for a Model 3.

    However, there are 14500 type high discharge capacity cells available. These so called IMR (Lithium manganese oxide, also called LMO) cells can supply currents in the 8A or more range, and I wanted to test if our HAT-like UPS equipped with these cells can actually support a loaded and tasked Model 3.

    In our efforts to see what is available for a Model 3 UPS support, Bud and I did not find many (if at all) that we thought could support current levels for the Model 3.

    Even with these high discharge IMR type cells, we’re still talking about a UPS function in the minutes only, certainly not hours.

    So for all practical matters, this UPS configuration is intended only to ride-out small Brown-Outs, swapping out wall-warts, moving the RPi to another wall socket, etc. and still provide a safe power down after a serious power deficiency has been detected. I will personally only use this UPS while I’m testing hardware and software on my Model 3, which is typically located on my desk. I use the same setup with my own UPS (Described here : for the other RPi models, and it saves me from doing something stupid and still preserve whatever script or settings I’m working on.

    The main power in my country and location (the Netherlands) is excellent with virtually no issues, so this UPS can also be used for more traditional applications like websites and servers, and still provide a clean and safe power down.

    The high power RPi Model 3 considerations and specifics

    The minimum requirement for the UPS to supply an RPI Model 3 running at full speed together with some peripherals connected to the USB ports was determined by me to be at least 2.5 Ampere. The minimum safe input voltage for the RPi family is published by the RP Foundation to be 4.75V.

    To supply a 2.5A payload with a minimum of 4.80V to the RPi, means that the booster will have to deal with cell voltages ranging from 4.2V, the top-off charge level, and the minimum safe discharge level of 3.0V. Realistically speaking, the cell will rapidly drop from 4.2V to 3.7V with a serious load attached. The most critical test however is at the lower cell voltages. At a cell voltage of 3.0V, the booster will require a whopping 5.2A from the cell to supply 4.8V at 2.5A to the Model 3!

    Normal 14500 cells, regardless of their capacity, cannot supply these high current levels. It should be clear to anybody looking for a UPS for a Model 3, that any design or commercial offering that does not include high current or IMR cells, simply cannot work. At the same time, a booster chip or circuit that cannot handle these currents is off limits as well, or will result in failure, at best and hopefully not cause a fire or something melting.

    This was the reason for the costly (in terms of ordering components to try, several manufactured PCB’s and shipping cost of components to me in Europe) and also time consuming journey Bud and I went on to try fulfill this requirement.

    At these high current levels, there are some serious challenges to overcome. The most important ones are dealing with high currents and the heat. Bud designed the UPS PCB’s specifically to channel the heat away from the booster chip, and made sure that there is enough PCB trace capacity to handle these currents and keep weird side-effects at bay.

    During my measurements, the surface temperature of the booster chip topped out at 60 degrees C, with a room temperature of...

    Read more »

  • More Booster design considerations - input/output capacitors

    Bud Bennett07/23/2017 at 18:08 2 comments

    A comment from PaulV got me thinking about the values that were used for the input and output capacitors on the boost converter. I was aware of bias voltage and temperature effects on ceramic capacitors. This article is a good introduction to the subject, but it is a just the start of your education.

    This is the schematic for a typical 5V/3A application as shown in the data sheet:

    But the capacitors shown in the schematic are not really the correct capacitor values needed for proper booster operation. This is what the data sheet has to say about the “effective” capacitor values:

    “The TPS6123x requires at least 20-μF effective capacitance at output for stability consideration. Care must be taken when evaluating a capacitor’s derating under bias. The bias can significantly reduce the effective capacitance. Ceramic capacitors can have losses of as much as 50% of their capacitance at rated voltage. Therefore, leave margin on the voltage rating to ensure adequate effective capacitance. In this example, three 22-μF capacitors of 10-V rating are used.”
    “The required minimum effective capacitance at input for the TPS6123x is 4.7-μF. Considering the capacitor’s derating under bias, a 10-μF input capacitor is recommended, and a 22-μF input capacitor should be sufficient for most applications. There is no limitation to use larger capacitors. It is recommended to put the input capacitor close to the VIN and PGND pins of the IC. If, for any reason, the input capacitor cannot be placed close to the IC, putting a small ceramic capacitor of 1-μF or 0.1-μF close to the IC's VIN pin and ground pin is recommended.”

    So why are my capacitors so big? I’m using a 47µF//1µF at the input and (3or4)x47µF//1µf at the output. Mostly it’s because I have a given inventory of capacitors and I don’t want to pay exorbitant prices for a few more. So I have to compensate for that.

    The data sheet recommends a specific capacitor C1 for the booster input: a Murata 10 μF 6.3 V, 0603, X5R ceramic (GRM188R60J106ME84). If you spend the time to locate the data sheet and look at the bias voltage variation you’ll eventually find this plot.

    Note that the capacitance is about 3.5µF with a DC voltage of 4.2V. It appears that TI is cutting it a bit close here. Maybe they are hoping that C4 can make up the difference, but C4 is only 0.3µF at 4.2V, so the grand total is about 3.8µF at the input. So much for a minimum requirement of 4.7µF.

    I rooted around Digikey to find out what the voltage variation for my choice of input capacitors might be. I’m using a 47µF (6.3V, X5R, 0805) in parallel with a 1µF (16V, X7R, 0805). The typical bias voltage variation for the 47µF X5R is shown in this graph.

    The capacitance falls off by 75% with 5V across it!!! But even so, the effective capacitance is still around 12µF. The 1µF doesn’t add much to this, but is there to improve ESR at high frequencies. It appears that my design meets the minimum effective capacitance requirement even after factoring in the 20% initial tolerance and temperature effects.

    OK. Let’s take a look at the output caps. TI is using 3x22uF (10V, X5R, 0805). Here’s the voltage bias curve of their suggested cap.

    At 5V, the capacitance drops from 22µF to around 10µF — a fall of more than 50%. Three of them in parallel yields 30µF, which is well above the minimum effective capacitance requirement of 20µF. 

    My effective output capacitance with 3x47µF (6.3V, X5R, 0805 -- same as the input cap) is about 36µF, so it is similar to what TI is using, and has room for tolerance and temperature variation. In addition, you must think about the derating the capacitor voltage rating at high temperatures. Since I don't expect to exceed 85°C I think that I can get away with using 6.3V rated capacitors at the booster output. If the board had to operate...

    Read more »

  • The Hat Version is Working

    Bud Bennett07/22/2017 at 19:34 0 comments

    The Hat PCB is functioning as designed. Here's a photo of it attached to my Raspberry Pi 2 B.

    I ran two discharge tests on this UPS version. The first was with the red Efest 700mAh battery: it lasted 1 hour 15 minutes. The UPS lasted 1 hour 51 minutes using the black KeepPower 800mAh battery. The load for both tests was an idling Raspberry Pi 2B.

    The SOT23-5 battery charger gets quite hot when charging the battery with full current, but it doesn't appear to cause any problems since the charger has a thermal limit.

    At this point I'm pretty much done with this project. I will let PaulV perform the 2-3A torture testing.

    Here's a photo showing all three PCBs for comparison purposes.

  • Going forward with the Hat version

    Bud Bennett07/08/2017 at 18:46 0 comments

    New Information:

    I'm editing this log to reflect some new testing information. I received 2 purple Efest 14500 Hi-discharge batteries yesterday (2017-07-10). When I put them to the same testing as the other batteries I noticed that something was wrong -- the battery holder started melting at the minus terminal. Apparently, the crimped connection at that terminal had become higher resistance and causing a lot of heat to build up at that junction. After I replaced the cheap Chinese battery holder with a similar cheap Chinese battery holder I repeated the testing on all of the batteries. The new results are contained in this log. I must note that the MPD battery holders are probably the ones to get -- the contacts are a single piece of flat metal that insert directly into the PCB holes -- no chance for high resistance connection unless the contact tension is weak. And I'll bet that the plastic will withstand higher temperatures. You get what you pay for.


    PaulV and I have hashed out an agreement on the "Hat-like" UPS. He wanted the UPS to provide at least 3A @ 5V. I did not see any reason to provide more than 2A @ 5V. He won the argument and we are proceeding with the Hat. I've updated the log that deals with the Hat, so see that log for reference.

    There are a few restrictions on the battery if you are going to provide that kind of current. I performed a series of experiments to see if any of my batteries would be able to provide more than 2.5A. Here's the results:

    • Experiment #1: Initial VBAT=4.0V, Final VBAT=2.75V. Battery: Efest 14500 700mAh V1 (red). Load = 2Ω (2.5A). UPS duration: 6 minutes 18 seconds. Note: My wall wart could only provide 4.75V to a 2Ω load, so I reduced the UPS target voltage to 4.67V for all subsequent testing.
    • Experiment #2: Same as Experiment #1, but the battery was a Keeppower 14500 800mAh (black). Duration: 0.1 second. (I think that the battery's protection kicked in and opened the circuit.)
    • Experiment #3: Same as Experiment #1, but the battery was an Effest 14500 650mAh (purple). Duration: 8 minutes 52 seconds.
    • Experiment #4: Initial VBAT=4.2V, Final VBAT=2.75V. Battery red Efest 14500. Duration: 8 minutes 49 seconds.
    • Experiment #5: Same as Experiment #4, but battery was purple Efest 14500. Duration: 10 minutes 46 seconds.

    When the booster is providing 3A @ 5V from the battery near exhaustion (2.75V) the current drawn from the battery will probably exceed 6A. Therefore you will need to get a battery that is rated above 6A continuous discharge current ( the "purple" Efest 14500 IMR battery is rated for 6.5A continuous, and 9.75A pulsed.)

    There are a couple of take-aways from this. The type of battery that you intend to use is a big factor in the UPS performance. If you need the UPS to provide high currents then it would be wise to obtain a battery that uses IMR chemistry and IS NOT PROTECTED. If your load is less than 1A @ 5V then almost any 14500 Li-Ion battery will do the job.

    The higher load current forced us to employ a poly fuse with higher current/voltage ratings, and a bigger footprint. The UPS Hat version PCB has been ordered from OSH Park and should be back from fab in a couple of weeks.

  • UPS disturbance of seismometer

    Bud Bennett07/01/2017 at 15:12 0 comments

    It doesn't appear that the seismometer is disturbed by the UPS. Today I disconnected the wall wart supplying power to the seismometer, waited about 5 minutes and then reconnected it. Here's the plot from the seismometer: seems like there is a problem, but apparently the problem is with me. The two major "bumps" in the data are caused by my proximity to the seismometer since I had to get down on my knees within 2 feet of the seismometer in order to unplug the wall wart. 100 counts on the seismometer ADC is equivalent to about 32 nano-meters of displacement to the concrete slab that it sits on. I repeated the experiment -- this time I only kneeled down next to the seismometer without disconnecting the wall wart. Here's what the seismometer reported:

    The first trace shows very little difference (that I can determine) in the section that was running off the UPS power. I'm satisfied. Now I must wait for a power outage to see how the UPS performs for a longer period.

    Just for grins and giggles, here's what a "real" earthquake looks like, from last week's magnitude 6.8 quake down in Guatemala:

  • UPS-18650-NS Installed on the seismometer

    Bud Bennett06/30/2017 at 22:52 0 comments

    The UPS-18650-NS is installed and working on my seismometer (I think.) The Raspberry Pi version that services the seismometer is a B+. The only way to know if it is working for sure is to disconnect power and wait 4-5 hours. Here's a photo of the installation:

    I tried to get the UPS as far away from the capacitance-to-digital sensor as possible. I will have to perform a series of tests to see if the UPS needs to be shielded, but right now the seismometer appears to be working normally.

    Here's the code that I'm using to monitor the UPS in the background:

    This program monitors the status of the UPS via the i2c interface and
    manages the Raspberry Pi shutdown when the UPS signals that the battery
    is exhausted. It lets the UPS determine when the battery is exhausted.
    If the UPS battery voltage (VBAT) is greater than 3.2V, the status is checked
    every minute. If VBAT < 3.2V then the checking interval is shortened to 1 second.
    When the UPS asserts BATLOW = 1, the UPS will wait 5 seconds for the Raspberry Pi
    to acknowledge by setting the SHUTDN bit. If the Pi sets SHUTDN = 1 then the UPS immediately
    begins a 20 second timer to terminate the power. If the Pi has not set the SHUTDN bit
    within the 5 second period then the UPS begins the 20 second timer irregardless.
    So the Pi must initiate it's shutdown sequence immediately after receiving the BATLOW
    signal from the UPS and sending/confirming the SHUTDN acknowledgement.
    from smbus import SMBus
    import time, os
    from datetime import datetime
    ups_address = 0x36
    i2c = SMBus(1)  # set interface to i2c-1
    command = 0x00
    VBAT = 5
    bus_active = 0
    def read_ups_data(address=0x36, cmd=0x00, debug=False):
            if debug: print('Sending command = {0:02x}'.format(command))
            word = i2c.read_word_data(ups_address, command)
            byte1 = 255 & word
            byte2 = word >> 8
            PWRGOOD = byte1 & 0x01
            BATLOW = (byte1 & 0x02) >> 1
            SHUTDN = (byte1 & 0x04) >> 2
            if byte2 != 0:
                VBAT = 2.048/byte2 * 255
                VBAT = 5.0
                if debug: print('ADC value error')
            bus_fail = 0
            bus_fail = 1
            VBAT = 5.0
            BATLOW = 0
            SHUTDN = 0
            PWRGOOD = 1
            if debug: print('I2C exception')
        if debug:
            print('PWRGOOD = {0}'.format(int(PWRGOOD)))
            print('BATLOW = {0}'.format(int(BATLOW)))
            print('SHUTDN = {0}'.format(int(SHUTDN)))
            print('VBAT = {0:.2f}\n'.format(VBAT))
        return PWRGOOD, BATLOW, SHUTDN, VBAT, bus_fail
    time_now =
    print("{0} Powerfail is active.".format(time_now))
    while True:
        # read the UPS
        PWRGOOD, BATLOW, SHUTDN, VBAT, bus_fail = read_ups_data(ups_address, cmd=command, debug=False)
        # if the UPS has set BATLOW, then send SHUTDN command to initiate UPS shutdown
        # (but the UPS will shutdown in 5 seconds on its own...)
        if (BATLOW and not bus_fail):
            print('Sending shutdown command.')
            command = 0x04
            PWRGOOD, BATLOW, SHUTDN, VBAT, bus_fail = read_ups_data(ups_address, cmd=command, debug=False)
        # confirm that UPS received the shutdown command and then shutdown the Pi
        if (SHUTDN and command == 0x04):
            print('Shutting down now!')
            os.system("sudo shutdown -h now")
            while True:
        # check UPS status at 1 minute intervals until battery voltage drops below 3.2V, then
        # decrease interval to 1 second.
        if (VBAT < 3.2):   
    I must get around to learning about logging someday...

  • UPS-18650-NS Working Prototype

    Bud Bennett06/26/2017 at 20:38 0 comments

    The UPS-18650-NS boards arrived from OSH Park on Saturday. By Sunday afternoon I had one of them populated and working. ( I ran out of 3.5mm terminal blocks so that will be the last board built until I get a fresh supply from China.) The polyimide stencil helped to get the solder paste aligned properly on the board, but it was a bit thick and I had to take a pin between the pads of the DFN and MSOP-10 footprints to prevent solder shorts. No shorts this time -- I'm amazed that the DFN package isn't prone to shorts given the pad spacings. If I get another stencil for these small pad footprints I will try the 3mil thickness...

    Measured 30µA from the battery terminals with no voltage applied to VOUT. That's a bit higher than the 14500 design but shouldn't matter much with this larger battery. With VOUT = 5.25V, I measured 125µA into BAT, which is pretty close to what I was shooting for. I unplugged the VOUT source and trimmed the open circuit voltage at VOUT to 5.00V.

    Next, I inserted a 18650 battery into the battery holder -- it seemed a bit loose so I had to bend the spring clips out a bit. When I plugged the wall wart into the microUSB jack and the plugged the wall wart into the wall socket the battery began to charge. So far so good.

    At this point I was confident that the boost converter was working properly so I connected the UPS to my Raspberry Pi 2B and waited until that battery was fully charged to 4V. Then unplugged the wall wart and timed the UPS until it gave up when the battery voltage dropped below 3.0V -- 4 hours 1 minute.

    I then disconnected the RPi, recharged the battery back to 4.0V, and attached a 2.5Ω load. This time the UPS lasted 36 minutes 5 seconds, from 4.0V to 3.0V. The output voltage dropped a bit, from 4.96V @ VBAT=4V to 4.94V @ VBAT=3V, but still very good line/load regulation. At the end of the test both the board and the battery were not very hot to the touch -- I estimate less than 15°C rise in temperature, which is fantastic. I measured the approximate time to recharge the battery from about 3.2V back to 4.0V -- about 5 hours, which is consistent with the 0.5A charge current and a 2500mAh Li-Ion battery.

    I don't expect to perform much additional testing. The design is very similar to the 14500 design, but with a larger battery. So this prototype will be installed into to my seismometer system in the near future. I need to clean up and finish the powerfail code before that happens.

  • The 14500 "Hat-like" Concept

    Bud Bennett06/13/2017 at 18:05 0 comments

    OK, I'll admit it right up front...I stole the idea to hang the battery upside-down off of the Raspberry Pi header from Patrick Van Oosterwijck's LiFePo4wered/Pi+ project on Hackaday. Everything else is an extension of this ongoing project.

    PaulV and I have been going back and forth about this Hat concept for quite a while. I'm not really enthusiastic because some of my headless Pi systems have very sensitive electronics hanging off the header, and so placing a 1MHz multi-Ampere switching regulator nearby is not high on my list. It would be OK if the system was not required to keep operating normally (like my heating system), but my seismometer must keep going as if nothing happened, so I'll be using the 18650 UPS for the seismometer and placing it reasonably far away from the sensing electronics and most probably shielding the UPS as well.

    It is called "Hat-like" because there is no EEPROM on board to make it a true "Hat".

    The physical nature of this UPS is its most important feature so I will start out with the 3D view.

    The header jack and battery holder are the only items placed on the bottom of the board. It is designed to work with the type of case shown below. It probably won't fit the Official Raspberry Pi case because there is a maximum distance of 4.5mm from the header to the battery holder, which is not enough clearance for the larger case style. I want to keep that spacing short to avoid putting too much stress on the header which will be the only thing supporting the UPS. Of course it would also work without a case, if the Pi was mounted to a surface with stand-offs. 

    The layout view should be considered next. Most of circuitry was directly ported from the UPS-14500-IS design. There are a few important considerations:

    1. The microUSB jack should probably be located to the left of the board so that the power cable doesn't interfere with the other ports of the Raspberry Pi.
    2. The push button reset switch had to be move to the top-side of the board for easy access.
    3. Because there are only two components on the bottom side of the board the goal was to make it no larger than required to support those components. As a result this PCB is a bit shorter, but wider, than the other 14500 UPS version. I believe that it is as small as possible.
    4. The two holes used for mounting the board through the battery holder are not required, and therefore deleted to make room for better bus width or component location.
    5. There is a cutout on the lower right to allow use with the planned case types.

    There were some tradeoffs that had to be made. Note the VIN trace that cuts diagonally from the upper left corner of the board. It must cross the top side GND plane, which had to be compensated with lots of via hole to the bottom side GND plane.

    The bottom side also has a wide trace cutting across the board to connect VOUT to the header +5V pins. This time the top side GND plane was used to jumper over that trace to keep the GND resistance low. The trace widths are probably much larger than needed, but it generally pays dividends to be conservative in that area. There aren't any critical components on the right quarter of the board so the GND plane in that area is almost a don't care. Note that the PCB could be smaller along the top edge, but that battery holder locator hole at the top right needs to be surrounded by the board.

    Schematic Changes:

    • The LTC4064 is gone. In its place is the MCP73831/2. This new charger part doesn't have a safety timer, and charges the battery to a 4.2 termination voltage, but it is one heck of a lot simpler to handle. One of it's package options is a SOT23-5 for about $0.60 each from Digikey.
    • The MCP73831 doesn't have a dedicated shutdown input, so another 2SK3018 NCH FET was added to open the programming resistor and set the charging current to zero, effectively implementing a charger shutdown.
    • Since the battery charger is no longer providing an AC present indicator signal the PIC will need to be reconfigured to do it...
    Read more »

  • UPS-18650-NS Boards

    Bud Bennett06/11/2017 at 20:11 0 comments

    Now that the 14500 version is working, I updated the 18650 design with the necessary changes and ordered boards from OSH Park. I named this version UPS-18650-NS for consistency with 14500 naming -- the NS stands for "No Switch". The schematic is only slightly different than the UPS-14500-IS: deleted the input switch, changed the charger to 500mA/6.5 hours. There are a couple more capacitors at the microUSB input and the booster input, but they may not be populated. C12, the tantalum capacitor at the microUSB jack, is there to prevent large transient voltages when a wall wart is hot plugged into the UPS (I never intend to do that.)

    The layout has gobs of empty space filled with metal buses. And the ground plane on the back side is more extensive. The metal helps to carry the heat away and keep the temperatures lower. The wide buses also keep power losses to a minimum. I'm really happy with this one.

    And the obligatory 3D view:

    I also ordered a solder paste stencil from OSH Stencils. This time the stencil is 5mil polyimide, instead of 4 mil steel, and I shrank the stencil openings on the MSOP-10 pads. Hopefully, it will prevent the solder shorts that have been a plague on that part.

View all 14 project logs

Enjoy this project?



Paul Versteeg wrote 07/09/2017 at 06:34 point

The reason I wanted to try and get 3Amps out of the UPS is that my intended target is an RPi Model 3. 

The power requirements for this model are such that most UPS systems cannot reliably satisfy the demands when you have an intensive use of the 4 cores, and some devices hanging off the USB ports.

Most of the "other" UPS systems we looked at that are available for the Model 3, even commercially, make claims that are hard to believe. The constraints on a battery cell supplying enough current to allow the dwindling cell voltage to be boosted to 5V at 3Amps are beyond most of these designs. Consider that the cell must be able to supply about double the current the RPi needs, so we're talking about a 6Amps + discharge rate. Most 14500 cells cannot do more than 2.5Amps

With those demands, the UPS design takes on another dimension, which is why Bud went through great pains, and many designs and board turns to get it right, we hope. 

With these kind of demands on the UPS, you can only expect to get several minutes of cell life and so you cannot really expect a real UPS behaviour. At a minimum, you get a safe power down in case of a mains malfunction. At best you can ride through a short brown out, or a wall wart switch over. This is fine for my application, where my Model 3 is sitting on my desk while I do developments and run tests on it.

The proof is in the pudding and so we're anxiously waiting for the 14500 "Hat" design to arrive.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates