Close
0%
0%

LiFePO4wered/Pi+

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

Public Chat
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!

LiFePO4wered-PiPlus-5.pdf

LiFePO4wered/Pi+ rev 5 schematic, CC-BY-SA licensed

Adobe Portable Document Format - 43.68 kB - 11/01/2019 at 21:28

Preview
Download

LiFePO4wered-Business-Pitch.pdf

Buniness Plan/Pitch for Hackaday Prize Best Product

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

Preview
Download

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

Download

LiFePO4wered-PiPlus-CC-BY-SA.pdf

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

Preview
Download

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

View all 9 components

  • LiFePO4wered/Pi+ on Mouser!

    Patrick Van Oosterwijck10/01/2019 at 16:30 0 comments

    Thanks to Crowd Supply, you can now buy the LiFePO4wered/Pi+ on Mouser! :)  They seem to be selling well and stock is getting low, so if it's more convenient for you to order there, you might want to get one soon before they run out.

    I just shipped more stock to Crowd Supply so this may be refilled soon, but since all of this is handled internally between Crowd Supply and Mouser I have no visibility on when that might happen.

  • Manufacturing status

    Patrick Van Oosterwijck10/01/2019 at 16:24 0 comments

    I've been putting more updates on Crowd Supply on the state of manufacturing etc, while keeping things here on Hackaday.io more technical, but I thought I should put something about it here as well.  Manufacturing is an important part of every project that makes it to becoming a product, so it's important to share the good and the bad of that as well.

    After some initial stumbles with the quality of the first article, PCBWay did better on the second try so I had them produce the rest of the 1000 piece order. So after not too long a wait I received a large shipment:


    Very nicely packaged. And good quality product. I have not run into too many issues after testing and final assembly of several hundreds of these boards. I had one board that needed reflow of the TPS61236P boost converter. A couple of panels had this weird issue where the mouse bites to separate the boards weren’t all drilled:

    And there was one board that had some cosmetic damage:

    But overall, production has been running smoothly. The red light issue fix I implemented on the revision 5 boards seems to have completely solved that problem, which is a relief. Demand for the product is looking good and with the quality boards we received we are able to keep up with it comfortably.

  • Raspberry Pi 4 Compatibility

    Patrick Van Oosterwijck07/03/2019 at 16:50 0 comments

    With the surprise release of the Raspberry Pi 4, I started receiving questions about compatibility with the LiFePO4wered/Pi+. Here’s what I found out!

    Surprise Raspberry Pi 4 release

    Like most people, I hadn’t really expected to see a next generation Raspberry Pi until next year. Unlike most people, for whom a new Pi release is invariably a delightful event, I experience them with some trepidation. I don’t have any special relationship with the Raspberry Pi Foundation. On the contrary it seems sometimes, since they studiously refuse to acknowledge the existence of my hardware, talk about it, or promote it in any way while they’ve done so repeatedly for my competition. So I have no advance warning, and when a new release drops, I need to scramble and find out if the new thing works with my existing hardware or if my stock suddenly has become significantly devaluated.

    In this case, the release happened on June 24 and I finally managed to pick up a unit from Micro Center on Friday June 28. I had some reasons to be worried since the new recommended power supply for the Pi 4 is a 5V/3A USB Type-C, and early reports indicated the new Pi to be a power hog. So I did some testing over the weekend.

    Testing the LiFePO4wered/Pi+ powering a Pi 4

    The first thing to check was whether the host software would work on the new Raspbian Buster which is required to support the Pi 4 hardware. On that front, everything went smoothly: the host software works just as it did before, and I had the system running from the LiFePO4wered/Pi+ in no time.

    Then came the time to put some load on it. I used the stress utility to load the CPU, memory and I/O subsystem and ran continuous YouTube videos playing full-screen to add some load to the GPU. I also connected a USB hard drive for good measure, while I already had a backlit USB keyboard and mouse connected as well. I kept this running for over a day, with no issues other than that the system indicated with the on-screen thermometer icon that it was thermally throttled. The LiFePO4wered/Pi+ had no issue charging the battery (I was using a 3A charger) and reported a load current to the Pi of about 1.5 A. Since the LiFePO4wered/Pi+ is rated for a continuous output current of 2 A, this presented no issues, other than heat, as the thermal image below shows:

    Both the Pi 4 CPU and the LiFePO4wered/Pi+ settled at a temperature of around 90˚C. When using a system like this at high load, it would obviously be wise to add cooling, but for testing, we like to abuse things. :)

    All this testing had been done with the LiFePO4wered/Pi+ plugged in, which is the thermal worst case since the charging system adds its own heat. Now it was time to test whether the system could run from the battery and survive the transition from external power to battery power, which oddly some competing so-called “UPS”es have trouble with.

    Below is a YouTube video of how that worked:

    No issues! The system runs through the transition as if nothing happened, which is how it should be. I didn’t do a battery run-down test yet, but based on the load current I’m seeing, the 18650 battery should be able to keep running for about 15-25 minutes from battery power at this load, before initiating a clean shutdown and cutting power when shutdown is finished. The 14500 battery is not recommended for a high-power system like this and will likely not work reliably. If you need longer run-times, the LiFePO4wered/Pi+ can of course be used with a large external 3.2V LiFePO4 battery as well, and then it just becomes an issue of how much space you have available.

    I will continue to do more testing, but it looks like the LiFePO4wered/Pi+ with 18650 battery is good to go for powering Pi 4 based systems. The only exception may be systems under super high load doing AI, GPU encoding at the same time with multiple high power USB devices attached, but I haven’t been able to make my Pi 4 draw that much current...

    Read more »

  • Fixing the "red light" issue

    Patrick Van Oosterwijck05/10/2019 at 19:19 0 comments

    Since I was running out of bare boards from the second production run of 1000, and I was intending to do another run of 1000 built completely at PCBWay, I needed to have a solution for some problem that had popped up in some units from the second production run: the "red light" issue.

    "Red light" issue

    Some boards were returned because the red CHRG light would come on (though usually very faintly) even if the battery wasn't being charged.  None of the units from the first batch of 300 ever exhibited this issue, but either having a different batch of components or just the higher volume made this pop up in a couple percent of units of the second batch of 1000.

    For users who mostly use the LiFePO4wered/Pi+ as a UPS the issue isn't really a big deal, but for shelf life and users who use the LiFePO4wered/Pi+ in sleep mode it would be a big deal since it would increase the power consumption in sleep more from around 5uA to several hundred uA.  I really didn't want to build another 1000 units that could have this problem, so a fix was urgent.

    "Red light" fix

    It took a while to come up with a good solution, but I’m pretty sure I figured one out. I reworked 10 boards that had been returned for this reason with my solution, and they all ended up working fine.

    The problem existed in the circuitry I was using to disconnect the charger from the battery when not charging to reduce leakage current. I use three MOSFETs to do this, and in the old circuit they were driven through dual diode D1 from the CN3801’s CHRG and DONE pins:

    In all the LiFePO4wered/Pi3’s and the early LiFePO4wered/Pi+ batch I made, this always worked as expected. The CN3801 has an under voltage lockout at 3.8 V nominal, 3.1 V minimum, and my assumption and experience up till then was that this would keep the CHRG and DONE pins from turning on when the only voltage powering the CN3801 was battery voltage leaking back to this circuit through the diode drop of Q1’s body diode. The pass transistors would be turned off and the circuit would not leak back to the charge input.

    But what I’m learning as I’m scaling to higher volumes is that you always run into new unexpected issues as you scale up. When you make 10 prototypes that work great, you will probably run into some 1 out of 20 problems when you make 100 units next. When you have fixed those problems, your next 1000 unit batch will still have some 1 out of 200 problems. And so on. The upside is that the circuit and your yield improves with every step in this cycle until it is high enough you can live with it. Of course, this also depends on component batches etc., so you might have a 1 out of 200 problem even after you’ve done a batch of 300 previously as was the case here.

    In this case it seemed that not all CN3801’s would keep their CHRG pins from turning on in the under voltage condition. To be honest, the spec never said that they would, this had been an assumption on my part confirmed by experimentation on an apparently too small number of samples. I have now changed the driving circuit for the MOSFETs to what’s shown below:

    The circuit with zener diode and pre-biased transistor doesn’t depend on variations in the CN3801 anymore. Instead it depends on variations in the zener and transistor thresholds. Which can be just as problematic of course. But I think I’ve calculated the tolerances well enough to be pretty confident it will work as expected. Being based on a current driven device like an NPN transistor with pull-down on the base has the added benefit that it presents a bit more load than the purely MOSFET based circuitry I had before, which could more easily be turned on by small leakage currents.

    Thanks to the use of a pre-biased transistor, the new circuit fits where the old one was so from a user perspective nothing will be different in this revision, and hopefully the "red light" issue will be a thing of the past. :)

  • Production progress

    Patrick Van Oosterwijck05/10/2019 at 19:01 0 comments

    Oof, I really haven't been keeping up with updates here.  Too much to do, sorry!

    When I wrote the last project log here, the Crowd Supply campaign was still going on, yikes!  That's been a while.  Since then, the campaign got successfully funded (including pre-orders over 500%!) and I've been scrambling to meet demand.  Since last week, finally all backer rewards and pre-orders were filled.  Crowd Supply decided to stock the LiFePO4wered/Pi+ and now I'm hard at work to build up their stock.

    If you want to catch up on what's been happening, I did write a bunch of project updates over on Crowd Supply:

    https://www.crowdsupply.com/silicognition/lifepo4wered-pi-plus/updates

  • Watchdog feature guide

    Patrick Van Oosterwijck08/28/2018 at 23:51 0 comments

    The Crowd Supply campaign is going very well!  Already over 200% funded and still 21 days to go, yay! :)

    As part of the campaign I'm supposed to post useful or interesting weekly updates.  This week I decided to explain a feature that may cause some confusion: the application watchdog.  Since it's not related to the campaign per se, but explains a feature, I decided to reproduce it here as well.  Enjoy!


    If you are an applications developer for embedded systems, sending your solutions to remote locations where they can’t be reached for reset or service, this update is for you.

    The LiFePO4wered/Pi+ has many helpful features for different use cases. Some people like to use the on/off button to boot and shut down their Pi, while others turn on auto-boot and/or auto-shutdown to get on/off behavior based on external power for their application. The wake-up timer feature is really cool and helpful in low power, low duty cycle applications, and it’s pretty easy to understand what it does and how to use it.

    One feature that people have more trouble with is the application watchdog. Unless you come from an electronics or embedded systems background, you may not be familiar with what a watchdog is or does. So in this update, I’ll explain what it is, why you want it, and how you can use the one provided by the LiFePO4wered/Pi+ to make your Raspberry Pi-based project more reliable.

    The Wikipedia article on watchdog timers explains that a watchdog timer is “an electronic timer that is used to detect and recover from computer malfunctions.” Let’s face it: computers are complicated beasts with many moving parts that all need to work correctly. There will always be bugs (or cosmic rays) that will cause something to act up at some point. If your computer is on your desk, you can reboot it when this happens, but what if you are using a computer like a Raspberry Pi in an embedded system? What about in something that needs to run automatically and reliably, may be hard to reach inside a machine, or is located far away in a remote location? The Wikipedia article notes that “watchdog timers are essential in remote, automated systems,” giving the example of a Mars rover. If your Mars rover’s computer crashed, who would go reboot it?

    Watchdog timers are usually extremely simple, and this is a good thing. It’s the complexity of computers that makes them susceptible to crashes and hangups, so it makes sense that the system that watches over them should be less susceptible to these issues, hence simpler. Ideally, watchdog timers are implemented in hardware. In the LiFePO4wered/Pi+, the watchdog is implemented in firmware. Not quite as desirable as hardware, but if you compare the complexity of the firmware on the LiFePO4wered/Pi+ (4 kB) with that of the Linux system running on the Pi (4 GB), it’s orders of magnitude simpler.

    The basic concept of a watchdog timer is that the software running on the system needs to regularly reset the timer (commonly referred to as “kicking” or “feeding” the dog, depending on how you feel toward dogs), because if you fail to do so, it will reset you instead (the dog will “bite” you) when the time runs out. This ensures that if your system hangs, it can be reset and brought back to a responsive state.

    In the LiFePO4wered/Pi+ implementation, by default the watchdog is off (WATCHDOG_OFF or 0). This is because it’s conceived as an application watchdog: it’s not just there to ensure the Linux system is up, but also to ensure that whatever application you are running is behaving as it should. So how you implement this is up to you as a developer and depends on what functionality is critical to your application.

    The watchdog can be set to two levels by writing to the WATCHDOG_CFG register. The first level, WATCHDOG_ALERT (1), is useful during development or when the Pi system is within view of an operator who can take action....

    Read more »

  • Crowd Supply campaign is LIVE!

    Patrick Van Oosterwijck08/03/2018 at 18:57 0 comments

    Finally, after 16 months of working on this project, the Crowd Supply campaign is now live, making the LiFePO4wered/Pi+ available to the general public!

    If you have been waiting, now's your chance to grab one (or a 10 pack ;)):

    https://www.crowdsupply.com/silicognition/lifepo4wered-pi-plus

    Check it out!

  • We're releasing on Crowd Supply!

    Patrick Van Oosterwijck06/22/2018 at 21:21 0 comments

    Wow, it's been a while since the last update, and in case you're thinking that nothing has been happening, you're very much mistaken!

    The test/programming fixture is working, production units have been characterized, documentation has been written, and we have been accepted for a big crowd funding release on Crowd Supply!

    We're very busy right now going through the Crowd Supply process, which is more involved than I expected.  That's one of the reasons for the delay in releasing the LiFePO4wered/Pi+ unfortunately.  But, the process is thorough, makes you think through everything, and is designed to maximize your chances of having a great release while at the same time being able to deliver to backers.  So it's all good.  We recorded raw material for the product video and will be working on editing it into hopefully a rough draft this afternoon.  We also built some cool demo's to show off what can be done with it:

    Some of these may at some point become their own projects on Hackaday.io to help people get started with the LiFePO4wered/Pi+ as well.  When I find the time. :)

    Crowd Supply is confident that we will be able to go live with the campaign in the next couple of weeks.  In the mean time, be sure to subscribe to the project on Crowd Supply so you're kept up to date and will be among the first to know when we go live!

    In the mean time, take a look at the Preliminary Product Brief as well.  It's very detailed and hopefully helpful in explaining all the awesome features that are available.  I realize it's dense and in the future I'll have to make some simple how-to videos or guides to explain how to use certain features, but for now I think it's important to have a document that captures all the pertinent data you may need to integrate this into your project.  Let me know if there's anything missing that you might need!

    And thanks for all the support and feedback everyone, it's been a long road but we're nearing the finish line. :)

  • 3D printable case design!

    Patrick Van Oosterwijck03/30/2018 at 21:26 0 comments

    A customer had created this great looking 3D printable case for the Raspberry Pi + LiFePO4wered/Pi3 and shared it with me.  I was very impressed and asked if he wanted to create a case for the LiFePO4wered/Pi+ as well, and he did!  The case design is available on Thingiverse:

    He was also nice enough to send me a sample:

    As you can see, the case comes with a hole for a fan, which he had included for me as well.  As the LiFePO4wered/Pi+ has pads for the switched 5V output, I used those as power source for the fan:

    The result is a nice, solid feeling and compact "computing brick" for having a Pi-on-the-go:

    Because of the active cooling, the system stays nice and cool even under high load.  With a Raspberry Pi 3 B+ running with 4 cores at 100% (load average 4.0), the core temperature of the CPU stayed around 62°C!

  • Testing 14500 version with Pi 3 B+

    Patrick Van Oosterwijck03/27/2018 at 22:47 1 comment

    I was curious if the 14500 (AA, small battery) option of the LiFePO4wered/Pi+ would be usable as a UPS for the new Raspberry Pi 3 B+, so I did a quick test.  I ran my Raspberry Pi 3 B+ powered from a LiFePO4wered/Pi+ 14500 prototype, plugged in, for 5 hours with 100% load on all 4 cores (load average 4).  After that time, I checked the voltage and current readings:

    These readings are in millivolts and milliamps, and as you can see the battery is full, the output voltage is not sagging, and the Pi is drawing 0.95A.

    At that point I disconnected the LiFePO4wered/Pi+ from incoming power.  I wasn't sure what would happen: it was possible the battery voltage would sag enough for the system to immediately shut down, or worse, be powered off immediately to protect the battery.

    That's not what happened though.  The battery voltage immediately dropped a lot (due to its internal resistance) to around 3.1V, but the system continued to run!  After about 10 minutes I took these readings:

    As you can see the load average is still the same, by now the battery voltage has dropped to 2.99V, but the output hardly budged: still a steady 5+V.  After about 15 minutes, the battery voltage had dropped enough to trigger a clean shutdown.  Just before this happened I took this thermal shot:

    As you can see, the Pi 3 B+ is hotter than the LiFePO4wered/Pi+.

    Very happy with this result!  It is good news for those who don't care about run time but just want enough power to do a clean shutdown.  Even with a heaviliy loaded Pi 3 B+, the 14500 size battery works.

    If you're going to do this, I recommend using the AUTO_SHDN_TIME register to either trigger an immediate shutdown or timed to 5 minutes or so, to reduce stresses on the battery.  If you want the system to keep running as long as the battery can support it, I'd recommend bumping the VBAT_SHDN to 3000 (3V) or even 3050 (3.05V) though.  The reason is that the boost converter experiences a lower input voltage than the one measured by the micro due to the charge current limit resistor which drops more voltage at high current, and you don't want the boost converter's low voltage cutout to trigger and turn the output off before the micro decides to do a shutdown.

View all 27 project logs

Enjoy this project?

Share

Discussions

Maikel.egberink wrote 17 hours ago point

Hi Patrick,

My current LiFePO4wered config is already running like a charm for almost two years, thanks again.

Now that I’m gonna order one of these soon for a new home-automation project I have a small question. Could you verify it’s also working for a rpi4?

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 3 hours ago point

Hi Maikel,

Yes, as long as the total current consumption is 2 A or below.

  Are you sure? yes | no

Kai wrote 12/03/2019 at 13:24 point

Hi Patrick! I bought the lifopo4weredpi module some months ago and it's working really well for me. It protects my home Automation pi from power adapter failures. Being a RC Pilot, I'm Always concerned About battery life. I wondered if there might be a possibility to tell the lifopo4weredpi module to run on battery while powered to "cycle" the battery to a given Level, then reloading it. I know, this might come with the possibility of not having enough backup power in case of a power outage… If it helps to keep the battery fit, this would be a great thing. Kind regards, Kai   

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 12/03/2019 at 15:29 point

Hello Kai,

Thanks for the suggestion!  I cannot do this with the current hardware as it's a stand-alone charging chip, but I'm working on new technology that integrates charge control into a microcontroller and it should be possible to do it there.
This new technology is currently being developed in the #LiFePO4wered/ESP32 project, but the plan is to migrate this into a future Raspberry Pi unit once it's been proven.

  Are you sure? yes | no

Kai wrote 12/03/2019 at 20:14 point

Hello Patrick,

thanks for your reply. This ESP32-based project looks very interesting. I'll follow it too.

  Are you sure? yes | no

Matthias Urlichs wrote 09/03/2019 at 17:23 point

Nice, the heap of lifepo4wered modules I have are working flawlessly so far.

One firmware enhancement request, though. Sometimes I need to re-init a pi from scratch, i.e. no daemon to keep the lifepo4 alive, i.e. crash halfway through the re-installation.

Idea: when that is imminent, flash the LED for some configurable time (default zero = feature disabled), and abort the shutdown if the button is then pressed.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 10/01/2019 at 17:34 point

Hi Matthias, thanks for the idea!  I'll have to think about this.  The problem is: how does the LiFePO4wered/Pi+ know that this is because you're reinstalling?  This is not necessarily behavior I want to have at other times, since it may make the boot timeout useless for its normal purpose.

Maybe it would be better to just have a longer timeout on boot?  It is adjustable, but maybe the default should be longer?

  Are you sure? yes | no

Matthias Urlichs wrote 10/02/2019 at 04:58 point

This is why I said I'd not do anything different except when I press the button. The boot timeout should be as long as it is anyway, but ten seconds before the LiFePo4+ would take the power down you switch the LED to fast-flashing, and when I *then* press the button you re-start the timer.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 10/02/2019 at 21:13 point

The problem is that one of the main reasons I implemented the boot timeout was to prevent problems with units being on or having run out of battery when they arrived because the button was somehow pushed during shipping.  This makes me nervous about canceling the timeout with a button push as it may make the timeout ineffective in one of its main uses.

  Are you sure? yes | no

turnkit wrote 11/27/2018 at 09:26 point

Motion >>> WAKE, stillness for five minutes >>> SLEEP ???

Any chance that functionality could easily be added???

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 11/28/2018 at 02:56 point

If you create a circuit that generates a >2s pulse from a motion detector and connect that with an open collector/drain to the BTN input, you might be able to make that work. :)

You'd probably have to add some lockout that inhibits the fake button press if Vout is present.

  Are you sure? yes | no

dion wrote 07/06/2018 at 02:16 point

Patrick,

I'm following this project with interest. It looks close to fruition which is terrific.

One query I had that may well have been covered though I've simply not delved deeply enough in the text here; if following a period of UPS function the battery depletes and the system shuts the Pi down in an orderly way, is there provision to reset the Raspberry Pi via the lifepo4owered/pi+ board when external power is re-enabled, and/or to remotely re-start the Pi when external power returns?

Dion

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 07/28/2018 at 02:37 point

Hello Dion,

Yes, you can enable the AUTO_BOOT feature to make it work this way!

Patrick

  Are you sure? yes | no

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:

https://hackaday.io/project/20909-lifepo4weredpi   (this one - lost it's + sign)

https://hackaday.io/project/9461-lifepo4weredpi  

Thanks in advance.

James.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 03/24/2018 at 23:45 point

Hello James,

Sorry I didn't see this earlier, I hope you will get some notification that I wrote an answer!  Here it goes:

1. It's an RTC function, not an RTC chip.  The micro has a 32 kHz crystal connected and in tandem with the host daemon implements what's needed to save the system time on shutdown and restore it on boot.  There won't be a /dev/rtc device, and it has no temperature compensation as fancy RTCs have, but it will be sufficient for many uses.  Testing indicates that you might deviate a second or so per day.

Note that if the system time is already very close to what the LiFePO4wered/Pi+ has kept track of, it will decide there's another system keeping time and won't reload the value on boot, so if you need a better RTC you can still add it and it will take precedence.

Also, your workflow to set network time etc should still work fine.

2. Unfortunately all power conversion wastes some energy, and so does the LiFePO4wered/Pi+.  If the battery is charged, the current doesn't go in and back out the 18650, but it still goes through the input (charge) stage and output (boost) stage of the circuit.  The charge stage has around 85% efficiency at high currents and the boost stage 90%, so the combined efficiency is around 75%.  This was tested at 2A load, I haven't done the experiment at lower load currents.

I should also note that the LiFePO4wered/Pi+ was designed to be able to remove the on-board battery area and connect an external (large) LiFePO4 battery instead, and some pre-release customers are using it that way.  By doing this instead of using a large external battery, you only need to consider the efficiency of the boost stage, which is around 90%.  You can also charge the big battery from a solar panel in that case, if that would be helpful.  On the downside, replacing the battery would clear your RTC time, unless you add a big cap in parallel with the battery.

Your procedure to test the behavior of your power bank sounds correct.  As long as the Pi is running, the LiFePO4wered/Pi+ will draw power from the input to power it, as long as power is present.  What happens when the Pi is shut down is the question, because when the battery is full, the LiFePO4wered/Pi+ will stop drawing current if the Pi is off.

3. The RTC wake time is set as a Unix time stamp, so a large number such as 1521934164.  Of course you can combine with other tools to make this more palatable such as "lifepo4wered-cli set rtc_wake_time `date +%s -d "3/25 10:00 am"`".  The rtc_wake_time register is for setting an absolute time to wake up, you can also still use the wake_time register which sets a relative number of minutes from the point when the system is done shutting down.  Performing actual shutdown is your responsibility.

4. That should be possible, but you can also just have the lifepo4wered-pi host tools installed and they won't cause any issue if no LiFePO4wered UPS is present.

5. With the LiFePO4wered/Pi+ added, a clean shutdown is performed and the RTC time is kept with the 18650 even if it's "empty"--there will still be plenty of charge to keep the 4uA micro running for quite a while on remaining charge.

And, yes, I know the + is missing from the URL, it's annoying but nothing I can do about it. ;)  On the plus side, the name meshes nicely with the new Raspberry Pi 3 B+ just released. :)

Again, sorry for not seeing this sooner and I hope it answers your questions.

  Are you sure? yes | no

James Christie wrote 04/25/2018 at 06:35 point

Patrick - thanks for this detailed reply - it gives me a lot to work with.  Cheers.

  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. 

Regards,

Alan

  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

Hi,

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 Hackaday.io 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 ™ V.in 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.
Sincerely
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: https://www.tindie.com/products/xorbit/lifepo4weredpi3/

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