Rain Gauge Volt Meter

How to Use a Weather Station Rain Gauge Input as a Volt Meter and Microcontroller 101

I don’t know about you, but I rely on the field weather station quite a bit.  I monitor the trends on the day before my planned flying session to see what time the wind comes up.  In the morning, before going to the field, I look again to see if there are any surprises.  If it still looks good, I go fly.   A nice additional benefit is that I can pull the weather station up on my iPhone from Weather Underground.  The mobile app site is i.wund.com and our weather station is KCALIVER24. 

Below is a pic of the new Rainfall Graph that is showing the battery voltage.  Read on for details. 

Enhanced Rain Display showing Battery Voltage

There are a lot of low cost weather stations on the market today, many under $100, and this is the type that we have at the field.  These are very low cost units made for high volume production that monitor only the essentials, wind direction and speed, barometric pressure, temperature and rain amount.  These units are highly optimized for cost. 

While it’s interesting to have all this stuff at our fingertips, only a portion of the monitored parameters are what I label as essential to a pilot.  For me, the wind speed and direction are the highest priority with the temperature running a close second.   The others are non essential. 

One issue that we have at EBRC is that our field lacks 120VAC service, so we are left to our own devices if we want any electronics to be active at the field.  We need to provide our own power, currently in the form of a small, motor cycle sized battery.  To keep things running, we have to swap out the battery periodically to keep things like the weather station running in addition to the radio link to get the info from the field and onto the internet.  Chris Farley has been gracious enough, and lives close enough to the field, to be the necessary remote end of the radio link that allows the information to get to the rest of us.   

To help the battery last longer, we have a small solar panel that helps to keep it charged.  In the summer, it may completely offset the consumption.   But in the winter with shorter days and a less optimal sun angle, the battery needs to be changed more often.  I’ve been monitoring it for the last month or so and it seems for January we lose a net 30mv/day on average from the battery.  “Net” in this case is the overall consumption from the battery with the solar panel doing a little charging when the sun is out.  A fresh battery is about 13.5v and we want to remove it for charging by about 11v. 

So we need to monitor and replace the battery.  Unfortunately, we don’t always know when to do this based on time because we don’t know how much the sun will be out.  We try to guess as well as we can, and to be safe, mostly change it out more often than is necessary.  Not to mention, that we all have busy lives.  This has been a burden Chris has carried for years and recently I’ve started to help out as well. 

We all owe Chris a huge debt of gratitude.  Not only has he done the ongoing battery maintenance, he also pays the electric bill to run his charger and power the laptop to run the radio link that puts the data on the web.  Not to mention recover from periodic equipment failures.  And I seldom see him at the field.  Kudos to Chris!  Thanks on behalf of the club!

In the past Chris just replaced the battery occasionally.  Over the Christmas holiday we lost a battery due to its becoming over discharged as both of us were out of town.  It was a couple of years old to be sure and likely near end of life, but this shows the weakness in our system. 

To help to remedy this, my thought was that if we monitor the battery status in real time, we can change it out only when needed.  Ideally, if we could display the battery voltage on the web then we can have multiple eyes on this in case some people are out of town.  This way, the weather station can be up continuously so everyone can enjoy its use and we all have less surprises. 

Reasearch and a Solution.  I looked around for a while for a way to monitor the battery voltage remotely.  Everything I found regarding better weather stations was on the order of $1000 or more for a new weather station that included this capability or $400-500 for a data logger alone to monitor the battery.    I thought, “There has to be another way.”  I think that the reason there is such a gap in the pricing between the low cost stations and the ones capable of monitoring a voltage, is that the sort of logger we need is classified more as “instrumentation” or  “test equipment” which commands a higher price due to smaller potential market and much lower volume of production. 

Clearly, we need wind speed and direction and temp but could sacrifice items like rain amount or barometric pressure without loss of vital pilot information.  While I was chatting up one of the weather station people, I asked about how the rain gauge works.

How the Rain Gauge Works.  Inside the rain monitor is a little bucket that sits on one side of a lever.  On the other side of the lever is a magnet.  When the bucket fills up, the lever flips and two things happen;   the lever moves a magnet near a reed switch (relay) and the bucket dumps its contents.  The magnetic field of the magnet causes the reed switch to close.  The reed switch is tied directly to the weather station. The weather station only has to count how many times in one hour the reed closes to measure the amount of rain.  Clearly this is a very low cost implementation and quite simple.   I deduce that the coding inside the weather station accumulates the pulses in a counter.  After an hour, the value is transferred to the display and is sent out over the radio link and this accumulator is reset to zero to count for the next hour. 

The Plan.  So, we need a box that can measure voltage (our battery) and output pulses to talk to the weather station in a way similar to the rain gauge.  This doesn’t sound too tough and should be easy enough to implement with a small microcontroller.  There are many such microcontrollers on the market that are pretty inexpensive that have a built in analog to digital converter (a/d) and can drive an output to control a reed relay. 

One such microcontroller is made by my company analog devices.  We wrap our converter technology with a core.  I happened to have one that I use at work, so I started with an ADuC7020 which has many features only some of which are used on this project.  More details on this part reside at the following link.


Typically, all the manufacturers make small boards with the microcontrollers and essential elements around it.  These are called evaluation boards or something similar, we call this one a mini kit.  We would need some other stuff to interface to the real world in addition to the microcontroller but not much;  some resistors, diodes, a transistor, some LEDs to aid debug, a reed relay, some connectors, a board to house all these parts and the mini kit itself.  You can get some of this stuff at Fry’s but a better place is Anchor Electronics which is smaller than Digikey (mail order) but within a few miles of my work in San Jose. 

Cost.  Since this is pretty much custom and designed for our specific needs, it won’t be as cheap as something in high volume production, but shouldn’t be too bad.  I think we have about $100 in this in parts.  Certainly this is much better than $500 or $1000 and we get exactly what we need for this task.  I presented this idea and estimate to the club Board of Directors asking that the club buy the hardware and they did. 

A few weeks ago Chris and I were at the field and he was showing me how the equipment is distributed in the three boxes.  While there, we ran the cabling to substitute RGVM output to where the rain gauge formerly hooked up. As it turns out, the sensor concentrator is not in the same box as the weather station, and resides in the box with the radio, up high due to sensor location and fixed cable lengths.  This took a phone connector which I had in my junk drawer.  So, now we’re ready with local connections in the same box as the weather station. 

Below is the unit installed under the weather station in the lower of the boxes at the field. 

initial field install.JPG

Rain Gauge Voltmeter Installed

I made a back to back Deans connector with a tap to get power and the voltage we need to sense. 


Rain Gauge Volt Meter (RGVM)

What are All These Parts Anyway?  The rectangular green board is called a mini kit and contains the micro controller with flash memory and some buttons for programming the flash memory, which is the smarts of the system.  The flash memory contains the custom software to do the needed function and a way to store it without power (non volatile).  The functional code is described below in general terms and will relate the input battery voltage to an output timing value that controls how often to pulse the weather station.  Another way to look at this is that the board measures the battery voltage and conveys this information to the weather station in the language of a rain gauge. 

The yellow board is something that I built to do a couple of things;  1) scale the input voltage from the battery level to the micro controller input level  and 2) drive the reed relay from the micro controller output.  The reed relay contacts will drive the weather station rain gauge input.   There are also a few other minor things here like an LED to aid testing, a transistor to drive the reed relay coil, on/off switch, etc.

What Capabilities Allow the Board to Do What It Does?   The microcontroller has a core to execute software instructions as well as several hardware peripherals that can be used at the discretion of the designer.  In our case we only need two of the peripherals, the a/d converter to measure the battery voltage, and a timer to control how often the output pulses are sent to the weather station.

The a/d converter (analog to digital converter or adc) allows a voltage to be measured and results in a digital number. This number is then used by the internal program.   The converter does this by breaking the input voltage into a bunch of little steps and then counting the steps.  In this case, there is a 12 bit a/d which means there are 4095 steps between 0v and the max input voltage of 2.5v.   So each step is 2.5/4095 in size or about 0.61mv.  I chose the max input as 15v and resistively divided so this is equivalent to 2.5v at the a/d input.  With this scaling, 12v is equivalent to a 2v input to the converter which is equivalent to an a/d count of 3276 (= 4095 * 2 / 2.5). 

The controller clock is derived from an input crystal of 32.768khz that is multiplied up for use by the core.  The Phase Locked Loop takes the crystal input and spins it up to 41.78Mhz.  Since we really don’t need all that speed,  I use the default divider in the PLL to get to 5.22Mhz (41.78/8).   This instruction clock is divided down to a useful level by an internal Timer (/32768)  and is called the system tick.  At every system tick, certain activities are performed as dictated by the internal program.  In our case, the system tick is 6.28ms.  As you can imagine, you can get any time you want by just counting the appropriate number of system ticks. 

So, How Does it All Work Together?  What are the system dynamics?   The software is really pretty simple;  it reads the adc count (analog to digital converter count) and uses this to look up a number in a table that provides the output timing.  This tabled number is put into a register and used as a reference for comparison.  At the same time, another register begins to count once for each system tick.  When this counting register is equal to the reference register, a time has expired and an action occurs. Let’s say this time is the off time (toff), then at toff timeout (toff expiration) the output is turned on and the on timer is started.  When ton expires, the output is turned off and the toff time starts.  This process is repeated till power is removed from the system.   Forever. 

Ok, Pretty Simple, How Do You Make the Lookup Table?  I didn’t know how many pulses is equivalent to how much rain, so I initially assumed there is one pulse per 0.01 on the display.   I call this 1 count, just ignore the decimal point for now.  Since the rain gauge is going to be updated once per hour, and I want a number of 1200 on the display representing 12v, I need to pulse 1200 times in 3600 seconds (1 hour).   So 1200 counts/3600 seconds is 1 count every 3 seconds.  If the voltage is higher than this, it will pulse more often, so the weather station will count to a higher number indicating a higher voltage.  If the voltage is lower than this, it will pulse less often indicating a lower voltage.  Later I found out that instead of 1 count for 0.01 in/hr, it is actually 1 count for 0.04in/hr.  So, now one pulse for every 0.04, or 300 pulses/3600 sec or 1 pulse every 12 seconds.   You can see an LED on the minikit pulse at this rate and this is also driving the output relay.  

I chose a 1 sec on time to be about what it would take to dump the rain bucket.  Since we know the on time (ton = 1sec) and the time for 1 full pulse (1 pulse in 12 sec at 12v input ), we can calculate the remainder which is the off time (toff).  So for every a/d count I calculate toff and put in the table.  I did the calculations in a spreadsheet to make it easier.  The table is about 500 elements in length to make some of the math easier inside the microcontroller.  There is some more detail behind this but that’s the idea. 

Other System Issues.  We don’t know when the 1 hour interval starts in the weather station, so we are distributing the pulses evenly over the full hour interval. This makes it less important when any pulse or set of pulses may occur.  Alternatively, we might be able to send all the pulses in a burst, but this could introduce unnecessary complications (pulses could be too fast for weather station to accept, weather station timing could make when pulses too critical, the 1 hour interval boundary would be very critical if within the burst time, etc ).

The rest of the effort to do this project is essentially the details behind the curtain.  This involves several different kinds of tools much like other professions;   hardware tools, mechanical tools, software code compiler tools, testing tools.  In many cases, you make the tools you need along the way, sort of like the RC hobby.  Some of the tradeoffs are dealing with hardware design choices, board mechanical issues and construction, software tool licensing, compiler and linker issues, emulator licensing and issues, code debug and micro controller flash programming. 

Below is a pic of the former current weather underground display that is fed from our weather station.  As is normal, not much rain but typical of Livermore especially this year. 

Weather Station Web Pic Before Enhancement

Below is the display after I turned on the Rain Gauge Voltmeter at about 11:30am on 2/19.

Web Pic with Rain Gauge Volt Meter Active

On the web based display, we cannot change the label (inches/hour) on the Rainfall Rate graph.  We will be feeding it numbers that will be battery volts.  We’ll just have to know to interpret the numerical display as volts;  that is, if the display says 12.00 in/hr, we will need to interpret it as 12.00 volts.  So, it will look very rainy at the field, say 12 or 13 typically, but we’ll know this means 12 or 13 volts on the battery, not the next great flood.

The WM-918 weather station has a limit on the rainfall rate measurement of about 39 in/hr on the rain gauge input but we’re well below that for our needs.  

Note the voltage sag just after 5pm which I suspect is due to the solar panel not providing charging as the sun sets.  Sunset 2/19 was about 5:45 and you can see how the solar panel contribution begins to diminish just after 5.  Next day and other graphs show a boost in the morning when the panel starts to charge the battery.  Very cool!

We still have some issues with the end to end system.  I’m sure we’ll figure it out so stay tuned. 

One problem (a) is how the data is displayed on Weather Underground in the graph format.  The correct data is listed below the graphs in the far right column but the graph sometimes has too many horizontal lines so it seems to be some scaling issue at Weather Underground.  One clue is that if the data goes to zero autoscaling seems to work, but if the data is continuously at 12 or so, we get the excessive horizontal lines.  

Another issue (b) is that periodically the data stops being received by Weather Underground although the RGVM is still correctly sending pulses to the weather station.   At this point it’s not clear if the issue is in the weather station itself or in the software that pulls data from the weather station and sends it to Weather Underground (virtual weather station). 

So, that’s about it.  Any questions about the design or implementation just drop me a line or we can chat at the field.   Using this scheme you can pretty much put whatever you want onto the display using the rain gauge input.  Any ideas for other applications just let me know.

Happy flying.