Monitoring your solar system

[OomD]

So I now have a solar system running, and I really want to keep monitoring it to see how much I'm actually gaining by it, and keep an eye on it's health. But, the software out there, even the ones being developed by members here, don't give me all the info I want. So I have to add a battery monitor, more money. The inverter (Axpert, in this case) does not give easily usable data (e.g. Kw into and out of batteries), you need to manipulate their data to get the info you want. And finally, I don't want to leave my PC on just to keep logging.

 

So, what does one do?

 

You build your own system. Yes, a raspi will do, with a few basic sensors, but ultimately I want to monitor the following:

 

12 Batteries (3 strings of 4) - monitor each one's voltage individully. To detect battery failures.

3 Strings - monitor current going in and going out of each string. Each string can be different capacities (within a string all the same, off course).

PV - monitor current being drawn, and determine energy obtained.

Display all this data in real time on a (non-PC) screen (I happen to love 7-segment displays, but this will require too many).

Log all this data in non-volatile memory for later download to a PC.

 

So, I don't want to rewrite any PC software, draw fancy graphs, upload to webs, etc. There's already people doing that. I want to monitor my system without my PC.

 

So, this December I'll start building my monitor. It will have plenty analog inputs for voltage and current monitoring. I'll use Hall-effect sensors to monitor current, as current shunts are expensive and necessitate a drop in voltage (albeit very little - catch 22, less drop = less accuracy).

 

Anyway, why this post? Well, developing hardware is costly. Prototyping takes a lot of money, a lot more than production does. So, is anyone interested in co-developing, or sharing the cost of development? I'm thinking maybe someone carries the hardware costs, I develop the firmware and we each get one prototype unit out of the deal.

 

Would there be interest? And feel free to share ideas of what the unit should monitor.

 

Finally, I know I new here, but can give examples of what I have developed. Trust me

[OomD]

What could be cool is that we integrate what you are doing with my system in the long run. So then you do all the capturing on the Pi and when the PC comes on it can pull all the data from the logger to see what happened. Or something to that effect.

Indeed the plan! Except I won't be using a pi, it's too costly. You still need a carrier board, power supply, etc. I'll just build my own board with a display and LCD. But yes, ultimately it will be like an offline logger, and can transfer its data to a PC for proper analysis.

[Chris Hobson]

Hi OomD

 

O the voltage monitoring side I have given it some thought and ATTiny 85 powered by the battery it is monitoring via a voltage divider. Pass the information via I2C to Arduino (or some other microcontroller). I am stumped at the moment in that I cannot find a ATTiny I2C library that works and I am not skilled enough to write my own.

[OomD]

Hi OomD

 

O the voltage monitoring side I have given it some thought and ATTiny 85 powered by the battery it is monitoring via a voltage divider. Pass the information via I2C to Arduino (or some other microcontroller). I am stumped at the moment in that I cannot find a ATTiny I2C library that works and I am not skilled enough to write my own.

Chris, if you're willing to share your existing source with me I can help getting the IIC running. That being said, though, IIC is not the ideal mechanism for communicating off-board (from one PCB to another). It is simply not designed for that. In addition to that it needs a GND reference, and if you have 4 of these coupled to batteries in a string you don't have a common GND (as each battery's GND is the +ve of the one preceeding it). You'll need to isolate these from each other, and for that purpose an opto-coupler will be perfect.

[Chris Hobson]

I have ordered 20 high speed dual opto-couplers from China. Local component prices are a joke and most companies want to charge R60 -R200 for postage. I can land components for what I would pay for postage in RSA. I unfortunately have to be PATIENT (not a strong point). What I like about i2C is only 2 wires and you could connect 111 slaves (128 minus reserved addresses) which would handle any size battery bank. Keeping track of slave addresses may be a bit more problematic but not insurmountable.

[Mark]

Hi All

 

I am not monitoring (manually the mid point voltages of the batteries.

 

What are acceptable levels or ranges and when should I start worrying?

 

Any tables on the Internet I can download?

 

Thanks

Mark

[___]

I'm also messing around in this domain, but as long as I'm doing this on my own I'm not holding anyone back... as soon as I join a team, something will come up (you know, a kid will fall ill or a deadline at work) and I'll become lost to the cause.

 

My plan is to go with the Raspberry Pi. At least initially. I know it's costly, but I don't have the time or skills to build my own Arm Cortex (or whatever) solution. I do have the skills and the tools to program the atmel chips used for the Arduino, that is the AT328 and the attiny chips. I got avrdude to work properly with the Arduino ISP over the weekend (does not work out of the box on ubuntu 14.04, you need to make changes to udev and avrdude.conf). I got a hall-effect current sensor from sebra80 on BidOrBuy... that is a good seller and he has a lot of cool stuff at prices rivaling ebay, but for R50-R60 you can courier it instead of worry about the Post Office.

 

No PC-board capabilities here though, it will likely all be stripboard and breadboard. I have some resources at work though, people I can ask, even some equipment. We have an entire hardware department building things using Atmel chips (among others).

 

Blatant plug: The New TomTom Fitness Watch has some of our hardware in it.

[OomD]

I have ordered 20 high speed dual opto-couplers from China. Local component prices are a joke and most companies want to charge R60 -R200 for postage. I can land components for what I would pay for postage in RSA. I unfortunately have to be PATIENT (not a strong point). What I like about i2C is only 2 wires and you could connect 111 slaves (128 minus reserved addresses) which would handle any size battery bank. Keeping track of slave addresses may be a bit more problematic but not insurmountable.

But, as mentioned earlier, it won't work for the simple fact that you need a common GND between all the IIC slave devices. If each device is powered by the battery it monitors then all their individual GNDs cannot be connected together.

 

Well, technically it can, but it will only last a millisecond or so.

 

You have no choice but to go the isolated comms route.

 

Unless, you power the devices from a common supply (e.g. the 48V string voltage) and measure each battery's +ve and -ve voltage and calculate the difference, then they'll all have a common GND and you can use non-isolated comms, be it IIC or whatever.

[___]

Also, re the isolation problem and not having a common ground. I was looking at these on Friday:

 

http://za.rs-online.com/web/p/digital-isolators/8232050/

[OomD]

Also, re the isolation problem and not having a common ground. I was looking at these on Friday:

 

http://za.rs-online.com/web/p/digital-isolators/8232050/

That'll work, yes.

 

But.

 

You need 2 of those for each battery you're monitoring (one for slave device TX, one for host device RX). So 12 receivers (in my case) to monitor 12 batteries. Very costly.

 

If you want to have a CPU at the battery, measuring it, then you'll need a cheap way of communicating all 12 back to the host... the easiest for this is a multidrop architecture with optos. Each device has a transmitting opto, your host has a single receiving opto. Each device periodically transmits it's voltage, using serial protocols to overcome bus collision and arbitration. Simple. Cheap. The host sits there listening and gathering the data that is broadcast by each slave device. No GND issues.

[___]

 

You need 2 of those for each battery you're monitoring (one for slave device TX, one for host device RX). So 12 receivers (in my case) to monitor 12 batteries. Very costly.

 

If you want to have a CPU at the battery, measuring it, then you'll need a cheap way of communicating all 12 back to the host... the easiest for this is a multidrop architecture with optos. Each device has a transmitting opto, your host has a single receiving opto. Each device periodically transmits it's voltage, using serial protocols to overcome bus collision and arbitration. Simple. Cheap. The host sits there listening and gathering the data that is broadcast by each slave device. No GND issues.

 

That particular model has two isolators per chip, and the 8621 differs from the 8620 in exactly that the second channel is backwards, so you have both an rx and tx channel on the one chip. Still, you'd need 12 of them for 12 batteries, so you do have a point.

 

The reason why I looked at that chip, is to add to the CP2102 serial converter to make a VE-Direct cable with the same properties as the one Victron makes, at a tenth of the cost.

[Guest]

VE Direct USB cables was R149.34 last week. 

[superdiy]

No PC-board capabilities here though, it will likely all be stripboard and breadboard.

 

As long as it is single-sided I might be able to assist.  That is for prototyping - not large scale productions runs please. 

[superdiy]

Also, re the isolation problem and not having a common ground. I was looking at these on Friday:

 

http://za.rs-online.com/web/p/digital-isolators/8232050/

 

I've used the ISO7220's in a USB-to-DMX cable, but I see they are now much more expensive than what I paid about a year ago.

[Chris Hobson]

Unless, you power the devices from a common supply (e.g. the 48V string voltage) and measure each battery's +ve and -ve voltage and calculate the difference, then they'll all have a common GND and you can use non-isolated comms, be it IIC or whatever.

 I looked at this initially but found at the higher voltages the scale for the ADC was too coarse and the measurement for the last two batteries (in a series of 4) was error prone.

[___]

 I looked at this initially but found at the higher voltages the scale for the ADC was too coarse and the measurement for the last two batteries (in a series of 4) was error prone.

One thing I thought of in that long discussion we had... if the problem only really manifests at the very top, you could solve the problem with two microcontrollers and two grounds. Maybe one for the bottom half and one for the top half. Now you need only solve one isolation problem and not one per battery.

[Chris Hobson]

But, as mentioned earlier, it won't work for the simple fact that you need a common GND between all the IIC slave devices. If each device is powered by the battery it monitors then all their individual GNDs cannot be connected together.

 

You have no choice but to go the isolated comms route.

 

 

What about using the PWM ability to transmit the voltage information?

 

What alternatives are available?

[Jakes]

It seems we've got a solid base of electronic knowledge on the forum.

 

You guys should see what OomD does with a BMW motorcycle.

 

Looking forward to the fruits of your labour.

[jhay]

 I looked at this initially but found at the higher voltages the scale for the ADC was too coarse and the measurement for the last two batteries (in a series of 4) was error prone.

 

It should be possible to measure all 4 from a single processor. There is no inherent reason that you can't.

 

Also you can "refine" the coarseness a few ways. The easiest is probably to take a few measurements and average them. For example if you want to measure up to 60V with a 10 bit ADC, you get 60 / 1024 = 59 mV per bit. If you take 16 samples and average them, you are closer to 59 / 16 = 3.5 mV per bit or with 32 samples you are below 2 mV.

 

The other option is to use a voltage reference to lower the voltage that you want to measure. You connect the positive of the reference to the point you want to measure and its negative through an appropriate sized resistor divider network to ground.

[___]

The other option is to use a voltage reference to lower the voltage that you want to measure. You connect the positive of the reference to the point you want to measure and its negative through an appropriate sized resistor divider network to ground.

 

Back when we had that discussion, I had the idea of using an LM337. This is a negative regulator, normally you would use it on the negative side (in conjunction with an LM317 on the other side) in a dual-rail supply. In this application, you will "pretend" that the positive side of the battery is "ground" and that the negative side is your negative voltage below ground. You then use the LM337 to provide a stable voltage "below ground". What you get is a stable voltage below the positive end of your battery. Then you measure the difference between that regulated voltage and negative.

Example, if you have a bank that can go all the way up to 65V. Using the right resistor divider on the LM337's adjust pin, you can set it to generate a regulated 30V (for example) below the positive end of the bank. This will leave you with a voltage between 10V and 35V between regulator output and negative. And that's much easier to measure.

The little 100mA versions of those regulators are quite cheap, as I recall.

Edited: Decided to add a picture. Excuse the plonk-cad :-) 3 pins on the LM337 is in (on the left), adjust (on the top), out on the right. Look at the datasheet, as I recall two of the legs are "the other way round" compared to the 317. The idea is to measure the voltage between out and negative (0V). That will be 36.5V below the top, so you add 36.5 and bob's your uncle. Of course you cannot measure anything below 37.7... but by then your batteries are destroyed.

Edited again: Note max voltage between IN and ADJUST is 40V. So that limits you to around 75V max battery voltage.

[OomD]

It seems we've got a solid base of electronic knowledge on the forum.

 

You guys should see what OomD does with a BMW motorcycle.

 

Looking forward to the fruits of your labour.

You're not talking about riding skills now, are you? 

[dax021]

Haven't tried this myself, but apparently it works.

DIY Printed Circuit Board

If you

[___]

I'm aware of the toner-method. It also works with traditional feric-chloride (of which I happen to still have a container of powder, 20 years old, but I'm sure it's in perfect shape).

[superdiy]

Haven't tried this myself, but apparently it works.

DIY Printed Circuit Board

If you

[OomD]

Hi OomD

 

O the voltage monitoring side I have given it some thought and ATTiny 85 powered by the battery it is monitoring via a voltage divider. Pass the information via I2C to Arduino (or some other microcontroller). I am stumped at the moment in that I cannot find a ATTiny I2C library that works and I am not skilled enough to write my own.

Chris, I gave the idea of separate MCU based sensors some thought, and the GND issues, and I believe I have come up with a nice solution that is still very cost effective. I'll jot down a quick diagram (probably tonight) and post it here. I like the idea of separate sensors instead of a bunch of analog inputs to a single board, makes it (almost) inifnitely expandable and much more flexible. Cost will be higher for the system as a whole, but I think it'll be worth it.