Aquametric - Cellular based stage monitors

The device uses cheap, off the shelf components to provide live data on conditions like stage, temperature and conductivity

Similar projects worth following
To make water monitoring more widespread, we developed a low cost device to provide real time data at a relatively low cost. Our sensor measures gauge first and foremost. The device is controlled by a Particle Electron 3G that enters a deep sleep of one hour between readings. Live data is posted to The widespread deployment of such a device has the potential to help both humans and natural ecosystems. Live flood prediction and early warning could save assets and even human life. Highly granular water quality measurements means that ecologists could pinpoint the source of a contaminant to a specific location or time. Say, for example, a chemical plant was dumping into the river each night. Knowing exactly when and where that was occurring would be the first step in stopping the damage.


Water bodies are crucial components of almost all ecosystems and many human activities. Today, the USGS maintains the largest collection of water 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 or the ocean. 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.

A typical USGS stream guage

Water data does not have to be limited to level 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.

As climate change makes super storms and mass flood events increasingly common, water resources are becoming harder and harder to predict. The remedy is more data and analysis to provide real-time insights about water bodies. A network of low-cost and easy to install sensors would help fill the gaps in our understanding about how water bodies interact while also providing real-time alerts to flood-prone homes.



(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 15 total cells.

(F)  An ABS enclosure is waterproof and designed to be easy to install at the field.

(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



ABS Enclosure


Particle Electron 3G


Ultrasonic Distance Sensor


AA Batteries x 15




Passives, wire, hardware

3.3V to 5V boost converter$2.00
Waterproof Button$5.00
Waterproof RJ45 Panel Mount$10.00




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...

Read more »


Latest Sensor Firmware

ino - 7.50 kB - 10/05/2020 at 02:51



EasyEDA Schematic File

JavaScript Object Notation (JSON) - 31.93 kB - 10/05/2020 at 02:50



(Old Sensor Version) The batteries and microcontroller live here. The wires that run outside of the sensor are to be potted with epoxy.

Standard Tesselated Geometry - 619.81 kB - 04/10/2020 at 22:57



(Old Sensor Version) The ultrasonic sensor is epoxied into the hole.

Standard Tesselated Geometry - 180.65 kB - 04/10/2020 at 22:57



(Old Sensor Version) This is epoxied to the main sensor body. The pcb antenna is attached on the inside.

Standard Tesselated Geometry - 194.52 kB - 04/10/2020 at 22:59


View all 6 files

  • 1 × Particle Electron 3G and antenna (Mouser, Digikey) Particle Boron 3G or 4G should work as well, but check to make sure sleep functionality is available
  • 1 × JSN SR04T-2.0 Ultrasonic Sensor (Ebay)
  • 1 × 100k Thermistor
  • 5 × 3 AA battery holder and batteries (Ebay)
  • 1 × ABS enclosure (3.9"x5.9"x2.8") Amazon

View all 8 components

  • Improving Data Visualization

    Rohan Menon10/17/2020 at 18:19 0 comments

    Our website ( is where data from our sensor network is logged. The flask server accepts requests from our sensor and stores them centrally. It also hosts a front end that allows a user to look at current and historical conditions from that unit. Currently, the graphs are generated by the backend on each page load by matplotlib.

    We recently added a graph preview to the main info screen that shows the past week of stage, temperature and conductivity data.

    We also added the ability to adjust the data range with a slider on the sensor detail page.

    Our next step will probably be switching to dynamically generating the graphs on the front end so they are easier to analyze and can adapt to various screen sizes.

    Additionally, the ability to graph other data alongside the water data might reveal insights about how things like rainfall affect conditions. Right now, downloading a CSV of the full data is how we do this.

  • Real time data for all!

    Rohan Menon10/05/2020 at 03:29 0 comments

    In Upstate NY, we have been relatively confined to measuring data on our local streams and rivers. But climate change has no boundaries. As situations unfold across the globe, putting millions of people and ecosystems at risk, we can't help but wonder: What could be different with faster and more plentiful data? ConservationXLabs highlights the urgency for better marine ecosystem monitoring, an area that is much less understood today by scientists. Measuring marine environments would likely require some ruggedizing of our device, but many of the same sensors we use in freshwater would carry over.

    As wildfires unfold across the globe, we wonder what kinds of sensors could help predict and slow their spread. We have been thinking about measuring things like humidity, temperature, wind direction and wind speed (We like the name Pyrometric). We imagine that these would be able to aid in the prevention, prediction and fighting of forest fires.

    Our project has shown us how interconnected the natural world is. We hope that our device can aid in understanding of how various parts of the environment affect each other as a step towards limiting the impact humans have on our natural world.

  • New Sensor Deployed

    Rohan Menon10/03/2020 at 22:08 0 comments

    We have been working on designing and releasing our next sensor version. This one focuses on using more readily available parts and being more versatile depending on the situation in which it is deployed.

    To read more about this sensor's design and some rough steps to create your own, visit our new guide at Keep in mind this is still very much a work in progress, so some of the pages may not be complete.

    We were planning to install our sensor via a single aluminum rod hammered into the stream bed. When we reached the stream, we realized that this plan was not going to work. The stream bed was extremely rocky. No amount of hammering was going to mount the rod securely enough.

    We settled on mounting the sensor to a tree overhanging the stream. Zip ties were used to secure the main device and auxiliary sensor cables to the log. While it may look crude, the sensor is very securely mounted, probably better than many of our other solutions.

    In fact the tree mounting has a slight advantage over our other options. Since, there is no mounting parts that enter the water, there is very little for debris to collect around, so we expect to get more stable stage readings from it.

    It has only been installed for a week now, but we have already seen some promising data. This shows the stream recovering to normal levels over a few days after a heavy rain.

  • Methods of Measuring Velocity

    Rohan Menon09/11/2020 at 13:16 0 comments

    While stage height can provide useful data to help predict flood events or other localized events, it is sometimes not enough to be able to quantitatively measure how one water body will interact with another.

    The flow rate can provide this data, but in order to measure it, you need to know a) the cross section of the stream, b) the height of the water flowing through that cross section, and c) the velocity of the water. Our device directly measures the height of the water and we did a project log on getting the cross section of a stream. We thinking about two different approaches.

    1. Infer It

    This is where the installer of the device would measure the average velocity manually when the stream is at a variety of different water levels to correlate the two. In theory, there's only one water velocity for a given water level. The installer could come to the stream a number of times (e.g. when the stage is 5 cm, 20 cm, 50 cm and 1 meter) and measure the velocity with a propeller based current meter. At that point, a unique expression that correlates velocity and stage could be created for the stream.

    2. Measure it on device

    Measuring the velocity in real time reduces the number of times an installer has to visit the device location, and it may provide new insight that we wouldn't gather from the first option. The most obvious way to do it is with a propeller based current meter. However, if we've learned anything from this project, it's that debris will find its way into anything open to it. Shrouding it in some sort of case is an option, but in general we would like to keep the device free of moving parts.

    We're also thinking about finding the velocity indirectly. By measuring the drag force that an object feels in the water, we should be able to calculate the velocity. We imagine a small load cell mounted near the base of the sensor with a plate mounted to its other end. This study appears to be doing a very similar thing in a lake.

    There is actually a phenomenon that isn't fully addressed by any of these methods. The velocity of water in a stream varies from near 0 at the stream bed to its maximum on the surface. The cross section looks something like this.

    Figure B-1. Stream velocity distribution: A cross-sectional view with... |  Download Scientific DiagramMeasuring velocity like this in real time is probably out of the question for our sensor's budget. Maybe if this kind of measurement was taken once, we could use the height to infer the velocity. However, even one manual analysis like this is costly and labor intensive.

    Neither of us are environmental science experts (or engineering experts for that matter), so we would love any feedback that you might have.

  • More Robust Hardware Alternative

    Rohan Menon09/02/2020 at 15:16 2 comments

    I've been working on an alternative sensor version for areas where natural conditions or people are likely to damage the device. The idea of a fully enclosed PVC sensor design came from my mentor session with Bruce Dominguez. While this design will be harder to install, it will be much more resilient to damage.

    Currently I am working on modeling up the new design in fusion and creating a new BOM. I want to make sure all the parts are still easy to find and relatively low cost. My main concerns with the design are the buildup of debris that may occur at the holes in the PVC and the potential for ultrasonic signals to bounce around inside the chamber before making their way back to the sensor, skewing readings. The only real way to test these things is by actually building a prototype of the device.

  • Sensor Vandalized

    Rohan Menon06/19/2020 at 15:30 0 comments

    We expected that at some point, someone would want to know about our sensor or want it removed (even though we received permission to mount the sensor), and that is why we provided contact information directly on the device.

    We did not expect, however, that someone would want to destroy our sensor just for the heck of it.

    We arrived at the stream to find most of the actual device missing. The mounting pole was still in the ground, but all that was mounted to it was a section of the sensor body, broken off from the rest of the device.

    We noticed that the temperature and conductivity sensors were still attached to the pole. They join the main sensor body through a waterproof connector. This end of the connector appeared to be in good condition, telling us that someone deliberately disconnected it to take the device.

    We don't think the device was removed by an authority because we imagine they would have either used the contact information to let us know or removed the whole device in one piece rather than leave most of it behind.

    We're not really sure what led this person to destroy our device, but it doesn't seem like they had a good reason.

    We looked around for any remnants of the sensor for a bit but didn't find anything. Even if the sensor was left close to the stream, we know that it is no longer communicating via cellular. By now, it's likely full of water thanks to the hole that was created when it was broken off its mount.

    Going Forward

    When Ian and I were first designing this sensor, we looked at the huge metal and wood structures used by the USGS and discussed how we would make something smaller, cheaper, and more accessible. As we've worked on this project, it has become increasingly clear why their sensors are the way that they are. While our sensor was not making measurements that people relied on, the experience has shown us that the barrier to in-field data collection may not be the technology.

    Granted, our sensor wasn't in a particularly hidden location, but citizen science shouldn't have to be hidden. Nevertheless, I am now working on developing a new version that is much more discrete (possibly under the surface of the water) to prevent this sort of thing from happening.

    Maybe we're missing something, or maybe you have some insight as to how to avoid these problems moving forward. Either way, your thoughts are appreciated.

  • Stream Cross Sectional Analysis

    Rohan Menon05/22/2020 at 18:32 0 comments

    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.

  • Sensor Submerged

    Rohan Menon04/28/2020 at 22:30 0 comments

    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.

  • OTA updates and editable measurement frequency

    Rohan Menon04/24/2020 at 15:42 0 comments

    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.

  • Quirky sensor data

    Rohan Menon04/23/2020 at 21:44 0 comments

    Recently, we visited the sensor and did some in-field fixes to the thermistor. The temperature now seems to be sending back sensible readings now and we can see the day night cycle in the stream temperature pretty well. Our conductivity sensor, on the other hand, is behaving pretty strangely.

    It also shows a daily cycle in readings, closely aligned to our temperature readings. Our conductivity sensor is simply two aluminium plates (1.5 cm x 1.5 cm) held about 1.5 cm from each other. The units on our conductivity sensor currently has no real meaning. The values from the voltage divider are simply scaled between 0 and 1 for the time being.

    We are also noticing that our sensor seems to wake up twice within 5 minutes every day around midnight or 1:00 am. Our sensor doesn't keep track of time on the device, so this is a pretty weird fault and it appears to be affecting our battery voltage and conductivity. The sensor should never really wake up twice like that, so it leads us to believe that the device has trouble connecting around that time and does it twice.

View all 12 project logs

Enjoy this project?



Emach00 wrote 09/11/2020 at 16:38 point

I wonder if you can use the 3G modem to get relative location off the tower(s) it is connecting to. Then have it phone home its relative location and sound a big old piezo buzzer. 

  Are you sure? yes | no

Rohan Menon wrote 09/12/2020 at 00:03 point

Thats a cool idea, but to preserve battery, we only have it turn on every hour, so it might not be in time. Maybe in combination with an accelerometer...

  Are you sure? yes | no

EK wrote 09/11/2020 at 01:55 point

That's a bummer that one of your devices was vandalized. Cool project, and keep up the good work  👍

  Are you sure? yes | no

Bill Knight wrote 04/15/2020 at 18:26 point

You might consider either the Particle Boron or the pycom GPy board for a future iteration.  Both offer LTE CAT-M1 cell modems.  NB-IIoT & LTE CAT-M1 cell services are much lower in cost than 3G.  Also the modems operate at lower power and have longer range than 3G versions.  The small amount of data your project requires makes them a good option.

  Are you sure? yes | no

Rohan Menon wrote 04/15/2020 at 21:35 point

Funnily enough, we started with a Boron LTE. At least for our area, LTE was not reliable enough to send readings consistently. I would be interested in trying out some other cheaper cellular boards however, as we're trying to drive the total device cost down.

Right now, we are using Hologram for our sim and for our amount of data it has been a very good option price wise.

  Are you sure? yes | no

Bill Knight wrote 04/16/2020 at 12:29 point

When the time is right, the pycom GPy board can be found for under $60.  The ESP32 processor can be put into deep sleep between readings and woken up via an internal counter.  IIRC there's also a 32KHz RTC.  Don't recall the specifics about powering down the LTE modem when not in use.

  Are you sure? yes | no

Mike Szczys wrote 04/13/2020 at 16:47 point

Fascinating bit about the unexpected conditions once version 3 was deployed. I thought at first the river had risen to completely cover the sensor. I'm surprised the build-up of debris happen s that quickly!

Nice use of the SR04 sensors. As you mentioned in another comment, these are automotive grade -- they'll hold up but elements but even better their widespread use means they're inexpensive and will be available for a long time.

Great project!

  Are you sure? yes | no

Rohan Menon wrote 04/14/2020 at 15:15 point

Yeah, we were surprised as well. In our last deployment, we tried adding a debris fin behind the pole to divert leaves and sticks around the senor. They are typically used to prevent debris buildup on bridge piers, but we're hoping that it has a similar effect on our sensor pole.

  Are you sure? yes | no

Daniel wrote 04/11/2020 at 07:54 point

Cool project.

But, I think you may be better off using the capacitive method for measuring the water level. These ultrasonic distance sensors don't seem to be too robust and I don't think they'll last very long in rough outdoor environments.

  Are you sure? yes | no

Rohan Menon wrote 04/11/2020 at 11:57 point

Interesting thought. I believe this is the same model of ultrasonic sensor found in car backup sensors, so we assumed it would hold up. Its epoxied into the sensor body to hopefully prevent leakage. However, we've only had this new sensor in the field for a week now so maybe its a matter of time

  Are you sure? yes | no

Tom wrote 07/01/2020 at 21:12 point

I have been trying to get the capacitive level thing working for small stream monitoring, with the TI FDC1004. Works ok but can't get the out of phase measurement working so changes a lot with interfering objects. Do you have any experience with them?

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates