Tag Archives: solar

Wireless IV Curve Tracer for long term field testing

Wireless IV Curve Tracer

Wireless IV Curve Tracer
Wireless IV tracer

The Problem

At work, we have a long term test facility with dozens of PV modules of various makes and models that are wired up to instrumentation that records IV curves once per minute, all day every day. The hardware for this testing does a great job in terms of accuracy and resolution, but has some shortcomings: it’s expensive (~$20K minimum), and requires a lot of wiring which means it isn’t very flexible. If I want to set up a new panel, or move an existing panel to a new location, I usually have to run new wiring for the PV module, a relay bank, and the DAQ hardware.

The hardware below was designed and built as a personal project in an attempt to address the shortcomings of a traditional IV measurement setup. The hardware and software are open source. If you find what I’ve done useful, I’d love to hear about it!

My Solution

The IV tracer pictured above (my working prototype) has just two wires to connect to the panel under test. Other than that, it’s completely self-contained and portable. When the panel isn’t being measured, the logic circuitry is put to sleep and the panel’s power is instead used to charge a small lithium ion battery. Even in complete darkness, the IV tracer can run from the battery for a couple of weeks, and as soon as the sun comes out, the battery is quickly recharged.

The IV data is transmitted as ASCII text using an Xbee in transparent serial mode. On the receiving end, a simple USB-Serial adapter is connected to a linux PC and a very basic logging script.

The complete IV tracer cost me about $140 to build, which is a huge cost savings in addition to the time saved from not having to mess with miles of wiring.

The Hardware

The hardware consists of two parts:

1) A “Power Module” that charges a small Lithium Ion battery and provides a regulated 3.3V power source. It also includes an onboard relay that allows it to be disconnected from the panel during IV measurements.

2) A “Logic Module” that performs the IV measurements and handles wireless data transmission.

Each module fits on a 1.97″x3.4″ PCB, and standard screw terminals provide for wire connections between the two PCB’s. The PCB’s and battery are mounted on a small section of DIN rail in a NEMA 4X enclosure, with short male/female MC connector pigtails for connection to the panel under test. The entire assembly measures just 7.1″x5.1″x3″ and weighs about one pound.

To measure an IV curve, relay K1 (see schematics below) is activated, switching the power module out of the circuit. Capacitors C1 and C2 provide a load to the panel, and voltage and current are first buffered by the MCP604 opamp and fed into the MCP3202 two channel SPI ADC. With the Atmega644p clocked at 7.37 MHz, and the SPI clock running at FOSC/8, it takes about 100 microseconds to capture each IV point (50 us for V, 50 us for I). In practice, the panel’s current varies with irradiance, and hence the IV curve acquisition time varies as well. Under full sun, it takes about 150 milliseconds to capture a 150 point IV curve. With the panel completely shaded, it can take about 4 seconds. A very simple software algorithm is used to determine which samples to store and when the IV curve is complete.

Once the IV curve completes, the Xbee is woken up, and the data is transmitted as comma-separated text, along with a unique ID number. The ID for each IV tracer is set via a 6 position dip switch on the logic module.

The Xbee coordinator can handle a maximum of 10 sleeping end devices, which means for a large test setup of 40-50 IV tracers, the PC on the receiving end will need a USB hub with 4-5 Xbee USB/serial adapters. Some simple text parsing can then pull out the IV data and present it in whatever format is required. I use a perl script to strip the ID numbers and sort the IV curves into separate directories for each test module.

The Software

The software is written in C and compiled with avr-gcc on linux. I used an Atmega644P, but other AVR micros would probably work with minor modifications.

In addition to the IV datapoints, the microcontroller also measures battery voltage and keeps a rolling window of Isc measurements. Since Isc is a good proxy for irradiance, I’m using this measurement to increase the time between IV measurements during periods of darkness. Since the Xbee coordinator expects all the endpoints to “check in” periodically, we can’t just sleep all night long, but this at least provides a basic way to conserve battery.

So… does it work?

Yes! Below are some sample IV curves. This is a plot of the raw data from the device, and you’ll notice that it doesn’t truly measure short circuit current. When the relay contacts close, it takes about 5-10ms for the current into the capacitors to reach a peak value due to inductance. In practice, this isn’t all that important, because we can simply extrapolate back to Isc. In fact, I have to do the same thing even when measuring IV curves with $5K electronic loads.

Sample IV curves

Sample IV curves

Downloads and links

Note: the design of this IV tracer is licensed under a Creative Commons license Attribution-NonCommercial-ShareAlike 3.0 Unported

PCB files (these will work with the free version of Eagle):
NOTE: These are my revised boards based on the first prototypes, and I haven’t had a chance to test them yet. I’ll update this page once I verify these designs.

Logic Module schematic
Logic Module PCB
Power Module schematic
Power Module PCB

PDFs:
Logic Module Schematic
Logic Module PCB
Power Module Schematic
Power Module PCB

Source:
C source code

Battery:
Either the 1000 mAh battery from Sparkfun
or the 900 mAh

Enclosure:
NEMA 4X enclosure from McMaster-Carr

Optimizing for Time of Use – Trackers vs Fixed Tilt

Most power companies have a tiered rate structure for electricity that makes energy generated during peak demand hours more valuable. In the northern hemisphere, you almost always get the maximum annual energy generation for a PV system by orienting the system due south (unless you have strange weather patterns, like cloudy mornings and sunny afternoons but that’s not typical). But if energy generated in the late afternoon/early evening (typical peak time) is worth significantly more the the power company, you can easily get a net benefit from altering the system azimuth to capture more energy during a specific time of day even though the result is a lower annual energy yield. You’re essentially trading annual energy for energy captured at a specific time of day.

With this in mind, I recently ran a performance analysis using actual time of use data for a large scale project, and the results were somewhat surprising.

First, the plots of annual energy vs. system azimuth (180 degrees is due south) for horizontal single axis trackers and fixed tilt PV systems:

Fraction of annual energy delivered versus system azimuth angle for single axis tracker and fixed tilt PV systems.

Fraction of annual energy delivered versus system azimuth angle for single axis tracker and fixed tilt PV systems.

Both systems deliver their respective maximum annual energy when the system azimuth is 180 degrees, but the overall effect of the azimuth rotation is quite small, even for large rotations of 20 degrees or so. There’s also some skew to the data due to the weather at the particular location I’m using. I should also point out that the single axis tracking system produces about 18% more energy at this location.

If we take the Time of Use factor (a value ranging from 0.6 to 2.5 depending on season and time of day) and multiply it by the hourly system output for each hour over the course of a year, we get some interesting results:

Annual Energy scaled by the Time of Use factor versus system azimuth angle.

Annual Energy scaled by the Time of Use factor versus system azimuth angle.

First, the fixed tilt system will deliver its greatest number of dollars per year when installed with an azimuth of 200 degrees (20 degrees West of South). Second, the single axis tracking system benefits very little from an azimuth rotation, and what little benefit there is occurs in the opposite direction (East of South). This is because the tracking system’s panels are already pointed to the West in the late afternoon, in a great position to capture sunlight during the period of peak demand. It’s a little counterintuitive, but rotating the tracker axis (the North-South axis) away from the sun actually points the panels more directly at the afternoon sun.

So to summarize, the tracking system produces 18% more annual energy, and doesn’t need any site-specific optimization of the install to maximize the benefit based on the Time of Use factors.

Adding a real tracking algorithm to PVWatts

The web version of PVWatts doesn’t take into account the effect of one row of panels/trackers casting a shadow on another, and neither does it account for backtracking in the morning and evening to avoid shading. Essentially, you are modeling the performance of a single tracker.

NREL has a page devoted to derate factors here which provides a rough approximation for a shading derate based on GCR (ground coverage ratio), but in reality the affect of backtracking is dependent on location.

With this in mind, I modified the PVWatts source to calculate the correct incident angle (function incident2) for a horizontal single axis tracker given a GCR, and ran the simulation for a number of GCR’s and locations. Here is a sample result:

Derate factor versus GCR for 3 different locations

Derate factor versus GCR for 3 different locations


This shows the actual derate factor you can expect as a function of GCR for 3 different locations. Clearly, they are NOT all the same! At a GCR of 40%, there’s a 1.4% difference in energy lost between San Diego and Salt Lake City.

With small changes like this I’m getting closer to a model that accurately predicts real world performance.

Measured inverter efficiency curves

Thanks to the California Energy Commission we can see what a real inverter efficiency curve looks like, and compare it to the pvwatts model.

It turns out that the pvwatts model doesn’t match reality very well. The pvwatts nominal efficiency of 92% is well below the average of current inverters, and the 4th order polynomial is a rather poor fit to the shape of the efficiency curve.

The plot below shows the measured efficiency curve for a SatCon PVS-135 (green) and the pvwatts model (blue). Clearly there’s quite a bit of room improvement.

I’ve created a log function to model the inverter and plotted that in red. Substituting the improved model in pvwatts calculations results in about a 4.5% increase in annual energy.

Even if you don’t know what inverter will be used in a particular case, just increasing the nominal efficiency inside pvwatts from 92% to something around 95% seems reasonable given the test data on the CEC site.

Inverter Efficiency Curves

Inverter Efficiency Curves

pvwatts inverter model

This is a plot of the pvwatts inverter model. Nominal efficiency is 92%, but if the input power is between 10 and 100%, a 4th order polynomial is used to calculate efficiency, and convert dc power to ac. If this is accurate (I haven’t yet found any efficiency curves published by inverter manufacturers), then there are some clear implications for string sizing.

pvwatts inverter model

pvwatts inverter model

Under the hood of pvwatts

One of the projects I’m working on right now involves getting under the hood of pvwatts, the solar performance prediction software from the National Renewable Energy Laboratory.

Just about everyone in the solar energy world is familiar with pvwatts, but how many of them have actually had a chance to examine the source code? I’m just digging into it now, and I’ve already found several areas that could use some improvement. Considering how widely accepted this calculator is, the code is quite a shock. The algorithms make sense, but the implementation is a bit frightening.

More to come.