2

I'm looking for the easiest way to delay the loss of power to the pi (for a duration on the order of milliseconds) after the power supply is lost. I'm no good at designing circuits and I'm guessing that it's a bit more complicated than just sticking a capacitor somewhere but if there is a simple schematic (ideally that just integrates with the main power cables) I could probably build it. Most UPS systems I'm finding are too complex and provide enough time for a full shutdown and I just want a fraction of that.

Thanks for any pointers.

Improve this question
7
  • 2
    take a look at this on how to setup a r/o filesystem for deployment. if you really don't need a r/w filesystem this might be a better solution than trying to delay the inevitable. "just sticking a capacitor somewhere" might "just fry your pi" ;)
    – Shreyas Murali
    Sep 23, 2016 at 19:02
  • 1
    I just want a fraction of that -> You are wasting your time if you think you can pull some kind of trick in "a few milliseconds" in this context using a normative operating system. A shutdown doesn't need to be more that a few seconds, but trying to cut corners on that is going to end with "scrap this idea and start again". Do it properly or don't bother.
    – goldilocks ♦
    Sep 23, 2016 at 19:20
  • 2
    I'm saying unless you write your own OS kernel you cannot ensure or control that (I'm dubious you could even then -- the SD card is a black box). Also, filesystems have a complex structure that does not allow you to just finish dealing with the current block then forget about everything and it will all be okay. Files are spread around in fragments, and meta information about the location of those fragments must be maintained...
    – goldilocks ♦
    Sep 23, 2016 at 19:45
  • 2
    ...A major cause of "file system corruption" is when these things do not correspond. I.e., on a very low, physical level, a write may have finished properly, but if the accounting for whatever it modified is not also done, the fs is now corrupt. Techniques like journalling mitigate against this in the sense they make repairing such damage easier, but in that case it doesn't really matter about "giving it a few milliseconds".
    – goldilocks ♦
    Sep 23, 2016 at 19:49
  • 1
    here's a post dealing with options for UPS
    – Shreyas Murali
    Sep 23, 2016 at 22:02

3 Answers 3

Reset to default
4

From the electrical point of view, adding a lithium battery would be the way to go. There are a lot tutorials on how to make your Pi ready for mobile use and if you have it permanently connected to the power supply and only need this as a backup, it should never run out of power.

Adding a capacitor would work, at least in theory, but let's talk about the dimensions first: The Pi 3 draws up to 2.5A (worst case scenario) from a 5V supply voltage. The definition of Farad is As/V. so by inserting current and voltage you get 0.5s from a whole (!) Farad, and only if it can hold the voltage until it is completely discharged... which, well, it simply doesn't. The voltage of a 1F capacitor would have dropped to 4.95V after only 20ms.

So you can see that to realize a capacitor solution for a whole shutdown you would need many F so it is going to a lot much more expensive than using a battery as a buffer. If you are still interested in the capacitor solution you could do some research about the capacitor discharge process. The circuit on the other hand would be super easy, just connect it in parallel to your Pi. So if you really need only a few ms go with the biggest capacitor you can afford. There are so called goldcaps which are quite cheap, but their voltage is low (around 2.3V) so you would have to connect some of those in serial. Just remember that this will also decrease the total capacity! I found a 22F 2.3V gold cap for 5,70€ so with 3 of them you could drive a Pi with around 7F. After 140ms the voltage would have dropped to 4.95V, after 282ms you would still have 4.9V... I don't know about the smallest voltage to drive a Pi but 4.95V (1% drop) sounds kind of realistic to me.

I think you will have to test it by yourself because noone knows what you're up to. I'd still go with the battery, though.

Improve this answer
1
  • This is the information I was looking for, thanks. Unfortunately I was hoping it would be much cheaper. So, yeah, the battery seems to be the best option
    – schmop
    Sep 25, 2016 at 23:34
2

You should be thinking of your worst case scenario here something like:

  • User has just sent large amount of data and filled all RAM buffers, say 100MB
  • Pi has not started to write any of this to SD card yet

How long will it take to write this to the SD card?

Assuming a decent SD card at 8MB/s you are looking at 12 seconds, double this for OS shutdown and other hiccups and you are looking at trying to get ~30 seconds of power after the Pi has been unplugged.

You know your application better than I do so can model the data writing better, but sticking a cap on the Pi's power isn't going to help in this case I think

Improve this answer
11
  • 1
    The software only writes a few bytes every few seconds. My plan is not to do an OS shutdown, just to block all writes and wait
    – schmop
    Sep 23, 2016 at 21:02
  • 1
    Would be worth updating the question to explain this, as others have pointed out there are other issues to think about with the filesystem. Mounting the FS with the sync option will help you too
    – Tim Fletcher
    Sep 23, 2016 at 21:04
  • I updated the question to remove all considerations about the filesystem
    – schmop
    Sep 23, 2016 at 21:22
  • 1
    Popping my head up again: There is no means by which you can just choose to "block all writes and wait" on a hardware level. What your software does is interact with the operating system. You do not control the hardware. Period. The OS kernel controls the hardware. That is a defining characteristic of what an "OS kernel" is and how operating systems work. CS 101. To be more blunt, this hopelessly naive. Go ahead and pursue it, just keep in mind you were warned.
    – goldilocks ♦
    Sep 23, 2016 at 21:31
  • @goldilocks You may be right in an absolute sense but in practice can't you can optimize all the parameters of the problem (how much time the UPS affords, reducing as much as possible OS activity, spreading necessary writes in small packets...) and have something that works as intended? I find it hard to believe that a stripped down kernel that has been at rest would suddenly stutter for half a second when asked to write 16 bytes, especially if the fs is mounted with the sync option.
    – schmop
    Sep 23, 2016 at 21:58
-1

The system will be writing to the disk almost the entire time between the shutdown command and the time it actually halts.

This makes the time between issuing the shutdown command and the shutdown being completed possibly the most dangerous time to pull the power.

I suggest you don't just give it a few ms here but ensure that you have enough power to complete the shutdown.

If you are just dealing with a single computer, a rechargeable USB charger should work great and be pretty cheap. If you are deploying this, a small stack of cheap batteries should cover the occasional few seconds of power down for a few years (I've seen these stacks of batteries in bulk LED toys that cost $0.10/ea, so there must be a way to get a supply of them for a reasonable cost)

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.