Operating system in RAM

[Miss Sissy Princess]

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

You got a big grin out of me there!  Thanks so much for jumping in with such a detailed and thoughtful reply.

I really like your design choice of using an AVR CPU. I used them extensively professionally, including in a custom chassis that provided power monitoring and emergency, sequenced shutdown for a satellite under integration and test.  I did everything in AVR assembly language using a simple real time kernel and task scheduler that I wrote from scratch (trust issues with compilers and a need to exactly characterize interrupt and polling latency).  

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

Hence my earlier recommendation of the Samsung Pro Endurance series which, though marketed for video recording, seem ideal for boot drives in Pi-based systems.

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 : 

It would work for most Pi-based servers.  I've got my moOde music server, a PiAware ADS-B aircraft tracking server (part of the FlightAware network), and two Pi's serving as web servers (those are on a commercial sine wave UPS).  I don't care if they take a few minutes to reboot after power restoration since I probably would not even notice -- I'd much rather that happen than I find out a week later that, say, my PiAware server corrupted its MicroSD during a power outage and didn't come back online (I suspect that's what happened one time when I had to reflash).

I suppose you could "long-press" the button to force the device to power on even when the supercaps are not charged fully.

Makes sense since that's how many UPSs work when you want to turn the outputs back on before AC is restored or when batteries are too discharged to guarantee safe shutdown times.

---

I apologize if my ignorance prevented me from locating the Hypnic device schematic to which you referred.  Also sorry for asking questions here, but I am not a diyAudio member (by choice as it would suck away what little time I have left).

Your wrote "[d]epending on your power supply and the size of the supercaps, this may be a few minutes."  I'm assuming that you've got something like a current-limiting resistor between the supercaps and the power supply, so what is the worst-case current draw just for powering up the Hypnic, with nothing attached to it, when the supercaps are discharged?  

This is not what the UPS folks call "line interactive" and, instead, it always powering the Pi via the supercaps, which are continually being charged from the supply, correct?  If so does the 5V boost guarantee 5V even if the power supply input sags a bit under load?  That would be really sweet (I'm thinking inrush to spin up a hard drive).

Hypnic V2 wishlist:

Multi-color LED:  Maybe Green = input powered and caps charged, Yellow = Supercaps not fully charged, Red = Power-down signal sent.
Berg jumpers or dip switches to select features:  Power on SBC after 5V input restored, Wait until supercaps charged before powering SBC, etc.
Faster charging of supercaps when not concurrent with powering board
- or-
current limiting the input such that the power supply is taxed at 3A (or 2.5A) during supercap charging, whether concurrent or not.
High-current (2.5A? 3A?) supercap charge rate when not concurrent with SBC power, reducing the delay before start significantly.
USB B and C power input connectors, possible with differing current limits (2.5A and 3A) for charging of supercaps.

Please accept my apologies if this is just another TL;DR type of post.

P.S. Yes, I'd be cool with paying another few bucks for a version 2 with (some of) those features.

[gilphilbert]

Apologies for the delay, I have a newborn baby that has prevented sleep (and, therefore, brain power) since my last post!

I haven't characterized the power draw when the supercaps are charging (with no load) but doing so would be simple. It would be an interesting value to understand anyway. I'm currently sold out but as soon as I have some more here I'll check.

Very good question about sagging voltages - yes, there's a boost module that runs inline whether running from external power or the supercaps. This means a drop in the external power supply voltage is tolerated well - especially since the supercaps can provide the current required to keep the SBC running even when external power sags - for example when you turn on a power-hungry spinning disk.

Multi-color LED:  Maybe Green = input powered and caps charged, Yellow = Supercaps not fully charged, Red = Power-down signal sent.
Berg jumpers or dip switches to select features:  Power on SBC after 5V input restored, Wait until supercaps charged before powering SBC, etc.
Faster charging of supercaps when not concurrent with powering board
- or-
current limiting the input such that the power supply is taxed at 3A (or 2.5A) during supercap charging, whether concurrent or not.
High-current (2.5A? 3A?) supercap charge rate when not concurrent with SBC power, reducing the delay before start significantly.
USB B and C power input connectors, possible with differing current limits (2.5A and 3A) for charging of supercaps.

Love the wishlist. You're actually close to my Hypnic v2 prototype. I'm not using a multi-colored LED, mainly because this makes an external LED much more complicated, as well as needing additional connections on the Hypnic (and there just isn't space). However, we can achieve the same thing by putting on a dim light, or using a slow-blink to show we're waiting for charge before powering on and a faster blink during power down.

The options around charging the caps while the load is applied are interesting, but obviously you can't limit the load. This would have the effect of increasing the supercap charging times. There's currently 1W 10R current limiting resistor across the supercaps as well as an additional schottky diode in that power path; this has the effect of "preferring" the load over charging the supercaps.

I already have a USB-C connector for charging (as well as retaining the screw terminals) in the v2 proto. There's also a DIP switch with two switches on it, one is for autoboot (whether to power on as soon as power is restored, or to wait for a power button press). The second on was to support momentary as well as latching power switches, but it could be repurposed to support a "wait for power" mode instead. The v2 also supports 4.5A (up from 3.5A on the v1) and support for flashing firmware over the USB port.

[DRONE7]

Congratulations on the new family member ! I'm sure the lack of sleep is more than made up for in the joy of a precious new life   

The v2 also supports 4.5A (up from 3.5A on the v1) and support for flashing firmware over the USB port.

Add me to the list   I will buy another !
I have several Pi and places around the property to use them as well as gifting MoOde players to good friends and family. 
Your Hypnic makes this so much easier as I don't have to worry about remote support for power and card corruption.

Bob

[Miss Sissy Princess]

Apologies for the delay, I have a newborn baby that has prevented sleep (and, therefore, brain power) since my last post!

Congratulations!

Very good question about sagging voltages - yes, there's a boost module that runs inline whether running from external power or the supercaps. This means a drop in the external power supply voltage is tolerated well - especially since the supercaps can provide the current required to keep the SBC running even when external power sags - for example when you turn on a power-hungry spinning disk.

That is excellent as I'm sure that it will take some marginal power supplies into the more-than-adequate range.

Love the wishlist. You're actually close to my Hypnic v2 prototype. I'm not using a multi-colored LED, mainly because this makes an external LED much more complicated, as well as needing additional connections on the Hypnic (and there just isn't space). However, we can achieve the same thing by putting on a dim light, or using a slow-blink to show we're waiting for charge before powering on and a faster blink during power down.

Works for me!  BTW, I'd be happy with a surface mount multicolor LED; in fact, I'd prefer it.

The options around charging the caps while the load is applied are interesting, but obviously you can't limit the load. This would have the effect of increasing the supercap charging times. There's currently 1W 10R current limiting resistor across the supercaps as well as an additional schottky diode in that power path; this has the effect of "preferring" the load over charging the supercaps.

I know you can't limit the load, but I'd like to see Load + Supercap_Charging = Power_Supply_Max_Current at any time that the Supercaps are not fully charged.  Think how fast you could charge the caps if you sucked 5V/3A from the supply just to charge the supercaps PRIOR to powering on the SBC (when set to charge-before-powering SBC).  

I already have a USB-C connector for charging (as well as retaining the screw terminals) in the v2 proto. There's also a DIP switch with two switches on it, one is for autoboot (whether to power on as soon as power is restored, or to wait for a power button press). The second on was to support momentary as well as latching power switches, but it could be repurposed to support a "wait for power" mode instead. The v2 also supports 4.5A (up from 3.5A on the v1) and support for flashing firmware over the USB port.

That's all sounding excellent.  I would prefer a "charge caps fully before 'autoboot' " option as opposed to level/edge triggering on the power switch.  Flashing over USB is a game-changer, too.  I'm old, so I like dip switches.  I recognize Berg jumpers take less space, but more often, they were used just because they were cheaper.

You might also think about using a momentary power switch as a means of changing operational modes:   Maybe something along the lines of "hold the power button depressed and supply power to the board.  When the LED does a heartbeat style blink (short on, short off, short on, long off, repeat), release the power button.  Press the power button one time to set..."  I'm sure you get the idea.  Just something to think about.