## 4 Discussion  
In this study, we conducted comprehensive tests using wearable devices specifically assembled for research in various biomechanical applications within sports and physical rehabilitation [22]. These applications span a wide range of actions with differing requirements: some necessitate low sampling frequencies and minimal streaming latency, while others demand high temporal resolution (i.e., high sampling frequencies) and can tolerate greater latency [16]. This section discusses factors that could enhance the performance and usability of the presented systems. It should be reiterated that the primary research objective of this study is the maximum sensor sampling frequency that can be supported by a given wearable device in streaming mode [3]. For this reason, we did not take any measures to mitigate packet loss in the wireless Wi-Fi connection. Some RTBF applications are highly insensitive to packet loss and do not require any measures to mitigate this loss. For applications that require reliable data transmission, additional tasks need to be implemented on the wearable device, lowering the highest achievable sampling frequency determined in our experiments. The reduction depends on the complexity of the data loss mitigation measures and protocols, but the detailed study of these measures is outside the scope of this paper. In this study, we did not consider the possible differences between the output rates of the sensor data and the sampling frequency of the device. While the former is a property of the sensor [19; 20] and is controlled by its registers, the latter depends on the settings of the periodic scheduler. For our results, it does not matter if there is a discrepancy between the two, as we only measure the capabilities of the wearable device, which depend on its sampling frequency. For real applications, the output data rate of the sensor and the sampling frequency of the device must be adjusted and set correctly. Optimizing the representation of sensor sample values in ASCII format for the UDP protocol is also crucial. By reducing the number of characters required for data representation, we increased the number of sensor samples that can be included in a single packet. The Wi-Fi protocol standard imposes a payload limit of approximately 1500 bytes, including IP and UDP headers. Considering these constraints, two options are available: (a) a decimal representation requires 138 bytes per sample and allows a maximum of 10 samples per packet and (b) a hexadecimal representation requires 53 bytes per sensor sample; therefore, a packet can hold up to 26 samples. Decimal representations are suitable for simple applications with low sampling frequencies of up to a few hundred hertz. Hexadecimal representations are required for demanding applications with high sampling frequencies or applications with additional processing load on the microcontroller. We have used UDP at the transport layer of the communication protocol stack for several reasons: it is lightweight, has low overhead, high throughput, and is very suitable for low-latency data transmission in real-time applications [23]. However, UDP is also unreliable and suffers from packet loss [24]. While the advantageous features of UDP match well with the requirements of our RTBF applications, its disadvantages may affect some of the applications. This depends on the functions and requirements of the applications. It should be noted that many RTBF applications allow some degree of packet loss, so the disadvantages do not seriously affect them. However, if the application requires reliable data transmission, mitigation measures must be taken at higher protocol levels or within the application [23; 25]. Such measures inevitably require additional processing on the microcontroller, which decreases the maximum achievable performance as measured in this paper.