PIP-4048MS and PIP-5048MS inverters

[weber]

Hi @weber
I've installed the firmware 73.00a on my inverter. Works great! Thanks for all the time spent on this!
I installed it because my batteries were never fully charged with the old firmware (early exit of absorb stage).

Thanks for the kind words. I note that I didn't have much to do with finding and fixing the premature float bug. That was coulomb. But I am responsibile for the changes to current reporting that you are having a problem with.

I'd like to report a bug/regression :
From version 72.70c beta, you've "improved the accuracy of the battery charge and discharge current readings, particularly for low currents, as displayed on the LCD, and as given in response to the QPIGS and QPGS serial commands"

I've built a small data logger / coulomb counter that runs on raspberry pi. And since the upgrade, my "total wh in" don't match "total wh out" any more (within reasonable margins).

Thank you for such a detailed report. So that's Wh in and out of the battery? Particularly with a lead-acid battery, I'd expect Wh in to be 5% to 15% greater than Wh out. Also, the resolution of current measurement by the PIP is only 1 amp. Not really good enough for coulomb counting. How much do they differ, and in what direction?

It looks like you've reduced the amount of amps reported by the inverter for battery charging current by 1 amp?

That is correct. And when the battery is not being charged, we've also increased the amount of amps reported by the inverter for battery discharging current by 1 amp.

From the Dynamic Current Control manual:

"The inverter does not have a current shunt, or any other means of measuring battery current. The standard inverter firmware estimates battery current by measuring AC power and applying a simple efficiency scale factor for inverting (100/108), and another for AC charging (119/128). It completely ignores the no-load and no-charge losses."

"We improve the accuracy of low readings by the simple expedient of subtracting 1 amp from the charge current reading if it wasn't already zero, otherwise adding 1 amp to the discharge current reading."

At first glance it seems reasonable to do that because the new figure becomes finally the real battery current, in most cases (see below).

Thanks for confirming that.

The previous battery current reported (before the upgrade) was actually "battery charge or discharge current" + "self consumption".
This is why the inverter would always report 1 amp even when the battery was in float and full.

Right.

I don't know exactly why, but there's an exception to this case, when in bypass mode and charging with AC.
In this state, the battery charging current doesn't include self consumption (or maybe more logically the self consumption is much less than the average 50W in solar charging mode with inverter on).

I think we tested it with AC charging and found approximately 50 W losses there too. But we will check this.

This has two unintended consequences with the new firmware :
1. The charging/discharging current reported is wrong (which is why my raspberry pi program is wrong)
2. The charger quits charging way too early when charging with 2amps, and quits slightly too early when charging with 10amps.

You should be able to replicate the problem by putting the inverter in bypass mode, AC charging at 2 amps, absorb time 180min. It never stays in absorb mode that long. (see attached picture - last night charging at 10 amps, absorb should be 180min - top red is AC charging)

As I've got a small system (4x 100Ah gel batteries) this is a bit of a problem for me.
Any advice?

I can see that would be a problem. We will investigate, and we may produce a version 73.00b to fix the problem.

[coulomb]

I don't know exactly why, but there's an exception to this case, when in bypass mode and charging with AC.
In this state, the battery charging current doesn't include self consumption (or maybe more logically the self consumption is much less than the average 50W in solar charging mode with inverter on).

Sinux, I see that you are from South Africa. For whatever reason, there seem to be a lot of older models in use there, which probably have the AC/utility power supply still fitted. That might explain why at least some of the inverter losses transfer to the AC input instead of the battery, when AC charging. The AC power supply, if present, would take over powering the processor, LC Display, relays, gate drivers, and other electronics. Later models omit this power supply altogether, so these losses stay with the battery.

Does your inverter have the black heat-sink on top, like this one?

Top heatsink.jpg (15.41 KiB) Viewed 5481 times

[ Edit: I no longer believe that the presence or absence of the utility power supply could explain what appears to be a difference in required correction depending on whether the PIP is in battery or line (bypass) modes. The power that this power supply handles is likely to be much less than 50 W, and in any case it would be present while the AC input is present, i.e. in both battery and line modes. ]

Don't go to any trouble, but perhaps you remember if it is possible to power up your inverter without the battery connected, but AC input present?

[weber]

We've just updated the 73.00a patched firmware to "release" status, here:
viewtopic.php?p=66664#p66664
The only thing we've changed is the version letter that indicates it's now a release version.

[coulomb]

I don't know exactly why, but there's an exception to this case, when in bypass mode and charging with AC.
In this state, the battery charging current doesn't include self consumption (or maybe more logically the self consumption is much less than the average 50W in solar charging mode with inverter on).

There are two current sensors in the PIPs. One is a LEM branded Hall effect sensor, that appears to be at the output of the DC-AC inverter. It seems to be a DC sensor so that it can detect excessive DC in the AC output (there is a fault code for this condition). The other current sensor is a current transformer, apparently measuring load (AC output) current. So the battery current is inferred, not measured directly.

When inverting, the battery current is inferred from the inverter load power less any solar charging power, so the losses are not counted, and are supplied by the battery.
When AC charging, the battery current is inferred from the AC charger (inverter working in reverse), and counts losses as if they go into the battery, but they don't.

In both cases, the current into the battery is actually about one amp less than the PIP indicates, hence Weber's corrections. On my PIP, the battery current corresponds well with the actual measured battery current after these corrections.

Note that the changes are only to displayed or reported values, so charging, including the time spent in absorb mode, should not be affected.

I've retracted my theory about the presence of the utility power supply possibly causing different results to be reported by the older models.

This has two unintended consequences with the new firmware :
1. The charging/discharging current reported is wrong (which is why my raspberry pi program is wrong)

As indicated above, I don't see why it would be worse with the corrections. If it really is happening, you could perhaps take into consideration that the PIP is in bypass mode, and uncorrect the correction. But it still would not be nearly accurate enough for coulomb counting.

2. The charger quits charging way too early when charging with 2amps, and quits slightly too early when charging with 10amps.

You should be able to replicate the problem by putting the inverter in bypass mode, AC charging at 2 amps, absorb time 180min. It never stays in absorb mode that long. (see attached picture - last night charging at 10 amps, absorb should be 180min - top red is AC charging)

I tried this, and as expected when the current limit was 2 A, the reported current was either 0 or 1 A. The charger remained in bulk/absorb mode, as indicated by the flashing CHG LED. So I can't replicate your problem. I don't understand why you seem to imply that the problem would be seen quicker with the current limit at 2 A compared to 10 A. [ Edit: my testing was with only one machine turned on; if I had both machines turned on, I now believe I would have replicated your problem. See this discussion of the two amp per active paralleled machine threshold. ]

Is it possible that your Raspberry pi software is assuming that absorb mode ends as soon as the reported current is zero?

[sinux]

Thanks for the kind words. I note that I didn't have much to do with finding and fixing the premature float bug. That was coulomb. But I am responsibile for the changes to current reporting that you are having a problem with.

Sorry I forgot to mention Coulomb! Thanks to all! and thanks for the kind reply.

I don't quite know where to start...
Yes I'm in South Africa, my model was manufactured in 08.2015. It doesn't have the top black bar (see pictures attached).

I'm mostly happy with the new display of the battery current it's much more realistic (although I would say a tad too pessimistic - full sunshine with load at 50% solar output, battery floating, it often displays -1Amp for a brief moment - the battery voltage doesn't change so I guess it's just rounding).

What bugs me most, is that the battery amps reported by QPIGS is now changed. For continuity/compatibility reasons it would have been nice to keep it consistent. I understand that you want it this way for dynamic current control. Wouldn't it be possible though to detect the use of dynamic current control function and only change the response to QPIGS if it's in use?

If it's not possible, I'll change my software. Just trying to think about other people who also have developed programs like that.

I'm all too well aware that the battery current resolution is insufficient for coulomb counting. However, this only affects when charging with AC (at night in my case). During the day, the solar power reported is accurate enough and I use those values. All I'm trying to do is have a general idea of the state of the battery during the day (the counter gets reset every night when the battery is full).

I was also expecting about 10% more Wh in than Wh out. But that's not the result I'm getting...
But that's a different matter, maybe we can chat about coulomb counting using only data provided by qpigs later.
Since the firmware update there's always more Wh out than Wh in (but that's because self-consumption is now remove from Wh in)

(this is to reply to Coulomb above) Now regarding the charging current on AC, I don't have the tools to measure it directly. I did a small experiment using my utility prepaid electricity meter (the assumption is that it's accurate...) :
Starting conditions : inverter in bypass mode, solar panels disconnected, charging with AC at 2amps.

Start at 09:23 am, the meter indicates 42.50 kWh remaining
The data logger indicates that I've used 0.978 kWh already that day (this value is the sum of all AC output power from Qpigs command times delta T)
Bat voltage 51.9V (remains constant during the test)
Stop at 11:10 am, the meter indicates 42.00 kWh remaining
The data logger indicates that I've used 1.223 kWh that day

This means that in 1.78h I've used 0.5kWh from the utility. Out of which 0.245kWh (1.223-0.978) were household consumption.

This leaves 255Wh for charging and self consumption (500-245).
If the battery is charging at 2amps this is 185Wh (51.9*2*1.78) and that means self consumption was 70Wh that's 39W (70/1.78)
Which is expected.
To me that means that when you charge the battery at 2Amps with AC, this is the actual current that goes into the battery ! Somehow the charger requests more power to compensate for self-consumption.
As you state during that time the current reported varies between 0 and 1 A. Which is wrong (if I didn't make a mistake above ).
See the plots attached.

I hope this clarifies the problem.
Thanks for taking the time to help!

PS: I don't seem to be able to attach pictures anymore...

[sinux]

Then I'll link the picture :

[sinux]

Sorry I forgot to reply to some of your questions :

Don't go to any trouble, but perhaps you remember if it is possible to power up your inverter without the battery connected, but AC input present?

No It's not possible to power my inverter without the battery connected.

Is it possible that your Raspberry pi software is assuming that absorb mode ends as soon as the reported current is zero?

My raspberry software doesn't assume anything in this way (it's not that clever). I just manually look at when the battery voltage reaches 57.6V.
That's my start of absorb. And then when voltage drops to 54.4V that's the stop of absorb, if I'm not mistaken.
The setting in the inverter is set to 180min (by me, just to test it).
But the measured absorb time as described above is always shorter.

For example see last night's charging at 10 Amps from AC (absorb timer set at 180min).

[weber]

Ok, of it I didn't know that ratio 8:1 was working of DC-DC converter. But to 60 V it is possible so that it is to hurry him up? It would be for me some solving a problem with my batteries.

Hi rezydent. What is the problem you are having with your batteries? There may be a better way to fix it. What kind of batteries are they? What is the version of the main firmware in your inverter?

[sinux]

So I can't replicate your problem. I don't understand why you seem to imply that the problem would be seen quicker with the current limit at 2 A compared to 10 A.

Please see the comparison of charging at 10 amps vs charging at 2 amps below.



Absorb should in theory be 180min in both cases (as this is set on the inverter).
Absorb time at 2 amps : 16 min
Absorb time at 10 amps : 60 min

What I meant (sorry if I wasn't clear) is that the less amps you charge the battery with, the shorter the absorb time.
I've been struggling for 2 years to charge my batteries.
6 months ago, I realised that if I was charging them at 20amps, they were getting fuller than if I was charging at 10amps.
But that didn't make any sense to me!
Now if the absorb time is too short, that could be an explanation.

I've got a very small system and most people have more batteries and solar panels than me, so the problem wouldn't be obvious to them.
Sorry for the long posts. I hope this clarifies things a bit. Thanks for your help!

PS: I should note that before using your custom firmware, setting 32 didn't exist on my inverter. I don't know if maybe that specific model is lacking some hardware to count the time spent in absorb (RTC, etc...) ?

[rezydent]

Hi rezydent. What is the problem you are having with your batteries? There may be a better way to fix it. What kind of batteries are they? What is the version of the main firmware in your inverter?

My batteries are mine cadmium nickel with KOH electrolyte 48 cell x 150Ah
2NiOOH + Cd + 2H2O ↔ 2Ni(OH)2 + Cd(OH)2
type KPL , see in documentation

Code: Select all

https://www.google.pl/url?q=http://www.amcosaft.com/sites/default/files/document_repo/AMCO%2520Saft%2520KP%2520Range_final%2520web_0.pdf&sa=U&ved=0ahUKEwiF6u7G6I7aAhUHEiwKHS2lCFYQFggUMAA&usg=AOvVaw0qB3AnngFa4Q2isl25q5V0

[weber]

Hi rezydent. You can't use 48 of those cells in series, with the PIP-4048MS inverter. I calculate that 36 in series would be the best choice. In that case you would set the absorb voltage to its maximum of 58.4 V, the cutoff voltage to its minimum of 40 V, and the float voltage to 50.8 V.

You should also install our patched firmware that fixes the premature-float bug.

[paulvk]

My batteries are mine cadmium nickel with KOH electrolyte 48 cell x 150Ah

They will need a different charging process to the lead acid I do not think the inverters will do it correctly see below:
Charging Flooded Nickel-cadmium Batteries. Flooded NiCd is charged with a constant voltage to about 1.55V/cell. The current is then reduced to 0.1C and the charge continues until 1.55V/cell is reached again. At this point, a trickle charge is applied and the voltage is allowed to float freely.

[rezydent]

in this moment I have an adjusted maximal value of stretching loading, it results from observation that the inverter is charging the battery of batteries up for me up to the 75-77% of the nominal capacity, through about 5 hours of loading. I have an additional rectifier charging these batteries up to the 95% of the nominal capacity of course. I simply thought that he would manage to modify this inverter so that he loads with high voltage, but I can see that it isn't possible this way. A curtailment of cell remains for the battery.

[al76]

Is it worth following this up with mpp solar or move fwd with buying another unit and have this unit repaired in Aus? I was planning on a parallel system plus I will be needing a second independent system soon anyway.

I can't really advise you on such decisions. Except to say that I don't see that you have anything to lose by raising the problem with MPP Solar.

How long has the PIP-4048MS been in use? Could there be a fault in the isolation device between your PV array and the PIP?

I'm assuming the isolation device between the PV array and PIP is the large switch?

Any way I've been limping along with this situation where the solar charging starts from approx 9:30-11:30am on most sunny days all the while the pips relays click away. Except 1 day last week which was cloudy and the solar charging started at 7:30am.
This morning I woke up to a dead pip4048ms. Checked batterys, fired up geny. No hint of life. I've ordered a replacement unit this morning.
The unit was purchased Dec 2016.

[curasun]

Hello guys,
I'm also having problems with charging my batteries fully. I've set the absorb time to 120min. It doesn't stay for 2 hours in absorb.
planning to buy a PCM60X from MPPsolar. Is this charge controller better?
Is their someone on this forum using this charge controller who can comment on this?

R.G.SPecht

[weber]

curasun. What main firmware version is your inverter running?

[coulomb]

I'm also having problems with charging my batteries fully. I've set the absorb time to 120min. It doesn't stay for 2 hours in absorb.

I note that even with timed absorb, absorb mode will be exited if the charge current falls to a particular value. That value is the number of active paralleled machines multiplied by two.

As an extreme example, suppose you had three paralleled machines (or a 3-phase setup with one machine per phase). Let's say you only have PV connected to one of them, and the battery voltage is near the absorb setting. The two machines with no PV connected still count towards the minimum absorb current of 3 * 2 = 6 A. The current will be non-adjusted currents, so about one amp more than the actual current. So if the charge current falls to 5 A or less, then as long as the battery voltage is close enough to the absorb voltage setting for 30 seconds without exception, then the charger will exit absorb stage regardless of the time spent in absorb.

[ Edit: actually because of the ~1 A difference between measured charging current and actual charging current, the effective threshold for the 3 machine example would be more like 3 A. So the current would have to fall to 2 A or less before this early exit from timed absorb would kick in. ]

NOTE: in the official firmware, the 30 second figure mentioned above was 10 minutes. Weber and I judged that this change was a misguided attempt by Voltronic Power to make it seem that they fixed their charge bug, so we changed this 10 minute figure to 30 seconds, as it was in earlier firmware versions such as 72.40. [ Edit: this change affects all absorb to float transitions, whether timed or not. ] That could make it seem that our patched software has regressed. But really, the original firmware would have exited early, but you'll always get 9.5 minutes more absorbing from the original firmware. This still could be an hour short of what you asked for.

I'm guessing that Voltronic Power consider 2 A per paralleled machine such a ridiculously low value that they're doing us a favour by cancelling absorb at this point, because the battery is "obviously" full. It would only take a single instruction patch to change this so that the threshold in timed absorb is zero, so the charge current could never be strictly less than the threshold (since nothing is strictly unsigned less than zero). So when in timed absorb mode, absorb mode would never be exited early, and would continue until the absorb timer ran out.

This is a moderately significant change to the way the charger would operate. Perhaps some owners who set their absorb times too high will overcharge their batteries if we made this change. However, it seems to be that this is a "you asked for it, you got it" feature, rather than a "I know better then thou, I'll do what I think is right" annoyance (and an undocumented annoyance at that).

What's the feeling amongst timed absorb users? Would anyone be inconvenienced if we patched the firmware to work more like it says it does?
The other question is, does a battery do any real absorbing if the charge current is low, less than 2 A per paralleled machine?

[ Edit: if the current -> if the charge current ]
[ Edit: paralleled machines that are switched on -> active paralleled machines ]

[sinux]

What's the feeling amongst timed absorb users?

That would be a very welcome change for me!
I've got 4 100ah gel batteries in series.
I've read somewhere that "Gelled cells should be charged at no more than the C/20 rate, or 5% of their amp-hour capacity." (http://www.electrovehicles.co.za/unders ... y-charging)
For me that would mean charging at 5 Amps. Sadly this setting doesn't exist (would it be possible to add it? ), so I'm charging at 2 amps.

A suggestion could be to check if setting 32 is set to anything different from auto before allowing a charging current less than 2 volts for absorb. In this case, the user most certainly would want the absorb timer to be taken into account.

The other question is, does a battery do any real absorbing if the charge current is low, less than 2 A per paralleled machine?

It would probably depend quite a lot on the size of the battery bank. I've recently bought a 12V battery charger (https://www.midas.co.za/pebble.asp?relid=1741&t=75). It has a slow mode that limits the current output to 2amps (as opposed to 8amps on fast mode). The manual says 2 amps is the standard way of charging the battery... I measured it absorb at less than 1amp for a couple of hours on a SLA 80ah 12v battery.

[curasun]

Hello,
Coulomb Firmware 73, it is a December 2017 model.

Thats the factory installed firmware.

R.G.Specht

[weber]

I've got 4 100ah gel batteries in series.
I've read somewhere that "Gelled cells should be charged at no more than the C/20 rate, or 5% of their amp-hour capacity." (http://www.electrovehicles.co.za/unders ... y-charging)
For me that would mean charging at 5 Amps. Sadly this setting doesn't exist (would it be possible to add it? ), so I'm charging at 2 amps.

Sinux, It is more difficult than you might think, to add new values for a setting. In any case, C/20 is a very low current. When I google "gel battery maximum charge current" I find 0.2C or C/5 commonly mentioned. That would be 20 A in your case, so I'm sure 10 A would be just fine. It's all about whether the battery temperature rises significantly during charge. You could measure this. It should not rise more than about 5 °C above ambient.

Clearly you are only using a single PIP/Axpert inverter, so Coulomb's extreme example does not apply. In fact the standard code has been saving your battery. If a nominally 48 V 100 Ah gel battery is being held at 57.6 V and the charge current has fallen to 1 amp (0.01C) then it is definitely full! That one amp is doing nothing but electrolysing water and generating heat.

[coulomb]

Hello,
Coulomb Firmware 73, it is a December 2017 model.

Thats the factory installed firmware.

Ah. So the early absorb termination could well be the long standing factory firmware bug, described here.

[ Edit: described the wrong charging bug; added link. ]

[coulomb]

Error 90 — Attention firmware updaters!
Weber and I have updated the patched firmware, both LC and LF versions, from 73.00a to 73.00b. This fixes a problem whereby on older hardware, the inverter would end up with an error 90 (fault code 90), after 60 days of running time. There has already been one machine stop working with this error; this was with factory 73.00, so this affects factory as well as patched firmware. So to users who have re-flashed their machines that came with an earlier version, be aware that you have a ticking time bomb, which could "go off" in a few days! Either roll back to a pre 73.00 version, or update to patched firmware 73.00b or later. There is no such problem with machines that came with factory firmware 73.00 or later.

See the Firmware section of the index post to find the latest patched firmware files.

[ Edit: minor changes to make it easier to find "error 90" or "fault code 90". ]
[ Edit: "no problem" -> "no such problem"; 73.00 still has the same charge bugs. ]

[coulomb]

Thanks, any idea where to get a relay with contacts rated for 60VDC?

The usual electronics stores: Jaycar, RS Components, element14, mouser, etc.

Would a SSR be ok to use?

I'd guess so, but higher current models might have too much leakage (i.e. they might not turn off "hard enough").

[xenonhost]

I have bought 11 months ago 48 pcs Winston LifePO4 for a friend. They worked well, but 2 weeks ago 18 pcs got swollen and they are all shortcircuited. I need a BMS, something for remaining 16 pcs connected to PIP.

[weber]

Hi @sinux. Coulomb and I recognised that we hadn't fully investigated your earlier bug report. We finally got a chance to do so, spending many hours on it yesterday.

We note that we have already determined that your second problem—the exit from an otherwise timed absorb stage when the charge current falls to 1 amp—is not caused by any of our patches, and is not a bug, as it has the potential to prevent damage to batteries held at absorb voltage for too long.

I'd like to report a bug/regression :
From version 72.70c beta, you've "improved the accuracy of the battery charge and discharge current readings, particularly for low currents, as displayed on the LCD, and as given in response to the QPIGS and QPGS serial commands"

It looks like you've reduced the amount of amps reported by the inverter for battery charging current by 1 amp?

Yes, and whenever the charging current was already zero (and so could not be reduced), we've increased the discharge current by 1 amp.

So, if you were to write some code in your Raspberry Pi to reverse this operation, i.e. if the discharge current (as reported by versions 72.70c, 73.00a or 73.00b) is greater than zero, subtract 1 amp from it, otherwise add 1 amp to the charge current, then your coulomb counter should work just as it did with the unpatched or earlier patched versions of the firmware.

At first glance it seems reasonable to do that because the new figure becomes finally the real battery current, in most cases (see below).

The previous battery current reported (before the upgrade) was actually "battery charge or discharge current" + "self consumption".
This is why the inverter would always report 1 amp even when the battery was in float and full.

I don't know exactly why, but there's an exception to this case, when in bypass mode and charging with AC.
In this state, the battery charging current doesn't include self consumption (or maybe more logically the self consumption is much less than the average 50W in solar charging mode with inverter on).

It turns out that your second "more logical" guess is correct. The self consumption when AC charging (and hence in bypass/line mode and not inverting) is only about 14 watts, whereas it is about 65 watts when inverting. Our patches mistakenly assumed about 50 watts in both cases. And so, while we improved the accuracy of discharge current readings and solar charge current readings, we made AC charge current readings less accurate.

Thank you so much sinux, for bringing this problem to our attention. We are now working on a 73.00c that will not only take these different losses into account, but will also round to the nearest amp instead of rounding down like previous versions. And this time, we will attempt to use these changes not only to give more accurate current readings, but also to give actual charge currents that are closer to the requested current.

73.00c will also fix some bugs in the original firmware, that cause minor problems when changing parameter settings via the LCD and buttons, as described by OomD here. Coulomb produced successful patches for these yesterday.