Close

UPS4041-LG2 Results

A project log for Single SuperCapacitor UPS for Raspberry Pi

A last gasp Uninterruptible Power Supply for any Raspberry Pi computer.

bud-bennettBud Bennett 11/12/2018 at 01:130 Comments

I received the second pass PCBs on 11/7/2018. I was busy, so I did not populate one of the boards until 11/9. I had second (third?) thoughts about a couple of items so I increased C9 from 10µF to 22µF to reduce the impedance at the output and hopefully reduce the ripple voltage at the output; and I increased C2 to 220nF to increase the minimum backup time to 500ms, having some concerns about how the power-fail comparator was going to function with the AC adapter. Here's the newly populated board:

My initial testing was limited to a power supply input and a resistive load -- I found out quickly that bench testing doesn't equate to the real thing. But on the bench the UPS appeared to be fully functional.

Measured Bench Parameters:

(All of these parameters measured with single 400F supercap. )

Full Charge VSCAP voltage = 2.67V (design target = 2.68V)

Charge Current = 1.075A (measured assuming 400F ±10% supercap: time to charge from 2.5V to 2.6V = 37.2 sec.) Design target = 1A.

Backup Voltage = 4.77V with 4Ω load resistor (design target = 4.8V)

Input Power Fail threshold = 4.75V (same as design target).

Power Off time out period, after 20 second one-shot interval = 8.3 second (design target = 5-10 sec.)

Anecdotal Data:

With a 2Ω load the output voltage during backup did not reach 4.8V. The output voltage dropped from 4.95V to 4.64V immediately after the input power was cut and descended below 4.5V within a few seconds. Clearly this circuit was not going to provide a 2.5A load during backup with a single supercap. The LTC4041 data sheet confirms it with this plot:

I wanted to determine if the circuit could manage two sequential power failure events. With a 4Ω load resistor the circuit maintained 4.77V at the output after 2 sequential power failures (30 second duration with a 4Ω load). The final voltage at SCAP was 2.19V.

Bench Testing Waveforms:

Here's a trace of the output voltage and PWRGOOD signal when the power was cut to the adapter (RL = 4Ω):

The initial voltage was 5.15V -- so the output voltage dropped to about 4.6V before the boost converter took action. A short glitch below the specified operating voltage of the Raspberry Pi doesn't appear to be a problem (in my experience). 

In the above waveform there doesn't appear to be any indication of a power failure on the PWRGOOD signal (channel #2). If we expand the timeline it becomes clearer:

The PWRGOOD signal drops for only a few µs because the backup system takes over and removes the load from the input. Once the power-fail comparator has tripped the LTC4041 keeps the system in backup mode for a time period set by the capacitor on the CPF pin, C2. With C2 = 220nF this period is approximately 500ms. This is to allow the input voltage to relax to a low level and avoid potential oscillations. After this initial short glitch the PWRGOOD signal doesn't fall again until much later:

As it turns out 500ms wasn't long enough. When the AC power fails the AC adapter stops operating with the effect that the input just becomes a high impedance with a large capacitor. Without any load the input capacitor takes a long time to discharge  and so the power-fail comparator can be fooled into thinking that there is still a power source at the input. The fix is to place a resistor at the input to discharge the input capacitance to a level below the power-fail comparator trip point before the 500ms minimum backup period expires. A 1kΩ resistor does the trick. I should have known to do this since the first discrete version of this UPS included this resistor -- but that circuit had the benefit of simulation using LTSpice.

Real World Testing:

Not wanting to destroy my more expensive Raspberry Pi units I chose a Raspberry Pi Zero-W for testing. Using a 400F supercap for the Zero-W is overkill. I had to wait 250 seconds for the supercap voltage to drop below 2.5V while in backup mode. This equates to a current draw by the Zero-W of only 300mA.

I was gratified when the Zero-W powered up and booted. But when I disconnected the AC adapter the UPS provided power but did not indicate a power failure on PWRGOOD. It took a while before I figured out that the load at the input was too light and I added the necessary 1k resistor to the input terminals. After that, the UPS provided backup power, the PWRGOOD indicator worked, and the Zero-W did not show any signs of distress as I connected and disconnected the AC adapter. 

My next test was to manually shutdown the Zero-W and then manually assert the SHUTDN signal to the UPS. When I reconnected the AC adapter the Zero-W did not boot. I measured 1.2V at the UPS output. It was stuck in some weird mode and did not recover when input power was applied. The problem turned out to be too light of a load at the output. I noticed that the output voltage would drop relatively quickly to below 2V, but then just drift downward for a very long time. I think that this was interfering with the POR circuitry on the one-shot and DFF. I added another 1k resistor at the UPS output and this problem went away. The UPS would now properly time out the backup interval, shutdown the output, and properly  re-apply the power when the AC adapter was reconnected.

At this point I modified the powerfail.py program and launched it. There were a few glitches with respect to initializing the GPIO properly but after that was fixed it appeared to run properly...for a while. When I turned on my soldering iron, situated nearby, the Zero-W crashed about 20 seconds later. There was something causing the SHUTDN input to trigger the one-shot when the solder iron was turned on. My first thought was to use shielded cable to connect the SHUTDN signal to the UPS, but eventually settled upon an R-C filter to fix whatever was causing the one-shot to trigger.

Now the UPS is functioning properly and not susceptible to any outside interference. Here's the final schematic:

The newly added components are R18, R19, R20 and C11. I added the new components to the existing PCB: R18 was easy -- just scratched some of the solder mask away and soldered the new 0603 resistor in place, R19 was a through-hole 1/4W carbon resistor between the OUT+ and OUT- terminals, C11 is an 0805 cap wedged between the SHUTDN terminal and GND at C7. I decided to just put R20 in series with the wire from the Raspberry Pi to the SHUTDN terminal block. Needless to say the board is not as pretty now.

Ready for Deployment:

My target application uses an original Raspberry Pi Model B, which doesn't consume much more current than the Zero-W. It doesn't need a 400F supercap and I don't need it to ride through a power disruption. So I changed out the 400F for a 100F supercap that I got from eBay, and connected the UPS to the Pi Model B.

The 100F supercap fully charges from zero volts in less than 5 minutes. 

I changed the parameters of the powerfail.py program to allow the power to be absent for 10 seconds before initiating the shutdown procedure. This gives a total time of 30 seconds for the UPS to provide power to the Pi. I monitored the SCAP voltage while I disconnected the AC adapter. The ESR of this 100F supercap is a LOT higher than the 400F that I got from Digikey since the voltage on SCAP dropped about 50mV immediately. The voltage on SCAP after the UPS turned off the power to the Pi was 2.38V. So far so good.

I then plugged the AC adapter in, waited a few seconds, and unplugged it to see how the UPS would ride through a glitching AC source (we get that quite a bit out here in rural Colorado). The powerfail service detected the loss of power as soon as the service started and then safely shutdown the Pi before the Xwindow GUI loaded. The voltage on SCAP after the second power failure was 1.9V.

Summary:

It's ready for prime time. I just need to clean up the code in powerfail.py and install the UPS into the heating control system running in the garage. I'll post the new code when it's finished. 

I probably won't build another PCB with the updated components, but I did modify the PCB layout with the changes. I'll post the latest schematic, BOM and Gerber files for the PCB layout to the files section of this project when I get the time. 

Discussions