A low-cost solid-state NAS with power-loss protection
Improvement on the dc-dc converter-based design, with a second MOSFET to drive the enable line.
asc - 6.81 kB - 12/01/2019 at 09:58
Version which uses a dc-dc switcher module (with ENable) instead a P-chan MOSFET.
asc - 5.91 kB - 11/15/2019 at 15:53
Updated to use actual MOSFETs I intend to use. The low gate voltages do make a difference to the choice of parts...
asc - 4.67 kB - 11/04/2019 at 15:52
Success at last.
The latest incarnation of the circuit seems to be much better: the signals to/from the Pi are now separated and behave themselves, and the dc-dc converter is definitely off (<1uA current) normally.
The 3 second delay prior to shutting down still isn't working, but maybe that's an OS problem that will eventually get fixed in some later update... For now, I think it's safe to use as a NAS will real data on it!
I've now got an 'ideal diode' module, so will try swapping it for the main Schottky so that the supply voltage doesn't bump up and down so much with load current.
I've found that with a screen plugged into the HDMI output, when pulling the power the RPi instantly reboots. Without a screen, the RPi correctly shuts down cleanly as intended by the gpio-shutdown overlay. No observable difference can be seen in the 'scope traces of the power supply for these two situations, so the rebooting is not being caused by my power management circuit, I don' think.
- why the heck should having an HDMI screen plugged in make any difference?!
...works and the Pi drives it from high to low after shut down. But
...with the pin as an input normally does not for some reason. The pin correctly turns into an input (apparently without the pull-up I was expecting it to have), but doesn't get driven low after the Pi has shut down. Instead the Pi instantly restarts without shutting down.
However, disconnecting my circuit, and pulling GPIO27 up to 3V3 with just a resistor does work. A low is seen just after (proper) shut down. I suspect somehow GPIO27 is triggering GPIO17 which is programmed to shut the Pi down!
Check the files for a v3 LTSpice circuit with an extra MOSFET switch. This isolates PGOOD from nSHDN to solve this problem, and also drives the ENable (to ensure the dc-dc module is properly off in normal use).
I ended up modding the mains power supply to produce ~5.5V instead of ~5.0V so that downstream of the Schottky the supply rail was about 5V. Now, when the main supply is pulled, the Pi no longer immediately restarts. Instead, it appears to initiate the shutdown as intended. There are still some problems though:
- the 'debounce' part of the dtoverlay doesn't seem to be working, as it begins shutting down immediately rather than after a couple of seconds
- the GPIO pin that is meant to drive low after shutting down doesn't appear to do anything, so the power never gets turned off
- in normal state, the dc-dc converter isn't quite fully off (the EN line is at about 1.3V) and seems to be sucking ~1mA instead of the ~0.2uA I get when EN is pulled to 0V properly. That will flatten the batteries in no time... [edit: EN needs to be less than about 0.9V for the standby current to be around 0.2uA]
Still more to be done then!
Just found this: https://www.raspberrypi.org/forums/viewtopic.php?t=50470
Kinda very relevant, but no mention of the Pi restarting at the instant the main and backup supplies switch over. Maybe earlier versions of the Pi don't have brownout resets?
Oh, and then there's this: https://thepihut.com/products/ups-pico?variant=20063191203902
...which I could just buy. :(
The RPi4 seems to use the MxL7704 PMIC, instead of the APX803 supervisory IC used in earlier versions. The 7704 does not have a brown-out reset line, so for my Pi to be resetting itself, something must be triggering that reset indirectly by monitoring the PGOOD lines. It's probably not helped by the supply already being low enough for the lightning bolt to be showing (<4.65V), likely due to the drop across the Schottky. I'll have to get the thing hooked up to a 'scope to see how big the glitch is. Adding 1000uF to the 5V rail did not cure it.
Last night I finally plugged everything in together for the first time. I had lots of problems getting the Pi to boot properly and produce an HDMI signal so I could actually see what was happening. Eventually I got it sorted, and was able to configure OpenMediaVault. Halfway through trying to set up the two disks as RAID1 I seemed to have more problems, and then stumbled across lots of stuff about RAID1 being effectively useless when used with USB disks (presumably due to the need to share the bus, rather than having independent controllers like SATA - IDK, I'm not an expert). I also thought a bit more about what I actually want the NAS to achieve, and maybe RAID isn't it.
So tonight I'll start again. This time I'm going to ignore RAID altogether, and set up a Main disk and a Backup disk, and use OMV to schedule automatic, incremental backups of one onto the other. So I kind of get the dual redundancy I wanted, as well as some protection against human error like accidentally deleting files.
Oh, ps. the fail-over power didn't quite work. Upon pulling the plug, the Pi instantly rebooted. But at least that means the batteries had taken over and were able to supply the power required. I guess the Pi's SoC has a brown-out detect that got triggered by some minute glitch. Something to fix later.
Rats. Just remembered RPi GPIO is not 5V tolerant, so will need a few extras to interface between it and my circuit...
The PGOOD line should just need a pair of resistors. The nSHDN line might be a bit trickier...
I've chosen to use GPIO17 and GPIO27 which are both pins with pull-downs by default, with a value of about 50k-60k ohms if the internet is to be believed. That means I only need another 30k-50k or so in parallel (i.e. external pull-down) in combination with the 10k series already in the circuit to ensure the voltage on these pins doesn't exceed 3v3.
After a couple more attempts I think I've got the fail-over power supply working, using the dc-dc switcher module. I had to modify the module in two ways:
- bring out the ENable line so I can control it
- remove the trimmer pot and replace with fixed value resistors to give ~5.5V out
- remove the 0.1uF cap on pin 8 so that the 'soft-start' feature is disabled. Without this the switcher takes ~15ms to come up, leaving a nasty gap as it takes over from the mains supply.
Had a play with possibly swapping out the main Schottky for a MOSFET, but it's tricky without resorting to a complete 'ideal diode' circuit (three transistors, two resistors). If it bugs me I might just buy an ideal diode module.
I built up the power loss protection circuit, made a few tweaks, and tried it with a very modest load (only 5ohms, i.e. 5W) and the poor AA batteries droop badly and cannot hold up anything like 4-4.5V. I'm getting more like 3.6V.
So maybe a change of tack? I have a little dc-dc converter based on the MP2307, which is supposedly good for 3A. It's hardwired to produce 5.0V at the moment, and therefore requires about 6.1V in. I'm thinking what I might do now is use a battery with more cells (possibly 6?) and the dc-dc converter. I can do away with the P-channel MOSFET since I can now use the enable line on the converter to shut off the power (leaving just 0.3uA standby current). I should now get much better supply regulation for the 10-20secs while the Pi shuts down and as the batteries droop.
I've bodged something together quickly on the bench, and it nearly works except that the TL431 cathode voltage doesn't rise fast enough to enable the dc-dc converter, before the rail supplying the TL431 falls and everything goes off. I could supply the TL431 direct from the battery, but that would flatten it in weeks.
Aaarg. Must stop finding problems to solve...
The solution was looking promising: RPi4 running OpenMediaVault coupled to a pair of SSD's in a RAID 1 configuration, like this YouTube video or similar. All the benefit of Gb Ethernet, USB3.0, SSD speed, and mirroring for robustness. Sweet. Total bill so far about £130.
Then I realised about power loss corrupting the RPi image, and worse, the SSDs - especially cheap ones like I'd chosen. Balls.
So what I need now is a battery 'hold-over' supply. Not quite a UPS (I don't need it to run for hours and there's no need for a rechargeable battery and all that), but just for the 10 secs or so for the RPi to shut down cleanly. And a mechanism to tell it to shut down. And a way to cut the power once it has shutdown so the batteries aren't run flat. Oh, and it must also come up again cleanly once the main power is restored. Phew - anything else?!
This forum post indicates that the Pi's supply should ideally be between 4.7V and 5.25V, at up to 2.5A, though 4.0 to 5.5V might work. The PMIC's abs. max. is 6V. The official datasheet for the Pi just says 5V.
After some inspiration, and a lot of simulation in LTSpice, I've come up with this:
The idea is the battery is normally disconnected from the load until the main supply drops below about 4.8V. When this happens, the TL413a goes hi-Z making the nPGOOD line go high. This simultaneously switches the PMOS on, applying battery power, and also notifies the RPi (via a GPIO) that the power has been lost. It can then set about shutting down cleanly. The last thing it must do is change the GPIO pin from input to output, and drive it low. This cuts the battery power, turning the RPi off completely. Upon restoration of the main supply, the whole thing pops back into life, and the RPi boots as normal.
Hope it works!
Follow the instructions in this excellent video which shows you how to install OMV on a Raspbian Buster Lite OS.
Probably best not to use the RPi4 image on the OMV website, as the folk on there point out that it's based on an unsupported Armbian OS.
Also, before plugging the microSD card in, write a blank file called "ssh" to the /boot folder, to enable ssh without needing a keyboard and screen plugged in. This saved me heaps of time!
Once OMV is installed, do all the updates, configure the disks/shares etc. according to the OMV documentation.
ssh in and edit /boot/config.txt using e.g. pico:
sudo pico boot/config.txt
...then add the following two lines to the end and save:
While you're at it, maybe consider commenting out some of the other unwanted stuff, like audio and 3D support.
In conjunction with the little circuit I described, PGOOD and nSHDN connected to pins GPIO17 and GPIO27 respectively you should be protected against power outages.
I had loads of problems with the NAS appearing and disappearing from remote connections (e.g. from Windows), pausing during audio/video playback, hanging, etc. It seems that the SSDs were not happy, and getting repeatedly reset. This article explains what to do in detail.
tl;dr version here:
Edit boot/cmdline.txt and add the following to the start of the line that's there:
...where aaaa and bbbb are the idVendor and idProduct codes for your SSD(s).