A Versatile, Low-Power and Low-Cost IoT Device for Field Data Gathering in Precision Agriculture Practices

Abstract

Spatial and temporal variability characterization in Precision Agriculture (PA) practices is often accomplished by proximity data gathering devices, which acquire data from a wide variety of sensors installed within the vicinity of crops. Proximity data acquisition usually depends on a hardware solution to which some sensors can be coupled, managed by a software that may (or may not) store, process and send acquired data to a back-end using some communication protocol. The sheer number of both proprietary and open hardware solutions, together with the diversity and characteristics of available sensors, is enough to deem the task of designing a data acquisition device complex. Factoring in the harsh operational context, the multiple DIY solutions presented by an active online community, available in-field power approaches and the different communication protocols, each proximity monitoring solution can be regarded as singular. Data acquisition devices should be increasingly flexible, not only by supporting a large number of heterogeneous sensors, but also by being able to resort to different communication protocols, depending on both the operational and functional contexts in which they are deployed. Furthermore, these small and unattended devices need to be sufficiently robust and cost-effective to allow greater in-field measurement granularity 365 days/year. This paper presents a low-cost, flexible and robust data acquisition device that can be deployed in different operational contexts, as it also supports three different communication technologies: IEEE 802.15.4/ZigBee, LoRa/LoRaWAN and GRPS. Software and hardware features, suitable for using heat pulse methods to measure sap flow, leaf wetness sensors and others are embedded. Its power consumption is of only 83 $\mathsf{\mu }$A during sleep mode and the cost of the basic unit was kept below the EUR 100 limit. In-field continuous evaluation over the past three years prove that the proposed solution—SPWAS’21—is not only reliable but also represents a robust and low-cost data acquisition device capable of gathering different parameters of interest in PA practices.

1. Introduction

Precision agriculture (PA) and smart farming (SF) are concepts that have been increasingly underlying the management of contemporary agricultural practices, essentially to make them more efficient. Indeed, the unwritten goal has quickly become to improve crop’ yields using less resources and preferably resorting to more sustainable practices. Both PA and SF have had an unprecedented evolution in more recent years, largely due to the incorporation of technologies from Industry 4.0. Consequently, terms such as Internet of Things (IoT), Big Data, Analytics, Artificial Intelligence and others are becoming a part of daily management activities in agriculture. While remote monitoring technologies—RGB, thermal, multispectral and hyperspectral aerial imagery, as well as radar—are important in monitoring parameters that enable the assessment of crops’ development, proximity data acquisition devices may play a key role both as a complement to remote sensing and as the main source of data. Actually, they are particularly useful in characterizing the meteorological context in which crops develop, as well as to monitor parameters that enable an evaluation of development conditions with a finer granularity, and often to do an estimation about potential disease risks. Considering that PA’s underlying goal (and necessity) is the understanding of crops’ spatial and temporal variability, the proliferation of small data acquisition units, at significantly reduced costs, has happened in recent years, also as a way to increase acquired data detail and coverage. Moreover, these units harvest energy from the surroundings and are able to exchange data with their neighbouring units.

A comprehensive bibliographic review highlights some relevant trends in the recent past years: (i) there has been a proliferation of DIY (Do-It-Yourself) devices based on Arduino^® or comparable systems that use open-source software and online communities to promote proximity monitoring solutions; and (ii) many of the sensors traditionally used in PA, e.g., temperature, relative air humidity, soil moisture, leaf wetness, have been replaced by more economical versions, which generally lack the robustness for in-field monitoring 365 days/year. Therefore, it seems that there is a tendency to trade off resolution for quantity. In fact, a few high-resolution sensors seem to be replaced by many redundant lower-resolution versions. Furthermore, these low-cost versions need to be periodically replaced, as they are not prepared to continuously operate in harsh environments. Data collection devices placed in outdoor agricultural environments are subject to conditions that may cause degradation over time and that in some cases can even lead to malfunction. Some of these conditions and a set of good practices that are acquired from experience include the following: (i) Temperature variations may cause degradation on battery performance; (ii) Electrical spring contacts should be avoided, and mechanical clamping contacts are preferred. (iii) Air moisture often causes oxidation of exposed conductive elements and promotes unwanted electrical short circuits. (iv) Enclosures must have an adequate protection index (Ingress Protection) both in terms of water (e.g., rain) and mechanical robustness, which allow for efficient isolation of the electronic system from the environment. Particular attention should be given to cable glands, which must also prevent insects from gaining entry in the system. (v) Solar radiation (namely ultraviolet wavelengths) cause wear and tear on plastic enclosures and supports. (vi) Daily use (or field work in agricultural contexts) must also be considered, as there is a risk that devices are damaged by both machines and workers.

Be that as it may, the majority of publications that appear when the search terms include wireless sensor networks (WSN) and PA resulted in many works where electronics DIY is prevalent. In regard to data transmission, proprietary radio-frequency solutions—often in Ultra High Frequency (UHF) bands to allow for a reasonable range—swiftly gave place to a set of standards and technologies that enable a solution on how to forward data from sensors spread out by vast agricultural fields to a remote place, where subsequent processing, storage and preview tasks may occur.

Agricultural fields are communication scenarios that can be often characterized by having extensive areas to overcome, frequently lacking 2G/3G/4G network coverage and with no available electricity. Therefore, the need arises to deploy a more complex network structure, e.g., mesh, usually tailored to each operational context—for the sake of effectiveness. Standards such as IEEE 802.15.4 and LoRa have emerged to promote specific data transmission solutions for sensors. Whereas IEEE 802.15.4 is the basis of network protocols such as ZigBee and supports mesh network solutions, LoRa is capable of directly sending data packages to gateways located up to 15 km away, creating LoRaWAN (Long Range Wide Area Network) networks where the payloads are integrated into customers’ applications. The 6LoWPAN protocol emerges as the first true IoT protocol, providing IPv6 support for IEEE 802.15.4 connections. Indeed, the IPv6 header was compressed to just a few bytes through an adaptation layer between both the network and MAC layers still maintaining IPv6 functionality. Furthermore, the transmission of 1280 bytes IPv6 Maximum Transmission Unit (MTU) over IEEE 802.15.4 is also made possible using fragmentation and reassembly, provided by the aforementioned adaptation layer [1]. In addition to these already very popular standards, others such as BLE (Bluetooth Low Energy) and Radio-Frequency IDentification (RFID) enable short-range connections. They are particularly useful to have data transferred from idle sensors that wake up when a collection element passes by within range. Communications based on GSM/GPRS 2G/3G and 4G-LTE are particularly interesting for establishing a connection with the Internet and provide higher speeds and greater data volume (e.g., transfer multimedia content). Among the aforementioned technologies, data communication that uses GPRS 2G/3G/4G modems are those that use more power, which makes them the preferred choice for communication between in-field gateways—aggregating data coming from sensor networks, and other remote environments. In fact, the gateway structure with data communication based on GSM/GPRS technology has been referred to in the literature as that that separates local data collection through communication supported by other standards of the place where data are stored (following or not a cloud structure, for example).

With regard to power supply, the overwhelming majority of papers refer to devices that rely on one or more combined forms of energy harvesting. Solar is undoubtedly the preferred source of power to charge devices’ batteries. The bulk of sensor nodes operate on a periodic power profile for data acquisition and/or transmission. A battery charged by a solar panel seems to be the elected option by most solutions described in the literature. It suffices because current, common embedded systems, as well as most of the sensors used, are in fact low-consumption systems. Moreover, they remain idle when not operating, which saves power. However, systems that need to operate perpetually, such as gateways, routers and other devices that are continuously connected, have their autonomy affected by available power. A recurrent solution seems to be to oversize the capacity of both production and storage systems, since the associated costs tend to be marginal. Some authors emphasize the thought to inter-complement renewable power sources to assure, within their randomness, some constant supply. Examples include solar and wind power, as well as kinetic energy from moving water in pipes [2,3].

Heterogeneity is a well-established characterization of the most common sensors for PA applications. Besides sensors with analog output (including voltage and current), others may have frequency output, potential-free contacts and may use some digital protocol, such as RS485 and SDI-12. Power requirements are also not homogeneous. While there are sensors that can only be powered by a specific and fixed voltage value, others cannot handle low voltages and/or have inadequate power consumption for IoT applications. The time between the moment when a sensor is turned on and when it is able to provide a valid output is also very important. Actuation of some sort is also necessary sometimes. For example, with heat pulse-based sensors, such those used to measure soil moisture and sap flow, it is usual to have an output that controls the power supply system for the heating system.

The aforementioned constraints should be considered to develop a low-cost data acquisition device, flexible enough so that it can become an interesting and competitive solution to monitor parameters in PA scenarios. Moreover, best practices in data acquisition within harsh environments, such as the agricultural fields, for electronic systems should also be factored in. SPWAS’21 device (Solar Powered Wireless Acquisition System, 21st edition) was developed and tested as a low-cost robust solution that aims to satisfy a wide range of requirements with regard to the most common sensors for use in PA. SPWAS’21 stands in as an IoT device that easily and with the same hardware can adapt the data acquisition process to a wide range of sensors used in various types of crops in an open field, at low cost, to promote a high granularity and thus better describe the spatial variability usually targeted by PA practices and with the possibility of using the most usual communication protocols.

The paper is structured as follows: Section 2 presents the related work reviewing published papers from the past five years that use WSN technologies and data acquisition nodes/devices in PA or PV (Precision Viticulture) applications. Section 3 describes materials and methods, detailing the system’s architecture, hardware options, system operation emphasising sensors and communication technologies used, and data integration with the mySense platform. Section 4 presents the results obtained during the tests carried out in a vineyard located in northeastern Portugal, and Section 5 finishes the paper with some conclusions drawn from practical in-field evaluation.

2. Related Work

This section reviews published works from the past five years that use WSN technologies and data acquisition nodes/devices in PA/PV applications. The goal is to evaluate communication technologies used to exchange data between devices, to classify their flexibility with regard to supported sensors, to verify the power supply and energy storage systems used, and to analyze their energy consumption. The most significant studies from this literature review are summarized in

Table 1. Research works published in past five years (2017–present) related to the use of data acquisition devices in PA/PV applications.

Work	Node Type	Nodes Communication	Gateway	Nodes Power Supply Type	Nodes Power Consumption (mA)	Sensors
[4]	Microcontroller based (Arduino®)	WiFi, ZigBee, LoRaWAN	No	3.65 W solar panel 3.7 V 6600 mAh Li-Po battery	270 mA (WiFi) 120 mA (ZigBee) 90 mA (LoRaWAN)	GSMS
[5]	Microcontroller based (Arduino® compatible)	Bluetooth®, XBee, WiFi, RF	Yes (WSN coordinator)	N/A	N/A	HTM2500LF
[6]	Microcontroller based (Arduino®)	LoRa (915 MHz)	Yes (Arduino® and ESP8266 based)	6000 mAh Li-Ion battery	N/A	SKU:SEN0193, pH (n/s)
[7]	Microcontroller based (Arduino®)	RF (nRF24L01)	Yes (Mini PC based)	N/A	N/A	DHT11, TGS813, SO2 gas (n/s), PIR motion (n/s), soil pH (n/s), EC-5
[8]	Microcontroller based (Arduino®)	ZigBee	Yes (n/s)	3.65 W solar panel 3.7 V 6600 mAh Li-Po battery	80 mA (Arduino®) 40 mA (XBee module) 35 mA (SM sensor) 1.5 mA (DHT22)	DHT22, GSMS
[9]	RPi 3B and Arduino® based	LoRa	Yes (Dragino LG-01 based)	N/A	N/A	RPi Camera v2
[10,11]	Microcontroller based (ESP8266)	WiFi	Yes (RPi 2B and Arduino® based)	Solar panel (n/s) 2 or 4 × 2100 mAh AA batteries	75 mA (transmission) 6 mA (deep-sleep)	DHT22, DS18B20, SHT11
[12]	Microcontroller based (STM32L011)	ZigBee, LoRaWAN	Yes (n/s)	N/A	N/A	SHTC1
[13]	Microcontroller based (STM32L151CBU6)	LoRa	Yes (Smart4418 board based)	Solar panel (n/s) 6000 mAh Lithium battery	250–300 mA (operation)	T (n/s), RH (n/s), WS (n/s), WD (n/s), PM2.5, PM10
[14]	Zolertia Re-Mote based	RF (2.4 Ghz/863–950 MHz)	Yes (RPi 3 and Zolertia Re-Mote based)	Battery (n/s)	N/A	T (n/s), RH (n/s), SR (n/s), noise (n/s), PM10
[15]	Microcontroller based (Moteino)	LoRaWAN	Yes (RPi 3B+ based)	Optional solar panel (n/s) 3.7 V 2000 mAh or 2600 mAh Li-Po battery	9.4 mA (active) 22 mA (transmission) 0.036 mA (sleep mode) 0.674 mA (average)	ECH2O 10HS, ECH2O 5TE
[16]	Microcontroller based (Heltec WiFi LoRa 32)	LoRaWAN	Yes (RPi 3B+ based)	1000 mAh Li-Ion battery	N/A	DHT11
[17]	Device off-the-shelf components based	IEEE 802.15.4 2.4 GHz	No	Solar panel (n/s)	N/A	SHT11, DS18B20, Watermark 200SS
[18]	Microcontroller based (n/s)	RFID	Yes (n/s)	RFID energy harvesting	N/A	T (n/s), SM (n/s), SCIC (n/s)

Legend: N/A: not available; n/s: not specified; T: temperature; RH: relative humidity; SR: solar radiation; SM: soil moisture; WS: wind speed; WD: wind direction; SCIC: soil chloride ion concentration; GSMS: Grove soil moisture sensor from Seeed Technology Co., Ltd.; Li-Po: Lithium Polymer; Li-Ion: Lithium-Ion; RF: radio frequency.

. A brief comparison is made thereafter. The following criteria are considered in this selection: (1) type of node where sensors are connected to understand what type of hardware has been used; (2) what protocols are used to deploy a WSN; (3) if a field gateway is used; (4) how the nodes are powered; (5) what the node power consumption is; (6) which sensors are used at each node.

From the literature review, the prevalence of Arduino^® as the platform as the microcontroller system used in the WSN nodes is unquestionable [4,5,6,7,8,9]. The reasons behind this choice lie in its popularity, low cost, being open-system, and having a large community of enthusiasts and online support. ESP8266 and ESP32 devices are also used as low-power and low-cost alternatives to the Arduino^® platform, adding WiFi communication capabilities [10,11]. Works [12,13] report the use of STM family microcontrollers (STMicroelectronics, Geneva, Switzerland). There are also works that use nodes based on other development boards such as Zolertia Re-Mote (Zolertia S.L., Barcelona, Spain) [14], Moteino (LowPowerLab LLC, Michigan, MI, USA) [15], and Heltec WiFi LoRa 32 (Heltec Automation, Chengdu, China) [16].

With regard to communication technologies between nodes and gateways/base stations, LoRa/LoRaWAN is used in half of the reviewed papers. RF communication is the second most used transmission technology. WiFi, IEEE 802.15.4/ZigBee and Bluetooth are also used in some cases. Works [4,5,12] present solutions where it is possible to choose from different communication technologies whose choice depends on the project’s characteristics, such as range and data rate.

Not all works made use of a gateway/base station [4,17]. A solution based on a Single Board Computer (SBC), mainly using a Raspberry Pi family SBC, possibly due to its popularity and support, is the most common choice. A Mini PC-based gateway is used in [7], a Dragino LG-01 gateway solution is used in [9], and a Smart4418 board is used in [13]. In [6], the gateway is designed around an Arduino and an ESP8266. Works [8,18] report the use of a gateway/base station, but no information is given about its details.

One of the main concerns is the network nodes’ power supply. It should suffice the power needs and, if possible, maintain the system powered for long periods of time and with little to no maintenance. One of the main solutions is the use of solar power with the respective battery, since solar energy is not available all day. For those works that uses this solution, lithium-based batteries are the main choice. Since nodes are generally designed for reduced energy consumption, this type of battery is enough. In the case of gateways, depending on the type, Lead Acid batteries are chosen due to increased power needs. While in [14] it is reported the the a battery is used as the only power source but no more details were revealed, in [6,16] as well, only a battery is used, reporting the use of a lithium-based battery. In [6,16], LoRa/LoRaWAN communication is used, and a battery may last for long periods of time, but in [14], RF communication is used, and in this case, power consumption is normally high and the use of a battery makes less sense. Interestingly enough, the work in [18] reports the use of energy harvesting to power the nodes, in this case using the energy harvested from an RFID reader. In four works, no information is given about nodes powering. In general, power consumption ranges from some mA to several hundreds of mA. Even though power consumption decreased when compared to older systems, it still is considerably high. Note the work of [15], which consumes about $36\mathsf{\mu }\mathrm{A}$ in sleep mode.

Some works are in an early stage of development, and possibly because of that, they use only one type of sensor, usually a temperature sensor, or only a few of the more common sensors, such as relative humidity and soil moisture sensors. Many use low-cost sensors such as DHT11 or DHT22 (Aosong Electronics Co. Ltd., Guangzhou, China) for temperature and relative humidity measurements or DS18B20 (Maxim Integrated, USA) for temperature measurements. Others resort to more expensive sensors such as the SHT11 (Sensirion AG, Stäf, Switzerland) or HTM2500LF (TE Connectivity Ltd., Schaffhausen, Switzerland), possibly requiring more accuracy in the measurements. Works [13,14] resort to some sensors normally found in weather stations measuring air temperature and relative humidity. In [14], solar radiation, noise and air-quality sensors (PM10) are also used. In [13], wind speed and direction and air quality sensors are also used. In [18], soil moisture and soil chloride ion concentration sensors are used, as well as a temperature sensor. Soil pH is measured in [7]. Only the work of [9] deviates from normally used sensors, resorting to a camera (Raspberry Pi camera v2). This variety of used sensors can be explained by the different needs of each study group.

Some works do not report what collected data are used. Some report sending data to a cloud or server, but no more details are given. It is not even clear whether it is possible to access the retrieved data. However, there are some exceptions. The work of [14] reports the use of a cloud service responsible for data storage, high level data processing and providing services. In [6], acquired data are transmitted to a cloud where end users can log in to access that data through a web browser with an interface that presents the last arrived data and charts with previous received data. In [5], combining remote and proximal sensor systems, it is intended to evaluate the vineyard thermal dynamics. Thermal data acquired with an unmanned aerial vehicle (UAV) and data from the WSN nodes are used to develop vine stress and grape-quality predictors. Even though research in this area is progressing, there is still much do, and many works are just beginning to be developed. Only a few works report some use of collected data.

Based on this literature review, there are some trends related to the use of multiple data communication technologies, heterogeneity of sensors to be used and the need to have online support for data processing, all at a reduced cost. Offering a set of solutions in the same device suggests enhancing greater granularity of measurement and more effective data collection.

3. Materials and Methods

Based on the literature review and on the needs identified during the tests performed to evaluate the relevance of the solution presented here, the first step was to identify a set of inexpensive sensors that would cover the widest range of parameters of interest. A summary can be found in

Table 2. Low-cost or/and common sensors identified as possible solutions for agrometeorology measurements in PA practices.

Reference	Parameter	Output Type	Power Supply	Power Consumption	Cost ()
TSL230 (TAOS)	Solar irradiance	Frequency	2.7–6 V	2 mA	1.50
DHT22 (Aosong)	T, RH	Digital	3.3–6 V	1.5 mA	2.00
10-HS (Decagon)	VWC	Voltage	3–12 V	12 mA/3.0 V	169.00
5-TE (Decagon)	VWC, EC	Digital (SDI-12)	3.6–15 V	3.0 mA	380.00
300.021 (Pronamic)	Rain gauge	Tip count	N/A	–	120.00
PCB (Proprietary)	Leaf wetness	Resistance	N/A	<50 $\mathsf{\mu }$A	5.00
Anenometer	Wind speed	Count	N/A	–	20.00
Thermocouple	Temperature	Voltage	N/A	–	3.50

Legend: N/A: not available or not applicable; T: temperature; RH: relative humidity; VWC: volumetric water content; EC: electrical conductivity; TAOS: Texas Advanced Optical Sensors.

.

3.1. System Architecture

SPWAS’21 system was built around a low-cost, low-power RISC 32-bit architecture microcontroller unit, MCU, (PIC32MX150F128, MicrochipTechnology Inc., Chandler, AZ, USA), featuring low power consumption ($23\mathsf{\mu }\mathrm{A}$ in sleep mode) and a wide range of peripherals. For analog to digital conversion, a low-power, 12-bit, internal 2.5 V reference converter was used (AD7888BRZ, Analog Devices Inc., Wilmington, MA, USA), while for thermocouple measurements, a precision thermocouple to digital converter with linearization and internal cold-junction compensation was used (MAX31856, Maxim Integrated, San Jose, CA, USA). Temporary storage for up to 500 data records is provided by a low-cost, low-power, 64 kbyte EEPROM (Electrically Erasable Programmable Read-Only Memory) device (25LC512, Microchip Technology Inc., Chandler, AZ, USA). Regarding actuating capabilities, SPWAS’21 has two specific outputs handled by its internal firmware. One is used to control a heater device (commonly used in heat pulse measurement methods such as Granier probes in sap-flow determination) powered by an external power source, while a second one is used to control, for instance, an irrigation solenoid valve. Figure 1 shows a simplified system architecture block diagram.

Power management plays a fundamental role when designing a field device that must operate in a perpetual mode. Small, stationary and unattended devices are often powered by batteries recharged using energy harvested from the sun and other energy sources [3]. The SPWAS’21 system, like its predecessors [19,20,21], uses solar energy to charge a single-cell 2000 mAh Li-Po battery, as the main energy reservoir. A highly integrated solution based on a BQ21040 (Texas Instruments, TX, USA) was used to recharge the Li-Po battery. It allows input voltages up to a maximum of 28 V, thus enabling the use of panels that can be somewhat high in some photovoltaic panel configurations, even low-power ones. For higher voltages, an optional ultra low quiescent current, linear regulator (MAX16910, Maxim Integrated, San Jose, CA, USA), can be used as a pre-regulation stage.

The system’s main power (3.3 V) is provided by a very low quiescent current linear regulator (MAX884, Maxim Integrated, San Jose, CA, USA). In this case, a linear solution is more advantageous than using a DC/DC conversion approach due to energy consumption without load, i.e., when the system is in sleep mode. Switched DC/DC converters are much more efficient (over 95%), but this efficiency is usually achieved over medium or high loads. For very low currents (below 0.1 mA), typical efficiency can drop below 45%. Sampling intervals in PA applications are often defined as 15 min, which may represent on/off cycles around 1% (about 9 seconds of system activity every 15 min). In these cases (and most of the time), the switched DC/DC converter powers a system with a very low-efficiency. It was found that despite being much more efficient for moderate loads (say between 50 and 100 mA), the time that the converter powers these loads is comparatively very short. Therefore, a linear solution was chosen to minimize the quiescent current, as this is dominant most of the time.

The battery voltage safe limits, which allow the system to operate adequately, are defined through a comparator with hysteresis (ICL7665, Maxim Integrated, San Jose, CA, USA). In turn, it controls a PMOS (P-channel metal–oxide–semiconductor) switch, responsible for turning on the entire system. Figure 2 illustrates a simplified diagram of the energy management sub-circuit.

Figure 3 shows a SPWAS’21 device along with its common communication boards built for evaluation under practical field operations. Each communication board uses a wireless device, referred to in

Table 3. Communications solutions available for use on the SPWAS’21 platform.

Reference	Manufacturer	Standard	Power Supply	Power Consumption	Cost
GL865-QUAD-V3	Telit	GSM/GPRS/3GPP	3.1–4.5 V	300 mA, max	46
RN2483A-I/RM105	Microchip	LoRa/LoRaWAN	2.1–3.6 V	39 mA @ +3.3 V, +14.1 dBm (868 MHz)	11
XB24CZ7UIS-004	Digi International	IEEE 802.15.4/ZigBee	2.1–3.6 V	45 mA @ +3.3 V, +8 dBm	19
RN171XVU-I/RM	Microchip	IEEE 802.11b/g	3.0–3.7 V	180 mA (TX) @ +3.3 V, +10 dBm	25

.

Regarding the firmware used, the MCU runs a state machine as a real-time operating system (RTOS) responsible for managing all peripherals and communications. Most of the time, the device is kept in a sleep state with the aim of saving power. In each data acquisition interval (defined using the RTOS), the state machine activates the power supply to the sensors and after 2 seconds proceeds to acquire data. For sensors that produce asynchronous events, such as a rain gauge, in the inputs cause MCU interrupts that in turn are responsible for registering that event. At the time of data transmission (also programmable by the RTOS), the state machine manages the whole process of data exchange with the superior entity (gateway or cloud, depending on the communications infrastructure used), through another state machine, guaranteeing the independence of the software processes.

3.2. Networking

One of the goals underlying the development and concept of the SPWAS’21 platform was to be able to change the way the system communicates with other systems, within the context of IoT and Machine-to-Machine (M2M) interaction, based on the most viable options in terms of range, energy consumption, availability and interconnection capabilities with other systems, with respect to the goals of the targeted monitoring application. Communication protocols such as LoRa/LoRaWAN, IEEE 802.15.4/ZigBee and GSM/GPRS 2G/3G/4G are among the most adopted solutions to exchange data across large areas. Thus, the SPWAS’21 platform was designed to rapidly change the used protocol and completely configure the system through a simple replacement of a communication module. Table 3 summarizes the modules that have been tested (others may be added in the future through firmware upgrade).

In addition to the wireless data communication solutions described above, another functionality was included: allowing data exchange through a wired connection, through a USB (Universal Serial Bus) port. This feature allows the SPWAS’21 platform to be integrated with other systems, communicating between them through JSON (JavaScript Object Notation) messages, which can be an extra benefit in existing gateways, for instance.

3.3. Data Integration

One major technological evolution regarding sensor data integration and management that the IoT paradigm has brought us in recent years is that all data are now being relayed to some web-based infrastructure, with the inherent facilities of data handling, processing and storage. It is therefore natural that storage solutions on memory cards or other forms have been overtaken by storage on the web, which implies that, somewhere along the path of these data, there is a point where there is a web platform to which the data are forwarded. In the past five years, the mySense [20] platform has been developed to attend to this need. It is a web/cloud infrastructure to which data can be sent through an API (Application Programming Interface). Thus, the integration of data from SPWAS’21 devices can be performed directly (when using GPRS modules), through LoRaWAN network servers (e.g., Wavesys or The Things Network), or indirectly when using the IEEE 802.15.4/ZigBee interface. In the latter, the data from sensors may be relayed over a mesh network to some type of gateway where they are aggregated and later transmitted to the mySense platform using some IP technology.

3.4. Experimental Setup

The evaluation of the SPWAS’21 devices was performed in a vineyard of the campus of the University de Trás-os-Montes e Alto Douro, located in northeastern Portugal (41.286965, −7.735533). In this way, the main objective of a long-duration practical evaluation was fulfilled, which, besides collecting agrometeorological data to support the determination of prediction models for powdery mildew and other vine diseases, allowed us to evaluate its performance in real conditions of use. This means that the long-term evaluation was to ensure that the entire data collection process would run without interruptions with regard to power management and communications subsystems. In an initial phase, one of the objectives was to verify whether mesh-type networks (IEEE 802.15.4/ZigBee) were indeed viable solutions that take into account the dynamics of the crop throughout its vegetative stage. In a second phase (starting April, 2020), LoRa/LoRaWAN communications were also evaluated to check its susceptibility to obstacles between the device and the network server.

Several SPWAS’21 devices (out of a total of six) were deployed in a vineyard for the acquisition of agrometeorological data every 15 min. Four devices formed a mesh network over IEEE 802.15.4/ZigBee links, transmitting and relaying data to a WSN coordinator and field gateway. For evaluation purposes, a fifth device transmitted data over a LoRaWAN connection to a Wavesys LoRa gateway/network server, located 4 km away and within the line of sight. The last device used a GPRS 2G connection.

4. Results

SPWAS’21 platform performance analysis from the last three years of being placed in-field brought about some of the many experiences gathered, namely those referring to its constraints, consumption and energy autonomy. During the three-year period, many abnormal operations occurred, which led to some important improvements with regard to both hardware and software. An example was the number of unsuccessful communication attempts, which were invariably related to the communications subsystem setup: the range between devices, positioning and gain of the antenna of the communications module used, and communications management by the system firmware. Indeed, whenever a communication attempt resulted in failure, there was always a set of two additional attempts. In turn, if these were exhausted, the problem was analyzed and the best solution was implemented, even if this in some way limited the initial setup. This was the case of the distance covered by the IEEE.802.15.4/ZigBee modules. The option was not to work at the coverage limit, knowing beforehand that the error rate, packet loss and other error metrics would increase. Since April, 2020, SPWAS’21 devices have reached a level of robustness (e.g., enclosure IP65 protection, electrical contacts, battery undervoltage recovery) that allows them to work continuously and with minimal maintenance, limited only to addressing situations derived from abnormal situations, such as damage caused by machinery during agricultural field work or replacement of components, such as batteries and sensor cables, when they reach their end-of-life. Once this robustness level was reached, a set of tests began, and those presented in this paper mainly focus on the last two months of data collection.

• SPWAS’21 power consumption was less than $83\mathsf{\mu }\mathrm{A}$, drawn from Li-Po battery when in sleep mode. Considering a power profile of about 10 mA/3.3 V for 2 s for sensors warm-up and data acquisition, followed by an average time of 1 second, which consumed a maximum of 30 mA/3.3 V for data transmission using XBee or RN2483A modules every 15 min, an average power consumption of about $150\mathsf{\mu }\mathrm{A}$/3.3 V was achieved (including all electronics quiescent current, measured using a 6 1/2-digit precision digital multimeter, Keithley 2000). Regarding the solar-panel energy transducers, three options were tested. The first one was a low-voltage, small unit (MIKROE-651, Mikroelektronika, Belgrade, Serbia) rated 4.0 V/100 mA, costing approximately EUR 9.5 and measuring 70 mm × 65 mm. In this case, a boost DC/DC converter was used to produce a 5 V output voltage needed by the BQ12040 Li-Po battery charger. The second choice was a 3 W solar panel from Libelium, rated 5.8 V/0.52 A, costing EUR 55 and measuring 234 mm × 160 mm. The third choice was a 5 W solar panel from RS PRO, rated 16.8 V/0.3 A, costing EUR 17 and measuring 250 mm × 200 mm. Based on comparing the cost, size and energy produced of these three solutions, the last one proved to be more suitable.
• When using GPRS modem GL865 QUAD V3 for exchanging data with mySense web/cloud server, every half hour for accelerating battery discharge in real use without having the solar panel plugged in, an autonomy of approximately 1.5 months was easily achieved, Figure 4.
• XBee and LoRa/LoraWAN were found to be interesting when payload data have a low-count byte size. Data from many sensors occupy a lot of space and data must by fragmented and reassembled in some way upon reception. It was expected that IEEE 802.15.4 RF links are susceptible to interference from vegetation, so careful placement of antennas should be considered. Indeed, LoRa suffers from vegetation and other obstacles that are between the line of sight to the near network server. During the winter, where the vineyard has no vegetation, all transmissions using a IEEE 802.15.4/ZigBee network were made without any problems, even at a distance of 100 m between an end-device and the network coordinator. The antennas, all whip monopole, were initially placed on top of the system’s enclosures (about 60 cm above ground). However, as vegetation grew, the number of unsuccessful communication attempts increased. Tests carried out in [22] revealed that when antennas are positioned close to the ground or by tree tops, the radio signal attenuation is not significantly affected by the presence of tree leaves. The reason is that close to the ground, the leaves are not within the propagation path, while close to tree tops, the diffraction from the canopy-air interface provides an additional propagation mode. Considering that in the region where the tests took place, there is vegetation in the soil that can interfere with the propagation path at certain time periods in the year, the decision was to place the antennas above the canopy level, as shown in Figure 5 (top-right), where this issue does not exist.
• IEEE 802.15.4/ZigBee requires a field gateway, which may pose some constraints when designing a practical application. For a WSN with a small number of devices, it is important to evaluate the need for a gateway against the use of devices that transmit directly to a remote server.

Figure 4 shows the battery discharging profile during an approximately 2-month period. During this period, the 3 W solar panel was unplugged to allow a full battery discharge. More than one month after, the system was disconnected automatically by its internal PMOS switch, and the solar panel was manually reconnected. In this experiment, data were transmitted every half-hour through the GPRS modem, and a set of sensors (rain gauge, temperature, relative humidity, leaf wetness, soil volumetric water content) was used.

Figure 6 shows data from part of these sensors for a full year (2020), while Figure 7 shows, in detail, data from other sensors such as from the 10 HS.

Figure 5 shows additional photographs taken from field evaluation. SPWAS’21 devices shown on the left side use XBee modules to create a WSN. The field gateway and IEEE 802.15.4/ZigBee WSN coordinator is also shown in the bottom-right. To create this effect, an Orange Pi PC plus (Shenzhen Xunlong) was employed, together with a GPRS 2G modem (also a GL865 QUAD V3). In the top-right position, the IEEE 802.15.4/ZigBee module’s antenna, after being movedto a higher position to avoid RF signal degradation, caused by the vegetation.

Figure 4. SPWAS’21 Battery voltage during normal field operation, with data transmission using the GPRS module GL865 QUAD V3 to mySense web/cloud server every half hour to accelerate battery discharging.

Figure 4. SPWAS’21 Battery voltage during normal field operation, with data transmission using the GPRS module GL865 QUAD V3 to mySense web/cloud server every half hour to accelerate battery discharging.

Figure 5. SPWAS’21 field evaluation prototypes. (Left) 2 XBee-based devices; (Bottom-right) Field gateway; (Top-right) Antenna location detail.

Figure 5. SPWAS’21 field evaluation prototypes. (Left) 2 XBee-based devices; (Bottom-right) Field gateway; (Top-right) Antenna location detail.

Figure 6. SPWAS’21 Sample data taken during whole 2020, 15 min sampling interval (Air temperature, red; relative humidity, orange; rainfall, blue.

Figure 6. SPWAS’21 Sample data taken during whole 2020, 15 min sampling interval (Air temperature, red; relative humidity, orange; rainfall, blue.

Figure 7. SPWAS’21 Sample data taken during some consecutive days (air temperature, grey; relative humidity, brown; DHT22 and soil volumetric water content, blue, 10 HS). Solid arrows indicates soil irrigation events.

Figure 7. SPWAS’21 Sample data taken during some consecutive days (air temperature, grey; relative humidity, brown; DHT22 and soil volumetric water content, blue, 10 HS). Solid arrows indicates soil irrigation events.

5. Conclusions

A complete and low-cost IoT solution solution for use in PA applications was described in this paper. Tests carried out in the last 3 years have led to the conclusion that it is reliable in terms of electrical operation (robustness, number of failed communications, power management, error recovery, box/enclosure maintenance and auxiliary systems). In real PA applications, where a data acquisition solution must minimally interfere with the crop for which it is deployed, the SPWAS’21 proposal proved to be an important auxiliary tool, with low maintenance and high flexibility in terms of low-cost sensors that can be used but also the possibility of using others commercially available (such as anemometers, rain gauges, among others). The costs of the most expensive (GPRS option) and least expensive (Wired option) versions of a SPWAS device (GSM/GPRS version) were EUR 157 and EUR 97, respectively, excluding sensors, and taking into account online purchase at distributors and for small quantities.

Regarding energy management, the use of a slightly oversized energy transducer and energy reservoir systems (solar panel and Li-Po battery), while keeping approximately the same size and cost of the systems designed for full use limits, enabled SPWAS’21 to operate without interruption for more than a month without any harvested energy. An average daily consumption of approximately 140 $\mathsf{\mu }$A (including air temperature and relative humidity, rain gauge and VWC sensors) was achieved.

Regarding data communications, the protocol used that posed the most problems turned out to be LoRa/LoRaWAN. The number of failed communications was significantly higher than that obtained with a GSM/GPRS communication. Although the LoRa standard allows ranges in the order of tens of kilometers, it is necessary that the systems are within line-of-sight and that the duty cycle is adequate to allow access to the medium when a join request is made. Unlike smart city applications, where the higher number of network servers allows redundancy, PA applications may suffer from the reduced number of network servers available for data integration of LoRa clients. In contrast, GSM/GPRS-based communications have proven to be quite suitable: firstly, there is no need for a field gateway, and secondly, the cost of GSM/GPRS network access has dropped significantly, allowing the IoT concept to be brought to the sensor end-devices.

Although the current work did not use a device compatible with the new ZigBee 3.0 standard, it is relatively easy to support the concept of a wireless sensor network that needs a gateway, and that this proves to be the best option when there are too many networked devices in a small area. However, it should be noted that in a mesh network, the need for routers that are always powered rivals the GPRS modems that, although they consume more, are powered only a very small fraction of time.

Having a comprehensive range of technological solutions to perform proximity monitoring in PA contexts for several crop types and different parameters seems like a smart strategy at first glance. However, when dealing with harsh monitoring scenarios in the field—which poses harvesting energy and data communication constraints—and an increasing demand for greater measurement granularity to understand spatial variability—which may be achieved by multiplying the number of inexpensive devices—the result can be a combination of heterogeneous single-use devices that need to be replaced every year and do not ensure a reliable source of data for decision support systems. Flexibility for both sensors and communications, robustness and reliability with a low price tag are the main proven features of SPWAS’21. This platform fulfills the functions of data gathering from many sensors that are already compatible with low supply voltage, low power consumption and with intermittent power and have a valid output in a few seconds. Future work will address the incorporation of innovative ways of device powering and data exchange, together with further miniaturization, to promote even further the emergent concept of agriculture of data.