Weather Station High Level Design

This is one of a series of posts about various aspects of my DIY weather station project YAWS. An overview of the project and links to all related posts are here

This post is one of a planned series about my project to build a home weather station using Arduino and Raspberry Pi hardware and open software. This post focuses on the overall design (and my latest challenge).


From the beginning the project had two guiding objectives: to gather good quality weather data and to maximise control over all aspects of the project. The second objective could equally be stated as to maximise the opportunities to learn new stuff. In other words I wanted to do it myself, but still have good quality results.

These objectives drove a few key requirements for the project:

  1. A comprehensive set of sensors and data gathering algorithms.
  2. The ability to locate the sensors in a suitable position.
  3. Reliable 24x7 unattended operation.
  4. Non-proprietory data storage, analysis and presentation.

Of these the second and third combined to have the biggest impact on the overall design. To get decent data the sensors need to be placed in the open and a reasonable distance from obstacles (buildings, trees etc). In my situation this means a spot in the open at least 30 metres from our house. Reliable operation means solid power and stable comms to the rest of the system. So how to get power and comms to a set of sensors 30 metres from the nearest power point and router?


Initial approach

When I started the project I was intent on using Raspberry Pi hardware for all components. My initial plan was to have a solar charged battery powered Raspberry Pi Zero run the sensors, communicating back to a Raspberry Pi Model 3B base station via some sort of radio link (perhaps XBee or LoRa).

I started down this road and built a neat little package around a Raspberry Pi Zero to run the sensors. This included an RTC module with a battery so that the Pi could keep time without access to NTP. It also included an ADC to interpret the analog signals from the weather vane. The sensors attached via three RJ11/RJ12 sockets. I wrote a python script to monitor the sensors and pul together a set of observations every minute, and communicate to another Pi using two XBee series 2 radio modules.

This all worked marvellously well ... when within arms reach of a power point. The more I looked at solar and batteries as a power solution, the more complex, expensive and problematic it looked. I wasn't convinced I could design a solar cell / battery / charging circuitry combination that would reliably power the Pi Zero and sensors 24x7 in all weathers. I would also need to include some level of power monitoring to allow a graceful shutdown in the event of failing power, and some way to reboot the system when the power was restored. This was probably all a bit beyond me, or at least beyond my ability to make it really reliable.

The current design

I changed direction after seeing a post on the Arduino Blog linking to a project to build an Ultrasound Tank Level Meter. For me the key idea from this project was connecting two Arduinos with 4-core wire to provide serial comms between them and to supply power to the remote Arduino. I quickly prototyped the set-up using two Arduinos (a Mega and a Uno).

This quickly showed that Arduinos were much better suited to this problem than the Pi Zero. The single focus approach of a micro-controller made it all so much simpler, avoiding the issues around start-up and shutdown inherent in a full on computer. 

And so the current high level design was born:

High level schematic.png.001.png

The Raspberry Pi Model 3B is the brains of the operation. It sits securely inside with mains power and a good network connection. It runs a process that requests a set of readings from the weather station every minute (so the Arduinos don't need RTCs). This data is then stored in MySQL and served up on the web via a Flask app (more on this in other posts).

The Pi talks to an Arduino Mega by a serial connection running across a radio link between two XBee series 2 modules. The Mega acts as a simple relay, passing serial traffic between the Pi and the Uno which looks after the sensors. The Mega and Uno are connected by 50 metres of four core telephone wire. Two cores carry power and the other two carry the 9600 baud serial connection.

The power comes from a 12V, 1A DC power supply attached to a two way splitter. One side of the splitter plugs straight into the Mega, the other plugs into a socket attached to the wires to the Uno. The other end the wires terminate at a plug which goes to the Uno.

When the Uno receives a request it gathers the readings of temperature, pressure, humidity, wind speed and wind direction. This takes about 10 seconds as it takes multiple readings of wind speed and direction to come up with a single direction and peak and average speeds. The data is then sent back to the Mega which passes it back to the Pi.

An obvious question is why use the XBees? The answer is that they allow the Arduino side of the system to be located outside the building without the hassle of running a cable from outside to inside between the Mega and the Pi (e.g. out a window or under a door). Another possible solution would have been to connect the Mega to our home network via a WiFi shield. Given the peculiarities of our house this would have been a bit more restrictive as there is only one outside location that has both a power plug and WiFi access. (Yet another possible design would be to ditch the Mega and go back to the idea of solar power for the Uno, talking directly to the Pi with one of the more powerful XBee modules)

One small problem...

This design has been running well for a while now. I have tried the station in a few locations around our property, using either a 15m or 50m cable. Both worked fine and the whole set-up has been quite stable. There is, however, just one small problem ...

My wife has started experiencing interference on her AM radios. My first thought was the XBees, and sure enough when I switched the system off the interference went away.  This got me thinking about options for replacing the XBees, either with cabling or WiFi. The thing that I didn't understand was how a 2.4GHz signal would interfere with 600 MHz AM.

Luckily 30 odd years in IT has taught me to be wary of cursory fault finding (well, sometimes anyway). I went back, set-up an AM radio near the Mega and tested the system with a variety of components disabled. It quickly became obvious that the XBees were not the problem. I could run the Mega and the Pi connecting via the XBees and get no interference. As soon as I plugged the power or the serial connection to the cable the interference started. Even just the serial without the power did it.

This latter point is interesting as the serial pins operate at 5V. I had wondered whether using a lower voltage power source would help but this would indicate that it probably would not. (I chose 12V to accommodate the voltage drop across a long cable)

So it would appear that the interference occurs anytime I put a voltage across the 50m cable. I can think of two possible solutions to this:

  1. My wife stops listening to the radio (or switches to FM or digital), or
  2. I replace the cable with a shielded version (perhaps something like this).

Option 1 would work but I could foresee implementation problems. Option 2 sounds plausible but I don't have the knowledge to be sure. I am hesitant to spend $65 without a little more confidence. Perhaps a slightly shorter cable would help (is there some issue with the 50m length being suspiciously close to one tenth the wavelength of an AM signal)? Perhaps the noise is coming from the connections rather than the cable itself, in which case perhaps putting the Mega in a Faraday cage would help? All this hardware, moving electrons stuff is way outside my software-centric comfort zone.

In all seriousness, the great thing about this project is that I have learnt about a huge range of topics and the end is not in sight.

Stay tuned for more posts on various aspects of the project, such as sensors, enclosure design, measurement algorithms and the mysteries of RJ11/RJ12 cabling.