Operating system in RAM

[Miss Sissy Princess]

IME SD card failure is rare. I've maybe had 4 cards die in over 6 years. The cards in my test systems get completely slammed with writes during development and abrupt power offs happen often.

I have been using Samsung PRO Endurance 64GB MicroSDHC cards in my various Pi-based servers (including moOde).  These are "specifically designed for video monitoring cameras including dash cams, surveillance & security cams, body cams, etc." They claim continuous HD video recording longevity of up to 25x that of conventional MicroSDHC cards.  I researched MicroSDHC cards for many hours (I'm "buy-curious" so I research every purchase to the extreme).  Independent tests show these cards to have good R/W speed, and much more consistent speed, when compared with conventional MicroSDHC cards.  While Sandisk also offers a high endurance MicroSDXC card, it is definitely a step down based on warranty (5 years for Samsung vs. 2 years for Sandisk), reputation, and anecdotal reports of failures and longevity.

All of those characteristics make the Samsung PRO Endurance 64GB (or any size -- I just think that, right now, that's the sweet spot for price/storage) MicroSDXC cards nearly ideal for use as Pi boot drives, especially where there is concern about write-induced failures.  



Note:  I am not affiliated with Samsung or any vendor of Samsung products.  Links provided are for the convenience of the reader and "clicks" of, or purchases from, those links do not benefit me, monetarily or otherwise.

[lykkedk]

FWIW :: I use a different solution for this.

I power my preamp. + poweramp. from a Philips Hue smartplug & a dimmer switch.
The Raspberry with MoOde installed is also powered by such a smartplug.

Besides that i have another Pi running 24/7 as a server (Ubuntu)...

When i press "power off / off" on the Hue dimmer switch for my stereo   then smartplug connected to the preamp. + poweramp. goes off (this is controlled from Philips hue ecosystem / app. whatever)...

With a python script running on the server, it detects the preamp, poweramp switch goes off, the server sends a ssh poweroff to the MoOde which is still running. - When 30sec. has gone after that, the smartplug for the MoOde goes off.

Seem's a little complicated, but the Hue stuff is very stable and it's working eveery time as expected without a glitch!
And the Hue its also kindoff "opensource"

Just my 2cents...

Jesper.

[Miss Sissy Princess]

FWIW :: I use a different solution for this.

There are two concerns being addressed in this thread.  

One is unclean shutdowns, which your solution addresses.  

The other is limited write endurance for MicroSD cards which, unlike SSDs, do not employ any kind of "wear leveling" controllers.  My recommendation of the Samsung Pro Endurance series MicroSDXC cards was aimed at addressing that concern.

Ideally, one would address both concerns, maybe combining a clean shutdown solution like yours with a high-endurance card like I recommended.

[TookaFace]

If you dont want writings at all, configure your system, then use the Overlay feature in raspi-config (Menu -> Preferences -> Raspberry Pi Configuration -> Performance -> Overlay file system).

That way, all the writings will be in RAM, system will work normally, but all the changes will be lost after reboot (thats why you have to configure your system before). You can disable the feature, if you need to write/change something.

Last time i tried, it worked well with moOde.

[jmperagine]

I found this solution and am quite happy with it.

https://lowpowerlab.com/guide/atxraspi/?view=all

Works amazingly well.

[Miss Sissy Princess]

I found this solution and am quite happy with it.

https://lowpowerlab.com/guide/atxraspi/?view=all

Works amazingly well.

That's neat, but I'm not sure how that helps the Pi shutdown cleanly when there is a sudden loss of AC power such as described in the original post: "my moode box is powered on and off with the main switch of the power amplifier."  

Are you suggesting that he could add that and always try to remember to manually press the button, wait for the shutdown, and then turn off his power amplifier?

[jmperagine]

I found this solution and am quite happy with it.

https://lowpowerlab.com/guide/atxraspi/?view=all

Works amazingly well.

That's neat, but I'm not sure how that helps the Pi shutdown cleanly when there is a sudden loss of AC power such as described in the original post: "my moode box is powered on and off with the main switch of the power amplifier."  

Are you suggesting that he could add that and always try to remember to manually press the button, wait for the shutdown, and then turn off his power amplifier?

Precisely my dear Watson! However, I have taken it a step further, I have my Schiit plugged into a wifi power switch except the turntable and Raspberry Pi.  This way, you can never accidentally kill the power on the Pi, or the turntable.

[DRONE7]

Precisely my dear Watson! However, I have taken it a step further, I have my Schiit plugged into a wifi power switch except the turntable and Raspberry Pi.  This way, you can never accidentally kill the power on the Pi, or the turntable.

Unless, of course, there is a power outage from the supply network ;-) Something that happens quite often on our rural line.
That is the reason for having a UPS of some sort. We have a UPS on our server and a Hypnic supercapacitor power manager on the remote Pi player.

https://www.diyaudio.com/forums/pc-based...-sbcs.html

[Miss Sissy Princess]

Precisely my dear Watson! However, I have taken it a step further, I have my Schiit plugged into a wifi power switch except the turntable and Raspberry Pi.  This way, you can never accidentally kill the power on the Pi, or the turntable.

Unless, of course, there is a power outage from the supply network ;-) Something that happens quite often on our rural line.
That is the reason for having a UPS of some sort. We have a UPS on our server and a Hypnic supercapacitor power manager on the remote Pi player.

https://www.diyaudio.com/forums/pc-based...-sbcs.html

I agree with you.  If you want to avoid corruption of a drive (MicroSD in this case) you need to have some kind of graceful shutdown in the event of an AC power failure.  There are way too many ways to inadvertently lose power -- storm outage, utility work, someone accidentally trips on a cord or bumps a PDU switch, etc.

I may be purchasing one of the Hypnic devices since your posts brought it to my attention.  My sole complaint concerns sequencing or, more specifically, lack thereof; it doesn't charge its supercaps first and then apply power to the Pi.  As the designer wrote:

When the Hypnic has been off for some time, the supercapacitors will be "empty" and will need to charge - like a battery. This means that the current draw during initial charge will be higher than just running your Pi (and your Pi likely uses the most power while powering on).

Therein lies my concern.  I have a 500GB SATA SSD in an external enclosure hanging off of one of the USB ports.  I could be looking at a substantial inrush current to simultaneously charge the supercaps, power-up and boot the Pi 4, and power the SSD, perhaps exceeding the design limits of the power supply or causing too much of a voltage sag on the USB power cable.

I'm not one of those "try it and see if it works" types; too many things work initially only to fail later, or intermittently, because some design limit of a component or subassembly is exceeded.  If I order a Hypnic device, I'll have to capture inrush current of the entire chain (Hypnic, Pi 4, USB SSD, USB DAC) on my digital storage oscilloscope, starting with  completely discharged supercaps.  (I need to read the whole thread to see if the Hypnic device inrush current has been characterized).

P.S. I'm not sure why the OP is concerned about accidentally killing power to a turntable.  Perhaps he can chime in to explain the concern there.

[gilphilbert]

I agree with you.  If you want to avoid corruption of a drive (MicroSD in this case) you need to have some kind of graceful shutdown in the event of an AC power failure.  There are way too many ways to inadvertently lose power -- storm outage, utility work, someone accidentally trips on a cord or bumps a PDU switch, etc.

I may be purchasing one of the Hypnic devices since your posts brought it to my attention.  My sole complaint concerns sequencing or, more specifically, lack thereof; it doesn't charge its supercaps first and then apply power to the Pi.

You could always ask the designer, I hear he's pretty good about answering questions...

The Hypnic was designed specifically to address SD card corruption - kids pulling power cords, power outages, etc. - these are fairly common occurrences in my house! It won't protect against wear out, of course. For that you need a high-endurance card if you want to perform lots of writes to the SD card.

You've raised an interesting question around concurrency. The default firmware on the Hypnic will power the device and charge the supercaps at the same time - as soon as power is connected. This is the most common use-case and - as long as your power supply can supply enough current - it works faily well, even when loads are high. There are two downsides though: obviously it requires a larger power supply that provides more current, and your device is not fully protected until the supercaps are charged, so an outage within the first few minutes could lead to an ungraceful power down. I say could, as it depends on load, previous supercap charge levels, how long it takes for the SBC to power down, etc.

The Hypnic actually has all the hardware to charge the supercaps to a given level before powering on the device. There are downsides here too though, the biggest one being that you need to wait for the supercaps to be charged before you can power on the device. Depending on your power supply and the size of the supercaps, this may be a few minutes. For many applications, this may well be fine - but as a general rule of thumb, users expect devices to power on when they press the power button : I suppose you could "long-press" the button to force the device to power on even when the supercaps are not charged fully.

Writing firmware to make this work would be fairly trivial, I just haven't got to it yet (I have other features in the works and this hasn't been a top priority).