RainSavor
RainSavor | Updates
Project Leads: Cameron Clonch and Cameron Whitlow
Working with Dr. Catalina Segura and the OSU Department of Forestry, a rainwater collection system is being developed to test the electrical conductivity of rainwater during storms in Oregon.
Using a cup and siphon design, 5mL of rain water will be collected and then released every 1mm of rainfall (about once every 15 minutes), with electrical conductivity measurements taken of the rain prior to the water's release. The data will be used to evaluate how conductive storm water is, indicating a presence of various minerals from the ocean and/or other nearby relevant geological sites.
| Specification | Metric | Value | Status |
|---|---|---|---|
| Battery life | Months | 2 | In Testing |
| Reads electrical conductivity of water | µs/cm | 0-100 | Yes |
| Records data at specified rainfall increments/intervals | mm | 0.1 - 1 | In Testing |
| Holds rainwater and then disposes | mL | 5 | In Testing |
| Logs Data to SD | time | date/hour | Yes |
| Serviceable for battery changing and clogging | Yes | ||
| SD and USB are easily accessible | Yes | ||
| Removable for winter time | Yes |
The system of the cup and siphon relies on gravity and potential energy to "push" the water out. Fluid behavior retains pressure throughout the entire volume. Once the maximum fluid height is reached, which is when the height of the fluid in the container and the maximum siphon height match, the fluid is able to flow downward, to a lower pressure (like water flowing down a mountain). The siphon now behaves like a vacuum since there is nothing to break the flow of the fluid until air is able to enter. However, air can't enter the siphon until all of the fluid has been removed and the base of the siphon is exposed.
The current design employs the Form 2 printer with SLA resin to create a see-through mechanism that enables the user to observe water passing through the system. The siphon drains at increments of approximately 5mL of water collection. Water is collected by way of funnel, then stored in a small reservoir, where the electrical conductivity is able to be measured; the water simultaneously fills a small siphon connected to the reservoir. The siphon also houses the interrupt probes, which trigger electrical conductivity readings just before a draining event occurs.
The funnel/reservoir/siphon trio will be contained in a frame used in the Davis Instruments Rain Gauge (which includes a mechanism for keeping debris out of the system). This aspect of the technology is currently being designed. All electronics will be kept inside a Pelican box, which is a weatherproof storage system that will protect everything from getting damaged. The mechanical and electrical design will be connected by way of CAT5 cables between the funnel setup (outside the Pelican) and electronics (inside the Pelican).
The RainSavor project consists of two main components – the mechanical and electrical pieces. The electrical system has a number of goals to meet including temperature readings, interrupt handling, EC sensor connections and signal processing, data sampling hardware, and a microcontroller. These last few items are handled with pre constructed solutions with a Feather M0 microcontroller and OPEnS Hypnos board which hosts the SD card for data logging and an RTC for time recording. The rest of the system will need to be designed purposefully to meet the rest of the system requirements, primarily around the EC measurements. Many projects here at the OPEnS lab have water EC measurement requirements and utilize the same board. This PCB was designed for specific use by the RainSavor and the Smart Rock teams, although it can easily be used by other teams who require these tools. Most of this system was built to kill two birds with one stone.
The design of the electrical system takes advantage of many tools that the OPEnS lab is familiar with a handful of additional components. Many of the features in the system are designed around this existing technology, such as the ADS1115 which is fully implemented in OPEnS Loom library allowing for very simple integration. The PCB hosts all of the components required with a handful of wires leading offboard via connectors. All of the connections traveling off of the PCB are 2mm pitch JST connections, varying between 2 and 4 pins. Only some of these connectors are utilized by the RainSavor system, the others are utilized by Smart Rock. All components are utilized by the RainSavor system except for the LEDs and the Reed Switch which are Smart Rock specific.
The PCB is small enough to be placed inside of a pelican box alongside a battery with enough room for wires to connect and travel outside of the box through a waterproof port. The size of the PCB was kept fairly small for these purposes and for Smart Rock size limitations. There are also mounting holes on the corners of the board. Many of the components are SMD, including all of the resistors, capacitors, and most of the chips. The components that require hand soldering is the 14 pin DIP op amp IC, the 5 diodes, various headers/connectors, and the switch. Using a stencil and oven to solder the SMD components is heavily recommended as the ICs are very difficult to solder correctly by hand. Overall the layout is built with as easy a flow as possible. All connectors to the left, microcontroller attached in the center/bottom, temperature connectors and indicators at the top, and all of the EC sensor circuitry in the center and right side. Supporting ICs, such as voltage regulators, the ADS, and a variable resistor, are towards the left side of the board to better optimize the routing of the I2C lines. This board communicates with all on board chips and off board sensors via I2C with no SPI support as all used components utilize I2C. There is an additional general I2C connector for any sensor.
The following is the power budget based on the parts used on the PCB. The power budget was calculated with the assumption that every part of the system will be running full time, which will not be the case in practice. This power budget will represent the absolute worst case scenario of no deep sleep and all circuits running full time.
An additional power budget will be ran with the same parameters (full time running) with a power supply measuring how much current is being drawn by the system.
There are a couple options for temperature sensing for a system like this and this can still be updated for future implementations. The main argument lies between using a thermistor or a thermocouple for temperature measurements. This system uses a thermocouple for a couple of reasons. The first is the dimensions of the sensor itself. The thermocouple has a small metal rod at the end of the wire with the tip sensing rather than the whole rod. In comparison the thermistor is a silicon rod that senses with the entire rod. Since the amount of fluid being probed is very small it wouldn’t be feasible to submerge the entire thermistor, the thermocouple makes the physical aspect of sensing much simpler. Each type also has different supporting circuitry. The thermocouple is more complicated with an entire breakout board being connected while the thermistor only requires a resistor in a voltage divider layout. The advantage on size and ease of implementation belongs to the thermistor for the minimal space. Unfortunately, there is an additional downside to the thermistor where the resistor changes value dependent on the temperature as well, which is difficult to fix in software. The thermocouple doesn’t have this challenge as the breakout board handles everything already and uses a cold solder as a temperature control point and varies much less than a thermistor. We decided it was worth the added complexity and space to have the thermocouple and greater temperature accuracy. Below are some temperature tests of the two methods that helped us come to this decision.
This graph shows how the thermistor and thermocouple react to extreme temperature changes and how noisy they can be. Note that the Y axis is different for the two sensors. The thermocouple measurements are in degrees Celsius while the thermistor is a value of voltage read in by the microcontroller ADC. Generally the thermocouple has less noise in the temperature signal and has a faster response to a drastic change in temperature.
To get more information out of the temperature graph comparisons the thermistor y axis was altered to match the scale of the thermocouple graph as a relationship to the input voltage. This allows for a more direct comparison that shows the limits of the thermistor in the upper temperatures and the greater variances across the graph. We aren't expecting rain to be the temperature of boiling water, so this drawback of a thermistor isn't important. Regardless these two graphs helped us to decide that a thermocouple is worth using. The effects of temperature on the resistor in the voltage divider network of the thermistor is slightly seen here, where the thermistor has a bigger or smaller error to the thermocouple at different temperatures.
The only reason temperature is needed is to give us more accurate descriptions of the water EC. The EC is fairly dependent on the temperature of the water and can have a large swing when the temperature is higher or lower than 25 degrees Celsius. Anyone using this system has the option to ignore the temperature sensing component but risks having data that isn’t as accurate.
This section will go more into how the electronics get data from the water to the board for processing. As explained above JST connectors lead all signals into the board. There are only two pairs of wires, four wires total, that connect to the funnel for the RainSavor system. One pair is for the EC sensor and the other pair is for an interrupt system. The interrupt system is straightforward. The first wire is a common ground and the other is attached to the interrupt pin with a large pullup resistor (large in this case is around 250k ohms). This large resistor is needed to pull the pin up and still allow it to fall when the large resistance of the water is introduced. When water in the siphon shorts the two wires the pullup is then shorted to ground, pulling down the interrupt pin and triggering the interrupt in the software. This allows the system to pull itself out of sleep mode when water is present in the system to take a measurement, saving battery and making sure the system gets a measurement every time there is enough water to measure. These probes are epoxied inside small holes in the siphon.
The main job of the electrical system is to measure the EC value of the water and log it on the SD card. The EC sensing circuitry takes up the most space of the board. The value measured by this circuitry is directly related to the conductivity of the water in the siphon. Some of the circuitry on the PCB is there to better tune the range and measurements of these readings and can be utilized on a project by project basis. The tuning resistor can be set as a ratio of 10k or 100k ohms depending on which circuit is being used. Calibration will be required for each set PCB as inherent small variations of component values may have an effect on the EC measurement. The calibration will be used to set this resistor value and find the correct equation for translating the results once the data is collected.
All of the tuning for the EC sensor is done using stock solutions. Each PCB will have slight variations but the same behavior should be observable. The first major test and comparison of the system is verification against the initial calibration data against these stock solutions. The next two graphs show a curve with generic probes and a curve with the siphon used for RainSavor. These curves are expected and similar data should be seen for this sensor.
Paying attention to the siphon measurements the resolution of the data is a poor fit for the system expectations. Our specifications detail that the range of measured EC is between 0 and 100 uS/cm whish has a very small range of readings from the initial measurements. The highest value shown is an EC value that is very outside the expected range. Better utilizing the tuning variable resistor will help to give a much larger resolution. There are two variable resistors that can be used between the 10k ohm and 100kohm base. The next graph will show the 10k ohm range on 100 uS solution, showing a linear relationship between the increased resistor tuning and the EC measurement.
This resistor sets the upper value of our circuit and since our high end if 100 uS it is useful to increase this value as high as possible. Since the maximum reading of the sensor is around 13000 there is still lots of room to use, allowing for good use of the larger tuning resistor value.
To better show the resolution changes when updating the resistor value, the next graph will display how the data reading is effected.
The full measurements of the EC reading as the EC sensor is swept is valuable information for determining what value of resistor is best for the application. The next graph shows some data that can be useful in this goal.
If an even greater resolution is required the larger 100k ohm version of the resistor can be used on the board instead. When running the same tests as above similar results are seen but with larger values.
With the system going in and out of deep sleep mode the timing to get the oscillating circuit up to the correct frequency will be important. If data is taken while the signal isn't ready the data may be inaccurate. This can be fixed by waiting a set amount of time before the data is sampled. In order to find out how long this wait time needs to be an oscilloscope can be used to find out how long the setup time is for the oscillating wave to match the sinusoidal wave. This is scoped out to the waveform below. This is easily by setting a trigger to catch the rising voltages and probing the sensor connection while the microcontroller/hypnos stack supplies power to the EC circuit.
The voltage division shown is 500mV per div, with the peak voltage at the start of the wave being 1 volt. The time division is 200 microseconds per div. The start of the signal is obviously not what we want when taking a measurement, the signal must reach a steady oscillation first. This oscillation becomes steady about 500 microseconds after the signal powers on, or about half of a millisecond. This is such a short amount of time that the software may not even need to have a delay introduced. To be safe a minimal delay of 1 millisecond can be incorporated to ensure the signal is ready for measurement. This is good to know for system development and fortunately this timing difference is quite inconsequential.
Through this wiki page data will show the sensor reading maximum values for seemingly no reason as no changes in the physical system happen when these outliers occur. The signal of this event was able to be scoped out and will be shown here. First the nominal waveform for correct operation will be shown which guarantees correct operation of the sensor.
The wave has a very consistent sinusoidal waveform at consistent voltages and the correct frequency of about 1.6kHz as the circuit was designed. In comparison the following is the voltage waveform of the same node (siphon connection) during one of these outlier events.
There's a lot happening in this signal and is very different from what is expected of the system. First of all the peak voltage is quite a bit higher, over 2x the amplitude. One of the most visual differences is the troughs of the signal. Unlike a normal sinusoidal wave the troughs have a saddle like shape with two low peak voltages before returning to a traditional sinusoid for the upper half of the amplitude. This effect is period and happens in every period of the signal. The other strange difference is what the signal is showing. It has a very visual sinusoidal like wave as an envelope signal for another much faster signal. This inner signal operates at 144kHz, almost exactly 9 times faster than the wanted oscillation speed. This is all very strange behavior and I am not sure what the cause is. The fast signal oscillation leads me to believe an impedance mismatch is causing reflection in the signal, essentially making copies of the same waveform overlying each other to create this signal. More testing will need to be done to find the cause of this behavior.
All of this data is useful to understand how each individual system will need to be calibrated. Different combinations and utilizations of the above data can form an equation for calibration in any way the user sees fit. At the moment we are using a linear fit curve using the DI water measurements, a midpoint EC value measurement (such as 23 uS/cm), and the top end measurement (the 100uS/cm measurement), giving a 3 point curve to create a linear fit. Other methods of data estimation can be used, such as other fits, or various theories in information theory. It all comes down to how accurate the final data needs to be for the user. In our case we used this 3 point linear fit to attempt to measure gathered rain water electrical conductivity. In this data we used an equation derived from these tests and an equation derived from a calibration taken right before measurements on slightly different electrical systems. The error between these two is also shown.
This data shows, across three trials from the same source of rain water, that the error between a calibration from the data taken at system verification and the data taken from a new pre test calibration is within one point of EC value. This is promising as the method of calibration won't greatly change the results, although the variation between these errors is higher than we would like to see and we would like to make smaller. The good news that we pull from this data is the system does indeed react to rain water and can pick up EC values. Additionally the higher resolution was easily able to pick up the EC value when compared to DI water. If we had used the baseline resistance of the 10k variable resistor this would not be the case as shown in above graphs, the EC data would be much closer to DI water. The reported EC value of the rain water is correctly within the range of the specifications and expected range. The downsides include the variance in the data. If exact measurements are needed it will be difficult to determine that value with a small amount of measurements per siphon event. This may not be a notable downside in RainSavors application as the trend of the EC from the rain will be picked up in the data over multiple siphon events in a rainfall event.
This section will provide information on what data we have gathered with our device. It will be broken down into three sections, a data analysis section, an in lab testing section, and a field testing section.
This section will serve to show some basic examples of data and the first data we got when operating our system in the lab. In practice data will be discrete and only sampled when water is present but in these sections the data will be shown as a continuous variable with samples taken periodically instead of only when needed. This is to better understand how the system is reacting to siphon events and to better watch the data. The first graph shown is the first run time test done.
This data graphs the voltage read by the ADC as a bit valued ratio over the samples taken. There are multiple peaks and plateaus (what I call hang ups) across the data. The peaks correspond to different stock waters with known uS/cm values, which rise and fall as would be seen with any water value. The hang ups are an artifact caused by an electrical phenomena in the circuitry and is currently unknown. Some capacitance or impedance mismatch is causing the voltage to max out for periods of time although this never occurs when water is introduced, only before or after. This is also not a repeatable phenomena but I believe it has to do with the connectors adding resistances, capacitance, or general impedance. Fortunately this can also be fixed in post processing as all of the wanted data survives. This can be done by taking these max values and setting them to a value the sensor reads when no water is present. The following is the fixed data.
In addition to suppressing the hang ups to a open sensor value the data is now graphed as EC value against sample number. This is done by running the raw data through a linear equation determined by calibration numbers. The values of the stock solutions (23, 84, 100 uS/cm) are clearly seen with some variance. This variance is caused by environmental temperature which can change the EC by a non minimal amount. I believe some of the smaller bumps are caused by the DI water mixing with stock solution in the funnel, carrying some of it with it. This causes a small EC to be picked up rather than very little EC as expected with DI water. All presented data will be shown in similar ways as this data.
With the anomalies seen in the first few tests, such as the one shown above, a few more lab tests are ran. Two more tests were completed to try to show similar results.
The first test did not show any of the hang ups present in the previous sections results. The small bumps from the DI water are still present which isn't unexpected at this point. Data without these hang ups is promising, as the issue that causes them isn't debilitating for the system and isn't always present. Between the inconsistency and how it can be fixed in post processing this issue will be looked into deeply at a later date when the system is field testing. A second test was done to see how consistent the system is.
The second test shows similar data to test 1. Both of these tests react appropriately, or as expected, as different EC stock solutions are introduced to the sensor. There is a hang up in the data at the end of test 2 which corresponds to when the connector wires are being unplugged from the siphon and PCB. This reaction leads me to believe that these hang ups are caused by changes in impedance of the transmission lines between the PCB circuitry and the probes for the water. All together the data is promising for field testing.
The first set of data shown in this section was taken with the entire system put into the field with a prototype field testing setup which will be used for future tests while the final field setup is being finalized. The system looked as follows.
The Davis instrument funnel at the top has our 3D printed siphon attached via screws at the output, allowing the small 3D printed component to have a larger surface area for rain to fall in. The water then drains out from the bottom of the Davis instrument. The wires run out from the printed siphon and into a pelican box mounted on the t post holding our electronics and battery which will run the signal processing and data logging. Unfortunately no rain was forecasted for on the day this first test was done. The purpose of this field test was to make sure this physical setup would work with water draining and was simple to install. The data we gathered with this setup was done with the same stock solutions all previous data was gathered with.
The above graphs show the data we collected with this excursion. It is worth noting that the data is only accurate for the first few hundred samples. We only had the system setup for about 10 minutes (as no rain was forecasted), but the electronics box was zip tied shut so we were not able to unplug the battery for a while. To take advantage of the situation we left it running for a few hours to see how the battery and the system behaved. The system was transported in a backpack and was repeatedly jostled as it was walked around. Interestingly the hang ups returned a few times, especially later when it changed to a room temperature environment. The data is accurate to the point of being able to read the reported EC values which correctly correspond to the used stock solutions. This test is successful enough to go forward with a longer test of 24 hours with forecasted rain over this weekend.
A quick rainwater test was shown above in the wiki in the calibration section but will be shown here as well.
These tests were done in a lab setting with rainwater collected with a bucket. The system was able to detect the changes in EC from rainwater and was about the EC value we expected from generic rain which isn't a very high EC. This also means our resolution is small enough to easily pick up the differences in rainwater EC. The future outdoor trials and field tests will be compared to this initial data to ensure our EC measurements are accurate. Data validation with a known instrument will still need to be done.
###First long field test The first multiple hour field test was done during a long term forecast for rain to retrieve as much data as possible for the battery life. This test didn't include a deep sleep mode in part to find out how long the battery lasts when running full time and taking data points very frequently.
The raw data from the SD card shows nothing very unexpected, although the high plateaus from the sensor readings are still present. As stated before these can be fixed with some data processing. Other than that there are many variations along the data line, some more extreme than others, that would correspond with rain being funneled through the siphon. The goal is to now determine how frequently these are happening to determine a battery life for the system. Additionally the data can be shown alongside a temperature graph to show how the outdoor temps change EC in water.
The top graphs show the raw data after some processing and converting to EC values. The second graph then shows temperature logged by the hour at a nearby weather station. This is interesting to include as it is well known that temperature changes the EC of water which has a visible effect on the EC graph when compared to the temperature.
Another way to view the data is to compare what was collected with measured rain rates. Some weather stations report a rate of rain fall for different intervals of time. Data was pulled from the KVCO station at the Corvallis airport.
The additional data provides more context towards what the sensors are reading. During higher rain rates the data sampled by the sensor represents a saw wave like signal with faster oscillations. This is due to the fact that with more rain falling the siphon will drain at faster intervals. There seems to be some semblance of a pattern between the EC measurement and the rain fall which may be due to temperature differences in the water and air in the siphon or some other type of issue.
Some things will need to be updated and changed in our system. The wires need to be remade to be cleaner and color coordinated and better waterproofed with heat shrink for the connections done outside of the pelican box. Additionally the siphon has suffered a crack while in transport. This siphon was printed with less durable materials for fast printing and testing. More printing is in progress to make suitable siphons with more durable materials.
The current goal is to put the system through more tests, making needed updates, and readying the system for full time use. The electrical system currently needs a better way to check for water existing in the siphon, the current interrupt handling isn't always successful. There are potential small circuits that can be wired together than may fix this issue, testing this is the first step. There are other software solutions that may also be fruitful.
- Capture and release equal volumes of rain water repeatedly
- Measure electrical conductivity of storm water
Siphon Size Tests: After testing various siphon sizes, aiming to achieve the smallest amount of water collection while maintaining accurate results, a water collection volume minimum of approximately 2mL has been determined.
In the coming weeks, RainSavor aims to integrate mechanical and electrical design to conduct prototype tests during rain events in Corvallis, Oregon. The project is also looking to improve methods for removing debris and keeping the siphon mechanism clear of any potential blockage sources.
Siphon, Rainwater, EC Measurements