Loaded 15W/50W Micro Wind Turbine Characterization

This past weekend we did the loaded testing for the two potential configurations for the wind turbines for Project Curacao.  

Two 15W Wind Turbine Configuration

We first tested a two 15W Wind Turbine configuration.  Our guess is that we could get at least a trickle charge out of these turbines at wind speeds of 15MPH.

Two 15W Turbines

We loaded the 15W turbines down with the actual Project Curacao charging circuitry.  This consisted of a DROK 3A/18W DC Buck Converter Car Regulated Power SuppIies 9-22V 12V to 6V wired to a relay that switches between the solar panels and the Wind Turbines and then to the solar battery charger,  LiPo Rider Pro.  This is the actual configuration used in Project Curacao.

This configuration is my "Load".   Please understand that your "Load" may not have the same impedance or characteristics of my "Load".  A better way of measuring this generally would be to discharge the Wind Turbine into a resistive load (a 65 ohm load in this case based on the data below) and measure the voltage.

The voltage was measured in the car at the wind speed shown.  

After the test outside, a variable power supply was connected to the Project Curacao box and the currents were read from the power supply current screen and from the Raspberry Pi RasPiConnect screen.   This is done on the assumption that a voltage is a voltage is a voltage when it is DC with little ripple.  Thus, I can put the measured voltage in to the system and read the currents from the software.  This avoids carrying a laptop, wireless connection, iPad, etc. in the car during test.

50W Wind Turbine Test

Based on some fragmentary data from a previous test run and the last test run it is clear that  the 50W Wind Turbine does far better than the smaller turbines at low wind speed.  No surprise there.  Clearly, at about 15MPH we can produce all the power we need.  We can generate a loaded regulated voltage of 6.4V at 15MPH (based on two measurements).  This gives us plenty of current to charge the battery, even when the Pi is running.

50W Wind Turbine

During the test photographed to the left, we blew out the DC/DC voltage regulator with an over voltage condition.  The damage was limited to the regulator.

Why did this happen?  

The open loop voltage measurement on the 50W Turbine gives us a clue.  The regulator is specified as a maximum 22V input.  When the turbine hits more than about 25MPH, we started to generate more than 22V, even loaded.  This eventually fried the regulator.  

What did we miss in our test setup?  

The 50W Wind Turbine very minimal specifications say in perfect conditions we can get 2A at 25V which is 50W.  However, if we aren't taking 2A (which is 2X to 4X our maximum), the voltage goes up.  Eventually, it killed our regulator.  We did not think that one through.

How to fix it?  

Add an over voltage circuit on the Wind Turbine side of the regulator.  We will build one of zener diodes and make sure we size it for about 4A to cover hurricanes (although in a hurricane, that will be the least of our problems - We would expect the Turbine to be halfway to Aruba by then).

We will set the over voltage protection at 20V to avoid this problem in the future.  We have ordered a new power supply and will build a over voltage circuit and re-run the tests in the next couple of weeks.

Conclusions

This leads us to several conclusions:

1) We need a wind speed of 20 MPH to generate power in our system using the two 15W Wind Turbine System.  We are sure there are better low speed turbines for our system.

2) The average wind speed in Curacao is about 14 MPH.  This means a substantial part of the time we won't be generating power.  How do we fix this?  We move the wind turbine higher on the tower as the wind speed is generally higher the higher you are above the ground.  We want the turbine as high as we can reasonably get it.  We gain about 15% in wind speed going up 10 meters (http://wind-data.ch/tools/profile.php), so we will see what can do.  We don't have a good number on the spread of wind speeds in but it looks like the bulk of the wind is between 10 MPH and 25 MPH so we will get some power.  Good thing we have solar cells.

3) Note how the voltage flattens out as we approach 50 MPH at about 16.5V on the open loop 15W turbine test.   Our system is designed to measure up to 17V (a voltage divider down to 5V for the Arduino) and tolerate up to 18.7V (no more than 5.5V into the Arduino).  This looks good.  If we have more than 50 MPH winds, the analog inputs will be the least of our problems.

Our control system will take this into account on cloudy days (low luminosity and solar voltage) and turn the wind turbine on.  Of course, we will turn the wind turbine on at night all the time.

Matplotlib, Raspberry Pi, MySQL and Project Curacao

One of the things we are using the Raspberry Pi on Project Curacao for is to generate graphs.  Yes, We know we could ship the data to another server and generate the graphs there, but since we have a nice linux platform, we decided to make the graphs on site.  Then we ship the graphs both to a webpage and also over to the RasPiConnect directory for display on the RasPiConnect App (www.milocreek.com).

Here's a picture of the embedded graph (in RasPiConnect):

The RasPiConnect Local.py code for a graph follows:

#W-11 is Pi System Status 

if (objectServerID == "W-11"):

                #check for validate request

                if (validate == "YES"):

                        outgoingXMLData += Validate.buildValidateResponse("YES")

                        outgoingXMLData += BuildResponse.buildFooter()

                        return outgoingXMLData

            # normal response requested

imageName = "systemstatistics.png"

               responseData = "<html><head>"

                responseData += "<title></title><style>body,html,iframe{margin:0;padding:0;}</style>"

                responseData += "</head>"

                responseData += "<body><img src=\""

                responseData += Config.localURL()

                responseData += "static/"

                responseData += imageName

                responseData += "\" type=\"jpg\" width=\"800\" height=\"300\">"

                responseData +="</body>"

                responseData += "</html>"

                outgoingXMLData += BuildResponse.buildResponse(responseData)

      outgoingXMLData += BuildResponse.buildFooter()

                return outgoingXMLData

Note that if you want to use a button to select different type of graphs for the same RasPiConnect control, you write the graph name to a file and the read the file to get what graph to display.  Make sure you assign the Web Control to refresh when you push the button.  Then you get an immediate response.  

You can select a different graph by using a feedback control button to write that file (that contains the graph name) and cycle through graphs (see my video on this blog for an example) as below:

# FB-11 - change the graph display 

if (objectServerID == "FB-11"):

                #check for validate request

# validate allows RasPiConnect to verify this object is here 

                if (validate == "YES"):

                        outgoingXMLData += Validate.buildValidateResponse("YES")

                        outgoingXMLData += BuildResponse.buildFooter()

                        return outgoingXMLData

# not validate request, so execute

               responseData = "XXX"

if (objectName is None):

objectName = "XXX"

               lowername = objectName.lower()

                if (lowername == "display voltages"):

                        responseData = "display currents" 

                        responseData = responseData.title()

                f = open("./local/GraphSelect.txt", "w")

                f.write(lowername)

                f.close()

                elif (lowername == "display currents"):

                        responseData = "display solar/wind" 

                        responseData = responseData.title()

                f = open("./local/GraphSelect.txt", "w")

                f.write(lowername)

                f.close()

                elif (lowername == "display solar/wind"):

                        responseData = "display voltages" 

                        responseData = responseData.title()

                f = open("./local/GraphSelect.txt", "w")

                f.write(lowername)

                f.close()

# defaults to display currents 

                else:

                        lowername = "display currents" 

                f = open("./local/GraphSelect.txt", "w")

                f.write(lowername)

                f.close()

                        responseData = "display voltages" 

                        responseData = lowername.title()

                outgoingXMLData += BuildResponse.buildResponse(responseData)

                        outgoingXMLData += BuildResponse.buildFooter()

                 return outgoingXMLData

We decided to use the excellent python based matplotlib package.  Here are the steps to get the necessary packages:

$ sudo apt-get install libblas-dev        ## 1-2 minutes
$ sudo apt-get install liblapack-dev      ## 1-2 minutes
$ sudo apt-get install python-dev        ## Optional
$ sudo apt-get install libatlas-base-dev ## Optional speed up execution
$ sudo apt-get install gfortran           ## 2-3 minutes
$ sudo apt-get install python-setuptools  ## ?
$ sudo easy_install scipy                 ## 2-3 hours

$ sudo apt-get install python-matplotlib  ## 1 hour

Thank you http://wyolum.com/numpyscipymatplotlib-on-raspberry-pi/

We run graphs on our pi system based upon entries in apschedule:

    scheduler = Scheduler()

   

    job = scheduler.add_cron_job(powerdatacollect.datacollect5minutes, minute="*/5", args=['main', 0])

    job = scheduler.add_cron_job(watchdogdatacollect.watchdogdatacollect, minute="*/5", args=['main', 30])

    job = scheduler.add_cron_job(environdatacollect.environdatacollect, minute="*/15", args=['main', 10])

    job = scheduler.add_cron_job(systemstatistics.systemstatistics15minutes, minute="*/15", args=['main', 20])

    job = scheduler.add_cron_job(doallgraphs.doallgraphs, minute="*/15", args=['main',10,60])

    # camera

    job = scheduler.add_cron_job(useCamera.takeSinglePicture, hour="*", args=['main',50])

    # send daily picture

    job = scheduler.add_cron_job(sendPictureEmail.sendPictureEmail, hour="22",minute="20", args=['main',0])

One good thing about running tasks like this in another thread, is that a hang in one of the threads does not stop the whole system.  Just that thread.


Here is the example matplotlib code and graph for one of the graphs (including the call to MySQL to get the data).  We are using the Solar/Wind line to show which power source is selected.  Reg Wind Volt gives the voltage on the regulated side of the DC/DC 12V - 6V Buck converter (fed to the solar power charging circuitry) and Unreg Wind Volt is on the Wind Turbine side of the converter.  We choose to use just points because of the intermittent nature of the wind.  See the post on the wind storm we had a couple of weeks ago.  This was the graph generated after a couple of trips in the car with various wind turbines.

# solar wind graph generation

# filename: solarwindgraph.py

# Version 1.4 01/12/14

#

# contains graphing routines

#

#

import sys

import time

import RPi.GPIO as GPIO

import gc

import datetime

import matplotlib

# Force matplotlib to not use any Xwindows backend.

matplotlib.use('Agg')

from matplotlib import pyplot

from matplotlib import dates

import pylab

import MySQLdb as mdb

sys.path.append('/home/pi/ProjectCuracao/main/config')

# if conflocal.py is not found, import default conf.py

# Check for user imports

try:

        import conflocal as conf

except ImportError:

        import conf

def  solarwindgraph(source,days,delay):

        print("solarwindgraph source:%s days:%s delay:%i" % (source,days,delay))

        print("sleeping :",delay)

        time.sleep(delay)

        print("solarwindgraph running now")

        # blink GPIO LED when it's run

        GPIO.setmode(GPIO.BOARD)

        GPIO.setup(22, GPIO.OUT)

        GPIO.output(22, False)

        time.sleep(0.5)

        GPIO.output(22, True)

        # now we have get the data, stuff it in the graph

        try:

                print("trying database")

                db = mdb.connect('localhost', 'root', conf.databasePassword, 'ProjectCuracao');

                cursor = db.cursor()

                query = "SELECT TimeStamp, RegulatedWindVoltage, UnregulatedWindVoltage, SolarWind FROM batterywatchdogdata where  now() - interval %i hour < TimeStamp" % (days*24)

                cursor.execute(query)

                result = cursor.fetchall()

                t = []

                s = []

                u = []

                v = []

                for record in result:

                        t.append(record[0])

                        s.append(record[1])

                        u.append(record[2])

                        v.append(record[3])

                print ("count of t=",len(t))

                # scale array for Solar =0 Wind = 1

                for i in range(len(v)):

                        v[i] = v[i] * 10

                #dts = map(datetime.datetime.fromtimestamp, t)

                #print dts

                fds = dates.date2num(t) # converted

                # matplotlib date format object

                hfmt = dates.DateFormatter('%m/%d-%H')

                fig = pyplot.figure()

                fig.set_facecolor('white')

                ax = fig.add_subplot(111,axisbg = 'white')

                ax.vlines(fds, -200.0, 1000.0,colors='w')

                ax.xaxis.set_major_locator(dates.HourLocator(interval=6))

                ax.xaxis.set_major_formatter(hfmt)

                ax.set_ylim(bottom = -200.0)

                pyplot.xticks(rotation='vertical')

                pyplot.subplots_adjust(bottom=.3)

                pylab.plot(t, s, color='b',label="Reg Wind Volt",linestyle="",marker=".")

                pylab.plot(t, u, color='r',label="Unreg Wind Volt",linestyle="",marker=".")

                pylab.plot(t, v, color='g',label="Solar/Wind",linestyle="-",marker=".")

                pylab.xlabel("Hours")

                pylab.ylabel("Voltage")

                pylab.legend(loc='upper left')

                pylab.axis([min(t), max(t), 0, 20])

                pylab.figtext(.5, .05, ("Solar / Wind System Last %i Days" % days),fontsize=18,ha='center')

                pylab.grid(True)

                pyplot.show()

                pyplot.savefig("/home/pi/RasPiConnectServer/static/solarwindgraph.png")

        except mdb.Error, e:

                print "Error %d: %s" % (e.args[0],e.args[1])

        finally:   

                cursor.close()

                db.close()

                del cursor

                del db

                fig.clf()

                pyplot.close()

                pylab.close()

                del t, s, u, v

                gc.collect()

                print("solarwindgraph finished now")

Windstorm on RasPiConnect

Here is a screen shot of RasPiConnect capturing the wind storm that came through last weekend.  We had the 15W Wind Turbine hooked up and reporting through the Project Curacao software.  It was fortuitous that the wind storm came through.  It pointed out that one 15W Micro Wind Turbine does not provide enough energy to charge the Project Curacao box in normal winds (15 MPH).

RasPiConnect Pi Power Subsystem Screen

Project Curacao Software Status (01/22/14)

We are approaching the final testing deadline (February 1st).

As of today (01/22/14), the current state of the software in Project Curacao is as follows:

- Arduino Battery Watchdog:  

1. Control of the wind turbine (selection between solar and turbine).  Currently this is manual (through the RasPiConnect Pi Power Subsystem Page)

RasPiConnect Screen modified for Wind/Solar Selection

- Project Curacao Pi main program:  The main program is generating all the graphs, camera pictures, environment sensing as required.  It is also regulating the Fan automatically now.    Reading log files from the Arduino Watchdog.  Next  things to be implemented:

1. Improving sensor error detection (Vastly improved, but still needs more)
2. Final Wind Turbine added to the battery Charging system and reporting

- RasPiConnect:  We have a few more graphs and dials and buttons to implement on the RasPiConnect software, but it's pretty close to final.  We use this all the time now to monitor what is going on in the project remotely.   

Here's the newest main screen (1 of 6 at this point):

pi camera / raspistill problem behavior change

Yesterday, we installed all the new updates and upgrades to the Raspberry Pi in preparation for the trip to Curacao (we leave at the end of February).  When we looked at the power system display this morning, we were surprised to see that the Pi was now taking  350ma or more instead of the around 200ma it had been taking on the average.

RasPiConnect Power Subsystem Screen

Something about the update increased current consumption by 75%.  After noticing that the camera was no longer working, we looked at the processes running (ps axf) and we found that the camera process seemed hung.

After some experimenting (running the command by hand with the '-v' option), we found that in the latest update, raspistill had changed the behavior of the '-t' option.  The new behavior had the camera continually taking new pictures, rather than just one.  This means that the process never exited and used a ton of current taking pictures, one after another.

The old command (which had been working for months):

raspistill -o /home/pi/RasPiConnectServer/static/picameraraw.jpg -t 0

The new command (which now works correctly - only one picture):

raspistill -o /home/pi/RasPiConnectServer/static/picameraraw.jpg -t 100

So the behavior of the '-t' option changed.  '0' now means capture pictures for ever and we have to give a value > 0 for single capture.


We also added the command:

/opt/vc/bin/tvservice -off

in /etc/local.rc to turn off the HDMI/PAL outputs on the Pi since we don't use them.  This reduced the current draw about 20ma.  You can see the 20ma drop in the base Pi current (green on the graph above).

Project Curacao / RasPiConnect Video

The folks over at Milocreek.com (Authors of the RasPiConnect App) asked us to put together a short video of Project Curacao focusing on the control panel (done in RasPiConnect).

Here it is:

Small Micro 15W/50W Wind Turbines Characterization - Open Loop

Update (03/26/2014):  We have finished the characterization and deployed the 50W wind turbine.  The model and characterization was close.  See the blog posting about the 50W Loaded Characterization and the Project Curacao Operational Blog posting)

 We decided a while ago to add a small wind turbine to Project Curacao.  This week we finally got around to installing the wind turbine in the Project Curacao system.  We are measuring the unregulated wind turbine voltage, the regulated wind turbine voltage and the Pi solar panel voltage using the Arduino Battery Watchdog A/D converters.  After understanding the Arduino A/D (it has one A/D converter and then multiplexes the individual analog pin), we had to add multiple delays and reads to allow the voltages to stabilize.  We also average 10 values of important channels (the battery voltage of the Pi in this system) to reduce noise.

An excellent thread reference about reading multiple A/D analog channels on the Arduino is: http://forum.arduino.cc/index.php?topic=54976.0

The description of the Analog to Digital converter on the Arduino from the specification follows:

"The analog input circuitry for single ended channels is illustrated in Figure 23-8. An analog
source applied to ADCn is subjected to the pin capacitance and input leakage of that pin, regardless
of whether that channel is selected as input for the ADC. When the channel is selected, the
source must drive the S/H capacitor through the series resistance (combined resistance in the
input path).
The ADC is optimized for analog signals with an output impedance of approximately 10 kΩ or
less. If such a source is used, the sampling time will be negligible. If a source with higher impedance
is used, the sampling time will depend on how long time the source needs to charge the
S/H capacitor, with can vary widely. The user is recommended to only use low impedance
sources with slowly varying signals, since this minimizes the required charge transfer to the S/H
capacitor.
Signal components higher than the Nyquist frequency (fADC/2) should not be present for either
kind of channels, to avoid distortion from unpredictable signal convolution. The user is advised
to remove high frequency components with a low-pass filter before applying the signals as
inputs to the ADC."

The Wind Turbine we are using is a $90 single blade 15 Watt DIY Small Wind Turbine Kit system from http://store.sundancesolar.com/15-watt-diy-small-wind-turbine-kit/

We aren't specifically recommending this turbine but it was the first inexpensive one we ran into so we bought it.   The first thing we needed to do was characterize the open loop voltage curve so we knew what voltages we were getting out of the turbine.  We put the turbine on a garden spade (literally) and stuck it outside the car through the window and drove at fixed rates of speed and measured the voltage with a multimeter.  We got strange looks from the neighbors (and a policeman) and had a hard time maintaining the speed because of the blizzard and ice on the road.  

The Wind Turbine on a Spade

Wind Turbine and Car in Snowstorm

We gathered the data up to 50 MPH, put it in an Excel spreadsheet and did a third order polynomial curve fit to get an equation to use in the software to predict the wind speed given an open loop voltage (which we are gathering).

The equation we are using is:

Equation: y = (c3 * x^3) + (c2 * x^2) + (c1 * x^1) + b

Where:
y = Wind Turbine Output Voltage
x = Wind Speed in MPH

The coefficients are:

c3	-0.000224491
c2	0.012549184
c1	0.255523699
b	0.247342657

The maximum curvefit  errors are +0.4V/-0.6V, +6.89%/-4.74%.  Good enough for our purposes.  Our data certainly isn't any better than +/-10% given the snow and general driving.

We are using this curve for control functions inside the Arduino Watchdog and for calculating the wind speed.

We are looking for a minimum 9 volts to run into our 6V regulator (which then is fed to the battery charging circuit).  

This leads us to several conclusions:

1) We need a wind speed of 20 MPH to generate power in our system.  We are sure there are better low speed turbines for our system.

2) The average wind speed in Curacao is about 14 MPH.  This means a substantial part of the time we won't be generating power.  How do we fix this?  We move the wind turbine higher on the tower as the wind speed is generally higher the higher you are above the ground.  We want the turbine as high as we can reasonably get it.  We gain about 15% in wind speed going up 10 meters (http://wind-data.ch/tools/profile.php), so we will see what can do.  We don't have a good number on the spread of wind speeds in but it looks like the bulk of the wind is between 10 MPH and 25 MPH so we will get some power.  Good thing we have solar cells.

3) Note how the voltage flattens out as we approach 50 MPH at about 16.5V.   Our system is designed to measure up to 17V (a voltage divider down to 5V for the Arduino) and tolerate up to 18.7V (no more than 5.5V into the Arduino).  This looks good.  If we have more than 50 MPH winds, the analog inputs will be the least of our problems.

Our control system will take this into account on cloudy days (low luminosity and solar voltage) and turn the wind turbine on.  Of course, we will turn the wind turbine on at night all the time.

Next post we will describe the regulator for connecting the wind turbine to our charging system.  We are waiting for a new variable power supply to run these checks as we only get about 5 MPH out of our box fan.

Project Curacao Software Status (01/04/14)

We are now doing system testing on the control software.  We have tested battery voltage shutdowns/startups, watchdog shutdown/startups, and alarm based shutdowns/startups.
Next, we have to test the deadman switch and add the 15W Wind Turbine.  Then the final testing begins.  We are installing in less than two months.

As of today (01/04/14), the current state of the software in Project Curacao is as follows:

- Arduino Battery Watchdog:  The watchdog is reading and reporting data back to the main software in the Pi via a serial link through level shifters.  

1. Communication between Pi and Watchdog is now reliable.  We had a timing problem where two processes were trying to use the same serial port at the same time.
2. Pi power control - Complete and now in system testing.  We now are putting the Pi to sleep and waking it up at appropriate times.  We have now added the code to put the Pi to sleep if the Pi batteries are close to being discharged and then wake it up appropriately if the batteries recover.  We are rewriting the voltage control code to make it more understandable and easier to test.
3. Watchdog logging - Implemented.  Log from watchdog is now transferred to the Pi for storage in the MySQL database.
4. Control of the wind turbine (selection between solar and turbine)

- Project Curacao Pi main program:  The main program is generating all the graphs, camera pictures, environment sensing as required.  It is also regulating the Fan automatically now.    Not yet reading log files from the Arduino Watchdog.  Next  things to be implemented:

1. Logging Arduino Watchdog Data - complete
2. Improving sensor error detection
3. Wind Turbine added to the battery Charging system

- RasPiConnect:  We have a few more graphs and dials and buttons to implement on the RasPiConnect software, but it's pretty close to final.  We use this all the time now to monitor what is going on in the project remotely.   We are thinking it might be good to put in a process monitor graph and reboot function.  Both are easily done. 

1. Added support for the new RasPiConnect alarms.  
2. Added Arduino Battery Watchdog log print and request. 

Here's the newest main screen (1 of 6 at this point):

Dead Man Switch

The Battery Watch Arduino software has expanded to about 3000 lines of code.  Guess what?  There are certainly bugs in this software.  One of the unresolved issues about the architecture of Project Curacao is that the software on the Raspberry Pi can be updated remotely easily across the Internet.  The software on the Battery Watch Arduino on the other hand, can not be updated remotely as there is no current way of updating the Arduino without plugging in a USB serial port.  While we are investigating options (different boot loader, figuring a way of using the USB port on the Raspberry Pi for programming - we are looking at connecting the Pi to the Arduino while cutting the power line on the USB line and feeding power from our power subsystem via the cut line to both the Pi (from the Pi Power Subsystem) and to the Arduino from the BatteryWatchdog Power Subsystem - this actually looks promising but we haven't done it yet), we want to make our system just a bit more resilient than it currently is.

For example, last night we programmed the Pi to wake up time accidentally before the shutdown for the midnight "peek" at Curacao.  The Pi went to sleep until the next midnight wake up time.  This got us thinking that we could make a mistake that would eventually shutdown our Pi forever.  That's not good for a unit 3,500 miles away.

So we are going to build what is called a "Dead Man Switch" in software.  If the Pi has not been turned on for two days, we turn it on and send an email if the Pi does come up.

How do we do this?

1) Set an alarm for two days from the last "Pi On" command

2) Reset the alarm each time the "Pi On" command is set

3) if this timer gets triggered and Pi is Off, disable the watchdog and the other sensors (bad sensor reading making Pi go off?)

4) Power Cycle the Pi and then leave on.  Send Interrupt to Pi to send email that the Dead Man switch has been triggered.

We might have a chance to contact the Pi with this, even if we have made mistakes in the code.

Another way to do this would be to build a timer in Hardware that would put the power on the Pi after two days.  This would be a better way of doing it, but our schedule is tight.

Who knows?  We may rue this decision.