RTDAS explained: architecture, network design and data quality for real time hydromet monitoring

RTDAS, the real time data acquisition system, is how India's water agencies describe a telemetered network of river, rainfall and weather stations that report to a central server. It is a system in the full sense: sensors, loggers, communication links, servers, quality control, and the people and procedures that keep them working. Under the National Hydrology Project, the Government of India has planned RTDAS for river basins as a step towards a hydrological information system, with automated rain gauge stations, automated river gauge stations and automated reservoir monitoring, using INSAT, GSM and GPRS links to relay data in real time [1][2].

This article looks at an RTDAS as an engineering system: its layers, how to place stations and choose reporting rates, where the errors come from, and why networks fail.

The layers of an RTDAS

 SENSE            ACQUIRE          COMMUNICATE        INGEST & STORE      PROCESS            USE
 radar level  ─┐                                       time-series DB     QA/QC flags       alerts, thresholds
 velocity radar├─► data logger ─►  GSM / LoRa /   ─►   + raw archive  ─►  derived values ─► dashboards, maps
 rain gauge   ─┤   (sampling,      satellite           (MQTT / HTTPS)    (rain totals,     reports, open API
 weather      ─┘    averaging,      store & forward                        rate of rise)    forecast models
                    alarms)

Sensors: what each station type contributes

River level (AWLR). Stage is the primary variable. A discussion of how the sensor type affects accuracy is in our article on radar, ultrasonic, float and pressure sensors. The point for network design is that stage error translates into discharge error through the rating curve, as ΔQ/Q ≈ b·Δh/(h − h0), and is worst at low flow.

River velocity (AWVLR). Adds surface velocity. Radar measures the Doppler shift of the signal scattered from short surface waves, and the WMO Manual states that some surface roughness must be present, generated by turbulent boils, wind or rain [3]. To convert surface velocity to mean velocity, a coefficient of about 0.85 is commonly used [3], and field studies of surface velocity radars recommend site-specific calibration, reporting discharge within about 10 % for low and intermediate roughness flows when a calibrated coefficient is used [6]. Discharge also needs the channel cross-section, which is a survey, not a sensor reading. See can radar measure river discharge.

Rainfall (tipping-bucket rain gauge). Each time a small bucket fills it tips and the logger counts one pulse. With a resolution of 0.25 mm per tip, the intensity is:

intensity (mm/h) = 900 / (seconds between tips)         [for 0.25 mm per tip]

At 10 mm/h the bucket tips every 90 s, at 50 mm/h every 18 s and at 100 mm/h every 9 s. Two properties follow from counting tips:

• Quantisation. Rainfall is reported in steps of 0.25 mm. A 5-minute total can only be 0, 0.25, 0.5 mm and so on, so the smallest non-zero 5-minute intensity is 3 mm/h. A 1-minute window can only show steps of 15 mm/h. Choose the reporting window for the use, or compute intensity from the time between tips.
• Systematic errors. Tipping-bucket gauges under-read in very heavy rain because some water is lost during the tipping movement, and every catching gauge under-reads in wind, because the gauge itself distorts the airflow above the orifice. The WMO instrument-intercomparison literature notes that the extent of wind undercatch depends on wind speed, drop-size distribution and rainfall intensity, so it is site and season dependent [7]. In one field comparison reported at a WMO instruments conference, an identically calibrated straight-sided tipping-bucket gauge recorded about 15 % less rain than an aerodynamically shaped one over the same period [7]. A typical manufacturer accuracy specification is a few percent at a stated intensity, for example ±5 % at 50 mm/h, and is a laboratory figure, not a field one.

Weather. Wind, temperature, humidity and pressure add context, and wind is the variable that most affects the rain gauge reading.

Where do the stations go?

The WMO Guide to Hydrological Practices gives minimum densities for hydrometric networks that depend on terrain. As commonly cited they are on the order of 1,000 km² per streamflow station in mountainous regions, about 1,875 km² for interior plains and hilly regions, and 2,750 km² for coastal areas, with much sparser networks in arid and polar zones [8]. These are minimum densities for general water-resources assessment. A flood warning network needs more stations, concentrated on the places where decisions are made.

A practical way to plan:

1. Start from the decision. Who needs to act, where, and how much time do they need? That sets how far upstream the first sensor must sit (see how a flood early warning system works).
2. Level stations at the outlets of sub-catchments, at confluences, above and below reservoirs and at the places where the river is already gauged, so new data joins a long record.
3. Rain gauges across the catchment, with extra gauges at high elevations where storms form and at the heads of fast-responding sub-catchments.
4. Weather stations where wind, temperature or humidity add real value, and at a few reference sites.
5. Redundancy. At key sites, two sensors or a second gauge reading, so a fault is detected by disagreement.

Rain and level answer different questions. Rainfall tells you the input, and how much time you have before the river responds. Level tells you the response. A network with both gives an operator the lag between them, which is the useful quantity.

How often should a station report?

Three intervals are independent, and designers often confuse them:

• Sampling interval: how often the logger reads the sensor.
• Averaging window: the burst over which it averages to suppress noise.
• Reporting interval: how often it sends a message.

A common pattern is to sample and average within each interval, log every 5 to 15 minutes, and report at the same rate in normal conditions. When a threshold on level or rate of rise is crossed, the station switches to a faster interval and sends immediately, and does so by itself, without waiting for the server. The reason is the arithmetic of rising water: at a rise of 1 m in 10 minutes, a 15-minute interval means the level changes by 1.5 m between readings, and a 60-minute interval by 6 m.

The Central Water Commission's field manual states the same principle for manual gauging: the greatest frequency of observation is required when the level is changing rapidly in response to rain, especially on small catchments in the monsoon, and in rapidly changing flows the maximum can exceed the highest recorded hourly level [4].

Communication: latency, reliability and data volume

Data volume is small; reliability is the problem. 100 stations reporting every 5 minutes produce 28,800 messages a day. At about 60 bytes each that is under 2 MB a day. A cellular plan is not the constraint. The constraint is whether each station's message gets through during the storm.

Latency budget. The time from the water level changing to an alert reaching someone is the sum of:

T_alert = T_sample_wait + T_processing + T_connect_and_send + T_server + T_notify

With a 5-minute reporting interval the first term alone averages 2.5 minutes and reaches 5 in the worst case. That is why alarm logic runs on the device and urgent messages bypass the schedule.

Link choice. GSM covers most sites. In valleys without coverage, a local LoRa network with a cellular gateway, or a satellite link, is the usual solution, and hybrid LoRa and cellular architectures are widely used for remote catchments [9]. India's RTDAS programme combines INSAT satellite telemetry with GSM and GPRS links [2].

Store and forward. A logger must keep readings during an outage and send them in order on reconnection. 30 days of 5-minute readings is 8,640 records, a trivial amount of memory. The server must accept late data without treating it as new.

Time. Every record carries a timestamp from a synchronised clock. A drifting clock makes it impossible to compare stations or to know when a rise began.

Data model, exchange and open access

Store time series as (station, parameter, time, value, unit, quality flag). Keep the raw value and derived values separately. For exchange between agencies, standards such as OGC WaterML 2.0 exist for hydrological time series. On the sensor side, SDI-12 and Modbus are common wired protocols, and on the network side MQTT suits intermittent links. Open interfaces matter because a hydromet network usually has to feed several users, and a system locked to one screen is difficult to leave.

Quality control: flag, never delete

QA/QC turns readings into a record you can defend. Automated rules should flag, not remove:

For rain gauges, a blocked funnel is the classic hidden fault: the station reports zero while neighbours report rain. Regular visits, a field check with a known volume of water, and spatial consistency checks catch it.

Why networks fail, and how to design against it

The most common failure of a telemetry network is not a design flaw. It is that stations stop working and no one notices. An audit by the Comptroller and Auditor General of India's flood forecasting scheme, as summarised by PRS Legislative Research, found that as of August 2016 only 56 of 219 planned telemetry stations had been installed, and that 59 % of the existing telemetry stations were non-functional, leaving no real-time data for the corresponding periods [5].

Design against this from the start:

• Remove maintenance. Non-contact sensors, solar power and no consumables mean fewer reasons to visit.
• Monitor the monitors. Every message carries battery voltage, panel current, signal strength and temperature, and the server raises a ticket when a station goes quiet.
• Define service levels. Availability of 95 % means about 18 days of missing data a year; 99 % means about 3.7 days. Decide which you need and measure it.
• Plan spares and response times as part of the contract, not an afterthought.

From data to action

The server turns a stream of readings into decisions: threshold alerts on level, rate-of-rise alerts, rainfall accumulations over 1, 3 and 24 hours, comparisons with antecedent conditions, hydrographs for each site and maps for the basin, plus reports and an interface for models. The same record that supports a flood warning also supports reservoir operation, drought assessment and, with calibration, water accounting.

Where ClimMaTech fits

ClimMaTech builds the river measurement side of an RTDAS: Tarang for water level, Pravaah for level and velocity, Doordrishti for camera verification and on-device detection at critical sites, and the logger and DeviceCloud software that bring readings into one record. Rain gauges are part of the same network, and our own weather station is planned for later. Where a client needs one now, a partner can supply it. All our devices work from -40 °C to +70 °C and report over GSM (2G / 3G / 4G), with LoRa and other options by site. See the RTDAS and hydromet telemetry solution or read the guide to specifying a station.

References

1. World Bank, National Hydrology Project (project P152698). projects.worldbank.org.
2. Water Resources Department, Nagaland, National Hydrology Project: RTDAS components (automated rain gauge, river gauge and reservoir stations with INSAT and GSM/GPRS telemetry). wrd.nagaland.gov.in.
3. World Meteorological Organization, Manual on Stream Gauging, Volume I: Fieldwork, WMO-No. 1044 (2010), sections 8.9 and 8.10. WMO publication page.
4. Central Water Commission, India, Gauge and Discharge Measurement Field Manual. cwc.gov.in.
5. PRS Legislative Research, CAG report summary on schemes for flood control and flood forecasting. PRS India.
6. Field assessment of noncontact stream gauging using portable surface velocity radars (SVR), Water Resources Research (2016). HAL.
7. M. Pollock, Accurate rainfall measurement, WMO Technical Conference on Meteorological and Environmental Instruments and Methods of Observation (TECO-2014). WMO.
8. World Meteorological Organization, Guide to Hydrological Practices (WMO-No. 168), hydrometric network density. WMO hydrology publications.
9. Water level monitoring using LoRa and cellular gateways in remote areas (conference paper). Atlantis Press.

Worked numbers are computed from the stated relations and illustrate the size of each effect. Station density values are the commonly cited WMO minimums and should be checked against the current edition of the Guide.