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.

schmop
  • 179
  • 1
  • 8
  • 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 '16 at 19:02
  • @ShreyasMurali That's why I'm looking for a proper schematic. I do need to be able to write to the SD card frequently – schmop Sep 23 '16 at 19:06
  • 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 '16 at 19:20
  • @goldilocks I don't understand what you are saying. Some ms is enough to finish an ongoing write (I write a few bytes every few seconds) and ensure that no new writes are made. Are you saying SD card corruption could still occur? – schmop Sep 23 '16 at 19:29
  • 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 '16 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 '16 at 19:49
  • 1
    here's a post dealing with options for UPS – Shreyas Murali Sep 23 '16 at 22:02

3 Answers3

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.

Domme
  • 375
  • 2
  • 11
  • 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 '16 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

Tim Fletcher
  • 131
  • 4
  • 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 '16 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 '16 at 21:04
  • I updated the question to remove all considerations about the filesystem – schmop Sep 23 '16 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 '16 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 '16 at 21:58
  • I'm not saying it will never work (although it will be hard to tell whether it mattered or not, because in practice most unclean shutdowns don't actually lead to data corruption -- the point is snake eyes and you lose, but most of the time you won't). I'm saying you can't do this in a consistent way. Could you statistically diminish the chances of corruption? Sure, but again they aren't all that high anyway. So maybe you go from a 2% average risk to a 1% average risk... – goldilocks Sep 23 '16 at 22:33
  • ...One of the problems is you haven't indicated a plan for detecting when a power cut occurs; the pi doesn't have any circuitry for that, so you have to add that too, and use, e.g., a GPIO trigger. Handling that is going to be on the scale of scores or hundreds of milliseconds, waiting for synced writes to complete within that context may be the same thing again, then you cross your fingers the system isn't doing anything else that involves SD I/O... – goldilocks Sep 23 '16 at 22:34
  • ...In the end, in theory maybe you have a curve with time required on one axis and the statistical adjustment to the chance of corruption on the other, e.g., at 5 milliseconds, 0% difference, at 500 ms, 80% difference. But you will never eliminate the risk in the same sense as doing a normal shutdown, meaning you now have to do a lot of zany stuff for what? To save $30 on a UPS?? And please don't say the motive is because you plan to incorporate this at scale into a device you are going to market! That is the kind of bad design hack that someone will catch onto and it won't be appreciated. – goldilocks Sep 23 '16 at 22:34
  • @goldilocks So you're saying I should just extend the delay to a few seconds and I'm good to go :) Sigh.... Maybe you're right but it's still something I would like to try. But I can't find anything anyways so I might just spend the $30 – schmop Sep 23 '16 at 23:41
  • Unless there's a lot of stuff going on, a proper shutdown should only take 2-5 seconds, so if you can come up with something that will A) Give you 30 seconds for lots of headroom, and B) Allow you to detect when that time starts, then you can just do that. My basic point is trying to shave that to nearly nothing, especially by circumventing an actual shutdown, isn't a worthwhile pursuit. I dunno enough about capacitors to say how viable that would be (I guess it must, if the capacitor is big). – goldilocks Sep 23 '16 at 23:53
  • @goldilocks: to be fair, CS344 is "Operating Systems 1" and CS444 is "Operating Systems 2" at Oregon State University. We didn't deal with kernel level stuff until CS444. – Jacobm001 Sep 24 '16 at 02:21
-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)

Bill K
  • 281
  • 1
  • 2
  • 8