We’ll start with one of my favorite summer recipes that is very simple, easy to make, and guaranteed to cool you off on even the hottest of summer days: Watermelon Aguas Frescas. Aguas Frescas, which means “fresh waters” in Spanish, is a refreshing non-alcoholic fruit drink that originated in Mexico, but is very popular today throughout Latin America and the Caribbean.

Ingredients

Serves 8

• 4 Cups Cubed Watermelon
• 1/2 Cup Water
• Juice of 1 Lime
• 24 Fresh Mint Leaves
• Ice
• Sugar to Taste (optional)

Instructions

1. Purée the watermelon, water, and lime juice in a blender until smooth.
2. Place 1/2 of a lime slice and 3 mint leaves into each glass and crush with a cocktail muddler.
3. Fill each glass with ice.
4. Pour the watermelon purée into each glass through a strainer to remove the pulp. While aguas frescas are traditionally served without pulp, if you prefer to have the pulp, simply omit the strainer.
5. Garnish with a lime slice and a mint sprig.

Tips

• You can substitute nearly any fruit you wish for the watermelon. Just make sure you remove the skin first. Some of my favorites include mango, peach, and coconut.
• I find making this drink with more watermelon and less water makes it taste even better! I also omit the optional sugar when I make it.

Enjoy.

The post Matt’s Favorite Summer Recipes: Watermelon Aguas Frescas appeared first on Matthew Gove Blog.

Before I begin troubleshooting an issue, I always brainstorm a list of at least 2-3 things that I think may be causing the problem. In no particular order, some of the potential causes I came up with were:

• An electrical problem that is causing voltages to go haywire
• A malfunctioning or defective sensor
• A bug in the Python code on the Raspberry Pi that reads the raw data from the sensor and converts it into Celsius

Start with the Easiest Issue to Troubleshoot

Before diving into troubleshooting, I always see if there are any causes I can reasonably eliminate. In this case, a malfunctioning or defective sensor is highly unlikely to be causing the problem. The sensor is an MPL3115A2 I2C digital barometric, temperature, and altitude sensor. It has been in service on the Raspberry Pi since last May and has taken nearly 1.2 million measurements. Of those 1.2 million measurements, the QA/QC algorithm has flagged 590 of them. That works out to 0.04% of measurements being bad, or a 99.96% measurement accuracy rate.

Identify Possible Bugs where the Raspberry Pi Interprets the Sensor Readings

Of the remaining two possibilities, I always start with whatever is easiest to troubleshoot. In this case, it would be a possible bug in the Python code. On the Raspberry Pi, Python interprets sensor readings and logs them in the database. Intermittent electrical problems are a nightmare to diagnose in the best of situations. The first thing to do is to look at the data and try to identify any patterns. If you’ve ever watched any detective shows on TV, you know what they always say: evidence doesn’t lie.

One pattern should jump out at you immediately. As air temperatures go to, and drop below freezing (0°C), the sensor readings on the Raspberry Pi go haywire. It is also important to note here that this does not rule out an electrical problem causing the problem. To strengthen our case, let’s query the sensor database to see if the sensor recorded any temperatures below freezing. We want to see no instances of the sensor recording temperatures below freezing.

We can now say with 100% certainty that something happens when the temperature hits freezing. However, we still don’t know what. To fully rule out an electrical issue causing the problem, it’s time to get on Google and research how the sensor works.

Can We Fully Rule Out an Electrical Issue Between the Raspberry Pi and the Sensor?

According to the manufacturer, there are three pieces of information that will help us here.

1. The sensor reads and transmits raw data in hexadecimal format.
   • In traditional decimals (such as 0.625), each element of the decimal can store values from 0 to 9. Those values are represented by the corresponding numerals.
   • In hexadecimal format, each element of the decimal can store values from 0 to 15. Those values are represented by the numbers 0 to 9 and the letters A to F.
   • Python uses standard mathematics to convert between hexadecimal and traditional decimal formats and vice versa.
2. Because of the way hexadecimal format works, the sensors cannot handle signed (i.e. negative) values in their raw format.
3. The sensors come with a software module that converts the raw hexadecimal data to a “human-readable” decimal temperature, in Celsius.

The Problem Lies with How Digital Sensors Handle Negative Values

To finally be able to rule out an electrical problem, let’s focus on item #2. The sensors not being able to handle signed (negative) values in their raw format. With any kind of digital sensor, if it gets a reading that’s off the scale, it loops around to the opposite end of the scale.

For example, if a sensor had a scale of 0 to 400 and got a reading of -1, it would output a value of 399. A reading of -5 would output 395. It works on the other end of the scale, too. A reading of 410 would output a value of 10. During my meteorology studies at the University of Oklahoma, we routinely observed this phenomenon while measuring wind speeds inside of tornadoes with doppler radar.

Item #2 is such a key piece of the puzzle because the problem occurs as soon as temperatures drop below 0°C. With this information, we can firmly establish the bottom end of the temperature sensor’s scale. Now all we had to do was figure out what the top of that scale was. For that, we have to look at the Python code, in which I found the following equation:

raw_temperature = ((raw_temperature_msb * 256) + (raw_temperature_lsb & 0xF0)) / 16

In this line of code, Python converts the raw temperature reading to standard decimal. Python reads in the sensor’s raw hexadecimal readings bit-by-bit before converting them to Celsius and sending the to the Raspberry Pi. Each reading from the sensor contains a maximum of 2 bits. For example, if this formula was used on a standard Base 10 number, such as 27, it would be read as:

temperature = (10 * 2) + (1 * 7) = 20 + 7 = 27

Calculating the Sensor’s Upper Bound

While that information may not seem significant on its own, it gives us enough information to calculate the upper end of the sensor’s temperature scale. Remember in hexadecimal, each bit can contain a value up to 16, so calculating the upper bound (in degrees Celsius) is simply:

Upper Bound = 16 * 16 = 256

Now that we have established that the sensor has a raw output range of 0 to 256°C, let’s look back at the query results. Keep in mind what I mentioned above about off-the-scale readings looping around to the other end of the scale.

What is the Actual Temperature of the Elevated Sensor Readings

To calculate the actual temperature, simply subtract 256 from the sensor readings in the 250’s. For example, if you look at the last entry in the above table, the actual temperature would be:

Actual Temp = 254.625 – 256 = -1.375°C

Using the above query as an example, the correct actual temperatures using the loop-around equation would be:

Implementing the fix before the sensor readings even reaches the QA/QC algorithm on the Raspberry Pi is simple. We simply need to add an if statement to the Python code that converts the raw hexadecimal sensor readings to degrees Celsius. Here is the original code:

try:
    raw_temperature = ((raw_temperature_msb * 256) + (raw_temperature_lsb & 0xF0)) / 16
    unrounded_temperature = raw_temperature / 16
except:
    raw_temperature = None
    unrounded_temperature = None

With the if statement added to fix the problem, the above block of code simply becomes:

try:
    raw_temperature = ((raw_temperature_msb * 256) + (raw_temperature_lsb & 0xF0)) / 16
    unrounded_temperature = raw_temperature / 16
    if unrounded_temperature > 70:
        unrounded_temperature -= 256
except:
    raw_temperature = None
    unrounded_temperature = None

Maintain Data Integrity

The final piece of the puzzle is to update the bad data points in the database to ensure data integrity. Amazingly, we can do that with a simple UPDATE command so we don’t lose any data. Full disclosure, this is not the actual database structure in the weather station. It’s just worded that way to make it easier to understand.

UPDATE `sensor_measurement`
SET `measurement_value` = `measurement_value` - 256
WHERE `measurement_type` = 'temperature'
AND `measurement_value` >= 70;

Well, this has certainly been an interesting one. It’s always a relief to confirm that the sensor is functioning exactly as it should and the problem is nothing more than an easy-to-fix bug in the Python code on the Raspberry Pi. Until next time.

The post Digging Deeper: Diagnosing My Raspberry Pi Temperature Sensor’s “Hot Flashes” appeared first on Matthew Gove Blog.

I recently logged onto my weather station to check some high and low temperatures for the month of January. While I was casually scrolling through the data, I caught something out of the corner of my eye. When I looked a little closer, I had to do a double take.

What was even more impressive were the “heat indices”. They make summers on the Persian Gulf, where heat indices can reach ridiculous levels, look like absolute zero. For comparison, the temperature of the surface of the sun is 9,941°F.

Hunting Down Bad Data Points on the Raspberry Pi

Both my and several friends’ initial reaction was to cue the jokes: “Well, it does get hot in Arizona…”, but unfortunately on a logic and reasoning test, science will beat humor every single time. Time to figure out why this happened. First, we need to run a query for all raw temperature data my sensors recorded that were greater than 60°C (140°F). I chose that cutoff based on the hottest temperature ever recorded in Arizona. On June 29, 1994, Lake Havasu City topped out at a sizzling 53°C (128°F).

Amazingly, the query returned almost 300 hits. Here is a small sample of them.

Sensors getting screwy readings like this is part of the deal when you operate any kind of data logger like this. I am much more concerned that so many bad data points managed to slip through my QA/QC algorithm on the Raspberry Pi. I’ll admit the QA/QC algorithm was the very basic one I wrote to just “get things going”. It was long overdue for an upgrade, but still, it should have caught these.

Once I queried the dates where these bad data points occurred, the culprit was revealed.

Recently Replacing the Sensor Adds a New Wrinkle

You may recall that this past December, I had to replace the analog temperature and humidity sensor that broke. I formally decommissioned the broken sensor on December 14, 2019. Did you happen to notice the first date of bad data? That’s not a coincidence.

So what caused the QA/QC algorithm to nod off and miss these bad data points? The answer goes back to the broken analog sensor. The broken sensor measured both temperature and humidity. When the relative humidity reading hiccuped, often showing values greater than 3,000% when it did, the corresponding temperature reading would get thrown off by about 10-20°C.

The problem is that 99% of those bad temperature readings were between -5 and 15°C (23 to 59°F). During the winter months, we see actual temperatures inside that range every day here in the Phoenix area, so you can’t simply filter them out. I wrote the original QA/QC algorithm to flag relative humidity values that were greater than 100% or less then 0%. I would deal with the temperature parameter when I updated the algorithm.

The New Temperature Sensor

The new digital sensor I installed only measures altitude, barometric pressure, and temperature. As a result, the Raspberry Pi reverted to obtaining its humidity data from the National Weather Service. The NWS data is already QA/QC’d. Because my original QA/QC algorithm only flagged humidity and not temperature, it deemed every data point that passed through it “OK”, thus rendering the algorithm redundant.

To confirm that this is the issue, the database puts the data that the QA/QC algorithm flags into a separate table in the sensor database. I use that data for troubleshooting and making improvements to the algorithm. A simple query will reveal the dates of temperatures I have flagged. If swapping the sensors did in fact make the QA/QC algorithm redundant, the query will only return dates on or after the sensor replacement. I replaced the sensor on December 14, 2019.

Thankfully, fixing the issue requires nothing more than a few lines of code to add an if statement to the algorithm so it flags temperatures that are outside of an acceptable range of -20 to 60°C. (-4 to 140°F). I chose the upper limit based on the hottest temperature ever recorded in Arizona (53°C/128°F). At the other end of the spectrum, I based the lower bound off of the coldest temperature ever recorded in Phoenix (-9°C/16°F). I will tweak that range as needed.

Looking Ahead

My goal is to continually add small upgrades and fixes to the QA/QC algorithm over the next year. By the time I have the complete network of sensors up and running, it will be up to a level of complexity that is acceptable for a hobby weather station. At the same time, I want it to be held as close to professional standards as I can. Stay tuned for future posts where we will look closer at what happens in the data logger’s electrical system to cause such wacky temperature readings.

The post Houston, I Think There’s a Bug in My Weather Station’s QA/QC Algorithm appeared first on Matthew Gove Blog.

Once I figured out that I needed to achieve smart home automation, the whole ball game changed. Automating simple tasks not only makes your life much easier, but it can also save you a lot of money. Some of the smart home automation solutions I use include:

• Automatically turn off all lights and lock all doors when I leave home or go to bed
• Automatically turn on the living room lights when I arrive home after dark or wake up in the morning.
• If I’m home, turn on the living room lights 10 minutes before sunset
• Turn the air conditioning off automatically when I open the house up (open the doors and windows)

Solving the Flaky Internet Connection Problem

I live in a rural area. One of the main issuesis having a fast, reliable internet connection. Where I live, cable and DSL internet connections are not an option, so I use a satellite internet connection. The satellite internet package gives me plenty of data and bandwidth to run my business. It’s also fast enough to stream Netflix, YouTube, and other audio and video channels.

One of my biggest complaints with satellite internet is that you get a lot of very short internet outages (less than 10 minutes). Anything from a bird landing on the satellite dish to sharp increases cable attenuation due to the extreme heat in the summer to thunderstorms passing overhead can cause these outages.

While it doesn’t seem like a big deal, those 10 minute outages always seem to hit when I’m on a Skype call with a client or a FaceTime call with my family. Murphy’s Law, right? To further compound the matter, more often than not, I have to reset the modem to re-establish the internet connection. Can we use smart home technology to automate the process?

The solution here is to connect your modem (and/or router) to a smart switch or smart outlet. Why I didn’t think of this sooner is beyond me. My smart home controller is kept in-house (it is not dependent on the cloud). It does not require an internet connection to work locally. In the worst case scenario, I can reset the modem with a couple taps on my phone instead of having to crawl around and contort myself just trying to reach the plug on the modem.

Automating the Modem Reset

The truly ingenious, and also most challenging part of the solution is configuring the system so it automatically resets the modem when the internet goes out. Note that on just about every smart home system, this will require writing a script. Thankfully, it is not too difficult.

In the example below (in pseudocode), the script will ping Google’s server 4 times, with 15 seconds between pings. If all 4 pings fail or do not receive a response, then it means the internet is down. The modem will be rebooted using the smart outlet or smart switch.

# First, define the IP Address you wish to ping. This *MUST* be
# an external IP Address (not on your local area network). In this
# example, we will ping one of Google's servers.
ipAddressToPing = "8.8.8.8"

# Then, define the number of seconds you wish to wait between pings.
secondsBetweenPings = 15

# Define the number of pings you want to perform
numberOfPings = 4

FOR i = 1 TO numberOfPings
   Ping ipAddressToPing
   IF i < numberOfPings THEN
      Wait secondsBetweenPings
   END IF
END FOR

IF All Pings Fail Or Receive No Response THEN
   Turn Modem Off
   Wait 30 Seconds
   Turn Modem On
   Note in system log that modem was restarted
END IF

A Big Step, But Still Not Perfect

Writing the script was a huge step towards the full solution. There’s still a major issue. We still need a trigger to run the script. The most logical solution is to run the script on a time trigger. In other words, run it on the top of every hour or run it every X minutes. However, the problem is that I need to reset the modem as soon as the internet goes out. Even that wouldn’t solve the issue of my Skype calls getting disconnected.

You could in theory have the script running pretty-much non-stop to detect outages sooner, but my smart home controller is not powerful enough to do that while still running the rest of the system. Back to the drawing board.

Finally Solving the Skype/FaceTime Issue

It turns out that trying to close the internet outage gap completely is impossible. Instead, it is much easier to just build a bridge over it. Many routers nowadays come with a feature called Dual-WAN Functionality. With Dual-WAN, you can connect two modems to the same router. In a Dual-WAN setup, you can choose between two options:

1. When the primary connection is online, 100% of the traffic and bandwidth will flow through it. When it goes down, the router will automatically switch to the secondary or backup connection until it can re-establish the primary connection.
2. Split the bandwidth so that the two modems share the load. This is called load-sharing.

Option #1 is exactly what I need to “bridge the gap”. It keeps my Skype/FaceTime calls connected and solves the issue of triggering the modem reboot script. Even better, I had an ace up my sleeve that was the perfect piece to complete the puzzle.

Earlier this fall, I switched my cell phone carrier, and opened two new lines (a work line and a personal line). When I signed up, the new carrier had a promotion where they would give me third line for free as long as I kept the other two lines in good standing. That free line is now a cellular backup for my primary satellite internet connection. It uses USB tethering to connect to my router. The cellular line comes with 3 GB of 4G tethering per month, followed by unlimited 3G if you use it all up. I can pay for additional 4G data if for some reason I need it. That’s more than enough to keep me going through the brief satellite outages.

Updating the Script for the Dual-WAN Setup

So how do we update the modem reboot script for the dual-WAN setup? When do we trigger the script to run? It’s pretty easy: instead of pinging an external server to test the internet connection, ping the modem of the primary connection on the local network. In my case, that would be the satellite modem. When the router flips over to the cellular backup, you will not receive a response if you try to ping the primary modem. Then I simply run the modem reboot script at the top of every hour. The router does all the work figuring out when the primary internet connection goes down. If the system is on the cellular backup, the satellite modem automatically reboots.

For those of you that are curious, this is what the final version of the smart home automation script logic looks like. Happy coding.

# First, we will have the system ping the primary/satellite modem,
# since you will not receive a response when you are on the
# cellular backup connection.
ipAddressToPing = "192.168.XXX.XXX"  <-- IP Address of satellite modem

# Then, define the number of seconds you wish to wait between pings.
secondsBetweenPings = 15

# Define the number of pings you want to perform
numberOfPings = 4

FOR i = 1 TO numberOfPings
   Ping ipAddressToPing
   IF i < numberOfPings THEN
      Wait secondsBetweenPings
   END IF
END FOR

IF All Pings Fail Or Receive No Response THEN
   Turn Modem Off
   Wait 30 Seconds
   Turn Modem On
   Note in system log that modem was restarted
END IF

The post An Ingenious Smart Home Office Automation Hack appeared first on Matthew Gove Blog.

Over the summer, I noticed something odd after a monsoon thunderstorm had gone through. The outdoor relative humidity on my weather station read about 20% higher than the outdoor humidity on my thermostat. I wrote it off as an isolated incident related to the monsoon storm and didn’t think much of it.

As the summer progressed, I noticed the same thing would happen whenever a monsoon thunderstorm would pass over us. The weather station would report the relative humidity about 20% higher than it actually was. By the end of the summer, it was reading 20% high all the time, even in sunny weather.

A Possible Hack that Would End in Disaster

On several occasions, the idea popped into my head to just go into the weather station’s Python code and subtract 20% off of the relative humidity values the sensor was reading. Trust me, it was very tempting. I had to keep telling myself that doing so would open up a whole new set of problems.

What happens if the sensor starts working properly and gives a reading below 20%. I wrote the Python code. I know that negative relative humidity values will crash the system. When you calculate the dewpoint, you would have to take the natural log of a negative number, which is undefined.

It turned out that my instinct to not tinker with the source code was correct. Over the course of the fall, that 20% gap between the sensor’s readings and the actual humidity grew to 30%, then 40% and 50%. By early November, the weather station would be reporting 80-90% relative humidity when actual humidity values were in the 10-15% range. That would have made a big, ugly mess of the source code, and would not get me any closer to fixing the problem.

The Sensor Finally Kicks the Bucket

By the 1st of December, the sensor would only give humidity readings of 100%, regardless of what the actual humidity was. Pulling the raw sensor data from the main database on the Raspberry Pi confirmed this. While I pondered my next move, I changed the weather station’s Python code. It would now get relative humidity data from the National Weather Service instead of the sensor.

A Deeper Analysis of the Raspberry Pi Humidity Sensor Data

Looking at the above table piqued my interest enough to dump all of the relative humidity data out of the database that contains all of the sensor data and take a look at it. The sensor went into service in early May and takes readings once per minute, so the query returned about 300,000 data points. After crashing Microsoft Excel’s plotting tool several times (I have an old, cranky PC), I adjusted the query to only return the relative humidity values at the top of every hour.

Now, before I show you the marked up plot explaining everything, consider the following. Think of how it can help show when the humidity sensor went off the rails.

• The summer monsoon this year was almost non-existent, with only a small handful of storms the entire monsoon season
• Relative humidities on non-rainy summer days generally range from a minimum of 10-20% to a maximum of 35-45%.
• The fall was very dry as well, until a series of winter storms started impacting the desert southwest on Thanksgiving Day (November 28th).
• I also queried the weather station’s main database for days where measurable precipitation (1 mm or more) fell. This is the result:
  

When you put everything together, it should become clear where the sensor goes awry.

How Do We Fix the Sensor?

Unfortunately, the only remedy at this point is to replace the sensor, preferably one of much higher quality. The old sensor that broke was a cheap analog one I paid about $5 for. You get what you pay for, right? Thankfully, the pressure sensor, which is a digital I2C sensor, also measures temperature. With some minor rewiring, I can simply swap them out.

The nice thing about I2C sensors is that you can connect multiple sensors to the system using only one data cable, so adding additional sensors is easy at either end of the wire. I can add them either in the solar radiation shield or in the waterproof housing that houses the Raspberry Pi and the power supply. Additional sensors will get connected where the four gray wire nuts are in the above picture. I will definitely be adding an I2C humidity sensor to the Raspberry Pi and likely more as well. Stay tuned.

The post Troubleshooting a Raspberry Pi Sensor Gone Awry appeared first on Matthew Gove Blog.

I originally looked at using smart valves to control the water flow. As you can probably guess, they are not very cost effective. Smart valves run $250 to $300 a pop, and I need at least 2 of them for the system. It quickly becomes cost-prohibitive.

Thankfully, there was an obvious and much cheaper solution that I frequently use in smart-home technology. Instead of buying a smart device, which in this case would be the smart valve, buy a dumb device and connect it to a smart switch. All of a sudden, that $300 price drops to about $50. You can put a lot of “dumb + smart switch” devices for the cost of 1 smart device.

For the “dumb” valve, I used a solenoid valve that is used in irrigation systems. They are readily available at Lowe’s and Home Depot for about $15. Instead of using an irrigation timer, I will connect it to the smart switch. I put a Y-connecter on the spigot so I can still connect a garden hose without having to disconnect the woodpecker system. I included a ball valve on the bottom of the system if I ever need to drain the pipes on cold nights.

The setup up top is dirt simple. I attached the PVC pipe to the bottom of the eaves with pipe clamps. I then drilled three 1/16 inch holes in the side of the pipe to be the sprayer nozzles. The actual system will have many more holes. Depending on the connection, the pieces of PVC pipe are either screwed or glued together. I tried to use screw connections whenever I could. If I ever needed to take the system down, replace a part, or make an upgrade, then I could.

Now, it’s time for the moment of truth: turning it on to see if it will work. We’ll find out just how good my calculations were, seeing as stupid arithmetic errors were at one point one of my signature moves. Thankfully, using a script eliminates most of those.

It turned on, the water sprayed forcefully, and the system didn’t blow itself to pieces! Win, win, and win.

A Few Observations of the Anti-Woodpecker Sprayer Prototype

One thing I noticed right away on the first test was that the valve had a hard time turning off. It eventually did, but it took way longer than it should have. This was due to the system having too much water pressure – mainly due to the fact that there was only 10 feet of pipe on the prototype. I was a bit concerned because I didn’t want to get in a scenario where the system activated while I was not at home and then couldn’t shut itself off.

After backing off the pressure by slightly closing the spigot, the system worked much better. The valve had no issues turning off, and the anti-woodpecker sprayers were actually more powerful with less water pressure. Remember in the calculations, if we over-pressurize the system, we lose all of that extra energy and more due to friction. I’ll be the first to admit I’m a bit of a nerd when it comes to things like this. As cool as it is to see in the mathematics and equations, it’s even more fascinating to actually see it in a real-life application.

Where Do We Go From Here

The next step will be to expand the system so it protects the entire house. The big challenge will be to get the motion sensors to work properly. Motion sensors are designed to have a very wide field of vision because they’re primarily used for security purposes, but I need them to have a narrow field of vision. I don’t want the system to activate every time someone walks by or every time I step outside. I’ve got a few ideas right now, but they need some more thought before I can elaborate on them here.

An Added Bonus

Ever since I bought the house, I have wanted to put misters on my patio to make sitting out there in the hotter months more comfortable. The anti-woodpecker spray system will act as the foundation for the misters, which will make installing the misters much easier, since the plumbing will already be there.

Well, that’s it for now. Stay tuned for future updates. This battle is only beginning. Thankfully, mother nature has given me a big assist over the past few weeks with cold, rainy weather, which has kept the woodpeckers at bay. I fully expect them to be back out in full force later this winter and into the spring.

The post Building the Anti-Woodpecker System Prototype appeared first on Matthew Gove Blog.

This blog post will read more like a page of notes instead of a formal “article”, but it’ll at least give you a window into my train of thought. To make these calculations much easier, everything will be converted to metric units.

My water comes from a well, so I know the exact water pressure coming out of the well. However, these calculations do not take into account any pressure losses going from the well to the house. I assume that they are minimal, and can be ignored.

General Notes and Conversions

• Well is at 50 PSI = 344.738 kPa
• Flow rate is 40-60 liters per minute
• Friction loss at 10 gallons per minute:
  • 1/2 inch pipe: 35.5 PSI per 100 ft
  • 3/4 inch pipe: 8.7 PSI per 100 ft
  • 1 inch pipe: 2.6 PSI per 100 ft
• Friction loss at 15 gallons per minute:
  • 1/2 inch pipe: Unknown – a lot
  • 3/4 inch pipe: 18.4 PSI per 100 ft
  • 1 inch pipe: 5.5 PSI per 100 ft
• Pressure loss from elevation
  • 10 feet of rise: -4.33 PSI
  • 10 feet of fall: +4.33 PSI
  • This equates to 9,794.2 Pa per meter

Calculating Pressure Loss Due to a Leak

Since the spray mechanism will just be holes drilled in the side of the pipe, we can calculate the pressure loss due to these “leaks” to ensure the system has enough water pressure to protect the house. Because I had to run these calculations a bunch of times, I wrote a Python script that can run these calculations for different scenarios very quickly.

One fascinating thing about these calculations is that water flowing through a pipe behaves just like an electrical circuit. When there is a hole in the pipe, the leakage reduces the total resistance to the flow, thus causing an increase in flow rate. Increased flow rate means that a larger proportion of ∆p occurs upstream of the leak, thus resulting in less pressure drop across reduced resistance downstream of the leak.

1. From the pipe diameter, calculate the pipe’s cross-sectional area (A_pipe).
2. Then calculate the area of the hole (A_hole).
3. Calculate the fluid velocity (v_pipe) through the pipe.
   
   where Q_pipe is the flow rate (listed above as 40-60 liters per minute). Note that this will need to be converted to cubic meters per second (cms)
4. The volume flow out the leak hole is then simple:
   
5. Then we can calculate the pressure drop from the leak rate equation, which is derived from Bernoulli’s equations.
   
   Note: C is a flow coefficient and for water, C = 0.61.
6. We can use this pressure drop, along with the initial pressure coming out of the spigot, to calculate the maximum number of holes we can add in the sprayer system before running out of pressure. In Python, these steps look like this:
   
   

Accounting for Elbow Fittings and Tees

We can account for pressure losses going around corners (i.e. though fittings) by assigning an equivalent length of pipe for each fitting and calculating the pressure loss due to friction over that length. The equivalent length is a factor calculated from the number of pipe diameters required to get the equivalent length. We are working with several different fittings:

For example, in 3/4-inch pipe, the equivalent length of a 90° elbow would be:

l = 0.75 inches * 30 = 22.5 inches

Then you would simply multiple the pressure loss due to friction by that equivalent length to obtain the pressure loss due to the elbow fitting.

Note: The 22.5 inches would also need to be converted to meters for our calculations.

Putting It All Together

To calculate the (approximate) maximum number of holes the system can support, we calculate the pressure at the end of the pipe system assuming that there are no holes or leaks and divide that number by the pressure loss per hole. The Python code to calculate this for all scenarios is:

leak_diameter_meters = LEAK_HOLE_DIAMETER * INCH2METER
pipe_diameter_meters = PIPE_DIAMETER * INCH2METER
pipe_flow_rate = SPIGOT_FLOW_RATE * LITRES_PER_MIN_TO_CMS
friction_loss_metric = FRICTION_LOSS * FRICTION_LOSS_CONVERSION_FACTOR
hole_pressure_loss = pressure_loss_from_hole(pipe_diameter_meters, leak_diameter_meters, pipe_flow_rate)

pressure_loss_from_turning_spigot_up = friction_loss_metric * (ELBOW_45DEG + 0.1 + ELBOW_90DEG)
spigot_pressure_pa = SPIGOT_PRESSURE * PSI2PASCAL
print("Starting Pressure: {:,} kPa".format(round(spigot_pressure_pa/1000, 1)))

KEY_ELEV = "elevation"
KEY_DIST = "distance"
KEY_FITT = "fittings"

scenarios = {
	"master bedroom only": {
		KEY_ELEV: [2.1],
		KEY_DIST: [2.1, 6.75],
		KEY_FITT: [ELBOW_90DEG],
	},
	"master bedroom plus north side": {
		KEY_ELEV: [5],
		KEY_DIST: [2.1, 6.75, 6.42, 6.42],
		KEY_FITT: [TEE, ELBOW_90DEG * 2],
	},
	"master bedroom plus patio": {
		KEY_ELEV: [2.1],
		KEY_DIST: [2.1, 9.1, 3.03, 9.1, 3.03],
		KEY_FITT: [TEE, ELBOW_90DEG * 7],
	},
	"master bedroom plus north side and patio": {
		KEY_ELEV: [5],
		KEY_DIST: [2.1, 9.1, 3.03, 9.1, 3.03, 6.42, 6.42],
		KEY_FITT: [TEE, ELBOW_90DEG * 9],
	},
	"office guest room and south side": {
		KEY_ELEV: [5],
		KEY_DIST: [3.35, 0.8, 0.45, 2.58, 2.58, 6.42, 6.42],
		KEY_FITT: [TEE, ELBOW_90DEG * 5],
	},
	"office guest room only": {
		KEY_ELEV: [4.15],
		KEY_DIST: [3.35, 0.8, 0.45, 2.58, 2.58],
		KEY_FITT: [ELBOW_90DEG * 4],
	},
	"north side on garage spigot": {
		KEY_ELEV: [5],
		KEY_DIST: [3.5, 6.42, 6.42],
		KEY_FITT: [ELBOW_90DEG * 2],
	},
}

for scenario in scenarios.keys():
	elevation = scenarios[scenario][KEY_ELEV]
	distance = scenarios[scenario][KEY_DIST]
	fittings = scenarios[scenario][KEY_FITT]

	# Calculate pressure at the end of the pipe, assuming no holes/leaks
	end_pressure = spigot_pressure_pa - pressure_loss_from_turning_spigot_up - (PRESSURE_LOSS_FROM_ELEVATION * sum(elevation)) - (friction_loss_metric * sum(distance)) - (friction_loss_metric * sum(fittings))
	
	print("The pressure at the end of the {} system is {:,} kPa".format(scenario, round(end_pressure/1000, 1)))
	
	print("\tThe pressure loss in the system (sans holes) is {:,} kPa".format(round((spigot_pressure_pa - end_pressure)/1000, 1)))

	# Divide the pressure at the end of the pipe by the pressure loss from
	# one hole to determine the total number of holes the system can support
	num_holes = math.floor(end_pressure / hole_pressure_loss)
	
	print("\tThis supports up to {:,} holes ({:,} holes/meter), each with a pressure drop of {} Pa".format(num_holes, math.floor(num_holes/sum(distance)), hole_pressure_loss))

print("\n")

Script Results

Calculating pressure loss using 3/4 inch pipe and 1/16 inch “sprayer” holes, we get the following results. These calculations account for:

• Elevation changes in the system/pressure loss due to gravity
  • Remember that for vertical hlow, we need to account for both pressure loss due to gravity and pressure loss due to friction
• The pipes going around corners (elbow and tee fittings)
• Pressure loss due to friction inside the pipe
• Fittings needed to do a 180° turn out of the spigot to get the water up to the eaves
• The script does not account for the negligible pressure loss due to straight fittings where two straight pieces are joined and do not go around any corners.

Matt:Desktop mattgove$ python3 pressure.py
Hole Diameter: 0.0625 inches
Pipe Diameter: 0.75 inches
Spigot Pressure: 50 PSI
Spigot Flow Rate: 60 Liters per Minute
Friction Loss: 18.4 PSI per 100 feet
--------------------------------
Starting Pressure: 344.7 kPa
The pressure at the end of the master bedroom only system is 281.2 kPa
	The pressure loss in the system (sans holes) is 63.5 kPa
	This supports up to 16,541 holes (1,869 holes/meter), each with a pressure drop of 17 Pa
The pressure at the end of the master bedroom plus north side system is 192.6 kPa
	The pressure loss in the system (sans holes) is 152.1 kPa
	This supports up to 11,332 holes (522 holes/meter), each with a pressure drop of 17 Pa
The pressure at the end of the master bedroom plus patio system is 189.9 kPa
	The pressure loss in the system (sans holes) is 154.8 kPa
	This supports up to 11,173 holes (423 holes/meter), each with a pressure drop of 17 Pa
The pressure at the end of the master bedroom plus north side and patio system is 103.8 kPa
	The pressure loss in the system (sans holes) is 241.0 kPa
	This supports up to 6,102 holes (155 holes/meter), each with a pressure drop of 17 Pa
The pressure at the end of the office guest room and south side system is 181.8 kPa
	The pressure loss in the system (sans holes) is 162.9 kPa
	This supports up to 10,694 holes (473 holes/meter), each with a pressure drop of 17 Pa
The pressure at the end of the office guest room only system is 250.3 kPa
	The pressure loss in the system (sans holes) is 94.5 kPa
	This supports up to 14,721 holes (1,508 holes/meter), each with a pressure drop of 17 Pa
The pressure at the end of the north side on garage spigot system is 219.5 kPa
	The pressure loss in the system (sans holes) is 125.3 kPa
This supports up to 12,910 holes (790 holes/meter), each with a pressure drop of 17 Pa

If we run this again for a “worst-case” scenario, let’s say 40 PSI and 30 liters per minute, the numbers are actually better. The reason is that the slower flow rate reduces the pressure loss due to friction (labelled as “Friction Loss” in the script output). Note how the pressure drop in the lower pressure/flow system below is only 5 Pa per hole, while in the high pressure/flow system above, pressure loss is 17 Pa per hole.

Matt:Desktop mattgove$ python3 pressure.py
Hole Diameter: 0.0625 inches
Pipe Diameter: 0.75 inches
Spigot Pressure: 40 PSI
Spigot Flow Rate: 30 Liters per Minute
Friction Loss: 8.7 PSI per 100 feet
--------------------------------
Starting Pressure: 275.8 kPa
The pressure at the end of the master bedroom only system is 234.9 kPa
	The pressure loss in the system (sans holes) is 40.9 kPa
	This supports up to 46,980 holes (5,308 holes/meter), each with a pressure drop of 5 Pa
The pressure at the end of the master bedroom plus north side system is 178.1 kPa
	The pressure loss in the system (sans holes) is 97.7 kPa
	This supports up to 35,611 holes (1,641 holes/meter), each with a pressure drop of 5 Pa
The pressure at the end of the master bedroom plus patio system is 191.8 kPa
	The pressure loss in the system (sans holes) is 84.0 kPa
	This supports up to 38,351 holes (1,454 holes/meter), each with a pressure drop of 5 Pa
The pressure at the end of the master bedroom plus north side and patio system is 136.0 kPa
	The pressure loss in the system (sans holes) is 139.8 kPa
	This supports up to 27,205 holes (694 holes/meter), each with a pressure drop of 5 Pa
The pressure at the end of the office guest room and south side system is 172.9 kPa
	The pressure loss in the system (sans holes) is 102.9 kPa
	This supports up to 34,586 holes (1,530 holes/meter), each with a pressure drop of 5 Pa
The pressure at the end of the office guest room only system is 209.7 kPa
	The pressure loss in the system (sans holes) is 66.1 kPa
	This supports up to 41,939 holes (4,297 holes/meter), each with a pressure drop of 5 Pa
The pressure at the end of the north side on garage spigot system is 190.7 kPa
	The pressure loss in the system (sans holes) is 85.0 kPa
	This supports up to 38,149 holes (2,334 holes/meter), each with a pressure drop of 5 Pa

Another Fun Fact

Thanks to Bernoulli’s Principle, as long as the “sprayer” holes are much smaller than the pipe diameter, each system will support the same maximum number of holes regardless of the hole diameter because the same volume of water exits each hole. Water will exit smaller holes with a higher velocity than bigger holes. Because of this, we want to make the smallest holes possible in the pipes.

Next Steps

Thankfully, these calculations of pressure loss confirm that there is enough pressure in the system to protect the entire house. In the next installment of this project, we will look at the parts needed to set up the system and we will actually start building a prototype.

The post Mathematics of the Woodpecker Deterrent System appeared first on Matthew Gove Blog.

In Arizona, animals that are classified as pests, such as the ground squirrels, can be legally controlled if they are causing damage to your property, as long as you do so in a humane manner. I want to emphasize that if a pest is not causing any damage, I either leave it alone or shoo it away using non-harmful scare tactics. The second the pest starts causing damage, though, all bets are off. I will use any and all legal means at my disposal to protect my property.

I live in a rural area outside of city limits, so my trusty air rifle is my go-to method of ground squirrel control. In instances where discharging the air rifle is either unsafe or impractical, I use rat traps. Last summer, a large family of ground squirrels burrowed underneath my air conditioner. The rat traps worked wonders.

A Problem with Woodpecker Control

Unlike pests such as ground squirrels, woodpeckers are highly protected under federal law. Controlling them by lethal means is out of the question. If you’re caught killing a woodpecker, you will face up to a $100,000 fine and will be thrown in jail. Don’t even think about doing it. To add insult to injury, woodpeckers are fiercely territorial. Once they set up shop, it is next to impossible to get them to leave.

With the more “traditional” means of pest control not being an option, my best option was behavioral control through scare tactics. In other words, you want to scare them away before they cause any damage. I started by hanging the bird flash tape. As expected, the woodpeckers just went and pecked where there was no bird tape. Covering the entire house with bird tape is not exactly practical, so it was on to Plan B. I got a couple of those plastic owls to scare them away.

I did not realize that woodpeckers are as smart as they are. If you don’t move the owls every day or two, the woodpeckers will figure out that the owls are fake. The day I went outside to find a woodpecker pecking on one of my fake owls was when I knew this battle was escalating beyond traditional means. It was time to think outside of the box.

The Next Bad Idea for Keeping Woodpeckers Away from the House

My next thought was to use noise to scare them away. Woodpeckers drum on things and make loud noises to establish their territory and attract mates. The loudest bird gets the territory/mate. Hopefully all I have to do is to make a louder noise than them and they’ll leave. If you’re not rolling your eyes at that statement, you should be. Enter the air horn.

Now, picture this. To effectively use the air horn, I had to creep around the sides of the house, just like they do in those shooter movies, blindly reach around the corner of the house and sound the air horn. Once the woodpeckers took off, I would sprint after them blowing the horn at them until they left the property. If you’re thinking I look like a fool here, well, you’d be right. Unfortunately, the woodpeckers quickly realized the horn was harmless. To add insult to injury, they had already damaged the house before I could shoo them away.

Back to the Drawing Board

I knew now that I had to reach deep into my bag of tricks and go beyond “outside-the-box” thinking. It was time to go MacGyver on them, so I sat down and made a list of requirements for a system to keep woodpeckers off the house.

1. Much faster response time in order to shoo them away before they damage the house. The deterrent system must activate pretty much instantly once they land on the house.
2. The woodpeckers must know there is actually a credible threat behind the scare tactics without harming the birds. They’ve figured out that everything I’ve done so far is just a hollow threat and there are no consequences for them.
3. The system must be able to protect the entire house.
4. I must be able to manually activate the deterrent system from inside the house, without having to open any windows or doors.

Enter a Crazy, but Ingenious Idea

Once that list was done, it was time to see if my various prongs of knowledge, experience, and logic could all come together to meet the requirements of the system. Once I started brainstorming, it took a bit of a superfluous route, but here’s where it eventually landed:

• If you’ve ever trained a pet before, you know that spraying them with water works very well to tell them when they do something wrong. This trick works especially well with cats. Birds generally don’t like to be wet because it can adversely affect their ability to fly. Spraying the woodpeckers with water would check off number 2 (the credible threat requirement) on the list above.
• Remember all of the years I spent studying meteorology and physics. I can use my knowledge of fluid dynamics to run the calculations to ensure that a spray system will both a) actually work, and b) protect the entire house.
• I installed a smart home system in my house last spring. The smart home system will allow me to use smart switches and/or valves to both automatically and manually activate the system from anywhere. A motion sensor under the eaves hopefully can detect when woodpeckers land there. They will instantly send a signal to the smart home controller to activate the anti-woodpecker spray system, eliminating the gap in response time.

Now that I have an idea to work with, it’s time to jump into the mathematics and fluid dynamics to ensure this will actually work before I start running out to buy parts for it. Stay tuned.

The post Keep Woodpeckers Off Your House with this Crazy, but Proven Solution appeared first on Matthew Gove Blog.

Anyway, I can’t believe fall is already here in Phoenix. It’s time to start thinking about putting my garden back into winter mode. Here in the low deserts of Arizona, growing season is backwards from what you would expect. It starts in late August/early September and runs through the end of May. I’ve got some ambitious goals for this winter, but they will build a great foundation for future gardening here in Arizona.

My Foray into Winter Greenhouse Gardening in Arizona

For those of you that don’t know, about 2 years ago, I built a plant cage to house my potted plants (herbs and veggies) to keep the ground squirrels and other varmint out of my plants. Right before I built the plant cage, the ground squirrels ate my entire garden down to stumps. As you can probably guess, I was not happy, and the wars with the ground squirrels officially began.

In the winter, I put plastic on the plant cage, effectively turning it into a greenhouse. The greenhouse allows my cold-sensitive plants to winter over outside. Even here in the Phoenix area, winter nights are too cold for my peppers, tomatoes, and basil without some kind of protection.

Last winter was my first venture into greenhouse gardening in Arizona. I built a heating system to protect the plants from the cold. It worked (we had nights down to 22°F), but it was both a lot of effort and expensive to maintain it throughout the winter, even in Phoenix. I need to make some changes this year. Which is a perfect segue into this year’s gardening goals and ambitions.

Goal #1: Greenhouse Must Be Easier to Maintain and More Cost-Effective

To upgrade the greenhouse for last winter, I plan to implement the following changes and upgrades:

• Integrate smart home technology/automation into the heating system to give me much finer control and monitoring of the climate control.
• To decrease costs, reduce the night time temperature/heat setting inside the greenhouse from 67°F to 55°F.
• Add insulation (clear bubble-wrap) to the sides and top of the greenhouse.
  • The cost of adding the insulation should more than pay for itself over the course of the winter.
  • I shouldn’t need to cover the greenhouse unless nighttime temperatures drop below 45°F.
• With the added insulation, I should be able to cover the greenhouse with frost cloths, which are much easier to put on and take off, and still maintain 55°F inside.
  • I only want to have to use the big tarp if temperatures drop below freezing, it rains, or you have high winds combined with chilly temperatures.

Update December, 2019: These upgrades have worked flawlessly so far. During a couple cold nights in October, the frost cloths and the heater were able to hold 57°F without any plastic or insulation on the plant cage with outside temperatures down to 35°F. I have only had to use the big tarp two nights, when we had wind gusts to 80 km/h (50 mph). I bought a smaller light-duty tarp to use when it rains. It’s essentially used like a rain fly on a tent. The smaller tarp is much nicer to use than the big heavy-duty tarp, which covers the entire greenhouse.

Goal #2: Add an Indoor Herb Garden

The motivation for adding an indoor herb garden stems from all of the times I wanted a stalk of basil, a sprig of cilantro, or a couple of cherry tomatoes while I cooked dinner, and the greenhouse had already been put to bed for the night (you can’t get into it once it’s put to bed for the night).

I have huge south and east-facing windows in my kitchen, so it was a no-brainer where to put the indoor herb garden. The space around the window is essentially just dead space right now. An indoor garden will be a nice addition.

The challenge of the indoor garden was finding a table that the potted plants could sit on. A standard table was way too wide and not tall enough. I started looking at console tables, which are long, skinny tables that often go right behind sofas. Again, I couldn’t find one that was the right length or height, so I finally decided to just build one myself. I am so glad I did. It was a really fun project to work on over the long Columbus Day Weekend and it fits in just perfectly in my kitchen.

I have currently have cilantro, scallions, peppermint, oregano, rosemary, and four different types of basil (Italian, Thai, Mexican, and Sweet) in my indoor garden.

Goal #3: Paint the Plant Cage

When I built the plant cage two years ago, I didn’t have much money to spare. The company I was working for at the time had just gone under. I knew the elements would destroy the bare wood, so I painted it the (cheapest and) most redneck color I could find: primer.

While the primer worked fine, I have always wanted to paint it with a nice southwestern color scheme. The plant cage gets moved between its summer and winter homes twice per year. That’s the perfect oppotunity to catch up on maintenance, including painting. I wanted to paint it last spring, but ground squirrel activity peaks that time of year. There has been basically no ground squirrel activity this fall, so this is the perfect time to paint it. I found some nice southwestern colors at Sherwin Williams and will be painting it this weekend.

Update October, 2019:

Goal #4: Plant Winter Veggies

I learned the hard way last year that winter veggies will fail miserably if you plant them too late. I planted them in mid-December, and the only successful veggie I grew was lettuce. This year, I planted my winter veggies in late September: spinach, lettuce, cilantro, and broccoli.

Update December, 2019: The lettuce, spinach, and cilantro are overflowing the outdoor whiskey barrel planter. The broccoli has not set heads yet, but they’re growing like crazy.

Goal #5: Begin Designing Raised Beds for the Yard

While the 8-foot by 4-foot plant cage is all well and good, I have an acre of land here and it’s time to put it to work. Since not much grows in the desert soil, raised beds are the best option for both summer and winter gardening in Arizona. Unfortunately, we still have the ground squirrel/pest issue we need to deal with, so the raised beds need to be ground squirrel-proof.

Ground squirrels are cunning, very smart, and absolutely relentless. They will not stop until they get what they want. They will try to go over, under, and through any obstacle to get it. Most of the raised bed design is to squirrel-proof it, but the good news is that squirrel-proofing the raised beds will also keep the rabbits, mice, and other pests out. While I am far from finalizing a design, this is what I’m leaning towards/thinking about doing right now:

• Put some kind of large gravel or crushed concrete blocks to prevent the squirrels from digging underneath.
• Extend the frame at least 6-12 inches underground to prevent digging underneath
• Put sides with hardware cloth at least 1 foot high so pests can’t just jump into the raised bed. I’m still working on determining how cost effective this will be
• Put electric fencing wire around the top so anything that tries to climb over will get zapped. Assuming that this actually works, the electric fence will be solar powered so that I don’t need to run power out to the garden.

I’m hoping to build a prototype of the raised bed this winter/spring, but I’m not sure whether that will actually happen or not.

Winter gardening in Arizona is a unique experience with its own set of challenges. When done correctly, it’s incredibly rewarding. It can provide you with a lush, flourishing garden you’d never think would be possible in the desert.

The post Time to Think About Winter Gardening Here in Arizona appeared first on Matthew Gove Blog.

A Word on Solar Radiation Shields

The purpose of a solar radiation shield is simple. Block solar radiation from reaching temperature sensors so you can get accurate readings even if you do not have a location in the shade to mount your sensor.

The goal of solar radiation shields is to ensure temperature readings that are within the accuracy for your sensor’s calibration. They block the solar radiation and allow for ample air flow across the sensor.

Experiment Design

To truly test which solar radiation shield worked best, I wanted to expose them to the most extreme environment possible. Thankfully summers here in Phoenix are more than happy to oblige. As an added bonus, they get exposed to direct sunlight in the early mornings and late afternoons for about 6 to 8 weeks on each side of the summer solstice.

Running the experiment in early June would satisfy both requirements: extreme heat/dry and exposure to direct sunlight. June is typically the hottest and driest month in Phoenix. Afternoon highs pretty routinely hit 110°F (about 45°C). Relative humidity typically bottoms out between 5% and 15%.

I took hourly observations from the temperature sensors in both the bowls and the plates and compared them to the observations at Phoenix Sky Harbor International Airport. Sky Harbor is the official National Weather Service observation station for the Phoenix area. I also compare them to the observations at Luke Air Force Base in Glendale, which is closer to my house. The observations were taken Monday through Thursday for three weeks.

Hypothesis

I went back and forth for a long time on which one I thought would perform better. The key to obtaining accurate temperature readings from inside a solar radiation shield is proper airflow across the sensor. Because of that, my gut was telling me that the shape of the plates would allow for slightly better airflow across the sensor. I opted to stick with my gut feeling for my official hypothesis and go with the plates.

Results

Before diving into the results, there are a few things we need to take into consideration:

• The greater Phoenix area is one of the largest urban heat islands in the world. You must account for the heat island when comparing the National Weather Service observations. The Weather Service takes observations inside the city, while my house is outside the city.
• The sensor inside the plates was not connected to a data logger. It is missing data points for where I was sleeping, cooking, not paying attention, etc.

Week 1: May 20 – 23, 2019

Despite my best efforts to run the experiment in as extreme an environment as I could get, the week of May 20th was unseasonably cool across the desert southwest. Normal highs in Phoenix this time of year are right around 40°C/100°F. As you can see from the plots, we didn’t get anywhere close to that benchmark. However, it did provide a nice contrast to the observations I took once the weather heated back up.

This dataset gave me pretty much what I was expecting:

• Both day and night observed temperatures were slightly warmer in the city than at my house.
• Instances of the homemade solar radiation shields having insufficient airflow or being in direct sunlight did not result in any major temperature anomalies.
• The plates performed slightly better during the heating of the day. They both stayed slightly below the city observations and were closer to the National Weather Service observations.
• There was no noticeable difference in the performance of the bowls and the plates at night.

Week 2: May 27 – 30, 2019

The Phoenix weather finally started warming up this week, giving some interesting results as the extreme environment returned. The beginning of the week started cool, but became hot by the time Wednesday and Thursday rolled around.

Right away, a few things really jumped out at me from this plot

• The effect of the solar radiation shields being in the sun, especially in the late afternoon (about 3 to 6 PM), is very noticeable, especially in the hotter temperatures.
  • Remember the plates and bowls (yellow and blue lines, respectively) should be just below the Sky Harbor (green) and Luke AFB (red) observations due to effects of the urban heat island.
• When the bowls/plates are in direct sunlight in the morning, they go into the shade at about 9:00 AM. Notice how the observed temperature on the blue and yellow lines temporarily drops right around 9 AM each day. Both solar radiation shields definitely feel the effect of being in direct sunlight.
• Interestingly, the difference between the bowls/plates observations and the National Weather Service observations remained pretty constant as high temperatures increased.
• Once again, the plates performed slightly better, as they were closer to the official National Weather Service observations.
  • Bowls are mounted west of the plates and are in direct sunlight for slightly longer in the afternoon. However, that difference is only just a few minutes, so its effect should be minimal.
• The sensors performed as expected at night, with temperatures at my house reading slightly below the city observations.

I expect that the final week of the experiment to be the hottest of the three. It will be interesting to see if those results corroborate what we’ve seen so far.

Week 3: June 3 – 6, 2019

The final week of the experiment was by far the hottest, with afternoon temperatures finally exceeding 40°C or about 105°F. Keep Week 2’s results in mind as we look at the results of Week 3.

The patterns from Week 2 are also evident in Week 3.

• The effects of both solar radiation shields being in direct sunlight are clearly evident on all four days.
• The observed temperatures were as expected at night, with temperatures at my house being slightly lower than the city observations.
• The temporary drop in observed temperatures in the bowls and plates occurred at about 9 AM each morning when the solar radiation shields went into the shade.
• The difference between the bowls/plates and the National Weather Service observations do vary a bit more than in Week 2. This is most likely due to higher wind velocities.
• Again, the plates seemed to perform slightly better than the bowls during the day.

The Verdict

This was a fun and interesting experiment with a few curveballs. I was able to draw the following conclusions and propose solutions to problems that I discovered during the experiment.

• The plates performed slightly better than the bowls in both cooler and hotter weather.
• Both types of dinnerware were affected by being in direct sunlight in the early morning and late afternoon.
  • Thankfully the solar radiation shields are completely out of direct sunlight for close to 10 months out of the year.
• Adding fans to the solar radiation shields to ensure an ample and consistent airflow across the sensor will noticeably reduce the effects of being in direct sunlight. It likely will not eliminate them completely.
• The sensors all performed as expected at night.
• Wind velocities should be recorded as well.
• All sensors should be connected to dataloggers so I can collect data 24 hours a day.

In the future, I would like to run the experiment again in both winter and summer settings. The results of those experiments combined with the results of this experiment would then give us a definitive answer as to whether bowls or plates make the best DIY solar radiation shields.

The post DIY Solar Radiation Shield: Results of the Bowls vs Plates Experiment appeared first on Matthew Gove Blog.