For a while now ive noticed that the SOC reported can often be 99% whilst in float (float proper, not float mmpt). This is most likely caused by a partial discharge (rounding / AH counting /efficiency mismatch) after absorb ends. But from a usability point of view it would be nice if SOC remains at 100% whilst holding float (and WBJr amps below EA threshold). I guess this is connected to skip days and 100% trigger without absorb.
Also as previously requested could the SOC modbus register have another decimal place. Graphing in whole percent increments is ugly.
Any chance of an modbus spec doc update? Now that things have settled down a bit.
Thanks boB!
I thought the SOC was simply calculated from the AmpHours remaining therefore getting a tenth of a percent accuracy was only possible with a battery bank rating over 1000Ah. Since the probability of there being a majority of banks rated much lower then a percent accurate SOC was ok.
I also noticed from my graphs that Ahr-remaining and SOC almost exactly follow each other but since my bank is over 1000ah the Ahr graph is more detailed
When looking at the battery efficiency, as input by user or using the 95% default, it seems that every 20th ah as input is not counted rather than each Ah input being slightly stretched to allow for the efficiency loss.
This sort of made me think that trying to calculate a better SOC was probably not worth the effort as there are just too many variables such that even a 1percent accuracy is probably pushing credibility.
I think this SOC will stay ugly :P
Dgd
Quote from: dgd on June 14, 2016, 08:31:02 AM
I thought the SOC was simply calculated from the AmpHours remaining therefore getting a tenth of a percent accuracy was only possible with a battery bank rating over 1000Ah. Since the probability of there being a majority of banks rated much lower then a percent accurate SOC was ok. I also noticed from my graphs that Ahr-remaining and SOC almost exactly follow each other but since my bank is over 1000ah the Ahr graph is more detailed
Not sure im following. I rather imagined that bob rounded SOC to a whole number so that the MNGP would see it thus (any maybe to only occupy 8bits of ram). While i have no illusions about SOC accuracy, im just looking for a smoother curve.
Quote
When looking at the battery efficiency, as input by user or using the 95% default, it seems that every 20th ah as input is not counted rather than each Ah input being slightly stretched to allow for the efficiency loss.
Interesting. Surely the AH counter must be in fractional amp.seconds or some such? How did you figure that out?
Quote
This sort of made me think that trying to calculate a better SOC was probably not worth the effort as there are just too many variables such that even a 1percent accuracy is probably pushing credibility.
I think this SOC will stay ugly :P
Dgd
Oh indeed. You either do it rough and know its rough (imagine that was bobs approach), or you go all out like Bogart did, and try to factor all the coeffcients you know about (just because you can, not because you know its actually going to always work well, as batteries age etc). ( i read somewhere that Midnite and Bogart did some work together some years back, so maybe bob knows a thing or two. )
I did start a purely blackbox derived SOC figure a while back, but havent completed it yet, for various reasons. The biggest question in my mind was how to factor that "charge effciency" percent. My approach was just, each second multiply Iwbjr by 1/3600 of an hour and add that to the tally. If teh increment was positive (charge), scale the increment by the 94% or whatever figure.
But that scale factor is after all a charge cycle average only. During bulk it will be near 100% (99.9). Then tapering downwards as absorb progresses, eventually reaching 0 (EA and beyond current adds no further SOC).
Thats all modellable (i guess). I even got as far as buying parts to do some automated experimental charge discharge cycles on a 7AH AGM, because theres remarkably next to no research done on this. I can dig out what few papers i did find if you want.
Gee aint it bliss that this is all we have to talk about now. Kinda miss those broken net stack days of adventure.
A modbus spec update, maybe? Now that would be sweet icing material.
I first noticed some time ago, using my 10 minute log text web page, that as the Net Ahr number increases the battery Ahr remaining increases at the same time
Then every so often the Net Ahr increases but the Ahr remaining does not.
It didn't take long to realise this was probably because of the battery efficiency figure and extra charging Ahr was going into battery but not seen as Ahr available to take out.
I suppose this is the best way to do it as fiddling with making each Ahr going into the battery so that it is actually a charging Ahr plus a bit extra to allow for battery efficiency seems unnecessarily complicated.
I'd rather work with real Ahr and just pop an extra one into the battery every so often.
Just to be more obtuse I often thought an SOC% ranging from 0 to 100 was not too meaningful since the real useable SOC for FLA was more likely 70% to 100% athough my LiFe bank's 20 to 100 makes SOC more sensible :)
dgd
..and just on calculating SOC% I have done this in code with a KID for my KID web server using a paralleled with WBjr, AtoD device wired to Deltec shunt. Necessary because of the paucity of data that can be extracted from the KID. <sigh!>
It was just complicated fine tuning the data to match what was happening with the KID and battery info needed to be specified and stored in an SD card file along with voltage set points and various timing parameters.
It was pleasing to see the KID ending Absorb and my SOC% nudging at 100% before I had to force the 100% as the voltage dropped to the Float set point
Even that was complex to ensure the charging state was really in float and not just transiting its way to a lower level.
One advantage of this exercise was that it demonstrated how possible it is to make a system web monitor that could be used with any piece-of-junk controller (that reports nothing) and set of batteries and still achieve some pretty accurate charge control information and battery SOC, Ahr remaining etc...
dgd
Quote from: dgd on June 15, 2016, 12:31:19 AM
I first noticed some time ago, using my 10 minute log text web page, that as the Net Ahr number increases the battery Ahr remaining increases at the same time
Then every so often the Net Ahr increases but the Ahr remaining does not.
It didn't take long to realise this was probably because of the battery efficiency figure and extra charging Ahr was going into battery but not seen as Ahr available to take out.
I suppose this is the best way to do it as fiddling with making each Ahr going into the battery so that it is actually a charging Ahr plus a bit extra to allow for battery efficiency seems unnecessarily complicated.
I'd rather work with real Ahr and just pop an extra one into the battery every so often.
May that have been a rounding thing? Add 0.08Ah each minute, after 12 minutes or so the net ah goes up by 1Ah? Surely that math is done in floats, or pseudo float int*100 or something.
Quote
Just to be more obtuse I often thought an SOC% ranging from 0 to 100 was not too meaningful since the real useable SOC for FLA was more likely 70% to 100% athough my LiFe bank's 20 to 100 makes SOC more sensible :)
dgd
Now that the Mrs can see the tablet, shes suddenly all interested in power. And ive had to explain why she cant take it down to 0%.
Quote from: dgd on June 15, 2016, 12:50:57 AM
..and just on calculating SOC% I have done this in code with a KID for my KID web server using a paralleled with WBjr, AtoD device wired to Deltec shunt. Necessary because of the paucity of data that can be extracted from the KID. <sigh!>
Which shunt amplifier did you end up using?
Quote
It was just complicated fine tuning the data to match what was happening with the KID and battery info needed to be specified and stored in an SD card file along with voltage set points and various timing parameters.
It was pleasing to see the KID ending Absorb and my SOC% nudging at 100% before I had to force the 100% as the voltage dropped to the Float set point
Even that was complex to ensure the charging state was really in float and not just transiting its way to a lower level.
One advantage of this exercise was that it demonstrated how possible it is to make a system web monitor that could be used with any piece-of-junk controller (that reports nothing) and set of batteries and still achieve some pretty accurate charge control information and battery SOC, Ahr remaining etc...
dgd
This is kind of what im asking for in the classic. For instance on skip days, it should still reset to 100% if EA is reached and float voltage being held. For the same reason post absorb, the same should occur after a partial discharge, and recharge.
Whats a good classic efficiency figure for AGM? 94 is too low. But it depends on where you cycle your bank.
Hi zoneblue,
There is something that I have trouble understanding.
When you said, "This is kind of what im asking for in the classic. For instance on skip days, it should still reset to 100% if EA is reached and float voltage being held. For the same reason post absorb, the same should occur after a partial discharge, and recharge" It is not clear just what you are trying to accomplish.
Seems to me, that if the Vfloat is not set to Vabs, but SOC is set to 100% when EA has been satisfied, and Vfloat was maintained, that the battery will NOT have been returned to 100% SOC.
Realize that you are using AGM batteries, and that customarily, AGMs have a higher Vflt than do FLAs (like the banks here), but still my FLAs would have only about 60, or so percent of the required charging done, a few hours after Vflt had been reached, on a Skip day. This is difficult for me to quantify, as I am not one who does careful monitoring and data recording of the battery banks here.
Just seems that even with infinite time spent at Vflt, that a battery would not be fully charged, unless the Vflt was at, or very close to the Vabs necessary to fully charge the battery in a reasonable amount of time.
Just trying to understand what you are doing, not trying to be too tedious.
Thanks, Vic
VIc, that is a common enough understanding. However ive watched many charge cycles closely with BB and it seems the the difference between float voltage and absorb voltage is more about the time it takes to reach true 100%SOC. On skip days the exact same charge acceptance taper occurs as on a normal absorb day, thus im led to believe that EA at float voltage is also 100%SOC. At least the classics SOC figure maxes out at 100% as usual.
Whether this is true or not i dont know. I guess one way to find out is to do a full charge cycle to EA on float voltage, then force an absorb and see if the battery will take any more.
None of this would matter much is one could get the charge efficiency figure bang on, but thats not going to happen.
Quote from: zoneblue on June 15, 2016, 05:49:54 PM
Which shunt amplifier did you end up using?
It is a 24bit AtoD for weighing scales from Ebay, I will get part id and photos later
Quote
This is kind of what im asking for in the classic. For instance on skip days, it should still reset to 100% if EA is reached and float voltage being held. For the same reason post absorb, the same should occur after a partial discharge, and recharge.
I'm not sure this would be a true 100% SOC.
The EA figure (so I thought) was only applicable when at Absorb voltage ie the power being absorbed by the battery is reduced to AbV*EA
The EA at Float is obviously significantly less power so I think using the EA here is not indicating the battery is full.
I noticed since installing WBjr several years ago that on days where either the Absorb was not completed
(or more often just a few minutes done) OR Absorb never started that often the Classic would still get to reporting 100% SOC with just the BulkMPPT stage.
If this happened for several days then although reporting 100%SOC I could see that the overnight resting voltage of the battery was reducing which was IMO indicating a much lower SOC.
This appeared to me that either the charge efficiency or the actual efficiency of the battery was not as good at lower charging voltages BUT that the higher voltage Absorb was essential in arriving at a fully charged battery.
So calculating SOC just based on Ahr in and Ahr out scled to some efficiency factor was never going to be that accurate, at least for Lead-Acid cells.
OTOH my LiFe cells behave well with a 99% efficiency figure ???
dgd
Whats a good classic efficiency figure for AGM? 94 is too low. But it depends on where you cycle your bank.
[/quote]
Quote
This is kind of what im asking for in the classic. For instance on skip days, it should still reset to 100% if EA is reached and float voltage being held. For the same reason post absorb, the same should occur after a partial discharge, and recharge.
I'm not sure this would be a true 100% SOC.
Hi guys ! Sorry I have been a bit scarce... Been working feverishly on new PCBs and a bit of bug catching...
The reason we don't keep SOC at 100% with voltage and current below ending amps is because it is calculated based
on amp-hours into and out of the battery and remaining amp-hours. The only reason it resets to 100% SOC after
an Absorb cycle is that this is really the only time it makes sense to be done. Good thing there is at least one time
that this can be done. Of course, it has to be assumed that going from Absorb to Float transitions at the right amount
of Absorb time and MAYBE ending amps but we have discussed even better ways of doing this somewhere on this
forum a while back. Maybe some day.
As for higher resolution, internally the resolution is either 32 bits or even 64 bits because Amp-Hours must be
accumulated as amp-seconds or even smaller ticks to get it right. I guess it could be made 0.1% resolution
but it would take time that I don't have right now.
However, as soon as you can get those modbus specs you want, then you could I suppose calculate all of that yourself
externally if you really wanted it. The WB Jr. only reports back to the Classic ~around~ 10 times per second
so it's not ALL that fast that modbus couldn't read each reading I think.
OK, back on my head for now but I had to pop up and say hi at least. I'll look at a couple more items and see if
I can appear useful.
Happy summer ! I'm tired of being cold and wet up here !
boB