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.

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.

• A database to store the data
• A script that takes sensor readings, QA/QC’s those readings, and logs them in the database.

From Sensor To Database

The flow of data from the sensors to the weather station’s primary database, is as follows. The primary database contains the full set of weather data. It logs data every 5 minutes. The weather station’s web interface displays those data. Data for which I do not have sensors are obtained from the National Weather Service.

1. A Python script reads data from the sensors and logs them in the data logger every minute
2. The Python script QA/QC’s the raw data read from the sensor.
3. The script puts salid or “good” data points into the database, in default metric units. It flags invalid or “bad” data points and puts them into a separate table so the primary database cannot get any “bad” data.
4. Every 5 minutes, a Python script associated with the primary database queries the database containing the sensor data. It takes the most recent set of “good” data points that fall within that 5 minute period and inserts that data into the primary database, along with the data it obtains from the National Weather Service. If no “good” data points fall within that 5 minute period or if the sensor or the data logger are offline, it obtains the data from the National Weather Service.
5. Once per day, data measured by the sensors are synced with the primary database to ensure that the primary database has the correct sensor data in the event of a network outage.

Database Design

I could easily write an entire post about database design, so I’m not going to go into too much detail of why I made the decisions to design the database the way I did. Instead, here is my list of requirements for the database:

• Uses all the standard practices of relational databases
  • Only store raw, non-calculable data from the sensors.
    • Data that can be calculated from the sensor output do not need to be in the database.
    • This database is separate from the primary database for the DIY weather station, which I described above
  • Properly normalized to third normal form
  • Easily scalable up and down
• Store information about the sensors (manufacturer, model, serial number, etc)
• Have a mechanism to handle bad data points flagged by a QA/QC system
• Be easily queryable to pull data into the primary database for the DIY weather station (more on this later in this post)

From that list of requirements, this is the EER diagram I came up with for the sensor database.

Note here that the “good” data are put into the “measurement” table, while the “bad” data flagged by the QA/QC mechanism are put into the “measurement_to_qaqc” table.

The Python Script

The Python script is where all the magic happens. Its main purpose is to QA/QC the data it reads from the sensors, essentially acting as a guard so bad data points do not get into the weather station’s primary database.

The first iteration of the QA/QC algorithm is quite simple, and is to a degree, a bit crude. Essentially all it does is to just ensure that the data are within acceptable ranges. For example, the script flags and removes relative humidity readings of 3,285%, as well as the temperature readings of -145°C.

I haven’t begun coding a version 2 of the QA/QC algorithm, but it will look at trends in the data and eliminate unrealistic spikes. For example, if the sensors show that the temperature rose 20°C over the course of a couple minutes, that would be flagged and removed by the QA/QC algorithm. In the current first version, you could in theory have temperature readings of 10°C and 30°C within a minute of each other and the algorithm would not flag it, because both temperature values are within the acceptable or realistic temperature range.

Python Classes to Parse Sensor Readings

Within the Python code, there are classes for each type (make/model) of sensor. To instantiate an object of one of these classes, they are passed the GPIO pin in the data logger to which they are connected, as well as the Sensor ID, which is the primary key in the “sensor” table in the database described above.

The sensor classes also perform the following:

• Read the raw data from the sensors and QA/QC those readings.
• Round all data readings to a maximum of 5 decimal points, which the database requires
• Inserts the data read from the sensors into the database.
• Convert raw pressure to mean sea level pressure
• Run a test measurement. The user manually calls the test method, which takes a sensor reading and dumps the data to a Terminal window without interacting with the database.

The primary script in the data logger Python module performs the following steps to log the sensor data:

1. Instantiates an instance of the appropriate sensor class for each sensor in the weather station network
2. Loops through each sensor
3. Reads the data from the sensor
4. QA/QC’s the data from the sensor
5. Inserts the “good” data into the database

Well that just about wraps up the sensor and data logger portion of the DIY weather station project. I certainly had a blast designing and building, and I hope you enjoyed reading about it. Until next time.

The post DIY Weather Station, Part 4: Database Configuration and Programming the Sensor Readings appeared first on Matthew Gove Blog.

Supplies Needed

• Raspberry Pi, with case and power adapter
• GPIO Ribbon Cable for the Raspberry Pi, which makes it easier to connect the sensors.
• MPL3115A2 I2C Barometric Pressure, Altitude, and Temperature Sensor
• AM2302 Wired Temperature/Humidity Sensor
• 22 AWG Wire Jumpers, to connect the sensors to the Raspberry Pi
• Thermostat Wire
• Breadboard for Testing (optional)

Do a Test Run Inside First

Before installing everything at the data logger site, I always do a test run in a controlled environment indoors first. I set everything up in my home office, which allowed me to spread everything out. I could confirm that I hooked everything up correctly, and easily troubleshoot any issues. As a nice bonus, it let me work in the air conditioning instead of outside in this 100-plus degree heat.

First, get the Raspberry Pi up and running. The Pi will come with instructions for how to install the Raspbian operating system, which is a distribution of Debian Linux. After installing the operating system, simply plug in an external monitor and an ethernet cable. Then plug the Raspberry Pi in to turn it on. Once it boots up, log in and make sure you can get online and open a Terminal window.

Before connecting any sensors, shut down the Pi and unplug it. Never attempt to connect any sensors to the Pi while it is powered on! If you connect them to the wrong ports, you can damage both the sensor and the Pi by either running incorrect voltage through it or by shorting it out. After shutting down and unplugging the Raspberry Pi, connect the GPIO ribbon cable. Then get your sensors and jumper wires ready.

Each sensor will have instructions for which GPIO pin it needs to be connected to. Most sensors will connect to either 3 or 4 GPIO pins. One pin feeds the hot and neutral wires for power, and the remaining pins transfer data. For testing the sensor, connect the sensor to the GPIO pin with the jumper wires. If the sensor has wires built into it, which our temperature/humidity sensor does, you can use those.

A Few Tips for Connecting the Sensors

• Most sensors support using both 3.3 Volts and 5 Volts for power. For this test (and any other application where you are using short lengths of wire), always use 3.3 Volts. You may damage the sensor if you use 5 volts. Only use 5 volts is you have long lengths of wire. Unfortunately the definition of “long” varies depending on what type of sensor you’re using.
• Each sensor will come with instructions telling you which GPIO pin to connect it to. Please be aware that if you’re using a GPIO ribbon, those pins will be a mirror image of the GPIO pin diagram that comes with the Raspberry Pi. If you’re connecting the sensor directly to the pins on the Pi’s board (i.e. not using a GPIO ribbon), that diagram will be correct.

Once you have the sensor(s) connected, it’s time to test them, so power the Pi back on.

Test the Sensor After Connecting It

Most sensors come with scripts so you can verify that they’re working. Both sensors I’m connecting to the data logger come with Python scripts for testing, which I downloaded from GitHub. After installing any dependencies those scripts require, run the test script in a Terminal window. If the sensors are connected correctly, the sensor readings will appear in the Terminal window’s output. Make sure the sensor readings are accurate, too! If you’re in the United States, be aware that nearly all test scripts will output sensor readings in metric units by default.

Tip #1: Once you have verified the sensors are working correctly, I highly recommend taking a picture of the GPIO ribbon that shows each sensor wire connections. That way you can easily re-create the setup when you move it to the permanent data logger site.

Tip #2: Before you move the Pi to the permanent data logger site, enable SSH logins and turn off the GUI so it will be command line only. I don’t have an easy way to get a monitor to the data logger site so it is much easier to just SSH into the Pi from my laptop over my local network.

Installing the System at the Data Logger Site

Now that we’ve confirmed the sensors are working, it’s time to permanently install them at the data logger site. Make sure you shut down and power off the Pi before unplugging any sensors to move them.

A Quick Note About Thermostat Wire

I chose to use thermostat wire to connect the sensors. It is made out of a high-quality, highly conductive metal (solid copper). The conductors in thermostat wire are the perfect size for connecting to the sensors and the Raspberry Pi. It comes in many different configurations (number of conductors). It’s also cost-effective and won’t break the bank.

For the DIY weather station project, I used 18/5 (18 gauge, 5 conductors inside) wire because the pressure sensor has four connections. 18/3 wire would work fine for the temperature/humidity sensor, which only has three connections. For more complex sensor configurations, I have seen thermostat wire with up to 9 conductors available at most hardware stores.

Installing the Sensors

We are connecting two sensors to the data logger here: the temperature/humidity sensor and the barometric pressure sensor. We will mount the barometric pressure sensor in the data logger housing with the Raspberry Pi. It can be connected in the same manner it was for our inside test using a short piece of thermostat wire.

The temperature/humidity sensor is a little trickier, but if you’ve made it this far, it’s nothing you can’t handle. Before diving in, remove about 8 cm (3 in) of the jacket on the thermostat wire to reveal the conductor wires inside.

Put the Sensor in its Housing Before Connecting any Wires

The first step is to mount the sensor in the solar radiation shields we created in Part 1 of the DIY weather station project. I hung a small piece of wood in the radiation shield’s cavity and screwed the sensor to that. Make sure there is a hole in the top of the radiation shield to run the thermostat wire through. The hole should be just barely big enough to fit the wire through. After attaching the sensor to the wood, feed the end of the thermostat wire through the hole in the top of the radiation shield. Connect the sensor wires to the conductors of the thermostat wire using gray wire nuts. You can cut off any unused conductors in the thermostat wire or fold them back so they’re out of the way.

Next, securely run the thermostat wire back to where the data logger will be mounted. In my setup, I ran the wire through a conduit attached to the shepherd’s pole from which the radiation shield hung, then underground and up to the data logger through the same conduit through which the power and internet cables run.

An Important Note About Voltage and Wire Length

The DIY weather station’s analog temperature sensor can only support a maximum wire length of about 3.5 meters (11.5 ft). If you cannot get a sensor reading using 3.3 volts, use 5 volts instead. You’ll likely need to use 5 volts for wire lengths greater than about 1 meter. If you still cannot get a sensor reading using 5 volts, you’ll have to shorten the wire. By contrast, the digital pressure sensor can support a wire length up to approximately 30 meters (100 ft).

Installing the Data Logger

The data logger can be mounted in the sprinkler box housing we installed on the side of the house in Part 2 of this project. Run pieces of string through holes in the bottom of the Raspberry Pi’s case to attach it to the mount points inside the sprinkler box.

After mounting the Raspberry Pi, connect the sensor wires to their corresponding GPIO pins. If you have issues connecting the thermostat wire directly to the GPIO pins, connect one end of a jumper wire to the GPIO pin and attach the other end of the jumper wire to the sensor wire with a gray wire nut. After confirming the sensor wires are in place, connect the ethernet cable and plug the Raspberry Pi into the outlet in the sprinkler box to power it on. SSH into the Pi from your computer and run the test scripts again to confirm that the sensors are working properly.

Now that the sensors and data logger are in place, in the next phase we will set up the database, program the data logger to pull data from the sensor at specific intervals, and connect the data logger to the rest of the DIY weather station.

The post DIY Weather Station, Part 3: Installing the Data Logger and Connecting the Sensors appeared first on Matthew Gove Blog.