OK. New thread for this.
I had a quick look and wondered if these 4 channel 12 bit 1 wire breakouts would work with webcontrol:
http://learn.adafruit.com/adafruit-4-channel-adc-breakouts/assembly-and-wiring
Or these 8 x 10 bit (spi not i2c) with arduino:
http://nicegear.co.nz/components/mcp3008-8channel-10bit-adc-with-spi-interface/
Webcontrol, vs arduino, vs beagebone. Happy to hear more arguments re pros and cons. Cubieboard only has 6 bit adcs, so that isnt a solution. How long til the new webcontrol comes out?
Other than cell balance, the other obvious datapoints are :
a) get _actual_ pv current verses classics approx reading
b) and hence check actual classic efficiency
c) and by a process of elimation, classic tare draw.
and weather station data direct. Can use these sort of thing to intercept the 433 Mhz signals.
http://www.practicalarduino.com/projects/weather-station-receiver
Re muliplexing: see
https://www.sparkfun.com/products/299
http://www.eetimes.com/document.asp?doc_id=1278370
Much fun and games to be had, with just time being the all pervasive primary constraint in the known universe.
Quote from: zoneblue on October 18, 2013, 05:34:56 PM
I had a quick look and wondered if these 4 channel 12 bit 1 wire breakouts would work with webcontrol:
http://learn.adafruit.com/adafruit-4-channel-adc-breakouts/assembly-and-wiring
I can't see what the chip used is, but as it's I2C I don't think it is supported.
Quote
Or these 8 x 10 bit (spi not i2c) with arduino:
SPI has the same problem: it's not onewire, and it's not a DS2450
Quote
Webcontrol, vs arduino, vs beagebone. Happy to hear more arguments re pros and cons. Cubieboard only has 6 bit adcs, so that isnt a solution. How long til the new webcontrol comes out?
Very soon.
None of the boards you've listed here will help with "cell balance" because of the lack of isolation between them. Even with the extra resolution, I'm not convinced I like the common-mode uncertainty. By the time you divide a 48V (nominal, lets say 60V realistic) down to keep within the ADC range, we're already something like 4 or 5 bits down.
(20:1 divider to break 60V down to 3V. That means detecting 2mV difference at the battery needs to be now 100uV after the divider - so 16-bit ADC reading 20:1 divider is really about the same resolution as a 11-bit reading the raw battery volts)
I kind of get what youre saying, been a long time since i did any serious EE.
Solutions:
- If we happend to find say a cheap 32 channel analog multiplex chip, then we can use one really high bit adc. That 16 channel chip i linked was sub $1.
- lots of high bit adcs, if they were cheap enough.
- use differential inputs at the cost of more adcs.
- Or use your approach of floating each group of 3 low bit adcs.
Avoiding electronics in the battery box. Sheilded audio cable to a central box, mounted near but out of danger range...
Ill leave you 2 to ponder all that i think!
Zoneblue
I can see that we have stirred your interest :)
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)
So herewith my attempt at defining "RE" sensing/automation requirements (as distinct from
More traditional HA inputs and outputs)
I've tried to structure below In a logical way we can then discuss each "block" prioritize effort
As we think best, and use a structured approach to how we gather and display data
RE sensing/automation blocks
1) PV array
2) Charge controller
3) Inverter
4) battery bank
5) Generator
6) Weather
7)Solar radiation
(it's probably part of weather, but I include it separately because of it's complexity)
8 ) Loads DC and AC
9) Environmental sensors
What/how to get from each block
1) most useful/important data can be accessed via CC via modbus BBP
Possible additional thoughts would be to measure individual PV strings in an array,
However given its DC, and very high voltage (and current) ... The options here are expensive and limited. .. And aside from fault monitoring - possibly don't yield ROE/I (effort and investment)
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 multiple in
Differ et directions, tracking vs fixed (Ross thinking of you)
Suggest we allow for n sensors per array and x arrays (pick some reasonable number for n and y)
2) Modbus data from CC into BBP - "done" (zoneblue/Ross pls take a bow)
3) my inverter interest is magnum ... However in a separate thread I've already detected
That access to magnum data is a challenge (aside from their web portal ... Which doesn't
Work if your "off the Internet grid" ... Even temp interruptions "loose data")
I'm sure other inverters have much better data access
as a minimum - if other model inverters provided "closing contact/digital status Outputs"
It would be easy to read the inverter status ... And of course better is more useful data avail
a) inverter charger status, inverter SOC, AC load PWR, et al
4) battery bank
a) Bank voltage (CC) - done
b) cell voltages (see other forum posts),
c) cell temps simple sensor attached to batteries
- glued on side of cell
- attached to terminal ... This measures the conducted heat out of battery onto battery terminal
Note the temp sensors are so cheap, could put one "between each cell"
5) generator
Needs a mix of voltage, current and environmental
a) start battery (voltage)
B) AC voltage,current and power output ;
AC current transformer CT (lots of work already done on this)
c) status : running, standby, manual,
d) oil and water temp
e) room temp
F) CO gas sensor
Note some generators likely provide some of above already via a status panel etc
However we can plan for worse case and assume all above need to be sensed
6) weather
A very well (over done) aspect in HA already ... So many options, hard to summarise "how"
As a minimum the RE block needs
a) ambient temp (near array, possibly "under array" also
b) humidity
C) atmospheric pressure (barometer)
d) wind speed and direction (not sure the relevance for PV?)
As a minimum BBP can have its own sensors for a) b) c) , or access a separate weather
Station .. As ZB points out ... Can use off shelf weather station and sniff it's RF (eg 433MHz )
But there are myriad of options around
(Happy to separately share my experience on this)
7) solar radiation and insolation
(Other thread topic)
a) pyranometer
b) solar "test array"
c) simple solar (eg photodiode ambient light )
Note some weather stations also have above "built in"
8 ) Loads
- DC loads
Use low cost Hall effect breakouts circuits to measure DC current
Various modules avail off shel, to measure up to 30A + per circuit
Can measure individual circuits and look for faults and monitor loads
- AC loads (see generator 5b above)
Plenty of ready avail options .. Just need to "read" into BPP
9) environmental
Mostly covered above
a) room temp sensors (battery room, inverter room)
b) gas sensors (CO, hydrogen, fire, smoke ) as applicable for each location
There are low cost breakouts boards that can achieve each of above
As you can see - the list is biggish - hence need to "prioritise" .. Hope I haven't scared Zoneblue :)
I will separately document my thoughts on the various methods to achieve each of above
We can use above list as a reference start point - and add to it as required
I think in my enthusiasm I put this in wrong thread ?
Pls move as appropriate
My apologies
Quote from: Gregy on October 19, 2013, 01:27:25 AM
1) most useful/important data can be accessed via CC via modbus BBP
Possible additional thoughts would be to measure individual PV strings in an array,
However given its DC, and very high voltage (and current) ... The options here are expensive and limited. .. And aside from fault monitoring - possibly don't yield ROE/I (effort and investment)
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 multiple in
Differ et directions, tracking vs fixed (Ross thinking of you)
Suggest we allow for n sensors per array and x arrays (pick some reasonable number for n and y)
OK, I didn't want to play this card just yet... but well, you've kinda forced it :)
Year ago I started work on my entirely new and improved tracking system. Different to anything else on the market. Basically, it's a small controller that bolts to the frame of a tracker. A common bus goes from inside to outside (just a lump of figure-8 flex, polarity isn't important). I get a little cute with the way it works, but basically I have a webcontrol-8 board inside that fetches sun-position information from one of my servers, then powers up the trackers, sends them a command to position to a certain *ANGLE* and leaves the trackers to position themselves to it. After a while, it polls each tracker for its current position (elevation and azimuth) and last actuator current, which it reports back to my central logging computer.
My first prototype board without the inclinometer:
(http://general.rossw.net/webcontrol/tracker-bus-pcb-noincl.jpg)
Same board but with the inclinometer installed:
(http://general.rossw.net/webcontrol/tracker-bus-pcb-incl.jpg)
That gets mounted in a flanged case that simply screws to the movable part of the tracker, so it knows exactly where the array is "pointed".
(http://house.albury.net.au/27mar2013/100_5988.JPG)
I have a single pin left on the PIC, it might be possible to add a DS18B20 to read the panel temperature and return that along with the status... if there's any interest?
(I haven't finished this project yet, it works but isn't completed. It already has all the ramp-up and ramp-down, current limiting on the actuator, jamb-detection, calibration etc. I have no code space left, but I can probably ditch some of the extra stuff I put in that isn't really necessary and is just for my entertainment and diagnostics). The design has a limit of 14 addressable arrays (plus a "broadcast"), so it's probably got plenty of capacity for most of the people reading this...
I think you just defined a new sub block under item 1) PV. Array
(Note I started a new thread for my above BBP modules post )
We can add a New subcategory for "panel tracking"
Zone blue quote
"Webcontrol, vs arduino, vs beagebone. Happy to hear more arguments re pros and cons. Cubieboard only has 6 bit adcs, so that isnt a solution. How long til the new webcontrol comes out?"
As this raises a generic debate over the role of the different ways to "sense" data
Using these different platforms
I'm going to take the liberty of responding under the new thread I started on BBP modules
As the question you raise extends well beyond the "battery DAC" requirement