A cost-effective redundant communication system for improving the reliability of a flood early warning system

Nowadays it is common to find a wide variety of early warning systems, ranging from assessing the financial risk of bank conglomerates (Faranda et al. 2015) and famine spreading by drought (Senay et al. 2015) to volcanoes eruptions (Gregg et al. 2015) and the mitigation of the effects of natural disasters (Balis et al. 2013; Calvello et al. 2015). Nevertheless, the management of flood hazards is one of the most frequent and critical components of public safety due to its usually disruptive impact on public health and infrastructure (Plate 2007; Chen et al. 2014). Therefore, the establishment of flood early warning systems (FEWS) has been very active in the last decades to help decision makers deal with hazardous floods (Garrote & Bras 1995; Asante et al. 2007; Henonin et al. 2013; Verdin et al. 2016).

As defined by Plate (2007), a FEWS is a set of actions oriented to protect lives and properties whenever the river free surface elevation attains a pre-established threshold value. Almost all flood warning networks work with gauges and communications system to collect and distribute hydro-meteorological measurements. The information is used in real time to predict whether a flood is about to happen, when it is going to arrive at some critical points within the watershed, and how severe it is going to be.

Floods triggered by heavy rainfalls are of considerable interest in urban regions bounded or crossed by large or medium size rivers (Plate 2007; Fakhruddin et al. 2015). As such, a FEWS is irreplaceable for local authorities since it allows them to take proper action before the flood arrives (Asante et al. 2007; Henonin et al. 2013).

Consequently, an early flood warning embraces few detailed sequential steps (Plate 2007): capturing, transmitting, retrieving, forecasting, warning, and transforming. The last two stages comprise warnings to local decision makers and the population in general and then transforming the warnings into remedial actions. Figure 1 depicts the subsequent phases that make up a FEWS.

Flood warning systems that integrate rainfall monitoring with flood forecasting are now operational in many countries all over the world (Velázquez et al. 2009; Henonin et al. 2013). Indeed, any FEWS has evolved from fully integrated flood management tools involving short-term hydrological forecasting (Merkuryeva et al. 2015) to a stand-alone system that takes in-situ measurements to warn their clients via SMS (short message service) (Kuantama et al. 2013). The relevance of an operational FEWS becomes evident if the potentially avoided flood damages are computed, yielding an approximated benefit of 400€ for every invested € (Pappenberger et al. 2015).

However, the purpose of this work is not to review the state of the art underneath the operation of any FEWS, nor to go through the latest developments in technologies to ease the communications between the data capture and the required short-term flood forecasting (Guo et al. 2012; Pumo et al. 2016). Instead, this paper deals with the operation of the FEWS located in the lower watershed of the Salado River in Midwest Santa Fe Province, Argentina, and a cost-efficient solution to circumvent part of its transmission losses.

The Santa Fe City implemented its early warning network after the catastrophic flood suffered in 2003 (Vionnet et al. 2006). Nevertheless, and among other persistent problems, the network has been hampered by communication problems ever since. As a possible solution to this shortcoming, this work proposes an alternative way to transmit the data captured by the monitoring network without interfering with the proprietary hardware of the functioning FEWS, given the frequent missing of data. Although the implemented solution relies on affordable open source components, it is not similar to the alternative followed by Sadler et al. (2016), who resorted to Arduino platforms to design a low-cost datalogging and transmission system for environmental sensors connected to a network. The solution consists of installing an interface that runs on a minicomputer coupled with a router to transmit the data through WiFi or mobile communications. The interface then accesses the data utilizing an electronic switch that avoids interfering with the satellite communication system embedded in the FEWS.

Thus, and according to Figure 1, the authors strictly restrict the discussion to the communication phase of a working FEWS; the low-cost solution found to circumvent the problem, and the test performed to check if the data packages transmitted by the alternative channel were indeed unaltered.

The aspects that contain the occasional or potential failure of a flood warning system are often minimized. An early and accurate warning is what defines an adequate warning network. In this work, a detailed field survey of more than seven years is presented, involving the direct action of some of its co-authors, who visited the Salado River Flood Warning Network several times, documenting the occasional and specific failures of each monitoring station. The survey is summarized in this paper, providing a clear picture about which item of the network fails most frequently. To the best of the authors' knowledge, there are few detailed statistics spanning seven years that document the failures of a flood warning system.

The survey triggered the need to find a technical solution, once it was detected that communication blockage was the most frequent failure. Therefore, the way to solve the problem of an operational Flood Warning Network, using pieces of hardware of common use combined with free software, is also a novel aspect if one takes into account that it was addressed from the academic, and not from the professional field. However, it is well-known that equipment developed by private industry for environmental applications is usually based on patented technology that manufacturers lock away from the public reach. As a result, the user is soon in a somewhat uncomfortable situation due to the impossibility of introducing changes in the hardware or software that controls the equipment.

In tune with the problems mentioned, one of the main contributions of the present work was the developed software to automatically emulate the manual process that operators generally perform in front of the station when they download data, without interfering with the normal operation of the network. The operator interacts with a graphical user interface (GUI) using images rather than commands executed line by line. The selected library (PyAutoGUI) allowed controlling, through a Python script, the mouse and keyboard to automate the interaction with the proprietary GUI software and thus emulating any desired manual operation. Such methodology was previously tested against several commercial devices such as a Campbell^® station, Steven^® and Spectrum^® soil moisture sensors, and a Genica^® phreatic level sensor and a Pegasus^® station (the earlier three made in the USA, and the former two made in Argentina). The variety of commercial sensors and the scenarios tested make the proposed development easily transferable to other situations with restrictions of similar characteristics (closed software, lack of backup communication system). In this aspect, the solution proposed here is in tune with the work of Sadler et al. (2016).

In summary, the novelty of this work relies on three well-separated aspects; first, a detailed field survey of more than seven years detected that communication blockage of the flood warning system was the most frequent failure of the network. Second, the automatic manipulation of a GUI is a technical contribution that emerged due to the impossibility of accessing the manufacturer's application of each data unit of the network, with an end product that sends the data with incredible fidelity. Last but not least, the testing of the methodology with different devices and environments ensures a trouble-free and transferable product, making it attractive to similar systems or situations.

The remainder of the paper describes the main floods of the Salado River throughout the 20th century to present days, including a brief description of the damage suffered by the two bridges that cross the river since their construction in 1972. Then, the document continues with the method developed to solve the problem mentioned above. It includes a description of the FEWS of the Salado River, and the architecture of the proposed alternative to transmitting the data of the network without using the satellite communication system. The following section presents the results, which are mainly based on the comparison between several data packets sent simultaneously through the satellite and redundant communication systems. The paper ends by discussing the results and the far-reaching implication of the proposed solution. Finally, and to keep text to a minimum, the previous research conducted on commercial devices is summarized in Supplementary material, Appendix A. There, it is possible to find out how the developed interface interacts automatically with the proprietary GUI software of some devices. All developments are freely available to the reader in a web repository.

The design of a FEWS requires the estimation of maximum water levels attained for floods corresponding to given return periods. This information is crucial for the city authorities and people located on the floodplain, along the riverbanks. Nonetheless, it is not the purpose of this work to carry out an exhaustive statistical analysis of the extreme floods of the Salado River. This section offers a brief account of the historical floods of the river, with an overview of the frequency distribution of the water heights. The flood of 2003 caused, for the first time, loss of human life besides severe damage to the public and private infrastructure. The official death toll was 23 (Vionnet et al. 2006). The serious consequences of the flood were the reasons behind the decision that pushed forward the local authorities to establish an early warning system.

The Salado River crosses several provinces of Argentina. It flows for about 1,150 km from the northwest of the country to its central part, near Santa Fe City (Figure 2(a)). The city borders on the west with that river, and to the east with the Paraná alluvial system (Figure 2(b)). Table 1 shows the great floods of the Salado River that affected the city in the last 100 years. The listed floods were generated in the lower watershed of the Salado River (Figure 2(a)). The region comprises a relatively flat area of approximately 30,000 km². This region is located in the mid-west of the Province. In the last 50 years, the basin has undergone modifications in land use, as well as the development of a wide network of drainage channels. Areas with frequent flood risk have been occupied by the population over the years, increasing the vulnerability of the region. Despite these periodic setbacks, the lower river watershed supports a healthy economy that is vital for the region and the country.

The Santa Fe-Rosario Highway (Province of Santa Fe) was inaugurated at the end of 1972. It was necessary to construct two bridges to cross the Salado river, stretching 157 m each in a place where the alluvial valley was 2,000 m wide (Figure 2(b)). At that time, the wetted cross-section was about 500 m² under the bridges. Both structures were destroyed during the 1973 flood. Surveys carried out after the flood revealed that the cross-section had tripled its size, with erosions deeper than 5 m from the initial bed level. The bridges were rebuilt with a pile foundation placed at a much greater depth but still the same span, 157 m. The flood of 2003 again affected the bridges, collapsing one of the abutments (Figure 3(a)). The bridges were rebuilt once again, this time stretching a total of 578 m (Figure 3(b)).

It is possible to infer the statistics of extreme floods of the Salado River by looking at the 1953–2019 daily water level data. The records correspond to the Santo Tomé station by the Salado River outlet at the Paraná alluvial system, and the cross-section SR70, located 25 km upstream (Figure 2(b)). The data set comprises 22,327 readings of the river stage, which were converted to water surface elevation above sea level (the official datum of the Argentine Republic (IGN: www.ign.gob.ar/)). The 67-year long record has missing readings between the years 1988–1992.

Figure 4 shows the histogram of the water level readings at both stations. The histogram describes not only the spread of the data but also the disparate behavior of the water surface elevation at both sites. The hydrology regimes of the Salado and the Paraná rivers are independent. The histogram of the water height at the Santa Tomé station, located nearby the Salado River mouth, is affected by the backwater effects induced by the water surface elevation of the Paraná River. Consequently, it is unable to spot the two peaks of the bi-modal distribution of the SR70 station, which is 25 km upstream. These two peaks correspond to periods of low water, or dry seasons, and medium to high water, or periods of wet seasons. However, the relevance of the Santo Tomé scale to the warning system is crucial. The failure of the protection levee, built to protect people living in lowlands from the periodic flooding of the Salado River, was so dramatic during the 2003 flood that at one point the water was 2.48 m higher within the city than on the riverside, near the location of the Santo Tomé scale (Vionnet et al. 2006).

Finally, the available data set allowed the estimation of the return period of the 2003 flood using traditional two- and three-parameter distributions (Supplementary material, Appendix B).

After the catastrophic flood suffered by the area and the Santa Fe City in 2003 (Vionnet et al. 2006), the Government of the Santa Fe Province called for the implementation of a FEWS, a bid awarded to a joint venture between a Buenos Aires-based company and a firm in charge of the hydro-meteorological measurements nationwide (Tecmes & Evarsa 2006).

The network initially consisted of 41 stations, with only 36 fully operational until now (Figure 2(a)). Among them, 24 measure river stages, nine rainfall and soil moisture, and five rainfall, soil moisture, relative humidity, atmospheric pressure, phreatic levels, solar radiation, evaporation, and wind speed (Contini et al. 2014).

Each station has an outer enclosure which protects an inner cabinet that complies with the IP65 standard (water-dust resistant) and hosts the datalogger with the remote transmission unit (RTU), the wiring of the terminal blocks, the satellite module transmitter and the power system (battery, charger, and voltage regulator). In turn, each unit also has a service port allowing in-situ manual management, so providing access to data already stored in the datalogger with the aid of the proprietary software.

All stations, either fed with solar energy or from the power grid, measure the state-of-charge of their batteries, log the information internally, and whenever there is storage capacity available, upload and transmit the collected data to the final government repository site through the Orbcomm satellites (LEO – low Earth orbit satellites operated by the company Orbcomm, www.orbcomm.com).

Failures in any FEWS are mostly due to flaws in the functioning of sensors and dataloggers, as well as a power outage and transmission losses or environmental factors (e.g. lightning strikes). Vandalism is another source of partial or total failure. However, the incidence of any factor does not always end in complete data loss.

In other to analyze the occurrence of those factors, the FICH at the UNL and the Ministry of Public Works of the Government of Santa Fe Province signed an agreement for surveying the network performance for the period 2008–2013 (Macor et al. 2016). It was possible to totalize 2573 visits, with an average of 11.9 per station per year (Table 2, Contini et al. 2014). The lower number of visits in 2011–2012 was due to insufficient funds to afford the field trips.

During the field campaigns, the FEWS' companies supplier (Tecmes & Evarsa 2006) and the labor inspectors (Macor et al. 2016) agreed to fill out several surveys throughout the elapsed time of the consulting contract, and so they obtained a database organized according to the detected fault of each station:

• sensors: when observing unstable readings or losses of the parametrization settings,

• dataloggers: due to flaws in the proprietary software or connection problems which nullify the data reception,

• power outage: related to missing or broken panels, or to a faulty voltage controller of a battery close to its useful life,

• transmission losses: triggered by missing or broken antennas, a coaxial cable deterioration, or with the Orbcomm system,

• bugs: due to the presence of bees, wasps, ants and nests that could damage the electronic components,

• weather: produced as a result of some extreme weather events (hail, lightning, or high winds), and

• vandalism: damages provoked by antisocial behavior (e.g. gunfire, robbery, or fire).

Table 3 shows the number of failures observed in the years 2008–2013. Figure 5 depicts a stacked frequency histogram, which makes it easier for the quantitative comparison among the contributing factors to failure. The most frequent failure was the transmission losses, with an annual average of 22.6% occurrences. This flaw manifests itself as a delayed reception of the information or the eventual absence of the data package in the final repository site. The frequent repetition of this failure determines the operational vulnerability of the FEWS network, a critical aspect when the watershed is under extreme weather conditions or heavy rainfall (when certain thresholds are exceeded, and the network must activate warning alerts to local authorities).

The second factor affecting the FEWS was the presence of bugs, with an average frequency of 20% followed by the failure of sensors with a mean of 16%. The losses attributed to vandalism were steady and around 10% yearly.

Despite the significant drop in transmission losses observed in 2013 (only 6% of the total, Figure 5), an extension of the consulting study with the Ministry of Public Works allowed the testing of this issue once again for the whole network during 2015. Figure 6 depicts, in solid lines, the continuous transmission of the referenced station, whereas the blanks indicate periods of silence with no link between the station and the Orbcomm satellites. The Orbcomm system is in charge of uploading and forwarding the information to the final repository site. The loss of information due to transmission problems was still there.

Each station of the network acquires the hydro-meteorological data through a current loop working in the range 4–20 mA or 0–4,000 mV of voltage. The readings go in through a channel datalogger and convert to digital within the RTU according to a previously stipulated agenda. Then, a fixed and removable internal memory stores the data. If the measured value is above a preset risk threshold value; it broadcasts an immediate alarm. Otherwise, it is put on hold until the time for its transmission is attained.

The feeding of the Tecmes^® acquisition and recording unit (RTU) depends on the installation site. The two options are: (1) a 12 Vdc battery to 220 Vac with automatic charger; or (2) a 12 Vdc battery with charge controller and solar panel. This unit is responsible for managing the data acquired by sensors, and transferring them to a communication module satellite of the Orbcomm network. The module continues to receive data until it has communication with the satellite.

The data uploaded to the satellite transponder is stored until there is communication with the Earth station in charge of managing the Orbcomm network. At that moment, the information is sent to the servers, and from there, to the data recipients through a directory with the clients' email addresses. Then, an email enters the central station of the FEWS through a specific software that decodes the information, which deploys the value of each remote station on a watershed map.

An interface software which runs on some added hardware was installed on three selected stations of the network to upload the measured data to an Internet server without affecting the pre-established link between the nodes and the repository site.

The expected operations to be executed by the interface were: (i) to set up or modify the working parameters for each installed sensor device and (ii) to upload the recorded data to an Internet server which stores the measurements of the monitoring station.

Towards that aim, the work was broken down into successive stages: (1) conditioning the added hardware, (2) interacting with the proprietary software, (3) automating the download of historical or real-time data and reconfiguring sensors, (4) submitting data to the web through a VPN (virtual private network), and (5) viewing the data on a website.

This interface was used before to drive remotely commercial equipment purchased without the wireless communication module supplied by the manufacturer (López 2012).

The interface works as a multi-platform common datalogger interface with minimal software dependencies. Figure 7(a) depicts the interface architecture layout.

The system has two critical constituents: (1) a host program used for uploading and transferring the data from the station dataloggers; and (2) a server, which receives, stores and finally re-transmits the data originated at each site belonging to the FEWS network.

The interface requires two small devices to run, a SOHO (Small Office/Home Office) router and a general-purpose minicomputer (called MiniPC hereafter), the latter connected by USB or serial wire to the datalogger (Figure 7(a)). Consequently, a bundle of devices was ensemble first with the following features (Figure 7(b)): (1) one MiniPC equipped with a processor INTEL 2.41GHZ J1800 DC, a motherboard AsRock, Memory RAM 4 GB DDR3 1,600 MHz, a solid state disk (SSD) with a capacity of 128 GB, and a Mini-ITX cabinet with a power source of 60 W; (2) one SOHO router with an average power consumption of 0.6 W, equipped with a processor Atheros 400 MHz, Memory RAM 32 MB, 100 Mbps WAN/LAN Port, Wireless standard IEEE 802.11 ngb, and USB 2.0 Port.

It was essential to count with motherboards equipped with: (i) real time clock alarm, which allows the MiniPC to turn on automatically at any preset date and time, and (ii) Wake on LAN (WoL), which allows the MiniPC to be turned on remotely. The configuration of the former functionality is carried out in the power management section of each motherboard BIOS. For that reason, the network cards of the motherboards must support this protocol (this feature must be enabled from the BIOS). Also, it was vital to link the MiniPC to the Internet; a critical step since the proprietary software only works under Microsoft Operating System (OS), previously installed in each MiniPC. The task scheduler was duly programmed to run the developed interface automatically.

Depending on the FEWS station locations, two options were considered as a function of the available power supply: one for those that have access to the grid power and are close to an Internet connection, and the other for the remote which are fed by a photovoltaic system. For the first alternative, an 802.11 wireless network was implemented that connects to the Internet access point existing at the location (Figure 7(a), in black). For the second option, the Internet access was achieved through a mobile phone (3G/GPRS/GSM, Figure 7(a), in red).

The MiniPC was installed at each station, always off albeit with a self-start according to a preset schedule. The router, of low consumption, has dual functionality. On the one hand it provided access to the Internet (WiFi or 3G/GPRS/GSM) while at the same time it offered an environment for a general purpose embedded GNU/Linux for remote access.

As previously indicated, some stations are powered by solar panels. For this reason, a battery of 12 V was attached to connect the MiniPC and the router, and a timer, with a voltage regulator to cut the battery power for the added router, with a window of 30 min for downloading and transmitting the data as a preset scheduled task.

Due to the impossibility of establishing direct communication with the RTU of each station without using the proprietary application, a software was developed to simulate the manual process performed by the network operators. It was crucial to avoid any interference with the proper functioning of the FEWS. The procedure yields an alternative dual route for wireless transmission, either for sending the records to the Internet or for receiving instructions remotely to modify the sensors parameters.

The software acts as an interface between the proprietary application provided by the manufacturer and the actions executed from a configuration file that is updated and modified from the Internet. The different functions that drive the interface resemble a layered architecture where each establishes some degree of communication with the underlying layer, known as a common datalogger interface (CDI) (Figure 8).

The organization of the CDI relied on a single configuration file consisting of subsections, each containing the necessary specifications for each equipment to which the station is connected. For the present situation, the configuration file was adapted to work with a FEWS station. There are several subsections for managing commercial devices of different brands when more than one sensor is connected at the same time. In the current implementation, the interface software runs in Python. Consequently, and depending on the ASCII configuration file, the adopted design invokes one by one the Python module corresponding to each sensor.

Several languages allow manipulating GUI applications, such as PyAutoGUI (http://pyautogui.readthedocs.io) which was finally adopted, and whose purpose is to provide cross-platform Python modules for their automatization. PyAutoGUI offered the best possible interaction with the RTU software. One of the main advantages is that it provides a Python library with an automation environment which, in turn, allows the use of the language's benefits, such as object orientation, easy reading, and writing of configuration files. It simulates movements and mouse clicks, keystrokes combinations and also a search of images on the screen (Figure 8).

The design of the monitoring station posed a difficulty from the start. Whenever an operator connects a laptop to the service port of any station of the network (e.g. in a maintenance visit, Figure 7(b)), it automatically overrides the satellite transmission module. Since the service port of the RTU was the natural choice to plug in the MiniPC to upload the data through the interface, it was necessary to build an electronic switch (on/off) to avoid the permanent overriding of the Orbcomm module (Figure 9).

The switch is energized with a 12 V Molex connector from a motherboard and connected to pin 3 of the parallel port of the MiniPC. Through the operating system, the switch is set in the high state to close the relay and to enable the communication between the MiniPC and the RTU, and in the low state when all tasks end. In this way, the in-situ manual connection and disconnection for downloading data is emulated.

The operation of the implemented system consists of a series of steps, some of which are configurable, ranging from setting the power-on to the automatic shutdown of the MiniPC (Figure 10). Briefly speaking, they amount to the following:

• Self-starting: by using the MiniPC real time clock alarm Protocol (configurable from the BIOS).

• Connection: by using the electronic switch (the software sets in a high state a pin of the parallel port so closing the circuit and thus emulating a manual connection).

• Extraction: by downloading the data stored in the RTU and then by re-configuring the station.

• Disconnection: by setting in a low state the pin of the parallel port so leaving the circuit open and thus emulating a manual disconnection.

• Transmission: by using the Rsync protocol to transmit to an Internet server.

The use of a VPN enables remote access to computers that have a private IP from the Internet. For the current development, the VPN was set up in the MiniPC, which together with the TeamViewer package (www.teamviewer.com/es), allowed the remote access to the stations to perform unscheduled tasks (Figure 7(a)).

Then, and whenever scheduled, the acquired data are uploaded to an Internet server using the remote synchronization protocol Rsync to avoid loss or duplication of data. It uses an algorithm to reduce the amount of data sent over the network, transmitting only the differences between the source files and the destination files (Zhou et al. 1994).

Listing 1: Rsync commands: the first uploads the data to the internet server, and the second downloads the configuration files from the server.

The information then integrates a database for further processing before being transmitted to the final official repository site.

Most web services report according to the concepts of two layers; the front-end layer and the back-end layer which includes all the logic processes in charge of generating the results. The front-end layer is an outlet to portray the notifications produced by the backend. The backend layer uses a GNU/Linux server (www.tektonic.net) that hosts the data processing system consisting of a MySQL database, a Rsync daemon and Apache web server with PHP module and Python.

For the front-end layer, a dynamic website allows end users to obtain the information using customized queries. Furthermore, the raw files are available in a public repository using the original data format of each commercial device.

Once the interface synchronizes each field data, a set of Python scripts parses and stores them in a database. The system relies on the utility pyinotify (https://github.com/seb-m/pyinotify) that automatically executes when it detects any change in any directory. A Python script looks for new data files, and if they are present, the processing starts. It reads line by line getting the timestamp and the hydro-environmental recorded variable to put them all into the designed database.

The proposed alternative communication system sought to link a station of the FEWS network to a nearby stakeholder, or to a rural school having Internet access, otherwise through mobile technology. Consequently, some performance and stability checks were first run at laboratory scale to continue then at the field before moving the equipment to the selected monitoring sites.

An internal test brought by Ubiquiti equipment reaches speeds of about 180.39 Mbps in mixed transfer mode and 148.76 Mbps in one direction, so in the transmission to the terminal devices, the 100 Mbps RJ-45 interface reaches the limit before the maximum WiFi speed. The result showed a state of a permanent link, with no fall or reconnection and with a constant speed over time. Therefore the connection results were satisfactory against a certified WiFi access point 820.11n. Also, since for WiFi dish antennas the communication path must be a line of sight, to prove its duplex capacity a test was made in the laboratory by connecting a satellite dish directly to the rear connector of the router.

The second test consisted of placing the antenna on the first floor of the FICH Department, connected in turn to its Internet network, and putting the TP-Link MR3420 router with an antenna at two distant points (Figure 11). This device was configured to connect automatically at a different point to the signal emitted by the antenna. To verify the connection; the TP-Link MR3420 router was connected to a laptop computer, to which a few sample files were downloaded from a PC linked to the department's local network. Once the communication between the antennas was verified, both were taken to the field to establish the distance of reach between them. With that objective, one of them was held fixed to one side of the road while the other was carried in a vehicle until the signal faded (Figure 11).

In the field, the group also tested other types of WiFi antennas depending on the type of power supply available. Thirteen visits were made to the selected stations along the project, seven to Santa Fe, two to Santo Tomé and four to Flesia (see Figure 2(a) for locations).

The Santa Fe station (Figure 12) feeds from the power grid with AC. On the contrary, the Flesia station, which is on an isolated field site by the Flesia Creek, and the Santo Tomé station located by the Salado River (Figure 13), are fed by batteries powered, in turn, by solar panels without access to the Internet. In these cases, a 3G modem was used instead for the remote connection.

The Santa Fe station is located in the northwest part of the city, on premises owned by the Ministry of Public Works, and it has free access to the Internet. There, an 802.11 wireless link between two Ubiquiti antennas was installed, one of them adjacent to the administrative office and connected via Ethernet to the available network.

The TP-Link MR3020 was configured with OpenWRT (Holt & Huang 2014), which allowed remote access and to power on the MiniPC. Then, the remaining antenna was installed together with the MiniPC in the FEWS station. The Santa Fe station was frequently visited, given its convenient location, to verify the operation of the redundant communication system during the tests.

Both raw and verified data are uploaded and archived within the public server system as comma-separated, ASCII text files. Superusers or administrators can set the configuration parameters for each datalogger, to enable/disable sensors, and to increase/decrease the sampling and the data uploading frequency. The website allows users to access and send their customized queries. Then, users can choose different observation points and types of hydro-environmental variables between dates to download the information, or plot the temporal evolution of the records.

Although the system can preview filtered comma separated values from any formatted file, the relevance of the proposed solution is better appreciated whenever the transmitted data through the Orbcomm and the redundant channel are contrasted one against the other.

All sensors at the Santa Fe station were malfunctioning, except for the temperature sensor (Figure 14). The parity between both registers is visible, with five different and lasting gaps throughout the official record filled correctly by the backup system.

Figure 15 depicts the river stage evolution on the Flesia station over approximately 7 weeks. The data transmitted by the redundant system was one by one with the official record when both channels were on and correctly filled in the gaps left by the Orbcomm system in the three field experiments conducted.

Similarly, Figure 16 displays the outcome of one month of recording of the river stage at the Santo Tomé station; in coincidence with the peak of an ENSO (El Niño-Southern Oscillation) anomaly in the region. In this opportunity, in addition to failures in the Orbcomm system for periods that vary between 1 and 6 days, the RTU failed for about 3 days. The redundant system interrupted its transmission only once during a short period, less than a day on January 4, 2016. The developed interface could recover the data; but just the previous recorded day. Once again, a one-to-one correspondence is appreciated when both communication systems are active, as well as the achievement of the interface to fill in the missing information gaps.

Table 4 summarizes the total number of test days when both systems were working simultaneously, and their failure rates. Surprisingly, the official system exhibits a similar average failure rate (here weighted by observation days) to that detected in the consulting work carried out by FICH (Table 3 and Figure 5), while for the developed interface, the failure rate was lower than 1%.

Without discussing the fact that, in the end, what matters most is the cost of maintenance, it is relevant to emphasize here that the proposed interface is based on affordable hardware parts in some cases and open source components in others. This is in sharp contrast to the costly monthly service imposed by the Orbcomm satellite system, necessary to make data available in real-time.

Each station would require one MiniPC (cabinet, motherboard, and processor), with one solid state disk of 120 Gb, 4 Gb of RAM DDR3, an electronic switch, a waterproof resistance cabinet, a Tp-Link MR3020 router, and a voltage regulator, all totaling €295 approximately (Table 5). The WiFi option will require two Ubiquiti NanoStation M5 antennas, two Ubiquiti Loco M5 antennas, and several meters of outdoor UTP cable CatE (about 15 m), all adding up to approximately €186 (Table 6). On the contrary, the 3G alternative will demand a 3G Modem Huawei, one timer, USB cable (around 5 m or so), and a 12 V battery, totaling approximately €53. The latter will add up to €168 of the annual mobile or cellular service charge, totaling €220 approximately (Table 7).

In summary, in round figures, the alternatives successfully tested in the current configuration correspond to an initial investment that could add, per station, up to €480 for the WiFi alternative, or up to €516 for the 3G option. In the latter case, the annual cost of the cellular telephone service provider was included. These figures should be compared with the annual expenditure of €13,000 for having the Orbcomm system in operation, a system that fails, on average, 20% of the time.

The redundant communication system could be located in four or five key stations to have a reliable backup system whenever necessary.

The test period of the three stations together does not span more than three months. It is a very short period to obtain conclusions or reliable data on inherent system failures that would require the replacement of some or all of its components. However, based on previous and ongoing work carried out by the research group, which was the basis for the software development later transferred to the FEWS of the Salado River, it was possible to extract the following failure frequency of low-cost devices used in outdoor environments:

1. Ten months of data collection in the agro-technical school of Santo Domingo (Figure 2(a)), operating phreatic level, soil moisture and temperature sensors (https://www.specmeters.com, www.genica.com.ar/).

2. Seventeen months of observation with heat, water vapor, and carbon-dioxide flux sensors (Campbell eddy covariance (www.campbellsci.com)).

3. Three years of water level collection (acoustic sensor device (www.maxbotix.com/)).

4. Five years of observation of hydro-meteorological data with a Pegasus station (www.tecmes.com/wpcontent/uploads/2014/12/Folleto-PEGASUS-2010-VIGENTE.pdf; http://fich.unl.edu.ar/cim/).

Overall, the operation of the experiments detailed in the above list just served to provide a glimpse of the occasional failure of the low-cost components used in different outdoor settings, either by natural causes or by inherent faults (Table 8). The weighted average of the values shown in Table 8 yields a yearly maintenance cost for the low-cost system on the order of €104 (Table 9). The observed failures were always attributed to an electrical fault, which constitutes the Achilles' heel of low-cost systems.

Before applying the interface to the FEWS problem, all field experiments detailed in Table 8 served to test the development of the software with different devices and environments to ensure a portable and trouble-free product. In Supplementary material, Appendix A, the reader will find a block diagram explaining how the interface works, and a repository address with the Python scripts where all the examples are readily available.

With the weighted average cost to replace damaged components for the low-cost system, plus the cost of communication (Table 7), it is possible to set up the following comparison between both systems on an annual basis (Table 9).

These numbers should be taken with caution since there are always hidden costs, expenses not contemplated, or changes in technology that can push the figures 20–25% above or below the initial estimate. Nevertheless, the low-cost system is, on average, eight times cheaper to maintain than the equipment of the official network.

Finally, the backup system was transferred to the local authorities of the Province of Santa Fe at the end of 2015. A technical talk was given to the technicians and the authorities in charge of the alternative network (https://www.santafe.gov.ar/noticias/noticia/220436/). The system was easy to operate since, among other things, it relied on a dynamic website to visualize the data downloaded and transmitted through the redundant system. Unfortunately, immediately after transferring the product, there was election time in the Province, and new authorities took over the State, freezing the collaborative effort for a while. Nowadays, there is a renewed interest by the state authorities after the devaluation of the Argentinian currency, given the high cost to replace damaged components and the obsolescence of the official network.

The flood early warning system (FEWS) of the lower-catchment of the Salado River, Argentina, was set after the catastrophic flood suffered by the Santa Fe City, in 2003. A quick flood frequency analysis estimated the return period of the flood as around 130 years. However, the frequent loss of information due to communication problems in the final repository site of the FEWS has affected the network operational vulnerability ever since.

This paper proposes a solution based on a developed interface to transmit the data in parallel, previously captured by the monitoring network, through a dual channel that uses an electronic bypass without interfering with the original satellite communication system employed by the FEWS.

Several laboratory-scale trials were performed first to test the feasibility of the interface to transmit the data stored by the proposed redundant communication system. Three field experiments later complemented these tests carried out at laboratory scale. During the testing phase, the official communication system exhibited an average failure rate of the order of 20% compared to the developed interface, which was less than 1%. In all cases, the results had shown not only the consistency of the information transmitted by satellite and the proposed alternative, when both were active, but also the achievement of the latter to fill in the information gaps when the official system experienced a ‘blackout’ for some reason.

The automatic manipulation of a GUI was a technical contribution that emerged due to the impossibility of accessing the manufacturer's application of each data unit of the network, with an end product that sends the data with incredible fidelity. Moreover, the testing of the methodology with different commercial devices and environments ensures a trouble-free, portable product, making it attractive to any FEWS with similar characteristics. The software was designed to add support to other commercial devices. All software of the developed interface was uploaded to a public site, where the readers can study the source code, modify it, and use it the way they want.

The interface relies on low-cost, single open source board computers and routers that eventually reduce the maintenance cost of the satellite-based FEWS system significantly. This aspect of the proposed solution, in turn, can increase the reliability of any FEWS with similar characteristics.

Support from the National Council for Scientific and Technical Research (CONICET), research grant no. 112-201100100384, and from the Universidad Nacional del Litoral, research grant CAID 279/013-I + D 1-11, are greatly acknowledged. Thanks are also given to Senior Eng. Ricardo Giacosa and other authorities of the Ministry of Public Works of the Province of Santa Fe for their financial assistance and encouragement during the execution of this project. The authors also thank three anonymous reviewers for their useful criticisms and comments that helped to improve the first version of the manuscript.

The Supplementary Material for this paper is available online at https://dx.doi.org/10.2166/hydro.2020.216.