Black box project (BBP) sensing modules

[Gregy]

arduino and nanodes et al

zb quote "learn to code in 32k"

the  neat thing about arduino and these environemnts - its already been done (by many) and all the
code is posted open source ... and tons tutorials and example "sketches" (programming code)
so scaling the devices for difffernet sensor inputs is "simply" a case of adding in more snippets
of code ( a GY over simplification)
even myself as a "non programmer" should be able to become familiar and adapt existing sketches

[Gregy]

zb
thanks for the kind words - the research has been a interesting exercise .. there is a little more to
come but im nearing the end of completing each module ;
environmental sensors
wireless sensors ( i think you can guess where im headed on that)
BBP interfaces  (in conjunction with our other posts on architecture and interfaces)
are the three final peices im working on

ref openenergymonitor.org
my thinking exactly - i had already been doing some reading in their forum to understand what correct
protocol may be for our intro, also ascertain interest and any activity that may already be working on
off-grid adaptations of emontx and emonbase  (eg modified sketches)
my thoughts however to date
1) both hw modules are arduino - hence great for what they do, but limited onboard processing and memory cw BBP  (they fit your architecture diagram as nodes for bbp to access)
hence my "complementary" comments ... partic if we limit BBP to not replicate what they are already doing very well - and simply use it for the very off grid and other module tasks ive outlined above

2) at present it looks like their focus is to send data up to the webbased server for processing and display (unclear exact "local" capability provided by emonbase ... but indications it can be
interogated locally via ethernet) more research underway
and of course they have that very neat local display!
... more to come ...

[dgd]

Started a new thread to let separate discussion

I've been thinking thru the automation aspects of RE system, given that I have existing HA - albeit
For more traditional aspects (no RE type inputs at present)

 

RE sensing/automation blocks
1) PV array
...
What/how to get from each block

general: most useful/important data can be accessed via CC via modbus BBP
- PV string voltage and current (given its DC, and very high voltage and current)
options here are expensive and limited. .. And aside from fault monitoring - possibly don't yield ROE/I
Summary : at present IMHO we "leave it up to the CC" to manage and report
- panel temp (very useful and important) via a simple temp sensor glued to rear? Of panels
(Suggest a few to be able to get an averaging across each array)
Need to support More than one array for those with multiples
Suggest we allow for n sensors per array and x arrays (pick some reasonable number for n and y)
...

We can use above list as a reference start point - and add to it as required

I sort of agree that a lot of useful data concerning the PV array can come from the CC.
Some thoughts on this:
- meaningful  data is probably limited to when the CC is in BULK MPPT mode as in this mode the CC is extracting the maximum it can from
the PV array
- a larger capacity array that can exceed the CC current limits is more difficult for the CC to manage (and provide meaningful data) when the array is able to generate more power than the CC can handle.
- in ABSORB and FLOAT modes the CC limits current from array and is happy to waste excess power. In these modes the CC cannot provide an useful data on PV array capability.

The CC's primary function is to manage the charging of batteries and maximising battery life. It does not really care where the power input is coming from, PV, turbine etc.

Therefore making maximum use of the PV resource will need to detect when the CC is demanding maximum power from the array and when it is not.
The Classic can provide, via modbus register, info on which charging mode it is in and the current its taking from the PVs and the input voltage.
Some features of the Classic CC when dealing with a PV array
- in BULK MPPT the current will be maximum the array can provide OR the maximum current limit setting as defined by user. Voltage will be near the MPP voltage for the panel
- in ABSORB and FLOAT the current is limited but the array voltage will rise above the MPP voltage and may reach (almost) the PV open circuit voltage
- the MPPT tracking software in the Classic will, every so often, unload the PV array for up to 25 seconds (time based on obsrevations) for a deep scan or partially unload array for a quick scan. one effect of this is that the PV voltage will riae to PV OC voltage until the scanning is complete and the PV array is loaded again. Note - a side effect of this is that reports, eg in local app, will show max input V as the OCV for the array.
- The interesting AUX2 PWM can be used to divert  power to another device.  However, as pointed out in previous threads the PWM diversion process starts at a defined voltage below the set point for ABSORB or FLOAT and direting to a large enough load could prevent these set points being reached. Some experimenting with load balancing is the way to go.
- The  Classic input volts and amps meters are not 100% accurate but do give an approx indication of input values.

The ideal power diversion should (IMHO) occur as cloase to the power source as possible.
WIth a PV array the power is diverted from the array of a section of the array WITHOUT using the CC to manage this diversion.

A BB application  is ideal for this PV array diversion application.
The BB will probably need to give power priority to the CC so that the basic business of battery charging is completed.
Any diversion control (algorithmn) will need to take account of the CC's mppt loading and unloading of the array.
The BB must be able to appropiately unload the diversion load to allow the CC to resume battery charging as needed.

dgd

[dgd]

RE sensing/automation blocks

1) PV array
a) Fixed array
b) tracked Array

Not sure how these two PV array 'configs' would fit into BB logic.
I know RossW has done a lot of good stuff with tracked arrays and the graphs he posted some time ago do show some clear benefits to
array tracking.
Nevertheless I do get the feeling that with PV prices where they are, that tracking costs could  soon, if not already, exceeed the costs of just installing more PVs.
No matter though, just my opinion, I'm sure the tracker vs bigger array debate may be pointless...

dgd

[Gregy]

DGD
yep i think you have nailed it very well

my thinking was to use Module 7 (reproduced below) to be able to estimate the available power  from production array

***********
7) solar radiation and insolation
(Other thread topic)
a) pyranometer
b) solar "test array"
c) simple solar (eg photodiode ambient light )
************

which makes me think my above description needs modification
this module is actually to "predict instantaneous available power from production array"
using one (or combo) of options a) b) c)  for solar radiation/insolation to help it predict (note i may be incorrectly using the terms )

ANd then BBP provides a calculation (because it "knows everything" - thats why we need all info in one place.. aka BBP)

opportunity power available = predicted array total power - CC reported power usage
(details from CC regardless of its respective charging mode)

this calc can be  instantaneous , averaged over some time period? or other?
and then presents (and perhaps enable control) the estimate of opportunity power avail
note it will also need to have a CC efficiency factor to subtract CC pwr losses also

notes: im making assumptions (for which i admit i dont have experience)
1) the CC can report its PV sourced instantaneous power consumption regardless of its present mode
2) its possible to "load up" the CC by switching in additional loads via one of 2 methods
DC loads/AC loads via inverter (note loading up PV panels at DC high voltage directly is a different case  to also be meausred/ managed)
.. and do this by minimising disruption to battery charge state (which is kinda where we started this discussion:) .. in our quest to use opportunity power (for fixed loads - not PWM controllable "variable" loads) and not disrupt battery charging

Q: can the CC ramp up to supply more DC current for the additional DC loads and AC inverter loads, whilst maintaining current to battery and not disrupt its charging mode ??  (assuming the sum
of all loads on CC is within the predicted/actual available power to it from PV .. aka module 7)

my above assumptions need validation, otherwise the whole idea collapses ?

[Gregy]

we parallel posted

yep again
module 1)
the ability to capture "power" data from fixed vs tracked array - opens up opportunity to measure
(and perhaps debate
and quantify the whole fixed vs tracked  ... to compare the benefits , costs et al 
it wasnt so much to give BBP logic .. in this case it was more just measurement (i think) coupled
with module 7

and yes i agree ... with falling PV panel prices, in many scenarios im sure the additional tracked costs
become a limiting factor (inc reliability issues) ... and of course for those in high wind loading locations, eg hurricane etc .... fixed is a no brainer
... but for space limited situations, tracking may be a necessity (not to open the debate here)

[RossW]

In bouncy moving taxi on way to airport. Will post more when I get somwhere comfortable and with a real keyboard!

[Gregy]

DGD
im very much thinking out aloud ("TOA") here ....

your very relevant thoughts now drive us IMHO towards defining the BBP
- "decision modules"
- "output modules"
(my random terminology)

one we have Input sensor data (eg from sensing module structure)
this leads to the obvious "so what to do with it all"
so by defining what we want to do with it - then defines the output modules and hence then to the decision modules (and internal logic)
for example
we want output modules for:
- using opportunity "fixed" DC loads
- using opportunity "fixed" AC loads
- using opportunity PV loads (your preffered case : putting a fixed or variable load onto a PV array)

and then we define the algorithms for each in the "decision modules"
a diagram would help i know ... but Something like

sensor module/s data >>>>  decision module (algorithms and logic) >>>> output modules

working backwards from a prioritised "what do we want" list, also
help prioritise input sensor modules

ZB - pls jump in here - as im not sure how you envisage and/or have
already established BBP sw structure

thoughts?

[Gregy]

... and a heads up - my temporary excess time aberration has come to a sudden (as expected) halt,
at short notice im departing for a new country and new role today, and hence my prolific posting
will diminish ... pls stop cheering

at least  all the information ive generated can now "soak for a while" whilst everyone digests it

ZB - not sure when i will get a chance to send the other text doc ... as im now IPAD only IT challenged

[zoneblue]

I originally made a code seperation between input modules and output modules, but changed my mind. For now. Mostly because monitoring is the task list priority.

But to my mind a code module relates to a discrete piece of hardware, (plus more amorphous things like reading or writing to other servers.) That disscrete 'device' may have either or both inputs and outputs.

However for your purposes of controlling say a generator or diversion load then a simple relay board off our coms bus, would qualify as a new peice of hardware, and hence a new code module.

Modules are all alike run regularly, so what they actually do is irrelevent from my point of view.  So Im just calling them 'modules'.

As to what happens for logic that needs to consider data from multiple modules, im still pondering on that. Thus far im guessing some kind of hybrid datapoint . As an eg: the sum of all power inputs, from two say brands of charge controllers, plus one inverter/charger.