Open-source low-cost design of a buoy for remote water quality monitoring in fish farming

Abstract

In this paper we present the design of an open-source and low-cost buoy prototype for remote monitoring of water quality variables in fish farming. The designed battery-powered system periodically measures temperature, pH and dissolved oxygen, transmitting the information locally through a low-power wide-area network protocol to a gateway connected to a cloud service for data storage and visualization. We provide a novel buoy design that can be easily constructed with off-the-shelf materials, delivering a stable anchored float for the IoT device and the probes immersed in the water pond. The prototype was tested at an operating fish farm, showing promising results for a low-cost remote monitoring tool that enables automatic data acquisition and storage in fish farming scenarios. All the elements of this design, including hardware and software designs, are freely available under permissive licenses as an open-source project.

Introduction

Monitoring water-quality variables such as dissolved oxygen, temperature, and pH is key in fish farming [1, 2]. Typically, fish farmers manually collect measurements from these variables at frequencies that vary depending on the dynamics of the pond and environment [1, 3]. However, manual measurement of water-quality variables can be time-consuming and implies very low acquisition rates and frequent calibration. These limitations have motivated the development of automatic remote monitoring devices capable of reducing the burden on the fish farmer for data collection and increasing the acquisition frequency. For example, a device developed in Kenya transmits data collected from pH and temperature sensors that is subsequently processed and accessed through an app [4]. Also, in the work in [5], a wireless sensor network was developed and deployed to monitor and control an aquaculture system. Libelium, a wireless sensor network platform provider, offers several systems designed for remote monitoring of water-quality variables [6].

Even though these solutions are proven to work in a wide variety of scenarios in fish farming, they are either expensive for small-scale fish farmers and would not be affordable in lower-income countries or not open for shared development. For example, a solution provided by Libelium can be as expensive as 17 times the minimum wage in Colombia, a country in South America. There is a need to develop low-cost devices for remote monitoring of water quality variables in fish farming in a joint effort of the research community. In this paper, we present a system for remote water quality monitoring in fish farming scenarios that uses low-cost equipment, has low-power consumption, is scalable, and is open-source to continue being developed by the research community in the field. The developed prototype is a battery-operated data buoy for measuring temperature, dissolved oxygen and pH with the possibility to extend to other water quality variables, as shown in Fig 1. These measurements are transmitted using LoRaWAN with services from The Things Network (TTN) [7] to an on-site gateway connected to the Amazon Web Services (AWS) [8] cloud for storage and visualization by the user. This prototype involves a novel buoy design constructed using off-the-shelf materials and provides stable flotation that supports the electronics and the probes immersed in the water pond. The entire design has been released as an open-source project and uses commercially available products.

[Figure omitted. See PDF.]

The rest of the document is organized as follows. First, each device component is described, including the electronics and mechanical structure of the buoy. Then, the completed prototype and field test results are presented. This is followed by a discussion on the various future potential research directions to improve this design. Finally, the last section concludes the work.

Materials and methods

In the following sections we present the detailed design of the monitoring system as presented in the diagram in Fig 1. A complete guide to present the documentation, software and hardware designs including circuit schematics and PCB fabrication files can be found in GitHub via https://github.com/open-pisciculture/open-source-fish-farming-prototypes.

Buoy design

The data buoy includes the electronics for data transmission, the sensor probes for measurement, and the mechanical structure for flotation and protection from the environment. The system must shield the electronics from conditions such as rain and dust. In addition, the sensor probes must be immersed at a specific depth in the water pond while still allowing for adequate water flow. The buoy has to be stable with respect to wind and water movement. Fig 2 shows each of the data buoy sections, alongside the dimensions and center of gravity location.

[Figure omitted. See PDF.]

The following design was developed according to the specified requirements. At the top of the buoy the electronics were housed inside a modified IP55 electrical box with two additional apertures. The sensor probe cables output the first aperture using a PG13.5 cable gland towards the water. The second aperture was used for antenna placement. A 10 L expanded polystyrene box was used as the flotation device and to support the electrical box. Weight was added inside the polystyrene box to locate the center of gravity below the center of buoyancy and stabilize the object when subjected to external disturbances. The sensor probes were placed at a depth of 50 cm through a tube that allows sufficient water flow, but protects them from fish and other unwanted object collisions. Finally, an anchor was added to keep the system in a fixed position. The anchor was designed to reach the bottom of the pond.

Sensors

The device should ideally operate for long periods without human intervention, be affordable for small-scale farmers, and be easy to build without requiring specialized parts or equipment. Different sensors are available in the market: some products are cheaper but require calibration before every measurement; others incorporate more recent technology, such as optical sensors with extended periods between calibration and maintenance, but at a much higher price. We chose sensors from Atlas Scientific [9] of the evaluated commercial products, which proved to offer the best costs and quality trade-off. These sensors require occasional calibration and maintenance only every few months, and they are affordable. Table 1 summarizes the characteristics of each sensor.

[Figure omitted. See PDF.]

Variable t refers to temperature.

Communications

The device must regularly transmit data from sensors, have enough range to cover vast land areas, be low-cost and reach possibly years of battery life. Communication technologies range from the more traditional Wi-Fi and Bluetooth to more recent ones such as low-power wide-area networks (LPWAN) and innovative satellite solutions. LPWANs are designed for low-power long-range communications with low bit rates, such as transmitting sensor values from battery-operated devices [10]. Satellite constellations, such as Swarm Technologies [11] and Lacuna Space [12] promise to eliminate the need for on-site internet connection by offering a network based on satellites. These are much newer technologies still in development and, in most cases, are available only in select countries and through beta programs. Due to this, they were not considered in this work.

For this prototype, LoRaWAN was chosen due to its low power consumption, high range and low cost. It can cover ranges up to 20 km and reach long lifetimes with batteries [10]. The main limitation of this technology is its low bit-rate, which is around the kilobit or even bit per second range. In this case, since sensor values are measured between long time intervals and correspond to a payload of a few bytes, LoRaWAN is an appropriate fit for the application. In the Field test section we discuss the selection of the sampling time for this environment.

Hardware

The device electronics must run on batteries for an extended amount of time. Accordingly, the circuit must use low-power components and circuitry to read the sensor probes and transmit the data using LoRaWAN. The developed circuit board is illustrated in Fig 3, where each of the main sections are shown in colors. Following, we describe each one of the hardware components.

[Figure omitted. See PDF.]

Power supply.

Three AA batteries in series feed into an MCP1700 low dropout voltage regulator for the 3.3 V power supply. This chip was chosen due to its low quiescent current of 2 μA and 250 mA maximum current. In addition, the microcontroller controls the sensor’s power delivery using a MOSFET switch.

Microcontroller.

The prototype uses a NUCLEO-L476RG board with an STM32L476RG microcontroller. It includes various low-power modes and incorporates both I2C and SPI peripherals to communicate with the sensor circuits and LoRaWAN module, respectively. The developed code handles the LoRaWAN communications, reads the sensor values, and reduces the power consumption. First, the chosen LoRaWAN module does not include the LoRaWAN stack. Due to this, the microcontroller must implement it to transmit data. Various libraries exist for this purpose, most notably Semtech’s LoRaMac-node [13] and arduino-lmic [14] from MCCI, which are available under open-source licenses. This project uses arduino-lmic due to its straightforward implementation in STM32 microcontrollers. Second, the microcontroller reads each sensor using the I2C protocol. Each sensor circuit was assigned a known unique I2C address beforehand to differentiate between them. Lastly, to maximize battery life, the microcontroller places itself into a low-power mode and turns off the sensor circuits during the wait periods between measurements. The microcontroller wakes up after the sampling period has passed by programming the internal RTC alarm to generate an interrupt. Fig 4 shows the flowchart of the developed code.

[Figure omitted. See PDF.]

Each of the steps the program takes is shown here.

Sensor circuits.

The microcontroller communicates with a reading circuit connected to each sensor probe. These circuits enable easy converting of the voltages or currents from the sensor probes into the measured value. Furthermore, the pH and dissolved oxygen reading circuits are electrically isolated with an additional isolation board. This isolation is required because the two sensors cause interference, leading the microcontroller to receive incorrect values. It is important to note that the temperature sensor does not require electrical isolation. For this reason, it does not use this additional board.

LoRaWAN module.

Each country has different regulations for LoRaWAN that affect which specific device can be used and how it should be configured. Primarily, the frequency in which LoRaWAN can operate should be verified before choosing a module. In this case, the prototype uses an RFM95W transceiver module that transmits and receives at 915MHz. Other countries may have different regulations and thus would require a different version of the module.

Cloud

Amazon Web Services was chosen as the cloud provider. Its main role is to receive the data from The Things Network and forward it for storage and visualization. Fig 5 shows the cloud services used in this implementation and a brief description is given below. Each service has an equivalent version in each Cloud provider. Thus, it is possible to replicate this architecture in other frameworks such as Azure or Google Cloud. The main reason for selecting AWS was because The Things Network provides an integration available as an AWS CloudFormation template.

[Figure omitted. See PDF.]

AWS IoT core.

It connects The Things Network platform with AWS for sending and receiving messages to and from the IoT devices.

OpenSearch.

Provides access, handling, and storage of data. It includes, among other tools, OpenSearch Dashboards, a user interface that enables users to explore their data as time series.

DynamoDB.

A serverless NoSQL database. Its associated costs are relatively low, fulfilling the function of storing the data received.

Lambda.

Uploads data to databases DynamoDB and OpenSearch.

IoT rules.

These rules give IoT devices the ability to interact with AWS services. In particular, the main functionality is triggering the Lambda function to handle the received data.

Cognito.

It allows the system to add user sign-up, sign-in, and access control to web or mobile apps. In this case, it was implemented to manage credentials and access to OpenSearch Dashboards.

Results

Implemented prototype

The device was first validated under controlled conditions with a small water tank before deployment at the fish farm. The total cost of the device is approximately 658 USD. Fig 6 shows the assembled final version of the prototype.

[Figure omitted. See PDF.]

Fig 7 shows the entire system architecture. Data collection begins by reading the sensors and obtaining the temperature, pH and dissolved oxygen values. The data are then transmitted using LoRaWAN to the gateway located at the fish farm. If the gateway has an internet connection, the data are forwarded to The Things Network and finally sent to be stored in the AWS cloud, ready to be consulted by the user.

[Figure omitted. See PDF.]

This diagram shows the main components of the developed system required to bring information from the pond to the user.

Additionally, measurements of power consumption were done for each of the states to quantify the device autonomy following the energy consumption model presented in [15]. These are summarized in Fig 8 and the data and procedure details can be found in the project repository. The total energy required by a single operation cycle of 10 minutes can thus be estimated as 1.596 J.

[Figure omitted. See PDF.]

The power consumption for a single operation cycle is shown here. The total duration of the cycle is 10 minutes. Image not to scale.

Field test

The device was tested at a fish farm close to Neiva, Colombia, shown in S1 Video.

First, LoRaWAN coverage data was obtained. After that, the buoy device was deployed into the pond, and the gateway was installed in a storage room near the pond. The monitoring system was tested during seven days and remotely supervised with live camera feeds and by watching the data collected in the cloud. Fig 9 shows the device operating at the selected water pond. A video of the data buoy operation can also be seen in S2 Video. Following, we describe the results obtained during the field test.

[Figure omitted. See PDF.]

Coverage map.

An open-source GPS LoRaWAN node prototype was developed to transmit the current coordinates. The data sent by this node are stored in the cloud along with the packet information, such as the Received Signal Strength Indicator (RSSI) and the Spreading Factor (SF). Fig 10 shows the collected data points, showing that the communication system has a good performance for this particular environment. The SF characteristic shown is of particular importance and affects the range and power consumption of the node. It represents a trade-off between range, airtime and data rate, and six different choices are available from SF7 to SF12. Particularly for this application, the energy required increases as airtime increases as well, because the device will be running for a larger amount of time. The lower values of SF, such as SF7, present a decreased power consumption, but have a shorter operation range. In contrast, higher values such as SF10, have an increased power consumption but a longer operation range. Thus, the SF is an important parameter that must be adequately chosen depending on each node’s particular environmental conditions and location [10]. In this case, SF7 is enough for transmitting the data with the chosen buoy location.

[Figure omitted. See PDF.]

Internal temperature.

An RC-5+ USB temperature data logger was placed inside the electronics box during the week-long test to record the temperature inside. This device measures temperatures within the range from -30°C to 70°C with an accuracy of ± 0.5°C between -20°C and 40°C and ±1.0°C otherwise. This was done to study the temperature behavior inside the electronics box. Fig 11 shows the recorded data.

[Figure omitted. See PDF.]

Graph shows the first 40 hours of the field test.

Data collection.

Both pH and water temperature can be sampled daily or after specific events such as checking the liming response. However, critical dissolved oxygen values can occur during the night and sampling at an hourly interval can help anticipate dangerous values. Thus, the maximum sampling interval was considered as one hour [1]. However, to account for possible packet loss during transmission and errors during the data reception from the sensor circuits, a faster sampling interval of 10 minutes was chosen for the field test. In addition, an internal microcontroller temperature reading was added to study the variation and verify that the operating range for the microcontroller was satisfied. Fig 12 plots the recorded data. Note that a few values received from the water temperature sensor were identified as errors through software. These data points were computed through with a linear interpolation using neighboring data points.

[Figure omitted. See PDF.]

The blue lines plot the raw data collected from the sensors. The red dots for the temperature values indicate replaced error values through a linear interpolation.

Discussion

Prototype performance observations

Overall, the construction presented no significant issues, and the mechanical structure performed as expected. The electronics box protected the circuit from the environment for the seven days of the test, particularly from heavy rain. No damage occurred to any of the electronics. However, the electronics box and the polystyrene box presented traces of possible water condensation inside. The buoy maintained its position, indicating that the anchor worked as expected. Algae growth occurred at every point submerged in the water: the anchor, the protection tube, the sensor probes, and part of the fridge. Further analysis is required to assess the impact of algae growth on the flotation performance and stability for long-term usage of the device. No water sipped into the electronics box due to the rain, and the buoy continued to be stable in the correct position.

Three different kinds of data were recorded during the field test. First, the coverage map points were taken to verify if the gateway location was capable of receiving data from the planned data buoy deployment site. This test was successful, and thus the data buoy was able to transmit data from the pond. Second, the internal temperature data recorded show that the maximum temperature achieved was around 38°C. This test helps verify if the internal device temperature stays inside the operating temperature given by the electronics. In this case, the batteries used limit the maximum temperature to 54°C [16]. Since the maximum temperature was around 38°C, this stays inside the operating limits. Finally, the three water quality variables corresponding to water temperature, pH and dissolved oxygen were recorded for 40 hours alongside the microcontroller’s internal temperature. Here, the daily variation of each variable can be observed, with lower values during the night that rise during the day [1]. For the microcontroller temperature, the values stay well inside the operating range of -40°C to 85°C [17]. Notably, each of the five variables, including the water quality and internal device temperature data, show a dip beginning on midnight of the day 28th. This event may be related to environmental variations, such as rain. The recorded data indicate that signal filtering for the water quality variables and error detection for device maintenance, recalibration and malfunction are required.

Challenges and limitations

One of the first challenges encountered was the placement of the LoRaWAN gateway. The plan was to place the device inside a small building with Wi-Fi and an electrical plug. However, the building’s walls and roof were constructed from aluminum tiles. This type of structures could affect the transmission range and considerably reduce it. Future work could use an outdoor gateway placed in a better position.

The NUCLEO-L476RG board used in the node presented an additional limitation. Before entering Standby mode, the device must save the LoRaWAN session data in the Flash memory. After waking up, the device retrieves the data from the Flash memory and uses it to transmit the newly acquired measurements. The problem with this solution is that Flash memory has a low number of Read/Write cycles before it degrades. This number is minimum 10,000 cycles for the L4 board [17], which means that the prototype may damage the Flash memory and stop working during typical operation if left on for an extended amount of time. A better alternative would be to use a microcontroller with included EEPROM memory, such as an STM32L073RZ, which have an endurance of 100,000 cycles [18] and would last much longer before degrading. The STM32L476RG microcontroller inside the board does not include EEPROM memory. Therefore, a possible improvement to the prototype is to change the microcontroller to another with EEPROM memory and modify the program to save the session here instead of the Flash memory.

Table 2 shows a summary of the prices for each section of the data buoy prototype. Refer to the project website for more details in the corresponding Bill of Materials. The total price corresponds to close to 2.5 times the minimum wage in Colombia. Remarkably, close to 85% of the total cost is related to the sensors. This price includes the sensor probes, the reading circuits, and the required connectors and adapters. As a result, the biggest challenge for reducing the cost of these devices involves lowering those related to the sensors.

[Figure omitted. See PDF.]

Also, more recent microcontrollers from the STM32WL series integrate a sub-GHz radio for LoRaWAN and Sigfox communications. These may prove to be a more appropriate alternative, and future work could investigate the potential of these newer models for remote monitoring.

Conclusion

This paper presents an open-source prototype design for remote monitoring of water quality variables for fish farming. The device was tested at an operating fish farm, and future possible improvements based on issues encountered during the field test are proposed. The results successfully demonstrate the potential for battery-operated systems using LoRaWAN to replace conventional manual sampling methods.

Supporting information

S1 Video. Field test fish farm aerial view.

https://doi.org/10.1371/journal.pone.0270202.s001

(MOV)

S2 Video. Data buoy prototype during operation.

https://doi.org/10.1371/journal.pone.0270202.s002

(MOV)

Citation: Medina JD, Arias A, Triana JM, Giraldo LF, Segura-Quijano F, Gonzalez-Mancera A, et al. (2022) Open-source low-cost design of a buoy for remote water quality monitoring in fish farming. PLoS ONE 17(6): e0270202. https://doi.org/10.1371/journal.pone.0270202

About the Authors:

Juan D. Medina

Roles: Conceptualization, Data curation, Formal analysis, Investigation, Methodology, Software, Validation, Writing – original draft, Writing – review & editing

Affiliation: Department of Electrical and Electronic Engineering, Universidad de los Andes, Bogotá, Colombia

https://orcid.org/0000-0003-4077-9365

Alejandro Arias

Roles: Conceptualization, Investigation, Software, Supervision, Validation

Affiliation: Department of Electrical and Electronic Engineering, Universidad de los Andes, Bogotá, Colombia

Juan M. Triana

Roles: Investigation, Methodology, Resources

Affiliation: Department of Mechanical Engineering, Universidad de los Andes, Bogotá, Colombia

Luis F. Giraldo

Roles: Conceptualization, Data curation, Formal analysis, Funding acquisition, Investigation, Methodology, Project administration, Validation, Writing – review & editing

E-mail: [email protected]

Affiliation: Department of Electrical and Electronic Engineering, Universidad de los Andes, Bogotá, Colombia

https://orcid.org/0000-0002-2492-4422

Fredy Segura-Quijano

Roles: Investigation, Methodology, Writing – review & editing

Affiliation: Department of Electrical and Electronic Engineering, Universidad de los Andes, Bogotá, Colombia

https://orcid.org/0000-0001-7757-1432

Andres Gonzalez-Mancera

Roles: Formal analysis, Investigation, Methodology, Resources, Writing – review & editing

Affiliation: Department of Mechanical Engineering, Universidad de los Andes, Bogotá, Colombia

https://orcid.org/0000-0002-0663-2653

Andres F. Zambrano

Roles: Methodology, Supervision, Writing – review & editing

Affiliation: Department of Electrical and Electronic Engineering, Universidad de los Andes, Bogotá, Colombia

Julián Quimbayo

Roles: Resources, Software, Supervision

Affiliation: Department of Systems Engineering, Corporación Universitaria del Huila, Neiva, Colombia

https://orcid.org/0000-0001-6846-9997

Eduardo Castillo

Roles: Conceptualization, Resources

Affiliation: Department of Veterinary Medicine, Corporación Universitaria del Huila, Neiva, Colombia

References

1. Boyd CE, Tucker CS. Pond Aquaculture Water Quality Management. 1st ed. Springer US; 1998. Available from: https://link.springer.com/book/10.1007/978-1-4615-5407-3.

2. Mallya YJ, Thorarensen SPH. THE EFFECTS OF DISSOLVED OXYGEN ON FISH GROWTH IN AQUACULTURE. 2007.

3. Zambrano AF, Giraldo LF, Quimbayo J, Medina B, Castillo E. Machine learning for manually-measured water quality prediction in fish farming. PLOS ONE. 2021;16(8):e0256380. pmid:34407149

4. Antony AP, Lu J, Sweeney DJ. Seeds of Silicon: Internet of Things for Smallholder Agriculture; 2019. Available from: https://d-lab.mit.edu/resources/publications/seeds-silicon-internet-things-smallholder-agriculture.

5. Simbeye DS, Zhao J, Yang S. Design and deployment of wireless sensor networks for aquaculture monitoring and control based on virtual instruments. Computers and Electronics in Agriculture. 2014;102:31–42.

6. Smart Water Management IoT Solution | Water Quality Sensors Certified;. Available from: https://www.libelium.com/iot-solutions/smart-water/.

7. The Things Network;. Available from: https://www.thethingsnetwork.org/.

8. Cloud Computing Services—Amazon Web Services (AWS);. Available from: https://aws.amazon.com/.

9. Atlas Scientific | Environmental Robotics;. Available from: https://atlas-scientific.com/.

10. Mekki K, Bajic E, Chaxel F, Meyer F. A comparative study of LPWAN technologies for large-scale IoT deployment. ICT Express. 2019;5(1):1–7.

11. Products—Satellite modems and data network—Swarm;. Available from: https://swarm.space/products/.

12. Lacuna—Low-cost, simple and reliable global connections to sensors and mobile equipment.;. Available from: https://lacuna.space/.

13. Lora-net/LoRaMac-node: Reference implementation and documentation of a LoRa network node.;. Available from: https://github.com/Lora-net/LoRaMac-node.

14. mcci-catena/arduino-lmic: LoraWAN-MAC-in-C library, adapted to run under the Arduino environment;. Available from: https://github.com/mcci-catena/arduino-lmic.

15. Bouguera T, Diouris JF, Chaillout JJ, Jaouadi R, Andrieux G. Energy Consumption Model for Sensor Nodes Based on LoRa and LoRaWAN. Sensors (Basel, Switzerland). 2018;18(7). pmid:29966354

16. MN1500. Duracell; 2016. Available from: https://www.duracell.com/wp-content/uploads/2016/03/MN1500_US_CT1.pdf.

17. STM32L476xx. STMicroelectronics; 2019. DS10198. Available from: https://www.st.com/resource/en/datasheet/stm32l476rg.pdf.

18. STM32L073xx. STMicroelectronics; 2020. DS10685. Available from: https://www.st.com/resource/en/datasheet/stm32l073rz.pdf.