H2O Sense: a WSN-based monitoring system for fish tanks

In oceans, fish usually live in an environment that is best suited for their growth. When these fish are introduced into man-made environment, e.g. in mariculture and aquaculture set-ups, the physical parameters might stray from their ideal values, resulting in improper growth and undesired outcomes. Hence, to prevent these undesirable outcomes, continuous monitoring of the physical parameters of the water such as pH, temperature and dissolved oxygen is required. In this work, we present a system called H2O sense, which continuously monitors the physical parameters of the water in tanks and alerts the user in case the values deviate from ideal. We use only low-power, low-cost hardware and open-source development tools, which makes the system easily applicable to various settings. The deployment of our system in the Maritime Laboratory of the University of Namibia shows its efficacy. Furthermore, we evaluate in detail the performance of our system and discuss its applicability in similar challenged environments.


Introduction
Every genus in animal kingdom entails a natural habitat. That habitat provides those species with the perfect set of conditions for its growth and reproduction. Due to high demand of certain fauna as human food, they go through the process of domestication. The process of domestication in water-based animals is a challenge in its own. Multiple physical parameters of the water, e.g. pH temperature and dissolved oxygen, play important roles in the life cycle of fish. Optimally, these parameters should be monitored continuously and automatically controlled. However, current practices usually embrace a half-automated process, where humans measure the parameters regularly with hand-held devices. Additional challenges arise in mariculture laboratories, where the number of parameters to be controlled is higher and the effect of them on fish is less or not known at all. The tanks are usually also smaller, and different tanks have different requirements due to the different species or experiments inside.
Currently many solutions are available commercially that are capable of autonomous monitoring, but most of them either analyse limited amount of physical parameters or are expensive or both. Furthermore, the operation of such systems requires a certain level of technological expertise, which is not the main focus of the researchers working in mariculture laboratories. These factors usually make these systems impractical and unfeasible for research-based set-ups in educational institutions.
On the other hand, we have seen the rise of wireless sensor networks (WSN), Internet of things (IoT) and lowcoding hardware platforms such as Arduino. Such systems have been widely deployed in agricultural set-ups, smart homes, etc. They are comprised of wirelessly connected low-cost, low-power devices, which autonomously form a network, monitor environmental parameters and send these data recordings to a central server for further processing. However, some environments have not been penetrated very successfully yet, due to their challenging nature. In our previous work, we have explored how to deploy WSN or IoT systems in underground [14,15] or underwater [12] environments. The present challenge is a mixture of these environments. Strictly speaking, the laboratory is overground, but the air is extremely humid, with water flowing and splashing around.
We present H 2 O sense, a fish tank monitoring system. Our motivation was to ensure not only the perpetual operation of the monitoring process but also accuracy within the data that are gathered from the system. The developed system is flexible in terms of sensors attached, delivers the data in a convenient format so that it can be easily processed without any technical background and has low cost and low power. It not only offers monitoring of the environmental properties, but also evaluates them automatically and sends notifications via smartphone to inform the user about deviations.
This paper not only shows the development of this particular system, but also demonstrates how challenged environments can be targeted. It also evaluates the performance of the complete system, which will give valuable insight into future reproductions of this system to similar set-ups.
The rest of the paper is organised as follows: Sect. 2 describes the background of our work and the application scenario. Section 3 describes in detail the system architecture, the used hardware and software. Section 4 details the deployment of our system in the Sam Mujoma Campus of the University of Namibia and evaluates it in terms of accuracy of the data, communication quality and energy consumption. Section 5 focuses on the data received from the deployment and its usage in mariculture research. Section 6 summarises and concludes the work.

Background and application scenario
Our targeted application scenario is the autonomous monitoring of vital parameters in fish tanks. Our sample deployment is the mariculture laboratory of the University of Namibia, where we have installed and tested our system. Before going into the details of our system and its evaluation, we sketch here the requirements of our application scenario and the identification of the parameters we want to monitor.

Application scenario
Mariculture laboratory carries out various experiments with living fish, mostly consisting of growth and health studies with differing environmental parameters. For example, one of the long-term studies is to grow Tilapia (Oreochromis mossambicus), which is a freshwater species, in salt water. Many consumers prefer freshwater fish like Tilapia, but freshwater is scarce in Namibia. On the contrary, salt water is abundant.
Even if Tilapia tolerates salt water better than other species, it cannot simply be introduced to it at once. During the growth period, the water salinity needs to be carefully and slowly increased, while meticulously monitoring other parameters also, as described in the next paragraphs.

Monitored parameters
Temperature significantly affects the growth and food intake of a fish. Deviations from the desirable ranges can lead to less optimal growth in fish [3][4][5].
Another important factor in fish growth is the amount of dissolved oxygen in water. Different species of marine fauna are capable of tolerating different levels of dissolved oxygen [8]. Generally, deep sea creatures are capable of surviving very low amount of dissolved oxygen. Dissolved oxygen not only affects growth [7], but also has effects on day-to-day habits of fish, e.g. swimming close to surface or predator avoidance [6]. Very low amounts of dissolved oxygen can also lead to mortalities.
As discussed already above, salinity plays a vital role in fish growth [1,2,11]. In general, freshwater fish cannot tolerate higher salinity levels and vice versa. However, in our studies in Namibia, salinity plays the star role and our goal is to grow freshwater fish in salt water.
Alkalinity and acidity, generally measured with the pH value, also play an important factor in fish keeping [10]. Changes in pH levels at the gills of fish can lead to suffocation.
In the next section, we present our general system architecture together with the sensors to monitor the above required water parameters.

System architecture
The H 2 O sense overall system architecture is presented in Fig. 1 and consists of wireless sensor nodes with various sensors: a local server and a remote server. The sensor nodes are located on the tanks, with sensors reaching into the water, and are wirelessly connected to the local server in the laboratory itself. This gives the user the possibility to check the status of the deployment easily without the use of any additional hardware. The sensor nodes can accommodate different sensors, depending on the requirements. In our case, we have deployed one sensor node with salinity, pH, temperature and dissolved oxygen sensors and several further nodes with only temperature sensor on board. Figure 2 shows pictures from our sample deployment for better understanding.
The local server is connected via the university WLAN to a remote server. The remote server back ups all data: it is also an interface between users and collected data, as well as status of the system itself. It also validates the data and issues user notifications in case of unusual data.
In the next sections, we explain the individual components in detail.

Sensor nodes
One of the goals of our work was to deliver a low-cost, low-power, flexible solution. Thus, we turned to already available hardware platforms to serve as the basis for H 2 O sense. A good platform will be composed of a micro-controller, a radio transceiver at low frequencies (the lower the frequency, the better the penetration of wireless signals in our wet environment), and connectors to external batteries and sensors. Another important choice factor is the programming environment-it should be powerful and able to cater for our goals.
Keeping these requirements in mind, we selected the MoleNet [13].
MoleNet is a hardware platform, which we have developed for earlier deployments in underground scenarios. MoleNet is open-source hardware, 1 based on the Arduino platform and programming environment. Arduino, on its side, has been developed especially for non-technical people like artists, to enable them to quickly prototype interactive hardware. Since its beginnings in 2003, Arduino has developed into the preferred hardware platform for prototyping low-cost, low-power hardware.
The MoleNet platform uses a RFC69 radio transceiver at 433 MHz, which is one with the lowest frequency in the socalled ISM band (industrial, scientific and medical band), for which off-the-shelf radio transceivers are available. MoleNet is shown also in Fig. 3 on the right.
Compared to MoleNet, only few options exist, mainly because of the radio transceiver. Usually, most of the readily available WSN or IoT nodes use the 2.4 GHz frequency, which is not applicable to our scenario. An alternative is the Waspmode by Libellium. 2 However, with e240 per node (excluding the sensors) it is more expensive than MoleNet and it has its own proprietary development platform, which is less flexible than Arduino.

Multi-sensor node
The architecture of our multi-sensor node is provided in Fig. 3. Figure 4 shows a picture of it. This type of node carries all sensors.
Most of these sensors require a sensing chip to process their raw data. These chips are connected to a shield, which is then connected to the MoleNet sensor node. The purpose of this shield is to isolate the sensor probes form each other, to provide power to them and to connect them to the MoleNet. In particular, the data isolation is crucial, because individual probes influence each other and their readings would be faulty. We used the so-called tentacle shield from Whitebox laboratories.
The sensors we use are: • DS-18B20 temperature sensor. 3 The one-wire communication protocol allows easy interface using minimal amount of I/Os pins, which are usually a limited resource in small micro-controllers like MoleNet. • Atlas Scientific Dissolved Oxygen Probe (ENV-40-DO). 4 While there are other options available from DFRobot or from Vernier, the one from Atlas Scientific claims MoleNet is programmed via the Arduino IDE. The complete source code can be found under our Github repository, together with all other source code and data. 7 The code itself is very simple: the node is programmed to sleep most of the time and to wake up periodically according to the recent (configurable) sleep time. Every time it wakes up, all sensors are checked and the data are sent wirelessly to the local server. After sending the data, the node waits for an acknowledgement from the local server. In case there is no acknowledgement, the node tries to send data twice. Upon success or complete failure, the device goes back to sleep.

Temperature-only sensor node
For some of the experiments in the mariculture laboratory, only a temperature sensor is needed. In general, with rising temperatures the dissolved oxygen decreases, which is a hint that fish health is under risk. Thus, we have also designed a simplified version of our sensor node with temperature sensor only. The temperature sensor can be connected directly to MoleNet, which means that we also do not need the tentacle shield. The architecture of the temperature-only sensor node is provided in Fig. 5 and a picture of it in Fig. 6.
The software of the temperature-only sensor node is identical to the multi-sensor node.

Local server
In order to simplify the usage of the system, we have installed a local server directly in the laboratory, where users can see the current status of all nodes and their data. A picture is provided in Fig. 2a. The local server is based on a Raspberry Pi with a RFM69 radio transceiver to connect to the sensor nodes and an LCD display.
The software of the local server is based on the Raspbian operating system.
It performs four basic tasks: • Data are collected from the sensor nodes. The local server is always awake, waiting for incoming packets. • Data storage is implemented with a MySQL database, together with times-tamps of data arrival. • Data display takes the data from the database and displays on the LCD screen. We developed a Web-based GUI on top of an Apache server. • Data are shared with the remote server

Remote server and user services
The data of the system can be accessed globally through a remote end which is identical to the dashboard running at the local end. The data at the local end are shared with an online server which allows easy access of data from anywhere in the world. This allows the staff to monitor their experimental set-ups without being in the proximity of the laboratory where the experimental set-up is located. The remote server also allows user to view warnings generated by the system and access all the data logged by the system. Additionally, the end-user can also change the monitoring period through the dash board. Figure 1 shows that the sensor nodes are connected to the local server and the local server to the remote server. Here, we give some more details about this communication.

Communication: MoleNet to local
The communication between the sensor nodes and local server is done with the help of the RFM69 stack over 433 MHz frequency. A simple packet structure is added on top of the stack for ease of interpretation. The address of the sender is added at the beginning of the packet followed by the measured values and the retransmit period. Upon successful transmission, the receiver replies with an acknowledgement and retransmit period (for the node to synchronise itself ). The local network is arranged in the form of a star topology where every node has direct connection to the local server.

Communication: local to remote
The communication between the local and remote server is done via HTTP requests. The website on local server, upon detecting successful Internet connection, sends any new data available to the remote server. The remote server saves the data received from the local end to its database. The local server also inquires the remote server for any new settings that may not have been applied to the system. If a remote user has changed any setting of the system, upon inquiry, the remote end shares this information to the local end.

Duty cycling of sensor nodes
Duty cycling is one of the most common ways of saving energy on sensor nodes, first proposed by [9]. The idea is simple, but powerful: switch off the sensor nodes between two consequent sensor readings. When the node is awake only in 10% its total lifetime, we say it has a duty cycle of 10%. The approach poses a new challenge to communication between the nodes, as the duty cycling needs to be coordinated or synchronised. However, when all sensor nodes communicate directly to the local server, no coordination is necessary and the nodes can spend most time in sleeping mode.
For our sensor nodes, the temperature-only node can sleep most of the data and awakes every 30 s for 6 s to take the temperature reading and to send the data to the local server-this corresponds to 20% duty cycle. The multi-sensor node awakes only every 30 min for 30 s, which corresponds to 16%. However, please note that only MoleNet is put in sleep mode-the sensors themselves are not, since it takes a long time to restart them.
This section offers a practical evaluation of the energy consumption for both types of nodes and a theoretical evaluation of their lifetimes.

Discussion
Our sensor node and our general architecture can easily be used in other set-ups, e.g. monitoring of botanical gardens, greenhouses, laboratories, etc. The sensor node architecture is generally enough to accommodate various other sensor types. Also, the here presented and used sensors can be easily exchanged with more sophisticated ones.

Deployment of the H 2 O sense system
This section describes the details of the deployment of the system and the experiments related to the performance of the system.
The system was deployed in the mariculture laboratory in the Sam Nujoma Campus of the University of Namibia (UNAM). Figure 2 shows the deployed devices. The initial testing of the set-up was done in two different experiments: initially in the (1) Tilapia experiment and later in the (2) Kob experiment.
The Tilapia fish is a freshwater fish that is mostly found in lakes, streams and rivers. Therefore, in the Tilapia experiment, the water in the tanks was stagnant and only changed when the water condition deteriorated. Maintaining desirable water parameters (i.e. temperature, dissolved oxygen, pH), was key in this experiment to ensure proper growth of the fish.
The set-up of the Kob experiment, in contrast to the Tilapia experiment, was very dynamic. The Kob fish habitat is usually near beaches and river mouths where water flow is strong; therefore, an artificial current was present in the Kob tanks with continuous flow of water in and out of the tank. In this set-up, the key parameter to maintain was the temperature. The dissolved oxygen was already regulated due to the artificial flow.
The purpose of the system, during the testing, was to ensure that the suitable conditions for each species are maintained throughout the experiment. In this section, the performance of the system is evaluated in terms of accuracy, communication range of the sensor nodes and energy consumption.

Accuracy
One of the important aspects in developing the H 2 O sense set-up was to ensure that the data received were accurate and reliable. For the purpose of accuracy, the probes were calibrated before operation. All the probes were calibrated with the help of calibration solutions that come with the probes. To further increase the accuracy, the probe temperature registers were updated in every cycle using the reading from the temperature sensor. In the case of dissolved oxygen, the readings also depend on the salinity of the water and need to be used in the calibration. Table 1 presents a comparison between readings obtained by the set-up, readings from a manual water multi-meter and normal range of values for sea water in Henties Bay. For a fair comparison, the seawater readings were taken for the same month. The biggest difference was in the dissolved oxygen readings since the dissolved oxygen depends upon the depth as well. (Dissolved oxygen in water reduces as the depth of water increases.) The depth of our set-up was less than 1 m, but the manual multi-meter probe cable was longer; thus, the manual probe measured dissolved oxygen at a deeper level which leads to lower dissolved oxygen reading. For all other parameters, the difference between the parameters was small enough not to have a negative effect.

Communication ranges
The communication range of the system was enough to cover the whole laboratory.
To assess the range of the communication within the building, a normal mote node was used as a sender. The mote was positioned at various locations in the laboratory to measure the communication quality. The Received Signal Strength Indicator (RSSI) values of the signal received from the mote was recorded by the local server. The local server had a fixed position. Figure 7 shows the floor plan of the mariculture laboratory located in the UNAM Sam Nujoma campus where the set-up was deployed and tested. On top of the floor plan, a heat map was plotted that was generated with the help of the recorded RSSI readings. The red regions in the map show the areas with low RSSI (bad coverage). These areas were surrounded by large pieces of equipment and water tanks which resulted in a lower RSSI. However, no dead communication zones were found within the laboratory.

Energy consumption
Since WSNs are geared towards low-cost and low-power attributes, the energy consumption of a WSN mote becomes an important aspect. For a system to monitor autonomously, the lifetime of the motes should be long enough to support the independent operation. This aspect was also kept in mind while designing the H 2 O sense motes. Figure 8 shows the energy consumption during one complete cycle of a temperature node. The standby mode consumption of the temperature node is 6 mA and falls to 0.4 mA on average in sleep mode. The three peaks in the plot represent one data transmit along with two retransmits. In Fig. 8, we can also see that power consumption varies slightly with time even during the same operational mode of the sensor node. This is normal behaviour, as the micro-controller is performing some background tasks.
The energy consumption of the full-fledged (multi-) sensor node is higher with 115 mA on average in standby  . 8 Power consumption of temperature node in one cycle with retransmits mode and 95 mA on average in sleep mode. The culprit behind this unusually high energy consumption is the power and data isolators on the tentacle shield. These isolators allow multiple probes to work together properly and prevent electrical noise from interfering with the normal operation.
Given the duty cycles of 20% and 16% for both types of nodes, respectively, and battery capacities of 26,800 mAh for the multi-sensor node and 1900 mAh for the temperature-only node, the multi-node would be able to survive for approx. 11 days, while the temperature-only node for approx. 6 months. The very short lifetime of the multi-sensor node is again due to the power consumption of the tentacle shield. However, 11 days is an acceptable recharge period in a laboratory-like environment.

Data evaluation
The data obtained from the system during the period of experiment are discussed in this section. The effects of the temperature, pH, dissolved oxygen and salinity on the life cycle of fish are a long-term study, but certain habitual aspects can be observed in a short-term experiment. Data are presented from a total of 1 month (from 25 April 2018 to 25 May 2018).

Temperature data of all nodes
Temperature plays an important role in the well-being of fish [2,3]. Thus, it is vital to maintain appropriate temperature of the fish tanks. Figure 9 shows the temperature readings from all four nodes while monitoring the experimental set-up (the Tilapia experiment). Each of the nodes was monitoring a different tank in the experiment. To replicate natural environment, the desired temperature for the experiment was set between 26 and 31 °C. We observed frequent fluctuations in the readings of node 4 due to its sensors' close proximity to the water heater, which could be prevented, unfortunately.
Furthermore, significant temperature drops were observed during fish tank maintenance (cleaning and/or refilling). In Fig. 9, the drop on May 5 was due to the partial change of water (15% water change) and the temperature drop on May 17 was due to tank cleaning (≈ 50% water change). After May 10, node 2 was relocated to monitor the Kob experiment in a different tank. The physical parameters of this experiment were different; therefore, the data are not plotted after this date.
On May 17, due to a loose valve, the water of the tank monitored by node 3 was flushed out. The temperature sensor started thus measuring the temperature of the room, which was cooler than the water temperature. Thus, the readings showed a rapid drop which raised an alarm on the dashboard. This alarm alerted the maintenance personal to physically examine the tank. The problem was detected and addressed in a timely manner which resolved the issue without any repercussions. Such a situation would have otherwise lead to mortality of fish under observation. Figure 10a shows the situation of the tank before it was refilled. In future, we can add a water level sensor to be able to better recognise and identify this rare event.

Dissolved oxygen data
Insufficient amount of dissolved oxygen in water can lead to asphyxiation in fish [6]. Figure 10 shows the dissolved oxygen and temperature data from the multi-sensor node in the Tilapia experiment. On the y-axis, we have the dissolved oxygen, and on the x-axis, we have the time. The temperature is plotted on the secondary y-axis. The value of dissolved oxygen is correlated with the temperature of the water; therefore, both parameters are plotted in the same figure. The significant drop in the values of dissolved oxygen around May 1 occurred due to a clogged aeration tube. The build-up of grime in the fish tank due to water quality deterioration was found to be the culprit behind the clog. Furthermore, the temporary jump in the dissolved oxygen readings around the May 7 was due to the maintenance of the fish tank. This maintenance included addition of clean water into the tank which improved the dissolved oxygen for a limited time.
For the Kob fish experiment, Fig. 11 shows the readings of the dissolved oxygen and temperature over time. The required range of temperature readings for the Kob experiment is between 12 and 25 °C. The tank was much bigger in size than the Tilapia experiment. Due to the artificial flow current created to imitate the natural environment of Kob, higher values of dissolved oxygen were measured. The water changes can also be seen here as the temperature suddenly drops and dissolved oxygen improves on May 18.

pH data
The pH of water outside the optimal ranges can lead to toxicity and suffocation in fish [10]. In our scenario, the optimal ranges of pH are between 7 and 9. The pH data  ). The amount of nitrates in the tank can only be removed by a water change. This explains improvement in the pH after a water change performed on May 7. Figure 13 shows pH versus time plot for the Kob experiment. The readings were consistent throughout the experiment.

Salinity
The goal of the experiment conducted on freshwater Tilapia was to accustom it to sea water. Typically a freshwater fish dies if it is moved to salt water. But if the Tilapia are introduced into salt water as a fry, they can adapt to the salt water. The range of optimal salinity was between 35 and 37 PSU for the Tilapia experiment. Figure 14 shows the salinity data plotted from the data obtained from node 2. A gradual increase in the salinity can be observed in the figure. Evaporation causes increased saturation of the salts in the tank water since no new water is added to the system. Malfunctioning of registers of the probe chip caused the jump and temporary drop in the readings.
Salinity data collected during the Kob experiment are plotted in Fig. 15. On the x-axis, we have the time, and along the y-axis are the salinity values. Similar to pH values, the salinity values do not show considerable fluctuations and remain consistent throughout the experiment.

Conclusion
In this article, we have presented our H 2 O sense system to monitor optimal parameters for fish tanks. We have described our system architecture, how we selected the hardware and how we implemented and deployed the system. Although this system is rather a prototype, the step to permanent deployment is straightforward.
There are two important lessons learnt from this work. First, using low frequency for wireless communication achieves very good results even in harsh environments like fish tank laboratories, where air humidity is high and large pieces of equipment prohibit line of sight. Second, while the sensor mote itself is very cheap and very energyefficient (for example, our temperature-only sensor node), more sophisticated sensors are expensive and energyhungry. Here, we also see the major challenge for future deployments and the largest and most urgent need for further research.