UPS for Raspberry Pi 2

24 thoughts on “UPS for Raspberry Pi 2”

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

2. I had good results with this: http://www.electrobob.com/5up-simple-5v-ups/
   Sure, it is using stuff from ebay that i don’t think will last long, but i am currently working on a version with good quality parts.

   1. Good article – thanks a a lot for sharing.

3. The RPi build doesn’t install appamor so you can just stop mysql and:
   sudo mv /var/lib/mysql /mnt/usbdisk
   then :sudo ln -s /mnt/usbdisk/mysql /var/lib

   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.

4. 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

   You should now symlink your application directories onto the USB.

   Hope this helps. BTW, I like your ESP8266 articles. Most helpful. Still in catch up mode, but I’ve posted what I am doing (some Home Automation bits) on http://www.ebuild.co.uk/topic/15552-esp8266-roll-your-own-internet-of-things/ where I usually “live” these days. 🙂

   You’ve got my email if you want to PM me on any details. I am also happy to Skype/telephone if you want to discuss your RPi stuff. 🙂

   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…..

5. 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.

   1. 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?

6. Check this out Pete, fit’s your bill perfectly I think

   https://lowpowerlab.com/shop/index.php?_route_=mightyboost

   1. 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.

7. 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.

8. How do you connect the battery to the Pi? Or is it one that can be charged and give power at the same time?

   I have tried 4-5 different power packs (from eBay) but has yet to find one that may work as a UPS.

   1. Yes, it’s an off the shelf job – mini-USB in – USB out – one more lead and you have a fully functioning uninterruptable power supply!

      1. 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.

         1. 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.

         2. Looked back at my posts and found this:

            Using an Adafruit PowerBoost 500 charger as UPS for a Raspberry Pi

            http://khekker.blogspot.com/2014/07/using-adafruit-powerboost-500-charger.html?m=1

9. 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…

   1. Erm the output is surely directly connected to the battery… I’ll put a scope on this but I’m fairly sure the ones I have give continuous power regardless.

      1. 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.

         1. 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.

            Liked your idea about the RTC, I’ll try that too. 🙂

            1. 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.

10. 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.

    1. Got a new usb scope waiting for me at home – will graph and report.

    2. Bear in mind that the USB supply is generating 5v and the Pi is running on 3v3 with it’s own regulator so there’s likely to be a little wiggle room.

Comments are closed.