LiFePO4wered/Pi

I've been very busy with the development of of the #LiFePO4wered/Pi+ lately, so updates here have been sparse, my excuses for that.  That doesn't mean that nothing has been happening though!  In fact, much of the development going on for the /Pi+ also benefits this project directly, since there is a large shared code base that has been extensively tested on both devices.

Let's go over what's new:

Hardware

The new layout with the improved footprint for the MIC2876 boost converter has been working very well, I have had much less assembly issues with this new batch.  Lesson learned: don't just pick a footprint from the library that looks right, instead make sure it's as close to the manufacturers recommendations as possible or make your own!

The new layout also has a new design for the touch button:

How do you guys like it?  And what it means?

I've been a little remiss on making true on the meaning of that logo, sorry about that.  But very soon now, the source Eagle files for the LiFePO4wered/Pi and #LiFePO4wered/18650 (which is the charging base for the LiFePO4wered/Pi3) will be put up on GitHub! Yay! :)

Firmware

Much work has been done on firmware in the last couple of months.  The LiFePO4wered/Pi and #LiFePO4wered/Pi+ share a code base, so improvements made for the one directly benefit the other as well.  Here is a summary of the improvements that have spilled over to the LiFePO4wered/Pi:

• I2C write shadow buffer.  This ensures multi-byte register values are always written atomically to prevent race conditions.  The I2C peripheral on the MSP430G2231 is a pain because it requires so much babysitting in software, and the Raspberry Pi's I2C peripheral is a pain because it doesn't support clock stretching.  Initially I had a shadow buffer for both read and write, but because the bytes coming out of the LiFePO4wered/Pi could never be 100% trusted (the first bit might be wrong because the software couldn't get to it in time), ensuring consistency for reads has been shifted to the Raspberry Pi code, and only the I2C write shadow buffer is left.
• I2C write unlock code.  To prevent erroneous register writes when multiple processes are trying to access the LiFePO4wered/Pi, a write now needs to be preceded with an unlock code.  Look at the host software source or the updated product brief for details.
• Timeouts for boot and shutdown states.  Before, the LiFePO4wered/Pi would stay in these states until the right host event occurred.  But if a Pi became unresponsive, these events wouldn't happen and the LiFePO4wered/Pi would just keep waiting.  Now the timeouts ensure the power is turned off eventually if things are unresponsive.  The timeouts can also be adjusted by the user.
• It is now possible to force the power output off by pressing and holding the touch button for 10 seconds.  Nice for when you have started the LiFePO4wered/Pi without a Pi attached or if you have forgotten to insert an SD card.
• If the user wants to connect a hardware button, this was already possible by connecting a button in series with a 100pF capacitor between the T and G pads.  Since support for mechanical buttons was added for the #LiFePO4wered/Pi+, this is now also available on the LiFePO4wered/Pi.  Just set TOUCH_CAP_CYCLES to zero and connect a button between the T and G pads, no capacitor needed in that case.
• ADC values now have more precision.  I already was doing a running average on the ADC readings, but now instead of scaling this back to 10-bit every time, I keep the 13-bit value.  The result is better filtering, and less code.
• Added a host application watchdog function.  When using this feature, your application needs to regularly reload the watchdog timer so it doesn't run out.  If it fails to do so, the watchdog timer will expire.  When it does, either the LED will start flashing an error pattern to let you know, or the system will be shut down.  In combination with auto boot, this can be used to reboot the Pi to restart your application.
• Some general reliability enhancements and bug fixes.

And all of that functionality still fits in a 2K micro! :)  These new features are present in all devices shipped since the beginning of 2018.

Host software

The host software has been updated to support the new registers in the new firmware.  Other than that, there are some great enhancements even if you have an older device:

• If you do
  

  lifepo4wered-cli get

   without specifying a variable, the software will now dump all the available variables.  This was a much requested feature. :)

• When reading variables, the host software will now require 3 identical readings before reporting the result.  This is to prevent race conditions when reading multi-byte registers and issues with initial bits missing described above.  We're basically patching a hardware issue in software.
• The host software will automatically retry I2C accesses if they fail.
• The write unlock code described above is automatically handled.
• Added sign extension for some variables, so we can now have negative calibration offsets and they behave correctly.
• Add bus access locks to prevent I2C bus contention if multiple processes are trying to access the LiFePO4wered/Pi at once (such as the daemon and a user program).
• Added Python and Node.js language bindings.  These use the compiled shared library and as such benefit of all the reliability improvements described above.

With all of these enhancements, it is recommended you update the host side software even if you are using an older device!  If you still have the source from when you installed on your device, just run:

git pull
./build.py
sudo ./INSTALL.sh

And you will be up-to-date!  If not, just follow the installation instructions in the product brief.

So there you have it.  Enjoy all the new LiFePO4wered goodness. :)

In this case I lose.  Twice actually, since this is the second time I'm posting this!  Not sure what happened to the first attempt...

So I finally got around to building prototypes of the new boost converter design with the RT4812.  At first they didn't work.  But after I swapped the 1.2uH inductors I had stuffed (my current production parts) with 1.5uH inductors (as specified in the datasheet), they immediately came to life.  I didn't think such a small change would make much of a difference, but I guess this chip it picky!

Here is a prototype in action:

At first glance everything is working just fine.  I didn't really test this thoroughly, but I had the feeling the circuit stayed cooler at high loads as well, which makes sense since the chip has lower RdsON MOSFET switches than the MIC2876.

At some point during my testing I turned the Pi off and connected power to the Raspberry Pi's own power input.  To my great surprise, the boost converter started to become hot!  What in the world?

A little background information may be useful here.  When I search for a boost converter for the LiFePO4wered/Pi, I always look for parts that have a bidirectional load switch.  The reason is that although there is no point to it, you can guarantee someone will plug power into the Pi at some point.  The bidirectional load switch makes sure that in such a case, no parasitic current flows from the Pi's 5V into the battery, while firmware makes sure the LiFePO4wered/Pi refuses to turn the boost converter on.

My current production MIC2876 is such a part.  In the datasheet it specifies it has a "Bi-Directional True Load Disconnect".  So when searching for a potential replacement, I look for the same thing.  The RT4812 datasheet states it features a "True Load Disconnect".  I assumed that was their marketing term for the functionality I was looking for.  And I was wrong.  When powering the Pi from another source, the RT4812 apparently allows current to flow back into the battery.  Very disappointing, since it seems a nice part otherwise.

At this point I can't help but wonder what "True Load Disconnect" is supposed to mean.  If it only works one way, isn't that just regular on/off functionality?  It doesn't seem necessary to even mention it, let alone call it by a fancy name.

On the upside, the RT4812 gets warm but does seem to survive the condition just fine.  What's worse is that I measured 4.4V across the battery, 5V minus the diode drop of the MOSFET's body diode.  That's unacceptable, the maximum voltage across a LiFePO4 cell is only supposed to be 3.6V.

So, back to the drawing board.  Since I'm running out of stock I decided to do another run with the current design, but using a slightly adjusted layout.  The new layout has a different footprint for the MIC2876.  When I first designed the board, I had used a footprint I had found somewhere in the Eagle library, and it turns out it doesn't really match what is specified in the datasheet very well.  I custom made the new footprint according to the spec and also ordered a new stencil to go along with it.  I'm hoping that this will solve some of the assembly problems I've experienced with the chip.

Even though I'm focusing most of my new development effort on the next gen #LiFePO4wered/Pi+, that doesn't mean the LiFePO4wered/Pi shouldn't get any love!

One thing that I've started to notice now I've sold over 750 of these things is that the part that gives me the most trouble is the MIC2876 boost converter.  It's the only part that gives any trouble really.  The tiny little DFN package seems to not always be mounted correctly on the boards I get from the CM, so I need to rework some of them and that's a pain.  Worse, I've even had some field returns where units that were working fine before shipping, would not work when they arrived at the customer, and it's always this part that's been the problem on the returns I've analysed.

So I've been looking for a more robust replacement and I think I've found a good candidate to try: the Richtek RT4812.  It has a nice small leaded package, so assembly problems should go away, and with power MOSFETs that have 1/2 to 1/4 the RdsON as those in the MIC2876, it also should heat up less under heavy load, possibly extending the load current range.

So I've made a prototype layout to evaluate this change:

The RT4812 runs at a lower switching frequency than the MIC2876 and specifies a larger output capacitance, plus it doesn't have a fixed output voltage version, so between the extra capacitors and resistive divider the layout has become even more dense.  But it all fits and that's what counts. :)  The design has been sent to OSH Park, I can't wait to see how it performs!

One of my customers, Raman Sarin, spent some time trying to make the host software work on LibreElec, a small Kodi distro that doesn't come with all the bells and whistles expected for compilation.

I have not tested this myself, but here are his instructions verbatim in case someone else wants to give this a go:

1. Get another SD Card and install Raspbian
2. Go through the steps in the documentation to get the GIT depot onto your Raspbian install
3. Edit the lifepo4wered-daemon.c file and change the shutdown function to this:

void shutdown(void) {
  syslog(LOG_INFO, "LiFePO4wered/Pi triggered shutdown");
  char *params[6] = {"shutdown", "-h", "-t", "60", "now", NULL}; // shutdown halt in 10 seconds
  execv("/sbin/shutdown", params);
}

4. Build the files
5. Copy the BUILD directory to a USB stick
6. Shutdown the pi and swap to the LibreElec SD Card
7. Boot the pi
8. SSH into LibreElec 
9. Copy the files from the usb to sbin directory 
	a.  cp /media/ESD-USB/LiFePo4wered-Pi/build/DAEMON/lifepo4wered-daemon /usr/sbin/
	b.  cp /media/ESD-USB/LiFePo4wered-Pi/build/CLI/lifepo4wered-cli /usr/sbin
10. Make the files executable chmod u+x filenames
11. Make sure I2c is enabled by editing config.txt file
nano /flash/config.txt (at the end)

################################################################################
# Adding information to turn on i2c1 for later rpis
dtparam=i2c1=on
dtparam=i2s=on

12. nano /storage/.config/autostart.sh
	
	(
	        ~/LiFePO4wered-Pi/build/DAEMON/lifepo4wered-daemon
	)&
	
13. Now manually start the daemon so you can configure it
14. Now configure it, I'm using the following, this makes sure the Pi starts up when plugged in and shutsdown cleanly when power is removed. However it also means you can't power it off in software it'll just reboot again.
	a. lifepo4wered-cli set AUTO_SHDN_TIME 2
	b. lifepo4wered-cli set AUTO_BOOT 3
	c. lifepo4wered-cli set CFG_WRITE 0x46 
15. Now reboot the Pi and start testing.

Prototype PCBs for the higher power LiFePO4wered/Pi+ arrived from OSH Park, so I built up a prototype:

I also hacked a #LiFePO4wered/18650 to charge at up to 3A instead of 1.3A as a base for this. This proved to be a bit of a challenge. The charger uses an asynchronous buck converter topology, and the little Schottky diode kept getting too hot and burning out. So I had to hack in a diode in a big SOD-128 package to make it work. It's still getting too hot but it's surviving so I can do the testing with this power manager. This is a basic problem with asynchronous converters: you can never get rid of the voltage drop over the Schottky diode, and at high currents, it becomes a power dissipation problem.

The thermal image below shows the charger getting "too hot" when charging at 3A:

The new TPS61235P boost converter is pretty amazing though. With the Raspberry Pi3 running with 4 cores at 100%, the CPU at > 100C, the boost converter is hardly breaking a sweat:

Very nice! So time to put it on the electronic load and see how high it can go:

And here is a thermal shot at this load current:

I have to admit that eventually, the chip did a thermal shutdown at 1.8A. I lowered the load to 1.6A and it's been running for several days now (while charging, which provides a ton of heat on its own).

Overall I'm very happy with this result. It's capable of providing twice the power of the current LiFePO4wered/Pi before going into thermal shutdown. The components were chosen to provide up to 3A, but I think I have to face the reality that in this form-factor, that is not going to happen. The PCB is just too small to provide any substantial heat sinking. If I want to get to 3A, I will have to change the design and go to a larger PCB.

The #LiFePO4wered/18650 charger may actually be more of a limiting factor to get to 3A though. It's doing it in this prototype, but not at a healthy, mass producible temperature. I may need to look into a synchronous switching solution to get rid of the inherent voltage drop of the diode, which would always result in ~1.5W of power dissipation at 3A.

In the meantime, this still provides a path to an improved LiFePO4wered/Pi3. 1.7A is a huge improvement over 0.85A. And even though 3A charge current seems to be out of reach for the #LiFePO4wered/18650, 1.8A may be a whole lot more manageable.

It's funny how this project has evolved over time. It started with the #LiFePO4wered/USB, which I once connected to a Raspberry Pi as a demo for a Mini Maker Faire. It seemed to work well, and out of that the LiFePO4wered/Pi was born.

Then people wanted to use the LiFePO4wered/Pi as a UPS for the Pi 3, which drew more power than the #LiFePO4wered/USB charger could support, so I created the #LiFePO4wered/18650 as a more powerful charger and the LiFePO4were/Pi3 was born.

Now people are trying to power complete systems including hard drives and LCD screens from the LiFePO4wered/Pi3 and turns out it still isn't powerful enough. It seems the power craved by makers is insatiable. :)

I have received reports of customers powering Pi 3s with LCD screens successfully, and others reported that this failed. The worst thing was that according to the reports the LiFePO4wered/Pi3 did not do a clean shutdown first but power just went away, indicating the boost converter went into thermal overload and switched off. I decided that instead of calibrating this with "it can power a Pi3 at 100% CPU", I needed to come up with some real numbers. So I got a nice electronic load from AliExpress and did some testing:

Testing indicates that the maximum continuous load that doesn't cause the boost converter to go into thermal shutdown, at room temperature and with no extra cooling, is around 0.9A. The system had been designed with components rated for 2A, but on the tiny PCB it seems the boost converter just can't dump enough heat. Keep in mind that this is a thermal effect, so it takes time for the temperature to build up, meaning peak currents of 2A may be fine but are not sustainable over time.

The LiFePO4wered/Pi was originally designed for a Pi Zero or Model A+ or B+ load, for which it works fine. Then the "ping" of making the charger more powerful made the LiFePO4wered/Pi3 possible, still using the same boost converter. But now people want to power all kinds of peripherals as well, and a "pong" to bump up the current capability of the boost converter may be in order.

Luckily new and improved components arrive on the market all the time, allowing more powerful circuits in even smaller dimensions. One such component is the TI TPC61235P, which is a significant step-up to the MIC2876 I currently use. So I made a new layout based on this component and have prototype boards on order from OSH Park:

Tight, but it all fit. Can't wait to test performance of these prototypes!

Kind of late I know, people following me on Twitter or looking on Tindie already knew. I had forgotten that I hadn't mentioned it here yet, sorry. :)

So you can now buy a close-to-perfect power manager for the Raspberry Pi on Tindie! I wouldn't have dared to make such a claim about the LiFePO4wered/Pi, there were too many people who wanted to use it with the Pi 3 and who wanted input voltage monitoring and the behavior associated with that. But now that both these cases are supported with the LiFePO4wered/Pi3, we're getting there! :)

A couple of things are still missing:

• Adding RTC functionality would be great.
• Some people don't need a big battery for long run times. They just want a small battery to shut down safely, but be able to run indefinitely at high load when plugged in. While the LiFePO4wered/Pi3 can be used for this, its battery is overkill. So... I have some ideas. :)

If you like this and want to support my continuing development, please had over to Tindie and buy one!

I did a couple more load tests with the LiFePO4wered/Pi3, the variant that uses the #LiFePO4wered/18650 as a charging base (and should be for sale very soon now). A lot of people seem to have applications where they want to use a Pi 3, use the LiFePO4wered/Pi as UPS, and also plug in a USB flash drive. Since flash drives are power hogs, I decided I should test some scenarios with a flash drive plugged in. So here are a couple of tests I did, with the LiFePO4wered/Pi3 charging from a 2A USB charger:

• Pi 3, 4 cores @ 100%, ssh connection with a WiFi USB dongle (the built-in WiFi on my Pi 3 died), USB flash drive plugged in: slowly discharges (the system consumes more than the 1.33 A charge current).
• Pi 3, 3 cores @ 100%, ssh connection with a WiFi USB dongle, USB flash drive plugged in: charges!
• Pi 3, 4 cores @ 100%, ssh connection over Ethernet, USB flash drive plugged in: charges! :)

I'm quite happy with these results. Systems running at 100% CPU continuously are very unusual. Using a WiFi USB dongle on a Pi 3 is very unlikely as well (unless breaking that silly flip chip without any protective packaging is common, which wouldn't be too surprising). I'm certain the on-board WiFi uses less power than a WiFi USB dongle, so I'm pretty confident that scenario with the CPU @ 100% will work as well. I really should get myself another Pi 3 some time so I can test it.

I've been doing a lot of work on the LiFePO4wered/Pi firmware this week. Much of that was related to new functionality made possible by the ability to measure the input (USB) voltage with the new #LiFePO4wered/18650 base, but the quality time I spent with the code also resulted in some good improvements across the board, including for the standard LiFePO4wered/Pi. Here's a summary:

• Auto boot when plugged in. Aside of the old "always boot when there's enough battery voltage" auto boot, being able to measure the USB input voltage enables the addition of an "always boot when there's enough input voltage and the USB power is present" function that so many people want.
• Smart auto boot. It's fine and dandy to automatically boot when power returns, but it's kind of annoying if this prevents you from shutting the Pi down on purpose. Based on a suggestion from a user, I added smarts so that the auto boot only occurs if the system was shut down due to a low voltage condition, not when the user did a shutdown either with the touch button or from a program on the Pi. This is now an option for both the battery voltage based auto boot and the USB voltage based auto boot if it's available.
• Auto shut down with timer. Many people want the Pi to cleanly shut down when external power goes away and boot up again when power comes back. This is now possible by combining the auto boot and auto shut down features (only with the new #LiFePO4wered/18650 base). The auto shut down will shut down the Pi if external power has been gone for a settable number of minutes. It is actually always active, but by default it's set to 65535 minutes and the battery won't last that long, so the feature is effectively disabled. :) If you want the Pi to immediately shut down when power goes away, set the auto shutdown time to 0. If you want the Pi to keep running across power outages up to 20 minutes, set it to 20. If the outage is longer than 20 minutes the Pi will be shut down with plenty of battery power left.
• Improved wake timer accuracy. While implementing the auto shutdown timer, I implemented a new minute timer subsystem that's much better than the one I had for the wake timer. So now the wake timer also uses this new minute timer and benefits from much more accurate timing. It still uses the micro's internal RC oscillator, but it's much less dependent on variation due to other stuff going on in the code. As an example, I just ran a test of the auto shut down feature with the time set to 30 minutes, and it triggered a shutdown at 29:59. Nice! :)

The improvements that are dependent on measuring the USB input voltage will be available when the version with #LiFePO4wered/18650 base goes on sale, the other improvements will be in every LiFePO4wered/Pi unit going forward!

I'm making good progress on the new #LiFePO4wered/18650 base for Pi 3 versions of the LiFePO4wered/Pi, see this project log.

Meanwhile I've been doing some stress testing on my first prototypes. I've been running a Pi 3 at 100% CPU for 5 days straight, powered from the prototype (plugged in of course), covered with a box to contain as much heat as possible, and it's been rock solid. Yay! :)

So now that I have a new prototype that is pretty much identical to what I intend to run in production, I'm going to do the same test with it:

First I'm having the battery run out, then I'll let the system charge while under high load for a week or so and see if everything behaves well. If it does, I'll go ahead and order production panels.