###### Abstract
NTP synchronization offers the advantage of leveraging existing network infrastructure, eliminating the need for additional hardware investments. It enables the synchronization of clocks across diverse devices, including computers, servers, and IoT devices. However, it is crucial to acknowledge that network disruptions or NTP server downtime can impact synchronization reliability. Additionally, network delays, packet loss, or congestion may affect synchronization accuracy. For a comprehensive comparison between NTP and PTP, an in-depth analysis can be found in [42]. In the scope of this research, NTP was selected as the preferred methodology for clock synchronization, primarily due to its straightforwardness and convenient implementation process that obviated the need for supplementary hardware clocks. The analysis presented in Table 1 provides a comprehensive summary of the clock modules and wireless technologies employed in the relevant studies. It is important to note that the abbreviation \"N/A\" in Table 1 indicates that the number of end nodes participating in the synchronization test was not provided or specified. The authors conducted a series of experiments to continuously retrieve time information from an NTP stratum 1 server using the ntplib library on a Raspberry Pi. The experimental procedure, described in Algorithm A1, involved performing a total of 100 measurements, repeated 10 times. However, five out of the ten experiments exhibited instability, indicating that ntplib is not robust for capturing the entire time axis in correlation with MEMS sensor vibration capture. The results of these experiments are summarized in Table A1 and visualized in Figure A1. Furthermore, each experiment revealed a time difference of approximately 2 s or more based on 100 readings from NTP. This corresponds to a sampling rate of approximately 50 Hz or less, which is insufficient for capturing the desired level of detail in the vibration data. The deployment of a low-cost vibration-based SHM sensor network presents inherent challenges that need to be addressed. Although, Ref. [44] provides comprehensive details about the hardware and source code of the system in an open repository, there are still \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Reference** & **Clock Module** & **Wireless Technology** & **Number of End Nodes** \\ \hline
[33] & GPS 1 & LoRa 2 & 2 \\ \hline
[34] & GPS 1 & TCP/IP 3 via Wi-Fi and 4G & 5 \\ \hline
[35] & GPS 1 & NB-IoT 5 & 10 \\ \hline
[38] & NTP 4 & TCP/IP 3 via Wi-Fi & 2 \\ \hline
[39] & NTP 4 & 4G & N/A \\ \hline
[40] & NTP 4 & MQTT 6 broker and 4G & N/A \\ \hline
[41] & NTP 4 & 4G & N/A \\ \hline
[43] & NTP 4 & 4G & N/A \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Summary of time module of the related works. limitations in terms of transmission and local storage. Another major challenge arises from the need for simultaneous data collection from multiple sensors, especially at a high sampling rate exceeding 100 Hz, which is typical for vibration-based monitoring. Consequently, this results in the generation of large volumes of data, especially when considering the data recorded by multiple sensors on a given structure. Technical obstacles, such as data synchronization between nodes, network scalability, and efficient data transmission within the network, further compound the challenges. This study builds upon previous research in the field, drawing inspiration specifically from the works of [39; 40; 41; 43], which have provided valuable insights into the utilization of wireless sensor networks with NTP for synchronization purposes. Examining the findings presented in Table 11, we observe that this discrepancy results in a sampling rate of approximately 50 Hz or lower, which proves insufficient for capturing the desired level of detail in the vibration data. It is evident that relying solely on an NTP stratum 1 server may not ensure the robustness necessary to establish a dependable time axis for vibration-based monitoring.