Earth Notes: Expanding and Optimising Off-grid PV System for Mid-winter

Attempting to move 10 percent of mid-winter electricity demand off-grid...
storage

Goodbye To Lithium, for now

For about 5 years I have been testing and integration of a LiFePO4 battery with my off-grid solar PV system and its main (gel) lead-acid battery bank.

2016/05/22: LiFePO4 (LFP) battery removed and all PV input is now feeding to the ~400Ah gel lead-acid (LA) bank. The ~400Ah of lead-acid was itself integrated into the system 2011/01/14. The 'test' is done after ~5 years! The observation is that the combination works well, but the complexity and partitioning of available energy may not be worthwhile.

In May I also beefed up the lead-acid battery wiring with purpose-made cables (35mm^2 cable, length 25cm, lugs M8) between batteries as well as back to the controller, to minimise impedance and losses.

The Upgrade Plan

2016/05/23: the current plan is to put ~300W--500W of PV (~30Vmp) on the MPPT controller, and feed a nominal 12V set to a cheap ~20A PWM controller to get some value from any 12V panels retained. If it seems as if the current (15V/200W) MPPT is missing significant energy mid-winter then the 12V string may be moved back to it and a new 20A or 40A MPPT controller purchased for the 30Vmp strings. (Note: PWM 20A controller ~£25, MPPT ~£100.)

I quite fancy a 12V kettle instead of using the 3kW mains kettle; at ~30Wh per cup, maybe 180Wh/d. Rated 10A, so well within wiring ratings (~20A for 4mm^2), but given 15s@3kW, and this being 25x slower, ~6m to boil water for a cuppa (eg when the sun is out) seems plausible.

2016/05/27: LA battery getting first good solid uninterrupted absorption charge in a long while (11:10Z--14:20Z ie 3h @ 14.1V).

Here is the simplified system's schematic (PDF).

simplified schematic core

Mid-winter Blues

The big 5kWp+ grid-tied array on my roof only generates an average of about 1.5kWh/day mid-winter out of our ~5--6kWh/d demand. Were the big array south-facing rather than east and west, it would generate maybe double, though, realistically, I wouldn't have that much roof facing south!

I have a very limited amount of south-facing wall relatively unobstructed, particularly from just before noon mid-winter when the sun-arc is small.

My target is to obtain ~500Wh or ~10% more of our daily electricity demand (also can be viewed as capturing one third more energy daily) in mid-winter by expanding the PV system somehow.

As a first step, the 'dump' (FTTC/router) network equipment load should be kept off-grid almost all the time (yellow hatching for this sample day below), in addition to the RPi2 and its always-off-grid few watts. (The unhatched part below is where it was light and the grid was not in 'red' a high carbon intensity time.)

battery voltage and dumping

Seeing the cheap (second-hand) PV (<40p/Wp Spring 2016) at Bimble Solar got me all excited, ie at something like one tenth what I have paid in the past, and made me think that a significant upgrade might be possible. (Note that Bimble's prices are good, but some new panels from elsewhere are not vastly higher, and for the cheap options I have to give up ~25% of the nominal generation capacity in the ~1.6m by 1m panel format.)

The south-facing wall space is occupied by a motley collection of 12V-nominal panels, not maximising energy collection ability, and the previous complex LFP and LA separate strings made such maximisation difficult while being kind to all the batteries, thus the reason to scrap the LFP element at least for now. There is maybe at best (without anything too ugly by my low standards) ~4m by ~1.5m usable space, though partially shaded, realistically a maximum of 500--700Wp might squeeze in there.

Also, when I had the last part of my grid-tie system put in I had these spare rails put up:

So about 34cm/13.5" rail centre to rail centre and about 3m/10' long in an ~1m gap. And I have a bag of miscellaneous fixings/fastenings which may be Unirac Solarmount or very similar, in which case I seem to have 8x C clamps (1+7/16") for 33--36mm module thickness which accords with the 35mm-thick installed Sanyo HIT-215NHHE5 panels. As of 2016Q1 it might be possible to easily place 250Wp--600Wp up there.

So I could reasonably hope for 500Wp+ south facing (~500Wh/d mid-winter), and 300Wp shallow west-facing which could help when overcast and in afternoons.

The existing size of my grid-tie system (above G83 limits) and the presence of an export meter receiving FiT (Feed-in Tariff) means even the paperwork for connecting a small amount of extra PV, eg with microinverters, would probably be horrible.

The usable capacity of my (probably somewhat tired) 12V 400Ah gel lead-acid bank is well above the 500Wh/d target, and so it seems easier to capture that extra energy off-grid and find sensible ways to use it from there.

(Note that several sources suggest a maximum sustained charge rate for gel of about C/3, with a sensible charge controller to regulate it, which suggests that over 1kW/100A of PV could nominally be fed in to the bank.)

For example, it could be worth adding an inverter and transfer switch to take our mains lighting load off-grid when the battery SoC is decent, and the demand from our lighting is probably a similar amount.

Or, for example, making sure that the current loads (RPi+networking) are off-grid more of the time, which might be close to that 500Wp, with some opportunistic loads such as a 12V kettle to make use of some excess.

2016/05/29: the current plan implies preserving some of the existing panels (maybe ~160Wp) on a nominal 12V string, while putting two 260W panels on a nominal 30Vmp string (one on the roof could join them) in prime spots vertically mounted to minimise clutter and reclaim some patio! And maybe one more 260W panel could be roof mounted when I am feeling brave, though I may choose to wire it on as well as clamp it, given my inexperience! It looks as though the Unirac fixings I have would accommodate my current 100W 12V panel (NES40-5-100M, 40 cell, 20Vmp), lengthwise (probably not ideal for wind loading), and would not accommodate (in terms of panel thickness) the cheap 260W panels that I have been salivating over.

Test Mount with Al Brackets

2016/05/31: aluminium (wall-) mounting backets arrived today, and I have tested them out with the ES-62T (62W, triple junction, 10kg) panel. I will need to up my game at least a little when mounting heavier (18kg) panels.

The easily-available unobstructed south-facing wall space sections are ~1320mm+ vertically (with some ground clearance), E to W, now are used as:

a
(obscured by bushes)
b
set back, 1150mm x 1320mm+, could accommodate 40W panel
c
2.4W panel, tested, still functioning
d
(set back, tree in front, could maybe accommodate 20W amorph horizontally)
e
1120mm, currently has 40W panel + 20W mono at foot
f
set back, 1150mm, best insolation, currently has 100W + ~20W amorph
g
ES-62T 60W panel now mounted on wall ~30cm from the ground

(f) + (e) are targetted for 250W+ panels (~1650mm x ~1000mm) as having the best (mid-winter) generation potential.

See panels in sections e/f/g below.

main panel set (e/f/g) with ES-62T on wall

2016/06/05: some small potted plants have materialised below the 60W panel, hurrah!

Power Manager Snapshot

2016/06/10: I'm happy with estimation of battery SoC and handling of the optional/'dump' load (moving up to and extra ~300Wh/day off-grid), for example accounting for sag from discharge and lift during charging, so I've taken a code snapshot. I use the grid-tie output meter as one whopping great photocell, deciding when the battery should be being charged or not, and when I want to take the optional load off-grid to reduce night-time 'vampire' load (by a whole 13--14W)! (Graph for today...)

Also chatted today with builders about getting the 100W panel on the roof while we get some guttering issues fixed.

I'm writing this after sunset, with the server, Internet connection, laptop and desk light all off-grid (the laptop on its own battery).

Cabling for Two Strings

2016/06/11: significantly re-arranged and tidied (and shortened) wiring from panels, now not coming into the house at all, to make separate running of ~17Vmp and ~30Vmp strings to controllers near battery bank possible; currently the two circuits are combined at the controller and the '30Vmp' circuit is still being fed by the ES-62T panel.

2016/06/15: ordered some Schottky dual diodes (common cathode) 20A 100V to combine the two large panels in TO220AB and TO220FP packages (the FP, NTSJ20U100CTG, insulated tab, makes heatsink management easier). At worst the diodes might have to dissipate 10W (0.5Vf@20A for ~600W@30Vmp), but given for example a maximum 200W handled by the SS-MPPT-L a peak diode package dissipation of ~3W is more likely.

2016/06/22: have ordered a cheap 12V-nominal PWM solar controller to test. Bigger picture: given the very cloudy (climate-change 'blocking' jet-stream) weather and poor solar generation that we've been having for weeks, along with a huge drop in (retail) PV prices per Wp, I'm more and more inclined to think that overspecing PV wrt to inverters/controllers and demand, to deliver useful output on non-sunny days, eg now and in the winter, is a generically sensible approach. Don't maximise mid-summer output: optimise for cloud and winter and dump excess happily and safely in the way that PV almost uniquely allows. That helps to provide something useful and zero-carbon year-round, with some opportunistic extra fossil-fuel (etc) avoidance in summer.

2016/06/25: hmm, wrong PWM controller arrived yesterday; hoping for next week. Meanwhile here is the proposed new schematic showing some of the 12V string moving to the new controller as an experiment to make sure that it still works reasonably well. With PWM as this new cheap 'temporary' controller is, there is some expected loss of available power into low batteries cf MPPT, eg in the morning where these panels on the east of the house seem to have been especially useful. Note that the LS2024RP is positive earth, so for example the -ve string lines cannot be parallelled.

2016/06/26: a LTC4151 might make a nice high-side power monitor for my off-grid solar panels with an input range 7V to 80V (so good even for 17V and 30Vmp panels) and an I2C interface ready to talk to a low-power MCU such as V0p2 REV11... One such V0p2 could listen to 8 such devices and transmit stats by radio, being powered from the string at the combiner box. The MCU could also drive 'ideal diode' (P)FETs for the key string panels to minimise losses, while lower-power 12V-nominal panels could maybe directly use (say) a LTC4358 or a AUIRF4905STRL P-channel MOSFET Transistor, 70A, 55V 'backwards'. Note that the saving is likely of the order of 200mV at ~10A, so 2W, so it is reasonable to ask if the <1% savings from a ~200W+ panel is worth the complexity and cost, beyond simply establishing that it works. Most pertinently at the moment, with an under-specified controller, are there real savings at low powers and light levels in winter when needed. Eg at 30V/30W/1A the savings may be more like 300mV and therefore 300mW at 10% generation (typical overcast winter) output, still at the 1% level.

Brave New World

2016/06/29: installed LS2024RP PWM 20A controller and moved ~100Wp of 12V-nominal solar to it including ~15Vmp 60W panel; battery type set to 2 (gel) circa; 10am--noon. There are a number of wiring inadequacies for the new controller that ought to be fixed, particularly two:

2016/07/02: day and month month graphs just-post-solstice as snapshots before major Wp addition, for comparison with post-upgrade and mid-winter...

Now also in possession of (ratchet) socket set including 8mm socket for panel fixings: finished off existing ES-62T (60W) panel mount.

2016/07/03: my first M4 connector with crimping to replace failed one in -ve lead of 100W panel that had been temporarily replaced with a connector block.

I am not at all convinced about the new connection; 4mm^2 wires pulled out even when re-crimped on smaller setting, so backed up with solder. Also, the M4 connector evidently did not mate properly the first time (no connection, detected by lack of foward bias at diode in junction box) so took it apart and removed stray solder blob and reassembled. Connection now apparently working but I will keep observing; this one may end up difficult to access on the roof so its integrity is particularly important.

2016/07/19: gah! When I finally get to order the panels only one is in stock which is a huge nuisance. This probably means I won't get 500Wp installed for the winter (unless I can a closely matching panel), and so the 100W panel may not make it up to the roof either... (May therefore end up with one string ~30Vmp 255W, and the nominal 12V (PWM) string 40+100+60+40W.)

2016/07/21: hurrah! Two substitute (Canadian Solar CS6P-255P) panels arrived, so now I just need the fixings etc to put them up and wire them in. I expect to upgrade the system in stages, eg putting up just one 255W panel first, alone feeding the SS-MPPT-15L, having moved all the residual 12V-nominal panels to the PWM string, retiring the 100W and a 20W panel at least temporarily.

CS6P-255P spec: 255Wp -0+5W, 30.2Vmp, 8.43Amp, 37.4Voc, 9Asc, module effciency 15.85%, -0.34%Voc/C, normal operating temp 45C (+/-2), (NOCT 800W/m^2, 20C: 185W, 27.5Vmp), polycrystalline, 60 cells (6x10), 19kg, 1638 x 982 x 40mm.

It's Huge

2016/07/22: (noon, 11:00Z) swapped over the strings and controllers: the brown/black pair that will be all the 12V nominal now feeds the PWM, the grey/green pair that will be the 30Vmp panels now feed the MPPT. The latter (grey/green) pair currently has the 60W (ES-62T) panel on it.

3pm (14:00Z) the first 255W CS panel is connected up (not yet cleaned) but the aluminium brackets don't seem to fit it, so it's just propped up against the wall for now (bah! again!). The CS panel is connected to the SS-MPPT-15L with no blocking diode, the 60W (ES-62T) panel has been moved to the 12V string, and the 100W+20W have been disconnected. A significant jump in battery voltage suggests that everything is working (on top of testing various points with a multimeter...).

(The CS panels are quite large in the flesh, taking up a whole garden wall panel!)

The positioning of the CS mounting holes along the edges is not as good for me as the JA panels as I have to mount this vertically on a wall and the furthest down from the 'top' edge might be above the top of the wall! So I am faced with possibly drilling new mounting holes, which worries me somewhat.

2016/07/23: some full sun on the new panel arrangement today, with the battery voltage shooting up to absorption, then sitting at float for several hours (second day of those shown), which is exactly the type of behaviour I am hoping for. (Plus the tweaked powermgr behaviour allowing dumping to ride through brief dips into HIGH and OK.) The rise to absorption happened almost as soon as the sun came round the house to hit the new CS panel.

2016/07/25: a couple more days with interrupted sunshine, but the battery is clearly getting to something like float and getting a good charge.

2016/07/30: did first test hole in frame where it can work with the Al brackets. Somewhat slow with the hand (battery) drill, but not much drama. Had tape on drill bit and a ceramic tile and thick magazine behind hole to protect back of the panel if need be, but need wasn't.

2016/07/31: I'm doing the top holes 40cm from the 'top' of the panel, which will thus be 20cm below the top of the wall. I have bodged each of them in a different way, but basically made a pilot hole with a 4mm bit, and the 6.5mm bit makes a big enough hole for the bolt. There is quite a small 'good' area close enough to the edge for the Al bracket to work, but far enough for the nut not to foul the inside of the frame. In this case aiming for the middle of the ridged region seems about right. I'm putting the 'bottom' holes near the short edge to bear the weight as near the ground as possible (18cm from the short edge, midway between the existing holes). I am orienting the panel 'upside down' to kept the connector/wiring out of site at the base of the wall. My battery hand drill (~14Wh) ran down after making just the first two holes! As the drill bit breaks through it tends to catch and actually make the bit slip in the drill chuck, requiring some TLC to finish. Yes, for the four holes, "each bodged separately" as the TV ads might say, but done. Mounting on the wall is for another day...

2016/08/01: with the help of my kids, got the (second) CS panel mounted. More bodging, but it seems OK, with much of the load bearing directly down through a brick to the ground rather than being taken by the wall. Not convinced that it's electrically right, looking at the battery graph, even though it's an overcast day. May need TLC later. Did measure ~33Voc, and 29V when connected up, which is promising.

a
(obscured by bushes)
b
set back, 1150mm x 1320mm+, could accommodate 40W panel
c
2.4W panel, tested, still functioning
d
(set back, tree in front, could maybe accommodate 20W amorph horizontally)
e
1120mm, currently has 40W panel + 20W mono at foot
f
CS6P-255P 255W panel now mounted on wall ~8cm from the ground
g
ES-62T 60W panel mounted on wall ~30cm from ground

(e) remains due the second 255W panel.

CS6P-255P on wall

2016/08/03: making the extra holes in the second CS panel frame for mounting. Adjusting the hole positions slightly to try to hit mortar less. Adding extra mounting hole at bottom hoping to help load distribution, also more allowance for 'bad' mounting holes generally. Have taken down the 40W amorphous panel and removed the 20W 'floating' one.

2016/08/04: am: mounted and connected the second CS 255W panel.

a
(obscured by bushes)
b
set back, 1150mm x 1320mm+, could accommodate 40W panel
c
2.4W panel, tested, still functioning
d
(set back, tree in front, could maybe accommodate 20W amorph horizontally)
e
CS6P-255P 255W panel now mounted on wall
f
CS6P-255P 255W panel mounted on wall ~8cm from the ground
g
ES-62T 60W panel mounted on wall ~30cm from ground
2x CS6P-255P on wall with ES-62T

2016/08/05: some half-decent sunshine and the battery bank has probably had its best charge ever while in my custody! Note that the really steep rise around 11:00 UTC should actually come forwards in winter as the sun arc is smaller and the 255W panels will be in shadow from the house (to the east) for less or none of the day. We'll have to see...

battery voltage and dumping 5th and 6th
main changes made; 510Wp 30Vmp in place

2016/08/07: have lashed up MacBook Air via car (12V) universal 70W laptop regulator (Maplin N59AC) set to 15V and so I am back to being able to run my Mac off-grid, eg as a dump load. Note that the N59AC is not very efficient (~80%?). I happen to be able to charge my phone via the laptop this way too. Can aim to run server+Internet+light+MBA+phone off-grid all year this way.

2016/08/08: I will try to measure battery voltage at the battery using the SS-MPPT-15L controller over MODBUS over RS232 so I will be ordering a PC MeterBus Adapter. This should largely eliminate the effects of voltage drops in the supply cables when estimating SoC (leaving genuine sag from the battery bank itself). This should also allow measuring (some of) the power flow into the bank, and out to the loads. The are various solutions for having the RPi talk MODBUS to the SS-MPPT-15L including this on Fieldlines with Python, though I may prefer to keep everything in C for efficiency and use the LGPL libmodbus (see RPi build notes). Also see SolarNetwork in Java.

2016/08/15: with all the MODBUS data detail there are some nuggets. For example, coming up to solar noon and the battery in absorption with dwindling charge current I can see these values:

Sweep_Pmax (mW): 158264
Power_out (mW): 94457

which indicates that ~60W of power that could be used is not because the batteries are getting full and the ~40W of load that I have on at the moment is not enough to absorb the rest. (Why with both CS panels in direct sun the Pmax isn't nearer the controller's 200W maximum, I don't yet understand.) Note that this is ignoring power/charging from the 12V-nominal string via the other (PWM) controller.

Oh, and as of yesterday the SS-MPPT-15L claimed that it had put a total of 202.5kWh of charge into the batteries over ~60,000h. And that keeping my battery bank in absorption takes ~60W, which would have been difficult to do with only ~140Wp of sun-facing panel at noon mid-winter. Float appears to soak up ~25--40W. The main charging window at the moment seems to be ~10:00--16:00Z.

2016/08/16: I have started collecting some cumulative off-grid stats. In particular cumulative generation (kWh) as reported by the SS-MPPT-15L. It seems evident that unlike the grid-tie PV which generates all that it can and exports it to the hungry grid, the off-grid system is only going to 'generate' at most the load plus any system and battery losses, ie providing more load may increase the reported generation.

2016/08/18: operating the battery DC breaker to the SS-MPPT-15L works, ie it produces a battery fault, but it does not result in the load being disconnected, so I am likely to replace the load fuse with a 20A breaker somewhere easy to access.

Also, measuring the voltage drop across the (20A MAXI) load fuse showed 15--25mA at an assumed ~2A draw, thus implying ~10mΩ rather than the expected ~3mΩ.

Inspection also shows that I could probably take another 1m (9mΩ) out of the cable run back to the house/load from the SS-MPPT-15L, so maybe ~20mΩ or 20% max that can be taken out of the load circuit. The run upstairs can be doubled up also to reduce losses to the Mac adaptor which at ~70W peak (~5A) dwarfs the normal loads; maybe 100mV out of the ~500mV drop (~4% to ~3%) to it could be eliminated.

Some of this navel-gazing is because there has been quite a lot of power-LED flickering on the RPi, and it hung at 2am two days ago, which may be related. I adjusted some parameters (eg on the Gallery) to be less aggressive on power use but there is still some flickering. I may tighten up the supply (eg shorten leads, improve connections) from RPi all the way back to the solar controller to alleviate this issue and to reduce marginal losses.

2016/08/20: load fuse swapped out for circuit breaker and tested. No obvious change in load supply impedance to RPi observable.

2016/09/02: observation suggests that at least at this time of year output of primary panel array is 1/2 to 1/3 of that of grid-tie prorata. For example, at at rather dark 13:12Z the grid-tie was generating 183W and as 13:16Z the primary array was generating 9.9W (presumably heavy cloud). Given relative array sizes maybe 18W would be expected. It will have to be seen how this effective efficacy ratio changes though the year (hopefully for the good in winter).

2016/09/04: further supply impedance notes. This pair of log entries:

2016/09/04T21:30:06Z AL 0 B1 12357 B2 -1 P 25048 BV 12103 ST OK D e A1P 0
2016/09/04T21:40:06Z AL 0 B1 12397 B2 -1 P 15695 BV 12243 ST OK D e A1P 0

suggests ~40mΩ internal battery impedance and a further 100mΩ towards the load at least at the Vbus sample point mear the RPi. The latter figure confirms earlier values, the former is possibly higher than expected, though may be partly measurement granularity at the controller, and partly caused by 3 days' relatively poor charging (no float, little or no absorption time).

2016/09/05: checked output of the two CS 255W panels with multimeter in overcast conditions. Each separately delivering ~330mA Isc (~10W) and into the MPPT controller, so ~20W total vs ~560W from grid-tie system. So CS panels delivering ~4% of rated/peak, grid-tie ~11% of rated/peak, so confirming the 2x--3x ratio in actual:rated for vertical panels vs roof. May be extra good to get the 100W panel on the spare roof rails!

Possibly as a result of me fiddling with (checking) the CS panel connections, and/or because the battery is low enough to absorb the energy, the current into the battery just briefly hit the 15A limit (just over 200W):

2016/09/05T12:40:06Z AL 13007 B1 14148 B2 -1 P 26118 BV 13923 ST VH D h A1P 182754
2016/09/05T12:50:06Z AL 15000 B1 13926 B2 -1 P 23382 BV 14017 ST VH D h A1P 212347
2016/09/05T13:00:06Z AL 4984 B1 13349 B2 -1 P 24229 BV 13088 ST OK D r A1P 66268

2016/09/07: a few dull days and the system is starting to struggle, so have prioritised different calls on dump load; according to PVGIS this should be one of the better months!

2016/09/07T07:20:06Z AL 191 B1 12272 B2 -1 P 28705 BV 12093 ST L - L A1P 2326

But then all looks good with ~3 hours of 200W+ charging (~800Wh for the day), though not quite enough to hit float and thus 'FULL' status.

bad day, good day

2016/09/10: typical total 'office' (evening, non-aggressive) off-grid load ~26W, for:

which implies consumption fairly close to the 500Wh/d generation target.

(2016/10/01: verified that mains load for Internet+Loop is zero when nominally powered as dump load, 13.7W from mains when not 'dumping', as measured with Maplin N67HH plug-in meter.)

2016/09/10T19:00:07Z AL 0 B1 12452 B2 -1 P 24705 BV 12234 ST OK D e A1P 0
2016/09/10T19:10:06Z AL 0 B1 12436 B2 -1 P 25395 BV 12234 ST OK D e A1P 0
2016/09/10T19:20:06Z AL 0 B1 12433 B2 -1 P 26135 BV 12225 ST OK D e A1P 0
2016/09/10T19:30:06Z AL 0 B1 12433 B2 -1 P 24991 BV 12225 ST OK D e A1P 0
2016/09/10T19:40:07Z AL 0 B1 12433 B2 -1 P 25351 BV 12215 ST OK D e A1P 0
2016/09/10T19:50:06Z AL 0 B1 12433 B2 -1 P 26073 BV 12234 ST OK D e A1P 0

Parallelled +ve connection (and generally improved) from power cupboard to desk to better support heavy recharge demand from laptop, and shortened power route to RPi in hope of reducing measured supply impedance and red power light blinking (but it is still blinking when RPi is working hard).

2016/09/11: voltage drop debugging: noting snippets of output from ssmppt15l-modbus and powermng -v under reasonable load (recharging my laptop at ~40W) there is as much as a 500mV from from battery to Vbus (at the RPi), though 246mV is shown in this snippet, of which 100mV is between battery and the load output of the SS-MPPT-15L.

Vb_f battery voltage slow (mV): 12522
Adc_vl_f load voltage (mV): 12421
Adc_ic_f battery charge current (mA): 510
Adc_il_f load current (mA): 3141
Load power (mW): 39332
SS-MPPT-15L Vb_f slow battery voltage (mV): 12443
SS-MPPT-15L Adc_il_f load current (mA): 2312
Load power (mW): 28769
Input flag DUMPING is unset.
SS-MPPT-15L Adc_ic_f battery charge current (mA): 404
External flag file /var/log/SunnyBeam/LOW.flag is absent.
ADC command 6a 80
ADC (6a 0) response 1300 (5 14 0)
Battery voltage 1 local (LA) 12197mV, 2 (Li) -1mV.
Supply drop B1 to BV 246mV; implied supply impedance 0.106401ohm.

Extending the (verbose-mode-only) calculation inside powermng to use load terminal voltage explicitly yields a slightly more comforting snippet, ie that a significant chunk of the voltage drop (possibly a quarter to a third) happens before my wiring loom, indeed before the controller's load terminals.

Verbose mode ($Id: powermng.cpp 15411 2016-09-11 08:40:19Z dhd $).
SS-MPPT-15L Vb_f slow battery voltage (mV): 12473
SS-MPPT-15L Adc_il_f load current (mA): 1472
Load power (mW): 18361
Input flag DUMPING is unset.
SS-MPPT-15L Adc_ic_f battery charge current (mA): 658
External flag file /var/log/SunnyBeam/LOW.flag is absent.
ADC command 6a 80
ADC (6a 0) response 1307 (5 1b 0)
Battery voltage 1 local (LA) 12262mV, 2 (Li) -1mV.
Supply drop B1 to BV 211mV; implied supply impedance 0.143342ohm.
Adc_vl_f load voltage (mV): 12397
Supply drop controller to BV 135mV; implied wiring impedance 0.091712ohm.

(It may be time to remove the dual Schottky feeding the RPi's 12V-to-5V step-down regulator, wasting a little power, and that may be adding to the apparent supply impedance.)

2016/09/14: two days in a row hitting FULL though interestingly float state at the controller can persists down to ~13.2V ie at a voltage that I consider merely 'OK'.

There seems no quick way to interrogate the controller to find when it last considered the battery full, ie in float; reading up to 32 days' historical data (of 32 bytes each) might be needed.

2016/09/18: some disappointments:

bad day, dump oscillating
2016/09/18T00:30:06Z AL 0 B1 12421 B2 -1 P 907 BV 12394 ST OK D e A1P 0
2016/09/18T00:40:06Z AL 0 B1 12320 B2 -1 P 16078 BV 12168 ST OK D T A1P 0
2016/09/18T00:50:06Z AL 0 B1 12302 B2 -1 P 16178 BV 12150 ST OK - m A1P 0
2016/09/18T01:00:07Z AL 0 B1 12397 B2 -1 P 881 BV 12365 ST OK - t A1P 0
2016/09/18T01:10:06Z AL 0 B1 12397 B2 -1 P 905 BV 12384 ST OK - t A1P 0
2016/09/18T01:20:06Z AL 0 B1 12397 B2 -1 P 905 BV 12384 ST OK - t A1P 0
2016/09/18T01:30:06Z AL 0 B1 12418 B2 -1 P 907 BV 12394 ST OK D e A1P 0
2016/09/18T01:40:06Z AL 0 B1 12314 B2 -1 P 16193 BV 12159 ST OK D T A1P 0
2016/09/18T01:50:06Z AL 0 B1 12296 B2 -1 P 16170 BV 12140 ST OK - m A1P 0
2016/09/18T02:00:06Z AL 0 B1 12397 B2 -1 P 905 BV 12347 ST OK - t A1P 0
2016/09/18T02:10:06Z AL 0 B1 12397 B2 -1 P 905 BV 12375 ST OK - t A1P 0
2016/09/18T02:20:06Z AL 0 B1 12397 B2 -1 P 905 BV 12375 ST OK - t A1P 0
2016/09/18T02:30:06Z AL 0 B1 12397 B2 -1 P 905 BV 12384 ST OK - e A1P 0
2016/09/18T02:40:06Z AL 0 B1 12406 B2 -1 P 906 BV 12384 ST OK - e A1P 0
2016/09/18T02:50:06Z AL 0 B1 12415 B2 -1 P 907 BV 12384 ST OK D e A1P 0
2016/09/18T03:00:06Z AL 0 B1 12311 B2 -1 P 16153 BV 12150 ST OK D T A1P 0
2016/09/18T03:10:06Z AL 0 B1 12281 B2 -1 P 16150 BV 12140 ST L - L A1P 0
2016/09/18T03:20:06Z AL 0 B1 12397 B2 -1 P 905 BV 12365 ST OK - t A1P 0

2016/09/25: continuing to hunt down supply drop from battery to load (and I'm now allowing for an internal impedance of ~90mΩ to damp down dump load oscillations for a 'soggy' run-down battery) I have added a little more calculation to powermgr.cpp at the start, here shown with a fairly large load (laptop charging from ~empty + FTTC/router):

Verbose mode ($Id: powermng.cpp 15563 2016-09-24 23:11:42Z dhd $).
SS-MPPT-15L Vb_f slow battery voltage (mV): 12497
SS-MPPT-15L Adc_il_f load current (mA): 5847
Load power (mW): 73070
SS-MPPT-15L Adc_ic_f battery charge current (mA): 0
Input flag DUMPING is set.
System dumping for 414m.
LA/B1 dynamic threshold downward adjustment for load current 300mV.
ADC command 6a 80
ADC (6a 0) response 1263 (4 ef 0)
Battery voltage 1 local (LA) 11849mV.
Supply drop B1 to BV 648mV; implied supply impedance 0.110826ohm.
Adc_vl_f load voltage (mV): 12400
Supply drop B1 to controller load terminals 97mV; implied controller impedance
0.016590ohm.
Supply drop controller to BV 551mV; implied wiring impedance 0.094236ohm.

Removing ~5.5A of the load has the battery voltage jump back over 100mV, implying a battery-side impedance of ~20mΩ at the moment, so a tally of impedance to the RPi 12V power intake measurement point is:

though note that 4mm^2 is down as 9.22mΩ/m (two way) so ~6m from controller to RPi should be ~55mΩ. The 20A DC breakers on either side of the controller should be similar to a MAXI 20A fuse, ie ~3mΩ each, So still a mystery 30mΩ between controller and RPi!

(Looking again at the main wiring from controller to RPi, I think that 6m is a better estimate than my previous 4m value. possibly ~1m could be removed to save ~10mΩ.)

To put this in context, at a minimum RPi-only draw of ~1W (~80mA), ignoring draw by the controllers, the wiring losses etc from battery to RPi (@~130mΩ) are ~10mV (~0.1%); the loss from the redundant Schottky diodes just upstream of the RPi is probably ~350mV (ie ~3%) so possibly worth fixing. For the RPi+networking load of ~1.3A, wiring losses from the controller are ~120mV or ~1% at most. I can shorten the wiring loom or parallel up the unused cores to save ~30mΩ, but it is not a priority for now.

Note that the laptop power adaptor no longer 'screams' under heavy load (~60W); doubling the wiring run to it from downstairs seems to have been worthwhile.

This snippet, putting the laptop on to charge from near empty, suggests 40mΩ for B1 internal resistance + breaker + cable to controller, ie ~5A (~60W) increase in load caused a sag of ~200mV:

2016/09/25T07:40:06Z AL 278 B1 12439 B2 -1 P 16358 BV 12300 ST OK D e A1P 3473
2016/09/25T07:50:06Z AL 382 B1 12244 B2 -1 P 74309 BV 11605 ST OK - e A1P 4636

The sag/drop to BV, the RPi 12V input, was ~700mV, implying 140mΩ total supply impedance to BV.

Also, with the aim of making full and more precise use of my available storage during the (cold) winter, I have attempted to fold in some code support for temperature compensation of voltage set-points at the low end in particular, and so I am also logging/recording the battery temperature (using the Morningstar remote probe attached to the battery). It will be interesting to compare that to general exterior temperatures, eg observe time lags. I have set an initial base temperature of 20°C and 24mV/°C discharge, ie the thresholds for SoC levels drop with temperature, as per Victron advice, though I note that the SS-MPPT-15L uses 25°C and 30mV/°C for adjusting its setpoints. The slope is likely more critical (given that I am happy with my current setpoints today at 20°C) but I may adopt the Morningstar slope later.

2016/09/28: maybe dump oscillations are now damped...

bad day, dump not oscillating

2016/09/30: yesterday ~1/2 kWh was generated by the main off-grid array, with a rolling average of ~1/3 kWh/d, so below target.

2016/10/04: "Use it or loose it" experiment and data sample.

2016/10/14: (17:20Z) system measured under reasonably heavy load, after dark:

Verbose mode ($Id: powermng.cpp 15710 2016-10-13 07:35:43Z dhd $).
SS-MPPT-15L Vb_f slow battery voltage (mV): 12281
SS-MPPT-15L Adc_il_f load current (mA): 5781
Load power (mW): 70997
Input flag DUMPING is set.
System dumping for 475m.
SS-MPPT-15L Adc_ic_f battery charge current (mA): 0
SS-MPPT-15L T_batt (C): 13, discharge compensation -210mV.
LA/B1 dynamic threshold adjustment for load current -300mV.
ADC command 6a 80
ADC (6a 0) response 1246 (4 de 0)
Battery voltage 1 local (LA) 11690mV.
Supply drop B1 to BV 591mV; implied supply impedance 102mohm.
Adc_vl_f load voltage (mV): 12208
Supply drop B1 to controller load terminals 73mV; implied controller impedance 12mohm.
Supply drop controller to BV 518mV; implied wiring impedance 89mohm.

2016/10/30: am: having to resort to charging my MacBook from mains rather than the off-grid system for first time since the new panels went up, given the laptop near empty and the LA battery 'Low' this morning after poor insolation (particularly fog and thick cloud yesterday, fog this morning). The SS-MPPT-15L indicator was amber yesterday, so I'd like to let the battery get some charge and get back to green (13.1V).

The last few days' main-array generation reported by the SS-MPPT-15L in 0.1kWh units (sub-50Wh yesterday for example):

2016-10-25 0.2 0.310526
2016-10-26 0.2 0.3
2016-10-27 0.5 0.3
2016-10-28 0.3 0.29375
2016-10-29 0 0.293333

2016/10/30: pm: mounted the 40W amorphous panel in bay b as planned to try to catch some/more energy mid-morning outside of summer months:

a
(obscured by bushes)
b
Maplin N27JL 40W amorphous panel mounted on wall ~50cm from ground
c
2.4W panel, tested, still functioning
d
(set back, tree in front, could maybe accommodate 20W amorph horizontally)
e
CS6P-255P 255W panel now mounted on wall
f
CS6P-255P 255W panel mounted on wall ~8cm from the ground
g
ES-62T 60W panel mounted on wall ~30cm from ground

The 40W panel was connected to the secondary string/array and was live ~14:30Z, and the secondary string is now ~140Wp.

2016/10/31: it appears that imports from the grid dropped about 6kWh this month compared to last October (106kWh vs 112kWh) according to Pilio/sMeasure/iMeasure though gross consumption (I+G-E) has gone up up 6kWh while off-grid generation from the primary array was a similar ~10kWh. Not all movement of consumption off-grid happens at a time when it reduces imports, eg when the grid-tie is already causing net-exports. Taking load off-grid at night does directly save grid imports.

Note that ~2.5h of weak sunshine through haze where grid-tie hit ~1/3rd of max (thus maybe equivalent to nominal 1h/d full sun expected mid-winter) was able to hit the full ~0.5kWh/d target charging at a solid ~200W. This was probably only possible because the PV is overspecified >2x.

2016/11/12: sag with the fixed (networking equipment) dump load has risen to ~120mV with the LA battery at ~8°C, so rather than keep manually adjusting the constant in the code that allows for impedance-based sag, I have added temperature compensation, initially at -7mΩ/C, ascertained empirically by raising it from ~4 until dump oscillation stopped.

2016/11/29: with extern temperatures near freezing and the battery ~6°C, I have raised the impedance temperature compensation to -13mΩ/C, as oscillations have been nudging in again.

2016/12/01: raised the impedance temperature compensation to -15mΩ/C to help damp oscillations seen with battery at 2°C.

2016/12/15: so far the goal of 0.5kWh/d off-grid is being missed hugely; the running average is more like 0.2kWh/d now, close to winter solstice. Daily output is hugely variable, with more than an order of magnitude difference between today and yesterday (~0.4kWh/d).

2016/12/22: a respectable generation of ~400Wh today, with the running average a little over 110Wh/d to yesterday.

2016/12/29: there definitely seems to be an element of 'use it or lose it' when the battery is cold and thus unable to absorb much charge. Shortly after noon, adding a ~50W load from my MacBook saw primary generation jump by a very similar amount, with the battery voltage remaining flat at a little over 14.5V (battery at 3°C).

500Wh/d Winter Target Not Met

Possibly for a number of reasons including reduced battery bank capacity when cold (and it has been the coldest winter for a few years), the target for 500Wh/d of generation from the two large panels has not been met by a long chalk with a low around the solstice of more like 150Wh/d.

0.15kWh/d Dec/Jan

Code snapshot taken with what appear to be decent temperature compensation values.

2017/04/07: battery hit 'full' two days in a row according to the Morningstar controller; notice the float 'shoulder' on the right for the second day.

2017/06/19: interesting misbehaviour of 'dump' which went off and didn't come back on until I forced it back on by manually setting the DUMPING flag. Possibly the charging current was not a high enough multiple of the expected dump load currrent because the battery was near full and getting enough current from the other charge controller...

2017/06/20: I think that I could have the temperature coefficients rather wrong; the internal impedance etc is computed so high at 30°C that the battery could not dump unless on fire or something!

# powermng -nv
Verbose mode ($Id: powermng.cpp 15983 2017-01-19 17:11:57Z dhd $).
SS-MPPT-15L Vb_f slow battery voltage (mV): 13297
SS-MPPT-15L Adc_il_f load current (mA): 747
Load power (mW): 9933
Input flag DUMPING is unset.
SS-MPPT-15L Adc_ic_f battery charge current (mA): 1443
External flag file /var/log/SunnyBeam/LOW.flag is absent.
SS-MPPT-15L T_batt (C): 31, discharge compensation 0mV.
Estimated LA battery impedance: 65440mohm.
Estimated actual battery sag from load (mV): 0mV.
LA/B1 dynamic threshold adjustment for load current 0mV.
B1 and wiring dump load sag allowances 18947mV, 194mV.
ADC command 6a 80
ADC (6a 0) response 1397 (5 75 0)
Battery voltage 1 local (LA) 13107mV.
Supply drop B1 to BV 190mV; implied supply impedance 254mohm.
Adc_vl_f load voltage (mV): 13279
Supply drop B1 to controller load terminals 18mV; implied controller impedance
24mohm.
Supply drop controller to BV 172mV; implied wiring impedance 230mohm.
Input flag EXTERNAL_BATTERY_NOTVHIGH is set.
Input flag FORECAST_PV_GEN_GOOD is set.
Battery voltage 1 'very low' threshold 12100mV.
Flag EXTERNAL_BATTERY_VLOW is unset.
Battery voltage 1 'low' threshold 12300mV.
Flag EXTERNAL_BATTERY_LOW is unset.
Battery voltage 1 dump margin threshold 31297mV.
Battery voltage 1 'not high' threshold 13450mV.
Flag EXTERNAL_BATTERY_NOTHIGH is set.
Flag EXTERNAL_BATTERY_HIGH is unset.
Battery voltage 1 'very high' threshold 13600mV.
Flag EXTERNAL_BATTERY_NOTVHIGH is set.
Flag EXTERNAL_BATTERY_VHIGH is unset.
Flag EXTERNAL_BATTERY_NOTFULL is set.
Flag EXTERNAL_BATTERY_FULL is unset.
Setting up_threshold to 60%
Input flag NODUMP is unset.
Insufficient margin to dump, threshold 31297.
Flag DUMPING is unset.
Flag DUMPINGEND is set.
SS-MPPT-15L Power_out A1P (mW) 19236.
LASTDATA: 2017/06/20T16:58:37Z AL 1443 B1 13297 B2 -1 P 9933 BV 13107 ST OK - m
A1P 19236 B1T 31

In particular this is the impossible number preventing dumping:

Insufficient margin to dump, threshold 31297.

And this looked suspiciously like an overflow (eg of uint16_t) but turned out to be a sightly more complex signed/unsigned/underflow issue:

Estimated LA battery impedance: 65440mohm.

Here is the relevant patch/diff:

===================================================================
--- powermng.cpp        (revision 17846)
+++ powermng.cpp        (working copy)
@@ -315,7 +315,8 @@
 static constexpr uint16_t sagLAmVperADumpCorr = 80;
 // Increase in sag per C below base temperature (eg 20C).
 static constexpr uint16_t sagLAmVperAperCDumpCorr = 16;
-constexpr uint16_t sagLADumpCorr(const int tempC) { return(sagLAmVperADumpCorr + sagLAmVperAperCDumpCorr*(20-tempC)); }
+constexpr uint16_t sagLADumpCorr(const int tempC)
+    { return(uint16_t(MAX(0, int(sagLAmVperADumpCorr) + int(sagLAmVperAperCDumpCorr)*(20-tempC)))); }
 // Allowance mV/A for supply drop due to controller+wiring impedance (mohm).
 static constexpr uint16_t sagWiringmVperADumpCorr = 150;

Thresholds Up

2017/09/18: to buy or not to buy? Do I need to splash out a grand?

The lead-acid bank's capacity is looking increasingly dire, and I asked in this thread on Fieldlines for ideas on a possible replacement bank.

A suggestion from clockmanFRA, and that I've vaguely considered in the past to help protect against sustained over-discharge in the winter, is simply to limit the depth of discharge (DoD). He suggests 10% DoD max with leisure batteries as a radical approach.

I won't do anything quite that drastic yet, but I am right now creating 'conservative' / 'low-DoD' settings for my bank voltages to see if that keeps the bank healthier. If I'm not trying to power external loads, keeping the RPi running should be easy. I may this more dynamic by greatly raising the thresholds in the absense of (say) forecast sunshin, or recently hitting 'full'.

The key adjusted lines (with LESS_DoD = true) are:

static constexpr int BATT1_THR_L_mV  = LESS_DoD ? 12600 : 12300;
static constexpr int BATT1_THR_VL_mV = LESS_DoD ? 12450 : 12100;

Installing the updated code has pushed my bank from being in an apparently 'OK' state to 'VERY LOW', and the system should draw much less juice from it until the SoC rises significantly.

This will greatly reduce the nominal capacity of the bank, though if it reduces sulphation of this bank or its replacement, maybe less so than it appears on the surface.

I'm also increasing to nominally ~2 days' use (~50mV if the battery were at its original capacity, so probably back to more like 1 day again in reality) the extra margin to add in for a poor forecast tomorrow. This extra margin is also used if it has been more than a day since the battery last reached VHIGH. I may also extend that to "if not FULL for a week"; currently FULL has not been reached since the machine was last rebooted about a month ago! One to watch with the new thresholds...

See the new scheme graphically, along with mean temperatures and available sunshine dropping.

Lower

2017/10/01: as expected, especially on dull days, I'm seeing relatively little dumping, with a much-improved minimum/overnight voltage.

I'm trying a slightly-less conservative set of thresholds, that should still avoid sulphation, but should expose a bit more of the battery capacity (100mV ~ 10% of capacity):

// LOW threshold: ~85%/100% SoC un/loaded.
static constexpr int BATT1_THR_L_mV  = LESS_DoD ? 12500 : 12300;
// VERY LOW threshold: ~75%/90% SoC un/loaded, with some line voltage drop.
static constexpr int BATT1_THR_VL_mV = LESS_DoD ? 12425 : 12100;

Lower Bruce, Lower!

2017/10/02: according to Battery University, sulphation seems to be a problem at more like 12.3V than 12.4V. Note also that the VLOW threshold is a hard stop on dumping, with no further allowances for battery impedance, etc, so bringing VLOW down a bit further (but keeping VLOW and LOW well above sulphation voltages) may allow dumping to continue once started to make decent use of capacity, while allowing a return to a decent higher voltage and SoC. The issue is if it possible to avoid dumping for a long time, keeping the SoC too low too long for safety...

// LOW threshold: (LESS_DoD) ~85%/100% SoC un/loaded.
static constexpr int BATT1_THR_L_mV  = LESS_DoD ? 12500 : 12300;
// VERY LOW threshold: (LESS_DoD) ~70%/85% SoC un/loaded.
static constexpr int BATT1_THR_VL_mV = LESS_DoD ? 12350 : 12100;

These threshold values, compared to those of a few days ago, may allow use of another 10% of raw/nameplate capacity (ie 20% of usable capacity) while guarding against further premature damage and capacity loss.

See the slightly lower overnight resting voltage.

More Explicit

2017/10/14: a number of places in the code have been slanted to aggressively try to move the (dump) load off-grid, eg to help reduce the house's demand from the grid overnight and whenever the grid-tie system cannot cover house loads.

With LESS_DoD true I now tweak compile-time thresholds so as to be less keen to prop up the grid, and instead prioritise preserving battery life (and reserve to run the RPi).

However, when the grid needs some TLC (eg peak demand, peak carbon-intensity), this system will still try to help by covering maybe one-quarter-billionth of GB demand!

2017/10/16: I've now separated the externally driven dump demand into high-priority items (high grid demand or carbon intensity), and the rest, and only allow the latter group to trigger dumping (when LESS_DoD is true) when the battery has gained significant net charge during the day. The aim is to promote battery health and an increasing SoC until the battery is hitting FULL. (I may need to add specific code to allow the low-priority dumping when recently FULL.) I may want to add the "only when gained charge on the day" condition to other places too.

You can see dumping stopping early and then correctly resuming later during high grid carbon intensity. The early stop was caused by heavily overcast orange skies caused by dust and smoke brought in from the south by a hurricane while it was monstering Ireland.

There are now two new status code letters in the log: 'N' for not enough net charging in the day for anything other than high-priority grid support, and 'E' for those high-priority factors such as peak grid demand or carbon intensity.

2017/10/20: a significant semantic upheaval is now under test: VHIGH now indicates passing the specified voltage threshold and reaching absorption (or float) which implies a thorough (and efficient) charge. The 'H' timed start to dump is now upgraded to 'A' indicating having reached absorption (and been HIGH for long enough). 'N' now means that low-priority dumping is blocked because there has Not been a recent decent charge likely to avoid sulphation amongst other limits to DoD. A recent VHIGH no longer just implies a brief spike from the big panels, but instead leans on the charge controller to be an indication of a decent SoC, ie out of 'bulk' phase.

2017/10/21: back to "use it or lose it": in this case Sweep_Pmax greater than Power_out and Load power suggests that the battery cannot accept (much more) charge and the panels connected via the PWM controller are providing ~6W. This does strongly imply that the dump load should make use of the energy that is otherwise being wasted.

Vb_f battery voltage slow (mV): 14271
Adc_vl_f load voltage (mV): 14200
Adc_ic_f battery charge current (mA): 747
Adc_il_f load current (mA): 1179
Load power (mW): 16826
Adc_va_f array voltage (mV): 35044
Sweep_Vmp (mV): 26636
Sweep_Voc (mV): 32117
Sweep_Pmax (mW): 36554
Power_out (mW): 10615
kWhc (kWh*10): 3342
charge_state: 6
Ahc_daily (mAh): 8400
Ahl_daily (mAh): 5300
T_batt (C): 16

To test the "use it or lose it" hypothesis further, I've ordered a 12V kettle and an in-cup immersion heater, both maybe ~150W, giving me two orders of magnitude of loads from RPi through networking gear to kettle. I'll have to be careful that the kettle load doesn't hurt the solar controller nor crash the RPi by yanking the supply down too far. The controller maximum load is 15A, thus ~180W. It could struggle with simultaneously powering the networking gear and kettle.

Who Guards the Guards?

2017/10/14: I was concerned that the powermng program itself might be starting to eat significant CPU time and thus energy, since it is now fiddling with increasing numbers of (eg) governor parameters and thus incurring extra context switches, etc. But actual user and system CPU time is still very low, maybe working out as 10ms every 10m run.

# time /usr/local/bin/powermng -n
real    0m0.940s
user    0m0.010s
sys     0m0.000s
# time /usr/local/bin/powermng -n
real    0m0.940s
user    0m0.020s
sys     0m0.000s
# time /usr/local/bin/powermng -n
real    0m0.938s
user    0m0.010s
sys     0m0.000s
#