Tracking state of charge

[frackers]

Having just about completed my second generation (sounds good doesn't it!!) controller I'm not convinced that it tracks the inefficiency of the charging process. I'm charge counting but that doesn't allow for losses.

This article sums up the problem - efficiency depends on the SOC and the charge rate.
www.sandia.gov/pv/docs/PDF/batpapsteve.pdf

Has anyone tackled this problem and deduced a reasonable algorithm?

[frackers]

Replies to self...

The battery monitor chip I use in my controller tracks total charge in and total out independently (as well as aggregate) such that the difference between them can be used to determine the efficiency.

For example, after 3 years my system has seen 42250 amp-hours go in and 38921 amp-hours come out - thats 92% efficient.

I'll just tweak the aggregate value by that ratio each time I get to the end of a discharge cycle and that tells me how much needs to go back into the battery to get back to where I was.

[madlabs]

Frackers,

I do "the usual", meaning I've figgered out what my "average" efficiency is and plugged that into my program. It does ok, but as all of them do, creeps off over time. I'm no math whizz, so let us know if you come up with an algorithm, I'd love to plug it into my system and see what happens!

Jonathan

[frackers]

I think my approach will only work for my use case where I have a discrete discharge cycle.

At the end of the cycle I know exactly how much charge I've taken from the batteries (say 45 amp-hours) so I know to put back 45 * 1/efficiency = 48.9 amp-hours. Thats the target I set for the charge cycle and it uses the dump load if required until that amount has gone back in to the battery bank before another discharge cycle is initiated.

Not sure how to sync a continuously variable load (which is why I put a manual sync option into the UI of my controller!!)

[rossw]

At the end of the cycle I know exactly how much charge I've taken from the batteries (say 45 amp-hours) so I know to put back 45 * 1/efficiency = 48.9 amp-hours. Thats the target I set for the charge cycle and it uses the dump load if required until that amount has gone back in to the battery bank before another discharge cycle is initiated.

Not sure how to sync a continuously variable load (which is why I put a manual sync option into the UI of my controller!!)

Just thinking out loud... but why not "weigh" the charging watt-hours by the efficiency of the bank.

So if you are constantly monitoring the current in and out, for every watt-hour *OUT* you add 1, and for every watt-hour *IN* you add less than 1, depending on efficiency. May be only 0.92 Wh for every Wh in.

Make sense?

[madlabs]

Ross, that is exactly what I do, although sadly, I use a factor of .85. This works ok, but it errs both high and low. I zero out the watt hours when the volts hit 14.4 and the net amps in is less than 20. Mostly works, but I do have to manually zero it out sometimes.

Jonathan

[rossw]

Ross, that is exactly what I do, although sadly, I use a factor of .85. This works ok, but it errs both high and low. I zero out the watt hours when the volts hit 14.4 and the net amps in is less than 20.

I think my inverter does something sort of similar - but without the adjusting for efficiency on charge

The 0.92 I used was from the original posters data of 92%.

[frackers]

I think I've come up with something workable!!

When I'm both charging and discharging I save the current state of charge every 10 amp-hours either way in case the controller looses power.

What I'll try is on the discharge side I'll adjust the SOC value by my efficiency factor at the point I stash it in EEPROM, so very close to the way that Jonathan does it.

   // the ICA register, being only 8 bits wide, is not big enough to cover the charge
   // range of a large battery bank. For this reason we take the changes that
   // occur in it and use them to adjust a 16 bit variable. We keep the ICA register
   // in the centre of its range to avoid overflow.
   // We keep a copy of our 16bit pseudo ICA register in EEPROM so it is non-volatile
   gIca += Result.ICA - lastICA;
   lastICA = Result.ICA;
   if ((Result.ICA <= ICAREF - ICABAND) || (Result.ICA >= ICAREF + ICABAND))
   {
      // if discharging adjust ICA down by the efficiency of the charge cycle
      if (Result.ICA <= ICAREF - ICABAND)
         gIca -= (ICABAND * (1 - ((float)gDCA / (float)gCCA)));

      lastICA = ICAREF;
      SetICA (ids[battid], ICAREF);
      eeprom_write_block ((const void *) &gIca, (void *) &eeica, sizeof (gIca));
   }

   // remaining capacity (amp-hrs) = ICA / (2048 * Rshunt)
   gCharge = (int16_t) ((float) (gIca + 0.5) / (float) (2048.0 * Rshunt)); // beware of rounding errors here!!


No comments on my coding style please

[madlabs]

Let us know how well it tracks, Frackers!

Jonathan

[frackers]

Not much wind the last few days but 3 charge/discharge cycles seem to have proved that the new algorithm works OK.

The result is that having set the controller up to use 45 amp-hours to run the pool pump, the discharge curve is tweaked on the fly so that it actually uses 40 amp-hours but reads 45 amp-hours (i.e. about 10% less is used than is indicated). This ratio is derived from the charge counter registers in the DS2438 chip so should 'learn' how the battery bank actually performs.

Longer trials will be required but its better than having no correction at all!!