## 4 Discussion
The results demonstrate that our wearable device, coupled with the developed scheduler, offers numerous combinations of sampling frequencies and packet delays, along with flexibility in payload formats. The optimal configuration depends on the specificrequirements of the intended application. When assembling packets with multiple sensor samples, the packet delay at the receiver comprises the product of the number of samples and the sampling period, plus the time required to send the packet from the Wi-Fi module to the receiver (measured in milliseconds). The following three examples illustrate this. Maximizing Sampling Frequency: To achieve the highest possible sampling frequency, the maximum number of sensor samples per packet should be used, effectively utilizing the microcontroller's processing capacity. However, this approach results in increased packet delay at the receiver. For instance, at a sampling frequency of 1750 Hz with 26 samples per packet, the packet delay exceeds 15 ms. Minimizing Receiver Delay: If minimizing delay at the receiver is paramount, transmitting one sample per packet is preferable. This configuration is feasible up to 650 Hz using hexadecimal representation and up to 450 Hz using decimal representation, with expected receiver delays of only a few milliseconds. Intermediate Scenarios: Other configurations fall between these extremes. For example, as shown in Figure 11, at a sampling frequency of 100 Hz with 10 samples per packet, the receiver delay exceeds 100 ms. This is because the system must collect 10 samples (taking slightly more than 90 ms) before the packet can be transmitted. Developers of RTBF applications [16] or other systems employing such wearable devices with a scheduler now have multiple options at their disposal. In scenarios requiring maximum sampling frequencies or minimal receiver delays at the highest achievable frequencies, the microcontroller's computing resources are almost entirely dedicated to data streaming. By avoiding these extreme cases, additional processing power remains available for other tasks unrelated to streaming, which may be necessary for the application's successful operation [1; 22]. To relate these figures to the application-specific requirements of RTBF applications, we divide them into three groups: low, medium, and high, depending on the required sampling frequency. The first group with low sampling frequency includes the streaming of motion signals with low dynamics and/or physiological parameters. An example of such an application is [18], where the sampling frequency was 64 Hz. Other examples from this group are gait and balance analysis, rehabilitation applications [2; 16], and others. For this group, we can use practically any combination from Table 2. The group of medium sampling frequencies includes sports and rehabilitation applications with medium to high dynamic movements, with required frequencies from 100 Hz to 500 Hz [1]. These include various movements of the human body in different sports such as running, swimming, golf, skiing, and others [16]. For this group of applications, developers need to make a decision on the right combination of sampling frequency and number of samples in a packet, depending on the timing requirements of the application. If low delay is critical, fewer samples per packet are acceptable. For example, if the sampling frequency must be at least 500 Hz and the delay at the receiver must be less than 10 ms, we can only put five or fewer samples in a packet. The high sampling frequency group deals with frequencies above 500 Hz. Applications include human movements, often in combination with sports equipment, with very high dynamics and with impacts. Examples of such movements are skiing, ice skating, rugby, and others [16]. The aim here is to capture transient phenomena in movements that involve multiple joints or impacts of body parts and/or equipment and where the time spans are very short, sometimes less than 1 ms [7; 11; 15; 22].