Sailor Hat Adds Graceful Shutdown To Pis

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.

45 thoughts on “Sailor Hat Adds Graceful Shutdown To Pis

    1. 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.

      1. 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.

        1. 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.

          1. 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.

          2. 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.

  1. 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.

      1. 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…

        1. 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.

        2. 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.

    1. 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.

      1. 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.

      2. 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.

        1. 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.

    2. 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.

    3. 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).

  2. 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.

    1. 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.

      1. 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.

        1. 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.

  3. “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.

    1. 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.

  4. 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?

  5. 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.

  6. “…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.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.