Next Gen LiFePO4 battery / UPS / power manager for Raspberry Pi, ideal for headless and IoT use

Similar projects worth following
Many IoT and other projects are based on the Raspberry Pi, but usually little thought is given to the power supply. Most project use generic cell phone adapters or USB power banks, which is fine for one-off projects where the duct taped parts and cabling don't matter and it's expected that SD cards will die because power was removed with the Pi running.

But when you need reliable non-stop operation for your prototypes, or you're ready to turn your project into a good looking product, or you want to use different power sources such as solar, it's time to look for a serious power manager for your Pi.

Built on the solid foundation of the #LiFePO4wered/Pi, this project provides Pi bootup and shutdown management based on button or touch, input voltage, battery voltage and time, all while making sure the Pi always performs a clean shutdown before power is removed.
In addition it provides significantly higher power, RTC functionality and Pi current measurement.

It was a hard decision to start from scratch with a new project for this next gen effort since the #LiFePO4wered/Pi project has such good traction and a gazillion likes, but the more I thought about it, the more I realized that starting with a clean slate would allow me the freedom to make this what people want it to be instead of feeling shackled by legacy, and at the same time prevent confusion about the different generations. A new project also allows me to enter it for the 2017 Hackaday Prize. :)

There are some issues with the current #LiFePO4wered/Pi design that I hope to address in this Next Gen effort:

1. Make it easier to assemble. The two-PCB arrangement with the charger on the bottom and power manager on top makes for a nice and compact unit, but it takes too much time to assemble. The original design sprang from a desire to provide an example application for the #LiFePO4wered/USB, but the #LiFePO4wered/Pi has turned out to be a much more popular product in its own right. So this will be a single-board setup with the charger and power manager both on one PCB, significantly reducing assembly time and cost. It is the best way to reduce cost and support higher volume.

2. Alleviate power limitations due to physical size. Power supplies unfortunately generate quadratically more waste heat as the current goes up (P = I^2 * R), and the tiny PCBs in the current design have a hard time sinking this heat away. Customers always want more power, but recent experiments with higher power on the current physical design have convinced me that the only way to allow more power is a bigger PCB with more copper.

3. Improve hackability. For a product targeted at hardware hackers, the current design is not the most hacker friendly, mostly because there is very little room due to the small size. Customers want to connect different power sources, have the on/off button and LED remotely located, etc. The current design has some tiny surface mount pads to allow such things, but decent sized through-hole pads and more configuration and customization options would definitely be welcome.

4. Make load current independent of charge current. Some people don't need a big battery for long untethered run time, they just want a little bit of juice, enough to shut the system down safely when external power fails. But in the current design, maximum UPS load current is linked with charge current, which in turn dictates battery size. I hope to separate these two concerns and provide high load current with a small battery as well.

5. Improve physical stability. This isn't usually a problem, but the current mounting method with one screw and the weight of the battery supported on the 4-pin connector between the boards is not ideal. I plan to use a 40-pin header and connect to at least 2 screw holes.

So here is my current plan to make this happen:

  • Start with a Pi Zero-sized PCB, extended past the GPIO header so the battery can still sit next to the Pi, but upside-down. Have one PCB design that can accommodate both the 14500 and 18650 cells. The 18650 will be located more forward than in the current design, making sure it doesn't stick out farther than the USB ports on a Model B+ any more.
  • The circuitry will be over the Raspberry Pi as is the case for most HATs. The components will be mounted on the bottom of the PCB, with only the on/off button (mechanical switch) and LEDs mounted on top. Most of the top of the PCB will be copper plane for heat sinking, on which an additional heat sink can be mounted if deemed necessary for high power applications.
  • There will be through holes for remote on/off button and LEDs, to easily connect input power other than USB, give access to 3.2V battery power and switched 5V output power, connect external LiFePO4 cells and loads, and adjust the charger's MPP for use with solar panels.

Anything I've missed? Comments and requests are not only welcome but highly encouraged!


Buniness Plan/Pitch for Hackaday Prize Best Product

Adobe Portable Document Format - 308.92 kB - 07/21/2017 at 19:20


sheet - 10.73 kB - 07/18/2017 at 21:06



LiFePO4wered/Pi+ schematic as of 6/12/2017, CC-BY-SA licensed

Adobe Portable Document Format - 45.87 kB - 06/22/2017 at 19:38


  • 1 × CN3801 Power Management ICs / Switching Regulators and Controllers
  • 1 × TPS61236P Boost converter with bidirectional load switch
  • 1 × MSP430G2232 Microprocessors, Microcontrollers, DSPs / ARM, RISC-Based Microcontrollers
  • 1 × SSM3J332R Discrete Semiconductors / Diode-Transistor Modules
  • 1 × DMG2305UX Discrete Semiconductors / Power Transistors and MOSFETs

View all 10 components

  • Production boards!

    Patrick Van Oosterwijck02/17/2018 at 00:06 0 comments

    It's been a while since my last update, but a lot has happened!

    For a start I ordered production boards.  This time I decided to try another company than Elecrow.  My local CM had told me the boards could be better, especially the lead free HASL finish wasn't ideal in flatness to work well with tiny DFN packages.  I had received "spam" (unsolicited email) from several Chinese companies offering PCB services.  After getting quotes from several of them, I chose a Chinese company called XR-PCB because they seemed responsive and easy to work with, panelized my board for free and their quote was reasonable.  I went with matte black solder mask and immersion silver finish.  When I received the boards I was very happy: they are beautiful!

    The CM was also impressed with them: nice finish, good registration and alignment, nice flat finish.

    So I collected all my components and they started a build.  Meanwhile I also received a new shipment of batteries to be ready for production:

    On Tuesday the CM started production and I received a "first article" panel:

    Definitely an advantage of living in a city where the CM is literally down the street! :)  The first article boards tested out fine, no issues.  So I gave the green light to finish the rest.  Which I received today:

    It's happening people, almost there!

    In the meantime, I'm working on the product brief / manual, and need to update the web site.  I've also been hard at work creating a test fixture.  Using that I will be able to test these more thoroughly and faster than testing them by hand as I do with my current production boards.  Funny thing: the test fixture ended up being a more complex design than the product it will be testing:

    I'll be using a TI MSP430G2 Launchpad board as programmer, it will plug in on top of the main board.  There are two programmable loads to test the 5V and auxiliary outputs under various load conditions.  There is a "battery emulator", which is in fact a shunt regulator.  I'll be able to use it to test the behaviour of the DUT under various "battery levels".  Controlling it all is an STM32 which is configured the same as the Espruino Pico, so I will be able to use the marvellous Espruino firmware for quick development of the test functions.  Initially I had intended to drop an actual Espruino Pico module on the board, but I ended up needing more pins than those broken out to the castellated edges, so I opted to so a bare board design.  The remaining functions on the board are a beefy power supply and a USB hub to be able to run the Launchpad board and the Espruino from a single USB cable going to the test PC.

    So I'm now in a position to start selling these in limited quantities (manually tested for now, and lacking documentation).  I have decided to position them as a "professional" B2B product initially, and I'm holding off on making them generally available through a store front for now.  The LiFePO4wered/Pi and /Pi3 will continue to be sold on Tindie for the general public, as long as I have stock.  When stock runs out, the roles will reverse: the LiFePO4wered/Pi+ will become the publicly available product and the legacy products will only be available for volume buys.  This will hopefully give me enough time to get the test fixture and documentation finished before general availability.

    Professional customers who want early access and don't mind paying a little extra for manually tested boards can contact me directly and I will be able to get you early samples! :)

  • Power supplies, final PCB design

    Patrick Van Oosterwijck01/16/2018 at 01:01 1 comment

    Had a little bit of a scare this morning.  I arrived at my office and noticed that the LiFePO4wered/Pi+ I had intended to be running at 1.8A load over the weekend had turned off.  Off as in "the micro had determined the battery voltage was too low and switched to off state".  This was especially weird since the charge LED was on, and the input voltage was around 5.5V.  My first thought was of course "oh no, what has died?" :)

    I measured the voltage across the current sense resistors and it was zero V.  With 5.5V on the input and the charge LED on, it seemed "obvious" that something on the LiFePO4wered/Pi+ was faulty.  So I moved the setup over to my other workbench where most of my measurement tools live so I could scope what was going on, plugged it in to the power supply that was there and... the voltage across the current sense resistors was 120mV as it should be!  Everything was normal.

    Ok, move it back to the test bench, plug it in there... and 0V across the current sense resistors!  What the heck?  Was it the location?  Brought the supply from the other bench over... 120mV.  Seems something is wrong with the power supply on the test bench, but how can that be, since I measure 5.5V on the input?  Let's scope it:

    Ah I see.  The power supply did go bad.  Whenever the charger on the LiFePO4wered/Pi+ starts to draw power, the voltage collapses.  So the charger gives up, and the voltage returns.  Over and over, without actually providing any charge current.

    Now this was not my cheapest power supply from eBay or AliExpress.  I got this one as part of a Pi Zero kit at Microcenter.  It's rated 2A.

    Choosing the right power supply is going to be important for those who will want to push the LiFePO4wered/Pi+ to its limits.  Due to the nature of power conversion, the LiFePO4wered/Pi+'s efficiency is not 100% but around 75% instead at 2A load (much better at lower load).  The charge converter uses an asynchronous topology and has around 85% efficiency, the boost converter has around 90% efficiency in those conditions.  Combine them, and you're around 75%.  This means that to support a 2A load, the power supply will have to provide around 2.7A.

    My experience is that most 5V wall warts are not able to do that.  Even if they are rated at 2.5A, they start to sag seriously around 2A.  Since the LiFePO4wered/Pi+ has a smart charger that can be used with weak supplies and solar panels, it will automatically reduce charge current to ensure the input voltage will not sag below 4.65V (the default MPP set point).  So I'm sure I'm going to get complaints from people because they are using a lousy supply that sags but they will blame the LiFePO4wered/Pi+ for not working as a UPS at high load. :)

    That is a protection feature though to prevent the power supply from being overloaded.  Therefore it's odd that the one shown above died on me.

    On another note, I am now talking to PCB manufacturers to have production panels made.  I've finalized the design and decided to have the PCB manufacturer take care of doing the panellization this time.  Here's the final design they are working with:

    As you can see, I improved the silkscreen with some custom artwork, removed the unused HAT EEPROM and related components and put some more copper there instead for better heat dispersion.  The logo on the battery holder part is made by removing solder mask, so in the final product it will be silver in a black background, which will hopefully look cool when it sticks out of a case. :)

  • Thermal images

    Patrick Van Oosterwijck01/13/2018 at 00:21 1 comment

    I had expected my new FLIR ONE Pro to arrive next week, but I already received it yesterday.  Nice!

    So here are some thermal images of my test unit under different loads.  You may note that this is the LiFePO4wered/Pi+ version with the battery holder PCB area removed and an external battery connected by leads.  That's the worst case for thermal performance as the PCB is the smallest and provides less heat sinking.

    I had been running the test unit overnight with a load current of 1.5A powered by a 20V charger, so that's the first set of images I took:

    Running at a high input voltage, the charger's power MOSFET and Schottky diode are of course the hot spot.  But the hot spot is 20°C cooler at the same load current as my previous prototypes actually--a nice improvement!

    Let's crank the load current up to 2A:

    Getting pretty hot, but nothing is going on fire. :)  Just a little over the temperature reached by my previous prototypes when under only 1.5A load.  Remember, this is without any cooling or heat sink, and I will definitely recommend active cooling when using the device under high load with a high input voltage.

    I then switched back to testing with a regular 5V USB charger on the input.  I decided to do the 2A (worst case) test first:

    Nice, no extreme heat anywhere!  The hottest parts are the SSM3J338R pass transistor and the TPS61236P boost converter.  At the lower input voltage, the charger switching stage is not so hot anymore.  At this load, dumping 10W into the Pi, I'm pretty certain a well designed system is going to have a fan somewhere to cool things down.  But I'm happy to declare that the LiFePO4wered/Pi+ will work as a UPS with 2A load at room temperature without active cooling! :)

    But, it still looks pretty hot, doesn't it?  Yes, but most people will never have to worry about this kind of load.  A Pi 3 running at 100% CPU on all 4 cores only consumes about 800mA.  That's 4W, and I have now proven the LiFePO4wered/Pi+ will handle 10W without active cooling.  So I hope that will satisfy all the people wanting to power screens, hard drives, SSDs, SDRs etc. from my poor little UPS. :)

    To give you an idea of how the system performs when under a "light load" of 1A (= a Pi 3 running full boar):

    Hah! Hardly batting an eye.

    So I'm calling this PCB revision "approved", on to production!

  • Last prototypes!

    Patrick Van Oosterwijck01/11/2018 at 23:36 0 comments

    So I built my prototypes last week and I have been testing them since, I just hadn't found the time to write about it yet. ;)  Here are some shots of the build process, first pasted with components:

    And out of the reflow oven:

    This is how it looks all built up and with a 18650 battery and installed on a Pi:

    As you can see, there is accommodation for both 18650 and 14500 size batteries, and there are two positions for each size battery holder: one to be as compact as possible (battery close to the Pi) and one that provides a little distance to allow installation in standard cases while having the battery outside, as in this example with a 14500 cell in the official Pi case:

    The case only needed minor modification to fit.  Of course without making a hole, the USB connector and power button aren't accessible.  But it's easy enough to make a hole and if you don't want to, you can enable auto boot / auto shutdown and solder input power to the Vin pads.

    I started "easy" on the testing and everything was working great.  Even with a Pi 3 running with 4 cores at 100%, things hardly got warm.  Power down current, while keeping RTC, is still only around 4uA.

    Then I pulled out my electronic load and started testing at 2A load current.  The new switching MOSFET seemed to be handling it well, but oddly the pass transistor that previously wasn't giving me any trouble was getting really hot!  Then I looked at it a little closer:

    The device on the right was the one that was in the board and that I had sourced from China.  The one on the left was bought earlier from a US distributor.  The real part has a bigger body (probably to fit a bigger chip inside), and the leads come out flat on the bottom for less resistance and better heat transfer.  The fake part looks like a normal SOT23.  I really should have spotted that during assembly.  Turns out the fake part works as a "power MOSFET" as well, but it has an RdsON of about 130 mohm, while the genuine part has an RdsON of 20 mohm or less.  So it was burning way too much power at 2A load (2A load at 5V means over 4A from the battery do to the lower voltage and losses in conversion).

    So I replaced the fake parts with real ones and the overheating went away.  I have been doing high load testing since then and can confirm that the heat dissipation is low enough to allow UPS operation at 2A load current without active cooling!  But it's close, I can't get much higher before the boost converter kills the output because of thermal protection, and probably inside a case it will overheat sooner.

    But seriously, if you're building a system that is going to make a Pi burn 10W, you better have some fans for active cooling! :)

    I also tried what would happen at higher currents with active cooling:

    This ran for quite a while (several hours) at 2.5A load, eventually the boost converter did a thermal shutdown.  I haven't determined the limit since it doesn't matter: the spec is 2A.

    Also, remember my infamous project log where I burned up a transistor while testing at 20V input voltage?  Well, I've been testing this for over 8 hours now and it's working beautifully.  Yes, it gets hot, but no thermal shutdown, and nothing that some active cooling can't handle.

    If you're wondering why there aren't pretty thermal pictures in here, it's because I don't have convenient access right now.  Next week I should be getting my own thermal camera and then I'll be able to get some real data. :)  I'm pretty confident in the design though, so I'm ordering production panels.

  • PCB and firmware update

    Patrick Van Oosterwijck12/15/2017 at 19:21 0 comments

    I got my new proto PCBs from OSH Park, 0.8mm 2oz copper this time:

    It has the improvements described in the previous project log, you can see the new DFN power MOSFET footprint for instance.  I was getting ready to populate some prototypes by updating the BOM, until I noticed I had the wrong power MOSFET!

    That AON7408 I talked about last time?  Well turns out it's an N-channel MOSFET, and I need P-channel.  How I ever missed that while tearing apart the datasheet, I don't know.  So, I decided to use an Infineon BSZ120P03NS3 instead.  It's more expensive, but the safe operating area looks even better:

    Since I'm ordering production quantities to save time, I think this MOSFET should definitely have enough margin to work at high input voltages.

    On the firmware front, a LOT of work has been done.  I mean a TON.  Unfortunately most time has been spent chasing an elusive bug.  I think I finally got to the bottom of it.  Although it's more a patch than a root cause solution, it's as good as it will get, since the bug seems to be related to a hardware limitation.

    I really don't like the I2C peripheral in the small MSP430G micros I'm using.  Calling it a hardware I2C peripheral is an overstatement, it's more like a glorified shift register.  At every I2C related event, it requires software assistance.  8 bits are received: interrupt, set up for sending ACK.  1 bit sent: interrupt, set up for receiving 8.  Start condition, stop condition: all handled in software.  It stinks.

    So when I needed to add shadow buffering to ensure the 4-byte RTC would be written atomically, I seem to have upset a delicate timing balance.  Something in the timing was screwed up so sporadically the end of one packet and beginning of another would not be detected, causing the 8-bit I2C address with r/w bit and some other bytes (usually 0xFF because of reading) to be written over registers.  Registers such as the LED state (not good) or the I2C address (very bad) would be overwritten, with symptoms ranging from a flashing LED to killing communication.

    I tried for weeks, even months to track this down and fix it, but I think I just can't make it 100% reliable with this hardware.  With the shadow buffering added, there's just too much code running and based on when different other interrupts (timers, ADC) end up running, I can't guarantee the I2C baby sitting code will always run on time.  This is of course compounded by the fact that the Raspberry Pi has a retarded I2C peripheral as well that pays no attention whatsoever to I2C clock stretching, but just barges on even if the peripheral can't keep up.

    So I did the next best thing: I implemented a patch to prevent stray writes to I2C registers.  After the register to be written is received, the LiFePO4wered/Pi+ now expects an "unlock code" that is a combination of the I2C address, a magic value and the register to be written.  Once this is received correctly, the other bytes are written.  It just requires a small update to the host driver code.

    Other firmware updates: boot and shutdown timeouts, 32kHz crystal timers, RTC code, higher resolution oversampled ADC values, touch timing fixes, 10-second button hold to force off.  Many of these improvements will also carry over to the #LiFePO4wered/Pi as well, except those requiring a 32kHz crystal.

  • New prototype PCB layout

    Patrick Van Oosterwijck11/23/2017 at 18:59 0 comments

    Since blowing out parts on my existing prototypes has gotten them to the limit of their useful life, it was time to get some new prototypes. :)

    Time to make some changes related to things I've learned:

    • The locations of the mounting holes for the 14500 battery was wrong on the first prototype layout so I fixed that.  I also added extra holes to be able to mount the battery with a little gap so it's possible to mount the Pi in a case and have the battery outside.  This should work with the official case.
    •  Breaking the 18650 mounting PCB part off worked fine, breaking the complete battery holder part off was another story.  I did manage to break it off, but it put way too much strain on the PCB for my liking.

          So I now have added a gap that should make this process simpler.  Based on demand, I may also decide to have separate panels without the battery holder for those that want to use their own LiFePO4 battery.

    • I adjusted the layout around the 32kHz crystal so it now has a ground island and guard ring around the sensitive crystal signals.
    • I moved the programming pads a bit farther from the inductor for easier access.
    • I added some extra capacitors since ceramic capacitors have the habit of not having their full capacitance under bias voltage, and I want to make sure the supplies are clean.  Victim is the 4.25V output voltage option, which nobody seemed to be asking for anyway.  Yes, it would allow higher output current, but the output wattage would still be the same.  Since downstream there are usually switching power supplies, the lower voltage won't change the available power.
    • I changed the micro's supply ferrite beat and capacitor to a small resistor and bigger capacitor.  I had observed that under light load the battery voltage had some low frequency noise on it because the boost converter goes to PFM mode, and the periodic on/off puts little dips in the supply at around 30kHz.  The resistor / bigger capacitor combination will filter this better.
    • The fused battery voltage output was replaced by a battery output switched by load switch.  It provides protection and also turns the output on and off with the 5V output.  I just was not comfortable with the concept of having people connect stuff to the battery and be responsible for not over discharging the battery.  Now the LiFePO4wered/Pi+ circuitry can ensure the battery is not over discharged.
    • The charger switching MOSFET was upgraded to a higher power and current device since the current one blew out at high voltage and load current.  This required a new footprint.
    • I still have the HAT EEPROM circuitry on the board but don't intend to populate it.  The HAT standard is completely retarded in that it only allows ONE HAT, and only reads one HAT EEPROM address, even though it uses a bus.  This means that if people would use a LiFePO4wered/Pi+ they could not combine it with another HAT.  Since most of my customers order stackable headers, many must be using my current products with other HATs and it would be a disservice to populate the EEPROM on mine.  But since the LiFePO4wered/Pi+ is intended to be a base for other products that use the full HAT size and add custom circuitry, I'm reserving the space for the EEPROM so it is available for those spin-off products.

    I think that's about it for significant hardware changes.  Here's the new layout as sent to @oshpark :

  • Progress in learning and code

    Patrick Van Oosterwijck11/06/2017 at 18:29 1 comment

    I figured out some stuff since I burned up my power MOSFET last time.  Stuff like: "Read the datasheet more carefully dummy"! :)

    The SSM3J332R datasheet has the following graph in it:

    This makes it obvious that current capability of the MOSFET is seriously reduced at higher VDS.  The graph shows lines for pulse lengths but I'm not sure how repeated pulses play into this.  To be safe, I'm just scaling the DC line value by the duty cycle.  At 20V, that means the SSM3J332R is only rated for... about 260mA with 15% duty cycle.  No wonder it burned up!

    So, need to find a better MOSFET.  Unfortunately that means more expensive as well.  I stumbled across the AON7408, which is a significant step up and still low cost.  Unfortunately it's in a DFN package, and I prefer leaded packages.  But since my quest to replace the TPS61236P boost converter didn't turn up any good alternatives, I already am stuck with one DFN anyway so I might as well add another one.  On the upside, there seem to be many MOSFETs available in this package so if the AON7408 doesn't work out it should be easy to find an alternative in the same footprint.

    Here is the same safe operating area graph for the AON7408:

    In the same conditions at 20V with 15% duty cycle, the AON7408 should be able to deal with 4A.  A significant improvement, and the MOSFET fits in the same area as the original one.

    This also makes me wonder if some of the heat at 20V, 2A I saw in the previous project log near the Schottky diode was actually the MOSFET starting to burn up.  The resolving power of the thermal camera is just not good enough to tell where exactly the heat comes from if two components are close together.  Hopefully, the overall power dissipation and heat in the system will go down with this change, since the MOSFET has significantly lower RdsON as well.

    On the software side, I have finally implemented code for the 32 kHz crystal and RTC functions.  It's pretty cool to see the Pi wake up at an exact time. :)  I need to do some more testing, but I've started work on the next PCB revision and have started some volume component orders.  Exciting! :)

  • 2A load current! *

    Patrick Van Oosterwijck10/21/2017 at 04:16 2 comments

    Success!  I finally managed to get the LiFePO4wered/Pi+ to 2A continuous load current in UPS mode! :)  Without active cooling, and with the charger keeping up and keeping the battery charged.  So what changed?

    As I have previously explained, it all comes down to limiting the heat production on the board.  One commenter suggested I switch the 60V 5A SS56 Schottky diode for a lower voltage model, such as a 40V 5V SS54.  The reason is that the diode drop in the forward direction is lower for a diode with lower reverse breakdown voltage.  With a lower forward voltage, it will dissipate less heat.  I tried that, but unfortunately it didn't seem to make much of a difference.

    So I decided to look over some of my old thermal camera shots again to see what was producing the heat.

    In this one I was measuring the diode temperature, but as you can tell, there's another hot spot, between the 2 and 0 of the "> 120°C" text.  It even seems a little brighter than the diode spot, actually.  This is transistor Q4 in the schematic, it's present (in combination with Q2 and Q3) to disconnect the charging circuit from the battery when the battery isn't charged, to minimize current leakage.  Of course, while charging, it has the full charge current flowing through it.  Assuming conversion from ~3V to 5V at about 90% efficiency, this transistor has a continuous current of about 3.7A flowing through it when the load draws 2A.  Unfortunately the Vgs voltage is only 3V or so, so the transistor isn't turned on as hard as would be ideal, and likely has a RdsON of around 100mΩ.  This results in burning 1.37W of power in this little SOT23 transistor and it gets HOT.  Too hot probably, the DMG2305UX spec mentions 1.4W max mounted on 1 inch square 2 oz copper, which I'm not meeting in that location, especially since the diode is also heating the board.

    So I decided to try a different transistor, a Toshiba SSM3J338R (with the original SS56 diode).  It is specified to have 20mΩ typical RdsON at 2.5V Vgs, so it should be a good improvement and it has a SOT23 package as well.  It should only dissipate 0.27W at the same current, resulting in 5 times less heat.

    And it works!  Here's a thermal shot:

    And having it loaded with 2A, coming up from discharged battery, the system manages to supply the load with 2A and charge the battery, as it required for UPS functionality.  Success!

    But you must have noticed the little star, asterisk "*" in the heading.  You know what that means. :)  Fine print, exceptions, disclaimers, etc.  Well there are some here as well.

    In this case, it's about the input voltage to the system.  These tests were all done with 5V USB input, but I've designed the board to accept input voltages up to 24V.  So I decided to test what would happen at 2A with 20V input voltage.  The result isn't good:

    Yikes, frying the diode again!  This makes sense unfortunately.  At high input voltages, the PWM duty cycle is very low, which means that current is most of the time flowing through the freewheel diode.  At 5V input, the diode only conducts around 40%  of the time, but at 20V input it's about 85% of the time.

    Every power system is subject to trade-offs like this.  I'm all right with lower current capability when powered by higher input voltages--it's a trade-off the customer will have to make in their system design.  As long as it can do 2A with 5V input I'm happy.

    So how low do we need to go to have it work as a UPS and not overheat?  i tried 1.5A load:

    Better, "only" 110°C, but still too hot, since the battery discharges while plugged in.

    Ok, try 1A then:

    That's better, only 82°C and the system stays cool enough to allow the battery to charge!  It's not 2A, but it still can act as a UPS for a Pi3 at 100% CPU.

    Then I wondered: since at the higher input voltage the diode becomes the...

    Read more »

  • ETA1096 evaluation

    Patrick Van Oosterwijck10/18/2017 at 17:31 0 comments

    In my quest to reduce the cost and manufacturability of the LiFePO4wered/Pi+, my attention was drawn to the ETA1096, a Chinese boost converter.  It is significantly lower cost than the TPS61236P, and it comes in a nice leaded package, so I thought I'd evaluate it to see if I could use it on the LiFePO4wered/Pi+.

    I found out about this part while investigating some of my competitors.  I found the Geekworm UPS HAT and although the creator tries very hard to hide which parts are used by scraping the surface markings off, some smart people on the internet figured it out anyway.  Since the UPS lists 2A output current and the chip's specification lists up to 3A, it looked promising.

    What was harder was to get a hold of samples to evaluate.  The Chinese distributor refused to ship samples in the mail, and I wasn't going to spend $100+ to have a couple cheap chips shipped by Fedex.  In the end I decided that the cheapest way to get a sample part was to buy the Geekworm UPS HAT. :)

    Now it might be considered a stupid idea for my business to talk about a competitor here, but honestly the Geekworm UPS HAT is a pretty lousy device compared to the LiFePO4wered/Pi and Pi+.  Of course I'm biased, but check out this attempt by an enterprising individual to make it usable and you'll know what I mean.  Calling it a UPS is a bit of a stretch in my opinion, the out-of-the-box functionality is really limited.  It's something you can make usable if you want a project, but if you just want something that works so you can get on with the project you're already doing, you might want to get a LiFePO4wered/Pi instead. ;)

    I decided to hack in my own battery and charger (a #LiFePO4wered/18650 base) so I could focus on the ETA1096 performance without worrying about the rest of the system.

    [Just one quick note on the "rest of the system".  The charger chip (likely an ETA9741) is an odd part that actually puts 5V back on the input USB port even if the ETA1096 is off, and seems to draw 40-200uA from the battery.]

    I used my electronic load and started with a load current of 1A.  The ETA1096 seemed to be doing fine, the voltage didn't sag and the chip didn't seem to get warm.  I bumped the current to 2A and the whole thing shut off.  OK... start over and take smaller steps I guess?

    So I went to 1.1A, 1.2A, 1.3A, 1.4A, 1.5A, 1.6A and it shut off again.  Start over and let's keep it at 1.5A.  After a minute I decided to touch the chip to check how hot it was and I yelped--blazing hot!  I don't have access to the thermal camera at the moment so I used my IR thermometer and it reported 107°C!  And it's always been conservative compared to the FLIR One since it averages a larger area.

    Well, that's... unexpected.  I knew it would get warmer than the TPS61236P since it has 40/55 mΩ MOSFETs instead of the TPS61236P's 14/14 mΩ.  But that still only translates into 0.3W instead of 0.1W (based on 2.8A switch current estimate due to 3V->5V @ ~90% efficiency guess), not the "blazing hot" I was getting.

    I guess I'll forget about the ETA1096 and stick to the "expensive" TPS61236P for now. ;)  It bugs me though that I don't quite understand what's going on and cannot explain the amount of heat produced.  I seem to be missing something and would love some fresh ideas on what might be happening.

  • Current sense bypass check

    Patrick Van Oosterwijck08/16/2017 at 22:42 0 comments

    One concern I had was that when using the small 14500 size battery, the current sense resistor that limits the charge current also is in series with the load when running from the battery.  My concern was that it would drop so much voltage that the software would decide that the battery was depleted and shut down.  This is, of course, not a problem since the battery voltage is measured directly at the battery, and not after the sense resistor.  But I had temporarily forgotten that. :)

    So I did a test where I used a MOSFET to bypass the 0.18 ohm resistor when the input (charge) voltage was not present.  I wanted to see if it affected run time from the small battery.  This is still a valid test, because the boost converter does see lower input voltage due to the voltage drop across the sense resistor, so its efficiency might go down.

    The test was done with a Pi3 with 4 cores @ 100% and an active SSH connection over WiFi.  Here are graphs of the battery voltage in mV:

    Oddly, the results look better without the bypass.  The worst result was after a recharge a day ago, the voltage would droop and threaten to fall below the shutdown threshold, but then recovered.  The longest run time is without any bypass, and was about 23 minutes.

    I don't know for sure what caused the initial droop, it could be a chemical effect in the battery when charging wasn't recent and ion mobility may be lower.  I will have to do a little more testing on that since it comes dangerously close to the shutdown threshold.

    Overall this is good, the little battery did hold up so it's promising as a solution for those who are looking for UPS functionality and just want enough power to get through a clean shutdown.  The Pi was pulling ~950mA at 5V, which translates to about 1.6A at the battery voltage.  Testing with my electronic load seems to indicate 1.2A output current is the limit for the small cell, at which point the boost converter output droops to ~4.85V, still within the USB spec.

View all 16 project logs

Enjoy this project?



James Christie wrote 03/08/2018 at 10:07 point

Hi Patrick,

I've been following your work for some time, and am excited by the upcoming lifepo4owered/pi+ 

I am hoping the lifepo4wered/pi+ is appropriate for my project.  It's a remote raspberry-pi based audio recorder for birdsong and the like.  I recommend a USB power bank which gives 5 days, or a car battery which gives 45 days (permanent 24/7) recording.  There is big demand for a Calendar mode, so people can record only at certain times (eg the dawn chorus).  I'd like to ask the following:

1 - You are introducing a RTC (yet I don't see one on the components list?).  Will that RTC be available via /dev/rtc in the usual way?  I need to set system time from RTC at boot (while in the forest, so no net access).  Obviously the RTC needs set once after purchase, which is currently achieved by simply booting with a net connection (headless) and waiting for a few mins until systemd's thing picks up net time and sets the rtc and system time.  Will this workflow have to change?

2 - when running normally (power bank providing power), does the lifepo4powered/pi+ waste much of the power?  Specifically, I hope the current doesn't go into the 18650 and back out.  Every mAh is valuable to me. Also, some powerbanks "time out" if they see no current draw for a time (30s or so).  My standard current draw is 70mA (pi A+), and that's enough to keep most powerbanks alive.  However, I expect to see my powerbank time-out and power down when the pi is powered off (awaiting a timed reboot from the lifepo4wered/pi+). At that point, I guess the powerbank suddenly sees a demand (on it's USB output) and _might_ provide power, depending on the particular powerbank's design.  I could probably simulate this situation by : calling "poweroff", wait for the pi to shut down, then wait for the powerbank to timeout, then disconnect and reconnect the power to the pi, and seeing if the powerbank is triggered to turn on again.  Am I thinking about things correctly here? If the powerbank needs a physical button-press to get it going again after time-out, I'm stuffed, right? What a cumbersome question, sorry.

3 - Can I assume a sensible scriptable interface to the reboot-timer.  I'd like to call something like "lifepo4cfg set reboot-time 0500 2018-03-02", or "set sleep-time 10 hours", then call "shutdown" (or something), and have it reboot.  Is this roughly right?

4 - I currently provide users with a custom ".img" file to flash onto their sd-card.  They can drop a few config files into /boot/ to set volume levels and other things.  Can you imagine that I can have a "LIFEPO4=yes" in such a config file, which will allow me to script any loading and configuring the lifepo4 stuff (insmod for the i2c RTC, and whatever else), or might there be tangles there?  Apart from the initial setting of the time on the RTC, I need these things to work straight from a flashed SD card. (might there be access to a bit in the RTC eeprom I can use to flag whether it's been configed before? - RTCs sometimes have some spare bits).

5 -  Currently, standard operation is to allow the recorder to run out of battery and turn off with no clean shutdown (argh).  Wtih the lifepo4powered/pi+ I understand that shutdown will be clean, but will the RTC's clock time be retained (from power from the 18650?) after this?  Normally the operator arrives at the unit (in the forest), changes SD-card, and changes battery and restarts the system to resume audio recording.  I hope that the clock doesn't need reset after being fully run-down.

That's the end of the questions - phew. 

Finally - people might be confusing the lifepo4wered/pi with the lifepo4wered/pi+ project on hackaday because they URL looses it's "+" sign. But perhaps you know that:   (this one - lost it's + sign)  

Thanks in advance.


  Are you sure? yes | no

Steven Lu wrote 01/17/2018 at 21:15 point

I noticed that you mention that a power button (physical) will be employed this time (compared to the touch sensor on the non-plus). 

I support this move and hope that you stick to old school buttons. The other day getting off the train I tried to use the button to shutdown my pi but it did not respond to my finger at all. I have no idea if some combination of temperature or humidity is to blame, but considering how we care so much about the battery chemistry we should make such mundane components as buttons be as bulletproof as possible also.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 02/16/2018 at 23:17 point

Completely agree Steven.  The touch button was too sensitive to external factors such as static electricity that sometimes required it to settle whenever the "environment" changed.  No more of that.  This has a good old mechanical button facing the side, footprints for a button facing up and connections for an external mechanical button.

  Are you sure? yes | no

alanmcdonley wrote 10/01/2017 at 00:08 point

Hi Patrick,

You wrote: "I was intending to provide an option to lower Vout to 4.75V, because it will allow more output current. Can you expound on why you'd want higher Vout instead?"

With the existing LiFePO4wered/Pi3 unit running at Vout: 4958, cooled by the passive 15x15x15 heatsink, in the Tindie case (on 1/2 inch feet), a load factor greater than 2 will eventually report under-voltage throttling and/or high temperature throttling.  Perhaps a processing spike is trying to draw more current than the unit can supply causing the voltage to sag momentarily. Starting nearer the upper limit of the board spec 5.25 might offer me greater protection from these momentary voltage dips.

I read reports from some Raspberry Pi3 owners of under-voltage throttling when they ran at 4.75v (at the board).  Perhaps the voltage sensor on the Pi3, which supposedly triggers at 4.65v, is overly sensitive. 

Offering 4.75v as an option, sounds like it might extend the run time on battery as well.  Options are good.

The new unit with double the power sounds great. 



  Are you sure? yes | no

Patrick Van Oosterwijck wrote 01/13/2018 at 00:47 point

Hello Alan,

You pretty much give the answer yourself as to why being fixed at 5V and removing the option to go lower makes sense.  The Pi will complain if the voltage is "too low". :)  And since modern Pi's all use switch mode power conversion, the voltage level won't make much of a difference in efficiency.  It would have made sense for the original Model B since it used linear regulators, but the LiFePO4wered/Pi+ won't physically fit on those anyway.

I don't think I need to provide more than 5V though because my power output is pretty "stiff", it hardly sags under high load, and I don't need to contend with long cabling as wall warts have to (that's why you see so many 5.1V and higher wall warts--they want to have 5V left at the end of the cable when pulling high current through it).

It is by the way a good idea to use higher-than-5V wall warts with the LiFePO4wered/Pi+ and /Pi3.  They do throttle the charge current if the input voltage falls below 4.65V, and since most so-called 2A and even higher wall warts do sag significantly if you try to load them that much, it's good to start as high as you can. ;)

  Are you sure? yes | no

Jay wrote 08/05/2017 at 13:37 point

Any new updates since the initial load test results you posted 06-22? I'm interested in using a Raspberry Pi as a hub for an environmental monitoring device and your design makes my plan for it much more practical. Interested to know how the 2 oz copper works as a heatsink vs the 1 oz from before!

Thanks Patrick!

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 01/13/2018 at 00:37 point

Hello Jay,

Yes, finally I have new load test results from my latest board revision!  With some improved components, the new layout and 2oz copper PCB, the peak temperatures at high load are definitely lower (20°C lower I'd say).  And its hard to say for sure, but I do have the impression that with the 2oz copper the heat is spread more widely across the whole PCB.  But it's hard to say for sure because it's a different thermal camera, different color gradient, etc.  I just know it's supposed to be better due to physics. :)

  Are you sure? yes | no

x893 wrote 06/16/2017 at 09:19 point


possible use TPS61089 ?

I have some problem with download schematic - can you publish info on github ?

Thanks in advance

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 06/22/2017 at 19:41 point

That chip is more expensive than the TPS61236P I'm using, any particular reason for the suggestion?

Looks like the CDN choked on the "+" in the file name of the schematic, I changed the name and now it seems to work.  Hackaday, fix this so it either works or tells me there's a problem when I upload the file!

Wonder if the "lack of schematic" made any different in the Hackaday Prize judging... :(

  Are you sure? yes | no

Antoine wrote 06/14/2017 at 08:35 point

Hello Patrick,

I have already purchased your LiFePO4wered-Pi3 ™ from Tindie.
Our prototype is based on Pi Zero W for AQI.
Now I have to select Solar Panels and there is a big gap between the average output panels (Vmpp 12V to 17V) and the LiFePO4wered-Pi3 ™ Max (9V).
As you said, the MPPT is also less relevant for panels.

That's why this new version is very clever.

Our vote goes to You.

We keep in touch from South of France

  Are you sure? yes | no

Stevo wrote 05/29/2017 at 21:36 point

I would like to buy two when your have finished the development. How many amps can it supply to the Pi? I have a bunch of peripherals attached to one of mine. I love the battery backup idea. I have lots of 18650s and one of them would be great to power it in the event of power loss until it can be safely shut down. I have a lot of little nieces that tend to trip over chords, unplug things for the fun of it, and create a general state of complete havoc.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 06/22/2017 at 19:43 point

Hello, I'm designing this version to be able to supply 2A to the Pi and whatever you may have connected to it. :)

  Are you sure? yes | no

Magnus Eriksson wrote 05/27/2017 at 19:22 point

Hi. Patrick Van Oosterwijck
It looks very interesting.
I wonder if I can buy 2 pieces of LiFePO4wered / Pi
Then I'm building a bit of a Rasberry pi 3 type that I'll have in my vehicles
I am also interested in being able to drive them with solar cells.
I'm most interested in the model with 18650 cells.
Magnus Eriksson

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 05/29/2017 at 18:58 point

Hello Magnus,

You can buy the existing LiFePO4wered/Pi3 on Tindie:

It will be a while longer before this next gen version will be available since I need to do a lot more testing on it. :)

  Are you sure? yes | no

doubleodoug wrote 05/26/2017 at 22:21 point

Could you post your schematics? Ideally as pdf. I would really appreciate it.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 05/29/2017 at 18:55 point

Planning to post the schematics soon... I just need to overcome my reluctance to give my hard work away. :)

  Are you sure? yes | no

x893 wrote 05/26/2017 at 19:06 point

Super project !!!

Can you publish schematics for LiFe.../Pi+ ?

  Are you sure? yes | no

denplis wrote 05/11/2017 at 19:53 point

Could it be possible to use a few 18650 cells ?

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 05/29/2017 at 18:54 point

Yes, several 18650 LiFePO4 cells in parallel is supported, you will be able to connect them to the BAT through hole terminals and break off the existing battery holder if required.

  Are you sure? yes | no

oshpark wrote 05/09/2017 at 18:45 point

Awesome project!

  Are you sure? yes | no

SlumberMachine wrote 04/06/2017 at 23:40 point

Looking forward to your progress.  I have 2 of your lifepo4weredpi and they have been working great for me.  They even helped me detect and deal with a bad charger I had received by safely shutting down the pi because the usb charger was giving intermittent power (also started smelling like burnt plastic).  Probably would have cost me some corrupted SD cards if it wasn't for your lifepo4weredpi.  BTW - I'm using it for a time lapse setup which I leave connected to usb battery bank. 

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 04/30/2017 at 20:56 point

Thanks for the feedback and glad to hear the LiFePO4wered/Pi are working well for you, I always enjoy hearing how people are using them. :)

  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