Even though Windows and other operating systems constantly remind us to properly eject storage devices before removing them, plenty of people won’t heed those warnings until they finally corrupt a drive and cause all kinds of data loss and other catastrophes. It’s not just USB jump drives that can get corrupted, though. Any storage medium can become unusable if certain actions are being taken when the power is suddenly removed. That includes the SD cards on Raspberry Pis, too, and if your power isn’t reliable you might consider this hat to ensure they shut down properly during power losses.
The Raspberry Pi hat is centered around a series of supercapacitors which provide power for the Pi temporarily. The hat also communicates with the Pi to let it know there is a loss of power, so that the Pi can automatically shut itself down in that situation to prevent corrupting the memory card. The hat is more than just a set of backup capacitors, though. The device is capable of taking input power from a wide range of sources and filtering it for the power requirements of the Pi, especially in applications like boats and passenger vehicles where the input power might be somewhat noisy. There’s an optocoupled CAN bus interface as well for those looking to use this for automotive applications.
The entire project is also available on the project’s GitHub page for those wishing to build their own. Some sort of power backup is a good idea for any computer, though, not just Raspberry Pis. We’ve seen uninterruptible power supplies (UPS) with enough power to run an entire house including its computers, to smaller ones that’ll just keep your Internet online during a power outage.
” especially in applications like boats and passenger vehicles… ” PI’s are commercial temp rated. So good luck putting a PI in those types of applications.
So, if you want to use it, then install it in the passenger cabin, not in the engine compartment.
Even vcommercial automotive electronics differentiate between several locations in the vehicle abd their temperature extremes.
I have no horse in this race, but your remark prompted me to reflect on the prolonged 115 F temps we had last summer…and that was ambient temp. The interior temp of a car parked under those conditions in a driveway or lot are much, much higher. That would include presumably “cool” mounting locations like under a seat or beneath the console.
Mike’ point, at least in Arizona, is worthy of consideration.
I own a Nissan which whined on multiple occasions this summer about the in-cabin temperature being too high. I believe it shut down the blind spot monitoring. Not sure if it affected anything else. It showed off-line until the A/C had cooled the cabin and the vehicle was re-started.
My Toyota, under the same conditions never complained, but it doesn’t have blind spot monitoring. The radar for adaptive cruise and camera for lane departure detection, speed limit sign reading, spying on the driving public, or whatever else it does, seemed happy enough to keep working.
In our temps, we’re lucky the cars don’t melt.
The Toyota 4-Runner I once had would put the AC in Recirculate mode when the interior temp was very hot. I learned to quickly put it into outside air mode once the engine started.
To the Toyota engineer(?) who thought that was a great idea: it only prolonged the time for the interior to cool down and required the AC to work harder.
Since an RPi would usually only run while the car is running, likelihood is higher that the device would be active while the air con is on. There’s that initial hot period yes, but it’s brief.
Hailing from sunny Florida.
I’m sure everyone read the datasheet completely before installing a raspberry pi into their project.
And as always, have backups of your microSD anyway, because they have a habit of dying. My PiHole’s card died over the weekend, I’m not sure if something was writing to the card which shouldn’t have been or what, and it is a bit too late to find out now, but one dead card and one 5-minute re-image to a new card later and everything was working again. A lesson learned from the last time a card died and I had no backup.
I can see the appeal of small, ubiquitous, cheap, “good enough” storage in microSDs, but I won’t miss them when they’re eventually replaced by whatever comes next.
For what its worth I’ve had good luck with the SanDisk ‘industrial’ series cards. As well as the Samsung Endurance cards.
Good to know, I looked at those while waiting for the image to burn but wasn’t sure how much of it was just marketing. I don’t know the relative merits of using those vs a USB device, I need to look into that. But the endurance cards sound easy…
Slightly different application, but I have one of the SanDisk Endurance cards in my dashcam. It has lasted about four years now, while I was killing the random spare cards I initially used in a couple of months. They’re definitely a lot hardier.
Another option: Read-only mode via overlay filesystem. All disk writes go to a RAM disk and get lost if the system shuts down. This prevents corruption because interrupted writes are usually how corruption occurs. There’s a way to toggle into write mode for updates but general operation it’s read-only.
https://learn.adafruit.com/read-only-raspberry-pi/overview
I had a SanDisk card die in a Pi after maybe a day of use. I returned it for warranty replacement, and SanDisk complained that they didn’t cover or recommend using the cards in a Pi. They claimed that I needed their “harsh duty” or whatever card. I can’t remember if they sent me one of those (they did replace the one I sent back, despite whining) or I bought one, but I have it and we shall see.
My RPI-4 Pi-Hole (and also for other services) box uses a USB 3.0 500GB Samsung T5 which ups the reliability a lot. No SD card to worry about. Also plugged into a UPS for those occasional power bumps.
Yeah, that is something I meant to do originally but just haven’t gotten around to. Now that I have a home NAS up I might even be able to network boot it, but I need to read into that more first.
As the saying goes, there’s nothing more permanent than a temporary solution.
My home File Server tower (basically used like a NAS) and general purpose Desktop are also plugged into the same UPS. So all go down or reboot only when I ‘want’ them to. I’ve also added another UPS for my R&D workstation as well. Believer is UPSs for desktops and servers. Relatively cheap insurance. My Pico based projects seem to to handle power problems better than the RPIs.
On that note I’ve replaced most of my automation project RPI Zero Ws with Pico Ws for the ‘reliability’ aspect. Simpler to maintain too. Software is stored in flash, and the program source on the home server. No worry about maintaining or backing up a whole Linux OS for a restore when a disk goes bad. I am ‘liking’ it.
Forgot to add I like the above hat as it will give the computer time to shut itself down when a UPS isn’t practical.
Be careful what sd cards you use. I used the green Samsung EVO Selects for a while and ran into nothing but problems. 25% chance of bricking the FS even with a proper shutdown. multiple pi’s, multiple cards, multiple stores. switching up to the nicer red EVOs and higher solved my problems. I suspect there’s issues with the caching on lower-end cards.
SD cards (and USB keys) need a stable 5V voltage to operate correctly, e.g. when writing data to flash media. When Raspberry Pis are under load or when some periphery is sucking power from it, Raspberries can’t maintain stable 5 volts to SD cards … which may result in dead SD cards and lost data.
In my experience, quality of power on the RPi (including the type and amount of other devices hanging off from RPi) were a better predictor of when SD cards fail, than the brand and model of the card.
A power supply like the above might help a lot in such situations (provided that it can feed some amps to Pi).
Mouting a partition read-write on an embedded device is – in my opinion – heresy.
Here what i do my *Pi and other ARM SBCs:
– the whole base filesystem is one compressed archive that is loaded to RAM at boot
– any complementary applications are also archives, mounted as loopback with overlayfs
– any config or user-specific data are also in an archive, living in tmpfs.
– any runtime changes to the user data are synched back to the archive on demand
… and I use small, industrial-grade Micro-SD cards, and none failed me.
Those are of course excellent practices, but if you have, say, a data acquisition system the writes data to InfluxDB or Timescale, you need to have a writable filesystem. And many special-purpose systems such as Klipper 3D printer firmware require writable file systems and benefit greatly if the users can just flick the power switch to turn the thing off. Especially in a shared environment where misuse is nothing but guaranteed.
Yeah I agree, RO filesystems can’t always be used. For my Klipper, OpenWRT, and Zigbee Pi’s I’m using a PoE+ Hat as my POE switch in the garage is connected to a UPS – Any devices that require backup power are using a PoE injector (such as the fibre ONT) which make’s it easier when they are situated all over the house.
There’s now a read-only overlay option, far simpler:
https://learn.adafruit.com/read-only-raspberry-pi/overview
There’s nothing preventing you from having a read-only system partition and read-write data partition.
Exactly! Repartition the card, and do your O/S stuff on the RO partition.
This is also good for security.
If you need lots of RW area, maybe you should put that on a USB drive instead, so the thing can still boot, and then has a fighting chance of mending or reformatting the RW area.
I wonder how that lead-acid ups whole home backup is doing these days since that was 3 years ago.
NIce !
please add solar panel and … clock.
for example my raspberry pi harvest data, solar panel get power in day but I need send data in night.
It does have a real-time clock integrated, actually! And the firmware supports timed restarts. But powering from the solar panel would need a charge controller and a proper battery in addition to the SH-RPi.
“Even though Windows and other operating systems constantly remind us to properly eject storage devices before removing them, plenty of people won’t heed those warnings until they finally corrupt a drive and cause all kinds of data loss and other catastrophes.”
That hasn’t been the case for quite sometime.
The more accurate statement would be that the probability of that happening has been greatly reduced in software. However, there are still critical moments in the life of many storage devices. Especially those that have their firmware designed and written in places that tend to not bother with too much extensive testing, and just ship stuff once it seems to work.
What is the runtime of this at 1A, 2A, and 3A?
I did a rough calculation, but got a fraction of a minute for each power draw (assuming the hat itself has insignificant draw). Did I make a mistake? Or, is there a high probability this will not provide enough power to shutdown the SBC?
Hi, I’m the designer of this thing. The runtime is not an issue. On a Pi 4B or a CM4 with no additional hardware, the supercaps can keep the Pi running for a good minute or so. And given that a Pi will shutdown in a few seconds, there’s enough headroom for any practical add-on hardware. See this video for a demonstration: https://youtu.be/r5SamxvuIsk
The github’s readme.md states it uses a 2.7v 60F supercap, and states how long it is expected to give the Raspberry Pi 4 to shut down.
Oh, that’s actually obsolete. The current version uses 3x20F 3V caps in series. The available energy is roughly the same, or maybe a bit more than in version 1.
> The entire project is also available on the project’s GitHub page for those wishing to build their own.
Currently it looks like their repo’s main branch may be an older rev, there’s a v2.0.0 branch: https://github.com/hatlabs/SH-RPi-hardware/tree/v2.0.0
You can also purchase one from https://shop.hatlabs.fi/products/sh-rpi
Seems like the hardware repo wasn’t up to date – even the v2.0.0 branch was quite old. I’ve now pushed the current version design files to the repo.
I do not have a “pis” which is in need of being gracefully shut down,
This is the third time I’ve scanned through your offerings, and I finally stopped to read the article because it finallyoccurred to me what you tried to convey by, and why I might want to gracefully shut down my, “pis”.
A modicum of variety in the fonts available to you would work wonders on your (IN)ability to generate readable, understandable headlines.
Try it; you’ll like it…as will all your readers.
https://www.thevintagenews.com/wp-content/uploads/sites/65/2017/12/k2bnrpmg-640×360.jpg
I was just building an UPS with LiIon battery to be used with PI and Arduino in our RV car and boat.
Got to write something to sense the voltage drop.
Reminds me of the rather simpler design I created for my Cheap-O-NAS project: https://hackaday.io/project/168286-cheap-o-nas
“…available on the project’s GitHub page for those wishing to build their own.”
That’s great! I’m all for having the opportunity to do that. But just in case someone doesn’t want to build that particular part of their next Pi project themselves I’ll share this.
https://juice4halt.com/
Sure, the Sailor Hat for Raspberry Pi is open source and open hardware, but it’s also available as a pre-packaged product from the Hat Labs store! Why would you suggest otherwise?
Oh. Sorry, didn’t look far enough.
No worries!