UPS Discharging when it stills has input

Hey,
We have a weird issue across multiple UPS hats where even when the system has input voltage, it randomly swaps to discharging - before eventually going flat and switching off.

On the dashboard graphs you can see the input voltage is still 12 - 13V as expected

I am having the same problem. It seems like the HAT firmware is not switching to the input even though its sensors show that the input voltage and current are sufficient. In fact, I have one right now that seems to be load sharing between the input and the battery. The only way I can make the HAT switch from battery to input is to yank the battery. I’ve tried everything to make this work and nothing helps. It seems like a hardware problem as I have two other systems deployed using this same firmware with no issues. And I have been trying without success to get help from Sixfab but it seems there is no listening.

I’m reposting my emails to their tech support here in the hopes it helps.


This is a follow up to more community post here: UPS HAT is always showing 'on adapter' even when it's not and no battery power or current information

I received no reply and so I have replaced the UPS HAT with a new one and now I am seeing a different set of issues. The HAT always reports that it is on battery, even if I disconnect the battery. Right now I have it connected and running with a battery that reports 1% charge status. I’ve removed the software, reinstalled it, deleted the device, re-added it and nothing helps.

The battery was fully charged per the instructions on the website and now I am powering the system from the J4 connector. The result was the same when using the USB-C power connector as well.

Firmware is: 0.3.22 and software version is: 0.4.2

Power supply is 12VDC 45Ah battery with solar charging circuit. The solar storage battery is fully charged and floating at 14 VDC. Even the HAT sees this but remains in a battery discharge state.

Please help me. I have already deployed two remote systems using this HAT with no issues. I need to deploy this one early next week and am running out of time to resolve this issue.

image.png

image.png


Hello again,

I hope that you can help me soon. I am running short of time to get this system ready for deployment. Since my last email I have attempted the following in an effort to make this HAT work correctly.

  • Replaced HAT entirely (I mentioned this in yesterday’s email).
  • Swapped battery from 10Ah flat lipo to 3.5 Ah 18560 lipo.
  • Upgraded firmware to latest, forced reinstall of same, downgraded to previous version, then re-upgrade to latest.
  • Hardware reset by shorting reset pin field to ground.
  • Replace J4 input with USB-C using 5V 5A power supply.
  • Replace Raspberry Pi
  • Attempt to run this with your LTE HAT removed.

In every situation, the HAT behaves the same. If I start the HAT with battery connected, it will ONLY source the battery until the Pi shuts down (safe shutdown enabled) or until the battery is depleted. If I start HAT with the battery not connected, it will source the input (J4 or USB-C) but NEVER charge the battery.

I am including pictures of my setup as per your instructions. I hope you can help soon. This is very disappointing. I had very good results with my first two systems using your product but right now I am on my second HAT and cannot get this system to work correctly.

20210429_074830.jpg20210429_074824.jpg20210429_074816.jpg20210429_074757.jpg20210429_074746.jpg

image.png


I also wanted to share this video of what is happening. In it I have replaced the flat lipo with the 18560 and am using a digital power supply configured for 5.1V @ 5A. In the video you can plainly see that when the battery is connected (which is almost depleted) the HAT switches to it and draws no power from the external supply. When the battery is disconnected, the HAT switches to the external power supply connected on USB-C.

I’d like to add to the conversation here. I’m having exactly the same problem as others have posted: input current going to zero, while the input voltage remaining at ~12Vdc. The battery drains, and the device eventually shuts off. The only remedy to get the device back online is by unplugging the power supply and plugging it back in.

I had initially thought this was a power supply problem, but if others are having this problem in their own setups then it must be the UPS Hat.

Has anyone considered doing the following:

  1. Detect when the input current drops to zero (using the python API)
  2. Reset the MCU using the reset_mcu() command via the python API

I’m wondering if the MCU being reset programmatically is more or less the same as unplugging the power supply that provides power to the MCU. If not, hopefully someone from Sixfab can advise on a proactive strategy that can fix the issue before the battery is completely drained.

This issue has occurred in 3 of 4 of my deployed units in the field, with the zero-current issue occurring anywhere from 1 day in the field to ~2 weeks (with no unit lasting longer than 2 weeks). This failure rate is very alarming and I would strongly advise anyone who needs continuous power to devices deployed where they cannot be easily serviced to look for an alternative product.

Still nothing from Sixfab regarding this so assume it’s an issue they are aware of.
They are redesigning the power HAT (it’s currently out of stock while they get the new one built).

Really disappointing as we had 14 devices we wanted/needed to use this for but this is just one of the issues we hit which we got no support for.

Hi there,

I am sorry to hear about this. Several other people have reported this issue, We have been working on this problem for a long time.
First of all, we saw that in some systems we created, this problem was caused by connecting the battery in reverse polarity or damaging the system. Make sure you never connect the battery in reverse polarity.
We’re still testing the issue on our end, as the systems we’ve built and tested don’t have the same issue

However, we are constantly making improvements to the firmware and new hardware version to avoid potential issues. These will be available soon.

That’s why we ask you to test this, too: Power the UPS HAT with the official Raspberry Pi USB-C adapter and test as long as possible. Please confirm if the same issue will occur again. This will give us a better idea of how to handle this situation.

Thanks

@ensar,

I have never put my battery in backwards and the system is not maintaining power under heavy usage. It browns out which resets the pi. The “long time” comment really bothers me. I’m glad they aren’t still being sold. I have a number of your products, they aren’t cheap. I expected better.

Can you explain how this issue can be fixed on my end? Even with the batter out, it still powers down. Total system usage remains below 20W at all time from my 13.25V desktop power supply. I convert that using a 60W @5V PSU. That powers the Pi through the UPS hat. Also attached are the LTE hat, an IMU, GPS hat, and a HackRF SDR, and OBDII. The HackRF is high power, but still only USB 2.0 and is usually the problem. I can run the SDR for no more than 5 minutes before the system resets.

The battery also discharges WHEN NOTHING IS POWERED. I have used the EDM option (which is terrible btw, but that’s another matter), the LPM option, a ‘shutdown -h now’ after scheduling a UPS shutdown. Best I can do is the soft shutdown and UPS event… but the power usage comes right back after being “off” for about 15 seconds. I suspect the watchdog comes back on.

I think this device leaves a TON to be desired.

Please tell me new firmware can fix it… If nothing else, could you please release the firmware so that I can fix it.

Getting help from sixfab lately has been really rough.

Please also put back the hard_power_off() function. Please
S

1 Like

Hi @shawnj007 ,

Thanks for reaching out. I’m so sorry, I definitely understand your concern.
The new version of UPS Hat will be available soon. We will send it to you as soon as it is available.
We’ve received your email and we’ll examine the issue in detail. We apologize for the problem you are experiencing. Our team will do our best to solve the problem.

We plan to put the hard_power_off() function back with the new HAT version.
Also, we have been struggling with the global chip shortage caused by disruptions in the supply chain during the coronavirus pandemic. We hope everything goes well for all of us. Thanks for your comprehension.

@ensar

Thank you so much for reaching out. I understand about the chip shortage. Thank you for the news about the hard_power_off().

How about setting an event to start EDM? It cannot be set while on DC power, system will immediately boot. It does not gracefully shutdown the system. I need a way to shutdown before I pull all power.

An “always boot with DC power” option would be nice. Also, an option to disable the battery charging circuit (to avoid excessive intermittent load).

Shawn

The soft shutdown can be used for graceful shutdown.
It is not set to EDM when on DC power because it immediately exits the EDM on DC power. There’s nothing that can be done for this.

@ensar

About EDM…
I know it can’t be set when DC is plugged in. I want an event that I can schedule so that I can do a software shutdown, then put the device into EDM (with the preprogrammed, scheduled event). I schedule my shutdown the moment DC power is removed. But, I cannot use EDM, as it does not shutdown gracefully first. That should be repeated.

EDM does not gracefully shutdown the system. It just kills it… this is BAD.

EDM needs to be a scheduled event so that the system can be brought down to the appropriate run level before powering off.

The alternate solution would be to make EDM functionality only trigger after the DC power has finally been removed during the shutdown procedure.

As it stands, the EDM mode, while having a good intention, fails to be implemented in a useful and safe way. It needs to wait for power off (or DC detect), or be available as a scheduled event.

The soft shutdown does not bring the power usage low enough. It still sits at around 200-300mA at 13 Volts from my desktop supply. The soft shutdown does not power down the HAT. It only issues the shutdown command to the system. If the HAT does not cut power, the battery is consumed in less than 12 hours. It should last more than 10 times this at a very minimum.

The hard shutdown (scheduled event) works and brings the system (almost) all the way down, but the button must be manually pressed to power the pi again. This is a super-duper design failure, by the way.

*Side note: the HAT should also have an option for no blinking lights. Not everything needs a wasteful indicator circuit.

The HAT needs a capability to be powered up when DC power is plugged in, not if it is already plugged in as is the case with EDM.

My use case, effectively never calls for the system to be powered on battery for more than a few seconds, and then it is only meant to keep the RTC accurate. Nothing else. It’s a really simple use case, I can’t believe it hasn’t been considered before.

Let me say it one last time, as implemented “Easy Deployment Mode” is TERRIBLE!

Soft shutdown uses too much power.

Hard shutdown requires a button press to bring back up.

Is there someway to do a hard shutdown that also puts it into EDM at the end? I can schedule that after the DC power is removed. That seems like the best solution to me.

PLEASE PLEASE PLEASE fix these things in the new version!

Shawn

This might be a good way to solve some of these problems:

[SOLVED] How to make Easy Deployment Mode enable just before shutdown!