Hardware components | ||||||
| × | 1 | ||||
| × | 1 | ||||
| × | 1 | ||||
| × | 5 | ||||
| × | 1 | ||||
| × | 1 | ||||
| × | 1 | ||||
Software apps and online services | ||||||
 |
| |||||
Hand tools and fabrication machines | ||||||
 |
| |||||
Traditionally, streams are measured either manually by a scientist or by large and expensive permanently installed stations. To make stream and river monitoring more widespread, we developed a low cost device to provide real time stream and river data. Our sensor measures gauge first and foremost. This is accomplished through an ultrasonic distance sensor (JSN SR04T) mounted towards the surface of the water. Temperature and conductivity sensors are mounted at the end of a cable that is submerged. The device is controlled by a Particle Electron 3G that enters a deep sleep of one hour between readings. The sensor is powered by a pack of 15 AA batteries at 4.5V. Live data is posted to https://aquametric.menon.pro.
Project Updates5/22/2020 Stream Cross Sectional Analysis
Knowing the depth of the water flowing through a stream is great for knowing when it may flood or how the banks may erode over time, but in order to predict how other bodies will interact with a stream, its often useful know the actual volume of water flowing through it.
In order to calculate the flow rate, you need to know the cross sectional area of the stream which can be found with the live depth of water and a profile of the stream's bed. We found this stream profile using an old fashioned measuring tape and meter stick. At 2 feet increments across the width of the stream, we measured the height of the water. From those measurements, you can generate a graph for a cross section of the stream's bed.
To find the area from the profile, we use the height of water in the stream reported from our sensor to offset this line so that the x-axis represents the water's height. From there, we use a riemann sum to estimate the area. We have it working in a spreadsheet right now, but eventually we plan to incorporate it with our server to do live flow calculations.
Unfortunately, knowing the area of water isn't very useful without also knowing the velocity of water flowing through that cross section. The issue is that the velocity is highly dependent on the height of water in the stream. The most reasonable way to solve this is by simply measuring the velocity of the water across a wide range of different stream stages. After enough data was collected, a look-up table could be used to estimate the velocity for a given stage.
The issue with this approach is that it doesn't make for useful predictions of flow when the stream reaches a height that is out of the bounds that you measured previously. Using a sensor to measure the velocity live could work, but it would likely involve moving parts which would make it prone to debris build up.
4/28/2020 Sensor Submerged
Our sensor mysteriously stopped reporting measurements back to us yesterday around 3 am. The battery and cellular strength all seemed to be acceptable, so we were unsure what had happened to it. The last few readings from the sensor show the stream water level rising rapidly, but nothing that we hadn't seen before in previous rain storms. When we visited the sensor that evening here's what we saw.
Yeah, we didn't see the sensor either. After getting into the river, we found our whole sensor and mounting plate had tipped over and our sensor was entirely submerged under the water. We did not have very high hopes for the sensor, as it had probably been under the water for a good 18 hours by then. But, miraculously, the sensor woke up as usual as soon as we pressed its reset button.
When I later took it apart to inspect the damage, I found that the insides were very moist, but there was no puddle of water or major damage to the internals. We determined that the mounting solution was what needed fixing rather than the device it self.
When we first started the project, our initial idea for mounting was to hammer in a hexagonal aluminum extrusion into the river bed and mount the sensor directly to the top of it. When we came to Alplaus, we found that the rocky bed would not allow us to get the extrusion deep enough to be held securely.
Our next solution was a frankenstein of L brackets and an old desktop side cover. This would use rocks to weigh down the metal plate and hold the extrusion upright.
You may be able to see why this design didn't end up working. As soon as the water level and velocity rises, the metal plate acts like a sail and sends our sensor straight into the water. We need some more stability against tipping. So, continuing with the frankenstien theme, our current plan is to combine the two ideas.
First, we'll start by using a steel rod and a hammer to create a hole in the river bed. Then the aluminium extrusion will be placed in that hole. And finally, the metal plate will be attached to the pole and have rocks to weight it down to add some stability.
4/24/2020 OTA updates and editable measurement frequency
The frequent trips to the stream for software updates were starting to get tiring, so we sought to implement OTA updates. We also wanted to be able to change the frequency at which our sensor wakes up and takes a measurement (e.g. hourly, every 15 minutes).
The Particle Electron microcontroller we are using supports OTA updates out of the box, but it does not save flash requests in any kind of queue. This means that we can't update the device firmware for the time that the sensor is in a deep sleep. Additionally, even if we could time the update exactly for when it wakes, the runtime has been minimized to about 15 seconds and so it would not have enough time to complete the update before going back into a deep sleep.
We created a server that handles both the OTA and variable frequency features of the sensor. When the device wakes, it accesses a json file on our server. This contains two pieces of information, the amount time that the device should deep sleep for and whether or not there is an OTA update available.
If there is a piece of firmware ready to upload, the device publishes "ready_for_update" to Particle. and waits for 2 minutes. Using webhooks, our OTA server sees this message from the device. It uses Particle JS API to flash the device with the firmware in its queue.
While this seems pretty convoluted, this solution allows the device to skip the 2 minute waiting time if there is no update available which saves battery life. We hope to use the variable measurement frequency to take readings more often when we detect some anomaly with stream conditions.
4/11/2020 Sensor Initial Versions
Version 1
For the first version of our sensor, we focused on developing a device that could take accurate measurements of the water’s stage height. We initially chose an ultrasonic range finder for this purpose. It was oriented towards the water’s surface. By subtracting the measured value from the height at which the sensor was mounted, we could calculate the height of water flowing through the stream.
We decided to power this device with a solar panel and lithium polymer battery. This would theoretically allow the device to be deployed indefinitely. For communication, a WiFi-based Particle Photon microcontroller was used. WiFi limits the possible locations of the device's deployment, but we were less focused with this issue with this iteration. We were more focused on developing a device that could stay powered while providing accurate measurements.
While this iteration showed promise, it had issues revolving around waterproofing, battery life and connectivity.
While ultrasonic seemed like the clear choice for the sensor, it made the device almost impossible to waterproof. Unfortunately, the ultrasonic sounds from the HC-SR04 can not permeate almost any waterproof materials. This means that the receiving and transmitting elements were directly exposed to weather. They developed rust and failed within a week.
Both the battery and microcontroller operated on 3.3 volts. The ultrasonic sensor required 5 volts to function properly, so a voltage boost circuit had to be added. This added complexity and reduced battery life.
The WiFi based microcontroller that was used prevented the device from being deployed anywhere without an access point and permission to use it. This was the main barrier that we sought to overcome in our next iteration.
Version 2
The second design iteration was driven by some of the issues we discovered in preliminary testing of the first version.
This version began with a choice in communication method. LoRa (Long Range) is a communication protocol for low bandwidth and low power communication. There is a large community of developers using LoRa for sensors similar to ours. Some were achieving distances of upwards of 20 miles from transmitter to base station. We determined that most streams of interest would be within 20 miles of a WiFi and power source where a base station could be installed.
After beginning to test the possible range of the sensor, we quickly started realizing that it was going to pose an issue. Simply getting one mile to the nearest stream was impossible. We knew that tree cover was going to reduce the signal strength, but we were not expecting the loss of signal that we observed. Our signal strength was also significantly decreased by the fact that rivers tend to be located in valleys, which meant that our sensor would not have a direct line of sight to the base station. To attempt to fix these issues we first switched from standard linear antennas to two directional antennas.
This improvement in range allowed us to develop a sensor for a neighborhood stream about .2 miles from the base station.
Although the use of directional antennas did result in an increase in usable range, this increase was not significant enough to make this a practical solution. We briefly considered creating a system of several repeater stations to re-broadcast signals until the data arrived at our base station, but we decided that a simpler solution would be to move to a communication protocol for which a significant infrastructure of “repeater nodes” already exists - cellular.
Version 3
For the third version of the sensor, we again desired to improve on some of the issues that we discovered with our second design iteration.
Firstly, we switched from LoRa to cellular as the method we would use to transmit data from the sensor. Cellular was initially dismissed as a possible communication method due to its relatively high power consumption. We knew that there would be new challenges to using cellular connectivity, but its benefits would outweigh the costs. By using cellular, we were longer limited by our distance to the sensor - as long as we were within the range of a cell tower, we would (theoretically) be able to transmit stream data.
Another change that was made in the third design iteration was to switch to AA batteries instead of LiPo (Lithium Polymer) battery cells for our power source. Although alkaline batteries are less energy dense than lithium based batteries, switching came with a variety of advantages. AA batteries are less dangerous, as they don’t have a tendency to ignite when over-discharged. They also have a much longer shelf life, and are less susceptible to extreme temperature and water damage. We found that they performed at temperatures near freezing, which was an important consideration for us.
To reduce power consumption in this version, we added a secondary microcontroller to control power to the main cellular microcontroller. While on the surface, this may seem like simply doubling the required power, it proved highly effective to extend the battery life of the device. The power switching microcontroller is outfitted with a real time clock (RTC). It allows it to enter a very deep sleep state in between sensor readings. Each hour, the RTC wakes up the power switching microcontroller which subsequently uses a MOSFET to provide power to the cellular Particle Boron. This reduced the on-time of the device from 60/60 minutes to about 7/60 minutes.
For the first installation of our final sensor version, we used a 1.5 m aluminum extrusion that was driven about 50 cm into the ground. Finding a location in the riverbed that was soft enough to drive in the extrusion but firm enough to support the sensor was difficult, but we settled on a location under a bridge. Unfortunately, when we came to check on this sensor after a few days, we found the pole had been bent significantly from what we imagine were large ice sheets being carried down by the water. Additionally, a large amount of debris collected on the sensor pole which obstructed our ToF distance sensor.
The next deployment of our third iteration drove the development of new mounting systems. We located an alternative spot to mount the sensor, somewhat downstream from our first location, in shallower and faster-moving water. The streambed here was much rockier than our original location, making it nearly impossible to get the metal pole deep enough to provide the necessary stability. To solve this issue, a system was developed in which the aluminum extrusion was fastened to a steel plate through the use of L-brackets. This was placed onto the streambed, and covered with rocks for stability. This new system gave us much greater versatility in the selection of deployment locations. The faster-moving and shallower water made it much more difficult for debris to build up after the sensor, and after a few days there was essentially no debris built up on the sensor at all. Additionally, by moving to a location in the stream somewhat away from the bridge, the strength of the sensor’s cellular connection was also improved.
Streams and rivers are crucial components of many ecosystems and human activities. Today, the USGS maintains the largest collection of stream sensing devices. They have about 10, 000 sensing devices across the nation. Unfortunately, this does not cover millions of American homes susceptible to flooding from nearby streams and rivers. Additionally, these sensing stations are designed for accuracy. This means that installing one has a high cost of infrastructure and can cost thousands of dollars.
Stream data does not have to be limited to gauge and flow rates. Many residential drinking supplies come from water that originates as runoff. Impurities like road salt and fertilizer can sometimes find their way into these drinking supplies. By monitoring temperature and conductivity in these streams, you can help predict ecological events like algal blooms. And, if the network of sensors is large enough, you can pinpoint the origin of the impurities.
By creating a low-cost, distributed sensor network, we hope to address both of these problems. The availability of large volumes of high-quality sensor data has the potential to improve applications such as weather forecasting and ecosystem health monitoring.
Solution
Hardware
(A) A Particle Electron microcontroller is responsible for coordinating all the sensors present on the device and using a cellular data connection to transmit this to the central server.
(B) A 3G antenna is mounted internally away from other electronics to improve reliability.
(C) An ultrasonic distance sensor faces the surface of the water measuring fluctuations in the height of water flowing through the stream or river. The raw sensor data can then be used as a measure of relative flow rate.
(D) A thermistor mounted under the surface of the water measures the temperature of water flowing through the stream or river.
(E) AA batteries were chosen as the device’s power source for their high energy capacity, low leakage current, and resilience to extreme temperature. Cells are wired in series in sets of 3. This comes out to 4.5V with 18 total cells.
(F) A 3D printed enclosure is waterproof and designed to be easy to install at the field.
(G) An Arduino microcontroller uses a MOSFET to switch power to the main Boron microcontroller. This reduces the device’s power consumption and extends battery life significantly.
(H) Conductivity is measured by passing a small current through two aluminum plates. When placed under the water, it can monitor relative conductivity.
Bill of Materials
3D printed body - $4.50
Particle Electron 3G - $70.00
Ultrasonic Distance Sensor - $5.00
AA Batteries x 15 - $5.50
Thermistor - $2.00
Passives, wire, hardware - $10.00
Total - $97.00
Software
The software powering the project consists of two main components: the embedded software running on the actual sensor, and the software powering the web server which receives and stores the data from the sensor and provides historical data to users.
The embedded software is designed to consume as little power as possible to extend battery life. The Particle Electron stays in a deep sleep state in between readings which are taken each hour. When the Particle wakes, it takes sensor readings at the same time that it attempts to connect to cellular data. This is so that when it does eventually establish a connection, it can immediately publish the data and return to a sleep state. The device has a software watchdog running as well. If the sensor is on for more than 5 minutes without connecting, it returns to sleep and tries again later.
The web server serves two main functions: to receive data from the individual sensor units, and to make this data available to users. To submit data to the server, a sensor unit submits an HTTP POST request consisting of a JSON string which contains the current sensor readings. The server parses this string and adds the data to a log file for that specific sensor unit. This data is then accessible from the interactive website. The website was designed to provide a streamlined user experience and easy access to historical data from all sensor units. All sensor locations are displayed on a map, allowing the user to select the desired sensor. Users can then view graphs of each of the data fields being collected by the sensor, and download JSON or CSV files containing historical data to perform further analysis.
Comments