---
title: "Remote Monitor and Control System Based on SigFox IoT Network"
url: "https://maker.wiznet.io/WIZnet/projects/remote-monitor-and-control-system-based-on-sigfox-iot-network/"
markdown_url: "https://maker.wiznet.io/WIZnet/projects/remote-monitor-and-control-system-based-on-sigfox-iot-network/md"
type: "UCC: User Created Content"
author: "Lorenzo Francesco Livi and Jacopo Catani"
author_url: "https://arxiv.org/pdf/2110.15208.pdf"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "Lorenzo Francesco Livi and Jacopo Catani"
original_url: "https://arxiv.org/pdf/2110.15208.pdf"
published: "2023-02-13"
language: "en"
hardware: ["WIZnet W5500 Ethernet Shield"]
likes: 4
views: 393
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# Remote Monitor and Control System Based on SigFox IoT Network

> a new, low-cost system designed to provide multi-sensor remote condition monitoring of modern scientific laboratories, as well as to allow

Original author: Lorenzo Francesco Livi and Jacopo Catani (source: https://arxiv.org/pdf/2110.15208.pdf)

## Components

- **WIZnet W5500 Ethernet Shield** x 1

## Article

We describe a new, low-cost system designed to provide multi-sensor remote condition monitoring of modern scientific
laboratories, as well as to allow users to perform actions from remote locations in case of detection of specified events.
The system is battery operated and does not require the presence of a Local Area Network (LAN) or WiFi (which are
typically not available in case of, e.g. power losses), as it exploits the growing infrastructure of Internet of Things (IoT)
Low Power Wide Area Networks (LPWAN). In particular our system exploits the new SigFox ultra-narrow-bandwidth
(UNB) infrastructure, and provides for a bidirectional link between the instrumentation and the remote user even in
case of power line outages, which are among the most critical situations that a scientific laboratory can withstand.
The system can detect the occurrence of predefined events in very short times, and either autonomously react with a
series of predefined actions, also allowing a remote user to timely perform additional actions on the system through an
user-friendly smartphone application or via a browser interface. The system also embeds a novel power-loss detection
architecture, which detects power line failures in less than 2 ms. We provide a full characterization of the prototype,
including reaction times, connection latencies, sensors sensitivity, and power consumption.

I. INTRODUCTION
Modern research laboratories, often involving delicate and
sensitive instrumentation, are more and more highlighting the
need for reliable remote condition monitoring and control
capabilities1
. Similar demands are also characterizing the design of modern industrial plants2
, where the complexity of
production processes poses the needs for optimized predictive
maintenance routines to be achieved through the implementation of pervasive sensor networks3
. Whilst in the industrial
domain the main target of this deployment is the implementation of condition-based predictive maintenance routines with
cost-effective sensors networks, in the case of scientific laboratories the aim of remote monitoring is to maintain the best
experimental conditions to perform the most accurate measurement set, e.g., through stable environmental and/or instrumentation conditions. Another essential point concerns
the prevention of catastrophic failures of sensitive equipment
(such as ovens, lasers, Ultra-high-vacuum (UHV) vessels and
pumping stages) which can happen as a consequence of an
unexpected critical event, such as, e.g, AC power line blackouts and/or power, compressed air, vacuum line or technical
gas supply failures.
Recently, development of complex remote sensing and
monitoring systems has gained huge thrust from several sectors worldwide, due to the growing attention given to implementation pervasive sensing platforms, aimed at monitoring
of a large number of endpoints with minimal cost.

In this scenario, Wireless Sensor Networks (WSNs) are an emerging
platform consisting of small-size, low-cost sensors with low
energy requirements, that are used to sense, track measure,
observe, and monitor mainly environmental phenomena, such
as temperature, pressure, humidity, pollution, winds and send
data wirelessly for processing.

Among the 5G-compliant
platforms which featured a rapid growth in the last years, the
most prominent implementations of Low Power Wide Area
Networks (LPWAN) are represented by Low-Power LongRange Wide Area Networks (LoRaWAN), Narrow-Band IoT
(NB-IoT), Long-Term Evolution for Machines (LTE-M), and
SigFox6,7. However, the possibilities offered by such fastgrowing low-power IoT network architectures could also be
exploited in an extent wider than the pristine environmental
monitoring, to provide, e.g., a constant condition monitoring
of scientific and industrial infrastructures not leveraging on
local area networks, such as LAN and/or WiFi. This feature
is essential in order to provide connectivity redundancy, as the
latter are typically failing in case of power outages involving
the building where laboratory and/or industrial equipment are
located. This critical condition can put the apparatuses in an
isolation condition, where no monitoring and/or control are
possible even if local Uninterruptible Power Supplies (UPS)
are present in lab, so that no proper countermeasures can be
taken by remote users. Most of the LPWAN implementations
mentioned above also offer a bidirectional link, which is particularly important as it allows remote users to have a certain degree of control on the monitored equipment. This is
particularly relevant when human decisions could be required
in addition to automated actions, as it could happen during
the occurrence of critical events. Moreover, in the particular case of scientific apparatuses or protected environments,
where the electromagnetically-induced (EMI) noise can hamper the results of precision measurements, the possibility to
exploit LPWANs avoids the need for GSM/GPRS connection
modules. This is an essential advance as these standards typically involve large EMI noise to be irradiated in the environment during transmission of data8,9. Furthermore, the latter are not meeting the low energy requirements of most recent IoT networks10, and battery operation can be an issue
when long operation times are required. Here, we implement
and fully characterize a new multi-sensor platform for remote monitor and control of scientific, industrial apparatuses,
based on the SigFox network (see Fig. 1), which has recently
been deployed and represents one of the most promising LPWAN implementations for the development of pervasive sensing and actuation networks (see Sec. II). Despite alternative
IoT solutions currently available on the market (in particular LoRaWAN and NB-IoT) offer similar or even slightly better performance in terms of data rate and payload size, SigFox has been preferred over its direct competitors because of its excellent network coverage over the national territory
and the availability of an Arduino board already equipped
with a SigFox connectivity module, simplifying the implementation of the integrated remote sensing and control platform at both the software and hardware levels. Differently
from previous realizations11, our system provides a bidirectional wireless communication channel between remote users
and the equipment under control, and features a highly versatile sensing architecture, based on low-cost, expandable set of
I2C and 1-wire sensors, allowing for continuous monitoring
of several parameters (temperature, pressure, humidity etc.).
We also provide 4 general digital I/O ports, whose status can
be changed by remote commands delivered through the SigFox network, allowing users to perform remote actions on the
apparatus. The system also embeds a novel, low-cost AC line
status and quality monitor, providing fast reaction capabilities
(< 3 ms) to sudden variations of the AC line status. The system, which could run in battery mode for more than 12 hours
in our test campaign, performed inside a real scientific laboratory, could find applications in many sectors, ranging from
remote condition monitoring of scientific research apparatuses
and industrial plants, to on-field environmental and pollution
monitoring.

![](https://maker.wiznet.io/uploads/2021/11/sigfox1.png)

II. THE SIGFOX NETWORK
SigFox network12 is designed to provide a good coverage for either indoor and outdoor bi-directional long-range
communications with low-powered, low-cost IoT devices.
Long range and noise-resistant communication capability is
achieved by means of a ultra-narrow band (UNB) transmission protocol which employs a strongly reduced transferring
data rate (100 to 600 bps) to exchange 100 Hz wide messages
over a narrow spectral sector (868 to 868.2 MHz in Europe)
of the publicly available band. Transmissions are always initiated by the remote device which remains in idle state for most
of the time ensuring a high energy efficiency. Differently from
other network architectures, this transmission scheme implies
that communications between the devices and the base stations rely on a asynchronous exchange of messages. In particular, devices are not connected to a specific base station and
each broadcast message is replicated three times over three
different random frequencies and received by all the nearby
stations. Due to the long transmission times, the UNB protocol employed makes it prohibitive to transmit large amount of
data with battery powered devices so that a maximum of 12
bytes (8 bytes) payload size is allowed for uplink (downlink)
messages. In addition to this constraint, governmental restrictions to the usage of the publicly available band limit the maximum number of daily message to 140 per device. The base
3
stations receiving the device messages represent the first layer
of the SigFox network architecture. The second other layer is
constituted by the SigFox Support system, which is in charge
of processing of the received messages, their storage and final
deployment. SigFox users can access message data exploiting
a web interface or setting a callback to redirect the payload to
a custom service and push an eventual downlink message to
the IoT device. SigFox network is administered by a single
national operator, providing a clear map of the network coverage, and does not require end-users to install and configure
gateway units. Noticeably, the SigFox platform also features
several collaborations with private partners (e.g. Arduino and
Google)13,14, and is expected to play a major role in the largescale deployment of pervasive WSNs and IoT services in the
next few years.

III. SYSTEM DESCRIPTION
The system architecture is based on a Arduino MKR FOX
1200 microcontroller board, which is natively equipped with
a SigFox connectivity module for bidirectional communications. The device connectivity also includes the standard set
of I/O interfaces typical of the Arduino MKR series that comprises 7 analog inputs, 8 digital I/O, 1 DAC, a I2C and a SPI
communication bus13. SigFox operations are enabled by an
antenna tuned on the European ISM (Industrial, Scientific and
Medical) frequency of 868 MHz and accommodated inside
the plastic box enclosing the board. Communications with
the SigFox backend are characterized by an average Signalto-Noise Ratio (SNR) between 10 and 24 dB and a RSSI
(Received Signal Strength Indicator) between -101 and -131
dBm. Those values are measured with the board operating in
indoor environments, where walls and concrete structures typically lower the RSSI by orders of magnitude with respect to
outdoor configurations.

As shown in Fig. 1b, where a modular scheme of the platform is provided, in addition to the MKR FOX 1200 microcontroller the board also includes an Arduino MKR ETH
shield equipped with a Wiznet w5500 Ethernet controller
chip. Due to the small payload size and limited number of
messages daily allowed by the SigFox network, the system
also embeds the possibility to exploit a wired Local Area Network (LAN) connection in order to share real time sensor data
with remote users, leaving the SigFox connectivity available
only for emergency or on-field conditions. Along with the
w5500, the shield also hosts an SD card module that we employed to store sensor information and pre-loaded configuration parameters. Both the devices, the w5500 and the SD
module are interfaced to the Arduino exploiting the same SPI bus.

In order to support versatile remote monitor applications,
the board provides two general purpose I2C and 1-Wire buses
which allow for several low-cost and low-power typologies
of digital sensors for which Arduino libraries already exist
to be connected simultaneously in “star” or “daisy chain” arrangement with a minimal effort for the end-users. In addition to the extended assortment of commercial sensors available, the strength of the two buses consists in the minimal
amount of wires needed to control the connected devices. Indeed, only two wires and one wire (excluding the power connections) are employed by the I2C and (as the name suggests) 1-Wire buses, respectively. Being at most necessary
four wires (two for communication, one for ground reference
and one for the power supply) to control the sensors, we decided to use 4-poles telephonic cables and RJ11 6P4C connectors to assembly the sensor network, as this standard allows to
build complex arrangements exploiting inexpensive components and cable splitters. I2C bus is directly connected to the
dedicated pins on the Arduino microcontroller and supports
3.3 V sensors like the 16-bit ADC ADS1115 that we successfully tested. 1-Wire bus, instead, has been designed to work in
normal power mode with a 3.3V dedicated supply line as this
modality assures a better stability. Among the thermometryrelated probes exploiting the 1-Wire technology, we successfully tested the Maxim DS18B20 temperature sensor and the
Adafruit MAX31855 K-type thermocouple amplifier.
In order to expand the monitor and control capabilities of
our system, the set of I/O connections available on the board
also includes four 12-bit ADC and four general purpose digital
I/O, both directly provided by the Arduino MKR FOX 1200
board. The digital I/Os could be either set as input or output
terminals. As explained later in the text, the latter case is particularly relevant as it provides a remote user with the possibility to control an experimental apparatus or general equipment,
through either the SigFox or LAN network. As the Arduino
board uses a 3.3V supply, the digital I/O ports are provided
with a 3.3V to 5V bidirectional level shifter in order to be
compliant with the 5V TTL logic, widely used in both industry and laboratory settings.
The board is normally powered via an Universal Serial Bus
(USB) connector, while a battery power supply has been included in order to ensure monitoring and connectivity functions even in case of blackout/failure of mains AC power line.
The battery module features an inexpensive TP4056 USB
single-cell Li-Ion charger and a MOSFET-based circuitry to
automatically switch between USB and battery supply in the
case of a power outage. Finally, a 3.3V low-dropout (LDO)
regulator is used to deliver a constant voltage to the Arduino
board and all the other subsystems, with the only exception
being the SD-Ethernet shield and a I2C system status display
for which 5V supply is provided by means of a XL6009 DCDC step-up converter. The power supply unit also provides
the supply for the external sensors connected to the board.
As shown in Table I, the board power consumption (excluding the external sensors) strongly depends on the functioning condition, spanning from 125 mA during normal monitoring operation, and reaching a maximum of 150 mA during SigFox transmission. Power saving strategies are adopted
in emergency condition, when, e.g, 56 mA can be saved by
commanding the Wiznet Ethernet chip to enter in power down
mode in the case the board is running on battery and the internet connection is unavailable. As energy consumption is
one of the most challenging issues in WSN systems, additional power saving actions, e.g. the deactivation of the board
display, makes it possible to sustain battery-powered board.

Current consumption
Normal operating conditions 125 mA
Arduino MKRFOX 1200 32 mA
Ethernet shield 56 mA
SigFox downlink 20 mA
SigFox uplink 30 mA
TABLE (I) Board components current consumption.

The normal operating conditions refer to the board battery
powered, the Ethernet shield on and no sensor connected.
Additional power is needed for SigFox communication
during uplink and downlink, respectively.
activities for several hours without recharging, allowing for
extended outdoor operations. As an example, up to one day of
full operation in emergency/outdoor conditions is attainable
before complete discharge with the 2600 mAh single-cell LiPo battery that we embed in the board.

IV. SENSOR INITIALIZATION AND DATA ACQUISITION
As discussed before, the board can handle a nonpredetermined number of different sensors whose settings are
defined via a remote application. Each sensor connected to
the board is identified by a series of properties that define its
ID, model, physical address, operating and alarm ranges and
conversion factors. This information is stored in a dedicated
online database table which is updated exploiting the Android
application, without the need for the end-user to change the
Arduino firmware in order to modify the sensor properties, or
add/remove sensors. There is no theoretical limit to the number of sensors that can be connected to the board, with the
only exceptions of the Arduino flash memory required to store
their information, and of the length of the cables connecting
the sensor network to the board. For both the 1-wire and I2C
buses, maximum cable length strongly depends on the sensor
network arrangement, number of sensors and maximum distance of the sensors from the board and spans from tens of
centimeters in the case of I2C bus, up to tens of meters in the
case of 1-wire connections15.

As the number and properties of sensors are not hard-coded
in the Arduino script but determined by the end-user via the
Android application and stored online, two different procedures are exploited to initialize the board depending on the
board operating condition. In normal operating conditions
sensors settings are downloaded from the database table immediately after the board has been powered on and a copy
is stored on the board SD card. In emergency/outdoor conditions, where the Ethernet connection is not available, the
stored copy is employed during board initialization, so that no
download from the SigFox network is needed.
Once sensors are properly initialized, their read values are
cyclically acquired and stored for sharing. The time between
two subsequent readings of the same sensor is mainly limited
by the long conversion time typical of the 1-Wire temperature
sensors. The reading time depends on the chosen resolution
of the 1-Wire sensor, which could be digitally set. Reading
sequence times span from 94 ms at 9 bit resolution, up to 750
ms at 12 bit. This is not a particular issue as long as the board
is exploited to monitor environmental variables or signals that
are supposed to change on a timescale longer than the conversion time, e.g., ambient temperatures, pressures, humidity, or
CW laser diodes output powers, pressure values in a vacuum
vessels, or the polarization values out of a thermally-stressed
single mode optical fiber. As an example of such a monitoring activity, Fig. 2a reports the log of a DS18B20 temperature
sensor during a simulated blackout and subsequent failure of
both Ethernet connection and mains power supply, showing
the capability of the board to support communication in emergency conditions with both USB and battery power. Sensor
data have been acquired at full resolution (which gives us a
quantization level of 0.0625 °C) and setting a waiting time of
1.5 s between two acquisitions. The simultaneous log of the
AC power line RMS value measured by the board dedicated
ADC is reported in figure 2b, with the gray shadowed area evidencing the time interval during which battery powering has
been employed in response to the blackout event.

V. AC POWER LINE MONITOR AND FAST POWER
LOSS DETECTION
Particular effort has been put to equip our system with a
reliable sensor for AC power line monitoring and fast power
outages / instabilities detection. AC power line monitoring
constitutes a noticeable exception to the standard sensing and
condition monitor scheme described above as, despite a fewms power loss can be detrimental for laboratory instrumentation as well as for industrial equipment, this critical event
would not be detected by our 1.5 s−1 maximum sensor reading
rate. To this scope, as it is shown in Fig. 3, the implemented
sensing stage exploits an AC-AC converter to reduce the 240
VRMS of the main line to a safe lower voltage, and a precision
rectifier to convert the sinusoidal waveform to positive-only
values. The positive-only, periodic 50-Hz signal generated by
the precision rectifier, is then processed by a dedicated ADC
channel of the Arduino microcontroller. For this purpose, in
order to boost the ADC reading time, the ADC prescaler setting has been changed to 64 allowing a reduction of the sampling time from 430 µs to 21 µs
16. Fast real-time monitoring
of the AC signal is then achieved by means of a softwarebased interrupt service routine performing a periodic analysis
of the ADC read value every 2 ms. This time interval represents the lower limit to reaction times of our board to AC
mains failures. Our optimized routine raises a digital alert
every time the rectified signal drops below (above) a certain
software threshold value for more than 2 readings in a group
of 3 consecutive, meaning that a power loss (power restore)
is detected. Our AC monitor also provides a constant detailed
reconstruction of the AC power line waveform, along with its
RMS value. These features could also be exploited to detect
more complex power line degradation events (e.g., power line
brown-outs), occurring on timescales larger than few ms, after proper modification of the programming code uploaded on the microcontroller board.
As an example of power-down detection capability, Fig. 2cd reports the AC line waveform during an induced blackout
event (solid blue line) along with the digital alert signal generated by the board as a consequence of the detected power loss
(dashed red line), both measured with an oscilloscope probe.
The figures evidence how our simple but effective AC monitor scheme allows for a reliable and stable detection of power
outages / power restoration with minimal delays on the order
of 2.5 ms, enabling for prompt automated reaction in case interlock procedures are required by the presence of delicate instrumentation. Power loss alert messages are also delivered to
remote users for eventual further countermeasures or reaction
through remote control of the board, enabled by our bidirectional communications scheme (see below). Alert messages,
such as AC mains failure, are always uploaded via the SigFox network, given the high probability of Ethernet network
failure as a contextual consequence of power outage.

VI. INFORMATION FLOW AND COMMUNICATION
LATENCY
As sketched in Fig. 4, the board is designed to work in two
possible operating modes differing for the type of communication platform used to share the sensor data with the enduser and to remotely control the board, named normal and
emergency, respectively. In normal operating conditions, data
are acquired and transferred from the board to a web-based
database via Ethernet connection. The database serves as an
intermediate storage unit between the board and an Android
application (see Sec. VII) which provides end-users with services such as data visualization, remote control of the board
through user-defined commands, or real-time definition of
new sensors. All the data transfer operations are managed by
a PHP server hosted on a free web service which also hosts the
MySQL database employed to store the sensor data and properties. An alternative data visualization modality exploiting a
website is under development but not yet realized. Emergency
conditions occur in the case Ethernet connectivity is not available and the board automatically switches to the SigFox network to transfer data to the database. Given the restrictions of
the SigFox network in terms of transmission rate and payload
size, different strategies have been adopted in order to share
the sensor data in the two operating scenarios. During normal
operation, sensor data sharing is realized exploiting a POST
request to the database server through Ethernet. The refresh
rate for data sharing can be set by user, but must not exceed the
sensor data acquisition rate. When the Ethernet connectivity
is lost (or in general with any user-defined event which can be
configured by end-user) the board enters the emergency operation regime, and the sharing is performed via uplink through
SigFox network. In this configuration, we have to cope up
with the limit of 12 bytes in the payload size due to SigFox
constrains, and with a maximum of 140 messages per day.
This corresponds to a message every 11 minutes to evenly
cover the whole day, but the messaging frequency could be
increased, e.g., in case a more dense monitoring in correspondence of certain events or time periods is required. In order
to maximize the information packed in a single SigFox message we engineered a packet frame structure which exploits
the first byte of the payload to cast a code associated to a specific (user-defined) critical event, and arranges the values of
11 (user-defined) sensors in the remaining 11 bytes. As this
data frame requires each sensor value to be converted to 8-bit
resolution, we minimize information loss by shifting the conversion range (i.e. 28 = 256 values) to a measurement range
chosen by the user, which can be focused on the relevant variation range for each monitored quantity. Once the message is
sent, a callback redirects the payload of uplink messages from
the SigFox backend to the web server, which performs a conversion of the sensor values back to real units before storing
them on the database. In both normal and emergency operation modes, end users can retrieve information on sensor readings through a dedicated Android application (see Sec. VII for
details).

A. Remote control of the board through bidirectional data
link
Besides representing a versatile and real-time remote condition monitoring system, our system offers a bidirectional data
link in both Ethernet and SigFox connection configurations.
This feature allows our board to execute user-defined remote
commands in either normal or emergency conditions, which
has a prominent relevance in cases where human weighted
decisions are preferable over automated / programmed countermeasures in response to critical events. This could encompass, e.g., fail-safe setting of equipment to preserve or restore
its operating condition after power outages, or more generically any response to unexpected events for which no action
could be defined before the critical event. As an example, a
remote command, changing the status of one (or more) out
the 4 digital I/O ports provided by our system can be employed to manually trigger an interlock, or to reactivate / reprogram an instrument after a blackout. When SigFox connectivity is employed a maximum of 4 downlink messages
carrying a payload of 8 bytes can be received per day. Because of power saving requirements, inherited by the SigFox
framework, downlink requests cannot be issued at every time,
and they can only be performed after the device initiates the
communication with an uplink message. For this reason the
8-bytes payload containing the remote commands list set by
the user from the Android application is stored online and
redirected to the device by the SigFox backend after the backend itself receives an uplink message. The downlink reception
window starts 20 s after the uplink transmission has finished
and lasts for 25 s. The whole operation consisting in an uplink followed by a downlink event takes about 40 s to complete, as shown in table II where the reaction times of the system are reported. In the normal configuration, being the board
not continuously polling for downlink messages, a procedure
similar to the one adopted in the emergency configuration is
employed to retrieve user remote commands. In this configuration the amount of downlink messages is virtually unlimited,
and command execution times are substantially limited by the
latency of the Ethernet network+Arduino Ethernet shield, the
command processing time of the software loaded on the Arduino board. The complete process requires typically less than
50 ms plus the Ethernet latency time.

VII. ANDROID APPLICATION
In the current version of the project, an Android application was chosen as the only interface between the end-user
and the board. The extremely portable nature of this solution
guarantees a constant monitoring of the sensor records as well
as the possibility to react to unexpected critical event in any
condition. The application has been developed within the Android Studio environment and registered on the Google Firebase platform in order to exploit its cloud messaging service
to notify user-defined, critical events such as a power outage
or a sensor value exceeding a predefined threshold directly on
the end-user device. Fig. 5a shows the main view of the ap-
7
Absolute time ∆t
Power down event t0 –
Start alarm SigFox uplink t0 + 1.3 s ±0.5 s
Android notification displayed t0 + 4.5 s ±0.6 s
Remote SigFox command execution t0 + 39.6 s ±0.7 s
TABLE (II) System reaction times during emergency
operating conditions. A power outage event at t0 triggers the
communication of an alarm exploiting the SigFox network.
The board needs on average 1.3 s to compile the SigFox
message and start the transmission. Alarm notification on the
end-user device are displayed on average 4.5 s after the
critical event. Finally, due to the long SigFox downlink
times, the execution of a remote command takes about 40 s
from the critical event to be started.

VIII. CONCLUSIONS
In this work we presented a new system for remote monitoring and control of experimental apparatuses based on the
SigFox wireless communication network. Our system consists of a complete platform for multi-sensor data acquisition,
bidirectional data sharing via either Ethernet WLAN or Sigfox network and data visualization on end-user mobile Android devices. The data acquisition module is based on a
battery-powered Arduino MKR FOX 1200 board designed to
sustain a complex, fully customizable general purpose sensor network operating exploiting the 1-wire and/or I2C bus
standards. Low power consumption and SigFox connectivity
ensure a prolonged bidirectional link with remote instrumentation even in case of a power-outage of the electricity line
or/and a failure of the WLAN network. An Android application provides the end-user with a portable interface to monitor
sensor data and to plan the execution of remote commands.
Alarm messages concerning out-of-threshold sensor values or
emergency events like a blackout are notified directly on the
user’s device exploiting the Google Firebase cloud messaging service. The system has been tested with several lowcost commercially available sensors and is equipped with a
novel, custom AC power line monitor which demonstrated
power outage detection times as low 2 ms. These features
make our platform ideally suited for a plethora of applications which include continuous environmental and instrument
variable monitoring, detection and real-time communication
of critical events and remote manual intervention in case of
instrument failure.
ACKNOWLEDGMENTS
Authors would like to warmly thank L. Mischi for valuable technical support, and L. Fallani and G. Cappellini for
carefully reading the manuscript. Authors would like to
thank TechLab (http://quantumgases.lens.unifi.it/exp/tech) for
financial and technological support to the project, and all
members of Ytterbium team at LENS – Florence for valuable
discussions and help during the test phase.
DATA AVAILABILITY STATEMENT
Experimental data available on proper request from the authors. For further technical and availability information on
the complete system please contact TechLab via e-mail: jacopo.catani@ino.cnr.it.

---

Source: https://maker.wiznet.io/WIZnet/projects/remote-monitor-and-control-system-based-on-sigfox-iot-network/