Possible Uninterruptible power supply for Pine64's SBC's

[GreyLinux]

Hi all,

I'm not sure how much traction this idea will get, as I'm not sure how many people would benefit from it , but I was wondering if Pine64 would be willing to develop a Uninterruptible power supply for all their SBC's.

Maybe something similar to this for the Raspberry pi
It could include a shutdown script that is run should power switch to the backup module just incase that power outage is prolonged.

Unless users of pine64's SBC's have found another solution for the issue of power outages ?

Any thoughts of this idea ?

[CounterPillow]

Hi,

I think the simplest way to implement this without any monitoring would be to just hook up a 12V lead-acid battery in parallel with the input on e.g. ROCKPro64 or Quartz64 Model A. For the 5V boards this would need a DC-to-DC regulator as well.

For monitoring, a fuel gauge chip connected over I²C could be used. That way the battery could just show up as a battery like in a laptop to the kernel, and the regular userspace daemons for shutting down systems when battery is low could be used; no need for hacky scripts.

Speaking of Quartz64 Model A, there this isn't needed at all because the RK817 PMIC has battery charging functionality, a LiPo cell can be connected to the board and it'll just work if the driver posted to the mailing list is applied.

Personally I don't really have a use for this though because I can't even remember the last time I've had a power outage, it was probably a decade ago.

[GreyLinux]

Hi,

I think the simplest way to implement this without any monitoring would be to just hook up a 12V lead-acid battery in parallel with the input on e.g. ROCKPro64 or Quartz64 Model A. For the 5V boards this would need a DC-to-DC regulator as well.

For monitoring, a fuel gauge chip connected over I²C could be used. That way the battery could just show up as a battery like in a laptop to the kernel, and the regular userspace daemons for shutting down systems when battery is low could be used; no need for hacky scripts.

Speaking of Quartz64 Model A, there this isn't needed at all because the RK817 PMIC has battery charging functionality, a LiPo cell can be connected to the board and it'll just work if the driver posted to the mailing list is applied.

Personally I don't really have a use for this though because I can't even remember the last time I've had a power outage, it was probably a decade ago.

I like your thoughts about monitoring it didn't cross my mind to think of it like a laptop and get the userspace daemons to shut it down , makes complete sense.

Unfortunately where I live I probably have a dozen or so power cuts a year , not as bad as some but enough to give me worry about the possible SD card corruption.

I use a Rockpro64 as a server and a NAS , I know I should invest in a emmc , but I'm not sure of a distro that supports it fully yet.

[CounterPillow]

Unfortunately where I live I probably have a dozen or so power cuts a year , not as bad as some but enough to give me worry about the possible SD card corruption.

I use a Rockpro64 as a server and a NAS , I know I should invest in a emmc , but I'm not sure of a distro that supports it fully yet.

eMMC is supported by mainline kernels, so Debian/Armbian/Manjaro/etc. should work fine from eMMC. That won't prevent you from potentially getting filesystem corruption from power cuts though.

For immediate relief to your situation I think either an off-the-shelf UPS would do the trick, or a 12V lead-acid battery in parallel with the power input. This would keep the battery topped up while power is available, and if wall power gets removed, will automatically have the board powered from the battery. I'm no electrical engineer so I won't try to draw up a schematic, as I don't want to potentially spread a wrong circuit around.

For a more advanced solution, something like the TI BQ34110 might come in handy. It supports a wide range of battery chemistries, high capacities, high currents, and is designed for applications where the battery rarely gets discharged, like in UPSes. It communicates with the host through I²C, the only difficulty is that there is not yet a driver in Linux for this, but that can be remedied. The bigger issue is that this chip is currently unavailable due to supply issues, and won't be in stock until a year from now according to digikey.

So it'd be cool if we could find a comparable chip to the BQ34110. The BQ34Z110 looks promising, it only supports lead-acid but it is in stock. It also might actually have most of a driver already in drivers/power/supply/bq27xxx_battery_i2c.c. As for connecting the battery monitoring chip's I²C to the host board, something like Adafruit's STEMMA or SparkFun's QWIIC would be handy as a physical connector interface. That way people don't have to fiddle with individual jumper wires and PINE64 can just sell a STEMMA/QWIIC HAT for each board which is useful for things outside of the UPS.

[GreyLinux]

Unfortunately where I live I probably have a dozen or so power cuts a year , not as bad as some but enough to give me worry about the possible SD card corruption.

I use a Rockpro64 as a server and a NAS , I know I should invest in a emmc , but I'm not sure of a distro that supports it fully yet.

eMMC is supported by mainline kernels, so Debian/Armbian/Manjaro/etc. should work fine from eMMC. That won't prevent you from potentially getting filesystem corruption from power cuts though.

For immediate relief to your situation I think either an off-the-shelf UPS would do the trick, or a 12V lead-acid battery in parallel with the power input. This would keep the battery topped up while power is available, and if wall power gets removed, will automatically have the board powered from the battery. I'm no electrical engineer so I won't try to draw up a schematic, as I don't want to potentially spread a wrong circuit around.

For a more advanced solution, something like the TI BQ34110 might come in handy. It supports a wide range of battery chemistries, high capacities, high currents, and is designed for applications where the battery rarely gets discharged, like in UPSes. It communicates with the host through I²C, the only difficulty is that there is not yet a driver in Linux for this, but that can be remedied. The bigger issue is that this chip is currently unavailable due to supply issues, and won't be in stock until a year from now according to digikey.

So it'd be cool if we could find a comparable chip to the BQ34110. The BQ34Z110 looks promising, it only supports lead-acid but it is in stock. It also might actually have most of a driver already in drivers/power/supply/bq27xxx_battery_i2c.c. As for connecting the battery monitoring chip's I²C to the host board, something like Adafruit's STEMMA or SparkFun's QWIIC would be handy as a physical connector interface. That way people don't have to fiddle with individual jumper wires and PINE64 can just sell a STEMMA/QWIIC HAT for each board which is useful for things outside of the UPS.

Wow thats some incredible knowledge and could be a possible solution, I wonder if Pine64 would be interested in either developing the Hat you mention for each board or possibly a complete UPS solution. I had a quick look at the chips you linked, do you think the second one could work? it doesnt have the "integrated rarely discharged module" that the first one has, but as you said  the chip shortage is going to be a long term issue .
I will try and do some research about your temporary  solution regarding the 12V battery in parallel, hopefully I can post some finding back here.
Sorry I should have specified that of course emmc is supported in the linux kernel  but I believe the newer 5.x.x kernels have some issues with the emmc modules, Ive seen some mention of it on the Armbian forum. I use the SkiffOS distro currently and havent tried out a emmc module to see if it works.
I thought that Emmc modules were more resilient than SD cards when it comes to power outages and corruption but I guess memory storage and read/writes during a power outage still can lead to filesystem corruption.

[Arwen]

I have a 12v, 18 watt model for my fitlet miniature PC / server. It does not have remote monitoring, nor would it likely have enough power for a 3.5" disk in addition to a miniature PC / server. But, it does the job for me perfectly, and has done so for more than 4 years. Here is a link;
fit-Uptime UPS


Ideally, a small, smart UPS would have a USB 2.0 port for monitoring. Plus, some pass through USB 2.0 ports, (aka hub ports), that would be powered from the UPS at all times. (Meaning they don't take host power.) This would allow people to charge their smart phones and potentially a tablet during a power outage, if the UPS had extra juice.

One note about power loss detection. Even though my little "fit-Update" UPS does not supply any monitoring, my server can "ping" test something that is not protected by UPS. Thus, detect A.C. power loss and in theory, if A.C. power does not return within a pre-determed time frame, the server could shut it's self down.

[CounterPillow]

Ideally, a small, smart UPS would have a USB 2.0 port for monitoring. Plus, some pass through USB 2.0 ports, (aka hub ports), that would be powered from the UPS at all times. (Meaning they don't take host power.) This would allow people to charge their smart phones and potentially a tablet during a power outage, if the UPS had extra juice.

I think just directly using the I²C of the fuel gauge chip is the better solution if we're designing specifically for SBCs. They all have an I²C interface, and you'd still be able to charge your USB devices through the powered on SBC. Saves on cost since we wouldn't need an additional microcontroller, wouldn't need to write yet another driver for its USB interface, and makes this an easy solution to just hook up to every SBC you own. The only downsides I can see is that I²C doesn't do enumeration so you'd have to apply a device tree overlay (which is simple enough to do with mainline these days), and that you'd be charge limited to the 500mA or whatever the USB ports on the SBC output.

As for current it can provide, if we go for 12V with lead acid and no regulation (relying on the onboard PMIC of the SBCs to handle whatever voltage drop the battery can have) we can basically draw whatever the battery can take, which is a lot. (>100A typically it seems?) Though that might be a bad idea because of how quickly voltage will drop, and limits us to 12V batteries and 12V SBCs.

[GreyLinux]

I have a 12v, 18 watt model for my fitlet miniature PC / server. It does not have remote monitoring, nor would it likely have enough power for a 3.5" disk in addition to a miniature PC / server. But, it does the job for me perfectly, and has done so for more than 4 years. Here is a link;

fit-Uptime UPS

I couldnt get you link to work but I did find the UPS after a quick search  seems like a nice and small solution but I think @CounterPillow might be right a direct solution either with a hat module or a complete UPS solution that utilses I²C would be a better solution for most end users, especially to compete slightly with the raspberry pi solutions and more importantly because Pine64 are developing more SBC's that would benefit from it.

[Arwen]

I fixed the link.

[TRS-80]

If you decide to go the off-the-shelf route, you might want to choose one of devices supported by the Network UPS Tools (NUT) project.