Deploying open-architecture infrastructure for critical zone monitoring: lessons from the environmental sensing and data network

1 Introduction

1.1 Scientific context and history

Understanding and managing Critical Zone processes—the coupled interactions between the atmosphere, soil, surface water, and groundwater—under growing climate and anthropogenic pressures requires high-resolution environmental data across wide spatial and temporal scales (Berdugo et al., 2022). Historically, this challenge has been addressed by establishing long-term Critical Zone Observatory programs and stations designed for interdisciplinary, process-based monitoring (Brantley et al., 2017). Capturing the dynamics of coupled environmental systems at these sites demands a coordinated approach to obtaining dense, continuous, and multi-parameter observations.

In coastal regions, for example, Helton et al. (2025) note that seawater intrusion occurs through complex, interdependent hydrologic pathways: over land via storm surge, under land via groundwater transport, and through coastal channels that facilitate bidirectional salt transport. A single storm surge, flood event, or saltwater intrusion episode can, therefore, unfold over just a few hours or over many months (e.g., Manda et al., 2013). Yet, episodic manual sampling and periodic data-logger retrieval are incapable of resolving these processes at the timescales that govern them (Rode et al., 2016) or delivering the real-time insight needed to respond as they occur. Furthermore, field maintenance of stand-alone monitoring sites is inherently cumbersome, with troubleshooting in harsh, remote conditions highly impractical and prone to human error, particularly when a regular rotation of research staff and students limits the retention of long-term institutional knowledge. The resulting gaps in data must then be addressed through labor-intensive post-processing to attempt to reconstruct missing logger data (Turrado et al., 2016) under the threat of permanent loss of valuable records (Skålvik et al., 2023).

The potential of wireless sensing networks (WSNs) for Critical Zone monitoring has been recognized for decades (Hart and Martinez, 2007; Rundel et al., 2009). Early environmental WSN frameworks emphasized key deployment bottlenecks, including power management, usability, standardization, data quality, security, data mining, and sensor development, that constrained practical field adoption (Hart and Martinez, 2007). Many of these issues have received attention, with much innovation occurring in recent years across a variety of application areas. For example, Zhao et al. (2024) leveraged Long Range Wide Area Networks (LoRaWAN) to address power and data transmission limitations in soil moisture monitoring for stormwater management. Machine learning has been leveraged to improve data quality control (Schmidt and Kerkez, 2023), optimize sensor placement (Oh and Bartos, 2025), and increase energy efficiency (Manchanda et al., 2026). In addition, many studies have developed or deployed new, low-cost, or off-the-shelf network components in, for example, sediment transport (Langhorst et al., 2023), oceanography (Thaler et al., 2024), limnology (Tiberti et al., 2021), and groundwater (Venkatesh et al., 2024) studies.

1.2 The bottleneck

Despite the advances in WSNs and a movement toward integrating fragmented sensing deployments into unified, cloud-based “Environmental Internet-of-Things (IoT)” platforms (e.g., Hart and Martinez, 2015), Kazem et al. (2025) point out that “simple data logging remains widely used in [critical zone] observatories, when specific sensors are not available... but also because observatories are built in an incremental and ad-hoc manner.” A lack of standardization and simple ready-to-deploy technologies that avoid vendor lock-in ultimately reduces the interoperability of components throughout the network—from sensors through to data management and user accessibility (Hart and Martinez, 2015). Commercial sensing solutions have emerged that may operate effectively within their own proprietary system, but they often introduce expensive recurring telemetry costs or proprietary cloud subscriptions, and trap users within siloed, vendor-specific dashboards. Even when these platforms offer Web APIs (application programming interfaces), they lack standardization across vendors, requiring research teams to build and maintain custom integration scripts, or even attempt to implement their own custom IoT backend to unify the streams (Jones and Horsburgh, 2025). As a result, significant engineering effort can be spent implementing fundamental features—such as custom dashboards, automated alerts, and device management.

Open, off-the-shelf options now exist across the hardware and software components of environmental sensing networks, making it increasingly feasible to combine legacy sensors with newer instruments and software components to create a unified, though heterogeneous, architecture. In the past, building a WSN required substantial expertise to overcome complex operational challenges, for example, understanding the details and limitations of hardware and software for wireless communication, sensor-specific protocol integrations, metadata harmonization, and hardware programming, assembly, and maintenance. The standardization brought by IoT has reduced the technical barriers. The primary challenge for Critical Zone scientists today is identifying which components are available and appropriate for their specific science use case.

1.3 Scope and contribution

Sharing comprehensive documentation on the operational realities of environmental IoT networks is important for making the adoption and implementation of these systems accessible to domain-based scientists, rather than WSN experts alone. In this paper, we share our implementation of the Environmental Sensing and Data Network (ESDN), built using off-the-shelf technologies and components, along with practical feedback and lessons learned, to provide a blueprint that can help accelerate the development of similar initiatives across Critical Zone applications. We frame our approach through a four-layer IoT “stack” consisting of (i) sensing, (ii) network and transport, (iii) data management and processing, and (iv) application layers. We simplify the reference architecture to lower the barrier to adoption for domain scientists while remaining conceptually aligned with the model defined in ITU-T Recommendation Y.2060 (International Telecommunication Union, 2012), which defines analogous Device, Network, Service Support, and Application layers alongside cross-cutting management and security capabilities. Our framework intentionally consolidates these concepts into four operationally meaningful layers. We report on the current state of practice for each one of these layers, describe the specific implementation and performance details for the ESDN, and discuss recommendations for future implementations. This paper aims to help application-focused scientists evaluate opportunities and constraints across the sensing stack as they build heterogeneous WSNs for Critical Zone research.

The remainder of this paper is structured as follows. Section 2 presents our conceptual framework, outlining the four-layer sensing stack that forms the basis of environmental IoT networks. Section 3 details the practical implementation of the Environmental Sensing and Data Network (ESDN) across these four layers. Section 4 discusses the results of our deployment, highlighting key lessons learned and network performance. Finally, Section 5 provides concluding remarks.

2 Conceptual framework

2.1 The four-layer sensing stack

Modern IoT architectures have matured to a state of high interoperability through standardized and open communication protocols across the network from the physical sensor to the cloud. Hardware and software are more practical to deploy and operate in WSNs today than at any point in the past. For terminological consistency throughout this paper, we use four distinct terms. A sensor is the sensing device that measures the environmental variable. A control interface is the hardware that reads one or more sensors and stores or transmits data (e.g., a data logger or communications module). A sensing node is the field assembly of a sensor and a control interface. A hardware gateway is the local network equipment in user-managed architectures (e.g., LoRaWAN) that receives wireless radio transmissions from sensing nodes, translates them to Internet Protocol, and routes them to a centralized server via an internet backhaul. While software gateways perform similar logical bridging functions between networks, we focus exclusively on hardware gateways to abstract complex IT concepts for our target audience. For brevity, we refer to these simply as gateways throughout the remainder of this paper.

While alternative WSN architectures exist, we guide our discussion using the simple stack shown in Figure 1 with (i) sensing, (ii) network and transport, (iii) data management and processing, and (iv) application layers. A description of each layer is given in Box 1, with additional details in Supplementary Table S1. The following sections use this framework to organize a layer-by-layer discussion from sensing through application.

A brief overview of the sensing stack.

Sensing layer: comprises the sensing nodes deployed to measure critical zone parameters in the field. At this level, whether using analog or digital sensors, environmental data is acquired and staged for downstream systems. In some WSNs, nodes in this layer may also utilize on-device storage and computation to parse raw signals (e.g., extracting key features or triggering thresholds) prior to transmission.

Network and transport layer: consists of the complete data pathway required to bridge the gap between the field and the data collection backend, ensuring the reliable and efficient transmission of remote observations. This infrastructure spans the wireless interface used for sensor uplinks, the local gateway hardware that receives these signals, and the backhaul mechanism (e.g., Ethernet, LTE, Wi-Fi, or satellite) that securely routes the telemetry to cloud services. It manages traffic-level operations, such as protocol translation, payload batching, and packetization.

Data management and processing layer: serves as the centralized backend for short- and long-term storage, post-processing, and metadata management. It handles the ingestion of incoming telemetry from the network and transport layer, rule-based processing and message routing, automated per-sensor validation (QA/QC), and secure archiving of data following FAIR practices (Wilkinson et al., 2016).

Application layer: provides the user-facing interfaces and advanced capabilities needed to interact with and interpret the collected data. This layer features interactive visualization, dashboards, advanced analytical tools, programmatic access via APIs, and integrations for external modeling or decision-support platforms.

2.2 The sensing layer

The sensing layer is the foundational interface of any environmental monitoring network, serving the primary purpose of measuring physical Critical Zone conditions and processes and converting them into analog or digital signals for downstream ingestion. There is a wide range of sensors available to monitor an equally wide range of environmental parameters; we therefore leave this broad scope to existing reviews (e.g., Rundel et al., 2009; Moysey, 2021; Bogena et al., 2022; Madsen et al., 2025; Abdulhussain et al., 2025). The defining characteristic of an IoT sensor is its connectivity rather than a breakthrough in measurement technology.

Most modern environmental sensors ultimately output a digital signal, even if they natively make an analog measurement. Long-established industry standards support digital communications between devices, through physical interfaces (e.g., RS-485, RS-232), communication protocols (e.g., Modbus), and unified standards that define both (e.g., USB, SDI-12), enabling the seamless integration of arbitrary sensors with control devices like data loggers or communication modules. Consequently, many research-grade instruments from established vendors (e.g., METER Group, Pullman, WA, USA; Campbell Scientific, Logan, UT, USA; etc.) support these standards, allowing them to become interoperable sensing units within larger, heterogeneous networks.

Practitioners may therefore select sensors primarily for their ability to meet scientific objectives, with their ability to integrate into a broader network being an afterthought. While unique deployment environments may introduce specific hardware constraints, this strategy remains viable; today most environmental sensors can be seamlessly integrated into WSNs through cost-effective control interfaces. Because of this standardization, WSNs can also incorporate more affordable sensors designed for generic industrial applications. There is also an increasing number of true “off-the-shelf” sensors that come with integrated communication modules (e.g., Zigbee Connectivity Standards Alliance, 2023, Matter Connectivity Standards Alliance, 2026, LoRaWAN LoRa Alliance, 2024, or cellular IoT options such as LTE-M and NB-IoT), effectively combining sensing and data transmission within a single unit and reducing or eliminating the need for a separate control interface in basic deployments. Adoption of devices that have not been designed and tested for environmental settings means that additional work is required to evaluate their accuracy, reliability, and robustness under field conditions. As the use of these sensors in the environmental field grows, the validation burden will decrease as trusted sensors are identified over time and algorithmic data validation allow for the improved detection of faulty devices (e.g., Schmidt and Kerkez, 2023).

2.3 The network and transport layer

Building a scalable, multi-site environmental sensing network requires a telemetry backbone that balances transmission range, power consumption, and hardware interoperability (Mekki et al., 2019). The network and transport layer serves as the critical bridge between the field and the cloud, including the on-site hardware that sends sensor and telemetry messages to a centralized database, typically via the internet or dedicated communication gateways (Hart and Martinez, 2015). This layer encompasses the complete data pathway: the efficient wireless interface used for sensor uplinks, the local gateway hardware that aggregates them, and the critical backhaul mechanism (e.g., Ethernet, LTE, Wi-Fi, or satellite) that securely routes the collected data to the database.

Traditionally, the Network and Transport Layer in environmental monitoring has been engineered as a highly fragmented, parameter-specific architecture. As Hart and Martinez (2015) describe, scientists frequently rely on data logger-based systems with little or no network connectivity. The infrastructural reality of current environmental monitoring is starkly quantified by Kazem et al. (2025), whose survey of 34 European observatories revealed that over 26% still rely entirely on standalone data logging, while less than 9% have successfully networked all their sensors. This persistent reliance on legacy hardware results in acquisition latencies averaging 71 days for manually logged sites and failure detection delays exceeding 100 days (Kazem et al., 2025). In contrast, a fully connected IoT system ensures that telemetry is automatically collected, stored, merged, and visualized with minimal effort, fundamentally replacing what has historically been a highly manual, human-intensive workflow across every step of the data pipeline.

Modern IoT systems aim to replace isolated data loggers with WSNs that automate the data transmission process (Figure 2). In these sensing architectures, physical topology and infrastructure ownership are inextricably linked and depend on whether researchers manage the local network themselves or rely on commercial providers. User-managed networks offer topological flexibility because the deploying organization owns and maintains the receiving infrastructure. Field networks typically utilize a single star topology (Figure 2, Single Star Network), where nodes transmit directly to a central gateway. To improve resilience and range, researchers can deploy an overlapping star configuration (Figure 2, Overlapping Star Networks), or adopt a wireless protocol that supports mesh topology (Figure 2, Mesh Network), where sensors wirelessly relay data between each other until reaching a gateway. In all user-managed configurations, coverage is geographically bounded by the local hardware, and the organization hosting the hardware usually provides the internet backhaul.

WSNs can also rely on third-party-managed networks, such as commercial cellular, direct-to-satellite links, or commercial LPWANs (e.g., Sigfox). Nodes connect directly to a provider's macro-network, removing any burden on local infrastructure building. However, operating strictly as a client introduces inherent vulnerabilities. The physical infrastructure is completely abstracted; practitioners rarely know the exact location of receiving antennas or their true radio coverage. This blind reliance on commercial operators complicates troubleshooting when isolated nodes drop offline, while also introducing recurring financial costs.

Finally, hybrid networks (Figure 2, Hybrid Network) optimize deployment logistics and costs by integrating flexible topologies and leveraging the most appropriate technology on a case-by-case basis. For example, researchers might start a WSN by relying on third-party cellular infrastructure and immediately start gathering data before establishing a field network. Upon establishing a user-managed field network, older sensor nodes can be transitioned to control interfaces built for the local telemetry protocol, eliminating dependency on commercial backhaul and its associated recurring fees. This phased approach balances the rapid scalability of commercial networks with the long-term efficiency and topological flexibility of user-managed architectures.

Different networks leverage wireless technologies optimized for specific constraints. For example, short-range protocols (Zigbee, Wi-Fi) suit dense, localized deployments, whereas cellular IoT (LTE-M, NB-IoT) provides direct, regional internet connectivity. For remote, battery-powered monitoring, LPWAN technologies (LoRaWAN) offer the best balance of transmission range and energy efficiency. Crucially, these protocols can natively complement one another to overcome geographic constraints. For instance, cellular NB-IoT nodes can supplement a user-managed LoRaWAN network by linking isolated sensors hidden in challenging topography or deployed beyond the reach of local gateways. See Supplementary material (Supplementary Table S2) for a comparison of wireless technologies and examples of hardware platforms.

Regardless of the specific transmission technology selected, almost all communication standards offer both open and closed hardware ecosystems. For environmental science, where long-term deployments and constrained budgets are common, prioritizing an open ecosystem is a critical architectural decision. Closed systems restrict devices to proprietary hubs or managed vendor clouds, forcing reliance on vendor-specific APIs to access data. In contrast, an open system utilizes standard radio or IP protocols (e.g., MQTT, CoAP) to route telemetry directly to independent, user-managed infrastructure. This approach allows scientists to avoid relying on third-party paid services, maintaining full hardware ownership, and limiting the recurring fees associated with the system.

2.4 Data management and processing layer

The data management and processing layer collects, stores, processes, and retrieves sensor data streams, device records, and metadata for daily operation and long-term archiving. Infrastructure choices involve real tradeoffs. Relational databases (MS SQL Server, PostgreSQL) handle structured records, metadata, quality flags, provenance, and the relationships among sites, sensors, deployments, and derived products. Time-series extensions (TimescaleDB) or dedicated time-series databases (InfluxDB) improve throughput for high-volume telemetry, streaming inserts, and aggregation queries, though the right choice depends on scale and query patterns. When raw files, large observational datasets, or open-format archives need to be preserved, object storage or a data lake is usually more appropriate (Hai et al., 2023). Deployment decisions follow from these storage choices: data can sit on local servers, in the cloud, at the network edge (e.g., utilizing platforms like ThingsBoard Edge to process data locally before transmission), or in a hybrid setup that buffers locally and archives centrally.

Quality assurance at this layer is primarily a metadata problem. At ingestion, automated checks can validate timestamps, units, expected ranges, missing values, duplicate records, sensor status, and consistency with device and deployment metadata. Those results need to stay attached to the data as quality flags, processing levels, annotations, and provenance records that link raw, corrected, and derived observations. The Observations Data Model (ODM; Horsburgh et al., 2008) and its successor ODM2 (Horsburgh et al., 2016) were intended to address this directly; both were developed to standardize how environmental observations are stored and described, with particular attention to the contextual information needed for interpretation. ODM2 extended that foundation to support observations that are not just stored but also archivable, discoverable, and reusable across data types and cyberinfrastructure systems (Horsburgh et al., 2016). The data management and processing layer owns that foundational quality metadata and its audit trail. User-facing review, correction, approval, and visualization belong in the application layer.

Standards determine how easily sensor data can be shared and reused. The OGC SensorThings API (Liang et al., 2021) provides a data model and web API covering sensing devices, observations, locations, data streams, and observed properties, letting environmental monitoring data be ingested, queried, and served through interoperable web services. In practice, the standard's REST/JSON framework is a good foundation, but real deployments may still need domain-specific metadata, quality-control information, ownership models, and authentication on top of it. One implementation addressed this by mapping ODM metadata concepts into SensorThings structures, adding processing levels and result qualifiers to document quality-control status and data annotations (Horsburgh et al., 2025). Following established standards reduces dependence on custom schemas and one-off APIs, and makes later integration with visualization tools, GIS platforms, and data portals substantially easier. Full compliance is not always feasible, but aligning internal data models with common standards early on is far simpler than retrofitting later.

Recent surveys find that sensor network deployments increasingly favor scalable pipelines and tighter architectural integration over older siloed, logger-centered workflows, even if fragmented approaches remain common in practice (Trigka and Dritsas, 2025; Kazem et al., 2025). Systematic reviews of IoT networks in aquatic monitoring reach the same conclusion: cloud and edge integration is now central to handling continuous, heterogeneous environmental data streams (Cohen-Manrique et al., 2025). Platforms that handle these demands well share a few properties: reliable connectivity, real-time ingestion with automated validation, standards-aligned data modeling, and access controls that hold up through long-term archival.

2.5 Application layer

The application layer serves as the critical interface between the processed environmental telemetry and end users, transforming aggregated observations into scientifically interpretable information for multiple use cases, including real-time operations, hypothesis-driven analysis, and long-term process assessment. Modern IoT application layers must extend beyond static dashboards to support dynamic rule engines, automated anomaly alerting, and analytics-oriented processing for quality screening and real-time interpretation in environmental monitoring contexts (Schmidt and Kerkez, 2023). At the platform-architecture level, they also require standardized API interoperability and integration with external services for operational workflows (Panagou et al., 2025). As environmental WSNs increasingly support multi-stakeholder initiatives spanning academic researchers, municipal planners, and community scientists, the application layer must also provide robust federated access control for secure, role-specific collaboration.

From a research perspective, platform selection should be tied to explicit criteria rather than general preference. As De Nardis et al. summarize, platform comparison should include “communication protocols, data visualization, data processing, integration with external services and security,” with installation and documentation also considered for open-source options (De Nardis et al., 2022). Translating those criteria to environmental operations, the application layer should support scientific visualization quality, usability for routine workflows, and practical personalization so dashboards, alerts, and access scopes can be adapted to distinct research questions and stakeholder roles. Beyond presentation, the core value of this layer is methodological: custom dashboards and rule-based automation can improve data coherence, completeness, and quality by standardizing metadata pathways, surfacing anomalies early, and reducing silent failure intervals (Ayele et al., 2024).

3 ESDN implementation

3.1 ESDN deployment context

Our goal for the ESDN was to deploy a flexible environmental WSN infrastructure that can be used by multiple research groups, community scientists, educators and other end-users while growing organically over time based on user needs and demands. We have now deployed ESDN at sites across eastern North Carolina for a variety of research, education, testing, and community science objectives (Table 1). These representative deployments illustrate how the same open architecture can be adapted to distinct end-use and connectivity constraints while preserving a common workflow across the WSN stack.

Table 1. ESDN deployment sites and primary purpose.

^a Euclidean distance from ECU main campus.

Figure 3 illustrates the typical physical infrastructure deployed at a specific site, where sensor nodes wirelessly transmit data to a centralized LoRaWAN gateway that forwards data to the cloud for processing, storage, and serving for use in applications. The ESDN sensing layer (Layer 1) is designed to be fully customizable, allowing each site to deploy heterogeneous instruments tailored to address specific scientific objectives. The Network and Transport layer (Layer 2) uses LoRaWAN for local sensor communications with data backhaul to the cloud adapted for site-specific connectivity constraints. In contrast, the Data Management and Processing Layer and application layers (Layers 3 and 4) are intentionally standardized and shared across all sites. This keeps data ingestion, storage, and downstream analytics coherent while minimizing the need for custom data handling across interface and sensor configurations. We actively harmonize and automate these workflows as new configuration variants are encountered in deployment. As a result, while each site monitors a distinct set of environmental process variables, all operate within the common four-layer architecture shown in Figure 1, providing flexibility in the lower layers with standardization in the upper layers.

3.2 The ESDN sensing layer

To capture diverse environmental data, the ESDN uses a hybrid sensing strategy that combines research-grade legacy sensors with lower-cost industrial IoT alternatives. To date, the network has integrated 28 distinct sensor types, 5 gateway models, and 7 different control interfaces (a complete list of the hardware employed is provided in Supplementary Table S4). Core deployments emphasized hydrologic and meteorological monitoring, including: soil moisture and matric potential probes (TEROS 12/21, METER Group), CTD instruments (HYDROS 21, METER Group; CTD-206, Daxin, Dongguan, China), water-level sensors (Dragino PS-LS pressure transducers; LDDS75-LS acoustic distance measurement units, Dragino), and weather stations (WSC2, Dragino; RainWise units, Boothwyn, PA, USA). To evaluate the system's extensibility for community-engaged science, we also opportunistically deployed auxiliary sensors to monitor flood occurrence, air quality, light pollution, and indoor temperature. We have also used analog signals to monitor the battery health of field systems. Though we have successfully integrated all of the instruments in Supplementary Table S4 into the ESDN, we have focused most of our sensor validation and quality control efforts on the hydrologic sensors used for research applications.

Rather than replacing existing research-grade field sensors, we prioritized retrofitting our existing fleet with LoRaWAN-enabled control interfaces to integrate them into the ESDN stack. Legacy instruments, primarily TEROS and HYDROS lines from METER Group, were integrated by replacing their commercial ZL6 data loggers predominantly with Dragino SDI-12-LB/LS control interfaces, but also Milesight UC501 units (Milesight Technology, 2024), leveraging their native SDI-12 compatibility. Figure 4 illustrates the deployment of these interfaces, which were attached to existing structures or secured to U-posts to maintain hardware elevation and ensure signal propagation.

To avoid disrupting in-situ sensors, we removed their native 3.5 mm stereo jacks and hardwired the cables into weather-proof junctions using color-coded, lever-actuated terminal blocks. This configuration facilitates rapid field maintenance while consolidating up to six sensors through a single cable to the control interface (Figures 5a, b).

Additionally, the ZL6 datalogger supports both local data storage and LTE cellular data transmission to the cloud, but the Dragino interface was primarily designed for real-time data transmission via LoRaWAN. We eventually enabled local, short-term (days to months) data buffering on the Dragino device, though it was not an advertised feature. In general, we found that local data storage is not well represented in control interfaces designed for IoT, though we consider it to be an important feature for environmental monitoring given that sensors might lose communications at critical times, for example, during storm events.

We also connected off-the-shelf sensors designed for industrial IoT applications to the ESDN, such as the Daxin CTD (RS485 Modbus) and Dragino-compatible sensors. While these pre-packaged solutions theoretically offer plug-and-play functionality, achieving research-grade accuracy required substantial hidden effort. For example, we selected the Dragino LDDS75-LS acoustic distance sensor for non-contact river stage monitoring for both scientific reasons, that is, to avoid the debris and tidal scour risks associated with submersible sensors, as well as economic reasons, that is, each complete sensor node could be purchased for under $100 (US). Field testing, however, revealed erratic readings and severe thermal drift from direct solar exposure, ultimately requiring us to design and fabricate custom radiation shields. Likewise, extensive effort was used to calibrate low-cost soil moisture and electrical conductivity probes (Dragino SE01-LB/LS) to establish their effective operating ranges. These are precisely the class of undocumented hardware limitations that datasheets routinely overlook. Ultimately, while these low-cost options show promise as alternatives to traditional instruments, their upfront savings are often offset by the effort required to resolve measurement uncertainty. Consequently, their deployment demands rigorous laboratory and longitudinal field validation. As the scientific community gains more experience with specific sensors, this additional validation burden is likely to subside.

3.3 Node power architecture and solar recovery

Although the SDI-12 standard supports up to 15 devices, rather than optimizing the power budget for each unique sensor combination, we standardized our deployments to a maximum of six sensors at a 5-min sampling interval per Dragino SDI-12-LS interface. This limitation was driven by a design constrain: we wanted each node to sustain at least 1 week of uninterrupted operation without any solar input to provide resilience against multi-day periods of poor insolation or hardware faults. Depending on the sensor, power requirements were established from manufacturer documentation, power budget calculations, and empirical measurements using a CurrentRanger (LowPowerLab, 2024).

An analysis of the system's worst-case power consumption and empirical validation of solar recovery capacity is detailed in Supplementary section 6.

3.4 ESDN network and transport layer

We adopted LoRaWAN as the primary field telemetry protocol for the ESDN because of its stated long-range communication potential with very low-power draw, thereby allowing sensor nodes to theoretically operate independently on battery (or solar power) for years under a typical environmental measurement frequency (e.g., 5–30 min reporting intervals); see Supplementary section 2 for further details on LoRaWAN's technical suitability. In the LoRaWAN architecture, sensor nodes do not pair with specific receivers; instead, they broadcast telemetry that is captured by any gateway within range. Collectively, these gateways define the wireless coverage area for the WSN (Figure 2). Once a gateway receives this telemetry, it forwards the data packets to a central LoRaWAN Network Server (LNS).

The ESDN utilizes several internet backhaul methods to achieve transmission to the LNS: Ethernet (or Wi-Fi) is preferred when available, especially when power over Ethernet (PoE) is possible; LTE supports remote and temporary sites; and satellite internet (e.g., Starlink; Hawthorne, CA, USA) is used where terrestrial connectivity is absent. In cases where isolated sensor nodes are deployed beyond the reach of any gateway, cellular IoT (Cat-M and NB-IoT) can be used to send data packets directly to the LNS, which handles critical functions like data deduplication, routing, and security. In our implementation, we utilized The Things Network (free community cloud tier; The Things Industries, Netherlands) as the ESDN LNS, though we intend to transition to a self-hosted version of ChirpStack (Brocaar, 2026) in the future as the number of sensors in our network continues to grow. Data are sent from the LNS to an application end-point over the internet.

Given the critical role that gateways play in establishing the WSN coverage area, we experimented with five options for different types of environmental settings: Dragino DLOS8N, Heltec HT-M02 (Chengdu, China), Milesight SG-50, Browan MiniHub Pro (Hukou, Taiwan), and The Things Network Outdoor Gateway. The DLOS8N became our default ESDN gateway given its low cost (≈$380), ability to utilize WiFi or LTE for data backhaul, and low power consumption that can be drawn from a regular 110V outlet, 12V battery, PoE, or any external solar system. In contrast, the Milesight SG-50 was the most expensive gateway we tested (≈$1,000), but it is ideal for remote, standalone deployments as it comes packaged with solar power and LTE communications integrated in a single, robust device (Figure 6). The Browan MiniHub Pro is an ultra-compact gateway designed for indoor deployments; though it has limited range because it has no external antenna, the cost of only ≈$60 for this device makes it ideal for small-scale or educational deployments and local testing environments. Although each gateway model features a vendor-specific configuration interface, integrating them into the ESDN follows a common provisioning logic encompassing hardware configuration, network settings, and LNS registration.

Ideally, gateways are deployed at as high an elevation as possible to maximize the communication range. Mounting a gateway on top of buildings or high infrastructure, like the water tower shown in Figures 6a, b, provides the best range for sensor communications. For times when such infrastructure is not present, we developed a simple, one-person deployment protocol using a low-cost 30 ft flagpole that has proven to be robust (Figure 6c). To protect against lightning strikes, it is critical that the gateways and their antennas are properly grounded in both deployment scenarios.

3.5 ESDN data management and processing layer

The ESDN Data Management and Processing Layer was originally deployed using ThingsBoard Cloud (ThingsBoard Inc., New York, NY, USA). This platform's “software as a service” (SaaS) approach meant that no initial technical knowledge of cloud infrastructure was required to configure or deploy the network, which enabled us to focus on early experimentation and science applications rather than setup. As the ESDN grew, however, we eventually shifted to implement our own self-hosted instance of ThingsBoard Professional Edition (PE) running on Microsoft Azure (Redmond, WA, USA) cloud infrastructure. Selection of ThingsBoard as an architecture for the network avoided the fragmentation common in environmental WSN backends, where separate services are used for connectivity, ingestion, payload decoding, rule-based processing, dashboards, access control, and storage. In contrast, ThingsBoard provides device registration, metadata harmonization, protocol integration, and PostgreSQL time-series persistence in one operational stack. This aligned with the academic platform-selection criteria highlighted by De Nardis et al. (2022), particularly integration with external services and practical deployment considerations, and is consistent with broader evaluations identifying ThingsBoard as a mature open-source option for research deployments (Di Felice and Paolone, 2024; Ayele et al., 2024).

Our selection of ThingsBoard was informed by independent comparative studies. Di Felice and Paolone (2024) evaluated a variety of leading open-source platforms, including FIWARE, SiteWhere, Mainflux, OpenRemote, Eclipse Kapua, and ThingsBoard, across criteria such as connectivity, deployment, scalability/stability, cloud support, data/action processing, user management/authorization, and persistent message handling. For the ESDN data-management scope, these criteria map directly to practical operations: enrolling heterogeneous sensors and interfaces with consistent credentials and metadata, maintaining protocol-specific ingestion without custom glue services, and keeping telemetry/query workflows in a single operational backend. In this context, ThingsBoard offered the strongest fit for day-to-day enrollment and telemetry management while remaining deployable as a self-hosted academic stack (Di Felice and Paolone, 2024; De Nardis et al., 2022). The selection was also economic and operational. In contrast to architectures that scale platform cost per device or require separate paid services for ingestion, rules, and dashboards, the self-hosted deployment follows a fixed-cost infrastructure model in which expansion is driven primarily by compute and storage provisioning rather than per-sensor licensing. This made it practical to grow from pilot deployments to a larger, mixed sensor node inventory without redesigning the backend each time a new sensor class or field site was added.

ESDN data ingestion follows a “single-path” strategy: telemetry is read continuously through the ThingsBoard integration pathway rather than through disparate external forwarding rules. Data entering ThingsBoard are processed by rule chains and are written to PostgreSQL while immutable raw records are archived in Azure blob storage before downstream transformation, supporting long-term retention, auditability, and FAIR-oriented stewardship (Wilkinson et al., 2016). Sensors transmit raw values, including cumulative counters, and the rule engine computes differences, applies calibration coefficients stored as metadata, and stores raw and calibrated streams in parallel. This state-aware architecture avoids frequent edge firmware updates, reduces power demand on solar-constrained field nodes, and supports rapid remote triage through inactivity and watchdog logic. In practice, this design improved data integrity and maintenance response. Dual logging of raw and calibrated records preserved traceability during post-processing and retrospective QA/QC. For example, calibration-factor histories were used to identify severe drift episodes in estuarine CTD and water-level probes, enabling proactive cleaning before irreversible degradation of long-term records.

3.6 ESDN application layer

In the ESDN, ThingsBoard PE also serves as an off-the-shelf application layer, and the same selection logic applies: one platform provides user-facing dashboards, alerting logic, tenant isolation, and API access without requiring a separate visualization stack. Our choice aligns with the three practical criteria identified by De Nardis et al. (2022): visualization capability, integration/data-processing workflow, and deployment complexity. Although FIWARE is often ranked strongly as a broad smart-city backbone, the ESDN uses ThingsBoard because it better matches the operational needs of a sensor-driven, multi-partner environmental network.

Hierarchical multi-tenancy and role controls were particularly important for the deployment of the ESDN as a shared, multi-institutional resource. The platform was configured to provision isolated workspaces with dedicated dashboards and scoped device inventories for distinct partner groups, including the Coastal Studies Institute, Hyde County collaborators, Town of Nags Head, and ECU campus teams. This provided practical data partitioning and role-constrained collaboration while preserving a shared backend infrastructure. For visualization, ThingsBoard's native dashboards allowed immediate provisioning of partner-specific workspaces without deploying and maintaining an additional UI stack.

ThingsBoard is able to handle incoming telemetry through direct platform integration and rule-chain processing rather than a more brittle external forwarding loop. Rule-engine logic was coupled directly to operations; for example, irrigation workflows cross-referenced flow telemetry against valve state to detect persistent post-closure flow and trigger alerts. Programmatic access through REST APIs supports external Python, R, and MATLAB workflows, reducing manual export overhead and enabling repeatable modeling and analytics pipelines. In aggregate, these capabilities shortened maintenance response time by converting communication failures and anomalous states into near-real-time notifications, allowing teams to pre-stage repairs before site visits.

Centralizing data conversion and calibration in ThingsBoard has driven significant improvements in operational efficiency and data integrity. For example, we partially automated the calibration process for off-the-shelf 4–20 mA pressure transducers, entirely replacing legacy spreadsheet-based workflows and simplifying the process for field technicians (Figure 7). In the lab, a technician can now simply enter reference standards used for the calibration in the ThingsBoard panel, which are automatically fit by a linear regression that is later applied to incoming data in real time. By minimizing computational overhead and pairing an accessible dashboard with automated scripts, this streamlined architecture dramatically simplifies sensor maintenance, enhancing both scalability and data quality.

4 Results and discussion

4.1 Network scale and data production

Following early-stage experiments in mid-2023, the ESDN began expanding in mid-2024, growing into a multi-site network by mid-2025 that continues to actively expand as an ongoing initiative to support new research and educational efforts. We differentiate between individual sensors (which can be single or multi-parameter instruments) and control interfaces (which can receive and forward data from multiple sensors simultaneously). The combination of a control interface and its connected sensors is considered a single node at the LoRaWAN network level. As of June 2026, the network comprised 14 active gateways and 110 deployed nodes receiving information from 162 individual sensors, demonstrating that the system scaled beyond a localized prototype while remaining manageable for an institutional research group. This total sensor count (summarized in Table 2) was determined through a hybrid approach: we manually inventoried known field deployments (pairing interface controllers with their physically connected sensors) and supplemented this with an automated extraction from the operational database, explicitly filtering out devices with empty data payloads or those that had never successfully reported. In this count, deployed control interfaces supporting multiple sensors have a known number of sensors reporting, while all other LoRaWAN devices are considered as individual nodes hosting a single sensor.

Table 2. Counts of deployed sensors and environmental data records from ESDN field stations.

CSI, Coastal Studies Institute; PDR, Packet Delivery Ratio; CTD, conductivity-temperature-depth sensors; Soil, individual soil EC/moisture nodes; Level, acoustic stage sensors and pressure transducers; Met., air temperature/humidity and light nodes; Aux., SDI-12 nodes, GPS trackers, and other auxiliary devices. Other sites and lab includes sensors employed for experimentation. We included data records from decommissioned and inactive units. Bold values indicate network-wide totals, with PDR representing the overall network average.

At the time of writing, the ESDN database contained approximately 34 million environmental records across these 162 sensors, encompassing the active field deployments alongside past and present on-campus experimental units. This total increases to more than 230 million records when additional LoRaWAN telemetry diagnostics, device and firmware status fields, and derived or extrapolated values are included alongside the raw environmental measurements directly reported by sensors. To quantify transmission reliability, we calculated the Packet Delivery Ratio (PDR) using a time-based binning approach rather than raw packet counts. A node's active deployment timeline was divided into time bins matching its intended sampling interval (5 min), and we quantified the percentage of expected windows that successfully delivered at least one measurement. To prevent global statistics from being artificially inflated by redundant multi-gateway receptions or high-frequency transmissions during temporary lab calibrations, the minimum evaluation window was clamped to 5 min. Across these stationary field nodes that are set to transmit periodically, the network maintained an overall PDR of 95.4% during active deployment periods (excluding event-based sensors, decommissioned devices, and offline intervals exceeding 24 h attributable to depleted non-rechargeable batteries, recovered devices, or gateway outages).

During the analysis period, 50 nodes were reporting continuously, representing the primary live scientific network. The remaining registered inventory includes devices in diverse operational states: seasonal deployments, experimental units undergoing bench testing, partner demonstrations, field spares, and temporary campaign monitors. Data continuity was maintained by using ThingsBoard's watchdog rules to distinguish communication gaps from hardware failures, enabling targeted remote troubleshooting before scheduling field visits.

4.2 Network performance and reliability

4.2.1 Spatial range and coverage

Environmental conditions impact the effective transmission range for a LoRaWAN network; for instance, Petäjäjärvi et al. (2015) demonstrated how buildings and urban obstacles cause substantial on-ground path loss that limits range, while Myagmardulam et al. (2021) evaluated performance limitations caused by natural topography and shadowing in forested areas. Consequently, gateway coverage cannot be accurately modeled as a simple circular radius.

To account for these environmental complexities, we evaluated our actual LoRaWAN network coverage by conducting empirical mapping using mobile nodes and GPS logging, as illustrated in our preliminary mapping studies (AGU 2024 and 2025 posters, Moysey et al., 2024; Dessimond et al., 2025). Technical recommendations for performing empirical mapping are provided in Supplementary section 3. Around ECU's main campus, shadowing and multipath fading from infrastructure limited the absolute maximum signal transmission distance to approximately 2.7 km, which aligns with established urban attenuation limits (Petäjäjärvi et al., 2015). For instance, despite this 2.7 km maximum range, we could not obtain reliable coverage for stationary sensors at a site 2.4 km from the gateway or indoors in some campus laboratories. Deployment of indoor gateways mitigated these gaps by expanding coverage and providing redundancy. In the unobstructed coastal environment at CSI, empirical mobile mapping (combining on-board GPS logs with a moving node over water, and verifying that the received packets were properly attributed to the target gateway) recorded a maximum point-to-point transmission distance of approximately 22.1 km, consistent with over-water line-of-sight experiments achieving 15 to 30 km ranges (Petäjäjärvi et al., 2015). A plot illustrating this maximum transmission distance is provided in Supplementary Figure S1. Crucially, across both urban and coastal environments, these maximum distances merely mark the physical edge of reception; a single successful point-to-point uplink at extreme range does not guarantee a homogeneous radius of continuous coverage. Indeed, across our mixed-use deployment sites, coverage generally fragmented beyond 3 km, aligning with suburban environment expectations where link stability remains heavily dependent on local vegetation (Ahmed et al., 2025; Richardson Ansah et al., 2020) and structural obstructions (Augustin et al., 2016). To maximize horizontal line-of-sight in the flat, open coastal topography of eastern North Carolina (e.g., Hyde County and CSI), high-gain fiberglass antennas (7–9 dBi) were selectively deployed on gateways, while lower-gain antennas were utilized elsewhere. Antenna gain should be selected according to the deployment geometry rather than treated as a direct proxy for communication range (Kraus, 1950). Higher-gain omnidirectional antennas concentrate radiation into a narrower vertical beam, increasing effective gain toward the horizon while reducing coverage at steeper elevation angles. Accordingly, higher-gain antennas are generally better suited to flat, rural, line-of-sight deployments where gateways are elevated and end devices are distributed over relatively large distances. Lower-gain antennas can provide more uniform coverage in environments with greater elevation variation, such as suburban or campus deployments.

Further analysis regarding the network's long-term temporal stability, seasonal signal attenuation cycles, and Adaptive Data Rate (ADR) behavior at the physical edge of coverage is provided in Supplementary sections 4, 5.

It is also worth noting that the performance figures presented in this section are specific to eastern North Carolina's flat coastal plain. The cited literature (Petäjäjärvi et al., 2015; Myagmardulam et al., 2021) often evaluates LoRaWAN performance in markedly different settings (e.g., urban Finland or forested Japan). Direct extrapolation of our range findings to other geographic contexts should therefore be done with caution, as local topography, vegetation, and built-environment characteristics will substantially influence network performance.

4.3 Network cost analysis

We performed a cost analysis comparing an open-architecture infrastructure similar to the ESDN to a representative Commercial Turnkey IoT Solution (hereafter, commercial solution; Table 3). Historically, our field research relied on multiple commercial environmental sensing solutions. To construct a representative commercial baseline, we drew from our experience with industry-standard commercial equipment. This cost analysis assumes identical instruments (e.g., standard CTD units at ≈$600) and focuses exclusively on the varying costs of the communication hardware and infrastructure. We assume an average deployment ratio of two sensors per logger or control interface, with the ESDN architecture further assuming one gateway per 10 control interfaces. While commercial data loggers can support up to six sensors, they are realistically deployed with fewer in our use-case to prioritize broader spatial coverage across multiple local stations (a strategy where LoRaWAN excels). Similarly, while a single LoRaWAN gateway can support hundreds of devices, our conservative 1:10 ratio accounts for overlapping geographic coverage and network redundancy. Although specific commercial software, subscription, licensing, and cloud infrastructure fees vary, Table 3 provides a scalable template for estimating the cost of alternative configurations:

Table 3. Comparison of capital and operational unit costs for the representative commercial baseline and the user-managed ESDN LoRaWAN architecture.

CE, Community Edition; IP, Internet Protocol; PE, Professional Edition; VM, Virtual Machine.

As established in Section 3.5, data management platforms drive user-managed network costs. While proprietary cellular loggers (≈$550–$750) incurred $200 per unit in annual cloud subscriptions, the ESDN relies on inexpensive LoRaWAN control interfaces (≈$80–$200) and LoRaWAN gateways ($380–$1000). Deploying a self-hosted backend like ThingsBoard Professional Edition (PE) on Azure transitions data management to a fixed operational overhead, meaning the marginal cloud cost added per additional sensor is minimal. Researchers can further eliminate licensing and hosting fees entirely by running the open-source Community Edition (which comes with fewer software features) on-premises when possible.

In our case, the ESDN had a higher initial capital investment due to the ThingsBoard PE perpetual license (purchased for $2,999, though prices have since increased to $4,999 as reflected in Table 3). However, both the upfront software and cloud hosting cost was absorbed by eliminating the recurring cellular subscriptions of the commercial data loggers it replaced. As the network scales, this architecture provides massive economies of scale. For a 20-sensor network (assuming an average commercial logger cost of $650), the 5-year total cost of ownership for the commercial solution is $28,500, compared to $24,274 (high budget) or $13,255 (low budget) for the open solution. By decoupling sensor telemetry from recurring subscriptions, the low-budget configuration achieves an approximate 53% cost reduction, whereas the high-budget configuration reduces costs by roughly 15%. To better visualize how sensor count drives long-term costs, we calculated the 10-year cumulative TCO across these configurations (Figure 8). This 10-year projection accounts for the initial capital expenditure (CAPEX) for telemetry hardware and software, plus 10 years of operational expenditure (OPEX), such as per-node subscriptions for the commercial solution, or centralized server compute fees for the open solutions. The formulas used to compute these cost projections are provided in Supplementary section 7.

4.4 Lessons learned

The primary motivation for building an environmental WSN is to support science goals. Deploying sensor nodes across a site can drastically increase the spatial and/or temporal density of measurements interrogating critical zone processes. Discipline-specific recommendations are, however, beyond the scope of this report. Instead, we focus on lessons learned from creating and operating the ESDN that can inform the decisions of any applied scientist interested in building their own WSN.

Low barriers to startup: perhaps the most critical lesson for applied scientists from all fields is that the barriers to initiating a WSN are low and it is now practical for anyone to create a network, regardless of technical experience or application setting. The availability of low-cost hardware and free software significantly reduces the barrier to entry for research groups: it is possible to start an experimental WSN for under $200 using a single indoor gateway (e.g., Browan MiniHub Pro, ≈$60) paired with a low-cost sensor (e.g., Dragino D22-LB/LS outdoor temperature sensor, ≈$70) and free cloud services (e.g., The Things Network and ThingsBoard Cloud). A basic setup allows research teams to actively try both the LoRaWAN technology and related IoT software until they achieve operational confidence. Teams should start small, validate their data pipelines, and scale up to a self-hosted, multi-site infrastructure only when they thoroughly trust the architecture and their capacity demands it.

Leverage existing infrastructure: retrofitting legacy sensors with LoRaWAN interface modules had many benefits in our case, including preserving data quality by avoiding the disturbance of in-situ sensors, maintaining data continuity for long-term data records, and reducing costs associated with replacement sensors. Consequently, a critical first step when establishing a new WSN should be evaluating opportunities to retrofit and integrate existing systems rather than replacing them outright. This is an especially salient point for multi-investigator critical zone observatories that have the administrative capacity to coordinate the implementation of standards for Layers 2–4, even if site scientists insist on utilizing specific sensors that they are comfortable working with. Enforcement of standards, such as SDI-12 compliance, can make retrofitting almost trivial, but integrating existing analog sensors into the network is also possible.

Reduced labor requirements: prior to the ESDN, the lab operated commercial systems from different manufacturers (some connected via cellular, some not); for the connected systems, this required managing separate subscription portals and separate alarm mechanisms with no unified dashboard. As a result, some loggers went non-operational unknowingly, some subscriptions lapsed, and equipment faults were sometimes discovered only upon physical arrival at the field site. The ESDN consolidates all deployed devices into a single unified interface with a centralized alarm reporting pipeline, making the operational state of the entire network immediately visible. Our ThingsBoard deployment triggers automated email alerts within 15 min of a node failing to report (based on expected transmission intervals) or producing out-of-range readings (e.g., zeroed values or readings outside plausible bounds). This near-immediate failure detection provides a direct contrast to benchmark figures from non-connected legacy datalogger deployments, which have reported mean data acquisition latencies of 71 days and failure-detection delays exceeding 100 days (Kazem et al., 2025). While failure detection is now rapid, field remediation can still take considerably longer due to travel times, particularly when sensors are not immediately accessible. However, this centralized monitoring enables researchers to proactively plan field work, ensuring technicians arrive with all necessary supplies and pre-configured replacement hardware. This minimizes on-site maintenance and prevents wasted trips. It also significantly simplifies student onboarding and monitoring, as it reduces the number of disparate proprietary software systems and vendor portals that new researchers must learn for sensor configuration, data visualization, and troubleshooting. Furthermore, when fault origins are ambiguous, the low cost of LoRaWAN interfaces enables rapid unit-for-unit replacement, leaving the in-situ sensor undisturbed.

Hidden costs of open architecture: while the upfront cost of hardware is easily quantified, true total cost of ownership must account for the logistical expenses of fieldwork, including the time spent deploying sensors and the specialized tools required. Furthermore, open architecture networks demand specialized labor and expertise to maintain the backend infrastructure, server hosting, and data pipelines. However, the capital saved by eliminating recurring commercial subscriptions can be reallocated toward the personnel costs required to maintain and expand the network. While this shifts the financial burden from external subscriptions to internal labor, it ultimately provides researchers with significantly greater flexibility, ownership, and custom functionality. For example, replacing a single, higher-end multiparameter sensor with several more affordable, single-parameter units may reduce initial capital expenditure, but it will likely incur higher deployment costs due to the increased time and labor required for installation and maintenance of multiple units. It is therefore fundamental to streamline sensor deployments and design enclosures or mounting systems that minimize field time, thereby mitigating these associated labor costs.

Prioritizing spatial coverage over hardware consolidation: the elimination of per-device subscription and data transmission costs fundamentally shifts deployment strategies. Whereas commercial solutions financially incentivize researchers to maximize the number of sensors connected to a single multi-port logger to avoid additional subscription fees, the low cost of individual LoRaWAN interfaces allows nodes to be distributed more broadly. This empowers researchers to deploy single-parameter sensors at distinct locations, prioritizing spatial coverage across a field site rather than forcing co-location to optimize hardware consolidation.

Flexible network topology and backhaul: evaluating practical network range revealed that topography and local landscape characteristics influence deployment performance far more than theoretical hardware specifications (Petäjäjärvi et al., 2015; Myagmardulam et al., 2021). Our results indicate that a properly configured outdoor gateway can reliably serve sensors over several kilometers, depending on site-specific conditions, provided that low-quality antennas (usually provided with off-the-shelf prototyping modules) or incorrect node or device configurations are avoided. We opportunistically deployed LoRaWAN gateways to establish baseline coverage and subsequently added additional gateways when necessary, creating overlapping coverage and improving network resilience. For isolated nodes located near the edge of network coverage, upgrading the node with a higher-gain antenna proved an effective means of extending communication range while maintaining regulatory compliance. Where monitoring sites fell beyond the practical reach of the LoRaWAN network, cellular IoT nodes and gateways provide a seamless alternative. In highly remote locations lacking commercial cellular service, additional gateways can be deployed closer to the target site using alternative backhaul technologies such as Wi-Fi HaLow or Starlink. Numerous technical approaches can be used to establish connectivity; prioritizing deployment flexibility over adherence to a rigid network architecture is key to building a resilient environmental sensing network.

Testing and validation of “off-the-shelf” IoT sensors: beyond hardware integration, balancing cost with scientific reliability remains a primary challenge. Off-the-shelf IoT sensors offer affordable alternatives to purpose-built instruments but typically lack rigorous out-of-the-box measurement validation (Bogena et al., 2022). As the network scales, these validation workflows can be supplemented by improved network analytics to automatically detect sensor drift (Schmidt and Kerkez, 2023). Ultimately, the sensing layer's core architectural challenge is bridging the protocol gap between commercial hardware and telemetry interfaces while ensuring the resulting data remains scientifically robust.

Value of metadata: structured metadata must be treated as essential infrastructure from day one; standardizing sensor tracking, deployment histories, and calibration logs (such as documenting specific conductance calibrations at 18°C) prevents a scalable network from simply becoming an unmanageable data silo. Once this architecture is established, the front-end user experience becomes remarkably accessible. Students and collaborating scholars can confidently manage deployments and workflows using system-enforced standards without requiring deep software expertise, giving the team the clarity needed to differentiate between genuine network anomalies and initial configuration errors. Furthermore, treating quality assurance and quality control (QA/QC) history as trackable metadata adds significant value for researchers by ensuring complete traceability of data provenance. This approach could also be readily extended to satisfy strict compliance and auditing requirements for certain operational or regulatory user types. Likewise, strong metadata records will become critical for providing context about the network as the use of AI to access and manipulate data grows over time. Building and exposing metadata for AI use will likely be an important design choice in the immediate future and is an area of research that deserves more attention.

Heterogeneous network growth: if an environmental WSN is to be used for more than a single research project, it is likely that the network design will not be fully preplanned. Instead, it is likely to expand incrementally and opportunistically. As a result, there will be a range of sites that differ in maturity, sensor density, and gateway redundancy. Likewise, physical deployments, ranging from enclosure design to sensor deployment methods, are also likely to vary across sites as practices and technologies evolve over time. Maintaining full insight into network performance and ensuring the consistent production of high-quality data therefore demands careful documentation and tracking of these changes over time. This should not be done in disconnected records, but as embedded metadata within the system itself, allowing these changes to become discoverable as a part of the overall data stream. We have found that implementing such robust metadata standardization practices is in practice, however, challenging. As a result, maintaining data consistency across diverse sites remains an ongoing effort. Automation of network-wide summaries and the use of AI for metadata generation may help to reduce the burden, thus improving reliability of data for long-term reuse.

4.5 Toward participatory sensing

Participatory sensing offers a powerful framework for addressing gaps in environmental monitoring by enabling community members to actively contribute to data collection by hosting sensors and communication infrastructure on their own property. A truly participatory approach means that users will support regional data collection through the network while simultaneously addressing their own goals and priorities. For example, our deployment of Starlink in Hyde County not only supported a LoRaWAN gateway to meet our scientific goals, but it also provided reliable internet access to individuals in a rural region that previously had none. Supporting the deployment of low-cost sensing nodes in a robust, heterogeneous network, like the ESDN, can enable participation by individuals, organizations, educators, and communities in addition to scientific researchers.

Engaging a broad coalition of stakeholders fosters collaboration that is both inclusive and grounded in local knowledge. Community-based representatives play a key role in building trust, facilitating dialogue, and ensuring that monitoring efforts reflect the priorities and concerns of the people most affected, particularly among groups that have historically been underrepresented in environmental decision-making. In turn, this distributed, community-centered model expands spatial coverage of monitoring networks while empowering residents to take part in shaping and understanding the data that inform local environmental management.

Our work with the residents of a public housing project to monitor a new community garden is a good example. The integration of monitoring and irrigation control systems with the ESDN not only makes the management of the garden easier for the residents and provides us with data on water usage, weather conditions, and soil moisture, but the formalization of the system into a showcase has elevated the community's activities. For example, the residents have been empowered by their garden activity to organize and engage more directly with the City over community infrastructure, in part leveraging data from the network in these discussions. Seeing our formal investment in the community garden is also bringing new partners to the table to support additional contributions to the community (e.g., one organization is planning to provide a picnic table). In addition, sensing has been integrated into informal STEM education programs for youth in the neighborhood; the garden application makes sensing concrete and locally relevant rather than an abstract scientific task. Through outreach, training, and shared learning opportunities, participatory sensing also strengthens public engagement, enhances data literacy, and promotes the development of more equitable and impactful solutions to environmental challenges.

To involve students and the public with the deployed sensors, several enclosures around campus are outfitted with informational posters and QR codes (Figures 9a–d) directing users to a mobile-friendly, public-facing dashboard. This infrastructure and the data from these sensing nodes have also been integrated into the curriculum for formal undergraduate Geology labs at ECU as well as informal education activities, like the ECU Water Resources Center's Summer Community Science Camp.

While some of these activities leverage the outdoor monitoring network, the ESDN also supports the use of sensors indoors. We therefore use the same sensor nodes from our field deployments to implement hands-on activities in the classroom; for example, students use conductivity, temperature and depth sensors to experiment with the filtration of saline water through different media and use real-time dashboards in ThingsBoard PE to collect monitoring data and observe transient flow and transport behaviors that would be difficult (if not impossible) to capture with manual measurements.

5 Conclusion

The ESDN demonstrates that a complete distributed sensing solution spanning field instrumentation, wireless communications, centralized data infrastructure, and user-facing analytical interfaces can now be assembled entirely from interoperable off-the-shelf components at institutional scale. Only a decade ago, deploying such a system would have required substantially greater technical expertise, custom engineering, and financial investment. The recent convergence of low-cost LoRaWAN hardware, open network infrastructure, and self-hostable IoT platforms have largely removed the technical barriers that once confined distributed environmental monitoring to large, well-funded research programs and proprietary commercial platforms.

Future opportunities exist for WSN research in areas like leveraging sensor redundancy for automated QA/QC, enhancing metadata quality, and optimizing spatial and temporal data collection strategies to capture new insights about critical zone processes. Artificial intelligence (AI) is likely to play an increasingly important role in both the operation and analysis of data produced by sensing networks, making exposure of data to AI and robust metadata collection essential. Analytically, the ESDN's time-series API, open data architecture, and integration capabilities position it to support future AI-assisted analytics. For instance, ThingsBoard natively supports the integration of AI models (ThingsBoard, 2025) for anomaly detection and predictive analytics without requiring a system redesign, even though we have not yet deployed these capabilities. Finally, expanding the network's capabilities through edge computing architectures offers a pathway to perform local data processing, filtering, and alert generation directly at remote field sites prior to centralized transmission. These represent exciting technical capabilities that our future efforts will consider implementing.

By aggregating multi-parameter observations across coupled environmental systems, open-sensing and data architectures, like that utilized by the ESDN, can reduce disciplinary and practical barriers to conducting critical zone science and supporting participatory sensing. Its demonstrated transferability across distinct landscapes offers a practical blueprint for how monitoring infrastructure can natively support both traditional and AI-assisted data analysis. Ultimately, replicating this success relies on several concrete principles: build around interoperability from the start, build standardized metadata directly into the data pipeline, and build accessible laboratory and field workflows that research teams and the scientific community can adopt and refine.

The open-source environmental IoT ecosystem is still maturing, but already provides highly capable alternatives to closed systems. As these open platforms become increasingly accessible, scientific reliance on expensive, subscription-based dashboards and vendor-locked instruments will naturally decline. Rather than forcing users into proprietary ecosystems, hardware manufacturers that prioritize seamless, open API integration will be best positioned to support the operational realities of the modern environmental research community.

Generative AI statement

The author(s) declared that Generative AI was used in the creation of this manuscript. The author(s) acknowledge the use of artificial intelligence in the preparation of this manuscript. Google, OpenAI, and Anthropic models were used by some authors to aid the original drafting of some portions of the manuscript text, generate some elements of the figures, and to create scripts for downloading, organizing, and counting the raw sensor data. For the graphic content, AI was used exclusively to generate the 3D isometric illustrations of the hardware (Figures 1, 3). These generated elements were subsequently manipulated in traditional image editing software to create the final figures. No text or data graphs were created using image generation tools. The authors confirm that all AI-assisted elements and figures have been manually verified for technical accuracy.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher's note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Supplementary material

The Supplementary Material for this article can be found online at: https://www.frontiersin.org/articles/10.3389/frwa.2026.1906048/full#supplementary-material

Supplementary material Supplementary material at the source

Footnotes

Edited by: Andrew Stumpf, University of Illinois at Urbana-Champaign, United States

Reviewed by: Jose Luis Villa, Universidad Tecnológica de Bolívar, Colombia

I. A. Aderemi, University of Ilorin, Nigeria