question

lenarda avatar image
lenarda asked

Critical Bug - BMV 712 does not adjust SoC correctly based on Peukerts Exponent

As per the title - someone has screwed up the Peukert exponent algorithm in the BMV 712.


I'll state from the outset - I do not need a lecture on what the exponent means. I know what it means. I've been using it with my bank of Trojans at my present home for nearly 15 years, and my previous cabin for 20 years before that. I've used many other monitors tthat accurately de-rate the bank capacity based on instantaneous load. I know how this should work.


And the new Victron equipment I have paid thousands for in my recent RV build, does not.


For context, I have LFP bank rated at 400Ah @ C20, 385 @ C8. Both of these I have personally tested at STC and used the C20 value as the baseline capacity in the BMV settings, along with the corresponding Pe of 1.04, . The typical, expected behaviour then, would be that the capacity used for deriving instantaneous relative SoC should adjust under load to match these values.


Which is to say:

  • With a 20A load (corresponding to a C20 discharge), the SoC should be derived on a capacity of 400Ah. So if 100Ah is discharged, and a 20a load present, this should result in a 75% SoC displayed and a 15hr runtime, based on the C20 rating of 400Ah. ( [400-100]/400 = .75 ).
  • Equally, a 48.13A load (for a C8 disharge) when applied at the same 100ah discharged volume should result in a 74% SoC based on the C8 capacity ( 385-100 / 385 = .74), and obviously in-between values should be extrapolated


However, this is not what occurs.


Despite the manual explicitly stating the SoC value " is compensated for both the Peukert efficiency and charge efficiency.", I have never seen the SoC change with variation in instantaneous load. Even with changes in load as as high as 1C, the SoC remains the same (save for decreasing with Ah consumed as time progresses). This is not correct behaviour - relative SoC should be immediately lowered based on instantaneous load and Peukert exponent, to reflect the reduced total capacity available under heavy loads.


The "time remaining" value DOES adjust - but often incorrectly, either over or under-estimating with no pattern I can make sense of . Time to go averaging is set to 0m, and I am testing with constant loads, so this cannot be put down to variance in averaging calculations.


Every more bizarre, in the process of trying to troubleshoot this, I noticed that changing Pe in fact has the OPPOSITE to intended effect! For example, increasing the Pe to the max 1.5 value (simulating a high resistance, 'lossy' bank) somehow results in the SoC INCREASING!! This occurs even when under a load greater that the C20 rate, so it doesn't make sense as 'overrating' the explaining it as overrating capacity for loads lower than C20 (eg extrapolating to the C100 capacity). Indeed, when actually reducing the load to something like C100 (or increasing it further, for that matter) the SoC still remains exactly the same - again indicating no actual capacity adjustment is occurring based on load/Pe at that moment.



Conversely, lowering the Pe to 1 - for an 'ideal' bank that should simply used a fixed C20 400Ah as the reference regardless of load, somehow lowers the SoC! It's as if the capacity of the battery now HAS been shrunk, despite explicitly applying a Pe value that should disable this! This results in bizarre situations where in one instance, 47Ah taken from the 400Ah total capacity was shown somehow as 57% SoC remaining.




I have tried resetting the unit and SoC from known full charge to no change. This behaviour is totally at odds with not only the (very limited and simplistic) explanation provided in the documentation, but also with the very principle of how the exponent should work. It also appears this bug has been present for some YEARS:


https://community.victronenergy.com/questions/73478/smartshunt-and-peukert-coefficent-doubts.html


https://diysolarforum.com/threads/peukert-exponent-vs-soc.54769/



This is utterly unacceptable. I've already had to return both an Orion and a Smartsolar under warranty due to hardware/design defects (a whole other issue I wont get into in this post) and now I find sloppy programming has crippled basic monitoring functions that you'd find on a $50 ebay monitor.


The vendor has told me 'take it up with Victron' and refuses to warranty it with the outright incorrect assertion that "Lithium batteries don't have a Peukert thingy". But apparently Victron doesn't have any sort of actual technical help line (a huge letdown in its own right), which leaves me no choice but to air it publicly.


This needs to be fixed immediately. I didn't pay for this sort of sloppy execution, and frankly I've just about had it with this entire dogs breakfast of a company.



PS - I would provide images of these bizzare results, but apparently this forum is as buggy as your products and any attempt to upload any image of any kinds simply spits a "Parsing Response Failed" error. Well Done.

BMV Battery MonitorSOCbug report
2 |3000

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

2 Answers
JohnC avatar image
JohnC answered ·

@lenard.a

I think you misunderstand. You say this.. "I have never seen the SoC change with variation in instantaneous load. Even with changes in load as as high as 1C, the SoC remains the same (save for decreasing with Ah consumed as time progresses). This is not correct behaviour - relative SoC should be immediately lowered based on instantaneous load and Peukert exponent, to reflect the reduced total capacity available under heavy loads." (Your bold).

Nope, SOC is treated as an absolute figure. It doesn't change because you've applied a different load. Nor should it. The Time Remaining will change after whatever time you have set to recalculate it.

If you have partly discharged batteries, SOC will change if you change Peukert. It recalculates the historical discharge, and I think that's a great feature.

There's nothing to fix here. Perhaps your attitude when seeking help could use a little work though..


1 comment
2 |3000

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

lenarda avatar image lenarda commented ·

"Nope, SOC is treated as an absolute figure. It doesn't change because you've applied a different load."

No. That's completely incorrect from a chemical standpoint and demonstrates a fundamental lack of understanding of how batteries work.

You don't retrospectively adjust what you've removed to keep SoC constant. The energy removed is the fixed value. Whether you do it at a high or low rate, its the same total amount of net work/joules (minus maybe some negligible heat losses) lost from storage. Which means any SoC calculation should deduct this amount from the total available capacity. And its this available total, and ONLY this total, that changes based on the given load.

You can test this yourself. For example, find a lead acid battery's C5 capacity - usually about 80-85% of the C20 cap. Discharge that amount, but at the C20 rate - leaving you at about 15-20% Soc. Now discharge again - but at the C5 rate.

You will not have 20% of the C5 capacity remaining - you'll bust 1.8vpc almost immediately. The battery - as far as serving at the the 5hr rate - is flat. You have already removed all the capacity for that rate - all energy it could provide while keeping the voltage above threshold for that load.

Accordingly, the displayed SoC should be 0%. That is Peukerts law, and that is how every single monitor I've ever used in 30 years of doing this has worked. The same holds with lithium chemistries, just to a lesser degree.

Fudging the numbers on what you've used, to pretend you still have 20% available at the higher rate is demonstrably wrong and makes zero sense. How can SoC possibly be absolute, if the very premise is that total available capacity is less when drawing at higher rates?

It makes even less sense, considering that the Time To Go seemingly does recalculate itself of an adjusted available total. You can do the math on time * discharge rate and clearly see it doesn't match the total capacity that the SoC is being based. Something is clearly wrong.

Don't lecture me on my attitude until you get your own facts right.







0 Likes 0 ·
nickdb avatar image
nickdb answered ·

@lenard.a sorry to hear you're not having a good experience.

As a new member you have hopefully read our guidelines.

https://community.victronenergy.com/questions/5889/new-victron-community-guidelines.html

If so, you will understand that while the community has a Victron badge, it is a site full of volunteers and enthusiasts, not a Victron support channel.

While a flaming topic and responses might relieve some frustration, it will just drive away anyone who may want to try help, so it is counter-productive.

The actual support process is in our guidelines, and the support philosophy, pros and cons, has been discussed on many other topics available via search, and is not much any community member can change.

We don't like moderating posts, but we ask everyone to be constructive and civil, as those here do not make nor support the product.

Finally, re the forum issues.

Yes, we know, but it is not Victron software, nor run on Victron systems.

All clients of this platform have the same issues.

If you took a moment to browse the other sections you would find that the site is mid-transition to a new platform that really works well. This has happened because Victron values the client experience and they make constant changes based on feedback - where it makes sense to do so.

You only need to browse the dev sections to see how much effort goes into this.

Anyway, you may not get the answers that you want to hear, but good luck to you.


2 |3000

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

Related Resources

Victron BMV battery monitors product page

Additional resources still need to be added for this topic