sensors

Article
Design and Implementation of a Wireless Sensor Network for
Seismic Monitoring of Buildings
Julio Antonio Jornet-Monteverde 1 , Juan José Galiana-Merino 1,2, * and Juan Luis Soler-Llorens 3

1 Department of Physics, Systems Engineering and Signal Theory, University of Alicante,

Crta. San Vicente del Raspeig, s/n, 03080 San Vicente del Raspeig, Spain; [email protected]
2 University Institute of Physics Applied to Sciences and Technologies, University of Alicante,
Crta. San Vicente del Raspeig, s/n, 03080 San Vicente del Raspeig, Spain
3 Department of Earth Sciences and Environment, University of Alicante, Crta. San Vicente del Raspeig, s/n,
03080 San Vicente del Raspeig, Spain; [email protected]
* Correspondence: [email protected]; Tel.: +34-965-909636

Abstract: This article presents a new wireless seismic sensor network system, especially design
for building monitoring. The designed prototype allows remote control, and remote and real-time
monitoring of the recorded signals by any internet browser. The system is formed by several Nodes
(based on the CC3200 microcontroller of Texas Instruments), which are in charge of digitizing the
ambient vibrations registered by three-component seismic sensors and transmitting them to a central
server. This server records all the received signals, but also allows their real-time visualization in
several remote client browsers thanks to the JavaScript’s Node.js technology. The data transmission
uses not only Wi-Fi technology, but also the existing network resources that nowadays can be found





 usually in any official or residential building (lowering deployment costs). A data synchronization
scheme was also implemented to correct the time differences between the Nodes, but also the long-
Citation: Jornet-Monteverde, J.A.;
term drifts found in the internal clock of the microcontrollers (improving the quality of records). The
Galiana-Merino, J.J.; Soler-Llorens, J.L.
Design and Implementation of a
completed system is a low-cost, open-hardware and open-software design. The prototype was tested
Wireless Sensor Network for Seismic in a real building, recording ambient vibrations in several floors and observing the differences due to
Monitoring of Buildings. Sensors 2021, the building structure.
21, 3875. https://doi.org/10.3390/
s21113875 Keywords: wireless sensor networks; Wi-Fi networks; CC3200; Node.js; ambient vibrations; data
acquisition; building monitoring
Academic Editor:
Vassilis Papanikolaou

Received: 30 April 2021 1. Introduction

Accepted: 2 June 2021
The degree of building damage caused by earthquakes is strongly related to the soil
Published: 4 June 2021
characteristics (local site effects) and the dynamic behavior of the structures [1]. In the case
of the structures, numerical modeling and experimental measurements are widely used for
Publisher’s Note: MDPI stays neutral
estimating the dynamic properties of a building, although only experimental procedures
with regard to jurisdictional claims in
published maps and institutional affil-
allow obtaining the real behavior.
iations.
Earthquakes [2–5], forced vibrations [6,7] and ambient vibrations [8–10] can be used
as input signals. Earthquakes and forced vibration recordings are costly options that can be
applied in a reduced number of selected buildings. Besides, in the case of the earthquakes,
permanently monitored buildings are also required. Thus, ambient vibration (or ambient
noise) measurements have become a widely used alternative, as it is the fastest, cheapest
Copyright: © 2021 by the authors.
and easy-to-implement experimental approach. In this case, a minimum of two three-
Licensee MDPI, Basel, Switzerland.
component accelerometers or seismometers located on the ground and top floors can be
This article is an open access article
distributed under the terms and
used [11], although more extensive measurements are usually implemented [12]. Regarding
conditions of the Creative Commons
the recording duration, measurements ranging from a few minutes [1] to several days [13]
Attribution (CC BY) license (https:// can be found in the literature. Once the data is recorded, it is subsequently processed to
creativecommons.org/licenses/by/ estimate the building properties, such as the fundamental frequency [14,15]. Some of these
4.0/). techniques are the horizontal-to-vertical spectral ratio (H/V or HVSR) [16–18] and the

Sensors 2021, 21, 3875. https://doi.org/10.3390/s21113875 https://www.mdpi.com/journal/sensors

Sensors 2021, 21, 3875 2 of 26

standard spectral ratio (SSR) [19]. In the case of the H/V method, the spectral ratio between
the average of the two horizontal components and the vertical component, measured on
the highest level of the structure, provides an estimation of the resonant frequency of the
monitored building structure [11,20]. The fundamental frequency can be also estimated by
the SSR technique, calculating the spectral ratio of the horizontal components (longitudinal
and transversal) registered on the top floor and the same components registered on the
ground floor [21].
In this context, that is ambient noise monitoring in buildings, most of the time the
recording of the signals is carried out in situ, with seismographs that record the signal in
the internal memory. Once the measurements have been completed, the data are recovered
individually from each of the seismographs used, either by connecting a computer to them
or by copying the memory cards one by one [1,11,22].
Another alternative is to wire the different sensors to multichannel data acquisition
equipment, which in turn can be connected to a computer [12]. One of the limitations of
these systems is that they use cabling to interconnect the different sensors with the recorder
and this can severely limit the height of the building to be monitored. Another limitation is
the impact of the signal-to-noise ratio, SNR, as the length of the cabling increases and also
the interference that can be introduced in the recorded signal.
There are wireless seismographs on the market that do not have the limitations
mentioned above but are very expensive, such as Unite System by Sercel [23], Sigma
Systems by iSeis [24], or FierFly System by INOVA [25]. We can also mention the one
developed by Jilin University [26].
The high cost of instrumentation and the rise of low-cost microcontrollers, each
time with more functionalities, is what motivates the increasing number of proposals
for measurement systems developed by the research groups themselves. Thus, wireless
solutions can be found in the literature for seismic exploration [27,28], microzonation
studies [29–34] and building monitoring [35–37], among others.
In the case of building monitoring, which is the research framework of this work,
Nastase et al. [35], proposed a mixed system with wired and wireless connections. In this
work, each sensor is wired to an analog-to-digital converter and then into a data acquisition
computer. All these computers are connected to one router, which was in turn connected
to a wireless base station that communicated with the computer systems outside of the
building. A GPS Network Time Server with an antenna placed on the building’s balcony
was used for synchronization.
In the work of Hou et al. [36], the proposed system consists of a base station, a
computer and several wireless nodes connected in star topology. Each node includes four
main units: flash storage, wireless transmission, microprocessing, and power management.
The wireless transmission is carried out by the Texas Instruments CC2520 and CC2951
modules, using the ZigBee/IEEE802.15.4 protocol. They are used for sending and receiving
orders and data. However, no consideration is found regarding data synchronization,
which is very important when several sensors are monitoring simultaneously.
Finally, Valenti et al. [37] developed a system formed by two wireless sensor nodes
connected to a wireless sensor network concentrator, which is in charge of sending com-
mands, maintaining the synchronization, and identifying any malfunctions. In this case,
the data are stored in a local memory and transmitted after the acquisition ends, using a
polling scheme.
For short measurement periods, below one hour, it is important that all sensors are
initially synchronized. However, for longer periods, in the order of several days, it is
important that the synchronization is maintained throughout the entire measurement
period, avoiding possible drifts of the internal clocks. In addition, in these cases, it is very
important to have remote and real-time monitoring of the data, what allows verifying, at
any time and from anywhere, that the recording is being carried out correctly.
Therefore, one of the great challenges in distributed acquisition systems is the perfect
synchronization of the different Nodes, since without this feature the acquired signal tends
Sensors 2021, 21, 3875 3 of 26

to move and produces errors in the calculations of different parameters such as propagation
speed, positioning of the origin of the movement, etc. One of the disadvantages of the
existing microcontroller boards in the market is that they use a poor-quality quartz clock
to lower their prices. These clocks are not very accurate and produce deviations that in
prolonged recordings cause the time differences to be even greater and can be clearly per-
ceived. For this reason, a great deal of effort has been devoted to implementing algorithms
capable of synchronizing the Nodes. A starting point for the study of existing wireless
sensor network (WSN) algorithms and protocols is presented by Sundararaman et al. [38],
where different techniques are summarized and compared.
The basis of this work is an adaptation of the scheme proposed by Jornet-Monteverde
and Galiana-Merino for multi-zone air conditioning systems [39] and an evolution of the
works of Soler-Llorens et al. for wired [40] and wireless [31] seismic noise acquisition
systems. In these last works, the samples are stored locally for later recovery and post-
processing. In the wireless prototype [31], Zigbee technology is used to set up and control
the registering process, although there is no real-time information on the recorded data. In
the wired prototype [40], the registered signal can be monitored in real-time if a laptop is
connected to the system. Therefore, in none of these works the signal can be stored and
monitored remotely.
In this sense, the designed prototype gathers in a single system all the characteristics
mentioned above. It provides remote and real-time control, data monitoring and saving, as
well as data synchronization along all of the measurement period. For that, the proposed
system uses not only the wireless communication, but also the existing network resources
of the monitored building, reducing the expenses. Finally, the implementation is carried
out with low-cost microcontrollers and microcomputers, providing an open-hardware and
open-software system.
For a correct choice of protocol and algorithm it is necessary to take into account the
topology of our WSN. In our case we propose a point-to-multipoint topology, with a server
that provides the clock reference to the different Nodes under a wired and wireless network
infrastructure. In this work we developed a wireless seismic acquisition system capable
of displaying the sensor signal in real time and at low cost. Wi-Fi technology is used to
provide the Nodes with access to the internal network of the building to be monitored
and through this network the messages containing the signal samples are transmitted to
the server, which can be located anywhere as long as it is connected to the same network.
According to the Spanish Institute of Statistics, 91.4% of households had internet access
and almost all of them, 99.7% (15 million households), had broadband internet in 2019 [41].
In United States, more than 80% of households had also internet in 2016 [42]. Thus, the use
of the internal network connections in the monitored building is widely justified.
It is important to emphasize that each Node must be perfectly synchronized with the
server, so the local time is also obtained. The proposed system does not use wiring and
each Node is an independent entity that is controlled only by the server.
The main novelties of the designed system can be summarized in these points: (1) the
data interconnection scheme between Nodes and Server uses not only wireless commu-
nication, but also the existing network resources that nowadays can be found usually in
any official or residential building (lowering deployment costs); (2) the implemented data
synchronization approach takes into account not only the time differences between the
Nodes, but also the long-term drifts found in the internal clock of the microcontrollers,
what improves the quality of records; (3) the system offers remote control access, but also
remote and real-time monitoring and saving of the measured signals; (4) it is based on
low-cost instrumentation. Another advantage is that the system is totally modular and
up to 38 Nodes can be configured in theory, depending on the internal network traffic. In
our case, the system was tested with up to two Nodes, recording ambient vibrations in a
two-floor house.
Sensors 2021, 21, x FOR PEER REVIEW 4 of 27

Sensors 2021, 21, 3875 4 of 26

case, the system was tested with up to two Nodes, recording ambient vibrations in a two-
floor house.

2. Materials
Materials and
and Methods
2.1. Model
Model Description
Description
In order to monitor
monitorand andrecord
recordthethevibrations
vibrationsthatthatoccur
occurinindifferent
differentzones
zonesof of
a building
a build-
ing in real time, a model based on the Client-Server concept was designed. The clients are
in real time, a model based on the Client-Server concept was designed. The clients are
implemented using
implemented using aa Texas
Texas Instruments
Instruments (TI) CC3200 microcontroller
(TI) CC3200 microcontroller [43]
[43] (Nodes)
(Nodes) andand the
the
server is
server is configured
configuredthough
thoughaaRaspberry
RaspberryPiPi computer
computer [44] (RPI
[44] (RPIServer). TheThe
Server). system consists
system con-
of several
sists Nodes
of several located
Nodes on different
located on different floors of of
floors thethebuilding.
building.Each
EachNode
Node incorporates
incorporates
aa specially
specially designed
designed expansion
expansion board
board with
with aa conditioning circuit [40]
conditioning circuit [40] (page
(page 5),
5), which
which isis
connected to a three-component seismic sensor for the X-Y-Z axes.
connected to a three-component seismic sensor for the X-Y-Z axes. The Nodes are con-The Nodes are connected
to the Wi-Fi
nected to theon eachon
Wi-Fi floor
eachwhere
floorthey
wherearethey
located and through
are located the building’s
and through internalinter-
the building’s local
network they connect to the RPI Server via a TCP (transmission control protocol)
nal local network they connect to the RPI Server via a TCP (transmission control protocol) connection.
A JavaScript A
connection. (JS) server was
JavaScript developed
(JS) server was in the RPI Server
developed in that
the manages
RPI Server thethat
TCPmanages
connections
the
of the Nodes and receives the samples from each Node. Besides,
TCP connections of the Nodes and receives the samples from each Node. Besides, the re- the received data are
saved in
ceived local
data arefiles
savedandindisplayed
local filesthrough a web user-interface.
and displayed through a web user-interface.
Figure 1 shows the diagram of the developed system.
Figure 1 shows the diagram of the developed system. It It should
should bebe noted
noted that
that from
from
the designed web user-interface, it is possible to set up the number of Nodes that will be
the designed web user-interface, it is possible to set up the number of Nodes that will be
running simultaneously in the system.
running simultaneously in the system.

Figure 1.
Figure 1. (a) General scheme
(a) General scheme of
of the
the developed
developed system
system and
and its
its elements.
elements. (b)
(b) General
General three-dimensional
three-dimensional schematic
schematic of
of aa
monitored building.
monitored building.

The MQTT (message

The MQTT (messagequeuing
queuingtelemetry
telemetry transport),
transport), UDP
UDP (user
(user datagram
datagram protocol)
protocol) and
and
TCP protocols were tested to send the samples from each Node. We decided to usetoTCP
TCP protocols were tested to send the samples from each Node. We decided use
TCP as it is the most stable and efficient protocol for the Nodes-to-Server communication.
as it is the most stable and efficient protocol for the Nodes-to-Server communication. The
The
teststests carried
carried out with
out with the MQTT
the MQTT library
library causedcaused the Nodes
the Nodes to block
to block frequently
frequently in time
in long long
time periods.
periods. Another
Another factorfactor for choosing
for choosing TCP isTCP that is that it guarantees
it guarantees the delivery
the delivery of our
of our packets
packets in a sequential
in a sequential manner
manner even if theeven
Nodesif the
areNodes are insubnets.
in different differentBesides,
subnets.
oneBesides, one
additional
network layer is avoided by working directly with TCP, since MQTT is above TCP, and in
this way some resources are released in the Nodes. As for the tests performed with UDP,
it is observed that packets arrive correctly, with a packet loss rate of less than 1%, if the
Sensors 2021, 21, 3875 5 of 26

Nodes are in the same network and there is not much traffic. However, as soon as the Wi-Fi
traffic increases or different subnets are used for the Node connections, the packet loss rate
also increases. Therefore, for our purposes, the best choice is the TCP protocol, because of
its low packet loss rate, and the savings in memory and processing resources in the Nodes.
Although TCP guarantees the connection, if there were many retransmissions due to
network congestion or due to any Node down, then packet loss could occur and possibly
the connection would be restarted (TCP RESET). The RPI Server and Node codes were
prepared to detect this situation and report the number of missed packets as soon as the
connection is reestablished.
Another critical situation may be the loss of Wi-Fi connection during the sampling
process. In this case, the TI libraries in charge of the Wi-Fi connection are programmed to
reestablish the connection internally. Besides, control routines were also implemented in
the Nodes to reestablish the connection with the RPI Server.
Due to the characteristics of the signal to be sampled (ambient vibrations or seismic
noise), the proposed system was designed to work with a sampling frequency of 100 Hz,
what it is enough for the expected frequencies. The three components of the seismic sensor
were digitized through the 12-bit ADCs incorporated in the microcontroller. A minimum
of 2 bytes (16 bits) is required to record each of these data. Besides, for synchronization
purposes, a millisecond mark is also transmitted with the data. Thus, a constant rate of
100 samples × 4 values × 16 bit = 6.4 Kbps is the minimum payload that the protocol must
assume. To be as efficient as possible, a single Ethernet frame is used to transmit a block of
samples. The maximum size of the Ethernet frame is 1518 bytes, so we will transmit blocks
of 100 samples (800 bytes) every second, as two seconds would exceed the maximum size
and we will have to use segmentation.

2.2. Raspberry Pi Server

The server was developed over a Raspberry Pi 3 Model B v1.2 [44] with Raspbian
GNU/Linux 9 core 4.19. This model incorporates the Wi-Fi interface that can be configured
as an access point (AP) to provide coverage to the nearest Nodes. In our architecture
the RPI Server is connected to the internal network through the RJ45 connector and the
internal network is responsible for providing connectivity to the different Nodes. This
computer was chosen because one of the objectives is to design a portable, low-cost system
that allows us to easily instrument a building temporarily. In this sense, the Raspberry Pi
computer meets the hardware requirements needed by the developed system, so it is not
necessary to add a laptop or a dedicated computer, which would increase the cost.
The Node.js [45] package was installed in order to provide the Web service and execute
the JavaScript code of the Server. The main features implemented in the code are:
- TCP connection management.
- Management of received packets and storage of samples.
- Synchronization management.
The SCP (Secure Copy Protocol) service was also installed to access the sample files and
download them for a possible subsequent signal processing, for example with MATLAB.

2.2.1. TCP Connections

In order to identify from which Node each of the received packets comes, a TCP port
was created for each Node, instead of creating a generic one. Thus, Port 8001 will be used
for Node 1, 8002 for Node 2 and so on. The RPI Server will create as many ports as the
number of Nodes specified in the configuration and will wait for a new connection through
the socket. In this way, it is much easier to identify the origin and to group the samples.
When a connection is created, a Hello message should be received to confirm the Node
number and the socket will be stored in an array to manage the traffic to be sent.
A timeout was activated in each connection to detect the shutdown of a Node, being
32 s that correspond to the loss of three consecutive Hello messages. Two seconds were
Sensors 2021, 21, 3875 6 of 26

added to the timeout for considering any possible delay in the local network due to
increased traffic or any other cause.
As already mentioned, in case of network congestion it is very likely that connections
will be lost due to excessive TCP retransmissions or Timeout. However, while these
connections are being recovered, if the Nodes are in Sampling Mode, they will not be able
to send the samples and this is when the loss of samples will occur since the Nodes will
not stop sampling. For this reason, it is necessary to detect and report the loss of segments
and samples. To do this, the RPI Server keeps track of the number of samples it expects to
receive for each Node. If at the reception of a segment these do not match, the RPI Server
will calculate how many samples have been lost and increment the corresponding variable.
As soon as the Node resets the TCP connection, it will resend the segments containing
the samples.
For the connection between the JS Server and the client web browser, WebSockets [46]
were used and a series of events was defined, which will be sent as they occur.

2.2.2. Packets Management and Sample Recording

Several types of packets from our management layer were implemented. As for the
packets containing the samples, if there is a web connection, one sample out of 10 contained
in the packet will be sent to the client’s web browser in order to not saturate it. This means
that for every 100 samples contained in a packet, sample 1, 11, 21... and so on will be sent.
To graphically represent these samples in the client’s web browser, the Highcharts [47]
object for JavaScript was used.
We implemented the option to save the samples (SAVEDATA) in binary files to be
able to process them later (for example in MATLAB). The samples will be saved in files
every 15 min that the code itself will generate.

2.2.3. Synchronization Management

RPI Server provides the date/time using the NTP (network time protocol) protocol.
For this, an NTP client was configured to obtain the correct date and time from an NTP
server, and then an NTP server was configured so that the RPI Server itself provides the
date and the time to the Nodes.
The synchronization process between the RPI Server and the Nodes will be detailed
later on.

2.3. Nodes
The TI CC3200 platform [43] was used for the development of the Nodes due to its
low power consumption and the easy integration through its Wi-Fi interface. Specifically,
the CC3200 LaunchPad development board was chosen.
The main functions carried out by the Nodes are:
• Controlling the main timer and synchronization;
• Controlling the sampling;
• Controlling the Wi-Fi and NTP connections;
• Controlling TCP connection;
• CLI (command line interface).
The block diagram used for the Nodes functioning is shown in Figure 2. The messages
used between interrupts (TIMER_A0, TIMER_A1 and CLI) and tasks (Main, WLAN, TCP
Server and TCP Client) are also indicated in the block diagram.
 Sensors
Sensors 2021,
2021, 21,21,x 3875
FOR PEER REVIEW 7 of 26 7 of 2

Figure 2. Block diagram of the Nodes software. The main functions (square blocks) and interrupts
Figure 2. Block diagram of the Nodes software. The main functions (square blocks) and interrupts
(oval blocks) are shown and their relationship.
(oval blocks) are shown and their relationship.
Three interrupts were enabled:
1. Three interrupts
TIMER_A0. It is thewere enabled:
sampling timer and occurs every 10 milliseconds for capture
1. the samples. By default it is disabled
TIMER_A0. It is the sampling timer until
anda occurs
START every
command is received from
10 milliseconds for the
capture the
RPI Server.
samples. By default it is disabled until a START command is received from the RP
2. TIMER_A1. It is the main timer of the program and always occurs every one second.
Server.
3. CLI (command line interface). It is activated every time that the UART0 receives a
2. TIMER_A1.
character. ThisItinterrupt
is the main timer
is used of the program
to receive and always
user commands occurs
through every and
the UART0 one second
3. CLI (command
enable logging. line interface). It is activated every time that the UART0 receives a
character.
Besides, fourThis
tasksinterrupt is usedinto
are also created receive
the user commands
Start module. The tasks inthrough the
execution UART0 and
are:
enable logging.
1. Main task.
ItBesides, four tasks
is responsible are also created
for executing the maininfunctions
the Startand
module. TheThe
routines. tasks instep
first execution
is to are:
read the configuration parameters from a flash memory. After that, main task accesses
1. an Main
to task.
infinite loop where all messages that the main task should handle are. It is also
responsible for starting and
It is responsible for stopping
executingthethe
sampling
main process, andand
functions for setting the timers
routines. to bestep is to
The first
synchronized
read the configuration parameters from a flash memory. After that, main taskCLI
with the NTP server. Finally, it is in charge of opening and closing the accesses to
command line session.
an infinite loop where all messages that the main task should handle are. It is also respon
sibleWLAN
2. task. and stopping the sampling process, and for setting the timers to be syn
for starting
chronized with the
In this task, thefunctionalities
NTP server. associated
Finally, itwith
is inWi-Fi
charge of opening
connectivity, and
time closing the CL
acquisition
with an NTPline
command server, and the calculation of the delay and drift time with respect to the RPI
session.
Server are carried out.
2. WLAN task.
3. Server task.
In this task, the functionalities associated with Wi-Fi connectivity, time acquisition
This task is in charge of monitoring port 800X and waiting for TCP packets to be
with an NTP
received. server, frames
The different and thethat
calculation of the
were defined are delay and drift time
also implemented and with respect
processed. to the RP
This
Server
task are carried
is related to the out.
receiving part of the communication.
4.
3. Client
Servertask.
task.
This
Thistask
taskisisresponsible
in chargefor
of managing theport
monitoring socket thatand
800X communicates
waiting forwith
TCPthepackets
RPI to be
Server and therefore for sending the packets. It is in charge of constructing the frames
received. The different frames that were defined are also implemented and processed
defined in our protocol and sending them to the RPI Server, including the frame with the
This task is related to the receiving part of the communication.
samples that have just been collected.
4. Client task.
This task is responsible for managing the socket that communicates with the RP
Server and therefore for sending the packets. It is in charge of constructing the frame
defined in our protocol and sending them to the RPI Server, including the frame with the
samples that have just been collected.
Sensors 2021, 21, 3875 8 of 26

2.3.1. Sampling Mode

Nodes are connected to a three-component sensor through a conditioning circuit [40].
In our case, the sensor Mark-l-4C3D, with a natural frequency of 1 Hz, was used. The
conditioning circuit is connected to the three inputs of the ADC1, ADC2 and ADC3 to
sample each of the three components. When a Node receives a START-SAMPLING packet,
the Timer_A0 is activated and triggers every 10 ms. In the interrupt routine, the first thing
that is done is to read the value in milliseconds of the TimeStamp (i.e., MilliTimeStamp,
mTS) carried by the Node through Timer_A1 and then the values of the three ADCs are
read. These four values (mTS, ADC1, ADC2, ADC3) are stored in a buffer and the counters
in charge of controlling the number of total samples (numtotalsamples) and the number of
samples per packet (countsamplespkt) are incremented. When 100 samples are taken, that is,
every second, the MSG_SEND_PKT_TCP event is sent to the ClientTask to generate the
packet with the 400 values (mTS, ADC1, ADC2, ADC3) and send it to the RPI Server. The
inclusion of the mTS information in each packet helps to verify that the sample rate remains
stable throughout time. In order to know if the sampling of the signal might generate any
type of congestion in the resources of the microcontroller, the duration of the sampling
routine was measured. The results show that every 10 ms (sampling period), the routine
spends 4 ns in the data acquisition. Therefore, the performance of the other tasks carried
out by the Nodes is guaranteed.

2.3.2. CLI Interface

The UART0 was initially enabled as an aid to the development and troubleshooting of
the code. A library was developed with a series of commands that allow displaying the
status of each Node and the value of the variables used. Besides, the Wi-Fi selection (SSID
and password parameters) can be also configured through one of these commands, either
for the first time or because a change network is required.

2.4. Wi-Fi–TCP Communication

This is one of the most important blocks in the designed system since it must be capable
of transmitting all the captured samples to the RPI Server without any loss. As the CC3200
board incorporates the Wi-Fi interface inside, the sending and receiving of messages can be
handled from the designed code using the libraries provided by Texas Instruments.
We chose the TCP protocol as the container for our own layer and packet system. Three
tasks were created to manage all the events created: Wi-Fi, ServerTCP and ClientTCP Tasks.
Once all the peripherals are initialized and the required variables (e.g., the SSID and
the password) are read from a flash memory, the Main task starts the Wi-Fi connection
by sending an event to the Wi-Fi task. At this moment, the board automatically performs
everything necessary to connect to the wireless access point (AP or WAP) and provides an
IP. If there were any errors, the function would return an error code. Once the connectivity
is established, the current date/time will be requested to the NTP server in order to
be synchronized.
As previously mentioned, the ServerTCP task is in charge of listening and receiving
TCP packets coming from the RPI Server, and the ClientTCP task is in charge of creating
and sending packets to the RPI Server.
Nine different types of messages were defined, being identified through type field
(byte 2) and code field (byte 3) of each frame (Table 1).
Hello messages are generated on the Nodes every 10 s and serve to notify the RPI
Server that the Node and the socket are alive. Two fields TimeStamp (TS) and milliTimeS-
tamp (mTS) are added to each Hello message to tell the RPI Server the time just before
sending the packet. The TS (4 bytes) field is the time in the UTC system and the mTS
(4 bytes) field corresponds to milliseconds. These messages will be an important part in
maintaining the synchronization of the Nodes with respect to the RPI Server.
 Types of Messages
Echo Reply
Sampling Order, START immediately
Sensors 2021, 21, 3875 Sampling Order, STOP 9 of 26
Sampling Order, START without sending
Sampling Order, START in next sec
Samples Reply
Table 1. Types of messages.
Set Stop-and-Go
Hello
Types of Messages
Set Timer, set Sampling Timer counter value
Echo Reply
Set Timer, Ack
Sampling Order, START immediately
Set Timer,Order,
Sampling set Delay
STOPTimer value in milisecs
TimeStamp,
Sampling Order,initSTART
sampling
without sending
TimeStamp,
Sampling Order,Stop-and-Go
START in next sec
Samples Reply
TimeStamp, finish sampling
Set Stop-and-Go
Echo Request
Hello
SYNC CLK Request
Set Timer, set Sampling Timer counter value
SYNC CLK
Set Timer, AckReply
SYNC CLK
Set Timer, setReturn values
Delay Timer value in milisecs
TimeStamp, init sampling
TimeStamp, Stop-and-Go
Hello messages are generated on the Nodes every 10 s and serve to notify the RPI
TimeStamp,
Server finish
that the sampling
Node and the socket are alive. Two fields TimeStamp (TS) and milli-
Echo Request
TimeStamp (mTS) are added to each Hello message to tell the RPI Server the time just
SYNC CLK Request
before sending
SYNC CLK Reply the packet. The TS (4 bytes) field is the time in the UTC system and the
mTS
SYNC(4 bytes) field corresponds
CLK Return values to milliseconds. These messages will be an important part
in maintaining the synchronization of the Nodes with respect to the RPI Server.
The structure of the Hello messages is shown in Figure 3. It is composed of the fol-
The structure of the Hello messages is shown in Figure 3. It is composed of the
lowing fields:
following fields:
• Fields 1 and 2 (Origin, Destination). Indicates who is sending the message and who
• Fields 1 and 2 (Origin, Destination). Indicates who is sending the message and who
receives it.
receives it.
Master Ô0
Master 0
Nodes Ô 1, 2, 3 . . .
Nodes  1, 2, 3 …
• Field 3 (Type). Indicates the type of message.
• Field 3 (Type). Indicates the type of message.
• Field 4 (Code = 0).
•• Field
Field 45 (Code = 0).
(TimeStamp). System Time in UTC seconds
•• Field
Fields56.(TimeStamp). SystemMilliseconds
(milliTimeStamp). Time in UTCSystem
seconds
Time
• Fields 6. (milliTimeStamp). Milliseconds System Time

1 2 3 4 5 6 7 8 9 10 11 12
Origin Dest Type Code UTC System Time Millisecs System Time

Figure
Figure 3.
3. Structure
Structure of
of the
the Hello
Hello message.
message.

Type
Type 1 messages (SO, Sampling Order) are used to order
order the
the START/STOP
START/STOP of the
sampling
sampling according
according to the Code value. The
The possible orders are:
•• Code =
Code = 1:
1: Indicates
Indicates that
thatthe
theNode
Nodestarts
startssampling
samplingimmediately
immediately byby
sending thethe
sending samples.
sam-
• Code
ples. = 2: Indicates that the Node immediately stops sampling and sends the pend-
• ing samples.
Code = 2: Indicates that the Node immediately stops sampling and sends the pending
Sensors 2021, 21, x FOR PEER REVIEW
• Code = 3: Indicates that the Node starts sampling immediately without sending 10 of 27
samples.
• the samples.
Code This option
= 3: Indicates that theisNode
for when
startsthe time and
sampling drift of the without
immediately Node clock needthe
sending to
be calibrated.
samples. This option is for when the time and drift of the Node clock need to be cal-
•• Code
Code==5:
ibrated. 5: Indicates
Indicatesthat
thatthe
theNode
Nodestarts
startssampling
samplingatatthe
thenext
nextsecond
secondand
andstart
startsending
sending
the samples.
the samples.
The structure of these types of messages is shown in Figure 4.
The structure of these types of messages is shown in Figure 4.

1 2 3 4 5 6 7 8
Origin Dest Type Code Top Samples

Figure4.4.Structure
Figure Structureof
ofthe
theSampling
SamplingOrder
Ordermessage.
message.

The Type 2 messages (Samples Reply) are the packets containing the data included
in the 100 samples. Concretely, this information corresponds to the three ADC channels
and the mTS variable, making a total of 400 values (800 bytes). Taking into account that
the header occupies 16 bytes, the maximum size of these messages will be 816 bytes. A
message will be generated every second. The Samples field indicates the number of time
 • Code = 5: Indicates that the Node starts sampling at the next second and start sending
the
thesamples.
samples.
The
The structureofofthese
structure thesetypes
typesofofmessages
messagesisisshown
shownininFigure
Figure4.4.
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
Sensors 2021, 21, 3875 Top Samples 10 of 26
Origin Dest Type Code
Origin Dest Type Code Top Samples

Figure 4. Structure of the Sampling Order message.

Figure 4. Structure of the Sampling Order message.
The Type
The Type 22 messages (Samples Reply) Reply) are
are the packets containing the the data included
in the The
100 Type 2messages
samples. messages (Samples
(Samples
Concretely, this Reply) arethe
information the packets
packetscontaining
corresponds containing
to the three
data
dataincluded
theADC included
channels
ininthe
the 100
100samples.
samples. Concretely,
Concretely, this
this information
information corresponds
corresponds totothethethree
three ADC
ADC channels
channels
and the
and the mTS
mTS variable,
variable, making
making aa totaltotal of
of 400
400 values
values (800
(800 bytes).
bytes). Taking
Taking into into account
account that
that
and
the the
headermTS variable,
occupies 16 making
bytes, thea total of
maximum 400 values
size of (800
these bytes).
messages Taking
will into
be account
816 bytes. that
A
the header
the header occupies
occupies 16 bytes,
16 bytes, the
the maximum
maximum size of these
size of these messages
messages will be 816
willnumber bytes.
be 816 bytes. AA
message
message will
will be
be generated
generated every
every second.
second. The
The Samples
Samples field
field indicates
indicates the
the number of time
ofoftime
message will
slots contained be
contained in generated every second. The Samples field indicates the number time
slots
slots ininthe
the message
message (1–100)
(1–100)and and the
theNumSec
NumSecfield indicates the
field
fieldindicates thesequence number
thesequence num-
of thecontained
packet which thewill
message
be the(1–100)
number andofthe
theNumSec
first sample indicates
of the message sequence num-
in the total
ber
ber ofofthe
thepacket
packet which
which will
willbebe the
the number
number of
ofthe
thefirst
first sample
sample ofof the
themessage
message in
in the
the total
total
computation. The structure is indicated in Figure 5.
computation.
computation.The Thestructure
structureisisindicated
indicatedininFigure
Figure5.5.
1 2 3 4 5 6 7 8 9 10 11 12
1 2 3 4 5 6 7 8 9 10 11 12
Origin Dest Type UTC System Time Millisecs System Time Samples
Origin Dest Type UTC System Time Millisecs System Time Samples

13 14 15 16 17 18 19 20 21 22 23 24
13 14 15 16 17 18 19 20 21 22 23 24
NumSec milli-1 ADC-1 ADC-2 ADC-3
NumSec milli-1 ADC-1 ADC-2 ADC-3

25 26 27 28 29 30 31 32
25 26 27 28 29 30 31 32
milli-2 ADC-1 ADC-2 ADC-3 …
milli-2 ADC-1 ADC-2 ADC-3 …

Figure 5. Structure of the Samples Reply message.

Figure5.5.Structure
Figure theSamples
Structureofofthe SamplesReply
Replymessage.
message.

Type
Type777messages
Type messages(TimeStamps)
messages (TimeStamps)are
(TimeStamps) arethe
are thepackets
the packets
packets used
used
used tototo
indicate
indicate
indicate totothe
to RPI
thethe Server
RPI
RPI the
Server
Server the
precise
the instant
precise at
instant which
at the
which Node
the starts
Node sampling
starts the
sampling first
the sample
first of
sample
precise instant at which the Node starts sampling the first sample of the configured block the configured
of the block
configured
(Code
block ==1),
(Code(Code1),the= instant
the 1), atatwhich
the instant
instant whichatitwhich
itsamples the
thesample
it samples
samples the indicated
sample sample
indicated ininthe
indicatedtheStop-and-Go process
in the Stop-and-Go
Stop-and-Go process
(Code
(Code = 2), or the instant at which it finishes the last sample of the configured block(Code
process = 2),
(Codeor the
= instant
2), or the at which
instant it
at finishes
which it the last
finishes sample
the last of the
sample configured
of the block
configured block
(Code
=(Code
= 3). These messages, once received by the RPI Server, will serve as a time referencetoto
3). These
= 3). messages,
These once
messages, received
once by
received theby RPI
theServer,
RPI will
Server, serve
will as
serve aastime
a reference
time reference
calculate
to calculate
calculate the
the duration
the duration
duration timetime
time ofofof
aaaconfigured
configuredsample
configured sampleblock
sample blockby
block bysimply
by simplycalculating
simply calculatingthe
calculating thetime
the time
difference
difference between a Code1 and a Code3 message. In
In Figure
Figure 6,
6, the
the
difference between a Code1 and a Code3 message. In Figure 6, the structure of these types structure
structure of these types
ofofmessages
of messagesis
messages isisshown.
shown.
shown.
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
Origin Dest Type Code Reserved Reserved Reserved Reserved
Origin Dest Type Code Reserved Reserved Reserved Reserved

Figure 6. Structure of the TimeStamp message.

Figure6.6.Structure
Figure Structureof
ofthe
theTimeStamp
TimeStampmessage.
message.

The remaining
Theremaining messages
remainingmessagesmessages are related tototiming and synchronization and
andwill be
bede-
The areare related
related to timingtimingandand synchronization
synchronization and will will
be detailedde-
tailed
tailed in
inSection
Section 2.5.
2.5.
in Section 2.5.
The
Thesequence
sequenceof ofofmessages
messages shown
shown in Figure 7 isisan example for aablock ofof1000 sam-
The sequence messages shown in in Figure
Figure 7 is7an an example
example for aforblock block
of 1000 1000 sam-
samples,
ples,
ples, so the duration will be 10 s. When the Nodes are not sampling, they are sending
so the so the duration
duration will bewill10 s.beWhen10 s. Whenthe Nodes the Nodes
are notare not sampling,
sampling, they are they are sending
sending Hello
Hello
Helloframes
frames every 10s 10stotoindicate that theytheyare alive. When the theuser sends
sendsthe START
frames every 10everys to indicate indicate
that theythat are alive. are
When alive.theWhen
user sends user
the START the START
command
command
command through the theweb browser, the theTopSamples field
fieldwill indicate the number of
through thethrough
web browser, web the browser,
TopSamples TopSamples
field will indicate willnumber
the indicate ofthe number
samples, thatof
samples, that is 1000 samples in this example. This mode is called Limit Mode. If, on the
issamples, that is in
1000 samples 1000
thissamples
example. in this
Thisexample.
mode is calledThis mode LimitisMode.
called If, Limiton theMode.other If, hand,
on the
other
noother hand,
hand,no
number
number
ofnosamples
numberis ofofspecified,
samples
samplesisis specified,
specified,
this
this
mode isthis
mode
calledmode isiscalled
calledContinuous
Continuous Continuous
Mode and the
Mode
Mode and
and
Node
the
will Node
the never will
Node stop never
will sampling stop
never stopuntil sampling
sampling until
it receives it receives
untila itSTOP
receives a
command. STOP
a STOPWhen command.
command.the Node When
When the Node
the Node
receives the
receives
Start
receives the
theStart
Sampling Start Sampling
frame,
Sampling frame,
the process the
frame,starts theprocess
and just
process starts
when
starts and just
it is
and when
going
just to it
when itisisgoing
read the
going totoread
ADC1 the
value,
read the
ADC1
the
ADC1Codevalue,
= 1 the
value, theCode
frame ==11frame
(message
Code type
frame (message
7) is sent
(message type 7)7)isisthe
so that
type sent
sent so
RPI sothat
thatthe
Server the RPI
RPIServer
registers theregisters
Server time T0,
registers
the
thetime
which time T0,
will T0,which
be will
willbe
the sampling
which bethe sampling
start
the time. Then
sampling start time.
startthetime.NodeThen
Then the
will Node
thesend
Node thewill send
stored
will the
thestored
sendsamples in
stored
samples
batches in
samplesofin100 batches of
samples.
batches 100
of 100 samples.
When the Node
samples. When
When the
finishesNode
the Node finishes
reading reading
the 1000th
finishes the
readingsample, 1000th
the 1000th then sample,
it will
sample,
send a Code = 3 frame and the RPI Server will register the time when it received this frame.
Then the Node will send the last packet with the remaining samples to be sent and end
the sampling. When the RPI Server receives the last packet with the last samples, it will
calculate the statistics of times, packet loss, etc., and these statistics will be sent to the Web
Client for visualization.
 to the Client browser where it will draw the shape of the signals interpolating the 10 sent
samples. The purpose of plotting the signal is to provide an estimate of the detected signal
and not the signal in detail as it would consume many resources in the web browser be-
cause Node.js is very heavy. Tests were carried out sending a larger number of samples
Sensors 2021, 21, 3875 but from 20 samples onwards the web browser will produce delays and stops in the 11 ofvis-
26
ualization, even slowness in the interaction with the controls, which produce crashes and
a poor response from the web browser.

Figure7.7.Sequence
Figure Sequenceof
ofone
oneblock
blockof
of1000
1000samples.
samples.

When
As longthe system
as there is aisWeb
registering, each Nodethe
Client connection, generates a constant
RPI Server will sendtraffic
a set of
of 6.5 Kbps, so
10 samples
we
to themust
clientconsider the load
to be drawn ofHighChart
in the the network so that
object. Eachnotime
datatheis RPI
lost.Server
The theoretical
receives a limit
packetof
our system
with the 400in terms(mTS,
values of theADC1,
maximumADC2,number of Nodes
ADC3), it will that canthe
extract be supported
four valueswill be given
of the time
by the load
intervals of 21,
1, 11, the 31...
network
until and the
it has theRPI
10 Server.
and will If send
the network interface
them through of the RPI to
a WebSocket Server
the
runs atbrowser
Client a theoretical
wherevelocity of 1 the
it will draw Gbps, considering
shape a limit
of the signals of 25% so as
interpolating not
the 10to saturate
sent the
samples.
OS, purpose
The RPI processes and the
of plotting theNode.js server,
signal is we getan
to provide anestimate
approximate of thetheoretical calculation
detected signal and
not theNodes.
of 38 signalIn in the
detail as it would
experiments weconsume
tested upmany
to two resources in the web
Nodes working browser because
perfectly.
Node.js is very heavy. Tests were carried out sending a larger number of samples but from
2.5.
20 Synchronization
samples onwardsProcess
the web browser will produce delays and stops in the visualization,
even A slowness in the
new synchronization interaction withwas
scheme thedesigned
controls,based
whichon produce crashes
the Precision andProtocol
Time a poor
response from the web browser.
(PTP) [48] and the Doze Mechanism [49]. The developed approach consists of two phases:
When
the first the system
phase is registering,
calculates eachdrift
the offset and Nodebetween
generates thea Nodes
constant andtraffic of 6.5Server;
the RPI Kbps, the
so
we mustphase
second consider
triesthe load of the
to correct theNode
networktimesodrift.
that no data is lost. The theoretical limit of
our system in terms of the maximum number
For the synchronization process of the Nodes, of Nodesnew thatmessages
can be supported
types 4, will
6 and be9given
were
by the load
created. of the network and the RPI Server. If the network interface of the RPI Server
runs at a theoretical velocity of 1 Gbps, considering a limit of 25% so as not to saturate the
OS, RPI processes and the Node.js server, we get an approximate theoretical calculation of
38 Nodes. In the experiments we tested up to two Nodes working perfectly.

2.5. Synchronization Process

A new synchronization scheme was designed based on the Precision Time Protocol
(PTP) [48] and the Doze Mechanism [49]. The developed approach consists of two phases:
the first phase calculates the offset and drift between the Nodes and the RPI Server; the
second phase tries to correct the Node time drift.
For the synchronization process of the Nodes, new messages types 4, 6 and 9 were created.
The Nodes use the timers provided by the hardware of the CC3200 board and its
quartz crystal. These crystals are not of very good quality and therefore small timing
differences occur, which are increased over time (drift). In order for the Nodes not to have
time differences at the moment they have to read the samples (jitter) and to be as accurate
as possible when taking the sample, they must have the same time reference as the RPI
Server. Thus, the offset and drift of each Node with respect to the RPI Server must be
calculated and its time reference adjusted.
The calculation of the offset and drift values is based on the operation of the PTP
protocol but with modifications. The synchronization process is managed by the RPI Server
 quartz crystal. These crystals are not of very good quality and therefore small timing dif-
ferences occur, which are increased over time (drift). In order for the Nodes not to have
time differences at the moment they have to read the samples (jitter) and to be as accurate
as possible when taking the sample, they must have the same time reference as the RPI
Sensors 2021, 21, 3875 Server. Thus, the offset and drift of each Node with respect to the RPI Server must 12 ofbe
26
calculated and its time reference adjusted.
The calculation of the offset and drift values is based on the operation of the PTP
protocol but with modifications. The synchronization process is managed by the RPI
that will initiate the exchange of messages between RPI Server and Nodes. Figure 8 shows
Server that will initiate the exchange of messages between RPI Server and Nodes. Figure
a part of the message sequence.
8 shows a part of the message sequence.

1 2 3 4 5 6 7 8 9 10 11 12
Origin Dest Type Code UTC System Time T1 Millisecs System Time T1

13 14 15 16 17 18 19 20 21 22 23 24
UTC System Time T2 Millisecs System Time T2 UTC System Time T3

25 26 27 28 29 30 31 32 33 34 35 36
Millisecs System Time T3 UTC System Time T4 Millisecs System Time T4

Figure 8. Structure
Figure 8. Structure of
of the synchronization (SYNC
the synchronization (SYNC CLK)
CLK) messages.
messages.

In type 99 messages,
messages,the theTimeStamps
TimeStampsofofthe the time
time of of sending
sending each
each phase
phase are are added
added to
to the
the frames until the four TimeStamps required for the calculations are
frames until the four TimeStamps required for the calculations are completed. These four completed. These
four
fieldsfields
are theare the TimeStamp
TimeStamp value invalue
UTCinformatUTC andformat and in milliseconds.
in milliseconds. Each occupies
Each of them of them
occupies 4 bytes.
4 bytes. The thirdThe
typethird type of message,
of message, SYNC CLK SYNC CLKisReturn,
Return, added to is return
added theto return
completethe
complete time sequence
time sequence to the Node to the Nodeit so
so that canthat it can perform
perform the calculations
the calculations by itself by
anditself
thusand
be
thus beadjust
able to able tothe
adjust
localthe local
time. The time.
delay Theanddelay
timeand drifttime drift respecting
respecting the RPI
the RPI Server Server
time are
time are calculated
calculated by equation by [1],
equation [1], theofmeaning
the meaning of whoseare
whose variables variables
in Figureare in Figure
9. For 9. For
the example
shown
the in theshown
example Figure in9, the
it gives us values
Figure of delayT
9, it gives us values = 60 ofms and drift
delayT = −and
= 60 ms 20 ms, that
drift means
= -20 ms,
the Node
that means has
that thea Node
delay ofhas20a ms so itofwill
delay have
20 ms sotoit advance
will haveits toTimer
advanceabout
its 20 ms. about
Timer
20 ms.
𝑇 = TT𝑑 =+ d𝑑1 + + d𝑑2 + d3
delay=T =
𝑑𝑒𝑙𝑎𝑦 𝑆𝑡 (−St𝑆𝑡 − 𝑁𝑡 − 𝑁𝑡
4 − St1 ) − ( Nt3 − Nt2 ) (1)
(1)
 𝑑
Sensors 2021, 21, x FOR PEER REVIEW 𝑑𝑟𝑖𝑓𝑡
dri f = 𝑁𝑡 + Nt23 +−d2T𝑆𝑡 − St4

tT =

Figure 9.9.Sequence
Figure Sequenceof synchronization between
of synchronization RPI Server
between RPIand one Node.
Server and one Node.

Since the transmission times of messages in a Wi-Fi network are inconsiste

when the higher the network traffic the worse are the times obtained, it is neces
implement methods that provide stability and a better approximation to the value
calculated times. For this purpose, an algorithm based on the Doze Mechanism [4
 Sensors 2021, 21, 3875 13 of 26

Since the transmission times of messages in a Wi-Fi network are inconsistent and
when the higher the network traffic the worse are the times obtained, it is necessary to
implement methods that provide stability and a better approximation to the values of the
calculated times. For this purpose, an algorithm based on the Doze Mechanism [49] was
implemented, which consists of two phases.

2.5.1. Synchronization, Phase 1

After 20 s when a connection is established between the RPI Server and a Node, a
sequence of 16 SYNC CLK Request-Reply-Return messages is started and all the TimeStams
of the messages are stored in a buffer. Then the 16 values of delay and drift are calculated
and the average of these values, mdelay and mDrift, is obtained. Then the delay and drift
values below the corresponding average are selected and stored in the buffers vectordmm
and vectorDmm, the rest are discarding the other values. The average of the selected
delay and drift values is recalculated obtaining DELAYM and DRIFTM. Finally, the local
clock reference is adjusted according to DELAYM and DRIFTM. With this method, those
Sensors 2021, 21, x FOR PEER REVIEW messages that for some reason have generated greater transmission delays and that can14 of 27
alter the calculated averages are discarded. In Figure 10, the flowchart of the algorithm
phase 1 is shown.

Figure 10. General flowchart of the delay and drift algorithm in phase 1.
Figure 10. General flowchart of the delay and drift algorithm in phase 1.
2.5.2. Synchronization, Phase 2
2.5.2. Synchronization, Phase
In phase two we try 2 the time reference synchronized with the RPI Server. For
to keep
this,
In Hello
phasemessages areto
two we try sent by the
keep the time
Nodes every 10synchronized
reference s, containing the TimeStamp.
with The For
the RPI Server.
this, Hello messages are sent by the Nodes every 10 s, containing the TimeStamp. The RPI
Server will collect and store the 16 TimeStamp values of the received Hello messages to-
gether with the reception time and will recalculate the DRIFTM value as it is done in phase
1. If DRIFTM is greater than 20, it will mean that it has an offset of 20 ms and therefore the
 Sensors 2021, 21, 3875 14 of 26

RPI Server will collect and store the 16 TimeStamp values of the received Hello messages
together with the reception time and will recalculate the DRIFTM value as it is done
in phase 1. If DRIFTM is greater than 20, it will mean that it has an offset of 20 ms and
therefore the local clock will be reset. Otherwise, it will continue calculating a new DRIFTM
value for each Hello received. At the time of a local clock reset, 16 new Hello messages
must be stored, which will take 160 s. This will be done while in Waiting Mode, i.e.,
without sampling.
In phase 2, it is differed whether the Node part is in Sampling Mode or not. If it is in
Sampling Mode and a Type = 6 frame is received, it means that we have a sample offset
with respect to the other Nodes. If the Node is ahead, it means that the number of samples
it is counting (numsample) and doing is higher than that of the other Nodes and therefore
we will have to subtract that number of samples from the rest, but if on the contrary we are
behind then we will have to advance the numsample counter. This action will imply that
in the buffer where the samples are stored there will be a jump and therefore the positions
that are skipped decided to remain with the value zero. It could have been decided to fill
ensors 2021, 21, x FOR PEER REVIEW it with the value of the last sample taken but it was decided to zero in order to detect the 15 of 27
synchronization instants.
In Figure 11, the flowchart of the algorithm phase 2 is shown.

Figure 11. General flowchart of the drift algorithm in phase 2.

Figure 11. General flowchart of the drift algorithm in phase 2.
Note that to have a first fine tuning of the local Timer, a calibration must be performed
for 12 or 24 h to calculate the value of the Timer_A0 Counter Register and send it to each
Note that the
Node with to have
messagea first fine tuning
Set Timer (Type = of the local
6, Code = 1). Timer,
Even so,athecalibration must
effect of drift willbe per-
formed for 12 or 24 h to calculate the value of the Timer_A0
remain, but minimized. Figure 12 shows the structure of the message. Counter Register and send it
to each Node with the message Set Timer (Type = 6, Code = 1). Even so, the effect of drift
will remain, but minimized. Figure 12 shows the structure of the message.

1 2 3 4 5 6 7 8
Origin Dest Type Code Value Register TimerA0
 Figure 11. General flowchart of the drift algorithm in phase 2.

Note that to have a first fine tuning of the local Timer, a calibration must be per-
Sensors 2021, 21, 3875 formed for 12 or 24 h to calculate the value of the Timer_A0 Counter Register and send15itof 26
to each Node with the message Set Timer (Type = 6, Code = 1). Even so, the effect of drift
will remain, but minimized. Figure 12 shows the structure of the message.

1 2 3 4 5 6 7 8
Origin Dest Type Code Value Register TimerA0

Figure 12.
Figure 12. Structure
Structure of
of the
theSet
SetTimer,
Timer,Sampling
SamplingTimer_A0.
Timer_A0.

The Nodes
The Nodes have
have aamain
mainclock
clockfrequency
frequencyofof8080
MHz
MHz and to to
and getget
thethe
sampling
samplinginterrupt
interrupt
to trigger every 10 ms, the Timer_A0 Counter register should be 800,000. In the
to trigger every 10 ms, the Timer_A0 Counter register should be 800,000. In the experimen- experi-
mentation
tation section
section we see
we will willhow
see how the Nodes
the Nodes do notdohave
not have the same
the same quartzquartz crystal
crystal fre-
frequency.
quency.
For the Sampling Mode, two methods were implemented for the maintenance of
For the SamplingofMode,
the synchronization two methods
the Node: were implemented
Stop-and-Go and Synchro. for the
Bothmaintenance of the or
can be activated
synchronization of the Node:
deactivated from the Web client. Stop-and-Go and Synchro. Both can be activated or deac-
tivated from the Web client.
2.5.3. Stop-and-Go Method
2.5.3. Stop-and-Go Method
This is the first method implemented to correct the effect of time drift. In Sampling
Mode, This is thedetected
it was first method implemented
that as to correct
time progressed, the effect
although theof local
time drift.
clocksInofSampling
each Node
Mode, it was detected that as time progressed, although the local clocks of each Node
were adjusted, a small deviation (drift) was accumulating. To readjust the sampling time
were adjusted, a small deviation (drift) was accumulating. To readjust the sampling time
intervals in all Nodes, this method was implemented. It consists of the Nodes themselves
intervals in all Nodes, this method was implemented. It consists of the Nodes themselves
stopping sampling at a certain number of samples defined in the Set Stop-and-Go message
stopping sampling at a certain number of samples defined in the Set Stop-and-Go message
(Type = 4) and when the RPI Server has received the message containing the last samples
(Type = 4) and when the RPI Server has received the message containing the last samples
from all the Nodes then immediately send the order to continue to the next block of samples.
This will cause the fastest Node to wait until the slowest Node has sent its samples to the
RPI Server, restarting all of them at the same time.

2.5.4. Synchro Method

In this mode the Nodes are continuously synchronized as the DRIFTM exceeds the
threshold above 20 ms. It is the same method as phase 2 but using the TimeStamp field
that incorporates the sample messages (Type = 2) that are received every second. In this
case the algorithm waits to store 16 TimeStamp values, which will take 16 secs, and then
starts calculating the DRIFTM in the same way as in phase 2, selecting the best values, and
at each reception of a type 2 message containing the samples. If the calculated DRIFTM
exceeds 20 ms, that is two samples of deviation, then a Set Timer-Delay Timer message
(Type = 6, Code = 5) containing the milliseconds of difference (DRIFTM) is sent from the
Server. When the Node receives the message, it replies with the Set Timer-Ack message
(Type = 6, Code = 1) and immediately adjusts its Sampling Timer according to the value
passed. The structure of the Set Timer messages is the same as that shown in Figure 10.

2.6. Save File System

In the web user-interface options of the Web client, we added the option to save the
samples received in the RPI Server and then download the files with an SCP client. These
files are automatically saved with the name “SAMPLES_DATE_TIME” where DATE is the
date and TIME is the time of creation of the new file. A file will be generated every 15 min
due to the size of the files. The content of the files is exactly the messages Type = 2, in
binary format to reduce the file size. Concretely, the size of these files will be 1435 KB for a
15 min recording.
There is also the option to create and save the Debug messages in text mode for later
analysis in case of failures.

2.7. User Interface of the Web Client

The Web client part (Figure 13) was also developed with JavaScript language. It
consists of a panel where the current signal is displayed, taking into account that only one
of every 10 samples received is displayed so as not to saturate the RPI Server or the Web
client. It is to display an approximation of the received signal. We can select to display only
the signal of a particular Node or a particular component. Another panel is the Options
panel where we find Debug, SaveData, Synchro and Stop-and-Go.
Sensors 2021, 21, 3875 16 of 26

Figure 13. User interface of the Web client.

From the web page, the number of Nodes can be configured, generating the objects
required for each Node. A panel was also designed to display a table with the important
data related to the current sampling block such as the start of the sampling, the number of
packets received, etc. Additionally, on the right side of the screen a panel was implemented
to display important system messages and configuration, as well as the statistics at the end
of a sampling block.

3. Results and Discussions

3.1. Technical Characteristics of the Designed Prototype
As a result of the present investigation, a seismic data acquisition prototype was
implemented with the following technical characteristics:
• Nodes:
- Power supply of 5 V, obtained from batteries or microUSB charger.
- Model used: LaunchPad CC3200.
- Serial CLI interface at 115200 bauds for monitoring and provisioning tasks.
- Connected to three-component sensor (e.g., 1-Hz Mark-L-4C3D).
- Consumption:
n 70 mA Mode Standby;
n 80 mA Mode Sampling;
n 140 mA pp on start.
• Raspberry Pi Server:
- Power supply through the microUSB charger.
- Model used: Raspberry Pi 3 Model B v1.2 [44].
- Location: In a network outlet.
- Installed services: SSH, NTP Server, NTP Client, SCP, Java, Apache, Node.js.
 Sensors 2021, 21, 3875 17 of 26

- Consumption:
n 320 mA normal operation;
n 450 mA pp on start.
Sensors 2021, 21, x FOR PEER REVIEW Figure 14 shows the prototype of the conditioning circuit connected to the LaunchPad
CC3200 backplane. The black connectors for the connection with the three-component
sensor are shown.

Figure
Figure 14.14. Conditioning
Conditioning circuitcircuit assembled
assembled into CC3200.
into Lanchpad Lanchpad CC3200.

The cost of each part of the installed system is detailed below:

The cost of each part of the installed system is detailed below:
• Nodes:
• Nodes:
- LaunchPad CC3200: EUR 55.44.
-- Conditioning
LaunchPad CC3200:
circuit: EUR 55.44.
EUR 43.51.
• - Server:
RPI Conditioning circuit: EUR 43.51.
• - Raspberry
RPI Server:Pi Kit: EUR 101.33.
For the experimentation part, two Nodes were used with a total cost of EUR 200.28.
- Raspberry Pi Kit: EUR 101.33.
3.2. Experiments
For the experimentation part, two Nodes were used with a total cost of EUR
In order to test the correct functioning of the synchronization and sampling processes,
a series of tests were performed in a two-floor house with Wi-Fi connectivity. The scenario
3.2. Experiments
developed is as follows: two Nodes were installed, one on the first floor and the other on
the opposite
In orderside of
tothe second
test floor. Each
the correct of them connected
functioning of thetosynchronization
different AP and withinand samp
the same LAN together with the RPI Server. The same output of the sinusoidal signal
cesses, a series of tests were performed in a two-floor house with Wi-Fi connecti
generator (Multicomp MP750064) was connected to each Node’s ADC1, which generates a
1scenario
Hz and 1.2developed
Vp signal, soisboth
as follows: twothe
Nodes receive Nodes were at
same signal installed, one on
the same time. the first floor
Therefore,
other on the opposite side of the second floor. Each of them
the signal obtained from the user interface of the Web client should be exactly the same. connected to differen
The first
within thething
same to do
LANis to perform
together a calibration
with thetoRPI determine the appropriate
Server. The samevalue for the
output of the si
counter register of Timer_A0, which is in charge of controlling the 10 ms sampling interval.
signal generator (Multicomp MP750064) was connected to each Node’s ADC1, wh
The initial test is related with starting synchronization. At the beginning of the
erates aprocess,
sampling 1 Hz and 1.2 Vpstart
the Nodes signal, so both
at different Nodes
times receive
and there the same
are delays signal
between 20 andat the sa
80Therefore,
ms from thethe signal obtained
beginning. It is due tofrom thethat
the fact user
the interface
transmission of times
the Web
of theclient
packetsshould b
inthe
thesame.
network are different because some Nodes are further away from the RPI Server
than others. To ensure
The first thing thattoall
doNodes
is tostart at the same
perform instant, each
a calibration toNode was configured
determine the appropria
to start sampling at the beginning of the next second, that is when Timer_A0 triggers its
for the counter register of Timer_A0, which is in charge of controlling the 10 ms s
interrupt, when MilliTimeStamp is 000. If the Nodes are completely synchronized using
interval.
the implemented techniques, that means that the Nodes have almost the same time and
The initial
their Timers_A0 test almost
trigger is related withand
in unison, starting synchronization.
therefore At the
they will start almost beginning
at the same of
time. This was designed to avoid delays or differences in the sampling
pling process, the Nodes start at different times and there are delays between 2 times between the
Nodes, or at least that they are as small as possible. Figure 15 shows the initial phase shift
ms from the beginning. It is due to the fact that the transmission times of the p
of the same signal (1 Hz sinusoidal signal) at the two Nodes.
the network are different because some Nodes are further away from the RPI Ser
others. To ensure that all Nodes start at the same instant, each Node was confi
start sampling at the beginning of the next second, that is when Timer_A0 tri
interrupt, when MilliTimeStamp is 000. If the Nodes are completely synchroniz
Sensors 2021, 21, 3875 18 of 26
Sensors 2021, 21, x FOR PEER REVIEW 19 of 27

Figure 15. Start delay between Nodes: (a) without synchronized start, (b) with synchronized start.

synchronization were
After that, the time drift and the permanency of the synchronization were analyzed.
analyzed.
The result of the 24 h register is shown in Table 22 where
where the time difference between the
the time difference between
two Nodes for the same block of samples (24 h) can be
two Nodes for the same block of samples (24 h) can be observed. Node 1
observed. Node 1 (5048
(5048 ms
ms of
of
excess) samples slower than Node 2 (4292 ms of excess) and in turn both take longer than
excess) samples slower than Node 2 (4292 ms of excess) and in turn both take longer than
the stipulated
the stipulated time.
time.

2. Results of 24h register

Table 2.
Table register calibration
calibration with
with default
default values.
values.

RX: NODE
NODE22SAMPLE
SAMPLE TIMER
TIMER VALUE
VALUE = 800,000
= 800,000
Total Block Samples: 8640,000
Total Block Samples: 8640,000
Last Received Sample: 8640,000
Last Received Sample: 8640,000
Start Block Time: 2021-1-20 19:58:26.219
Start BlockTime:
End Block Time: 2021-1-20
2021-1-21 19:58:26.219
19:58:30.511
End
TotalBlock Time:86,404,292
Block Time: 2021-1-21ms19:58:30.511
PKT RX:
Total 86,400
Block Time: 86,404,292 ms
PKT LOST: 0
PKT RX: 86,400
LOST: 0%
PKT LOST: 0
RX: NODE 1 SAMPLE TIMER VALUE = 800,000
LOST: 0%
Total Block Samples: 8640,000
RX:
Last NODE
Received 1 Sample:
SAMPLE TIMER VALUE = 800,000
8640,000
Total BlockTime:
Start Block Samples: 8640,000
2021-1-20 19:58:26.212
End Block
Last Time:Sample:
Received 2021-1-218640,000
19:58:31.260
Total Block Time: 8,6405,048 ms
Start Block Time: 2021-1-20 19:58:26.212
PKT RX: 86,400
End
PKT LOST: 0Time: 2021-1-21 19:58:31.260
Block
Total
LOST:Block
0% Time: 8,6405,048 ms
PKT RX: 86,400
PKTWith
LOST: 0 results the calculations for the new values for the counter register of
these
LOST: 0%give us the following:
Timer_A0
- Nodo 1: counter_reg = 799,951;
With these results the calculations for the new values for the counter register of
- Nodo 2: counter_reg = 799,965.
Timer_A0 give us the following:
The results obtained from a new 24 h register is shown in Table 3.
- Nodo 1: counter_reg = 799,951;
- Nodo 2: counter_reg = 799,965.
The results obtained from a new 24 h register is shown in Table 3.

Table 3. Results of 24 h register calibration with new values of the Timer_A0 counter.

RX: NODE 1 SAMPLE TIMER VALUE = 799,951

Total Block Samples: 8,640,000
Last Received Sample: 8,640,000
Sensors 2021, 21, x FOR PEER REVIEW

Sensors 2021, 21, 3875 Start Block Time: 2021-3-31 11:08:23.041 19 of 26

End Block Time: 2021-4-1 11:08:22.998

Total Block Time: 86,399,957 ms
Table 3. Results of 24 h register calibration with new values of the Timer_A0 counter.
PKT RX: 86,400
RX: NODE PKT LOST:TIMER
1 SAMPLE 0 VALUE = 799,951
Total Block Samples: 8,640,000
LOST
Last Received : 0% 8,640,000
Sample:
RX:Block
Start NODE Time:22021-3-31
SAMPLE TIMER VALUE = 799,965
11:08:23.041
End Block Time: 2021-4-1 11:08:22.998
Total
Total Block Time:Block Samples:
86,399,957 ms 8,640,000
PKT RX: Last
86,400Received Sample: 8,640,000
PKT LOST: 0
LOST: 0%Start Block Time: 2021-3-31 11:08:23.024
RX: NODE End Block TIMER
2 SAMPLE Time:VALUE2021-4-1 11:08:23.101
= 799,965
Total Block Time: 86,400,077 ms
Total Block Samples: 8,640,000
Last Received Sample: 8,640,000
PKT
Start Block RX:
Time: 86,400
2021-3-31 11:08:23.024
End BlockPKT
Time:LOST:
2021-4-1011:08:23.101
Total Block Time: 86,400,077 ms
LOST: 0%
PKT RX: 86,400
PKT LOST: 0
LOST:With
0% these new values, the sampling frequency does adjust more accurate
Hz.
With these 16
Figure newshows
values, thehowsampling
the twofrequency
Nodes does adjust
are more accurately
synchronized to 100they
when Hz. reach
Figure 16 shows how the two Nodes are synchronized when they reach sample
2,880,000,
2,880,000, i.e.,i.e., 8 h after
8 h after starting,
starting, with thewith the Stop-and-Go
Stop-and-Go method. Themethod. The next synchro
next synchronization
willtake
will take place
place afterafter 8 h,ati.e.,
8 h, i.e., at sample
sample 5,760,000.5,760,000.

Figure
Figure Sincronization
16.16. with Stop-and-Go.
Sincronization with Stop-and-Go.
If we look at the test log in Table 4 we can see how Node 2 reaches the sample 2,880,000
If we
at the 962 look at
ms instant the
and Nodetest1 does
log in
it atTable
the 54 4mswe canofsee
instant nexthow Node
second, 2 reaches
so there is a the
2,880,000
92 at the
ms lag. Then 962how
we see mstheinstant and send
two Nodes Node the1ACK
doesalmost
it at the
at the54same
ms time
instant of next se
(56 and
58 ms) meaning
there that lag.
is a 92 ms they sample
Then we almost
seeathowthe same time. Nodes send the ACK almost at t
the two
time (56 and 58 ms) meaning that they sample almost at the same time.

Table 4. Log of Stop-and-Go occurs.

2021-04-02, 06:09:16.962, STOP AND GO Node-2 Sample = 2,880,000, New v

5760000
2021-04-02, 06:09:17.054 RX(816) -> 1:0:2:1617336557038:2879901-2880000
 Sensors 2021, 21, 3875 20 of 26
Sensors 2021, 21, x FOR PEER REVIEW 21 of 27

Table 4. Log of Stop-and-Go occurs.

2021-04-02, 06:09:17.058 Send START to Node 2
2021-04-02, 06:09:16.962, STOP AND GO Node-2 Sample = 2,880,000, New value = 5,760,000
2021-04-02, 06:09:17.069
2021-04-02, 06:09:17.054 -> Receive
RX(816) ACK STOP AND GO code = 2—Node 2
-> 1:0:2:1617336557038:2879901-2880000
2021-04-02, 06:09:17.135
2021-04-02, 06:09:17.054, STOP->AND
Receive ACK Sample
GO Node-1 STOP =AND GO New
2,880,000, codevalue
= 2—Node 1
= 5,760,000
2021-04-02, 06:09:17.056 Send START to Node 1
2021-04-02, 06:09:17.058 Send START to Node 2
The final result of the 24 h recording with the Stop-and-Go method configured at 8 h
2021-04-02, 06:09:17.069 -> Receive ACK STOP AND GO code = 2—Node 2
is2021-04-02,
shown in06:09:17.135
Table 5, which shows
-> Receive ACKaSTOP
timeAND
lag of
GO93code
ms=for Node1
2—Node 1 and 83 ms for Node2 with
respect to the time it should have taken. The time lag between them is only 10 ms. Figure
17 shows theresult
The final signalofat
thethe
24 end of the recording
h recording observing method
with the Stop-and-Go a deviation with the
configured at 8Stop-and
h
Go method.
is shown in Table 5, which shows a time lag of 93 ms for Node1 and 83 ms for Node2
with respect to the time it should have taken. The time lag between them is only 10 ms.
Table
Figure5.17Results
showsofthe
24 signal
h withat
Stop-and-Go
the end of =the
8 h.recording observing a deviation with the
Stop-and-Go method.
RX: NODE 2 SAMPLE TIMER VALUE = 799,964
Table 5. Total
ResultsBlock
of 24 hSamples: 8,630,000
with Stop-and-Go = 8 h.
Last Received Sample: 8,640,000
RX: NODEStart2 SAMPLE
Block Time:TIMER VALUE =22:09:17.017
2021-4-1 799,964
Total Block Samples: 8,630,000
End Block
Last Received Sample:Time: 2021-4-2 22:09:17.256
8,640,000
Total
Start Block Block
Time: Time:
2021-4-1 86400239 ms
22:09:17.017
End Block
PKTTime:
RX:2021-4-2
86400 22:09:17.256
Total Block Time: 86400239 ms
PKT LOST: 0
PKT RX: 86400
LOST
PKT LOST: 0 : 0%
RX:
LOST: NODE
0% 1 SAMPLE TIMER VALUE = 799,951
RX: NODETotal Block Samples:
1 SAMPLE 8,640,000
TIMER VALUE = 799,951
Total Block
LastSamples:
Received 8,640,000
Sample: 8,640,000
Last Received Sample: 8,640,000
Start Block Time: 2021-4-1 22:09:17.041
Start Block Time: 2021-4-1 22:09:17.041
EndTime:
End Block Block Time:22:09:17.373
2021-4-2 2021-4-2 22:09:17.373
Total Block Time: ms
Total Block Time: 86,400,332 86,400,332 ms
PKT RX: 86,400
PKT RX: 86,400
PKT LOST: 0
LOST: 0%PKT LOST: 0
LOST: 0%

Figure 17.Final
Figure 17. Finalsignal
signal
in in
24 24 h register
h register withwith Stop-and-Go.
Stop-and-Go.

As for the second implemented method, Sinhcro, the test results show a better syn
chronization since the adjustments are more continuous and do not drag the drift in time
Table 6 shows the final result of the 24 h recording with the Sinchro method. The
Sensors 2021, 21, 3875 21 of 26

Sensors 2021, 21, x FOR PEER REVIEW 22 of 27

As for the second implemented method, Sinhcro, the test results show a better syn-
chronization since the adjustments are more continuous and do not drag the drift in time.
Table 6 shows the final result of the 24 h recording with the Sinchro method. The
difference
times between
improved the for
by 78% twoNode
Nodes is 13
1 (71 ms)ms and
and can be
almost seen
65% forinNode
Figure 18.ms),
2 (84 As seen in the
the signal
log, Node 1 was reset about seven times and Node 2 about 14 times.
difference between the two Nodes is 13 ms and can be seen in Figure 18. As seen in the log,
Node 1 was reset about seven times and Node 2 about 14 times.
Table 6. Results of 12 h with Sinchro.
Table 6. Results of 12 h with Sinchro.
RX: NODE 2 SAMPLE TIMER VALUE = 799,964
RX: NODETotal Block Samples:
2 SAMPLE 8,640,000
TIMER VALUE = 799,964
LastSamples:
Total Block Received Sample: 8,640,000
8,640,000
Start Block
Last Received Time:
Sample: 2021-4-2 23:41:41.023
8,640,000
Start Block
EndTime:
Block2021-4-2 23:41:41.023
Time: 2021-4-3 23:41:41.107
End Block Time:
Total 2021-4-3
Block Time:23:41:41.107
86,400,084 ms
Total Block Time: 86,400,084 ms
PKT RX: 86,400
PKT RX: 86,400
PKT0LOST: 0
PKT LOST:
LOST: 0%LOST: 0%
RX: NODE 1 SAMPLE
RX: NODE 1 SAMPLE TIMER
TIMER VALUEVALUE = 799,951
= 799,951
Total Block Samples:
Total Block Samples: 8,640,000 8,640,000
Last Received
Last Received Sample: 8,640,000
Sample: 8,640,000
Start Block
StartTime:
Block2021-4-2
Time: 23:41:41.037
2021-4-2 23:41:41.037
End Block
EndTime:
Block2021-4-3
Time: 23:41:41.108
2021-4-3 23:41:41.108
Total Block Time: 86,400,071 ms
Total Block Time: 86,400,071 ms
PKT RX: 86,400
PKT0RX: 86,400
PKT LOST:
LOST: 0%PKT LOST: 0
LOST: 0%

Figure18.
Figure 18.Final
Finalsignal
signalin
inRegister
Register24
24hhwith
withSinchro.
Sinchro.

The
Thecomparison
comparisonofofthethesignals
signalsrecorded
recorded in each of the
in each Nodes
of the shows
Nodes a correct
shows synchro-
a correct syn-
nization, especially
chronization, whenwhen
especially the developed
the developedSinchro method
Sinchro is used.
method is used.
In
In the
the tests
tests carried out,
out, there
therewere
wereperiods
periodsofoftime
timeininwhich
which network
network congestion
congestion oc-
occurred. This situation caused packet loss. The observed effects were
curred. This situation caused packet loss. The observed effects were delayed in the deliv- delayed in the
delivery of packets
ery of packets and and
eveneven momentary
momentary lossloss of connection
of connection withwith
thethe Nodes.
Nodes. When When packets
packets are
are delayed
delayed duedue to congestion,
to congestion, thisthis directly
directly affects
affects the the instantaneous
instantaneous calculation
calculation of the
of the DE-
DELAYM
LAYM and and TimeStamps
TimeStamps fields.
fields. ThisThis causes
causes the the
RPIRPI Server
Server to believe
to believe thatthat the Node
the Node time
time has been
has been mismatched
mismatched and and
sends sends
the the
orderorder to delay
to delay or advance
or advance thethe sampling
sampling instant
instant de-
depending on whether the difference is positive or negative. This action
pending on whether the difference is positive or negative. This action will cause the Node will cause the
Node to become
to become misaligned
misaligned with respect
with respect to theto the others
others andresult
and will will result
in lossinofloss of samples
samples in the
case of a delay command. Delay mismatches will occur more frequently when congestion
occurs. As for the situation of connection loss, while restarting, those samples captured
Sensors 2021, 21, 3875 22 of 26
Sensors 2021, 21, x FOR PEER REVIEW 23 of 27

Sensors 2021, 21, x FOR PEER REVIEW 23 of 27

in the
by case of aNode
the affected delaywill command.
be lost due Delay
to themismatches
impossibilitywillofoccur
beingmore
able tofrequently
send them. when
For
congestion occurs. As for the situation of connection loss, while restarting,
this reason, the LOST PKT field is indicated in the final results of the log, so that the user those samples
captured
can take itby the
into affected
account Node
and will besuch
can detect lost periods
due to the impossibility
by viewing of being log.
the generated ableThe
to send
Wi-
by theFor
them. affected
this Node will
reason, the be lost due
LOST PKT tofield
the impossibility
is indicated of the
in being able
final to send
results of them.
the Forso that
log,
Fi network is the most susceptible to congestion because it is a shared medium and the
thisuser
the reason,
canthe
takeLOST PKT
it into field isand
account indicated in thesuch
can detect final periods
results ofbythe log, so that
viewing the user log.
thecabling,
generated
channel bandwidth is much lower than that provided by copper or fiber
can take it into account and can detect such periods by viewing the generated log. The Wi-
so it is
The Wi-Fi to
necessary network
prevent is the
the APs
mostfromsusceptible
being to congestion because it is a shared medium and
saturated.
Fi network is the most susceptible to congestion because it is a shared medium and the
the channel
Once webandwidth
confirmed iswith
much lower
the signalthan that provided
generator byNodes
copperremain
or fibersynchronized
cabling, so it at is
channel bandwidth is much lower than that providedthat the
by copper or fiber cabling, so it is
necessary
all times and to prevent
maintain the APs from being saturated.
necessary to prevent thetheAPssampling
from being frequency
saturated.at 100 Hz, we connected the Nodes to the
Once
three-componentwe confirmed
sensors.
Once we confirmed
with
Figure
with
the19signal
shows
the signal
generator
Nodethat
generator
that the Nodes
2 connected
the Nodes to theremain
remain sensor synchronized
located at
synchronized outside at
all
on times
allthe and
second
times maintain the sampling frequency at 100 Hz, we connected
floor. the sampling frequency at 100 Hz, we connected the Nodes to the
and maintain the Nodes to the
three-component sensors.Figure
three-component sensors. Figure 1919 shows
shows Node
Node 2 connected
2 connected to thetosensor
the sensor
locatedlocated
outside outside
on the second floor.
on the second floor.

Figure 19. Node 2 with sensor at second floor.

Figure 19. Node 2 with sensor at second floor.
Figure 19. Node 2 with sensor at second floor.
Figure 20 shows in MATLAB the detailed sampled signals contained in one of the
Figure 20
Figure 20 shows
shows in MATLAB the
the detailed sampled
sampledsignals contained in one
oneofofthe
files generated by theinRPI
MATLAB
Server and detailed
with a duration signals
of contained
15 min. The fileincorresponds
files generated by the RPI Server and with a duration of 15 min. The file corresponds to
the files
to
generated
23 by the RPI Server and with a duration of 15 min. The file corresponds to 23 April
23April
April 2021 between17:45
2021 between 17:45and
and18:00
18:00
h. h.
TheThe peak
peak recorded
recorded by Node
by Node 1, located
1, located on theon the
2021 between
ground 17:45 and 18:00 h. The peak recorded by Nodedoor
1, located onsubsequent
the ground level,
ground level, corresponds to the opening of a motorized door and the subsequent foot- foot-
level, corresponds to the opening of a motorized and the
corresponds
steps to the opening of a motorized door and the subsequent footsteps of people.
stepsofof people.
people.

Figure 20. Example of 15 min.

Figure 20. Example of 15 min.

Sensors 2021, 21, 3875 23 of 26
Sensors 2021, 21, x FOR PEER REVIEW 24 of 27

Figure
Figure21
21shows
showsthe thepower
powerspectral
spectraldensity
densityofofthe
thetwo
twoNodes
Nodesmonitoring
monitoringthe thebuilding
building
(Figure
(Figure20):
20):Node
Node1 1located
locatedininthe ground
the ground floor; Node
floor; Node2 located
2 locatedin the second
in the floor.
second Channel
floor. Chan-
1nel
of the two Nodes corresponds to the Horizontal-Longitudinal component;
1 of the two Nodes corresponds to the Horizontal-Longitudinal component; channel channel 2 to the2
Horizontal-Transverse component; channel 3 corresponds to the Vertical
to the Horizontal-Transverse component; channel 3 corresponds to the Vertical compo- component. The
Horizontal-Transverse component of
nent. The Horizontal-Transverse Node 2 clearly
component shows
of Node a peak at
2 clearly 9.03 Hz
shows corresponding
a peak at 9.03 Hz
tocorresponding
the resonanceto frequency of thefrequency
the resonance building. According to theAccording
of the building. study of Vidal etstudy
to the al. [50]of(p. 8),
Vidal
the relationship
et al. between
[50] (page 8), the periodbetween
the relationship of the building (T)ofand
the period the the number
building (T) of
and floors (N) is
the number
fulfilled,
of floorsbeing
(N) is for our particular
fulfilled, being forcase
our of 0.11 s (Tcase
particular = 0.054*N),
of 0.11 s corresponding to 9.09 Hz as
(T = 0.054*N), corresponding
reference value of Vidal et al. [50].
to 9.09 Hz as reference value of Vidal et al. [50].

Figure21.
Figure 21.Power
Powerspectral
spectraldensity
densityofofthe
therecordings
recordingsshown
shownininFigure
Figure20.
20.

Finally,the
Finally, theaccuracy
accuracy ofof the
the acquisition
acquisition system
system waswas analyzed.
analyzed. ForFor that,
that, twotwo continu-
continuous
signals of 700 and 1400 mV (value close to the maximum ADC voltage) were connectedcon-
ous signals of 700 and 1400 mV (value close to the maximum ADC voltage) were to
nected
the threetoinput
the three inputand
channels channels andrecordings
five 30-s five 30-s recordings were undertaken
were undertaken for each The
for each voltage. volt-
age. Thevalue
average average valueseries
of each of each series ofand
of records records and the corresponding
the corresponding number number
of counts ofby
counts
µV
by µV
were were calculated
calculated and compared
and compared with thewith the theoretical
theoretical value. Invalue.
TableIn7, Table 7, the obtained
the obtained results
results
are are The
shown. shown. Thepresents
system system presents
a maximum a maximum
deviationdeviation of 1.35%
of 0.70 and 0.70 andfor 1.35%
the halfforand
the
full
halfdynamic
and full range of the
dynamic ADC,
range respectively.
of the ADC, respectively.

Table7.7.Experimental
Table Experimentalaccuracy
accuracyresults
resultsofofthe
thedata
dataacquisition
acquisitionsystem.
system.

Input DCInput DC signal

signal (mV) (mV) 700 700 1400 1400
Sampling Sampling
rate (Hz) rate (Hz) 100 100 100 100
Dynamic Dynamic
range (bits) range (bits) 12 12 12 12
Theoretical value of one count (µV/counts) 358.15 358.15
Theoretical value of one count (µV/counts) 358.15 358.15
NS channel (µV/counts) 360.70 363.00
NS deviation from NS channelvalue
theoretical (µV/counts)
(%) 0.70
360.70 1.35 363.00
EW NS deviation
channel from theoretical value (%)
µV (µV/counts) 360.61 0.70 362.94 1.35
EW deviation from
EW theoretical
channel µV value (%)
(µV/counts) 0.68 360.61 1.34 362.94
Z channel µV (µV/counts) 360.57 362.94
EW deviation
Z deviation fromvalue
from theoretical theoretical
(%) value (%)0.67 0.68 1.34 1.34
Z channel µV (µV/counts) 360.57 362.94
Z deviation from theoretical value (%) 0.67 1.34
Sensors 2021, 21, 3875 24 of 26

4. Conclusions
In this work, a wireless seismic data acquisition prototype was developed. The
designed system transmits the signal registered by the Nodes to a central server (RPI
Server) and allows displaying remotely the seismic signal in different web browsers at
the same time, all in real time. In the developed system, the RPI Server was programmed
with Node.js technology that receives the frames with the samples and saves them in files
or sends them to the client web browsers. In the developed web user interface, different
controls and objects were implemented to start and stop a log as well as different options.
Therefore, it is not necessary to have a person in the field to start/stop the capture of the
samples. From any place with Internet connectivity, it is possible to send the commands
and also to visualize the signals. Besides, it is also possible to download the log files for
further processing with a maximum waiting time of less than 15 min since the server
generates a file every 15 min.
Wi-Fi connectivity was used in the Nodes to be able to transmit the captured samples
in a reliable and orderly way, so it is necessary to have a Wi-Fi network deployed in
the working environment. The microcontroller chosen was the LaunchPad CC3200 as it
implements a chip to provide the Wi-Fi interface, which also has a 32-bit ARM chip.
The experiments were carried out in a two-story building with two Nodes and it was
found that the system is able to synchronize and adjust itself in time automatically in order
to correct delays and drifts.
The use of low power consumption and low-cost components was taken into account
in the development. The software and the programming of the different elements were
developed with open-source tools.

Author Contributions: J.A.J.-M. conceived and designed the prototype and performed the experi-
ments; J.A.J.-M. and J.J.G.-M. oversaw the development of the system and the tests, and wrote the
manuscript; J.L.S.-L. oversaw the manuscript. All authors have read and agreed to the published
version of the manuscript.
Funding: This study was funded by the European Union’s Horizon 2020 research and innovation
program under grant agreement No 821046, the Ministerio de Economía, Industria y Competitividad
through research project CGL2016-77688-R, by the Consellería de Participación, Transparencia,
Cooperación y Calidad Democrática de la Generalitat Valenciana, and by Research Group VIGROB-
116 (University of Alicante).
Institutional Review Board Statement: Not applicable.
Informed Consent Statement: Not applicable.
Data Availability Statement: Not applicable.
Acknowledgments: We are very thankful to Jaume Aragones Ferrero for his collaboration in the
design of the web font-end layout.
Conflicts of Interest: The authors declare no conflict of interest. The identification of the name of the
instruments’ manufacturers does not mean any endorsement of their products.

Abbreviations
It describes the abbreviations and variables used throughout this paper.
Abbreviations Description
SNR Signal noise ratio
WSN Wireless sensor networks
MQTT Message queuing telemetry transport
UDP User datagram protocol
TCP Transmission control protocol
RPI Raspberry Pi
SCP Secure copy protocol
NTP Network time protocol
CLI Command line interface
Sensors 2021, 21, 3875 25 of 26

UART Universal asynchronous receiver-transmitter

ADC Analogue to digital converter
WAP or AP Wireless access point
UTC Universal time coordinated
mTS Milliseconds time stamp
TS Time stamp
PTP Precision time protocol
SSH Secure shell
LAN Local area network
Variables Description
numtotalsamples Number of total samples in actual block register
countsamplespkt Number of samples included in frame to send
mdelay Average delay of 16 calculated values
mDrift Average drift of 16 calculated values
vectordmm Buffer with those values less than mdelay
vectorDmm Buffer with those values less than mDrift
DELAYM Average delay of the selected values
DRIFTM Average drift of the selected values

References
1. Panzera, F.; Lombardo, G.; Muzzetta, I. Evaluation of building dynamic properties through in situ experimental techniques and
1D modeling: The example of Catania, Italy. Phys. Chem. Earth. 2013, 63, 136–146. [CrossRef]
2. Seismic Instrumentation of Buildings. U.S. Geological Survey Open-File Report 00-157. Available online: https://nehrpsearch.
nist.gov/static/files/USGS/PB2006105373.pdf (accessed on 24 May 2021).
3. Trifunac, M.D.; Ivanovic, S.S.; Todoroyska, M.I. Apparent periods of a buildings: I. Fourier analysis. J. Struct. Eng. 2001, 127,
517–526. [CrossRef]
4. Trifunac, M.D.; Ivanovic, S.S.; Todoroyska, M.I. Apparent periods of a buildings: II. Time-frequency analysis. J. Struct. Eng. 2001,
127, 527–537. [CrossRef]
5. Clinton, J.; Bradford, S.C.; Heaton, T.H.; Favela, J. The observed wander of the natural frequencies in a structure. Bull. Seismol.
Soc. Am. 2006, 96, 237–257. [CrossRef]
6. Mucciarelli, M.; Gallipoli, M.R.; Ponzo, F.; Dolce, M. Seismic waves generated by oscillating buildings: Analysis of release test.
Soil Dyn. Earthq. Eng. 2003, 23, 255–262. [CrossRef]
7. Gallipoli, M.R.; Mucciarelli, M.; Ponzo, F.C.; Dolce, M.; D’Alema, E.; Maistrello, M. Building as a seismic source: Analysis of a
release test at Bagnoli, Italy. Bull. Seismol. Soc. Am. 2006, 96, 2457–2464. [CrossRef]
8. Kobayashi, H.; Midorikawa, S.; Tanzawa, H.; Matsubara, M. Development of portable measurement system for ambient vibration
test of building. J. Struct. Constr. Eng. 1987, 378, 48–56.
9. Mucciarelli, M.; Gallipoli, M.R. Damping estimate for simple buildings through non-parametric analysisof a single ambient
vibration recording. Ann. Geophys. 2007, 50, 259–266.
10. Oliveira, C.S.; Navarro, M. Fundamental periods of vibration of RC buildings in Portugal from in situ experimental and numerical
techniques. Bull. Earthq. Eng. 2009, 8, 609–642. [CrossRef]
11. Gallipoli, M.R.; Mucciarelli, M.; Vona, M. Empirical estimate of fundamental frequencies and damping for Italian buildings.
Earthq. Eng. Struct. Dyn. 2009, 38, 973–988. [CrossRef]
12. Çelebi, M.; Sanli, A.; Sinclair, M.; Gallant, S.; Radulescu., D. Real-Time Seismic Monitoring Needs of a Building Owner—And the
Solution: A Cooperative Effort. Earthq. Spectra 2004, 20, 333–346. [CrossRef]
13. Tiganescu, A.; Craifaleanu, I.G.; Balan, S.F. Short-Term Evolution of Dynamic Characteristics of a RC Building under Seismic and
Ambient Vibrations. In IOP Conference Series: Earth and Environmental Science; IOP Publishing: Bristol, UK, 2021; Volume 664,
p. 012105.
14. Salawu, O.S. Detection of structural damage through changes in frequency: A review. Eng. Struct. 1997, 19, 718–723. [CrossRef]
15. Xia, Y.; Hao, H. Statistical damage identification of structures with frequency changes. J. Sound Vib. 2003, 263, 853–870. [CrossRef]
16. Nakamura, Y. A method for dynamic characteristics estimation of subsurface using microtremors on the ground surface. Q. Rep.
Railw. Tech. Res. Inst. Jpn. 1989, 30, 25–33.
17. Field, E.H.; Jacob, K. The theoretical response of sedimentary layers to ambient seismic noise. Geophys. Res. Lett. 1993, 20–24,
2925–2928. [CrossRef]
18. Lermo, J.; Chávez-García, F.J. Are microtremors useful in site response evaluation? Bull. Seismol. Soc. Am. 1994, 84, 1350–1364.
19. Borcherdt, R.D. Effects of local geology on ground motion near San-Francisco- Bay. Bull. Seismol. Soc. Am. 1970, 60, 29–61.
20. Castro, R.R.; Mucciarelli, M.; Pastor, F.; Federici, P.; Zaninetti, A. Determination of the characteristic frequency of two dams
located in the region of Calabria, Italy. Bull. Seismol. Soc. Am. 1998, 88, 503–511.
21. Parolai, S.; Facke, A.; Richwalski, S.M.; Stempniewski, L. Assessing the vibrational frequencies of the Holweide hospital in the city
of Cologne (Germany) by means of ambient seismic noise analysis and FE modelling. Nat. Hazard. 2005, 34, 217–230. [CrossRef]
Sensors 2021, 21, 3875 26 of 26

22. Acunzo, G.; Fiorini, N.; Mori, F.; Spina, D. Modal mass estimation from ambient vibrations measurement: A method for civil
buildings. Mech. Syst. Sig. Process. 2018, 98, 580–593. [CrossRef]
23. Sercel-Unite. Available online: https://www.sercel.com/products/Pages/unite.aspx (accessed on 10 November 2020).
24. Sigma System. Available online: http://www.iseis.com/html/sigma (accessed on 10 November 2020).
25. INOVA. Available online: https://www.inovageo.com/ (accessed on 11 November 2020).
26. Pang, G.H.; Liu, T.T.; Lin, J.; Wang, W. A field experiment with self-developed broadband recorders and a preliminary characteris-
tic analysis of the data records. J. Geophys. Eng. 2018, 15, 2287–2296. [CrossRef]
27. Yin, Z.; Zhou, Y.; Li, Y. Seismic exploration wireless sensor system based on wi-fi and LTE. Sensors 2020, 20, 1018. [CrossRef]
28. Attia, H.; Gaya, S.; Alamoudi, A.; Alshehri, F.M.; Al-Suhaimi, A.; Alsulaim, N.; Al Naser, A.M.; Eddin, M.A.J.; Alqahtani, A.M.;
Rojas, J.P.; et al. Wireless Geophone Sensing System for Real-Time Seismic Data Acquisition. IEEE Access 2020, 8, 81116–81128.
[CrossRef]
29. Picozzi, M.; Milkereit, C.; Parolai, S.; Jaeckel, K.H.; Veit, I.; Fischer, J.; Zschau, J. GFZ wireless seismic array (GFZ-WISE), a wireless
mesh network of seismic sensors: New perspectives for seismic noise array investigations and site monitoring. Sensors 2010, 10,
3280–3304. [CrossRef] [PubMed]
30. Dai, K.; Li, X.; Lu, C.; You, Q.; Huang, Z.; Wu, H. A Low-Cost Energy-Efficient Cableless Geophone Unit for Passive Surface Wave
Surveys. Sensors 2015, 15, 24698–24715. [CrossRef] [PubMed]
31. Soler-Llorens, J.L.; Galiana-Merino, J.J.; Giner-Caturla, J.J.; Jauregui-Eslava, P.; Rosa-Cintas, S.; Rosa-Herranz, J.; Nassim
Benabdeloued, B.Y. Design and test of Geophonino-3D: A low-cost three-component seismic noise recorder for the application of
the H/V method. Sens. Actuators A Phys. 2018, 269, 342–354. [CrossRef]
32. Soler-Llorens, J.L.; Galiana-Merino, J.J.; Giner-Caturla, J.J.; Rosa-Cintas, S.; Nassim-Benabdeloued, B.Y. Geophonino-W: A wireless
multichannel seismic noise recorder system for array measurements. Sensors 2019, 19, 4087. [CrossRef]
33. Liu, K.; You, Q.; Wang, J.; Xu, X.; Shi, P.; Dai, K.; Huang, Z.; Wang, S.; Shi, Y.; Ding, Z. A New Cable-Less Seismograph with
Functions of Real-Time Data Transmitting and High-Precision Differential Self-Positioning. Sensors 2020, 20, 4015. [CrossRef]
34. Kafadar, O. A geophone-based and low-cost data acquisition and analysis system designed for microtremor measurements.
Geosci. Instrum. Methods Data Syst. 2020, 9, 365–373. [CrossRef]
35. Nastase, D.; Chaudhuri, S.R.; Chadwick, R.; Hutchinson, T.C.; Doerr, K.U.; Kuester, F. Development and Evaluation of a Seismic
Monitoring System for Building Interiors—Part I: Experiment Design and Results. IEEE Trans. Instrum. Meas. 2008, 57, 322–344.
[CrossRef]
36. Hou, S.; Yu, Y.; Zhang, H.B.; Mao, X.Q.; Ou, J.P. A SA-Based Wireless Seismic Stress Monitoring System for Concrete Structures.
Int. J. Distrib. Sens. Netw. 2013, 9, 978313. [CrossRef]
37. Valenti, S.; Conti, M.; Pierleoni, P.; Zappelli, L.; Belli, A.; Gara, F.; Carbonari, S.; Regni, M. A low-cost wireless sensor node for
building monitoring. In Proceedings of the 2018 IEEE Workshop on Environmental, Energy, and Structural Monitoring Systems
(EESMS), Salerno, Italy, 21–22 June 2018; pp. 1–6.
38. Sundararaman, B.; Buy, U.; Kshemkalyani, A.D. Clock synchronization for wireless sensor networks: A survey. AdHoc Networks
2005, 3, 281–323. [CrossRef]
39. Jornet-Monteverde, J.A.; Galiana-Merino, J.J. Low-Cost Conversion of Single-Zone HVAC Systems to Multi-Zone Control Systems
Using Low-Power Wireless Sensor Networks. Sensors 2020, 20, 3611. [CrossRef] [PubMed]
40. Soler-Llorens, J.L.; Galiana-Merino, J.J.; Nassim-Benabdeloued, B.Y.; Rosa-Cintas, S.; Zamora-Ortiz, J.; Giner-Caturla, J.J. Design
and implementation of an Arduino-based plug-and-play acquisition system for seismic noise measurements. Electronics 2019,
8, 1035. [CrossRef]
41. Households at Home. INE. Available online: https://www.ine.es/ss/Satellite?L=en_GB&c=INECifrasINE_C&cid=125995264533
2&p=1254735116567&pagename=ProductosYServicios%2FINECifrasINE_C%2FPYSDetalleCifrasINE (accessed on 24 May 2021).
42. Computer and Internet Use in the United States: 2016. U.S. Census Bureau. Available online: https://www.census.gov/content/
dam/Census/library/publications/2018/acs/ACS-39.pdf (accessed on 24 May 2021).
43. Texas Instruments. CC3200 Launch Pad. Available online: http://www.ti.com/document-viewer/CC3200/datasheet/ (accessed
on 2 January 2020).
44. Raspberry Pi. Available online: https://www.raspberrypi.org/products/raspberry-pi-2-model-b (accessed on 7 January 2020).
45. Node.js. Available online: https://nodejs.org/en/ (accessed on 24 November 2020).
46. WebSockets. Available online: https://www.npmjs.com/package/websocket (accessed on 26 November 2020).
47. Highcharts. Available online: https://www.highcharts.com/docs/index (accessed on 23 December 2020).
48. Technical Committee on Sensor Technology. IEEE Std 1588-2008, IEEE Standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems; IEEE: New York, NY, USA, 2008; Volume 2008.
49. Cui, W.; Zheng, Z.; Qiao, L.; Zhang, W.; Wang, L. An improved TPSN algorithm based on doze mechanism. In Proceedings of the
2nd IEEE International Conference on Energy Internet, ICEI 2018, Beijing, China, 21–25 May 2018; pp. 230–234.
50. Vidal, F.; Navarro, M.; Aranda, C.; Enomoto, T. Changes in dynamic characteristics of Lorca RC buildings from pre- and post-
earthquake vibration data. Bull. Earthq. Eng. 2014, 12, 2095–2110. [CrossRef]