Measuring water levels using LoRa – a kick off

Elke DECLERCQ1, Kim DE BEULE1, Leen DE VOS1

1FlemishGovernment – Geotechnics Division, Ghent, Belgium
Corresponding author: Elke Declercq ([email protected])

Abstract
Water levels and water pressures are essential for almost every geotechnical design. They are often also a driving
force behind difficulties encountered during construction or during the life cycle of a construction.
Although continuous in-situ logging with conventional unconnected water level loggers provides some
information, a site visit is required to collect the necessary data. For projects that do not require real-time follow-
up, visualising data on an internet platform has the advantage that these data can be consulted at any time from
distance.
The last few years LoRa (Long Range) has popped up in the IoT (Internet of Things) world and became more and
more widely used. With LoRa ranges up to several kilometres are possible with the advantage that it has a low
power consumption and the disadvantage that you can only send a small bundle of data. For water level
measurements the latter is not a problem as it only requires sending out a small bundle of data.
With that in mind a couple of projects were setup with several LoRa water level loggers. They were tested
thoroughly and were compared with conventional water level loggers. In this paper our initial experiences with
the LoRa loggers are shared.
Keywords: LoRa, water level monitoring, real time

1. Introduction
Good and reliable data are important for a good analysis and interpretation of site conditions. Water levels or
water pressure can be a driving force in structural behaviour and have a big influence on construction conditions.
It is therefore often aspired to have (nearly) real-time measurements.
At the Geotechnics Division of the Flemish Government, we encountered the following challenges for such real-
time measurements: most systems require a sim card for every measuring point, modems use a lot of power,
the cost of each measuring point increases as extra hardware is required, some techniques require monthly fees,
in case of difficulties it is hard to find the bottleneck, each brand has its own visualisation platform, … The main
disadvantage of using multiple brands is that they have their own platform. This moreover complicates the
maintenance of all these platforms. The latter often forces one to stick with one brand.
From the different alternatives that were installed, the most promising systems use a type of Long Range, low-
power, data transmission with a protective shell. In order to better control the flow of the measurements and
enable using generic visualisations platforms, it is important to get rid of the shell and only use the things
needed. The preferred system should also be flexible in the type of sensors that can be used so relations between
results can be established.
When measuring water levels or water pressures within an open standpipe, a standpipe protection is highly
recommended. The standpipe protection however often blocks or attenuates the signal for data exchange. A
good balance between a physical protection and a limited disturbance of the data signal hence had to be found.

2. How to get real-time water level data without an expensive setup

2.1 LoRaWan architecture
Most low power platforms create a star setup where the measuring points, so called nodes, send their data to a
central point, the gateway. This central point or gateway collects the data and is connected to the internet. This
implies that only one sim card or internet access point and one location with a solar panel or power grid supply
is needed.

1
After prospection, most platforms seemed to be part of IoT (Internet of Things). One of the IoT communication
protocols is LoRa(WAN) in combination with The Things Network. Different from many other systems is that the
node has no dedicated receiver or gateway. Each node sends data and every gateway that “hears” the signal,
picks it up and sends it to a network server, The Things Stack from The Things Network, as shown in Figure 1.

Figure 1: LoRa Network Architecture. (https://www.3glteinfo.com/lora/lora-architecture/)

The distance between node and gateway can go up to several kilometres depending on the line of sight. An
additional advantage is that anyone can use any Gateway of The Things Network (TTN). When insufficient
gateways are available, one can install an extra gateway and add this to TTN. Although it is easy and cheap to
use existing gateways, it is good practice to also invest in an own gateway to enlarge the network and increase
reliability and redundancy.
2.2 Hardware: sensors and nodes
An established brand was selected for the sensors and nodes. The advantage of an established brand is that it
has a big knowledge database (available online). Different sensors with different accuracy can be chosen based
on the requirements for the site conditions. Typically the sensors are used with the user-friendly Kolibri interface
for data visualization to program the sensors, but this interface is not essential. The communication between
sensor and node is RS485. The architecture is well documented and software sample code is available for
integration into the company’s own application.
The tested node is available in two different versions: box or tube (see Figure 2). The tube can be installed in the
top of the standpipe, while the box can be fixed to a pole or installed in a protective standpipe cover. It is
advantageous to install the node as high as possible, as this improves communication between node and
gateway.

Figure 2: left: Keller tube and Keller box. Right: Pressure sensor attached to the tube. (www.keller-druck.com)

2
Although we acknowledge that it might be an advantage to be independent of a specific brand as it allows one
to customize the hardware parts, this has not been tested.
2.3 Hardware: gateway
There are many brands and types of gateways. Several requirements determine the choice of gateway type.
First, one has to decide to go for an indoor or an outdoor version. An outdoor gateway is recommended as this
extends the range of the gateway to an important extent. Second, one needs to decide if the data will be sent
over UTP or LTE (fixed internet or sim card). A wired internet connection leads to a more reliable connection. If
unavailable, LTE can be used instead. Finally, the frequency range used by the gateway and node needs to be
compatible with frequency range of the area where you want to measure. In the EU for example, the frequency
range is 867-869MHz.
The higher the gateway is installed, the better. Potentially an existing antenna pole can be used, see for example
Figure 3.

Figure 3: left: Gateway installed to an existing antenna pole – right: Installed gateway
As mentioned before, it is good practice to install your own gateway. If it is however preferred to use existing
ones, there are some simple instruments to check if there is a gateway in the proximity. An example of such an
instrument is Adeunis FTD (Field Test Device). Software is available to check where there is coverage and which
gateway is used as shown in in Figure 4. One can take an FTD on a trip and quickly gain knowledge on field
coverage.

Figure 4: Example of a trip in Antwerp with an FTD, marked are the connection lines to each available gateway

3
2.4 Hardware: protection
As the position of the pressure sensor is crucial to get accurate data, it is important to protect the open standpipe
from damage. Often, stainless steel protections are used, but steel impairs the signal. We hence recommend to
use a synthetic protection cover to less disturb the signal from node to gateway. In Figure 5 such an example
protection cover is shown.

Figure 5: Example of a high visible and lockable protection cover in HDPE. (www.boode.com)
2.5 Software: the hardware
This might sound evident, but every hardware has to be connected to The Things Network. This is an easy but
important step to take. This way The Things Network knows which data belongs to which sensor and to whom.
The Things Network has two main parts: the applications and the gateways as shown in Figure 6.

Figure 6: Main screen after logging in into the things network

By adding the specific dev EUI (Device Extended Unique Identifier) of each sensor to your list of devices, assigned
to an application in the Things Network, the Things Network knows how to connect the received data to the
correct database. If you have a gateway you have to add the gateway EUI too.
2.6 Software: the interface
It is very useful to have just one platform that takes care of calculating and processing, validating and
visualisation of the data. Such centralised system allows to compare data, plot water pressure versus tidal
measurements, versus rain, versus displacement and so on. Both Keller and The Things Stack from The Things
Network are well documented open source platforms. The programmers of our visualisation software were
asked if they could assimilate the IoT data. In a manner of speaking they could just implement the program code
found in the TTN community and the hardware knowledge database.
The nodes communicate with the gateway through the LoRaWan protocol. The gateway communicates with The
Things Stack through MQTT (Message Queuing Telemetry Transport, a standardized protocol of OASIS) protocol
as illustrated in Figure 7.

4
 Figure 7: LoRaWan versus MQTT
Also by the MQTT the data is extracted from The Things Stack into the visualisation platform. The raw data is
stored in the database of the visualisation platform after which calculations are performed. So both raw and
calculated data are stored. This allows to trace back the raw values and recalculate if necessary.

3. Test phase
3.1 Case study 1 - Antwerp
The first test case was located in the city of Antwerp nearby the river Scheldt. To keep the threshold as low as
possible, a sensor was hired and installed in the same standpipe as a traditional water pressure sensor. For this
first case study, we used existing gateways. The results of both the measurements with the traditional water
pressure sensor and with the pressure sensor connected via LoRa are shown in Figure 8. The difference between
the two measurements is about 1cm which is probably due to a small difference in position of the sensor and
within the accuracy limits which were aspired.

Figure 8: Water level measured with a traditional water pressure sensor (blue) and with a pressure sensor
connected via LoRa (yellow)
3.2 Case study 2 - Lier
The second test case was located in Lier. For this project, several open standpipes were installed in private
gardens. To limit the number of visits to the private properties, LoRa sensors were installed. This does not only
limit the amount of site visits, but also the time required for manual control measurements. Measurements in
the open standpipe were made by an external company for a few years. Both the old, conventional sensors and
the LoRa sensors have been measuring in the same standpipe for about four months. Old data and new data
were plotted together and compared. Additionally, manual measurement were carried out and considered in
the comparison. The results were satisfising as can be seen in Figure 9.

5
 Figure 9: Comparison with the old sensors (prefix _IMDC are the old ones)
But as to everything, there are upsides and downsides. From time to time there was a data gap, mainly for short
periods (one or two measuring points). Although this was not a hindrance for the case study projects, it would
be reassuring to understand the cause. The inconsistency can be seen in Figure 10. It is not yet clear which is
causing these gaps and how can this can be avoided. The gaps probably are due to the fact that the node did not
manage to transfer the data to the gateway (the signal could not be sent, or not be picked up by a gateway). A
very limited amount of data is stored in the sensor, but retrieving it cancels out one of the main advantages of
the system, which is to limit the amount of site visits required. As can be seen in Figure 10, these gaps occur
quite frequently, and are mostly not at the same time for each sensor, even though they are most likely using
the same Gateway.
Furthermore, the time stamp of the measurement varies slightly in time, resulting in a small difference in the
measurement frequency (seconds). It is quite unclear if this is due to the measurement or to the sending of the
data.

Figure 10: Illustration of the data gaps of the LoRa sensors.

6
4. Data validation and completeness
There are different checks performed to ensure our data are accurate:
- The water level is measured manually upon every site visit and compared with the automated
measurements. The manual value is added to the same graph as shown in Figures 8 and 9: the small
crosses indicate the manual measurements.
- The water pressure is calculated from the total pressure (water and atmospheric pressure) measured
in the sensor and the atmospheric pressure in each node. It is also possible to import only the calculated
value, but this leaves you with limited control when something goes wrong. For instance in one node,
moisture entered into the hardware and the atmospheric pressure got faulty. Because both, total
pressure and atmospheric pressure, are imported to accurately calculate the water level, the data could
be corrected by compensating them with a good atmospheric pressure sensor from another node.
- A comparison was made between all the atmospheric pressures from different sensors in the same area
to check if they measure correctly and consistently.
- Together with the pressure, a vast amount of metadata are added by TTN. Finding out which data give
important info about the data quality and which metadata are irrelevant, helps to limit the amount of
data which are important in the database.
- When data transmission is interrupted (e.g. a sensor is broken or stolen) this can be noticed almost
immediately when putting an alarm (through the software platform) on the consistency of the
measuring interval.
- If, for some reason, the data are not sent anymore, a node can store up to 28.000 data values. With an
interval of 15 minutes this is just more than 290 days, which allows for sufficient time to go on site to
download the data (unless the node is damaged or stolen). It is hence recommended to check on site
as soon as possible when data are not being retrieved any longer.

5. Challenges
As we only started the implementation about a year ago, there are still open questions and improvements to be
made. Following will be focussed on during the next projects:
- Try to improve the data density (avoiding gaps);
- Understand why timesteps vary slightly between measurements;
- A high amount of metadata are sent along with each measurement. Their added value is not yet clear.
- Search for good protections when installing open standpipes flush with ground level. To what extent
does this type of installation (below the ground level) have an impact on the signal quality?;
- How many gateways are required to get a reliable coverage?;
- How to install and fix the sensor at a random depth in a secure and yet handy way?.

6. Conclusions
The LoRa technique is a very accessible way to measure in real time. Measuring in real time has a lot of
advantages both for the consistency of data and the accessibility of data. If a strange behaviour is noticed in a
construction nearby, the data is directly available. On the other hand if something goes wrong with the sensor,
this is noticed almost immediately. One can hence intervene rapidly and resolve the issue quickly to restore the
dataflow.

Acknowledgements
We sincerely thank Elneo, Keller and Vision42 for helping us with the implementation. We would also like to
thank Bart De Lathouwer for reviewing this paper.

References
https://www.thethingsnetwork.org/docs/lorawan/what-is-lorawan/
https://keller-druck.com/en/products/wireless-solutions

7
https://lora-alliance.org/about-lorawan/
https://www.3glteinfo.com/lora/lora-architecture/
Jos Goossen Waterschap Scheldestromen (NL) (2021) LORA IOT Multiflexmeter GW_2021_04_06.pdf
https://lora.readthedocs.io/en/latest/
www.boode.com
Haxhibeqiri, J., De Poorter, E., Moerman, I. & Hoebeke, J. (2018) A Survey of LoRaWAN for IoT: From Technology
to Application. https://www.mdpi.com/1424-8220/18/11/3995