UPS for Raspberry Pi 2

Being a Sunday I was lying in bed early this morning pondering life when I was reminded that we had 2 short power cuts in a row the night before due to me overdoing the electric heaters here in our cave in Spain where we’re having a short break. The laptop of course survived no problem due to internal battery but the Raspberry Pi went stone cold dead on me.

It occurred to me as I load more and more onto this tiny computer including a MYSQL database, that such cuts could do damage to the microSD card and indeed people have said that occasionally they go bad.

It occurred to me as I was sitting starting at one of the many unused “emergency power” solutions I have for my phone lying around that one of these would make an ideal “uninterruptable power supply” for the Pi. Indeed a very trivial script attached to one of the input pins could easily monitor the incoming power and do a nice, graceful shut down in the event of power loss.

I have one of those “Juicebar” devices, half the size of the Pi that accepts USB power and/or solar charge and with maybe 200ma capability could easily keep the Pi running for half an hour or more. Aside from the obvious advantage of protecting against power loss, I have no doubt these units will also protect to some extent from power surges.

And so that’s the plan. One wasted piece of kit lying around doing nothing could now save the bacon next time we have a power cut. These devices can be had for as little as £2.99 from Ebay (minus the solar panel) so really it just makes sense.

Up market at £10, the solar chargers come with 10,000maH capacity – that’s well over a day of operation and the solar panel can actually make a small contribution to the running costs!

Update March 26,2015: Just as has been mentioned it has come to my attention that many designs of these power systems will NOT allow you to use them in this way - you'll have to test. I have 4 such supplies - two will act as uninteruptables, the other two will not charge and be used at the same time (which seems a bit daft).

Post navigation

24 thoughts on “UPS for Raspberry Pi 2”

Make sure you test the battery out beforehand. Most that I have tried actually drop the power to the pi briefly when the input power is lost. Meaning that you get a power cycle instead of a true UPS-experience.

Actually, you should have a look to adafruit site. They explain that most Usb batteries can't switch from charging to providing power transparently IE there will be a power off for long enough so as to enforce a hardware reboot.
There is also a kickstarter project which did ended with a successfull accessory board dedicated to the raspberry pi, suitable for this purpose.
Finally the mag pi has some advertising for some ups dedicated to the raspberrypi.
Sorry for the not so precise clues: I am typing this answer on a Android tablet...

Hello, again, now with a real keyboard...
So the dafaruit link https://www.adafruit.com/products/1566 states "Its not good as a 'UPS' power supply for an embedded linux board, although microcontrollers like Arduino may not care about the voltage drop as much.".
Actually I tried another one and did failed to get an UPS for a Pi.
About the Kickstarter project it is named PiUPS there https://www.kickstarter.com/projects/1842571016/piups-uninterruptible-power-supply-for-raspberry-p?ref=nav_search and they did had success. However it is rather expensive with respect to the RPi price...
Finally, the mag pi has those products are actually those of the kickstarter project.
Now what you are facing is more complicated, unfortunately, than just power outage of the RPi.
You should investigate about:
+ SD wearing (writting too often at the same flash memory bloclk),
+ ext4fs's commit parameter that define the maximum time it will retain data in memory cache (5 s per default) that should be specified in fstab file: endless discussions about those things.
+ and last but not least the fact that SD cards are littel computers lying to their hosts: they just don't say when you can power them off...

There is also, in the background, the fact that there is no RTC battery backup hardware which imply that Raspbian will periodically rewrite at the fake hardware file on the SD card: sd wearing in this case.
I did solve some of those problems with some compromises:
+ added an hardware clock (cheap and efficient),
+ suppressed swap files, suppressed fake hardware clock from raspbian,
+ use unionfs on top of /etc and /var/log.
+ accepted to loose some data by restricitng real writes to the sd card every 6 hours.

Databases are an other problem: most of them just don't care about writing data logs always in the same files: See Graphite rather than rrdtools for instance.

A little clarification :
1) "SD wearing (writting too often at the same flash memory bloclk) -"
--- When you use a "brand" flash that has a controller (not bare bone like the one in the ESP8266) you can't "wear" specific address. The controller has his own address table to mach with the "host" (user) address (like Virtual Memory).

2)" last but not least the fact that SD cards are littel computers lying to their hosts: they just don’t say when you can power them off…"
--- Every known "brand" flash has to follow JEDEC roles. One of them is telling the Host when it is ready to sleep. If the Host use this information or not, well... I guess not all of them.

The RPi is not supposed to be a robust system but an affordable, learning for the students.
Because of the low cost, we all try to maximize the benefit of it.

Hi,
1) Yes, you are somehow right: the ESP8266's flash is effectively written at a position strictly determined by the microprocessor. So it is possible to write 10000 times and wear it at once. But this flash chip is not intended to be written by a file system as it is the use case under linux.
However, under linux, the trouble comes from the file descriptor'ss memory blocks as it is stored in the subdirectory containing the modified file: it is overwritten, with say the new data size and modified time stamp of the file, every time it is modified. This is a brand dependent context but sdcards are mostly designed for movie and phto cameras which are far less tricky than linux. Furthermore the time stamp of the modification is also written in the subdirectory "last time modified field". There is an option, under ext4fs to disable and avoid this precise rewrite.
So, if you write, say every 1,5 s, to an ext4fs file, the subdirectory containing the file will have a particular memory block modified every 5 s (default commit value). Finally it takes 1 or 2 weeks, at this pace, to wear the subdirectory sector. You end up with a write error. The sdcard internal remaping is just designed to avoid bad blocks originally located on the sdcard.

You may get much better, and reliable, results either by:
+ splitting your file in timestamp based subdirectories tree: this is applied by photo cameras in their subdirectories tree used to store photos. It is clearly not appliable to databases as they are not designed to do so.
+ delay writes and just have a single one every so many hours rather than seconds (commit parameter value set to 10000 s for instance). You are then left in trouble with losing data and changes in case of power outage.
+ use a specifically designed file system such as Samsung's friendly flash file system fffs. It uses a totally different block allocation strategy and attempts to write at empty new blocks each time a file is modified, using special markers in order to indicate that previous ending blocks are no more valid. It will, once the sdcard is full, use a garbage collector algorithm to recover unused memory blocks and re use them. However, once the memory card starts to be really filled up, you will find yourself back to the previous problem.

As an other concern is real power outage, just remember that any write needs much more time (some wrote 30 s, certainly 1 or 2 s) to make sure that the writing cycle is effectively finished inside the sdcard. Not all sdcards do inform their host that they have done it. In case of externally caused power outage, there is just no solution but to have a real ups... Again one strategy, faillable but cheap, is to delay and group writes to the sdcard thus reducing by a considerable factor the probability of power failure during the actual writes to flash inside the sdcard.

As it comes to the faked hardware clock, you could disconnect the writes or symlink this particular file to /tmp. /tmp is a ramdisk setup per default on debian which won't hurt the /etc subdirectory flash sectors. This is just used to cope with the inaccurancy of the internal clock used in the RPi. As a side point, /tmp can be read and written by any linux user. As such there no security for files stored in it.

Just all of this is to mentionned that I did weared 2 sdcards with such occasionnal power outages AND continuous writes to log files (plain text files). I solved that by splitting my logs in subdirs, so as not to write inside those subdirs more than 7500 times each, and added an hardware clock. It allows to have immediatly correct time stamps at boot time far before NNTP gave a correct time to the RPi clock. And disconnected swap files, modified time propagated to subdirs and fake clock file redirected to /tmp. Those have little or no annoyance in real contexts.

So far, 5 months now, I have been lucky not to lose any data but the last 5 seconds of measurements, that's 3 points lost, in any circumstances: including double power outages separated by 1 minutes or less, of power on. I did not spend the price of a ups, as expensive as an RPi, and just purchased a hardware clock on ebay.

The last tricky thing for me will be to have such a long term reliability with real databases softwares: they do write their data and indexes files always at the same memory block and as such will kill the sdcard.

The adafruit product mentionned there is interesting beacause it is not too expensive. There are also other dev boards which include battery chargers (Olimex) costing more or less the same prices once batteries are added to the bill.

I did not mentionned:
+ the life expectancy of permanently charging batteries but this is also to be considered when you want years of non interruptible services.
+ the rapsbian updates that some times do not happen transparently and requires a re installation of some kernel's part. Dist upgrades do that sort of things.

So far, it is really is a matter of compromises between money/reliablity/complexity. And, yes I did learned a lot about fs, overlays, unionfs and generally linux thank's to the RPi.

I thought about it, again and again, but don't remember reading any allowing this setup for charging and supplying at same time.

So I did a quick test using my phone to the battery and then a metered watt from Walwart to battery. As expected, the phone will charge, but the battery will not accept supply power from wall adapter.
My conclusion: not all battery packs, if any or few, will be ready for plug-n-play ready as UPS.
If a known brand does exist, a link to that exact brand would be nice to share.

I'm not with this at all - I very often power something from one of those units - and charge it at the same time. I have at least 2 units back home I do this with. Here I have the solar powered JUICEBAR and it most certainly is charting (from USB) while it is powering the Raspberry Pi and when I accidentally pulled the plug the other night, it took the Pi 2 hours to die on me. I'll try others when I get back to the UK and report back in here but I'm sure the little £3 ones work in exactly the same way.

I'm currently running one of my Pis AND a ESP8266 using an unregulated wall wart and a LM2596 regulator identical to this one.. I'm also using one of these regulators to deliver 5 v to LED lighting and USB sockets in our boat.
In your situation, I'd be tempted to grab a 12v lead-acid deep-cycle boat/caravan battery, charged by a small charger or solar panel, and a regulator like above, to power the house computer. The battery voltage could be one of the monitored parameters, which would confirm both the presence of charging and the state of the battery when charging is off.

HEY - apart from it being in the states and me being in the UK, that looks GREAT Adam.... might be more of interest to our US readers as I suspect it will be cost-prohibitive to bring it here to the UK.

You are really better off using a real HDD for your applications data. I bought one of these cheap iSATA to USB cases for a 2.5" HDD that that I took out of an old laptop. Not bad - a 150 GB HDD for under £4. It will show up as /dev/SDA, so you can reformat partition 1 as ext4 and add the mount line to /etc/fstab.

Put in a crontab script to mysqldump the DB to a backup each night and then rsync this off-device or better off-site.

I thin you are probably right Terry and I have such a hard drive - I've not the slightest idea how to take my existing setup and make it work on a drive - including boot up - did you find a simple guide?

Re guide -- nah, I walked away from M$ and WinX a decade ago. I've been sysadmin on a couple of FLOSS projects and used only Linux for my Home PC since my last Windows PC died years ago. You may as well leave the boot FS on the /dev/mmcblk0p1 vfat partition and the root FS on /dev/mmcblk0p2 as standard.

If you trawl the internet there are all sorts of suggestions to minimise the writes to the SD card, such as mounting /tmp as a tmpfs, using noswap, ... but these I would avoid this sort of complication as you aren't experienced in Linux admin. Just get your SD image fairly stable, plug it into PC and take am image backup, then blow it onto a spare SD then keep this as a cold-swap by your RPi.

Create a mount point on the root: sudo mkdir /mnt/usbdisk
and add the following to your /etc/fstab: /dev/sda1 /mnt/usbdisk ext4 defaults,noatime 0 1

Will do - I've already copied the entire setup from one Pi to another just by copying the SD (another myth blown) and so keeping a spare is no big deal but I need faster SDs and faster copier as it takes a couple of hours to backup and restore the 32gig microSD
I'm also guessing I can stick with the SD but somehow tell mySQL to do it's data manipulation on an HD - pref a solid state one. OR one could put the data on a separate SUB memory stick - easier to back up - so many options.....

and restart mysql. So long as the HDD is mounted in the fstab, the directory will be there before MySQL starts.

If you have a HDD and move any other data directories onto,then you only need a 4Gb SD; 8Gb tops for your system. Since the two FS (boot and root) are standard file systems with no funny bootloader sectors, you can simply tar them. My images are about 550Mb in total, but I run my server headless and have stripped out all of the X and desktop crap.

Great post mate, enjoys reading. you really keep it simple. thanks for sharing.

Comments are closed.

Welcome

Hi - I'm Pete and this is my technology blog. It is BIG. Use the search box below or check out the archives and other links below - be sure to SHARE what you like using the social media buttons.

Please register or log in - the top menu changes a lot when you are part of the party... and once in, don't forget to tick the box so you will get email follow-ups to comments.

I am tied to no organisation - I do this for the joy of learning. Maintaining a blog of this size takes a lot of work and I hope you find my contributions useful - if you want to help fund my gadget habit or buy me a coffee - here is a link.

Disclaimer: Because I have no idea of your level of technical skill or the requirements of your country laws in terms of electricity supply etc., I accept no responsibility for any damage caused through following advice in these pages. When dealing with mains voltages you should satisfy yourself that whatever you are doing is safe and if unsure, seek advice from someone who is sure.

Notice: I'm always happy to offer advice on stuff I've written - and indeed take advice. If I can help in any way just let me know but PLEASE don't ask me how to program in C/PASCAL/NODE/etc. There are many resources out there - if you want to program and can't - there's always Google.

Newsletter

The blog will send you occasional emails containing links to recent posts. No ads and your email will not be given to third parties. There's an un-subscribe link on each email. Invalid names will be deleted.

Links

EE Times | Electronic Engineering TimesEE Times connects the global electronics community through news, analysis, education, and peer-to-peer discussion around technology, business, products and design