## 3 Results
### Packet Assembling and Sending Times  
In the second phase of our experiments, we measured the time required to assemble packets and send them to the Wi-Fi module via the SPI bus (see Figures 1 and 4). The tests were conducted by incrementally increasing the sensor sampling frequency to predefined values of 100, 200, 500, 1000, 1500, and 2000 Hz, which are some of the common frequencies used in applications. If a device failed to function correctly at any of these frequencies, we decreased the frequency in steps of 50 Hz to determine the highest stable sensor sampling frequency. It is important to note that the sensor sampling frequency in this phase should not be confused with the I\({}^{2}\)C bus frequency discussed in Section 3.2. The main results of these measurements are presented in Table 2. It lists the maximum sampling frequency achieved, and the mean times for packet assembly and sending packets across all four tested wearable devices. The data are shown for different numbers of sensor samples per packet, assembled in three different ASCII formats. We performed five measurements for each combination of the independent parameters, which are sampling frequency, number of samples in a packet, and ASCII representation of the values on each of the four devices. This means that for all the results presented in this section, we had twenty measurements from which we calculated the means and standard deviations. We would like to emphasize that the results presented in Table 2 show the maximum achieved sampling frequency that answers our research question, but these are not necessarily the sampling frequencies normally used in applications. Table 2 clearly shows the differences resulting from the different functions and formats used to calculate and represent the measured 16-bit and 32-bit integer values in ASCII format, as required by the UDP protocol in the Arduino library. We employed two data formats--decimal and hexadecimal--and utilized three different functions for converting integer values to ASCII format. The values shown in the upper part of the table correspond to the decimal ASCII representation, while the values in the middle and lower part of the table represent hexadecimal ASCII formats. The decimal conversion (indicated by D) was performed using Arduino's built-in snprintf() function. For the hexadecimal conversion, we used custom-developed functions: the basic function decToHexMeasurements() (indicated by H) and the optimized function konvHex16() (indicated by HS). \begin{table}
\begin{tabular}{c c c c c} \hline \hline  & \multicolumn{4}{c}{**Mean Cumulative Sensor Read Time [ms]**} \\ \hline
**f\({}_{\text{wire}}\) [kHz]** & **Device A** & **Device B** & **Device C** & **Device D** \\ \hline
100 & 2.640 & 2.680 & 2.650 & 2.640 \\
300 & 0.972 & 1.004 & 0.976 & 0.972 \\
500 & 0.642 & 0.676 & 0.646 & 0.640 \\
1000 & 0.397 & 0.432 & 0.404 & 0.397 \\
1500 & 0.317 & 0.350 & 0.322 & 0.317 \\
1600 & 0.305 & 0.338 & 0.313 & 0.306 \\
1700 & 0.296 & 0.330 & N/A & 0.297 \\
1800 & 0.286 & N/A & N/A & 0.286 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Mean sensor reading times (cumulative for magnetometer, accelerometer, and gyroscope) for four devices at varying I\({}^{2}\)C bus frequencies. N/A marks indicate that the communication was unstable for the device at that particular frequency. The decimal representation of the sensor values is not optimal, but it is very useful for the prototypes, and first tests, and sufficient for all applications with low sampling frequency. Using the hexadecimal representation results in shorter packets for the same number of samples compared to the decimal representation. In the decimal representation, 1, 2, 5, and 10 samples in a packet result in a payload size of 138, 276, 690, and 1380 bytes, respectively. In hexadecimal representation, 1, 5, 10, and 26 samples in a packet result in a payload size of 53, 265, 530, and 1378 bytes, respectively. Table 2 contains the most important results but omits some potentially interesting details.