Issues with Current Value and Charging

[savejeff]

Hi,

I have found some issues:

first, the current readings from both supply and batt in the python script are incorrect. it says the Raspberry consumes 2000mA
@5.0V resulting in 10W of power. the batt current also seemed too high. I checked it with a multimeter and both supply and batt current are of by about a factor of 2x.

ina_supply = INA219(0.00725, address=0x40)
ina_batt = INA219(0.005, address=0x45)

I think here the wrong resistor values are used. I get roughly the correct values by using double the current values. I think this should be checked.

Second, I observed frequent interruptions while charging. I plotted the charge current and it drops every 2 minutes. Also right after charging start Power Delivery 2 is used with 9V @ 3A for 2 minutes then it stops charging and goes standard USB charging with 5V @ 1.5A. As a result, charging takes longer than discharging. that's not fast charging.
I use the type c port for fast charging. I have tested multiple chargers, and I updated the firmware with the OTA script to the current Version 9

One Discharge and charge cycle

Start of Charging:

Lastly, when I plug in a powerbank on the fast charging port, the powerbank is getting charged not the ups. I was expecting that the charge port on the long side is only input and the two USB A and one USB C on the short side are for charging external devices.

[ArjenR49]

Re the INA219 values:I have noticed the same already in june 2021 and adjusted the parameters roughly based on measured input power in the appropriate situation (referring to your second point).

My INA219 calls:

#        inaBattery = INA219(0.005, busnum=DEVICE_BUS, address=0x45)
        inaBattery = INA219(0.011, busnum=DEVICE_BUS, address=0x45)

and

#        inaRPi = INA219(0.00725, busnum=DEVICE_BUS, address=0x40)
        inaRPi = INA219(0.0145, busnum=DEVICE_BUS, address=0x40)

In the case of your second point my explanation is the battery sampling done by the f/w at regular intervals (default 2 minutes). The blue leds are off while the battery is switched to power the load and the charging power supply is cut off for a number of seconds.
This is somehow documented: if your power supply is 'weak', you are advised to lengthen the sampling interval.
Under maximum (or typical, whatever you prefer) load check the battery voltage and the estimated battery capacity. If they drop, your power supply is 'weak', i.e. it cannot keep up with the discharging during the battery sampling event. You may be able to remedy that (a little) by changing the ratio of battery sampling time to charging time, i.e. increasing the interval time from 2 minutes.

Re your last point I have not much to add. I never tried to use any of the USB-ports on the shots side until just now ... It charges my phone ... the phone lives ... (USB A). Tried a Xiaomi power bank as well. It charges .. according to the led indicator at least (blinking).

It looks like my UPS f/w is frozen again. At least the minute counts (originally seconds, I converted them in my reporting script) aren't increasing any longer. This is the major problem with this UPS on f/w 9 for me. Not reliable as a UPS. When it freezes, the control scripts cannot shut the Pi down after an AC failure. etc. etc. See other issues for this BUG.
If it hasn't frozen, it's OK.

[savejeff]

as the parameter of the INA is the shunt resistor value, it should be something round like 0.01 and 0.015. don't really understand how this was not found already.

about the charging, why must the charging be stoped in order to check the battery state. if I use the UPS as intended where it its allweays plugged into a charger it would charge and discharge the battery at 100% every 2 minutes. that's a good way to age a lithium cell very quickly
I'll try to set the interval to a higher value. what does this interval thing do anyway?

about the charge port, I meant that when I plug a powerbank into the intended charge port on the LONG side it starts to charge the powerbank not the UPS. So there is no way to charge the UPS using a type c powerbank that can be charged and discharged over the same type c port.

I'm considering switching over to the PiSugar. This is too much unexpected behavior for my linking.

[Siegurd01]

It looks like the resistors used for shunts are 0.01R R010 0.01 Ohm 1% 2512 (1W) SMD, so you should use INA219(0.01, ...
In my case it 100% fits in measurements with voltage and power meters on battery and Rpi.

[ArjenR49]

Do you mean both INA219 instances need to have the same parameter value?
I originally set the values I use based on a power balance calculation using a metering device on the USB charging input and read values when the battery is essentially not charging nor discharging (I remember so; it's months ago; I also studied the INA219 spec sheet ... not sure if I understood everything there; I just went by 'what comes out, to the Pi, must go in via USB, albeit at a different voltage level and losses are incurred, so it was pretty approximative).

I haven't tried to get a current meter between the UPS and the Pi. Once I had thin flexible double sided PCB material ... it would have been easy to make a probe with that.

The parameter values I came up with are different for the two INA219's, both are about doubled from the original values.
It would have been great to have some comments from the makers on this.

In the end the precision of the current measurement isn't very essential for the UPS operation. What is your opinion about that?

[Siegurd01]

Do you mean both INA219 instances need to have the same parameter value?
Yes, shunt resistors R22 and R8 are the same nominal (0.01R R010) and they are connected to both INA's.

In the end the precision of the current measurement isn't very essential for the UPS operation.
I created an Issue topic cuz on some day my UPS starts to charge batteries with 3.5A+ and IP5328 was 120 C hot. So measuring parameters from UPS witch is not in final release can save you from batteries blow and fire.

[ArjenR49]

In one of the rare comments by the makers, they seemed to say that the parameter values take into account the typical ON-resistance of the adjacent switching MOSFET.
I would need much more information to be able to judge that.
In the light of what we read about mishaps, leaving this UPS on - for months or even just hours? - without supervision seems to require a leap of faith, although I personally have no worrying observations about overheating etc. If there ever was a problem with reported values, it's been the i2c bus that was the culprit, afaik.
It mustn't burn down my cottage ...

I have been on f/w v. 10 for a long time now, from before it was finally announced. This version prevents the Pi from accessing the i2c bus for a short while whenever it sees fit. This can be seen in the syslog. In practice this seemingly random blocking of i2c has not prevented control of the UPS by the script I use, fanShutDownUPS.py by frtz13 on GitHub. However, it has prevented freezing of the Pi/UPS combo assumed to be caused by contention over the i2c-bus.
The makers wrote in their announcement of v.10 that they followed official advice in this matter. It seems quite a rough way, though, especially as there are no instructions about how to make a control script overcome these 'random' i2c blocking events in an elegant way.

In fact, blocking i2c by UPS f/w v.10 was not admitted, it's just what I think happens ;-)
I admit that I know very little about i2c, so ...

[savejeff]

@ArjenR49 does this mean there is a Version 10 released that fixes the freezing bug?

I stopped using the UPS because it consistently freezes after an hour or so of operation.

Do I need to use another i2c implementation in python?

[ArjenR49]

Yes, there has been a version 10 long before it was announced on the GeeekPi GitHub site.
It does away with the freezing by - apparently - blocking i2c for the Pi whenever the UPS f/w wants to.

If the blocking happens to coincide with the control script trying to access the i2c bus, there will be an error message in the syslog, but otherwise nothing bad happens:
Oct 19 17:12:29 RPI-HUB /fanShutDownUps.py: [get_UPS_status_and_check_battery_voltage] Error getting data from UPS: [UPSPLus.init] Error reading UPS registers: [Errno 121] Gindse invoer-/uitvoerfout

As I wrote, I use frtz13's script from his GitHub page. I set the battery sampling by the UPS at an interval of 10 minutes: Battery sampling ('blue LEDs off') interval: 10 min (0x15-0x16)
At the default value of 2 minutes(?) error messages are logged more often ... likely because the i2c bus is blocked more often.
If I knew how to check the blocking before trying to access the bus, I might be able to avoid the error messages, but then the way frtz13's script is written, it is a bit much over my head (~object oriented programming?)

The battery check by Frtz13's control script is every 60 seconds.

I have not used the 'official' control script for a long time, but I haven't noticed it had been changed lately for version 10. I have no idea how it would behave. It had preciously little i2c exception handling when I last looked at it unlike frtz13's script.
I can't say anything to the i2c implementation. I don't recall having to change it. If I did, there must have been an instruction to do so, but I doubt there was any.

[hellresistor]

It looks like the resistors used for shunts are 0.01R R010 0.01 Ohm 1% 2512 (1W) SMD, so you should use INA219(0.01, ... In my case it 100% fits in measurements with voltage and power meters on battery and Rpi.

Friend, are you saying We should change on python code with that values "0.01"?

[Siegurd01]

@hellresistor, yep.

[ArjenR49]

To those worrying about maximum battery capacity % readings from the UPS:

I have changed the USB cable from the charger to the UPS to one by UGREEN advertised for fast charging (AliExpress: Ugreen Usb Kabel PD100W Usb C Naar Type C Fast Charger Kabel Voor Xiaomi Samsung Macbook Ipad 5A Mobiele Telefoon cord Usb-kabel Type C) and the charger to a UGREEN GaN 65 W charger, model CD244, also from AliExpress), which provides up to 3 A at 9 V (on my UPS).
Initial charge current was about 3A when the batteries had been run down, and the charging/battery capacity % rose to 99%, whereas on a 9V/2.22A PD Fast Charger from Ugreen and another USB cable it never got above 97%, more likely 94%.

A more powerful charger and better USB cable indeed seems to make a difference, although I do not think this is essential to the operation of the UPS. Not all PD chargers and USB cables are created equal ....
The new cable and charger were far more expensive than the UPS when I bought it ...

[yoyojacky]

Hi ArgenR49， That's right. better power supply will offer better perfornance...