LiFePO4 capacity test

[john61ct]

Compared to what? How could the device even know about its own level of accuracy?

And the accuracy will vary for every batt type, even model, size, current temperature, usage pattern.

Fact is you can benchmark This battery in This context. But it won't apply elsewhere.

[Paul L]

Originally Posted by john61ct

Compared to what? How could the device even know about its own level of accuracy?

And the accuracy will vary for every batt type, even model, size, current temperature, usage pattern.

Fact is you can benchmark This battery in This context. But it won't apply elsewhere.

Compared to what? Compared to their true value. If the accuarcy varies so wildly, as you say, then state what the range is. What is the point of a measurement of my battery state of charge or state of health that has an unknown error bar? How do you use a 98% SOC on a lead acid battery that might be +2% or minus 15%?
How could the manufacturer verify their algorithms and implementation if they don't have actual test data that shows the error range. I'm just asking the company to post what they are comfortable with for accuarcy ranges on the device. Something more specific that just marketing blurbs.
If the error ranges are different for different battery chemistries then show that.

[john61ct]

My point is that the %error is not fixed.

And is not known. Your assumption is that some other more accurate instrument / measure is available.

That may be the case in some lab, but the difference would only be true for **that** battery in **that** context.

Because it changes depending on dozens of changing variables,

any error rate for **this** battery in **these** circumstances, cannot be known out in the field.

And certainly is not something that the device can display about itself!

That you imagine it could, kinda boggles my mind?

[Paul L]

Originally Posted by john61ct

My point is that the %error is not fixed.

And is not known. Your assumption is that some other more accurate instrument / measure is available.

That may be the case in some lab, but the difference would only be true for **that** battery in **that** context.

Because it changes depending on dozens of changing variables,

any error rate for **this** battery in **these** circumstances, cannot be known out in the field.

And certainly is not something that the device can display about itself!

That you imagine it could, kinda boggles my mind?

Glad you are boggled. Accuracy is stated as a range. The vendor can state the range from their testing. Saying it depends on a bunch of stuff does not eliminate the reasonable expectation of publishing the error range and conditions.

What I said about the instrument is that it should indicate when it believes it has valid data. There is no need to call tech support to have them say all is good, the unit just needs more cycles. It knows exactly how many cycles it has. There is also no need for a user like Delfin to say that the conditions he's testing under aren't normal and therefor the units displayed data is not valid. The unit knows what the conditions were and could also indicate if it thought tbe data was valid or not.

[rgleason]

Actually I've cycled the FLA about 5 times.

[CatNewBee]

Originally Posted by transmitterdan

SoC and SoH don’t have industry agreed tolerances or even agreed units of measure for that matter. The SoC value can be defined numerous ways. It’s a topic about as inflammatory as anchor choice.

SOH is a ridiculous concept either.

Tell me your SOH. How old are you, do you feel healthy and what prognose would you give, how long will you be alife based on your SOH estimation.

So SOH is a out of thin air percentage that is decreased based on time, charge cycles and dark arts, but cannot reflect the real life expectancy of a battery. You may measure degradation of capacity, but only if you make a real capacity test, for PSOC it is simply BS, you cannot really tell the state of charge precisely, so SOH is even worse to deduct.

In the FLA world with 300...400 cycles life expectancy you may just count down the Ah charged and discharged to roughly estimate the health, but with LFP you have a range from 3000 to 10000 cycles, no way you can make an educated guess of the remaining life in a battery.

[rgleason]

I believe SOH is simply a percetage of Calculated actual AH / Manufacturer or initial entered AH.
No real mystery there. For different types of batteries the sg200 uses different formulas (calculas similar to what an earlier poster outlined) based on testing. It is likely that the accuracy will improve with each version of software. I believe that FLA, AGM and Gel are pretty well estabilished and figured out. and they are still working on fine tuning LFP improvements, but I don't know that as a fact.

[Delfin]

Originally Posted by rgleason

I believe SOH is simply a percetage of Calculated actual AH / Manufacturer or initial entered AH.
No real mystery there. For different types of batteries the sg200 uses different formulas (calculas similar to what an earlier poster outlined) based on testing. It is likely that the accuracy will improve with each version of software. I believe that FLA, AGM and Gel are pretty well estabilished and figured out. and they are still working on fine tuning LFP improvements, but I don't know that as a fact.

I believe it also includes the time to reach full charge. Whether it is "accurate" or not in the sense Paul is arguing for isn't of much interest to me. What I care about is a trend indication which will tell me if my charge/Management regime is working.

[hellosailor]

"Well the device knows all of this information and could easily turn on the yellow light."
Paul, you speak as if you expect the unit to have brains. It doesn't. Like all "computers" it has no ability to do what it hasn't been programmed to do.
Someone would need to add programming which from time to time reads the stored data, runs an algorithm to decide "what kind of cycling has been done?" looking at times and depth and state of charge and then comparing all that data to a stored set of potential "these are good enough" conditions.
That's certainly POSSIBLE, if the unit has a microprocessor with spare time and the memory to keep and run the extra programming.
But hardly a trivial exercise to implement, unless the existing unit already has the spare hardware to allow for the programming changes.
Easier to put a note in the manual that says "Don't read this display until..." and let the wetware do the job.
Numbers are dangerous when you just use them without knowing what they really might mean.

[Paul L]

Originally Posted by hellosailor

"Well the device knows all of this information and could easily turn on the yellow light."
Paul, you speak as if you expect the unit to have brains. It doesn't. Like all "computers" it has no ability to do what it hasn't been programmed to do.
Someone would need to add programming which from time to time reads the stored data, runs an algorithm to decide "what kind of cycling has been done?" looking at times and depth and state of charge and then comparing all that data to a stored set of potential "these are good enough" conditions.
That's certainly POSSIBLE, if the unit has a microprocessor with spare time and the memory to keep and run the extra programming.
But hardly a trivial exercise to implement, unless the existing unit already has the spare hardware to allow for the programming changes.
Easier to put a note in the manual that says "Don't read this display until..." and let the wetware do the job.
Numbers are dangerous when you just use them without knowing what they really might mean.

My career was in embedded computing. Your argument that it doesn't have the feature because it wasn't programmed is pretty silly. The unit does have an embedded processor, the unit is setup for years of firmware upgrading, it is a redesigned unit offered after years of marketing version 1.

[hellosailor]

Paul-
The computer literally does not have that feature because it was not programmed in. That's not an argument, it is a simple statement of fact.

As to WHY it was not programmed in? Yes, it could just be that the manufacturer didn't think about it. Yes, it could just take a couple of lines of code to, say, query the number of charge cycles and then send out a READY message when that exceeded a certain count. But then you are rashly assuming that the instrument DOES keep count of cycles, or that it keeps count of whatever criteria are really the valid ones here. Or that it has any spare memory for extra variables, or any of a half dozen other things.
Uniden recently announced a nice embedded system, their "new" R7 radar detector. Oh, but it is just a minor upgrade to their existing R3 except...that's right the R3 simply didn't have enough memory onboard to implement the minor new programming changes. And sometimes, that's what happens.
It can be the most trivial things, in hardware or software. Since I know at least one of us hasn't got any idea of what the hardware in that unit can do...At least one of us won't rashly guess whether it COULD do that simple extra job.
Some years ago a big client brought a big rush job into a shop I worked with. The only way to do the job was literally to have keyboarders inputting the work before there was a finished design for the work. So we told the client "that's going to mean...and you can have anything you want, but there can be no more than 20 style choices in it".
Twenty? Oh heck, they only needed 23 when they were done. Except, the software had a hard limit of 20 coded into it. "Easy" to fix that, sure, the guys who wrote the first quarter million lines of code would gladly knock that off...Not. And why their limit was originally 20, I still don't know. Maybe, only xx many variables in the programming language they used.
So by all means say it "should" be an easy fix, but that doesn't it would be. Ask Balmar, maybe they'll say they can fix it by the end of the week. Maybe.

[john61ct]

SoH is simply percentage of remaining capacity compared to either

(ideally) the peak actual Ah as measured just after breaking in / commissioning protocols executed, using the same exact load test, or

(distant second) to the mfg Ah rating

Obviously any prediction as to how many cycles left before complete failure is just a WAG.

But industry standard in mission critical use cases is EoL is at 80% SoH.

IMO most boat owners can push to 75 or even 70% but odds of "unexpected failure" are always increasing.

Those heading off on RTW or liveaboard in primitive / remote parts will have much lower risk tolerance than weekenders near a populated area in the developed world.

There are thousands of propulsion hobbyists that **only** use LI batts that others have scrapped. IMO a boat is no place for such risky business.

[john61ct]

And **changes** in an accurate SoH reading are excellent indicators as to deterioration caused by abuse or at least improper care.

Since thousands of cycles are possible with LFP showing **zero** drop in SoH

if you see any at all in the first few years, something IMO is wrong.

Of course purchasing sub-par batts in the first place will show the same result, and many do thinking they are saving money.

[transmitterdan]

According to the manufacturer the SG200 is not a redesigned version of the SG. It is a new product not based on the SmartGauge.

[Delfin]

Originally Posted by transmitterdan

According to the manufacturer the SG200 is not a redesigned version of the SG. It is a new product not based on the SmartGauge.

I have both. The difference between the SmartGuage and the SG200 is that the latter works with Lithium, and includes a SoH measure. Since SoC for Lithium is much more difficult to measure, it is unique and SoH is very much so.