17x Classic 200s, 4400Ah 44V lithium ion battery bank... few questions

[Halfcrazy]

Upon further investigation, exploiting the temperature compensation doesn't appear to get me a sufficient voltage change.

As for modifying the voltage outputs and/or amperage limits on the fly... this wouldn't be bad for the EEPROM unless those changes were committed to the EEPROM, correct? (Writing 4 to register 4160)... or does this happen automatically at some interval?

We have several customers doing something like this, They are all modifying the Absorb voltage on the fly and simply not saving it to eeprom. As for the network stack this seems to be aggravated by the local app and the customers using something else do not seem to have the issue. I have a 3rd party app talking to 7 classics here that have never lost connection.

[wk057]

Is there a limit to the mv/degree setting?

Epprom, not sure exactly when the eeprom write occurs, but both those settings are of necessity non volatile, so must occur somewhere. Bob might chime in.

But hey man, your other issue there is the netwrok stack issues, which are still being resolved. I wouldnt go relying heaviliy on ethernet communications at this stage in the firmware.

Upon further investigation, exploiting the temperature compensation doesn't appear to get me a sufficient voltage change.

As for modifying the voltage outputs and/or amperage limits on the fly... this wouldn't be bad for the EEPROM unless those changes were committed to the EEPROM, correct? (Writing 4 to register 4160)... or does this happen automatically at some interval?

Yeah the mV per C setting seems to max at 10mV.  So, at best I can swing it 1V or so.

As for ethernet, I've been using the ethernet link flawlessly with my logging software for months now and I have about 5 months of data polling every charge controller at 5 second intervals.  The ethernet issues seem to stem from opening and closing the TCP socket, which I don't do.  I just maintain a connection and auto-reconnect after a delay if it is lost.  Has worked very well.  See the historical data on http://wk057.solar if you don't believe me

[wk057]

Upon further investigation, exploiting the temperature compensation doesn't appear to get me a sufficient voltage change.

As for modifying the voltage outputs and/or amperage limits on the fly... this wouldn't be bad for the EEPROM unless those changes were committed to the EEPROM, correct? (Writing 4 to register 4160)... or does this happen automatically at some interval?

We have several customers doing something like this, They are all modifying the Absorb voltage on the fly and simply not saving it to eeprom. As for the network stack this seems to be aggravated by the local app and the customers using something else do not seem to have the issue. I have a 3rd party app talking to 7 classics here that have never lost connection.

Didn't catch this post because it was on the next page.

Very good to know.  I'm likely going to go this route.

[inMichigan]

Amazing...

I scrolled back through your output graphs to find a Biggie to show my wife.  Without grid-tie sell, looks like you don't utilize all that PV very often.   I suppose if you run your battery down just before a beautiful day, you'd get a cool set of data since you can dump current into those batteries at quite a rate.

Not exactly the same situation, but for FYI:

I also have lithium in the form of CALB cells with 2 Radians.   For about 2 months while waiting for net metering, I ran in Radian's Grid-Zero mode.   I have absorb/bulk/float set to 3.400 V/cell.   In this mode, my 14 kw of PV could easily outproduce my house loads.   As the sun dropped, the bank voltage would drop to V_DoD & V_Sell = 3.344 (this is how Radian handles selling to itself).    I am willing to exchange a lower SOC in hope for a longer battery life.  So, my daily cycle never let any long term very low current creeping in to raise the voltage too close to 100%.   Now that I can net meter, my sell is usually 3.344 V/cell.   

In grid-tie sell mode (instead of grid-zero mode), the Radian's don't attempt to invert for my house load below V-sell(not sure about their own power consumption, & the sleeping CC's have a small draw), looking at a few nights I see this kind of behavior...

As measured and reported by the FN-DC with battery bank shunt:
V/cell       situation
3.338  sun is out mid-day
3.312 sun has gone down 7 pm
3.305 midnight
3.299 6 am... no PV output

After 7pm and until the sun is shinning, the shunt is reporting 0.004 amps 'out' of the battery.   Some hours are '0', some early evenings have a rare 0.002 amp 'in'.   I assume this means the current flow is so low that S/N is iffy, but that being the point, almost no current flow.

inMichigan

[zoneblue]

As for the network stack this seems to be aggravated by the local app and the customers using something else do not seem to have the issue.

If you maintain open connections, yes. If you try to open read and close the connection it is not at all stable. The benefit of being able to do this is to allow the local app or other users to access the classic aswell.

The ethernet issues seem to stem from opening and closing the TCP socket, which I don't do.  I just maintain a connection and auto-reconnect after a delay if it is lost. 

Exactly. Its the same here.

However if you do it this way, you then encounter a different issue, frequent classic reboots. On a lite this is problematic in the sense that the classic loses clock time and confuses end of day eprom writes, but in general it means SOC anomolies, Wh/d and other data anomolies.

[inMichigan]

In your load panels below the Radians, I don't see the standard Outback GFCI DC breakers.      I have a 2 Radian system and found that hard way that two 2-poles should have been a single 4-pole mounted within just 1 panel.  While on the conference call with OB, my contractor (never installed a Radian before) and his distributor (never sold a dual Radian before), I asked what happens if I ever add a 5th CC since the larges GFCI they sell is 4-poles.   The answer was to use the more expensive FlexMAX Extreme that can have their internal GFCI's daisy chained in some manner.

Anyway, I am interested in how you solved the GFCI situation?

inMichigan

[wk057]

Local AHJ said that the GFCI within the Midnite Classic 200s was acceptable.

So the PV combiners have breakers on the input side, the Outback load center has 80A breakers on the output side, and Classic does the GFCI and AFCI.

I have two to three 80A battery side breakers in each Outback load center.  Only one has three, actually.

I don't have the info in front of me, but if I recall correctly the GFCI trip is configured to be propagated through the Classic local network chaining as well.

[wk057]

However if you do it this way, you then encounter a different issue, frequent classic reboots. On a lite this is problematic in the sense that the classic loses clock time and confuses end of day eprom writes, but in general it means SOC anomolies, Wh/d and other data anomolies.

I have about 20,000,000 data points from the Classics so far at 5 second polling intervals (17 classics, although all 17 were not online until recently).  Occasionally one has rebooted mid-day.  This has happened less than 5 times since I started logging, according to the data (looking at reset kwh_today events in my database that were not at midnight).

Fortunately I don't use any of its logging or time-based data for anything anyway.  I calculate my kWh produced using the polled data, which gives me accuracy with what the classic reports to within less than 0.5% error in practice.  This also lets me calculate the PV side and battery side power.  I use the time stamps from my logging machine, which is NTP set.

All of the classics are running the same out of date firmware (don't know the version off hand, but it's something like a year old maybe?), but I have no particular reason to update them since everything is working as I want it to.  I also didn't include a permanent USB connection for each one in my install, so, makes the task less enticing.

I've been compiling stats and have graphs of the data collected accumulating on a site I whipped up, http://wk057.solar/

For example, here is one from the other day (best day since I got my entire array online):


All of this data is calculated from my 5 second polls of all 17 charge controllers using the midnitelogger software I whipped up previously.  (I've made no revisions to the code since my last git commit a while back, either).  The watts graph is actually the battery side (what the classic reports as watts), since pv_amps*pv_volts is always higher.

kWh is calculated by a crazy sql query that sums up watt seconds based on the watts value and the time since last poll.  It matches to within 1% of the sum of the kWh_today fields of the charge controllers, and is likely more accurate since the resolution is a bit higher (watt seconds at 5 second polling...).  While I know the watts value reported every 5 seconds is instant and isn't a 5 second average, it's close enough with 5 second resolution.

Working on exposing more stats based on this data and AC-side usage data.  A net graph is probably next on the list... lining up AC usage data with PV output data and showing it on a graph that shows the net power usage and another that shows the net battery bank usage.

Should be pretty sweet when it's all done.

P.S. - No direct sunlight since early Friday afternoon

[zoneblue]

Ok. We use the server time as well. But pretty sure the classic is often confused about what time of day it is. If you have full classics then they will get time from the mngp. Lites dont have that. Have previously shown graphs that show our classic reboots on average about once or twice a week. Might be the one second sample interval. Just for kicks might try slowing it to 2s and see what effect that has.

[ebenbayer]

Jason,

That is a killer system.

Might I ask whats driving your load situation? I assume you likely drive an electric car... but is that the lions share?

Eben