Plus there has been some rather harsh comments about it. Some like this one, seems reasonable. Now I am not saying they are wrong, but that Geekworm Raspberry Pi UPS Hat worked for me, much to my surprise.
It is quite well described here and I will not repeat the information. I originally had the idea of using a store-bought power bank for the very same purpose. I thought if I ran the power bank with the charger always connected and the raspberry Pi always drawing power, it should work like a cheap UPS. Not bad for an RM30 no-name 3000mAh power bank.
 |
| Power bank as UPS. Note the Qi receiver coil |
But sadly it did not work consistently. When the mains charger was powered off it ran from battery well enough. The problem was when the charger was switched on, it sometimes rebooted. Looks like the output power was not quite stable enough during the switchover. A common enough problem with regular UPS.
Now I can still use it as a UPS for systems that can tolerate a reboot. In some cases I simply put a little restart code in /etc/rc.local. And I can't really complain about the price. Do be careful of discarded lithium batteries though. They have been known to explode, or burn white-hot.
But a real UPS would switch over and back without a glitch. And it would be nice to have an indication of the battery state. The Geekworm UPS actually looked like (I am not sure; I did not check) it was adapted from a power bank circuit and it would be good so see where I fell short.
Having heard some comments about bad batteries, miswired batteries and faulty UPS boards, I checked both the battery output and the polarity before I hooked it up. It all checked out and powered on a Raspberry Pi 3 Model B+ quite nicely while still on charge.
 |
| Geekworm UPS Hat installed |
The extremely brief 'manual' (http://raspberrypiwiki.com/File:UserManual.pdf) called for installation of a driver:
User Guide:
1. Upgrade software:
sudo apt-get update
sudo apt-get upgrade
2. Enable the I2C function via raspi-config tool.
3. Install wiringPi .
git clone git://git.drogon.net/wiringPi
cd wiringPi
git pull origin
cd wiringPi
./build
4. Download the zip package;?rpi-ups-hat.zip?
unzip rpi-ups-hat.zip
cd rpi-ups-hat
5. Run the tested program
sudo python example.py
But there is also a C program, which I reproduce in full here:
$cat main.c
#include <unistd.h> // close read write
#include <stdio.h> // printf
#include <fcntl.h> // open
#include <linux/i2c-dev.h>
#include <sys/ioctl.h>
#include <getopt.h>
#define VREG 2
#define CREG 4
#define BUFSIZE 16
#define DEV "/dev/i2c-1"
#define ADRS 0x36
static int readReg(int busfd, __uint16_t reg, unsigned char *buf, int bufsize)
{
unsigned char reg_buf[2];
reg_buf[0] = (reg >> 0) & 0xFF;
reg_buf[1] = (reg >> 8) & 0xFF;
int ret = write(busfd, reg_buf, 2);
if (ret < 0) {
printf("Write failed trying to read reg: %04x (0x%02x 0x%02x)\n", reg, r
eg_buf[0], reg_buf[1], reg);
return ret;
}
return read(busfd, buf, bufsize);
}
int main(int argc, char **argv)
{
int vOpt = 0, cOpt = 0, o;
while ((o = getopt (argc, argv, "vc")) != -1) {
switch (o)
{
case 'v':
vOpt = 1;
break;
case 'c':
cOpt = 1;
break;
}
}
int bus = 1;
unsigned char buf[BUFSIZE] = {0};
int busfd;
if ((busfd = open(DEV, O_RDWR)) < 0) {
printf("can't open %s (running as root?)\n",DEV);
return(-1);
}
int ret = ioctl(busfd, I2C_SLAVE, ADRS);
if (ret < 0)
printf("i2c device initialisation failed\n");
if (ret < 0) return(-1);
readReg(busfd, VREG, buf, 2);
int hi,lo;
hi = buf[0];
lo = buf[1];
int v = (hi << 8)+lo;
if (vOpt) {
printf("%fV ",(((float)v)* 78.125 / 1000000.0));
}
readReg(busfd, CREG, buf, 2);
hi = buf[0];
lo = buf[1];
v = (hi << 8)+lo;
if (!cOpt && !vOpt) {
printf("%i",(int)(((float)v) / 256.0));
}
if (cOpt) {
printf("%f%%",(((float)v) / 256.0));
}
printf("\n");
close(busfd);
return 0;
}
sudo apt-get update
sudo apt-get upgrade
And used raspi-config to turn on i2c. As soon as I did that an i2c device came up:
# ls -l /dev/i2*
crw-rw---- 1 root i2c 89, 1 Apr 30 20:28 /dev/i2c-1
A quick scan of the C program main.c showed that that was all it needed to run. So, I skipped all the other steps and went straight to:
# gcc main.c -o ups_read
And it runs:
# ./ups_read
97
When I disconnected the charger and ran on battery it actually reads a little higher:
# ./ups_read
98
But it quickly starts to show a correct, discharging trend:
# ./ups_read
97
I ran it for some 6 minutes at pretty much full power and it went to 83%:
# date;./ups_read
Thu Apr 30 20:46:49 +08 2020
83
# date;./ups_read
Thu Apr 30 20:47:27 +08 2020
82
And yes, it charges:
# date;./ups_read
Thu Apr 30 20:47:49 +08 2020
83
# ./ups_read -vc
4.161250V 96.550781%
And that was all it took. Raspberry Pi UPS Hat on the cheap.
Happy Trails.
[Update 2020-05-06]
Managed to reproduce some of the problems mentioned above by increasing the current drawn from the UPS. Decreasing the UPS input power did not affect it much, except it increased the charging time. But, if I increased the UPS load too much (by loading up the Pi USB ports with for example a WiFi dongle at full power), a switchover from mains to battery supply now caused the Pi 1 to reset. And on reboot, the Geekworm UPS often failed to charge unless the load is power-cycled.
600mA peak current draw from the Geekworm UPS Hat was enough to trigger the problems mentioned. A 510mA peak draw was more or less OK for trouble-free operation. Treat the numbers as a guide: I only used a USB Charge Doctor to measure the peak current consumption. This almost guarantees an incorrect reading. An oscilloscope would be a better choice.
The 4 LED do not accurately reflect the battery state of charge. The I2C value read by ups_read is much more accurate.
No comments:
Post a Comment