# Circuit to safely power-down Raspberry Pi

I want to use a Raspberry Pi as an XBMC server in the car. The XBMC docs say that you should always use the shutdown command before disconnecting the power. I don't want to have to (tell my wife to) log into the Pi and shut it down before turning the car off - I want to be able to

I've been thinking that it should be possible to create a simple circuit with a capacitor and probably a diode to detect when the power supply was disconnected (and raise an interrupt on one of the GPIO pins) but the capacitor would provide current long enough for the system to shut down properly.

Does this look correct and sufficient?

The circuit will be powered by a car battery - 12.6 to 11.7V. The Raspberry Pi takes 5V (5.25 to 4.75V) and draws 700-1200mA. I haven't timed it yet, but I'm guessing the shut-down process probably takes around 5 seconds.

So I suppose what I need to know is:

• What kind of capacitor would I need to store enough charge to keep the Pi going long enough for XBMC to shut down properly?

• Given that the Rasperry Pi's GPIO port takes 3.3V, what's the best comparator/op-amp to use (I suppose I could use a couple of resistors to bring the output down from 5 to 3.3)

• Would there be any benefit in having the GPIO line normally high or normally low?

• This IC: linear.com/product/LTC2935 might be of interest to you. Mar 12, 2013 at 1:45
• As per answer below in concept your idea is OK but will require very large caps. You could also look at powering the Pi from something on all the time, then just use the ignition to start a shut-down and maybe a timer to pull power altogether after a minute or so. Mar 12, 2013 at 1:57
• That's a good idea @PeterJ - would likely be a lot cheaper. Could you elaborate on that in the form of an answer? Mar 12, 2013 at 6:45
• Rather than powering the RPi from a capacitor for several seconds after the ignition is turned off, I think it probably makes more sense to use a relay controlled and powered by a 555 to switch to the battery. I've created another question: electronics.stackexchange.com/questions/61877/… Mar 25, 2013 at 14:08

An alternative strategy would be to power the Raspberry Pi continuously and use the ignition line to initiate the power down sequence. I've done that in the past but with systems where the exact solution wouldn't apply to a Pi but in general:

Use a DC-DC converter for the best efficiency, there are many examples around but the following is one example of something that would be convenient to use and it can supply 1A at 5V from a 6.5V to 32V input:

http://www.digikey.com/product-detail/en/V7805-1000/102-1715-ND/1828608

A car supply can be quite harsh, so you might want to use a 30V TVS diode across the input to protect against spikes with a chunky Schottky diode with the anode at ground and the cathode at the 12V input to protect against negative voltages along with either a normal fuse or a PTC resettable fuse in series with the connection between the car's power and your system. Otherwise you may be able to 'hack' a car to USB charger that should already have all that in place.

I'm not sure what a Raspberry Pi draws in normal idle mode, but presumably well under 500mA which is the maximum USB can supply and more likely 100mA. Say it's using 100mA at 5V that will be under 50mA at 12V using that circuit, a car battery is normally in the order of 50Ah so that would be around 20 days to drain the battery to 50%. If the car is in regular use there's probably no need to go any further, and you may just be able to leave it running and just turn off any peripherals you're not using.

Otherwise for detecting the ignition change either way and both informing the Pi it needs to shut down followed by removing power a minute later the most practical way is probably to use an external microcontroller that drives a FET. It could be done with discrete logic but you also need to make sure power is re-applied when the ignition goes high, so it's not an entirely trivial excercise but parts costs will be lower than using a large cap.

• Thanks, your answer led me to Googling for "shutdown controller raspberry pi". I was looking at this one for $42 but then found this one specifically designed for the Raspberry Pi, and it's only$15 and he has one designed for use in a car. Mar 12, 2013 at 13:18
• Raspberry Pi Model A takes 300ma (+ 100ma max on each usb port), while Model B takes 700ma. Mar 12, 2013 at 20:47
• What you can also do is to simply hook up a button and run a python app everytime your raspberry pi is powered on. Then in the python app, use button function os("halt") to simply shutdown your raspberry pi. That's what I did and its working fine. I dont know how that would work with XBMC though. Oct 19, 2016 at 9:34

I'm not intimately familiar with the behavior of the Raspberry Pi for shutdown and power usage, so I'll mainly rely on the numbers you gave and leave the formulas.

The exponential discharge curve you show is for a resistor-capacitor circuit, but the linear regulator causes things to act a bit differently. Suppose the RPi always consumes the maximum current you stated: 1200 mA. In this case, that current always flows through the regulator, and the effective resistance of the circuit is constantly changing (decreasing) as the capacitor discharges. This is true as long as we are in the operating range of the linear regulator, which is fine because we need the RPi shut down before we hit that region.

The differential equation for a capacitor is: $$I=C\dfrac{dV}{dt}$$ which can be rearranged to solve for C: $$C=I\dfrac{dt}{dV}$$

• I is simply the average current for the RPi. In this case, we will assume it is 1200 mA, or 1.2 A.
• dt is the time it takes to shut down the RPi. Using your example, this is 5 s.
• dV is the change in capacitor voltage. We'll assume that the starting voltage is the lowest specified voltage of 11.7 V, and that the ending voltage is 7.0 V. I'm setting the end voltage to 7.0 V because the 7805 linear regulator requires two volts headroom for proper operation (5.0 V + 2.0 V = 7.0 V). This makes dV = 11.7 V - 7.0 V = 4.7 V.

This gives the following result: $$C=1.2A\dfrac{5s}{4.7V}=1.28 F$$

Yes, that's 1.28 Farads (no micro or milli here). This would likely involve buying several low-voltage caps and placing them in series

So then the other issue is your circuit - it won't work the way you want it to, because the only way the positive input of the comparator gets close to the negative input voltage (so the output can change) is when your input voltage is already dead. As designed, the comparator would never switch.

What you want to do is measure your input voltage, before the capacitors and diode, and compare that voltage with a "reference" that you can set with a trim pot. See example circuit below:

simulate this circuit – Schematic created using CircuitLab

• You're right - I meant to feed the positive input of the comparator from the other side of the diode D1. I need the GPIO pin to trigger an interrupt the moment the 12V supply is disconnected (the radio and accessories are turned off). ...So the reference voltage is 0, isn't it? What's the purpose of the TVS diode? Mar 12, 2013 at 2:42
• I have multiple of these here, would they be perfect for this job? i.ebayimg.com/images/g/lF8AAOSwBP9UYdRb/s-l300.jpg Sep 1, 2016 at 6:08
• @danbru No idea, that's a picture, not a datasheet. If you think your eBay capacitors are really 1.5F at 5.5V, then you will still need to put multiple in series and parallel to get your needed capacitance.
– W5VO
Sep 1, 2016 at 11:55
• @W5VO is there some easy way I can test the capacitance? Sep 2, 2016 at 6:45

Note: the following answer was written with the assumption that only the file system's usage of an SD card could become corrupted. A lot of anecdotal evidence has since come to light to suggest that the internal state of SD cards themselves, below the level of any filesystem are potentially at risk for corruption from ill-timed power loss, something it may not be possible to work around at filesystem level.

I'd be tempted to look at an entirely different approach, one of solving the problem at it's source. Essentially, there's nothing fundamentally wrong with just yanking the power from the pi; the problem is potentially uncommitted filesystem state leading to file system corruption, and subsequent boot failure until you repair/re-image the volume.

But this is something that can be fixed on the software side, by some combination of:

• Create more partitions on the SD card, and never mount the boot or operating system partition in writable mode. If you want to go a step further, never write to anything on the SD card at all, keeping all your mutable data on a USB stick.

• Use a journalling file system to store data which will actually be modified in operation.

• Simply keep a backup card handy, optionally this could be some automatic backup and recovery scheme from a connected card with a rule where only one of the cards can ever be mounted writable at any given time (combined with first rule of the boot/operating system partitions never being writable)

Ultimately it comes down to a question of design philosophy - the choice between:

A) A delicate system which must be protected from power loss less it suffer corruption

or

B) A system designed such that unexpected power loss cannot result in unrecoverable corruption.

Most embedded systems are more along the lines of (B).

• Separate partitions on an SD card with some read-only won't entirely solve the problem. Wear leveling on SD cards can destroy ANY block on the card (when it's swapping blocks). This wear leveling is completely hidden in the SD and there's no way to control it. In fact, with the filesystem partition read-only it will have the lowest write counts and will be prime targets for what to swap with when wear leveling. Mar 12, 2013 at 18:06
• BTW - I've come to the conclusion SD cards are impossible to design robust embedded solutions for unless you can guarantee clean shutdowns. The spec really sucks for embedded use cases... which given how many ARE embedded it's a pretty sad state of affairs. Mar 12, 2013 at 18:12
• @darron: It is sad, given that there are many ways the problems could have been avoided. For example, the spec could have specified a "shutdown" command and required that any device must be able to put itself into a safe state within e.g. 250ms of receiving it. I think most practical SD-card implementations would have had no problem with such a spec even if the shutdown command came in the middle of a "background defragmentation" operation that would have taken minutes to complete. Mar 12, 2013 at 18:26
• @darron - it was specifically because of such cross-partition issues that I mentioned the possibility of never writing to the SD card at all. Mar 12, 2013 at 18:40
• When shut down properly, XBMC saves the current point in the song/film being played to disk so that it can resume from the same point when restarted. I'd really like to avoid "Dad, we've already seen this bit, can you pull over and fast forward to the bit where that man does the thing?" Mar 13, 2013 at 0:47

As others have pointed out, there are a few problems with the circuits proposed so far, and you can get a capacitor large enough to hold up the supply either. If you're willing to build a little circuit, you might consider a latching power turn ON/OFF controller that is push button operated. To turn OFF the XBMC server you could press a button that signals the Pi to shut down, it could then do what it needs for a clean orderly shutdown, then issue a GPIO signal to the circuit that shuts down power to itself. That gives the RPi as much time as it needs to do things like safely shut down the SD card. The circuit doesn't have to be even as complex as a relay and timer.

Here's a simple circuit to do it, that uses only a dual mosfet as the controller. The circuit is described on the web page.