13 min read
This blog post is fourth of a 5-part series that explores the use of IoT and Data Science to maximize solar energy by leveraging the MapR Data Platform. Read the previous 3 blog posts here, here, and here.
So my data confirms that I have some weird behavior, but now I want to finish understanding the math of "how can I know what optimum is?" After reading the paper from the NREL (https://www.nrel.gov/docs/fy13osti/58891.pdf), I realized that I already had the information I needed in order to calculate it.
Essentially, the NREL paper breaks down determining the optimum angle of a single axis tracker to:
R = tan-1(X) + ψ
R is the Optimum Rotation angle of the panels along the axis
With the variables defined as:
θΖ - The Zenith Angle of the sun (or 90 - the sun's altitude)
γS - The Solar Azimuth, or the position of the sun around a circle, 0 degrees being due north, 180 being due south
γα - The Axis Azimuth of the array. This is 180, in that the down slope of my arrays point due south or 180 degrees.
βα - Axis Tilt. This is the angle from the back of the array to the front, when the panels are flat.
And as to the value of ψ, it's dependent on the result of X.
So, being perfectly honest, this function made my head swim. Once I stared at it long enough, I realized I needed four variables. The axis tilt and axis azimuth were easy. These are static for both arrays. Axis tilt is 20 degrees and axis azimuth is 180 degrees.
The sun zenith angle and azimuth are also easy to obtain for any given time, using the Python module I mentioned earlier called Pysolar (https://github.com/pingswept/pysolar). This allows me to provide a date, local time, latitude, and longitude, and it will return the sun's altitude and azimuth.I wondered why I needed to provide longitude, and questioned if it was even needed, and yet again, my colleague Dr. Ted Dunning pointed out that without it, the calculations could be quite a bit off, given our longitudinal placement in a timezone. Thus, providing longitude IS needed for an accurate solar time calculation and accurate sun positions relative to where we are.
So, given that equation, I wrote a Python function that took those 4 variables and returned the optimum rotation along the axis. (Note that the equation wants zenith, not altitude, so I changed that right away in the function by subtracting the altitude from 90 degrees to get the zenith.) All of the Python math module's trigonometry functions expect variables and return results in radians; my function takes all things in degrees, and returns degrees, so I needed to handle that on return.
The result of this math is a simple function:
The initial results seemed promising, and after working out some syntax errors and other minor math flubs, I was ready to test the equation on my panel data.
Now that I had a function, I could not only implement in my tracking program but also, since I've been collecting data (including the sun azimuth and altitude at the time), actually do some graphing to see how it WOULD have done in the past. Unfortunately, November appears to be the arch nemesis of solar production, so my sampling of days is not verbose. Here are a few examples with discussion on each.
Note, the first query on these examples is to determine the conversion factor from the sensor. We are using rough math here, but the max rotation is 41 degrees, and then I take the max and the min of the sensor readings, average them, and then divide them by my actual angle to get my conversion x factor. I then use that in my query to return the actual angle rather than the sensor reading. This allows me to graph it next to the optimal sun rotation angle returned from the function. Anything returned from the optimal sun function beyond 41 or -41 is just the limitation of the tracker motion: I can't physically move my array past those rotations.
The 41 degrees range is the accurate number for these arrays; however, for a time, I was using 50 to -50 degrees as my rotational range. I obtained 50 degrees by attempting to manually measure (poorly) the array as it was tilted. After I measured it, I realized a couple of things:
In order to get a more defensible measurement for rotational angle, I reached out to the helpful folks at U.S. Solar Mounts; they stated that the array was designed to have a max surface angle range of -45 degrees to 45 degrees. Surface angle takes into account the axis tilt (20 degrees). When I looked at the NREL paper, they gave a function to determine surface tilt as:
cos-1((rotational angle) (axis tilt))
When I used this function to model out all the potential rotation angles, I realized that to get the 45 degree surface tilt, my ACTUAL rotation angle was very near 41. Thus, this is what I use in my calculations. It's better to use an equation here than a poorly obtained physical measurement.
Now that we know the rotational angle calculations and have the data from the sensors, let's look at a few days to graph the array position as well as where the rotational angle SHOULD be based on the NREL function. For each of these, I include some observations.
As we can see here, when the tracker is tracking (from around 11:40 to around 12:50), the derived optimum (orange) and the actual (produced via optical tracking) are right in line, if perhaps off by a bit. We may be able to say that is due to the optical eye only accounting for azimuth and not angle.
More thought given: It's due to me, using min/max to calibrate sensors rather than averages; I will explain later in this blog post!
There are parts, though, where the eye goes haywire and looks the wrong way (from around 10:30 to 11:40 and 12:50 to around 13:30).
In the above graphs, even when trackers ARE tracking correctly, there is sometimes a space between the tracker line and the optimal line. After some testing done on Nov. 13, I realized that it comes from poor calibration of the sensors.
Essentially, when the array is all the way west or all the way east, the sensor (for example, on the north array) would use values from 1345.0 (east) to -1308.0 (west). I mentioned this earlier. However, earlier I was taking the MAX or MIN of these values to determine my range. But this is a sensor that takes hundreds of readings per second, and I am only sampling a few times. The min/max readings are not actually indicative of whether the array is full east or full west; min/max are actually outliers. So what I did is: over a couple of days, I took large time blocks that indicate the array is full east or full west and averaged the values in that position. Instead of using the min/max, I've used the derived averages for those time frames.
Essentially, I graphed it for two days, and then took some of the blocks of full east or full west and found averages; once I did that, I got an angle factor of 29.451. This actually helps both of my array graphs: both are now spot-on (see the following graphs for tracking today, Nov. 13).
Note: The south array is not fully calibrated from a mechanical perspective. I realized I need to set the arm length on the actuator to be exactly halfway when the array is perfectly level. I've done it fairly accurately on the north array, but it's November in Wisconsin, and it's cold. I'd like to spend some time dialing that in with some help, as I need to adjust the arm that holds the panels in place. Right now, it's "close enough" for me, and I will work on that when the days are bit warmer.
The data looks promising. We will review the results in the next and final blog post of the series.
Stay ahead of the bleeding edge...get the best of Big Data in your inbox.