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.