Greetings,
So, I've constructed a huge off-grid system using 17 Midnite Classic 200s (each hooked to ~2.6kW of PV, for 44.4kW total), eight Outback Radian GS8048A inverters (64kW total), using 36 lithium ion battery modules salvaged from Tesla Model S vehicles (~5.3kWh each for ~191 kWh total). It's a pretty massive setup. Pics here: https://www.dropbox.com/sh/3945sqtx3fviouc/AADUUye2EKAh0N5VHlySbcT2a?dl=0 (https://www.dropbox.com/sh/3945sqtx3fviouc/AADUUye2EKAh0N5VHlySbcT2a?dl=0) and some stats here: http://wk057.solar/ (http://wk057.solar/)
So, yesterday was the first sunny day since the system has been fully online. I had tweaked the charge voltages on the classics a bit, but unfortunately had never had enough PV input until yesterday to have both a full battery bank and normal loads.
Classic networking is all setup for follow-me, each is ethernet connected and I've been logging data with the program I made (https://github.com/wizkid057/midnitelogger) for months now.
Long story short, in the summer time the system will overproduce power like crazy, and I have no intention of selling to the utility nor do I want to have huge diversion loads outside of the basics like just setting my thermostat a few degrees cooler.
What I would like to happen when the batteries are charged is for the classics to output just enough power to cover loads without actually continuing to charge the batteries. I tried tweaking the float voltage a bit, but eventually they would start trickle charging the pack again and this is no good for lithium ion (lithium cobalt aluminum oxide I do believe in this case).
Is there a good way to do this? My custom BMS has cell voltages and such and is able to kill the classics via AUX2 if needed, but killing them just shuts down PV input entirely and loads use the batteries, which seems counter productive while i have 30+kW of PV coming in and should be able to cover 10kW of loads with ease.
My initial thought was to use the modbus tcp interface with the custom BMS software to tweak the float voltage as needed to keep current across the shunts to the battery bank where I wanted it, although this seems like it could be error prone. Ideally it would be great if there were a watts-out limit that could be continuously updated across the classics (individually by my BMS since array orientations vary) to maintain a neutral pack load once fully charged.
Also, I don't plan on charging the storage batteries to full. Setting absorb to ~4.05V per cell with a ~15 minute timer is plenty (comes out to just above 80% SoC) for longevity of the cells. But I don't want to continue to feed them power after this while I still have power to cover loads.
I'm just wondering if this has come up elsewhere or if anyone else has a similar issue with a solution. For now I just have the float voltage set at ~3.9V per cell and the PV output basically drops to nothing once absorb is done, which is not ideal but is safe.
Thanks!
Hi wk..,
Nice LARGE system!
I have NO experience with Li batteries.
A number of folks have been asking for a Classic (and KID, for that matter), adjustable measured battery charge current Limit, for a while, now.
Believe that MN boB has said that it is on the list of probable additions, but, as you realize, there are New Product designs in process that have priority, as they can generate significant return to MN, and make many customers happy to have those great new products. So nice enhancements like this new Limiting function are, and should be, down that list, IMO.
I know nothing of just how such a Limit would be implemented, but this battery charge current limit, settable to 0.0 A sounds very nice. Especially with Li batts, or just regular batteries that have access to large PV arrays, etc.
All opinions, Have Fun, be careful!! Vic
Big is an understatement...! Wow, nice job. Are there more Li cells elsewhere than in the 2 stacks in the garage?
Just a dumb thought flashed past my eyes... could you use a clipper to divert that excess power to or heat that pool with plus opportunity loads?
Isnt just a matter of turning off temp compensation, and keep lowering the float voltage til you get zero charge? As i recall the queensland guy (using calb fepo4 cells) ended up with a slight discharge later in the day, but he got it pretty close in the end.
Set the ABSORB & FLOAT voltages to the same, at the max value you want the batteries to reach, and it will hold it there.
& temp comps = 0
Can't see how that will over-voltage the cells under those conditions.
How many car batteries do you have ? Can they/it safely absorb all the power you are feeding it? Do you have thermal management on the pack ?
In the Model S the batteries are happy to accept charge rates as high as ~1.4C (267 kW for my pack) at up to ~40% SoC and tapers to about C/4 (47kW for my setup) at ~95% SoC. Since the most I expect in a worst case scenario is about 40kW (due to my array orientations I'll never see peak power on both at the same time), and I don't plan on charging past 90%, the batteries should always be able to take whatever I have available until they're charged.
I have the ambient temperature in the electrical room kept at about 64F (~17.7C) since specs for similar batteries favor temperatures slightly below average room temp. I figure the rest of the equipment would appreciate the cool air as well. (High efficiency mini split heat pump unit I have in there uses at most about 2 kWh/day to keep that room 64F in 95F weather). Previously I tested using the inverter charge function charging the pack from the grid at about 40kW. After two hours of charging at 40kW (about C/5) the cell temperatures had gone up to about 75F. The modules do have a liquid cooling loop that may eventually hook up, but with such a small change in cell temperature under the max possible charge... I might not bother for now.
Setting float to the absorb voltage doesn't seem possible (it kicks it back to 0.1V lower than absorb). However, at 0.1V lower the controllers do cover all loads, but they also are continuing to pump power into the pack. The curve looks a lot like a constant-voltage taper that never quite reaches zero since the amperage per cell in my setup at these low rates is very very low.
Today I had the float voltage set ~0.8V lower than the absorb voltage, and the PV output graph, after the absorb stage was over, appeared to resemble my power usage graph pretty closely, but was still trickling a bit of power to the cells as well after a while, confirmed with two clamp meters and my BMS shunts.
Temp correction disabled, of course.
From my understanding of the cell chemistry, a continued low current to the cells like this is very bad for the cells and causes some kind of oxidation or plating of one of the electrodes which could cause premature capacity loss... so this seems bad. Given that, I'd prefer a trickle of a discharge from the pack after it is full while the PV powered loads directly, until it dropped below a certain voltage, then top it off again. I don't know if this bad chemical reaction takes place when trickle charging the cells at below 100% SoC. I can't seem to find much data on this but have put some feelers out to some experts on the matter.
Based on today's data I *think* I could make some relatively good algorithm to manipulate the float voltage on the fly to prevent current flowing to the batteries based on BMS data from shunts, but this is definitely less than ideal.
There does appear to be a tweak for setting the maximum output current... I'll have to tinker with this. If it is adjustable on the fly via the TCP interface this might work perfectly for me. I'd like to be able to feed the controllers a maximum output wattage or current that can be adjusted on the fly based on DC side load (updated say, once per second or two). I'd feel better about some kind of input on an AUX terminal (PWM duty cycle based limiting?) or something rather than relying on TCP-based modbus.
I'll try adjusting the float voltage even further down tomorrow if/when the pack gets full again and see if I can find a sweet spot or something that lets me not trickle charge the cells.
Another idea just crossed my mind... I wonder if I could exploit temperature compensation for this. Basically rig the input from the temperature sensor using the BMS and adjust as needed to keep the batteries from charging when full...
Thats as crafty as all hell. I say give it a go. That is better then messing with the CC setpoints continuously as the latter will impact CC eprom wear leveling. As someone else said WBjr amp limiting is on the cards so at some point that will turn up. Hopefully... Around here these things take time.
Quote from: wk057 on September 07, 2015, 11:11:47 PM
Another idea just crossed my mind... I wonder if I could exploit temperature compensation for this. Basically rig the input from the temperature sensor using the BMS and adjust as needed to keep the batteries from charging when full...
Quote from: zoneblue on September 08, 2015, 04:40:53 PM
Thats as crafty as all hell. I say give it a go. That is better then messing with the CC setpoints continuously as the latter will impact CC eprom wear leveling. As someone else said WBjr amp limiting is on the cards so at some point that will turn up. Hopefully... Around here these things take time.
Quote from: wk057 on September 07, 2015, 11:11:47 PM
Another idea just crossed my mind... I wonder if I could exploit temperature compensation for this. Basically rig the input from the temperature sensor using the BMS and adjust as needed to keep the batteries from charging when full...
Yeah, I'm liking this idea. Does anyone have any specs on the temperature sensor? Would make things easier...
boB provided some info on the Temp Sensor here
http://midnitesolar.com/Forum/index.php?topic=1985.msg18479#msg18479 (http://midnitesolar.com/Forum/index.php?topic=1985.msg18479#msg18479)
I actually just gutted one and found a thermistor hooked to the red+black and green+yellow leads. Showed around 10-11k ohms at room temp. So I swapped it out with a 10k 1% tolerance resistor and plugged it into one of the classics. It showed a pretty stable 25.3C on the temperature readout.
Using my meter to read the resistors:
2.89k = 56.5C
3.39k = 51.9C
9.93k = 25.3C
13.3k = 19.3C
19.6k = 10.4C
23.0k = 6.9C
So it appears to be a β model thermistor with a 25C resistance of 10k. Should be able to emulate this with a digital potentiometers. I'll try a bit later.
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?
kool system,huge investment i envy .If ever you don't have use for an outback inverter please donate :P :P
oh yes i am loving my not so new outback inverter worth the investment and love being at 48v nominal,i have said it before and i am saying it again ,
i think higher nominal voltages is the future for off grid solar .guess our engineering have some work to do.
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.
Quote from: wk057 on September 09, 2015, 09:59:24 AM
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?
Quote from: wk057 on September 09, 2015, 09:59:24 AM
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.
Quote from: zoneblue on September 09, 2015, 05:11:38 PM
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.
Quote from: wk057 on September 09, 2015, 09:59:24 AM
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 :P
Quote from: Halfcrazy on September 10, 2015, 06:24:32 AM
Quote from: wk057 on September 09, 2015, 09:59:24 AM
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.
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
Quote from: Halfcrazy on September 10, 2015, 06:24:32 AM
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.
Quote from: wk057 on September 09, 2015, 09:59:24 AM
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.
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
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.
Quote from: zoneblue on September 13, 2015, 06:13:24 PM
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):
(http://wk057.solar/productiongraphs/2015-09-18.png)
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 :(
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.
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