Automated real-time data collection can be done with IEEE-488 interface

I would consult with the US Geological Survey, whether on methods, equipment or possibly contracting or cooperating with them on stream gauging studies, real time stations. If working with watershed scale, they have the Doppler equipment to measure floods efficiently. If working with small catchments, flumes, weirs, wadable streams, etc., makes measurements easier. He USGS does a great job with their real-time stations. We found that the Georgia office was very supportive and helpful when we decided to cooperate on the Upper Chattooga River site to provide near real time data and quality control. Another option might be a cooperative arrangement with a National Forest or USFS Research Station for hydrological study, sharing resources, collaboration. Some Universities have a hydrology or water resource program that might interface.

Continuing on data storage, the USGS does well and provides access. I’m primarily old school, pre-cloud work primarily, so I cannot really advise on the Cloud long term security and sufficiency, but it probably helps provide easier sharing of data. When I was studying the Chattooga River, as well as most gauged streams in North Georgia, SC, and a few other states, through time, I used Lotus 123 at first, and then converted to MS Excel. These spreadsheets provided in most instances enough space for data downloading, cleanup, converting USGS datetime to dates and time, etc. Even with the cloud these days, I would still want sufficient internal backups for data on computer as well as external hard drives. And make sure the rows and columns are sufficiently labeled or Titles or footnotes when needed.

You might want to take a look at Meter's Hydros 21 sensors (Depth, T and EC). They are linked (with cable) to a ZL-6 Datalogger, which is solar powered. Link: https://www.metergroup.com/environment/products/hydros-21-water-level-monitoring/

Like William, I'm kind of old school, too! We don't have enough of a network to bother with the complexities of integrating cloud-based data uploading and management into our work processes. And I am wary of approaches that reduce field time--that needs to be scrutinized carefully. I mean, you need to do regular maintenance on these sensors to ensure you are getting good data, particularly for collecting stream level data. Is it worth it to go this way if you need to visit these loggers for maintenance purposes, anyway? The time savings isn't worth it if it could compromise your data quality. Having said all that, we like Onset Instruments HOBO data loggers (https://www.onsetcomp.com/) for continuous monitoring loggers. Level and temperature can be measured with the same logger. They are reliable and robust and, to your needs, they seem to offer some sort of cloud-based architecture for data management and uploading (https://www.onsetcomp.com/products/software/hobolink). I can recommend the loggers--I have no experience with HOBOlink. Good luck!

Thank you all for these suggestions and insights. Peter Schaap, the Hydros 21 sensor looks very promising for near-real time monitoring and remote cloud-based data access. This is exactly the type of resource that our team is looking into. William F. Hansen, thank you for these helpful thoughts on collaborative opportunities with partner agencies, as well as the importance of data backups. A chat with those agencies would be valuable, and sounds like that approach worked well for you and your team! Christopher Victoria, I appreciate the heads up on the HOBOlink, as well as the reminder of how important it is to keep boots on the ground (maintaining instrumentation and continuing direct field observations) even as we have our heads in "the cloud." It certainly is an exciting time for water-resource monitoring with all these emerging tools!

It sounds like you're looking to transition from internally-logging instruments to a wireless, telemetered system. Your radio signals will have a range determined by radio frequency (lower frequencies, e.g., 900 MHz, are attenuated by foliage less than higher frequencies, e.g., WiFi, ~3 GHz; cellular intermediate). There are a number of commercial manufacturers who have gotten into this field, including OTT Hydromet, In-Situ, Solinst, ScadaLink, YSI, Onset and others. Our agency runs our own telemetry systems based on Campbell data loggers and Raven cellular modems sending data to our own server and database, so I can't offer any direct experience with these commercial suppliers. However, I've been a big fan of Onset, YSI, and In-Situ instruments, and I share Christopher's cautions about over-automation. (On the other hand, telemetered systems give you more or less instantaneous notice of a sensor problem). Some things to consider with "cloud" systems, however: Who "owns" the data: You or the cloud provider? What are the ongoing costs: Will you be charged by the data node, for data storage, etc.? If using cellular networks, are there ongoing "data plan" charges? Who is responsible for system setup, and repair if there are breakdowns?

Thank you Ted Swift - this is exactly what we are hoping to do. It sounds like your program offers an excellent example for us to learn from. I appreciate the suggestions, I will be looking into each of these. And the list of questions to consider with these type of systems is very important. I need to follow up to better understand the implications of data "ownership".

I'm glad my comments are helpful. I hope it's clear that the data-collection part of our process is NOT in 'the cloud'. Campbell's "Loggernet" software polls all our stations over cell phone modems into a conventional server (in the realm of radio). The polling is done from "inside" the organization, rather than letting the stations "send" data unbidden, for network security reasons: If an evil-doer stole a cell modem, we don't want them having access to our agency's internal network. The modems have fixed IP addresses, and the network only let them respond if "asked". Many issues and headaches you have to consider when you network things together. From the data server, our data goes to a database program that IS "in the cloud", in the sense that our agency's servers are "virtualized" in a big inscrutable data center, though they're OUR inscrutable servers, not a sensor vendor's server. In the database, we can do QAQC, flag and grade the data, etc. Most of the parts are based on "homebuilt" databases (think: legacy software maintenance...), rather than a commercial "turn-key" system. The nearly-raw data are also forwarded to a publicly accessible database and web interface (cdec.water.ca.gov, the California Data Exchange Center).

Depending on the scale of your network, you might be able to "do it yourself" (this presumes having in-house expertise, maintain institutional knowledge, etc., etc.). Or you could go with a "turn-key" system. You are not alone in weighing these options.

Whether you are an experienced data logger user, or just getting started, this article can help you during the data logger selection process. It outlines some of the most important considerations when choosing a data logger and offers tips on looking for specific features.

https://www.onsetcomp.com/files/data-logger-basics.pdf

follow

Thanking you for the reference on data-logger-basics.

Thank you, Brett Boisjolie, for discussing this issue. Since I live in a Himalayan region, we are still coping up to bring automated data loggers in our hydrological assessments. Usually, the systems we use are stand-alone systems that record data, which field workers manually pick up. However, in downstream areas wherein cellular networks are available, the data is continuously logged and sent to the admin while storing that in the cloud too...

Thanks