Author Topic: Keeping the FPP alive during power off  (Read 260 times)

Offline algerdes

  • Supporting Member
  • ******
  • Join Date: Apr 2014
  • Location:
  • Posts: 516
  • Kudos: 4
Re: Keeping the FPP alive during power off
« Reply #15 on: April 18, 2017, 10:21:56 PM »
Would I would do is get a usb battery pack, it can/will be charged when power is on, will also keep it running on power loss/brownouts.

With the battery pack - the pi never looses power - just make sure you find one that will allow charging while the attached device is drawing power - amazon has a couple that I know of.

Just my 2 cents

Myk


I have put a lot of thought into this.  Your assertions are pretty much where I am thinking. 


1.  Get a battery pack with pass through charging.   
2.  Pick a time that in no way could have a show still running (say 10:45 PM since the latest the gate closes is 10 PM on Friday and Saturday and the longest anyone would ever stay would be 30 minutes). 
3.  Set a shutdown sequence to run at 10:45PM.  This will take the FPP offline for the evening.


 Even if the battery should die, effectively powering down the FPP, there shouldn't be any corruption. 


4.  Powering up the display the next day, usually 15-20 minutes before we open the gates, should bring the RPPs back online and ready to start at 5PM.


Thanks everyone for the ideas.   I appreciate "group think" so much, especially when my brain is mush.

Online Sawdust

  • Full Member
  • ***
  • Join Date: Nov 2015
  • Location:
  • Posts: 169
  • Kudos: -2
Re: Keeping the FPP alive during power off
« Reply #16 on: April 19, 2017, 01:28:18 PM »

You can!  FPP logging is not the only disk writing that happens.  The OS does its own logging even with FPP logging disabled (take a look as SYSLOG for example).  And there are other writes that can happen with FPP logging disabled.  Disabling FPP logging greatly reduces the amount of writing, but doesn't eliminate it.

Think about it.  What would be the purpose for any OS to have a SHUTDOWN command if it was going to cause more corruption than just killing power?  The whole purpose of having a SHUTDOWN command is to safely and cleanly shutdown, halt, and power-off the system.

Help me fully understand what you are telling me....I don't write in Linux very well, in fact, I do my best not write....been away from it too long.
You mentioned the OS does it's own logging, but isn't that the shutdown sequence.  Does it actually write/log during normal operation?  What may it write?
I thinking I don't want to use the shutdown script so I don't write in this process..

Comments please.

Offline Materdaddy

  • Moderator
  • *****
  • Join Date: Jul 2013
  • Location: Oceanside, CA
  • Posts: 2,029
  • Kudos: 8
    • Christmas On Quiet Hills
Re: Keeping the FPP alive during power off
« Reply #17 on: April 19, 2017, 07:51:01 PM »
Does it actually write/log during normal operation?  What may it write?
I thinking I don't want to use the shutdown script so I don't write in this process..

Yes, there are other services running all the time that log.  I think Chris will be able to rattle some off the top of his head based on the "read-only" script changes, but look in "/var/log" to see files being touched all the time.  It could be drivers (to dmesg/messages.log) login attempts (auth.log), and more.  We configure apache logs to go to the media device (USB drive), but there are still things that can/will write to the SD card during normal operation.

The way the read-only script moves logging to a ramdisk instead of the SD card.  The logs are lost after a reboot, but that's the price to pay to make the SD card last longer and not become corrupt when writing and power is pulled.

Offline bpos

  • Jr. Member
  • **
  • Join Date: Mar 2015
  • Location:
  • Posts: 50
  • Kudos: 1
Re: Keeping the FPP alive during power off
« Reply #18 on: Today at 12:48:33 AM »
This is an area I have been researching for quite a while now. I am down to 2 thoughts about what is happening. I am almost convinced its a hardware issue. Either its the SD card integrity or its the power supply. The reason I point at the SD card as one potential problem is obviously its the source of the problem. I have did hundreds of reloads to test the integrity of the SD and while it will take some rewriting hit over time they hold up fairly well depending on brand. I had the best luck with sandisk cards. (they do eventually corrupt from extensive use I have found) The next problem I kept running into was when I would mount the Pi next to the power supply (within perhaps 2 inches or so?) It kept corrupting the disk every time. The best I can figure is 2 things. Perhaps the EMFs are messing with the SD cards or that the power "supply" was winding up slowly and that might cause corruption? What I mean by that is, lets say that the Pi is plugged in, the power from certain 5vdc sources may be tied to the main power supply of perhaps 12vdc lets say. In some cases you can sponge off the control board that will perhaps have an onboard 5vdc power out. Or a 12vdc to 5vdc power converter? In these instances the power may come on slowly depending on how its bridge rectified and caps and such? So you might not get 5vdc instantly? May perhaps take a half second or less. But that may be enough of a hit for the SD card? This is all considering the 5vdc source is already plugged in to begin?

I have not pin pointed the exact problem but its narrowed down to one of these I think... 

I could be wrong but that's what I have seen thus far.


 

Back to top