HSRW EOLab Students Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Rhine-Waal University of Applied Sciences; Faculty of Communication and Environment; Final Project Report; Interdisciplinary Projects; WS 2025/2026



====== IP 25 Dissolved Oxygen Sensor ======
**Development of a Prototype for Continuous Monitor-ing in Flowing Waters**

**Project Supervision:** Prof. Dr.-Ing. Becker, Hannah Pearly Shelly David

**Authors:** Sascha Althaus (31507), Mohamed Karim (32603), Yannick Müsch (31490), Stefan Rak (31604), Alexander Rausch (33213), Johannes Schelb (31861), Lars Theodor Schöne (31629), Sultana Shamsunnahar (33852), Fabian Sloma (31647), Subrina Sultana (33977)

**Submission Date:** 10/02/2026


[[ https://gitlab.hsrw.eu/31507/ip_25 | Project Repository ]]

[[ https://gitlab.hsrw.eu/32603/ip25-esp32-sketch | ESP32 Sketch ]]

{{ :ip:ws2025:do_sensor:ip-25_final_project_report.pdf |PDF-Version of the report}}

{{ :ip:ws2025:do_sensor:ip2526_ip25_dissolved_oxygen_sensor-1.pdf |PDF of the created poster for the poster session}}

----

===== Abstract (Karim) =====

LINEG needs a low-cost, low-maintenance way to continuously monitor local water bodies and catch contamination events that manual sampling misses. This report presents a prototype hardware platform that measures dissolved oxygen, pressure, and temperature every two hours using an ESP32-based sensor node. The system uses an optical RS485 dissolved oxygen probe and a pressure sensor, powered by a single-cell LiPo battery through a DC-DC boost converter with a switched sensor power supply. Power budgeting based on worst-case datasheet values predicts a battery life of about 4.9 weeks, which is well above the required seven-day maintenance interval. Lab tests confirm that the sensing and communication chain works correctly from end to end. Detailed calibration and long-term field testing are left for future work. The design shows that a low-cost, modular monitoring node tailored to LINEG’s needs is feasible.

----

===== 1. Introduction =====
This report presents the development of a prototype for continuous dissolved oxygen monitoring in flowing waters. The project was conducted in cooperation with LINEG, the corporation responsible for water quality monitoring in the lower Rhine region.

Chapter 1 introduces the project background, objectives, requirements and the overall approach taken by the project group.

==== 1.1 Project Frame and Goal (Schöne) ====
Water quality monitoring is a key element of environmental protection and sustainable water management. Rivers and streams are dynamic systems whose ecological status is influenced by both natural processes and human activities, such as nutrient input, organic pollution and hydro morphological changes.

A reliable assessment of these influences therefore requires regular monitoring of relevant parameters. Dissolved oxygen is one of the most important parameters for evaluating water quality. It is closely linked to biological activity and overall ecosystem health, and it reacts sensitively to pollution and changing environmental conditions. Low dissolved oxygen concentrations can indicate increased organic load and impaired ecological conditions, which may pose a serious threat to aquatic life.

The Water Framework Directive (Directive 2000/60/EC)  establishes a comprehensive legal framework for the protection and sustainable management of surface waters and groundwater in the European Union. Entered into force in December of 2000, it requires Member States to regularly monitor key water quality parameters, including dissolved oxygen to assess their ecological and chemical status to maintain or achieve good water quality.

In the Lower Rhine region, these monitoring tasks are carried out by LINEG. The company is responsible for assessing the ecological status of numerous water bodies and over 400km of waterways (LINEG, o. J.).

Despite its importance, dissolved oxygen is often measured only a few times a year using manual, on-site methods. While such measurements provide valuable snapshots of water quality, they offer limited temporal resolution and cannot capture short-term fluctuations or dynamic processes in flowing waters. In addition, these measurement campaigns require a high level of human involvement, as trained personnel must be present on site for data acquisition and documentation.

The objective of this project is the development of a prototype system for continuous dissolved oxygen monitoring in flowing waters. The system is designed to perform automated data acquisition and to transmit measurement data autonomously to an external interface, enabling remote access and further analysis. A further objective is suitability for long-term deployment, with the aim of reducing manual measurement effort while increasing temporal data resolution.

==== 1.2 Requirements and Concept (Schöne) ====
Based on the project objectives, a set of functional and non-functional requirements was defined to guide the system design. These requirements reflect both the intended measurement tasks and the environmental conditions of long-term deployment in flowing waters.

The functional requirements focus on reliable data acquisition and communication. The system is required to measure dissolved oxygen continuously at predefined time intervals. In addition, temperature and water pressure are recorded as supplementary parameters, as they influence dissolved oxygen levels and support data interpretation. All measurement data must be transmitted wirelessly to enable remote access and further analysis.

The non-functional requirements address operational robustness and long-term usability. The system must operate reliably in flowing waters and withstand environmental influences such as current, debris and weather conditions. Energy efficiency is a key requirement to allow extended operation without frequent maintenance or battery replacement. Furthermore, the system should require minimal maintenance, with particular attention given to sensor fouling and cleaning requirements. Finally, the system must be protected against external interference, including potential vandalism during field deployment.

Based on these requirements, a corresponding system concept was developed. The envisioned system is a stationary sensor platform designed for long-term deployment in natural aquatic environments. It is intended to operate autonomously over extended periods of time, while minimizing the need for physical maintenance and on-site intervention.

The designed system is to be placed near the to be measured bodies of flowing water. The main housing, containing the electronic components and energy supply, is intended to be positioned outside the water body. Only the sensors that require direct contact with the water are deployed within the aquatic environment. This separation reduces exposure of sensitive components to harsh conditions, simplifies maintenance and improves overall system reliability during long-term operation.

The overall concept as shown in figure 1 follows a modular architecture. This allows the integration of multiple sensing units and supports future system expansion without a fundamental redesign. At its core, the system consists of a sensing subsystem, a central processing unit, a communication unit, an energy supply module, a cleaning mechanism and a protective housing.
 
<imgcaption image1|>
{{ :ip:ws2025:do_sensor:block_diagram_of_system_concept.png?nolink&600 |The block diagram of the proposed system concept, showing the main subsystems, data flow, and the spatial separation between in-water sensors and above-water housing and components. Source: Own illustration.}}
</imgcaption>

The sensing subsystem is designed to measure dissolved oxygen as the primary parameter, complemented by additional environmental variables such as temperature and pressure to improve data interpretation and measurement reliability. 

The system concept defines the logical separation between data acquisition, processing and external data access. Sensor data is collected, prepared for transmission and forwarded to a remote backend, where it is stored and made accessible for visualization and analysis. This enables both real-time monitoring and retrospective analysis of recorded environmental data.

To support long-term autonomous operation, the system concept includes a dedicated approach to sensor maintenance. A cleaning mechanism is incorporated to reduce biofouling and minimize manual servicing requirements over time.

Finally, the system is enclosed within a robust protective housing. The housing is designed to shield the internal components from environmental exposure and water ingress, while also addressing risks related to unauthorized access or vandalism.

==== 1.3 Approach and Workflow (Schöne) ====
The project was carried out following a structured and collaborative workflow. At the beginning, the problem was defined and the project objectives were specified. Based on this, an initial analysis of functional and non-functional requirements was conducted to establish a common understanding within the group.

In the next step, multiple concept ideas were developed in small subgroups. These concepts addressed different approaches to hardware, power supply, data transmission, casing, cleaning and placement methods. The proposed solutions were then presented and discussed within the full project group. Based on this comparison, a final prototype concept was defined.

After the overall concept had been established, the project work was divided into subsystem-oriented subgroups. Each subgroup focused on a specific aspect of the system, namely hard- and software (including the subgroups hardware, power supply, data transmission and visualisation), cleaning methods and casing. These groups then carried out their work in parallel, while the project team regularly reconvened for key decision-making steps.

----

===== 2. Methodology =====
The following chapter describes the technical implementation of the proposed system concept. It begins with an overview of the method of operation, outlining the process from data acquisition to data transmission and utilization. The subsequent sections then present the individual subsystems in detail.

==== 2.1 Method of Operation (Schöne) ====
This section describes the operational workflow envisioned for the system, outlining how measurement data is acquired, processed, transmitted and ultimately made available for use. The focus lies on the functional sequence of system operation rather than on the technical implementation of individual components.

During operation, the sensors are deployed in flowing water, where they continuously monitor the aquatic environment. At predefined time intervals, dissolved oxygen is measured as the primary parameter, complemented by temperature and pressure measurements. These additional parameters are needed for the calibration of the DO-sensor and can also support the interpretation of dissolved oxygen values and therefore improve measurement reliability.

The system follows an autonomous operating logic to enable long-term deployment. Between measurement cycles, the system enters a low-power state to reduce energy consumption. At the scheduled measurement interval, the system wakes up, performs data acquisition and processes the recorded signals before returning to its low-power state.

After acquisition, the measured data is transferred from the sensor interface to the central processing unit. There, the data is aggregated and formatted for transmission. Once prepared, the measurement data is transmitted wirelessly to a remote backend infrastructure.
In the backend, incoming data is stored in a database and made available for further use. A web-based interface allows authorized users to access the measurement data. Both real-time monitoring and retrospective analysis of historical data are supported, enabling continuous observation of water quality conditions.

This sequential workflow defines the intended functional behaviour of the system and serves as a reference framework for the technical implementation and evaluation described in the following sections.



----


==== 2.2 Hardware (Karim) ====
IoT-based water quality monitoring has received a lot of attention in recent years. Jan et al., 2021 reviewed current IoT water monitoring systems designed for domestic use, looking at sensor types, communication methods, and overall system design. Their review found that while many systems exist, they tend to share the same weaknesses: poor power management, limited communication range, and high costs. The system presented in this report addresses these issues directly through its maintenance-synchronized power design and low-cost components.

Forhad et al., 2024. built an IoT system for real-time monitoring in water treatment plants, measuring dissolved oxygen, temperature, pH, and total dissolved solids. Their system uses a PLC controller with 4G connectivity and achieved reliable automated monitoring with small error margins. However, it draws 29 W continuously and costs around $2,445. This is suitable for fixed installations with mains power but impractical for battery-powered field nodes. The system in this report is designed for a completely different scenario: remote locations where there is no power grid and the hardware must remain low-cost and field deployable.

On the energy side, Bouguera et al., 2018. developed a detailed energy model for LoRaWAN sensor nodes. They showed that the main factors controlling battery life are the duty-cycling settings — things like spreading factor, coding rate, payload size, and how often the node transmits. Their phase-based approach (sleep, measure, transmit) is the same framework used in this design to estimate weekly energy use from datasheet values. The main difference is that this system ties its energy budget to a real operational constraint — the seven-day sensor cleaning schedule — rather than just trying to maximize battery life as much as possible.

=== 2.2.1 Hardware Design Requirements (Karim) ===

The system brings together the processing unit, sensor connections, and power management into one design. The overall layout and connections are shown in Figure 2, while the physical implementation of the prototype is depicted in Figure 3.

The hardware was designed to meet these specific requirements:
  * Measure Dissolved Oxygen (DO), pressure, and temperature at regular intervals (default: every two hours)
  * Run for at least seven days on battery to match the maintenance schedule
  * Allow battery charging via USB-C during weekly maintenance visits
  * Keep sensor power draw close to zero when not actively measuring
  * Safely connect 3.3 V logic to 12 V industrial sensor.
  * Work with both WiFi and LoRaWAN communication


<imgcaption image10|>{{ :ip:ws2025:do_sensor:bild10.png?nolink | System Block Diagram showing the data and power connections between the ESP32, Sensors, and Power Module. Own illustration.}}</imgcaption>

<imgcaption image200|>{{ :ip:ws2025:do_sensor:bild200.jpg?nolink | The assembled prototype showing the ESP32, power management module and the sensors. Own illustration}}</imgcaption>

=== 2.2.2 The Brain: ESP32 Microcontroller (Karim) ===

The ESP32 microcontroller is at the core of the system. It was chosen because it combines a capable processor, Wi-Fi, Bluetooth, and multiple communication ports in a single affordable chip. When paired with an external transceiver, it also supports LoRaWAN for long-range communication.

The ESP32 also has several UART ports for talking to sensors, analog-to-digital converters (ADCs) for reading voltages, and a deep sleep mode that drops power consumption to just a few microamps. This deep sleep feature is essential for a battery-powered device that needs to last weeks in the field.

The firmware runs a simple repeating cycle: wake up, turn on the sensors, wait for them to stabilize, take the measurements, send the data, and go back to sleep. This keeps the battery drain as low as possible while still collecting regular data


=== 2.2.3 The Pressure Sensor Interface (Karim) ===


The pressure sensor outputs an analogue voltage that corresponds to the water pressure. The problem is that its output can go up to 5V, while the ESP32′s ADC inputs can only handle up to 3.3V. Connecting them directly would damage the microcontroller.

The solution is a voltage divider built from two resistors (1𝑘Ω and 1.8𝑘Ω). Since the sensor’s maximum output is 4.5V, these values were chosen to bring the signal down to a safe level:
<WRAP center round box 30%>
$V_{in} = V_{out} * \frac{R_{2}}{ R_{1} + R_{2}}$

$V_{out} = 4.5\,\text{V} \cdot \frac{1.8\,\text{k}\Omega}{1\,\text{k}\Omega + 1.8\,\text{k}\Omega} \approx 2.89\,\text{V}$

</WRAP>
This scales the full sensor range down to about 2.9V, which stays safely within the ESP32′s 3.3V ADC range. The 12-bit ADC converts this voltage to a digital value. The firmware then translates it into a pressure reading using sensor-specific calibration coefficients.



=== 2.2.4 The Dissolved Oxygen Sensor Interface (Karim) ===

The dissolved oxygen sensor used in this project is the DFRobot SEN0680, an optical sensor based on fluorescence quenching (DFRobot, o. J.c). Unlike older electrochemical sensors that consume oxygen during measurement and need regular electrolyte changes, this optical type is non-invasive and requires very little maintenance. 

The sensor runs on 12V and communicates over RS485. Since the ESP32 operates at 3.3V, an Active Isolated RS485-to-TTL adapter is used between them. This adapter handles both signal translation and voltage step-up. Its built-in boost converter generates the 12V the sensor needs from the system’s 5V rail (DFRobot, o. J.a). The sensor also has a built-in temperature probe, so it can automatically compensate the DO readings for water temperature.

=== 2.2.5 Power System Architecture (Karim) ===

The power system follows a “Maintenance-Synchronized” approach. Because LINEG technicians already must visit the sensor every seven days to clean the optical membrane, the battery only needs to last longer than one week — not months. This simplifies the power design significantly.

The system runs on a single 3.7V, 2,000mAh Lithium-Polymer battery. Charging is handled by the Adafruit Universal Charger, based on the TI bq24074 chip (Texas Instruments, o. J.), which supports load sharing. This means the system continues operating while the battery charges via USB-C during maintenance visits.

The voltage path works the following way:
  - Input: 3.7V from the LiPo battery
  - Boost: A DC-DC Boost Converter (NCP1402) steps this up to a stable 5V rail
  - Distribution: The 5V rail powers the ESP32 and the sensor switching circuit

<imgcaption image11|>{{ :ip:ws2025:do_sensor:bild11.png?nolink | The power management system integrating the Adafruit bq24074 charger. Own illustration.}}</imgcaption>

=== 2.2.6 Relay-Based Power Switching (Karim) ===

To save power, the sensors are completely disconnected from the supply when not in use. This is done using a High-Side Switching circuit, which cuts the 5V line to the sensors during sleep, so they draw zero current.

<imgcaption image12|>{{ :ip:ws2025:do_sensor:bild12.png?nolink | The intended High-Side Switching logic using a P-Channel MOSFET driven by a BC547 NPN transistor. Own illustration}}</imgcaption>

In this prototype, a mechanical relay (FRS1B) was used instead of the planned P-Channel MOSFET because the MOSFET was not available at the time (Chameleon Electronics, o. J.). The relay draws more power (90mA) than a MOSFET would, but it still proves that the switching logic works correctly.
=== 2.2.7 Circuit Protection: The Flyback Diode (Karim) ===

Because the prototype uses a relay (which is an inductive load), the circuit needs protection against voltage spikes. When the BC547 transistor switches off the relay, the magnetic field in the coil collapses quickly. According to Faraday’s Law ($V = -L \cdot \frac{di}{dt}$), this rapid change in current creates a high-voltage spike called Back EMF. This spike can be high enough to destroy the transistor or the ESP32.

To prevent this, a 1N4007 flyback diode is placed across the relay coil in reverse. During normal operation it does nothing. But when the relay switches off and the voltage spike appears, the diode becomes forward biased and provides a safe path for the current to loop back through the coil until the energy is used up as heat. This simple component protects the rest of the circuit from damage.
=== 2.2.8 Power Consumption Analysis (Karim) ===

Power consumption was estimated using values from component datasheets. A worst-case approach was used for all active loads to make sure the battery life estimate is conservative. This method of estimating IoT node autonomy from duty-cycle parameters is well established in the literature (Bouguera et al., 2018).

**Component Current Draw (5V Rail)**

ESP32-WROOM-32D (Espressif Systems, o. J.):
  * Deep sleep: 10 μA
  * Active CPU (80 MHz): 80 mA
  * WiFi transmission (802.11n): 180 mA

FRS1B Relay (Chameleon Electronics, o. J.): Active (coil energized):
  * 90 mA (0.45W/5V)

DO Sensor Interface (DFR0845): 67 mA (Calculated)
  * Note on Power Conversion: The DO sensor requires 12V (0.2W)1. Since the system runs on 5V, the adapter must boost the voltage (DFRobot, o. J.a)
  * Load Current:
<WRAP center round box 14%>
$\frac{0.2\,\text{W}}{5\,\text{V}} \approx 40\,\text{mA}$
</WRAP>
  * Accounting for 85% boost efficiency, the actual draw from the 5V rail is ≈ 47 mA.
  * Quiescent Current: The isolation chip (TDH541S485H) draws 20 mA
  * Total Active Draw: 47 mA + 20 mA ≈ 67 mA

Module Quiescent Currents (Always On):

  * NCP1402 Boost Converter (Onsemi, o. J.): 15 μA (quiescent current while regulating)
  * Grove LoRa-E5 Sleep Mode (Seeed Studio, o. J.): 60 μA (module powered but idle)

**Component Current Draw (Battery Rail - Direct)**

BQ24074 Charger (Texas Instruments, o. J.): 6.5 μA
  * From the datasheet’s “Battery Discharge Current” spec (USB input disconnected, device enabled)

**Operational Cycle: The system wakes every two hours, which gives 84 cycles per week**
  * Sleep Phase (7,165s): ESP32 sleeping, LoRa sleeping, Boost converter idling
  * Measurement Phase (30s): ESP32 active, Relay ON, all sensors and RS485 powered
  * Transmission Phase (5s): ESP32 Wi-Fi radio active, Relay OFF

^ Phase ^ Duration ^ Current (5V) ^ Active Components ^
| Deep Sleep | 7,165 s | 0.085 mA | ESP32 (Sleep), LoRa (Sleep), Boost (Quiescent) |
| Measurement | 30 s | 239.8 mA | ESP32, Relay, Sensors, RS485 |
| WiFi TX | 5 s | 180.0 mA | ESP32 WiFi Radio |
//Table 1: Overview of the operational phases of the system and their associated current consumption at 5 V.//


**Energy Consumption Calculation (Weekly)**

First, the energy used at the 5V rail is calculated for each phase:

<WRAP center round box 40%>
$E_{5\text{V}sleep} =
0.085\,\text{mA} \cdot \frac{7165\,\text{s}}{3600\,\text{s/h}} \cdot 84
\approx 14.2\,\text{mAh}$

$E_{5\text{V}meas} =
239.8\,\text{mA} \cdot \frac{30\,\text{s}}{3600\,\text{s/h}} \cdot 84
\approx 167.9\,\text{mAh}$

$E_{5\text{V}wifi} =
180\,\text{mA} \cdot \frac{5\,\text{s}}{3600\,\text{s/h}} \cdot 84
\approx 21.0\,\text{mAh}$

$E_{5\text{V}total} =
14.2 + 167.9 + 21.0
= 203.1\,\text{mAh}$
</WRAP>

Next, this gets converted to battery capacity (3.7V). The boost converter steps up from 3.7V to 5V, and it is not 100% efficient (𝜂 ≈ 85%), so the battery has to supply more energy than the 5V rail consumes:

<WRAP center round box 26%>
$E_{\text{batt,load}} =
E_{5\text{V},total} \cdot \frac{5\,\text{V}}{3.7\,\text{V}} \cdot \frac{1}{0.85}$
</WRAP>

Finally, the small constant drain from the BQ24074 charger (connected directly to the battery) is added:

<WRAP center round box 40%>
$E_{\text{charger}} =
0.0065\,\text{mA} \cdot 168\,\text{h}
\approx 1.1\,\text{mAh}$
</WRAP>

Total weekly energy budget:

<WRAP center round box 40%>
$E_{\text{TOTAL}} =
322.6\,\text{mAh} + 1.1\,\text{mAh}
= 323.7\,\text{mAh}$
</WRAP>

**Battery Life Conclusion:** With a 2,000 mAh LiPo battery and a conservative 80% usable
capacity (1,600 mAh):

<WRAP center round box 40%>
$\text{Estimated Runtime} =
\frac{1600\,\text{mAh}}{323.7\,\text{mAh/week}}
\approx 4.9\,\text{weeks}$
</WRAP>

Even with the power-hungry relay and the RS485 adapter, the short duty cycle keeps weekly consumption to only about 324 mAh. This gives nearly 5 weeks of operation on a single charge — far more than the seven days required between maintenance visits.

//Note: This estimate is based on worst-case datasheet values and has not been tested with a real long-term discharge test. Verifying the actual battery life under field conditions is planned as future work.//
=== 2.2.9 System Testing and Results (Karim) ===

Before any field deployment, the complete sensing chain was tested in the lab to make sure everything works correctly. The DO sensor was checked against the dissolved oxygen saturation table published by the Vermont Department of Environmental Conservation (Vermont Department of Environmental Conservation, o. J.), and the pressure sensor was zeroed at atmospheric pressure.

To test the DO sensor, the probe was placed in fresh tap water at room temperature. Tap water works well because its dissolved oxygen level at a given temperature is well documented. The VT WSMD Wastewater Program Lab Manual provides a saturation table listing oxygen solubility at various temperatures (Vermont Department of Environmental Conservation, o. J.). The test was repeated 𝑛 = 4 times. Each cycle went through the full firmware routine: wake up, power on sensors, wait for stabilization, take the reading, power off, and go back to sleep.


^ Cycle ^ DO (mg/L) ^ Temp (°C) ^ Saturation (%) ^
| 1 | 7.83 | 18.9 | 84.4 |
| 2 | 7.82 | 18.8 | 84.1 |
| 3 | 7.79 | 18.7 | 83.6 |
| 4 | 7.78 | 18.6 | 83.3 |
| Mean | 7.805 | 18.75 | 83.9 |
| Std Dev | ±0.024 | ±0.13 | ±0.49 |
//Table 2: Dissolved oxygen, temperature, and saturation measurements over four cycles, including mean values and standard deviations.//

The average reading was 7.81 mg/L (σ = ±0.024 mg/L) at a water temperature of 18.75°C. The saturation table in the mentioned report of the Vermont Department of Environmental Conservation lists 9.45 mg/L at 18°C and 9.26 mg/L at 19°C; interpolating for 18.75°C gives about 9.31 mg/L at full saturation. The measured 7.81 mg/L is therefore about 84% of the saturation value, which is right in the expected range for normal tap water (typically 80–95% depending on standing time and aeration).
**
These results confirm three things:**
  * The optical sensor produces readings that match physical expectations
  * RS485 communication from the sensor through the isolated adapter to the ESP32 works without data errors
  * The built-in temperature compensation works correctly. The minimal variation between readings (σ = ±0.024 mg/L, or 0.3%) demonstrates the sensor gives consistent results across independent power-on cycles

This test shows that the sensor works and gives repeatable results, but it is not the same as a full calibration across the whole measurement range. To measure the absolute accuracy properly, a comparison against a certified reference instrument (such as a calibrated WTW FDO 925 probe) would be needed, which was outside the scope of this prototype. The sample size of 𝑛 = 4 is enough to show good repeatability, but not enough to assess long-term drift or day-to-day changes.

<imgcaption image13|>{{ :ip:ws2025:do_sensor:bild13.png?nolink | DO and temperature measurements over four test cycles. The results match expected values for normal tap water.}}</imgcaption>

Two-Point Calibration Procedure for Field Deployment: Before the system is deployed, the manufacturer’s two-point calibration will be carried out by LINEG technicians and repeated at every weekly maintenance visit to correct for membrane aging. The full procedure is described in the sensor wiki (DFRobot, o.J.c) and works as follows:

  - **100% Saturation Calibration:** Pure water (distilled or deionized) is aerated with an air pump for about one hour, then left to sit for 30 minutes to stabilize. The sensor is placed in this water, and once the reading is stable, the 100% calibration command is sent via Modbus.
  - **Zero-Point Calibration (0% DO):** A 5% sodium sulfite (Na2SO3) solution is made by dissolving 5 g of anhydrous sodium sulfite in 95 g of pure water, then left to stand for at least one hour so all the oxygen is consumed. The manufacturer suggests adding a small amount of cobalt chloride as a catalyst. The sensor is placed in this solution, and once the reading is stable, the zero-calibration command is sent.

Both steps should be done in a calm, shaded spot to avoid interference, and the sensor needs to sit in each solution long enough for its temperature to match the liquid (DFRobot, o. J.c). After calibration, the manufacturer specifies an accuracy of ±0.2 mg/L across the 0–20 mg/L range. The firmware already has adjustable offset and span settings built in, so technicians can calibrate without touching the code.

The pressure sensor was zeroed by reading its output voltage at atmospheric pressure (zero gauge). The ESP32 ADC measured 0.180V at this baseline, which differs from the datasheet value of 0.321V. This kind of offset is normal and comes from small manufacturing differences between individual sensor units (DFRobot, o. J.b). The measured offset is stored in the firmware and used to calculate pressure from all future readings, giving accurate values relative to atmospheric pressure.


----

==== 2.3 Power Supply (Rak) ====
This section focuses on the measurement station’s power supply. The design is based on datasheets, conservative estimates of power and current, as well as derived calculations. The resulting decisions were later discarded by the IoT lab staff for cost reasons, while Mohamed documents the implemented alternative in his hardware section; the original concept is still presented here because it remains relevant for future prototypes. 

The power supply must support heterogeneous electrical loads for the different components, and it must ensure reliable operation across seasonal temperature changes. Depending on the other components, the power supply has three tasks: 
  - It powers the DO sensor directly with a voltage in the range of 12 to 15 V (DFRobot, o. J.c). 
  - From this, it provides two additional supply rails: 3.3 V for the Heltec board as an al-ways-on logic supply, and 5 V for the measurement peripherals. 
  - The sensor is intended to operate autonomously for a long period of time. 

=== 2.3.1 Battery chemistry ===
In an initial discussion with the HSRW IoT Lab staff, lithium thionyl chloride (Li-SOCl₂) is selected as the battery chemistry, because its characteristics match the intended use case: an autonomous outdoor measurement station requiring long runtime with only low to medium currents. Due to the high energy density, Li-SOCl₂-cells require little enclosure volume. The manufacturer specifies an operating temperature range of −60 °C to +85 °C, which covers extreme outdoor conditions. Typical self-discharge is low (<1% per year), so storage losses are not a limiting factor for autonomous operation (EVE Energy, 2015).

=== 2.3.2 Battery cells ===

EVE ER18505/S cells were selected as the energy source. According to Eve Energy (2015), their nominal voltage is 3.6 V and remains largely stable during discharge: under load it quickly drops to about 3.4 V and stays above roughly 3.3 V for most of the usable capacity. This flat profile reduces the risk of falling below component minimum supply levels, which would otherwise cause measurement errors or device failure, and it reduces the need for additional regulation such as LDOs or buck/boost converters.

<imgcaption image2|>{{ :ip:ws2025:do_sensor:figure2.png?nolink |Cell discharge curve compared with that of an aged cell. Source: EVE ENERGY 2015.  }}</imgcaption>

=== 2.3.3 Battery pack ===
A battery pack uses a total of eight lithium thionyl chloride (Li-SOCl₂) cells of type EVE ER18505/S. Each cell has a nominal voltage of 3.6 V and a capacity of about 4.0 Ah. Four cells are connected in series, and two of these series strings are connected in parallel. This results in a 4S2P pack with the following characteristics:

^ Dimension 	^ Single cell 	^ 4-series, 2-parallel (8 cells) ^
| Nominal voltage 	| 3.6 V 	| 14.4 V | 
| Plateau voltage 	| ca. 3.4 V 	| ca. 13.6 V | 
| Capacity 	| ca. 4.0 Ah 	| ca. 8.0 Ah | 
| Nominal energy 	| ca. 13.7–14.4 Wh 	| ca. 110–115 Wh | 
| max. continuous current 	| 130 mA 	| ca. 260 mA | 
| max. pulse current 	| 180 mA 	| ca. 360 mA |
//Table 3: Electrical characteristics of the EVE ER18505/S cell and the 4S2P battery pack. Source: EVE Energy (2015). The values for the 4S2P pack are derived from calculations.//


**The design addresses two key issues:** 
  - According to its data sheet, the DO sensor requires at least 10 V. Four cells connected in series provide roughly 12–15 V throughout the usable service life, so the sensor always operates within a well-defined supply range (DFRobot, o. J.a).
  - Li-SOCl₂ cells allow only limited continuous current. System peaks are in the range of 150–180 mA. With a single 4S string (4S1P), each cell would operate close to its continuous current limit. Using two 4S strings in parallel (4S2P) splits the current, reducing it to approximately 75–90 mA per cell. 

=== 2.3.4 Power domains ===
The design uses three voltage domains. Domain 1 is the 12–15 V battery rail and supplies the DO sensor directly. Switching regulators derive domain 2 (3.3 V, always on) for the Heltec ESP32/LoRa board and domain 3 (5 V, measurement-only) for the pressure sensor and the UART-to-RS485 converter. To minimize sleep consumption, a switched measurement domain disconnects non-essential loads. A P-channel MOSFET high-side switch is placed in series with the DO sensor supply and the 5 V regulator input and is controlled by an ESP32 GPIO. Three states are to be considered: Sleep, Sense + Compute (no LoRa), and Peak (with LoRa).

^ Parameter ^ Sleep ^ Sense + Compute (without LoRa) ^ Peak (Measuring + LoRa) ^
| ESP current at 3.3 V | ca. 0.05 mA | ca. 100 mA | ca. 250 mA |
| ESP power at 3.3 V | negligible | ca. 0.33 W | ca. 0.83 W |
| 5 V load (RS485 + pressure sensor) | 0 mA | ca. 23 mA | ca. 23 mA |
| 5 V rail power | 0 W | ca. 0.12 W | ca. 0.12 W |
| DO sensor power | 0 W | ca. 0.20 W | ca. 0.20 W |
| Total power | < 0.1 W | ca. 0.65 W | ca. 1.15 W |
| Estimated 4S bus current | ca. 0.02–0.03 mA | ca. 0.11–0.14 A | ca. 0.15–0.18 A |
| Current per 4S string (4S2P) | ca. 0.01–0.015 mA | ca. 55–70 mA | ca. 75–90 mA |
| ER18505/S cell limits | – | 130 mA continuous, 180 mA pulse | 130 mA continuous, 180 mA pulse |
//Table 4: Operating states and load conditions. Sources: Based on datasheet values from DFRobot (o. J.a–c) and EVE Energy (2015), as well as conservative estimations derived from HelTec (2022).//

In the peak case, the total current on the 4S bus is about 150–180 mA. With the 4S2P configuration, this current is split across two strings, so each cell only sees 75–90 mA. This is below the continuous current limit (130 mA) and the allowable pulse current (180 mA).

**For the runtime estimate, the following assumptions are used:**

  * Peak current:			≈ 0.15 A
  * Sleep current:			≈ 0.03 mA
  * Capacity: 			        ≈ 8000 mAh
  * Measurement schedule:		4 measurements per hour; 15 s per measurement 60 s/h in peak mode; 3540 s/h in sleep mode

**This yields:**

^ Dimensions ^ Value ^
| Peak charge demand per hour | ≈ 2.5 As (≈ 0.69 mAh) |
| Sleep charge demand per hour | ≈ 0.11 As (≈ 0.03 mAh) |
| Total demand | ≈ 0.72 mAh per hour (≈ 17.3 mAh per day) |
| Calculated runtime | ≈ 463 days (≈ 1.3 years) |
//Table 5: Calculated charge demands and runtime. Source: Values derived from calculated results.//

Including realistic losses, temperature effects, and a generous safety margin, an operating time of about one year is to be expected. With shorter measurement durations or lower measurement rates, this period can be extended further. Overall, the concept meets the key requirements. Each component is supplied according to its electrical needs, and the chosen battery chemistry satisfies both the external environmental requirements and the internal electrical constraints. At €47.92 (as of January 2026) for a complete 4S2P pack, the power-supply cost is within an acceptable range. The mechanical form factor remains manageable and can be adapted to different enclosure designs. In conclusion, the implementation of this battery concept should be considered for future projects.


----


==== 2.4 Data Handling (Althaus, Rausch) ====
The following section divides data handling into two subchapters. First, the choice of technology will be explained and then the choice of a visualization tool and its implementation in will be discussed. In general, while being separated fields of expertise and knowledge, the subgroup worked closely together, especially in terms of troubleshooting.
 
The platform https://gitlab.hsrw.eu/  was used for collaborative work and versioning of the application system and its components. Tasks were divided up using the git-workflow and developed in separate branches.

=== 2.4.1 Data Transmission (Rausch) ===
A major discussion as part of the data handling was how the data flows from our entry point to the databases we set up. Like already mentioned in the hardware section, we decided early to use LoRaWAN to send the data. For the data handling or more precisely the backend of our Projekt, we deemed it important for the data to be open source and thus for the data to be available from a centralised point. This is why our decision fell to using MQTT as the transmission protocol. Furthermore, we decided on trying the MING stack for our visualisation of the collected Data, as well as an added route for a PostGIS database to save data long term in an attempt to host an API with the findings. MING stands for MQTT, InfluxDB, Node-Red and Grafana, which are the components making up the software. In order to test our approach, we designed a docker system that is used to set up the entire stack over multiple containers that interact with each other. For testing purposes, we also ended up adding a local Mosquitto MQTT in our docker system. This system allows us to test with LoRaWAN but also use a Wi-Fi-connection in the case a technology switch is intended.

The decision to use the MING stack was ultimately made due to its usage in general IoT-Environments, as well as its scalability and easy visualisation with Grafana, which is discussed in the second subchapter. In addition to this the decision to use docker was made for easy and quick deployment on multiple devices, so that testing can be carried out by multiple people without any intensive installations
In order to understand how the stack works, a quick explanation on how MQTT works is necessary. In short MQTT is a data transfer protocol that allows data to be pushed into different topics. A topic here is basically a hierarchical string similar to that of a File System, for example “do/sensor/data”. Devices can publish and/or subscribe to these topics. When data gets published to a topic, the MQTT forwards the data to all active subscribers, similar to how a standard observer pattern works.

Node-Red on its own is a low-code add-on for your JavaScript that allows you to simplify JavaScript code into simple building blocks. These blocks represent functions in JavaScript. The flow line is hereby the order in which the functions call each other. This allows you to build an endpoint without having to code all of the standard calls yourself. Node-Red itself offers a good number of add-ons on its own, which includes already pre constructed nodes for connections to other systems and tools.

The transmission specifically works as follows. The entry point for data is our MQTT, which our Node-Red flow is subscribed to. Incoming data will now flow through Node-Red and the payload will be split and changed accordingly for both, our InfluxDB and our PostGIS database. Making for a quite concise flow of data.

<imgcaption image3|>{{ :ip:ws2025:do_sensor:figure3.png?nolink | Data Transmission chart. Source: Own illustration.}}</imgcaption>

As for our PostGIS database, the original goal was using it to give the data the opportunity to flow further with an added API which sadly did not get completed in time and is thus another step for additional development after the initial Project has concluded. The PostGIS database and the dataflow to it are both successfully implemented already. The following is a database diagram of the resulting table.

<imgcaption image4|>{{ :ip:ws2025:do_sensor:figure4.png?nolink |The PostGIS database model with the measurement table and its attributes. Source: Own illustration.}}</imgcaption>

The implementation of the MQTT and its connection to Node-Red ended up being a lot easier than originally imagined. We were even able to integrate it two ways, for the early testing purposes without a sensor. The work with node-red in general was a breeze and was quite a nice experience. However, it was not entirely without challenges. One of the major issues we ended up facing was implementing the PostGIS payload. Node-red is not a one and done app, it instead requires multiple downloadable add-ons that can be used to further the capabilities of the tool. In this case, node-red needed a PostgreSQL node that would be compatible with the geometry field added by PostGIS. Finding one and then implementing it in a way that works took multiple hours and ended up being the reason for the API to be delayed. This was due to missing documentation on insert statements, when it came to the nodes we found.

=== 2.4.2 Data Visualization (Althaus) ===

In order for the measured values sent by the sensor to be evaluated, they must be displayed in a structured manner in a user interface and made available for analysis purposes. The implementation must meet the following criteria:
  * High user-friendliness thanks to a simple user interface
  * Plattform-independent Access
  * A flexible range of data processing options
  * Filtering of data according to specified times/time windows
  * Low costs for installation and commissioning
In order to save development time, existing open source solutions were examined and compared with the above criteria. The web application Grafana was selected. 

Grafana allows you to freely configure how data is displayed. Among other things, you can choose from a wide range of chart types for visualization or, in the case of a line chart, switch directly to the table view. 

In addition, further visual adjustments can be made so that users can optimize the display for analysis purposes. The data is retrieved using the Flux syntax. Various parameters and filters are set, which enable one or more measured values to be queried. Furthermore, the measured values can be filtered using tags. In this way, the data to be displayed can be precisely controlled.

The dashboards provide an overview, in which several visualizations are organized thematically and integrated for direct display. Within a dashboard, the desired time window can be specified, which is automatically applied to all visualizations. With the live function, the transmitted measurement data is automatically updated at intervals of 5-10 seconds. Since the sensor transmits the measurement data at intervals of 5 minutes, no significant loss of measurement data is to be expected, so that live transmission is compatible with these values.

<imgcaption image5|>{{ :ip:ws2025:do_sensor:figure5.png?nolink |The Grafana Dashboard. Source: Own illustration.}}</imgcaption>

The database management system (DBMS) InfluxDB was chosen to manage the data. InfluxDB is also open source and specializes in managing large volumes of time series data. The DBMS automatically adds a timestamp when writing data, so that this does not have to be sent by the sensor. Furthermore, the data does not require a rigid framework for recording the measurement data, as is the case with other DBMSs. This makes it possible to add further measurement categories without any additional effort. This provides a suitable basis for installing additional sensors and flexibly expanding the data packets with the corresponding values.
 
The arrangement of the payload data is restructured in Node Red using a function node. This creates an array with two blocks. In the first block (Fields), the measured values and their designations are transferred as key-value pairs, and in the second (Tags), further assignment criteria follow, also as key-value pairs.

In addition to the payload, the data object contains the Measurement attribute, which specifies the purpose of the measurement.
Within the scope of this project, the following data structure was defined for the Fields, Tags, and Measurement:
  * Measurement:
    * Water Quality
  * Fields:
    * Dissolved Oxygen
    * Water Pressure
    * Water Temperature
  * Tags:
    * Location
    * Sensor

The desired structural changes only require an adjustment of the sensor payload and the assignment in the Node Red node. The DBMS uses the reorganized data structure without the need for further intervention.

The choice of the above tags ensures that multiple sensors can be used in different environments. The data is quickly transferred, chronologically sorted, and made available for visualization thanks to the compact database structure.
To test the selected application system, the focus was placed on the data itself.

Since a general data structure could be derived from the requirements, the focus could be placed on implementing the data flow.

The data is to be sent via the sensor, received and forwarded via MQTT, and prepared for writing to the database via Node Red.

Since the data required for the data flow could not be sent by the prototype itself at the beginning of the project phase (it first had to be developed), it had to be replaced by randomly generated test data. For a better overview, two different starting points were used to send the data packets: The first starting point is located within the Docker environment in the Node Red application. With the help of a so-called “Inject” element, test data in JSON format could be transferred directly to an InfluxDB node. To check for a successful write operation, the database was accessed directly via the Docker environment, and the corresponding entries were retrieved.

The second starting point was chosen outside the Docker environment so that almost the entire data flow could be simulated. The data was sent using a Bash script that was executed on the local machine and transferred the data to the MQTT container in the form of a payload.

The main challenge was to ensure the data flow from the initial starting point. The obstacle was setting up the Node RED nodes. In order for the data to be successfully written to the Influx database, an InfluxDB node had to be installed using the Node RED package palette and a function node had to be set up to customize the payload data structure. Several packages were available for installation, with different versions and documentation.

Due to the dependency of the function logic on the corresponding package and the fact that, depending on the selected package, no errors were output in the Node RED environment, complications arose in determining the cause.

After some research, the current package “node-red-contrib-influxdb Vers. 0.7.0.” was installed and the function logic was completed with the help of the accompanying documentation. A special feature was the use of tags and fields through an array structure in the message payload, as opposed to the usual transfer through the tag and field attributes of the message object.


----

==== 2.5 Cleaning Methods (Müsch, Shamsunnahar, Sultana) ====

This chapter focuses on the cleaning and anti-fouling subsystem of an autonomous optical dissolved oxygen (DO) sensor for long-term aquatic deployment. It describes the impact of biofouling on measurement accuracy and presents a passive copper mesh–based anti-fouling concept, including its design rationale, mechanism of action, experimental validation, and remaining limitations.

=== 2.5.1 Role Within the Overall System (Shamsunnahar, Sultana) ===

Within the overall autonomous DO monitoring system, the anti-fouling subsystem plays a supporting but essential role. While the sensing electronics and data transmission components define the nominal measurement capability, long-term data quality is determined by how well the sensing interface is preserved over time. 

In practical deployments, fouling-induced drift often becomes the dominant source of measurement error well before electronic limitations are reached (Delauney, Compère and Lehaitre, 2010).

By limiting biological growth at the sensing membrane, the anti-fouling subsystem stabilises oxygen transport conditions and preserves the optical measurement path. This directly extends deployment duration, reduces maintenance requirements, and supports reliable long-term autonomous operation.

=== 2.5.2 Description of the specific Area of the Prototype (Shamsunnahar, Sultana) ===


 In this chapter, we focus on the cleaning and anti-fouling subsystem of an automated optical dissolved oxygen (DO) sensor intended for long-term deployment in aquatic environments. Optical DO sensors rely on direct contact between the sensing membrane and the surrounding water. As a result, any biological growth at this interface directly affects the measurement by interfering with oxygen transport and optical signal transmission.

Biofouling in aquatic systems develops progressively, starting with the adsorption of organic molecules, followed by bacterial attachment, biofilm formation, and eventually macrofouling by algae or larger organisms (Delauney, Compère and Lehaitre, 2010). Once a biofilm forms on the sensor surface, it introduces an additional diffusion barrier and creates a local micro-environment in which oxygen is actively consumed by microbial respiration. This leads to a reduced oxygen concentration at the membrane compared to the bulk water, causing systematic underestimation of dissolved oxygen levels (Banna et al., 2014).

From a transport perspective, this effect can be described using Fick’s first law of diffusion: 

<WRAP center round box 10%>
𝐽   =   - D    $\frac{dC}{dx}$
</WRAP>


Where J is the oxygen flux toward the membrane, D is the diffusion coefficient of oxygen in water, and $\frac{dC}{dx}$ is the concentration gradient across the diffusive boundary layer. Biofouling increases the effective thickness of this boundary layer, which reduces oxygen flux and slows sensor response. Preventing or delaying fouling at the membrane is therefore essential for maintaining both measurement accuracy and response time. 

Within this scope, we investigated a passive copper-mesh anti-fouling system integrated into the sensor housing. The aim was to inhibit early-stage microbial settlement rather than mechanically removing established fouling. Alternative cleaning approaches were reviewed to support the selection of the proposed solution.

=== 2.5.3 Implementation of the Concept (Shamsunnahar, Sultana) ===


We realised the anti-fouling concept through the design and implementation of a copper wire mesh enclosure mounted around the DO sensor head. Copper was selected due to its well-documented antimicrobial properties in aquatic environments. When exposed to water, copper releases Cu⁺ and Cu²⁺ ions, which inhibit microbial growth through several physicochemical mechanisms.
 
At the cellular level, copper ions disrupt microbial cell membranes, bind to thiol groups in enzymes, and interfere with essential metabolic pathways. In addition, copper participates in redox reactions that generate reactive oxygen species (ROS). One representative reaction is:

<WRAP center round box 25%>
Cu⁺ + H2O2 → C²⁺ + OH- + .OH
</WRAP>


The resulting hydroxyl radicals cause oxidative damage to DNA, proteins, and lipids, thereby inhibiting cell replication and attachment (Grass, Rensing and Solioz, 2011).

By enclosing the sensor head within a copper mesh, we created a localised region with elevated copper ion concentration near the sensing membrane. While copper ions rapidly dilute in the surrounding water, the concentration within this region is sufficient to suppress microbial settlement and prevent the formation of the initial conditioning film that precedes biofilm development (Delauney, Compère and Lehaitre, 2010).

A key design constraint was ensuring that the anti-fouling system did not interfere with oxygen transport or optical measurements. To address this, we positioned the mesh at an offset distance of approximately 1–2 cm from the sensing membrane. This spacing allows sufficient water exchange and avoids optical interference while maintaining antifouling effectiveness.

=== 2.5.4 Used Methods, Tools and Technologies (Shamsunnahar, Sultana) ===

We developed the mechanical design of the anti-fouling cap using Autodesk Fusion 360, which allowed precise control over geometry, spacing, and mounting features. Prototypes were fabricated using additive manufacturing (3D printing), enabling rapid design iteration and modular construction.

A fine copper wire mesh (wire diameter approximately 0.1 mm) was mechanically fixed to the printed structure. Mechanical fixation was preferred over adhesives to avoid long-term degradation and unintended chemical interactions in the aquatic environment.

In parallel, we evaluated alternative anti-fouling strategies based on existing literature. Mechanical cleaning systems, such as wipers and rotating brushes, are effective at removing fouling but require motors, control electronics, and additional power, and they introduce mechanical wear points (Lewis, 2010). Surface-based approaches, including low-surface-energy coatings, reduce biological adhesion but often degrade over time and may affect optical performance (Zhou et al., 2015). These considerations supported the selection of a passive copper-based approach.

=== 2.5.5 Key Technical Decisions (Shamsunnahar, Sultana) ===

One of our main design decisions was the use of a passive anti-fouling strategy instead of an active mechanical cleaning system. Passive solutions reduce system complexity, eliminate moving parts, and minimise energy consumption, which are critical factors for long-term autonomous deployments.

Another important decision concerned the mesh-to-membrane spacing. Placing the mesh too close to the membrane would increase the thickness of the diffusive boundary layer and restrict oxygen transport, while excessive spacing would reduce copper ion effectiveness. The selected 1–2 cm offset represents a compromise between maintaining efficient oxygen diffusion and achieving sufficient anti-fouling performance.
 
We also designed the anti-fouling cap to be modular, allowing it to be removed or replaced independently of the sensor. This improves maintainability and enables future testing of alternative materials or geometries.

=== 2.5.6 Applied Method: Copper Mesh Anti-Fouling System (Müsch) ===

The solution employs a custom-designed, 3D-printed cap carrying a copper mesh barrier, mounted securely onto the DO sensor head. A critical challenge is balancing biofouling protection with sensor performance. Placing the mesh too close introduces measurement artifacts; too far reduces copper ion protection. Our design implements a specific 1–2 cm offset between the mesh and the sensor membrane.

**Offset Necessity (1–2 cm):**

  - Hydrodynamic: Mesh placed directly against the membrane would act as a baffle, restricting water movement and thickening the diffusion layer, causing sluggish response and potential oxygen depletion. The gap ensures sufficient water exchange, maintaining natural diffusion rates.
  - Optical: A metallic mesh in the optical near field could reflect excitation light or scatter emission light. The offset ensures the mesh is outside the primary optical path, preventing signal distortion.

**Construction:** A modular cap was CAD-designed (Autodesk Fusion 360) and 3D-printed with large windows to maximize water exchange. Commercially available copper wire mesh (0.1 mm diameter wire) is stitched onto the frame through pre-designed mounting holes, avoiding adhesives that might degrade. The cap utilizes an internal stud system to guarantee the 1–2 cm offset when mounted. Screw-Tightening ensures a firm fit on the sensor head and prevents slipping during long-term deployment underwater.

**Two developed variants:**
  * Full-Coverage: Mesh covering sides and front/top, providing maximum biological protection.
  * Front-Open: Mesh on sides only, maximizing mixing directly before the membrane.

<imgcaption image8|>{{ :ip:ws2025:do_sensor:figure8.png?nolink |Prototypes of the Full-Coverage (left) and Front-Open (right) Custom Mesh-Sensor-Cap. Source: Own Illustration.}}</imgcaption>

=== 2.5.7 Mechanism of Action (Müsch) ===

The copper mesh functions through multiple biocidal pathways driven by copper ion (Cu2+) release (Grass et al., 2011). Contact killing occurs when organisms settling on the mesh experience immediate membrane depolarization and cell wall rupture. Copper ions catalyse Reactive Oxygen Species (ROS) production, attacking DNA, proteins, and lipids.

By enclosing the sensor head in a mesh cage, a micro-environment with elevated copper ion concentration is created within the 1–2 cm gap. While low enough to disperse into open water, this concentration inhibits planktonic bacteria and algae from settling on the membrane, preventing the conditioning film that precedes all subsequent fouling.

=== 2.5.8 Experimental Validation, Results and Interpretation (Müsch) ===

To verify the design does not negatively impact measurement capabilities, comparative experiments were conducted using the automated sensor node. The node performed cyclic routines (5s warmup, sensor reading, LoRa transmission) in a water reservoir after thermal equilibration. Three configurations were tested: Full Coverage, Front Open, and No Mesh.

^ Configuration ^ n ^ Mean (mg/L) ^ Min–Max (mg/L) ^ Std. dev. ^
| Full coverage | 9  | 7.934 | 7.76–8.08 | 0.129 |
| Front open    | 18 | 7.917 | 7.75–8.17 | 0.144 |
| No mesh       | 11 | 7.845 | 7.66–8.07 | 0.178 |
// Table 6: Comparison of DO sensor configurations measuring dissolved oxygen.//

Both mesh configurations produce statistically similar mean values (Full Coverage: 7.93 mg/L, Front Open: 7.92 mg/L). If the mesh restricted oxygen diffusion, the Full Coverage unit would show lower DO values. The virtual identity confirms that the 1–2 cm offset and mesh porosity allow adequate hydrodynamic exchange. The No Mesh reference shows a slightly lower mean (7.85 mg/L), but this difference (0.08 mg/L) is well within the standard deviation (0.13–0.18 mg/L) and attributable to run-to-run variation in temperature and mixing. The comparable standard deviation across all setups confirms the mesh does not introduce optical noise.

The evaluation is limited by sample size and slightly different environmental conditions between runs. Temperature and mixing were not strictly controlled. The dataset demonstrates short-term compatibility but cannot fully quantify antifouling performance. Long-term drift reduction and biofilm suppression must be validated through longer field deployments.


=== 2.5.9 Reference-Based Calibration and Bias Analysis (Müsch) ===

**2.5.9.1 Motivation and Relation to the System Calibration Concept**

The prototype evaluation confirms that the dissolved-oxygen (DO) sensing chain is functional and repeatable under laboratory conditions. However, quantifying accuracy requires direct comparison against a certified reference instrument across relevant operating regimes (e.g., different hydrodynamic states and mesh configurations). In addition, the manufacturer recommends a two-point field calibration (100% saturation and a zero-oxygen solution) as a baseline for routine maintenance. Within the project scope, a full two-point procedure and broad controlled sweeps over the full DO range were not feasible.

For the intended long-term deployment with copper mesh, a second question becomes operationally critical: Does the mesh (and the local hydrodynamics around it) introduce a systematic bias, and can this bias be compensated by a simple calibration function that is feasible for embedded implementation?

Therefore, this section documents a reference-based calibration experiment intended to:
  * quantify mesh/flow-dependent bias and
  * derive practical calibration parameters for field deployment.

**2.5.9.2 Experimental Setup and Tested Water Samples**

A reference probe (WTW FDO 925) and the project probe were mounted in the same reservoir and measured in parallel over time. The project probe ran custom firmware to enable precise logging of sensor readings and event markers (mesh changes, flow regime changes, and cooling steps to maintain approximately 20°C throughout the experiments).

<imgcaption image_calib_mounting|>
{{ :ip:ws2025:do_sensor:img_5307.jpg?nolink&700 | Mounting of reference and project probe in Sample 2 (Tap-Water).}}
</imgcaption>

**Logging-Intervals**
  * Project sensor (SEN0680): logged every **5 seconds**
  * Reference instrument (WTW FDO 925): read approx. **every minute** and entered near-synchronously into the same CSV record via serial command:
<code>
r <DO_READING> <TEMP>
</code>

To induce DO dynamics, dissolved oxygen was increased periodically (every 5 minutes) using controlled stirring (magnetic stirrer), followed by quasi-steady segments (15 minutes) in which DO gradually decayed.

**Configurations**

Three sensor configurations:
  * **none**: no mesh
  * **mesh1**: front-open mesh variant
  * **mesh2**: full-coverage mesh variant

Three flow regimes:
  * **off**: no intentional flow (stagnant)
  * **low**: gentle stirring (approximate laminar mixing)
  * **med**: increased stirring intensity

**Water samples**

^ Sample ^ Description ^ Volume ^ Typical DO ^
| Sample 1 | BSB water / “Biological Oxygen Demand” | 1600 mL | ~9 mg/L |
| Sample 2 | Tap water | 3500 mL | ~6–8 mg/L |
| Sample 3 | Mussel water, aerated | 3000 mL | ~8–9 mg/L |
//Table 6.1: Overview of water samples used for reference-based calibration and bias analysis.//

**Operational observation (Sample 3, medium flow):**
At medium stirring intensity, the vortex generated by the magnetic stir bar entrained air bubbles and transported them preferentially to the reference probe. This can cause short transient phases in which the reference responds earlier than the project sensor despite similar positioning. Consequently, quantitative calibration fitting was prioritised on quasi-steady segments rather than immediate post-aeration mixing transients.

**2.5.9.3 Calibration Model and Data Processing**

To keep calibration explainable and suitable for embedded deployment, a linear model was selected:

<code>
DO_ref = m · DO_proj + c
</code>

where:
  * **DO_ref** is the reference DO in mg/L (WTW FDO 925)
  * **DO_proj** is the project sensor reading (scaled to mg/L)
  * **m** and **c** are slope and offset estimated via least-squares fitting

For operational interpretation, bias was computed per configuration and flow regime as:

<code>
ΔDO = DO_proj − DO_ref
</code>

Bias was summarised as **mean ± standard deviation (SD)** to separate systematic over-/underestimation from variability.

**Segment selection principle (important for robust fitting):**
  * Prefer quasi-steady phases (decay / stable plateaus).
  * Down-weight or exclude short-lived transients immediately after aeration, especially under **med** flow (bubble/vortex artifacts).

**2.5.9.4 Results: Influence of Mesh and Flow (Bias)**

Across all three samples, the bias analysis indicates that both mesh configuration and flow regime influence measurement behaviour.

  * In stagnant conditions (**off**), local gradients and boundary-layer effects are expected to be stronger, which can increase both bias and variance.
  * In contrast, gentle flow (**low**) improves mixing near the membrane and reduces local gradients, typically improving agreement with the reference.

**Key patterns observed:**
  * **mesh2 + low flow** produced the most balanced behaviour across samples, with bias values closest to zero and comparatively low variability.
  * **no-mesh** more frequently exhibited **positive bias** (tendency to overestimate DO), and in some cases higher variability.
  * **medium flow** can yield good agreement during steady phases, but is more susceptible to transient artifacts during aeration and bubble transport (notably in Sample 3).

<imgcaption image_bias_sample1|>
{{ :ip:ws2025:do_sensor:report_mesh_influence_bsb_water_probe1.png?nolink&700 | Bias summary (mean ± SD) across mesh and flow regimes for Sample 1 (BSB-Water). Source: Own analysis.}}
</imgcaption>
<imgcaption image_bias_sample2|>
{{ :ip:ws2025:do_sensor:report_mesh_influence_tap_water_probe2.png?nolink&700 | Bias summary (mean ± SD) across mesh and flow regimes for Sample 2 (Tap-Water). Source: Own analysis.}}
</imgcaption>
<imgcaption image_bias_sample3|>
{{ :ip:ws2025:do_sensor:report_mesh_influence_mussel_water_probe3.png?nolink&700 | Bias summary (mean ± SD) across mesh and flow regimes for Sample 3 (Mussel-Water). Source: Own analysis.}}
</imgcaption>

<imgcaption image_calib_timeseries_sample1|>
{{ :ip:ws2025:do_sensor:report_plot_bsb_water_probe1.png?nolink&700 | Time series comparison (reference points vs. project sensor) for Sample 1 (BSB-Water). Source: Own analysis.}}
</imgcaption>
<imgcaption image_calib_timeseries_sample2|>
{{ :ip:ws2025:do_sensor:report_plot_tap_water_probe2.png?nolink&700 | Time series comparison (reference points vs. project sensor) for Sample 2 (Tap-Water). Source: Own analysis.}}
</imgcaption>
<imgcaption image_calib_timeseries_sample3|>
{{ :ip:ws2025:do_sensor:report_plot_mussel_water_probe3.png?nolink&700 | Time series comparison (reference points vs. project sensor) for Sample 3 (Mussel-Water). Source: Own analysis.}}
</imgcaption>

The full results from the lab experiments including the source codes for logging (during experiments) and analysis are provided for future reference:

  * {{ :ip:ws2025:do_sensor:experiment_analysis.zip | Ressources used for analysis (Archive)}}


**2.5.9.5 Recommended Calibration for Field Deployment (mesh2)**

The intended field scenario prioritises anti-fouling robustness; therefore **mesh2** is the most likely deployment configuration. Based on the reference-based fits and robustness across samples, the following strategy is recommended:

  * If flow classification is feasible, a **two-regime approach** (**low** vs. **off**) is preferred because it preserves accuracy under stagnant conditions while keeping the model simple.
  * Otherwise, a **single-curve approach** is acceptable when operational simplicity is prioritised.

^ Regime ^ Calibration function ^
| mesh2 / low | DO_ref ≈ 1.249 · DO_proj − 1.763 |
| mesh2 / off | DO_ref ≈ 1.238 · DO_proj − 1.673 |
| mesh2 / all | DO_ref ≈ 1.231 · DO_proj − 1.597 |
//Table 6.2: Example calibration functions derived from the dataset for mesh2.//

**Note:** These parameters are derived from laboratory measurements (three samples at controlled temperature and defined stirring regimes). Field conditions may differ (biofouling, temperature swings, real turbulence). A dedicated field validation phase is recommended.


**2.5.9.6 Interpretation and Operational Notes**

**Mesh-related effects:**
The copper mesh modifies the local hydrodynamics around the sensing membrane. The results indicate that **mesh2** can be calibrated to high short-term accuracy and that **gentle flow** reduces boundary-layer effects. Importantly, the mesh does not introduce unacceptable short-term noise in the presented experiments, provided that the hydrodynamic regime during calibration and operation is broadly comparable.

**Flow-related effects:**
Gentle flow improves agreement with the reference by reducing local gradients and improving exchange at the membrane interface. Medium flow can be acceptable during steady phases, but may amplify transient artifacts during aeration and bubble transport (vortex entrainment), which is particularly relevant for laboratory mixing setups.

**Conservative monitoring perspective (alerts vs. calibration):**
For environmental monitoring, missing low-oxygen events is typically more harmful than triggering occasional false alarms. Any safety margin should be implemented in the **alert logic** (e.g., slightly lower alarm thresholds or persistence-based alarms) rather than by intentionally biasing the calibration function, which would reduce comparability and interpretability of long-term time series.

**Maintenance:**
Depending on pollution and suspended solids, the copper mesh can clog with dirt and organic material (observed during Sample 3). Reduced permeability and accumulation around the mesh can impair exchange near the sensing surface, leading to drift and/or reduced responsiveness. Periodic inspection and cleaning intervals should therefore be defined based on deployment conditions.

**2.5.9.7 Limitations**

  * The experiment uses three representative samples but does not cover the full 0–20 mg/L DO range; broader controlled sweeps would improve generality.
  * Temperature was held approximately constant (~20°C). Temperature dependency and compensation should be validated for seasonal field deployment.
  * Medium-flow phases can introduce short-lived reference-leading artifacts due to bubble/vortex transport; calibration should therefore prioritise quasi-steady segments.
  * Long-term drift and fouling behaviour under real environmental conditions remain to be validated in extended deployments.

=== 2.5.10 Limitations, remaining Issues and possible Improvements (Shamsunnahar, Sultana) ===

The performance of copper-based anti-fouling systems depends on environmental factors such as temperature, pH, salinity, and flow velocity, which influence both copper ion release rates and convective transport. These parameters were not systematically investigated in this study. 
Furthermore, while copper is effective against microorganisms and early-stage fouling, it may be less effective against macrofouling during very long deployments. Our evaluation was limited to short-term laboratory testing and does not fully quantify long-term reductions in biofilm formation or sensor drift. Potential environmental impacts associated with continuous copper release were also outside the scope of this project.

In future work, we plan to conduct long-term field deployments to evaluate the antifouling performance under realistic environmental conditions. Coupled diffusion–reaction models could be developed to better understand oxygen transport and copper ion concentration near the sensing membrane under varying flow regimes. 

Further optimisation of mesh geometry and porosity may improve convective mixing while maintaining antifouling effectiveness. A hybrid approach, combining passive copper protection with occasional low-power mechanical cleaning, could provide increased robustness against both microfouling and macrofouling. In addition, environmentally friendly surface coatings could be explored as complementary measures to further extend maintenance-free deployment duration.

----

==== 2.6 Housing (Schelb, Schöne, Sloma) ====

The housing represents a central component of the overall system, as it protects the sensitive electronics of the autonomous measurement system from environmental influences while simultaneously enabling practical field deployment. Beyond its protective function, the housing significantly affects maintenance effort and operational reliability under real-world conditions. When installation in public spaces such as water bodies or bridge structures is envisaged, not only technical requirements but also usage-related aspects must be considered, especially the risk of vandalism in public environments (Nowak et al., 2024, pp. 2 ff.).

The objective of the housing design was therefore to develop a robust, cost-effective, and maintenance-friendly solution that meets the requirements of outdoor operation and integrates seamlessly into the overall concept of the autonomous measurement system. The housing was intended as a prototype solution that can be functionally tested while also allowing conclusions to be drawn regarding possible further developments for long-term deployment.

=== 2.6.1 Requirements for the Housing in Outdoor Use ===
Several fundamental requirements arose for the planned outdoor application. First, sufficient protection against precipitation, splash water, and temporary submersion had to be ensured, as the system is operated near water bodies and is regularly exposed to high humidity and changing weather conditions.

Furthermore, the UV resistance of the housing material plays an important role. Polymer-based materials are subject to aging under prolonged solar radiation, which can lead to embrittlement and mechanical weakening (Saputra et al., 2025, pp. 11 ff.).
Another important aspect is the thermal behaviour of the housing. Direct solar radiation can cause significant heating of the interior, which may negatively affect the service life of electronic components (Wankhede et al., 2007, p. 858). Therefore, the housing should be designed in a way that avoids excessive internal heating.

In addition to these technical requirements, ease of maintenance was a key consideration. Since battery replacement and maintenance work are necessary, the housing should be easy to open without compromising its protective function. At the same time, the housing should be as compact as possible to minimize material usage and enable unobtrusive installation.

Finally, vandalism prevention was also considered. In publicly accessible areas, there is an increased risk of damage or manipulation (Nowak et al., 2024, pp. 2 ff.). A deliberately simple and technically inconspicuous appearance can help reduce the perception of the housing as a valuable or interesting technical installation. Studies in the field of crime prevention indicate that unobtrusive design concepts in public spaces can reduce the risk of vandalism (Levan, 2005, p. 19).

=== 2.6.2 Design Concept of the Pipe-Based Housing ===
Based on the requirements outlined above, a housing concept was developed sing a commercially available polypropylene drainage pipe. Polypropylene is widely used in technical applications and is characterized by good chemical resistance, sufficient mechanical stability, and ease of processing. In addition, the material is cost-effective and widely available (Hossain et al., 2024, p. 1). An initial design of the housing concept is illustrated in the following figure.

<imgcaption image6|>{{ :ip:ws2025:do_sensor:figure6.jpg?nolink |A rendering of the first housing concept sketch. It shows the used pipe as the main component and the mounting board for easy access to the hardware. Source: Own illustration.}}</imgcaption>

The cylindrical pipe geometry offers several design advantages. It provides high structural stability against external loads and enables a vertical arrangement of components inside the housing. Electronics, battery, and antenna can be arranged compactly in a stacked configuration, while the sensor cables can be routed straight downward out of the housing. This facilitates sensor installation in the water and reduces mechanical stress on the cables.

The housing was fabricated from a polypropylene drainage pipe with a diameter of 90 mm and cut to a length of approximately 61 cm, representing a compromise between sufficient internal space for the electronics and a compact overall design.

=== 2.6.3 Implementation and Structural Design ===
The upper end of the pipe was sealed using a removable coupling. A metal handle was attached to this coupling, allowing it to be pulled off and providing easy access to the interior. Maintenance tasks such as battery replacement or functional checks can therefore be performed without fully disassembling the housing.

At the lower end, a sliding coupling was installed to achieve a closed termination. Two holes were drilled into this coupling to accommodate waterproof cable glands, through which the sensor cables are routed out of the housing, as shown in the figure of this chapter.

The electronic hardware is mounted on printed circuit boards, which are fixed to a separate mounting board manufactured to fit precisely using laser cutting. This board includes both the required mounting holes for the circuit boards and a handle opening to allow easy removal from the pipe. 

<imgcaption image7|>{{ :ip:ws2025:do_sensor:figure7.png?nolink |The design for the mounting board in Autodesk Fusion. Source: Own illustration.}}</imgcaption>

To secure the mounting board inside the housing, two plastic guide rails were bonded to opposite inner walls of the pipe. The mounting board can be inserted into these rails, providing a defined position and secure support. Additional stoppers installed at the lower end of the rails prevent the board from sliding down to the bottom of the housing, ensuring that the electronics remain in the intended position.
=== 2.6.4 Key Design Decisions and Rationale ===

The decision to use a polypropylene pipe as the housing material was primarily driven by requirements regarding cost, availability, and ease of processing. Compared to industrial enclosures, which are often certified and designed for long-term series applications, the chosen solution represents a cost-effective alternative.

The modular insertion concept using guide rails enables a clear separation between the housing and the electronics. Electronic components can be mounted, tested, or replaced independently of the housing, reducing maintenance effort by allowing the electronics to be removed as a single unit.

Another key design decision concerns the deliberately simple external appearance. By adopting the unobtrusive look of a plain pipe, the housing is less likely to be perceived as a technical installation, which may help reduce the risk of vandalism (Levan, 2005, p. 196).


<WRAP center round box 60%>
The material costs for the prototype housing consist of a polypropylene drainage pipe with socket (DN 90, 1 m), one sliding coupling, and two end caps (total cost: €14.26; OBI online catalog; status: 21 January 2026):
  * https://www.obi.de/p/2838803/marley-ht-rohr-mit-steckmuffe-dn-90-1000-mm,
  * https://www.obi.de/p/2839165/marley-ht-ueberschiebemuffe-dn-90,
  * https://www.obi.de/p/2839223/marley-ht-muffenstopfen-dn-90.
By comparison, commercially available industrial enclosures with defined protection ratings for outdoor use (e.g., weatherproof IP65 outdoor boxes or enclosures designed for industrial outdoor applications) are typically available at significantly higher price levels, depending on size, material, and configuration. 

An example is a weatherproof, lockable IP65 industrial enclosure (status: 21 January 2026):
https://www.wlan-shop24.de/mantar-sm-40-33-23-cabinet-weatherproof-lockable.

Additional material costs, such as cable glands or internal mounting components, would similarly apply to an industrial enclosure and would therefore be incurred in addition to the enclosure itself.
</WRAP>

=== 2.6.5 Challenges and Mitigation Measures ===
One of the central challenges of sealed outdoor enclosures is the formation of condensation inside the housing. Temperature fluctuations between day and night can cause humid air to condense, leading to water accumulation on electronic components (Joshy, 2018, pp. 7 ff.). To mitigate this effect, the use of silica gel as a desiccant can be considered (Hraiech et al., 2025, p. 1; Dahan et al., 2013, pp. 15 ff.).

Another issue is the limited UV resistance of polypropylene. Prolonged exposure to UV radiation can lead to material aging (Saputra et al., 2025, pp. 11 ff.). A possible countermeasure is coating the housing with a UV-resistant polymer paint (Brostow et al., 2020, p. 1), which could be implemented in the future to extend service life in outdoor environments.

Thermal heating of the housing can also be mitigated through appropriate surface coatings, which can significantly reduce internal temperatures (Wankhede et al., 2007, pp. 858 ff.).

Regarding mounting, a fixed integrated mounting solution was deliberately avoided because the exact deployment location was not defined in advance. Instead, the pipe-based design allows flexible attachment using pipe clamps, cable ties, or additional brackets, for example on bridge railings or similar structures.

During final assembly and integration of the electronic components, an issue related to the mechanical integration of the mounting board was identified. The mounting board, including the fully assembled electronics, could not be inserted into the housing using the intended guide rails, as the screws used to mount the printed circuit boards protruded slightly and interfered with the inner edges of the guide rails. As a result, the mounting board could not be slid into position as originally planned.

The primary reason for this issue was the delayed availability of the dissolved oxygen sensor, which prevented full assembly and dimensional verification of the electronics at the time the housing was manufactured. Due to long delivery times, the housing had to be completed before the final dimensions of the fully assembled electronics were known, making prior integration testing impossible.

As a practical solution, the mounting board together with the electronics was inserted into the housing without using the guide rails and positioned alongside them. In this configuration, the mounting board still fits securely within the housing and remains sufficiently stable for prototype operation.

For future use or further development of the prototype, the guide rail geometry could be adapted to accommodate the fully assembled mounting board, for example by increasing clearance or adjusting rail dimensions. This would allow the guide rail concept to be utilized as originally intended while maintaining compatibility with the final electronic assembly.

=== 2.6.6 Evaluation of Results and Limitations ===

The developed housing concept provides easy access to the electronics and supports flexible field installation, making it well suited for use as a prototype and for time-limited field tests. For deployment periods of several months, adequate functionality can be expected when appropriate protective measures such as UV coatings and moisture management are applied (Saputra et al., 2025, p. 11).

However, for multi-year continuous operation, increased requirements regarding material durability, sealing systems, and certifications are to be expected, as are typically met by industrial enclosures.

=== 2.6.7 Outlook and Potential Further Developments ===

Future developments could enhance the housing concept with UV-stabilized materials or certified industrial enclosures. In addition, integrated pressure equalization elements and location-specific mounting solutions could be considered. The insights gained from prototype operation provide a valuable basis for such further developments.

----

===== 3. Discussion =====

The following chapter presents the overall outcomes of the project and reflects on the results achieved across the different subsystems. It summarises the technical findings, evaluates the level of implementation reached by the prototype, and highlights the insights gained during development and testing. Based on these results, remaining limitations and perspectives for future work are outlined.
==== 3.1 General Outcome (Schöne) ====

The project resulted in the development of a comprehensive system concept for an autonomous dissolved oxygen monitoring station intended for long-term deployment in flowing waters. The primary outcome lies in the structured integration of sensing, data handling, housing, cleaning, and energy concepts into a coherent overall architecture. 

A notable challenge during the project was the high demand for practical hardware knowledge and experience in electronics assembly. This expertise was not evenly distributed across the project team, which resulted in large parts of the hardware design and integration being concentrated on a single team member.

This circumstance limited knowledge transfer within the group and increased dependency on individual contributions. Although other team members frequently attempted to support the hardware-related tasks, this support was inherently limited due to the lack of prior experience. It quickly became apparent that the level of technical and electrical knowledge required for effective hardware prototyping could not be acquired within a short project timeframe, further reinforcing the concentration of responsibility in this area.

In addition, communication between the parallel working subgroups could have been improved. Although informal coordination took place, a more structured workflow would likely have increased transparency and alignment between subsystems. Adopting a lightweight agile approach, such as regular short status meetings in the style of Scrum, could have been beneficial. For example, a weekly meeting at the beginning of the course session, in which each subgroup briefly reports on its current progress and challenges, may have helped to identify interdependencies earlier and reduce coordination overhead.

Nevertheless, a functional prototype was successfully realised for the core sensing and data handling chain. The dissolved oxygen sensor with an integrated temperature sensor, complemented by pressure measurements, was integrated into an operational measurement workflow that includes periodic data acquisition, local processing, wireless transmission, and backend-based storage and visualisation. 
The defined Method of Operation provides a clear and reproducible description of how the system is intended to function during autonomous operation, forming a solid basis for both implementation and future optimisation.

The data transmission and backend infrastructure represent a key technical achievement of the project. The use of LoRaWAN for low-power wireless communication, combined with an MQTT-based backend architecture, enabled flexible and scalable data handling. The implementation of the MING stack (MQTT, InfluxDB, Node-RED, and Grafana) allowed measurement data to be reliably received, processed, stored, and visualised. 
The successful deployment of this infrastructure using containerised services demonstrated that the system can be easily reproduced and tested across different environments. Even though the system was mostly tested with simulated test data, the complete data flow from entry point to visualisation could be validated.

A further significant outcome is the development and evaluation of the housing concept. The pipe-based polypropylene enclosure provided a cost-effective and mechanically robust solution suitable for outdoor use. The modular internal mounting concept enabled easy access to the electronics and supported flexible installation scenarios. While the housing was designed primarily as a prototype solution, it demonstrated practical suitability for short- to medium-term deployments and allowed conclusions to be drawn regarding future improvements for long-term operation.

The anti-fouling subsystem represents another central contribution of the project. A passive copper-mesh-based approach was designed, implemented, and experimentally evaluated. Short-term laboratory tests showed that the copper mesh did not negatively affect dissolved oxygen measurements when an appropriate offset distance was maintained. The modular design allows easy replacement and further experimentation with alternative geometries or materials. Although long-term antifouling performance could not be fully assessed within the project timeframe, the concept provides a technically sound and low-power solution that aligns well with the requirements of autonomous operation.

In contrast, the power supply subsystem remained largely at the conceptual design stage. A detailed theoretical power concept was developed, including battery chemistry selection, voltage domain definition, current and power budgeting, and runtime estimation. However, this concept could not be implemented in the final prototype due to practical and organisational constraints. As a result, long-term autonomous operation of the complete system was not fully demonstrated. Despite this limitation, the documented power supply design remains a valuable outcome, as it provides a well-founded reference for future prototype iterations.

<imgcaption image9|>{{ :ip:ws2025:do_sensor:bild9.jpg?nolink | Sideview of the fully constructed prototype. The Housing is fully assembled with the previously shown hardware safely concealed inside, with only the Pressure and DO Sensor on the outside. Additionally, the copper mesh is fixed onto the DO Sensor.}}</imgcaption>

Overall, the project successfully delivered a modular and extensible system concept supported by partial prototype implementations and experimental validation, as illustrated by the picture of the assembled prototype above, integrating housing, sensor hardware and copper mesh protection. 

While not all subsystems reached the same level of maturity, the project achieved its primary objective of demonstrating technical feasibility and identifying the key challenges associated with autonomous dissolved oxygen monitoring in natural aquatic environments.

==== 3.2 Technical Design Challenges and Solutions (Karim) ====

Several technical challenges came up during development:

**Component Availability (Relay vs. MOSFET):** The original plan was to use a P-Channel MOSFET for the sensor power switch, since MOSFETs have almost no current leakage. Due to component shortages, a mechanical relay (FRS1B) was used instead. The relay proves the switching logic works, but it draws about 90mA when active — far more than a MOSFET. Switching to the MOSFET in the final version will be important for reducing power consumption.

**Infrastructure Limitations:** The system was originally designed to send data over LoRaWAN for long-range coverage. However, testing showed that the local LoRaWAN gateway in Kamp-Lintfort is currently offline. As a workaround, the system was switched to use the ESP32s built-in WiFi instead. Because of the modular firmware design, this change did not require any hardware modifications. The LoRa-E5 module stays on the board and can be activated later when the gateway comes back online.

**Sensor Calibration:** The prototype validation used a single-point ambient check with tap water at known temperature, which confirmed correct operation and good repeatability (σ = ±0.024 mg/L) against the saturation table of the VT WSMD Wastewater Program (Vermont Department of Environmental Conservation, o. J.). Full two-point calibration using sodium sulphite (0% DO) and air-saturated water (100% DO) is planned for the deployment phase and will be part of the weekly maintenance routine. The firmware already supports this through configurable offset and span parameters.

==== 3.3 Technical Economic Feasibility and Design Trade-offs (Karim) ====

One of LINEG’s main requirements was that the system should be cheap enough to deploy at multiple locations. The total hardware cost for this prototype is about €194:

  * Optical DO Sensor (SEN0680): €121.86
  * Pressure Sensor (SEN0257): €21.00
  * RS485 Adapter (DFR0845): €19.75
  * LoRa-E5 Module: €16.90
  * Charger (Adafruit bq24074): €14.00

The ESP32, LiPo battery, and enclosure materials came from existing lab stock.

LINEG currently uses the WTW MultiLine Multi 3630 IDS (with FDO 925 optical oxygen sensor) for manual sampling, which costs about €3,900. This prototype achieves a 95% cost reduction compared to that device. The WTW system offers certified calibration and measures additional parameters like pH and conductivity. However, at €194 per node, multiple permanent monitoring points can be installed for the price of a single handheld device. This fits the broader trend in IoT water monitoring, where low-cost sensor nodes are increasingly seen as a practical alternative to expensive commercial equipment for distributed environmental monitoring (Jan et al., 2021.).

A conscious decision was made to size the battery for 3–4 weeks of operation instead of several months. LINEG technicians must already visit the sensor every seven days to clean the optical membrane. Designing for months of autonomy would mean a bigger, heavier, more expensive battery — with no real benefit, since someone is already coming every week regardless of the battery state.




==== 3.4 Outlook (Schöne) ====

The project outcomes provide a solid foundation for the future development of an autonomous dissolved oxygen monitoring system, while also highlighting several areas that require further work before the prototype can be considered field ready. A key next step is the full integration and long-term validation of all subsystems within a robust, deployable prototype. Extended outdoor deployments are essential to evaluate system reliability, energy autonomy, data stability, and resistance to environmental influences over prolonged periods.

For future development phases, it is recommended that the project team includes a higher proportion of members with technical and electrical engineering expertise. As the system evolves from a functional prototype toward a deployable solution, tasks such as hardware integration, power management optimization, debugging, and long-term reliability testing will become increasingly important.

From a hardware perspective, future iterations should focus on consolidating and completing the power supply concept. In particular, the relay currently used for power switching should be replaced with the originally planned P-channel MOSFET. This change would eliminate the continuous relay coil current of approximately 90 mA, resulting in significantly improved energy efficiency and extended battery lifetime. Furthermore, the current breadboard-based assembly should be migrated to a custom printed circuit board (PCB) to improve mechanical robustness, reduce system size, and enhance suitability for long-term outdoor deployment. The originally designed battery system should be fully implemented and combined with optimized energy management strategies to further extend operational lifetime.

The housing concept also offers potential for improvement. Future designs should consider the use of UV-stabilized materials, improved sealing strategies, and certified enclosures to support multi-year deployments in public and environmentally exposed locations. These measures are particularly important to ensure durability, weather resistance, and protection against unauthorized access or vandalism.

Regarding sensor maintenance, long-term field testing of the copper mesh anti-fouling system is required to quantitatively assess its effectiveness in reducing biofouling and sensor drift under varying environmental conditions. Hybrid approaches, combining passive anti-fouling measures with low-power mechanical cleaning mechanisms or environmentally compatible anti-fouling coatings, may further enhance sensor robustness and measurement stability over extended deployment periods.

On the software and data-handling side, completing the planned application programming interface (API) for structured data access would enable broader reuse of the collected measurements and facilitate integration into external monitoring platforms. In addition, the firmware should be extended to include offline data buffering, allowing measurements to be stored in local flash memory during periods of network unavailability and automatically uploaded once connectivity is restored. Advanced data analysis methods, automated plausibility checks, and alert mechanisms could further improve practical usability. In particular, drift detection algorithms should be implemented to monitor long-term sensor behaviour and notify technicians when calibration drift exceeds acceptable limits.

The modular structure of the prototype, together with the documented hardware concepts, data-handling architecture, and anti-fouling strategy, provides a solid basis for further refinement and integration. Future development efforts can build directly on the existing designs, extend the level of implementation across all subsystems, and address the remaining limitations identified in this report.

A critical step toward validating the system under realistic conditions is comprehensive field testing. A continuous deployment of at least four weeks in an actual LINEG water body is recommended to evaluate enclosure durability, energy autonomy, data reliability, and the rate of biological growth on the optical sensor surface. The experimental results and design rationales presented in this work support informed decision-making for these next development stages.

Overall, this project delivers a well-structured and well-documented starting point for continued development, enabling future teams to focus on optimization, validation, and scalability rather than on fundamental concept development.



----


===== 4. Conclusion (Karim) ====

This project produced a working prototype for remote water quality monitoring that meets LINEG’s core requirements. The system measures Dissolved Oxygen, Pressure, and Temperature every 2 hours, giving 12 readings per day — enough to detect contamination events while keeping the battery alive well beyond the seven-day maintenance window.

**Key results are:**
  * Power Architecture: The maintenance-synchronized power design supports about 5 weeks of operation on a single charge, far exceeding the 7-day requirement
  * Communication: The hardware supports both WiFi (used now for testing) and LoRaWAN (ready for future long-range deployment)
  * Sensor Integration: The switched-power design keeps sleep current near zero while still handling high-current industrial sensors
  * Cost: At €194 per node, the system costs 95% less than LINEG’s current handheld equipment, making multi-site deployment affordable

The prototype shows that a low-cost, maintainable monitoring node is feasible. By tying the power budget to the existing maintenance schedule, the design reaches a good balance between performance, cost, and complexity.

----

===== References =====

**Banna, S. et al. (2014).** Biofouling Control Strategies for Sensors Deployed in Aquatic Environments. Sensors, 14(4), pp. 583–604.

**Bouguera, T. et al. (2018).** Energy Consumption Model for Sensor Nodes Based on LoRa and LoRaWAN. Sensors, 18(7), 2104. Available at: https://doi.org/10.3390/s18072104 (Accessed: 7 February 2026).

**Brostow, W. et al. (2020).** Effects of UV Stabilizers on Polypropylene Outdoors. Materials.

**Chameleon Electronics (o. J.).** FRS1 Relay Datasheet – Subminiature SPDT Relay. Available at: https://www.box73.de/file_dl/bauelemente/FRS1.pdf (Accessed: 6 February 2026).

**Dahan, A. et al. (2013).** The Application of PEEK to the Packaging of Implantable Electronic Devices: Water Permeation Calculation Method and Maximum Achievable Lifetime with Desiccant. Journal of Microelectronics and Electronic Packaging, pp. 15–22.

**Delauney, L., Compère, C. and Lehaitre, M. (2010).** Biofouling Protection for Marine Environmental Sensors. Ocean Science, 6(2), pp. 503–511.

**DFRobot (o. J.a).** Gravity: Active Isolated RS485 to UART Signal Adapter Module (SKU: DFR0845). Product Page. Available at: https://wiki.dfrobot.com/Gravity_Active_Isolated_RS485_to_UART_Signal_Converter_SKU_DFR0845 (Accessed: 6 February 2026).

**DFRobot (o. J.b).** Gravity: Water Pressure Sensor (SKU: SEN0257). DFRobot Wiki. Available at: https://wiki.dfrobot.com/Gravity__Water_Pressure_Sensor_SKU__SEN0257 (Accessed: 6 February 2026).

**DFRobot (o. J.c).** RS485 Fluorescence Dissolved Oxygen Sensor (Freshwater), SKU: SEN0680. DFRobot Wiki. Available at: https://wiki.dfrobot.com/SKU_SEN0680_RS485_Dissolved_Oxygen_Sensor_Freshwater (Accessed: 6 February 2026).

**Espressif Systems (o. J.).** ESP32 Series Datasheet. Available at: https://documentation.espressif.com/esp32_datasheet_en.pdf (Accessed: 6 February 2026).

**European Parliament and Council (2000).** Directive 2000/60/EC Establishing a Framework for Community Action in the Field of Water Policy. Official Journal of the European Communities, L 327, pp. 1–73.

**EVE Energy Co., Ltd. (2015).** ER18505 Lithium-Thionyl Chloride (Li-SOCl₂) Battery: Technical Specification. Available at: https://www.akkuman.de/shop/mediafiles/PDF/EVE/10176.pdf (Accessed: 31 January 2026).

**Forhad, H.M. et al. (2024).** IoT Based Real-Time Water Quality Monitoring System in Water Treatment Plants (WTPs). Heliyon, 10(23), e40546. Available at: https://pmc.ncbi.nlm.nih.gov/articles/PMC11652906/ (Accessed: 7 February 2026).

**Grass, G., Rensing, C. and Solioz, M. (2011).** Metallic Copper as an Antimicrobial Surface. Applied and Environmental Microbiology, 77(5), pp. 1541–1547.

**Heltec Automation (2023).** WiFi LoRa 32 V3.2 LoRa Node Development Kit. Heltec Automation, pp. 11–13. Available at: https://resource.heltec.cn/download/WiFi_LoRa_32_V3/HTIT-WB32LA_V3.2.pdf (Accessed: 1 February 2026).

**Hossain, M. et al. (2024)**. Research and Application of Polypropylene: A Review. Discover Nano.

**Hraiech, N. et al. (2025).** Experimental Characterization of Silica Gel Adsorption and Desorption Isotherms Under Varying Temperature and Relative Humidity in a Fixed Bed Reactor. Scientific Reports.

**Jan, F., Min-Allah, N. and Düştegör, D. (2021).** IoT Based Smart Water Quality Monitoring: Recent Techniques, Trends and Challenges for Domestic Applications. Water, 13(13), 1729. Available at: https://www.mdpi.com/2073-4441/13/13/1729 (Accessed: 7 February 2026).

**Joshy, S. (2018).** Humidity Effects in Electronic Enclosures. Dissertation, Technical University of Denmark (DTU).

**LINEG (o. J.).** LINEG – Verantwortung für die Umwelt. Available at: https://www.lineg.de/ (Accessed: 20 January 2026).

**Levan, V. (2005).** Situational Crime Prevention in Public Housing. Penal Issues, CESDIP, pp. 19–22.

**Lewis, J.K. (2010).** Mechanical Wiper Systems for Optical Water Quality Sensors. Journal of Environmental Monitoring, 12, pp. 197–204.

**Nowak, A. et al. (2024).** Impact of Vandalism on Avian Nest-Box Studies: Challenges and Strategies for Research and Conservation. Biologia, pp. 3137–3143.

**Onsemi (o. J.).** NCP1402 – 200 mA, One Cell Li-Ion Battery Step-Up DC-DC Converter. Datasheet. Available at: https://www.onsemi.com/pdf/datasheet/ncp1402-d.pdf (Accessed: 6 February 2026).

**Saputra, I. et al. (2025).** Study of the Effect of Ultraviolet Exposure Duration on Polypropylene Properties. Jurnal Sains Materi Indonesia, pp. 11–18.

**Seeed Studio (o. J.).** LoRa-E5 Module Datasheet V1.0. Available at: https://files.seeedstudio.com/products/317990687/res/LoRa-E5+module+datasheet_V1.0.pdf (Accessed: 6 February 2026).

**Texas Instruments (o. J.).** BQ2407x Standalone 1-Cell Li-Ion Battery Charger. TI Datasheet. Available at: https://www.ti.com/lit/ds/symlink/bq24074.pdf (Accessed: 6 February 2026).

**Vermont Department of Environmental Conservation (o. J.).** Dissolved Oxygen (DO). VT WSMD Wastewater Program Lab Manual, Section 11. Available at: https://dec.vermont.gov/sites/dec/files/wsm/wastewater/docs/Section%2011_Dissolved%20Oxygen.pdf (Accessed: 6 February 2026).

**Wankhede, A. et al. (2007).** Evaluation of Cooling Solutions for Outdoor Electronics. 9th Electronics Packaging Technology Conference, pp. 858–863.

**Zhou, Q. et al. (2015).** Low-Surface-Energy Coatings for Biofouling Control on Optical Sensors. Applied Surface Science, 356, pp. 101–110.


===== Figure References =====

EVE Energy Co., Ltd. (2015). ER18505 Lithium-thionyl Chloride (Li-SOCl₂) Battery: Technical Specification, p. 2. Available at: https://www.akkuman.de/shop/mediafiles/PDF/EVE/10176.pdf (Accessed: 31 January 2026).

----


===== Disclaimer on the Use of Generative AI =====

ChatGPT, Mistral AI and Google Gemini were used for translation and feedback purposes to support the writing process of this report. They were used to improve the text readability and grammar.

Additionally, Google Gemini was used to assist with ESP32 C++ debugging.

All technical content, analysis, calculations and conclusions are the original work of the involved authors. 

----

===== Contribution Summaries =====

=== Sascha Althaus (31507) ===

{{ :ip:ws2025:do_sensor:timesheet_sascha_althaus_31507.pdf | Timesheet Sascha Althaus (31507)}}

As part of the project, I actively contributed to the initial brainstorming phase, particularly regarding the design of the housing and the energy supply concept. I also participated in the excursion to LINEG, where I collaborated directly with domain experts to collect and document a detailed requirements catalogue based on practical insights.

In the area of data handling, I set up and maintained a GitLab project to support structured collaboration within the team. Furthermore, I designed and implemented a container-based architecture using Docker for Grafana and InfluxDB. To validate the complete data pipeline, I developed a Bash script to test the data flow from MQTT via Node-RED to InfluxDB and finally to Grafana. In addition, I configured a dedicated test stack within the Node-RED environment to further verify and analyze the data flow.

A key task was the final configuration of the Node-RED function nodes, where I adapted the payload structure based on official documentation and test data. I also created an example dashboard in Grafana, incorporating simulated test data generated by the Bash script. To support the project presentation, I produced screenshots and accompanying textual content for the project poster.

Finally, I configured an MQTT node provided by the university to receive real sensor data and visualize it in Grafana. To ensure knowledge transfer and facilitate future work, I wrote a comprehensive README file in the project repository, documenting setup procedures and handover information for a subsequent team.


=== Mohamed Karim (32603) ===

{{ :ip:ws2025:do_sensor:timesheet_mohamed_karim.pdf |Timesheet Mohamed Karim (32603)}}

I was responsible for the complete hardware development of the IP-25 monitoring node,
including system architecture, sensor integration, power design, and laboratory validation. I
designed and implemented the full sensing chain around the ESP32 microcontroller,
integrating the optical RS485 dissolved oxygen probe (DFRobot SEN0680) and the analog
pressure sensor, including the necessary voltage scaling and electrical protection. I
developed the high-side switching concept for sensor power control, implemented the
prototype using a relay-based solution due to component availability, and documented the
intended MOSFET optimization for the final revision.

In addition, I designed the entire power management architecture, including charger
selection, boost converter topology, duty-cycled operation strategy, and a worst-case
analytical energy budget aligned with the 7-day maintenance constraint. The resulting model
demonstrated an estimated runtime of approximately 4.9 weeks on a 2,000 mAh LiPo
battery. I assembled and soldered the prototype hardware, performed end-to-end sensor
testing under laboratory conditions, evaluated dissolved oxygen readings against saturation
tables, calibrated the pressure sensor zero offset, and documented all calculations, figures,
and validation results in the final report.

According to my documented timesheet, this contribution amounts to approximately 184
hours of hardware design, implementation, testing, debugging, and technical documentation.

=== Yannick Müsch (31490) ===

{{ :ip:ws2025:do_sensor:ip25_timesheet_31490.pdf | Timesheet Yannick Müsch (31490)}}

During the project I contributed primarily to the “Cleaning / Anti-Algae” work package with a focus on the copper-mesh anti-fouling mechanism. Building on the research/brainstorming from the beginning and our group’s initial screw-tightening concept, I led the detailed design and CAD development of two copper-mesh cap variants, including the final dimensions, mounting holes, sensor offset, and fixation studs to ensure stable positioning and compatibility with the DO sensor housing. The design evolved from direct clamping of the copper-mesh to the sensor (initial idea) to a more sophisticated sensor cage and the mesh wrapped around it; this way the sensor is not prone to scratches or damages from the copper-mesh and a precise offset to the membrane is guaranteed at all times (thus ideally not influencing measurements).

I produced two 3D-print iterations, stitched the mesh carefully to the cage and validated the mechanical fit and usability of the caps. Together with Mohamed, I planned and executed practical tests of both variants and documented the results (including logs). Based on these tests, we could not observe short-term negative effects or interference from introducing the copper mesh. All findings were then compressed into the respective sections of the report.

Later on, I led a more comprehensive series of experiments at LINEG to further quantify the effect of different variables such as mesh-configuration and water flow. The experiments were performed in a controlled laboratory setting at approx. 21°C and equal mounting of the reference probe (WTW FDO 925) and project probe (SEN0680). With three different water samples (BSB/"Biological Oxygen Demand", Tap, Aereated Mussel Water) and controlled stirring (using a magnetic stirrer), a DO range spanning from approx. 6 mg/L to 9 mg/L was covered. The in-depth analysis of these results was then used to derive a linear calibration model for the project probe to reduce the error (as measured by RMSE) and correct the measurement bias (i. e. slightly lower readings with full-cover mesh) to resemble the reference probe more closely. The presented results were then documented and discussed.

=== Stefan Rak (31604) ===

{{ :ip:ws2025:do_sensor:timesheet_stefan_rak_31604.pdf | Timesheet Stefan Rak (31604)}}

Early in the project, I contributed to the concept phase by assessing alternative energy approaches. This included collecting and comparing options such as solar panels, small-scale wind power, or small-scale pumped-storage hydropower. Through research I regarding the practicability and constraints of said approaches. Contributing to the decision on why specific solution paths were later discarded. In this phase, I also helped structure the power-supply requirements based on the planned measurement workflow and the heterogeneous load profile of the station.

For the poster workstream, I learned Adobe InDesign specifically for this project and took ownership of the poster production end to end. I developed the visual concept and layout, gathered and curated suitable media and technical material, wrote parts of the text, and coordinated the creation of remaining content by other team members. Based on these inputs, I produced the final poster, organized a test print to validate readability and layout, and handled the physical setup by mounting the poster on the pitch day.

In parallel, I worked on the electrical side by designing the power supply concept for the measurement station. I began with research into a 12 V LiFePO4-based solution and evaluated it against the project constraints. After this approach was rejected by a stakeholder, I collaborated with the IoT Lab to establish a detailed current and power budget for the selected components. To support this work, I expanded my electrical engineering knowledge over several weeks and translated the requirements into a complete power concept based on lithium thionyl chloride (Li-SOCl₂) cells. This included voltage-domain design, switching strategy, and runtime estimation. I aligned the design decisions with the hardware architecture in coordination with Mohamed. Although the Li-SOCl₂ concept was later replaced by a 3.7 V lithium-ion battery solution decided by other stakeholders, I supported Mohamed with parts of the technical implementation of the final design where possible.

=== Alexander Rausch (33213) ===

{{ :ip:ws2025:do_sensor:timesheet_ip_25_alexander_rausch_33213_-_tabellenblatt1.pdf | Timesheet Alexander Rausch (33213)}}

Early in the process of this project, I helped a few times by offering technical support, e.g. during the meeting most of us learned how to use a microcontroller. I also contributed more heavily in the original brainstorming phase and with my group I developed plans for an alternative swimming prototype powered by solar energy. For this I searched for both, small mobile solar panels and necessary waterproof material. I also researched and checked what material can be used for our anti fouling mechanism and recommended a copper ring or mesh construct during the first draft phase. 

Later I partook in the LINEG excursion and ended up being the notes taker and I summarised the entire visit in note form, as well as keeping track of the currently used DO sensor models. As part of that I also ended up helping finding the necessary documentation for the sensor, as well as noted down and communicated any major changes that needed to be made to our project plan, due to the newly received information.

During the actual project phase I worked together with Sasha on the backend software for our project. I added the Node-Red and PostGIS containers to the docker construct and persisted the used containers with the use of docker volumes and localised volumes, depending on which was more necessary. I also set up a local MQTT inside this docker volume for testing purposes. I also created the “database” model for our sensor data, that ended up consisting out of one datatable only. I build the necessary node-red route for the PostGIS database connection. During this process I also helped in the communication between the subgroups of this project, as well as communicated our current development status to the project team and project supervisors. 

For the poster I ended up creating the dataflow diagram including the database diagram.

=== Johannes Schelb (31861) ===

{{ :ip:ws2025:do_sensor:timesheet_johannes_schelb_31861.pdf |Timesheet Johannes Schelb (31861)}}

At the beginning of the project, I actively participated in the initial brainstorming phase, during which fundamental ideas regarding the design of the prototype were developed. In a second brainstorming phase, I worked together with my project group to develop a concrete prototype concept and contributed to the preparation and presentation of the corresponding concept proposal.

In parallel with the early project phase, I independently acquired basic knowledge in working with the ESP32 microcontroller. To this end, I studied the linked technical documentation, completed tutorials, and carried out practical exercises with the ESP32 in a private environment, as it was not yet clear at that time which group members would later be responsible for this part of the project. In addition, I intensively familiarized myself with the topic of dissolved oxygen sensor technology, the measurement of dissolved oxygen in water bodies, and the relevance of this parameter for water quality assessment, based in part on the literature provided via Moodle.

After the division into project groups, I became part of the team responsible for the design and implementation of the housing. In this context, I worked together with my group to develop the fundamental housing concept and conducted extensive research, for example on the material properties of different materials, the effects of UV radiation, and the formation of condensation in sealed outdoor enclosures.

I was unable to attend the on-site visit to LINEG due to a concurrent university course. However, in advance of the visit, I compiled targeted questions in order to better understand the requirements defined by LINEG and to incorporate this information into the further development of the concept.

After the decision had been made to implement the housing in the form of a pipe, I participated in a visit to a hardware store together with the housing team to evaluate suitable materials for realizing the concept. During this process, the decision was made to use housing components made of polypropylene pipes. In a subsequent visit to the hardware store, I was responsible for purchasing the required materials.

For the project poster, I worked together with my group to create a schematic illustration of the housing concept and prepared a fact sheet summarizing the key features and characteristics of the housing. In addition, I carried out the practical assembly of the housing, using my own tools and, in part, materials from my private workshop.

As part of the final presentation, I contributed to the preparation of the presentation slides and submitted them on time. Furthermore, I prepared a fully written presentation script for the two presenters, which served as the basis for the three-minute final presentation.
Finally, I was responsible for writing the section of the project report that addresses the housing concept and its implementation.

Throughout the project, I regularly attended the lectures in person - with one exception - and actively participated in group discussions. In addition, I supported other project groups with technical questions and occasionally assisted in the IoT laboratory with the assembly of technical components.

=== Lars Theodor Schöne (31629) ===

{{ :ip:ws2025:do_sensor:lars_schoene_timesheet.pdf |Timesheet Lars Theodor Schöne (31629)}}

At the beginning of the semester, when the entire course was still working as a single group, I actively contributed to the development of an initial prototype plan. As I have limited technical expertise in hardware and system assembly, I focused primarily on conceptual aspects and the integration of creative ideas for the prototype. This included, for example, the idea of using a pipe-based housing as well as the exploration of different cleaning and maintenance concepts for the measurement station.

After the initial project plan had been established, I proposed dividing the course into smaller subgroups, each responsible for a specific aspect of the prototype. I organized the allocation of team members to these subgroups and defined milestones with key dates and deadlines. At this stage, I also created a first outline for the project report.

From that point onwards, in addition to my regular work within the housing subgroup, I took on a significant number of organizational and coordination tasks. These included communication with Mrs. Gallas to clarify prototype-related details, as well as coordination with Jan Sonntag regarding hardware procurement. I also supported several other subgroups in the planning and research process for hardware selection and ordering. Furthermore, I assumed responsibility for overall team coordination, which sadly did not always function smoothly.

For the pitch and poster session, I organized the selection of presenters and prepared the pitch presentation. In addition, I took responsibility for the overall project report by assigning chapters to the respective subject-matter experts within the team and writing the remaining sections myself. To assist every team member, I constructed a general guideline for all expected parts that should be included in each chapter of the report. Further I proofread most chapters from each subgroup and gave feedback where necessary. I subsequently consolidated all contributions into a consistent format and published the complete report on the StudentWiki platform.

Within the housing subgroup, I worked closely with my team members, for example by jointly developing a design concept and visiting a local hardware store outside of scheduled course hours to evaluate potential materials. The IoT Lab offered the option for the team to purchase certain required components independently, which we carried out together as a group at a hardware store. I was also involved in the final assembly of the housing and the integration of the hardware components, which had been prepared and partially assembled by other team members beforehand.

=== Sultana Shamsunnahar (33852) ===
Throughout the course of the project, I contributed primarily to the Cleaning / Anti-Fouling, with a focus on the conceptual development of an anti-fouling solution based on a copper mesh for dissolved oxygen (DO) sensors used in long-term water monitoring. From the early stages of the project, I was actively involved in research and brainstorming, and I initially proposed the use of copper mesh as a passive anti-fouling mechanism. Building on this idea, I contributed to developing the overall 3D design concept of the protective sensor case using Autodesk Fusion 360, including how the copper mesh could be integrated around the sensor safely and practically. The main goal of this concept was to protect the sensor from biofouling while avoiding direct contact with the sensitive membrane and minimising any potential influence on measurement accuracy.

I also participated in the project excursion to the LINEG laboratory, where an existing dissolved oxygen measurement system was demonstrated. During this visit, I focused on understanding how DO sensors are used in real laboratory and field environments, how fouling is handled in practice, and how the overall system operates. I documented relevant setups and details by taking photographs, which were later used as reference material for the project and helped connect our theoretical concepts with real-world implementations.To further support and validate the concept, I visited the HSRW IoT Laboratory, where I worked on refining the copper-mesh casing idea and discussed practical aspects such as sensor integration, mounting options, and protection of the sensitive measurement membrane. This helped ensure that the proposed design was technically feasible and compatible with existing sensor hardware and deployment constraints.

I conducted independent research on anti-fouling and cleaning strategies for DO sensors, including both passive approaches and active mechanical cleaning methods, such as rotating brushes and wipers, as well as surface-based solutions like non-stick and low-surface-energy coatings. I analysed and compared these approaches with respect to power consumption, system complexity, maintenance effort, and long-term operational suitability, and shared these findings within the group to support informed design decisions.

I also contributed to the project pitch presentation, in which I presented the overall dissolved oxygen monitoring system rather than individual subsystem details. In this presentation, I explained the project motivation, the intended system functionality, the current project status, and provided an overview of LINEG, including what LINEG does and how it operates. This helped communicate the broader project context and objectives to the audience.

Overall, my contribution focused on idea generation, conceptual and CAD design, technical research, system-level understanding, and communication. I played a key role in introducing the copper-mesh anti-fouling concept, developing the base 3D-printed case design in Fusion 360, supporting the project through laboratory-based concept development and comparative analysis of cleaning strategies, and contributing to the effective presentation of the project vision and progress.

=== Fabian Sloma (31647) ===
{{ :ip:ws2025:do_sensor:timesheet_31647.pdf |Timesheet Fabian Sloma (31647)}}

During the initial concept phase, I actively contributed to the brainstorming process, focusing on a design concept for a floating, enclosed sensor modeled after a buoy. This early draft included provisions for a protective mesh to shield the sensor head and a preliminary arrangement of specific internal components.

As a member of the housing subgroup, I collaborated with the team to transition from the initial concepts to the final "pipe design" architecture. I helped define the general spatial layout of the components to ensure they fit within the enclosure constraints. To validate our material choices, I participated in a visit to a local hardware store with the housing group, where we evaluated suitable piping materials and sealing solutions for realizing the concept.

My primary individual technical contribution was the design and engineering of the internal "Mounting Board," which serves as the chassis for the electrical components. This involved an iterative design process; I initially modeled a version intended for 3D printing, but after evaluating the requirements, the project pivoted to a laser-cut design. I finalized the Drawing Exchange Format (dxf) file for this version, which was successfully manufactured and used in the final prototype.

In the concluding phase of the project, I was involved in the final assembly. I integrated the laser-cut mounting board and the hardware components into the housing, ensuring that the physical structure was secure and the components were correctly positioned for operation.



=== Subrina Sultana (33977) ===

{{ :ip:ws2025:do_sensor:timesheet_subrina_sultana_33977_.pdf | Timesheet Subrina Sultana (33977)}}

During the project, I mainly contributed to the Cleaning / Anti-Fouling work package, with a strong focus on improving the long-term reliability of dissolved oxygen (DO) sensors used in water monitoring. My primary task was the development and evaluation of a copper-mesh–based anti-fouling solution, which was designed as a passive method to reduce biofouling caused by algae, biofilm, and debris. I was involved in developing the initial design concept together with another team member and was responsible for creating the base design. I contributed to defining the concept’s purpose and analyzing how the copper mesh could act as both a physical barrier and a chemical deterrent without negatively affecting sensor measurements. Special attention was given to the positioning of the mesh to ensure sensor protection while maintaining accurate readings.

In addition to the passive copper-mesh solution, I conducted research on alternative anti-fouling and cleaning approaches, including active mechanical cleaning methods such as rotating brushes and wiper-based systems. I analyzed these systems from both a mechanical and electronic perspective, focusing on components such as small motors, power consumption, control mechanisms, and integration with microcontrollers.Alongside this, I explored the use of protective and non-stick coatings to further reduce fouling and enhance the effectiveness of both passive and active cleaning strategies. For each method, I compared advantages and limitations in terms of durability, maintenance effort, complexity, and suitability for long-term deployment.

I also contributed to the practical evaluation of the proposed concepts, including prototype considerations and feasibility discussions. Through these activities, I assessed how different cleaning strategies could be realistically implemented and combined for continuous operation. As part of the project, we visited LINEG to study an existing dissolved oxygen sensor prototype, which provided valuable insight into practical aspects of sensor operation, deployment, and maintenance. Observing an industry-oriented setup helped validate our design choices and align the proposed solutions with current professional practices.

An important part of my contribution was the communication of the overall GeoSensor prototype concept. I prepared and presented the pitch presentation, in which I explained the autonomous dissolved oxygen monitoring system, its system architecture, and the achieved development status. I also addressed future work, focusing on further system integration, performance improvements, and field testing to move the prototype towards a reliable long-term monitoring solution.

Overall, my contribution combined concept development, technical research, practical evaluation, and presentation work. By developing the base design of the copper-mesh anti-fouling solution, researching alternative cleaning methods, gaining insights from real-world systems, and presenting our ideas effectively, I supported both the technical depth and clarity of the Cleaning / Anti-Fouling work package.