The H2O 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 H2O 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,Footnote 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 so-called 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.Footnote 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.Footnote 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).Footnote 4 While there are other options available from DFRobot or from Vernier, the one from Atlas Scientific claims to have very long maintenance cycles (recalibration needed only every 18 months).
-
Atlas Scientific Salinity Probe K1.0.Footnote 5
-
Atlas Scientific pH probe.Footnote 6
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.Footnote 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.
Network topology and communication
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.