StraightUp avatar image

Field Test: Why Victron MPPT controllers use incorrect absorption times.

So, after this topic coming up in multiple different threads recently, @Leslieanne proposed a theory as to why so many users are finding their Smart/Blue Solar units are only doing ~1hr absorptions, despite having quite a low battery voltage at sun up.

In short, the theory is that if you have significant enough shading on your panels at some point during the bulk stage, the panel voltage drops below cutoff, as if encountering 'sundown'. When the shading is removed, it goes through another 'sunrise' and recalculates the absorption time, using the below table...but with a new, much higher battery voltage - resulting in drastically shortened absorb phases.

Considering I personally run float=absorb, I've never actually looked at my 'absorb' times. So I decided to test this. For the last 5 days, I've run my batteries (370Ah) down to 30% each night to guarantee consistently low startup voltage, then isolated any loads all the way until the next sundown (ie no power draw while charging). Whilst it's meant a week of cold meals (which have not impressed the wife) this has guaranteed a consistent test environment, in which the controller SHOULD provide the full max absorb time - set at 6 hrs.

And it did! Well, at first:

Left to right, Days 1 to 3 were slightly cloudy but steadily clearing, hence the increasing yield. Day 3 in particular was solid sun and I was able to get a full 110% overcharge and even a brief equalization, completely restoring 100% charge. Importantly, each day correctly ran the max absorb time. The fun begins on day 4.

Being a sunny day, I had to resort to 'simulated' cloud i.e driving under a roof. Once the battery V reached 13v, I did one short tunnel pass and noted that sure enough, the controller drops out of charge and the blue 'bulk' light flashes, just like after sundown. It only takes a few seconds of sun loss, and sure enough....

As shown, the controller reset and recalculated a 1 hr absorb, based on a 'startup' voltage of 13.0v. Two further things to note here

Firstly, the total yield in this case has remained more or less the same , due to my float v = absorb v. Had this not been the case, by the end of the week I would have certainly totally killed the batteries.

Secondly this was with 70V panels on 12V batteries. With more typical 12/24V, I suspect you could trigger this with even cloud or treeshade.

As it happens, I tested this on the last day anyway. A storm front blew over and we had a good 5 minutes of twilight under some good Cb. Quick check to the meter and yep - the Victron dropped out at 12.4v, panel V fluctuating around 15-20v. Lo and behold, the result - a 1/3 absorb.

So, the conclusion?

These MPPT units are undeniably vulnerable to spurious absorption calculation, but @Solvan s theory that its due to inaccuracy in the units measurements is incorrect; they are accurate enough for their purpose, the problem is their own calculation algorithm.

Regardless of panel voltage, even a few seconds of major solar interruption by common events (driving through shade, sail blocking, dark clouds) will entirely disrupt this algorithm. This would be especially exacerbated if you were running a load at time of solar interruption, dragging V down further and likely cutting the most critical phase of charge by 80%. If you're not actively watching your SoC, or at least your end amps during float, this could easily result in chronic cumulative undercharging.

Victron needs to sort this out - this has the potential to damage customers' batteries. Its a very simple matter of extending the time required for low panel voltage to trigger a controller shutdown, from a few seconds to maybe an hour or so.

( Or, yknow - having a manual absorption configuration like every other controller on the market...)

@mvader (Victron Energy Staff)
@Guy Stewart (Victron Energy Staff)

MPPT - Solar Charge Controllerabsorption
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Thanks @StraightUp for your sacrifice of cold meals to conduct this test and observe the drop and reset. So if the drop in volts happens when it's in bulk it disrupts the calculation to unknown impact (could be more or less absorption than desired depending on volt reading). On the absorption side, I observed that it stays in absorption even when the volts drop (not sure how far) making you think it did get full absorption at absorption volts when it actually didn't. Again that would happen on partly cloudy or shady days. Not sure at what volts it would leave absorption and go back to bulk. Your test involved bulk only right?


It's OK - I'd eat cold baked bean sandwiches every day if I was allowed!

Regarding V drop in absorption - yes, I've also noted if you have heavy cloud cover after reaching absorption, it simply continues 'absorb' as best it can, at a lower voltage. Agree this can be a tad misleading, BUT:

Firstly - technically still an absorption, in that the controller is holding constant voltage while letting the battery dictate current based on SoC. On cloudy enough days, that voltage may not be quite as high as you want, but it's still an absorption that can charge a battery to 100% - it's just a lower (and slower) one.

@straightup. You said...

Firstly - technically still an absorption, in that the controller is holding constant voltage while letting the battery dictate current based on SoC. On cloudy enough days, that voltage may not be quite as high as you want, but it's still an absorption that can charge a battery to 100% - it's just a lower (and slower) one.

Not sure I understand the difference between this situation and bulk then. At that point aren't they both pushing the volts trying to get up to absorption volts again? Seems more accurate to change the name of the phase to bulk until it's at absorption volts again and count absorption time only when it's at the high volts. What am I missing?

This, of course means it will take longer to put the same kWh in, which wouldn't be an issue IF the controller was settable to, say hold absorb no matter what, until a % overcharge or minimum current had been reached (I think the trimetric can do this with Bogarts own PWM controler?)

Secondly - you do have some visibility with the victron unit on the kWh meter to see how muh charge it actually managed to replace, as you do with the trimetric. So in that sense, you can still get a gauge for how effective a charge you got

I actually didn't test the case of a solar cutout mid-absorption, to see if that also resets absorbtion time. I might give that a try next!

Has Victron addressed this issue. Is there a firmware update available yet?

I'm having all the same issues listed in the above and below discussions with my own bleusolar 85/150 mppt.

Absorb voltage being triggered by a cloud edge effect voltage spike early In the morning then absorb voltage not being maintained.

Though the absorb timer continues to run and switches to float without having been able to hold the set V absorb for that time. Resulting in a Undercharged battery by some 15% (you could call that issue exiting bulk to early)

We need to be able to force the mppt controllers to hold V absorb for a set time. Have the absorb timer pause if the V absorb can't be maintained and go back to bulk.

Ultamatly have the BMV talk to the controller and give us the ability to set a true (end amps) for float trigger. That way the battery's ability to accept charge current can be the determining factor for float trigger.

As a dumb countdown timer and voltage based algorithm at sturtup won't cut it in 2019 with lithium battery.

If the update is available is it only going to be for bluesmart controllers or will it be for both blue solar and smart mppt co trollers.

@OffgridSA As of last weeks Firmware 1.42, it's still a problem. Disappointing, considering they explicitly claimed this was (finally) a fix.

3 Answers
mvader (Victron Energy) avatar image

Hi @StraightUp, thank you for the extensive report!

We are working on (a) adding a fixed absorption time and (b) some other related improvements.

Above input helps.

I’ll keep (all of) you posted.


3 comments Share
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

With these fixes - are you going for a fixed absorption time alone?

If so, thats a pretty crude setting, and has problems for a number of reasons, most obvious being different depths of discharge.

Why not allow people to simply specify to hold absorption until a given tail current? This is the best guarantee of a full charge, assuming you dont have a constant fluctuating loads?

And for those users -why not work in something like the Bogart Trimetric, where the battery monitor communicates directly with the charger, and tells it to switch to float once the previous cycle's defecit is replaced? As best I can tell, the BMV units dont have this feature at present - I think that would be the most complete solution.

Yes; all of the things you mention there.

And yes a fixed absorption setting is rather crude and when not handled carefully it can end up damaging batteries by overcharging them.

See my email; I’ve invited you to help discuss the solution and test the firmware. Looking forward to the reaction.

Hm; I’ve tried sending you an email from different accounts now; but all rejected by your provider as spam. :-).

If you know my email address, please send me one; and otherwise I’ll ask IT to check next week.

Frederic.mora avatar image

Hi, @mvader @straightup I think I just fried a set of 4 firefly batteries for the exact reason that is explained here by @Straightup. I m getting a new set of batteries and would rather use an upgraded version of firmware instead (MPPT Bluesolar 100-30 with BT dongle).

Has there been any Firmware update fixing issues described by the Post owner?

Thanks a lot.


1 comment Share
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.


See here.

As of their latest update, the bug persists.

There's no work-around here - either you leave it as-is and risk undercharging, or set float=absorb and risk overcharging.

I'm about to return my unit before it does the same to my batteries. Sorry to hear about yours

JohnC avatar image

This a selected VRM portal graph of mine which shows a return to Abs after a couple of heavy hits with an ac load. 48V, 150/100 mppt (Bluesolar not Smartsolar), default charge settings outta the box. Temp comp working, but must have been 'standard' that day. But it's typical of everyday behavior for me..

Note it hasn't locked Abs in for long, just enough to compensate for a heavy hit on the batts. So yes, it can return to Abs under even normal circumstances. I like how it does this, and haven't seen any need to alter it.

Only posted to indicate 'possibilities' that may be misinterpreted with instantaneous readings.

1550637702892.png (77.7 KiB)
6 comments Share
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

I dont see the relevance of this information to the topic. The issue here is panel voltafe drop due to shading, triggering a false 'sunset' event, not battery voltage drop due to load.

Any V drop can cause it, whether from pv or loads. I could have picked an intermittently cloudy day to show you an identical effect. Just the graph gets 'messier'. The mppt doesn't know about loads, it just sees V.

I only posted that to help you understand. I could have also thrown in a pv production graph to show much higher production half way through Bulk than 20 min into Absorb. Tis the way it happens. Abs is just a peak V of Bulk, when it must back off to prevent over V. Abs V not something cast-in-stone, where you *must* spend a certain time there.

And I do note you run quite long Bulk times. I'll see that in winter, and might never quite reach Abs on many days. Even on the worst when I run a genny after sundown, it mightn't see Abs for more than (say) 30 min. By then A will have dropped so low that the genny is just idling and not worth running. The batts are done!

Tis about understanding. Sorry if I can't get that across.

Hey both, thanks for the help. I’ll share a document soon.


"The mppt doesn't know about loads, it just sees V"

Yes - V from panels, and V from batteries. Separately.

"Any V drop can cause it, whether from pv or loads"

No. The sunset/rise trigger disrupting absorb length calculations happens based on batt voltage ONLY at the time when panel voltage rises. Your graph fails to show any correlation based on batt V load drop alone.

In fact, look closer & youll see your graph actually proves my point - theres 12.6v equiv @ sun up, and a matching 2hr initial absorb time, despite your loads. Intervening batt V drop without a new 'sunrise' had NO effect.

A better test would be to apply loads mid initial absorption period, but I can already say - it simply puts the controller in bulk, then restarts the same miscalculated abs time again....unless you cut the panels during the load.

If there is something else you "can't get across" here, it is your communication that is failing to do so.

Hey both; can I ask to please stop the discussion?

There is indeed an issue, @StraightUp and possibly/probably others as well helped to highlight it / narrow it down

A fix is underway.

Best regards, Matthijs

Kristof G. avatar image Kristof G. mvader (Victron Energy) ♦♦ ·

hoi Matthijs,

just to be sure about this discusion,

is it the same problem i am having for a long time ( see my mails to you and Johannes) ?

but maybe with the quattro (ESS) ?

= partially resolved ( = voltage problem is solved)