# Learning Swimming Techniques by Means of Real-Time Monitoring with Embedded Devices
## 2 Materials and Methods
### Software Analysis
#### 2.2.2 Slave Device  
Each slave device--Device_1, Device_2, and Device_3--is shown in Figure 4 and shares the same software implementation. This uniformity is due to the fact that each  
Figure 4: System architecture.  
device has a unique MAC address, which is identified by the master device to correctly assign data for the feedback panel.  
In terms of operating mode, the slave device is initialized with the Wi-Fi communication protocol. Since the master device utilizes ESP-NOW, the slave devices must also implement this protocol. The slave devices receive requests from the master device and execute the corresponding routine, which may be Calibration, Training, or Vote. Once the routine is completed, the slave sends feedback to the master.  
The core functionality of the slave device is managed by a state machine that prioritizes requests from the master. Whenever a Calibration, Training, or Vote routine is requested, any ongoing tasks are interrupted, and the corresponding logic for the requested routine is executed.  
Considering the power consumption of 150 mA from the ESP32 with continuous Wi-Fi operation and an additional 4 mA from the MPU6050 sensor, the total current draw amounts to 154 mA. Given a 500 mAh battery, the estimated operational time can be calculated as follows:  
\[\frac{500\;\mathrm{mAh}}{154\;\mathrm{mA}}\approx 3.24\;\mathrm{h} \tag{2}\]  
This duration is slightly lower than that of the master device but does not significantly impact system performance. Given the minimal difference, all device batteries can be recharged simultaneously, ensuring synchronized operation.  
Below are the main features of the slave device are described.  
1. Calibration Request  
It is essential to begin the readings from a controllable checkpoint, which requires calibration.  
This calibration process utilizes data from the sensor to compute an average set of values. The implementation involves reading the sensor every  
(3) Vote Request This is the most critical part of the system, as live gesture samples must be compared with the pattern stored during the recording phase.  
The logic behind this step relies on a precondition--the same movement detection condition used in the recording phase. Once this condition is met, the system can begin reading values from the sensor and evaluating the new input data.  
Several sub-features are incorporated into the voting routine. One of these is the \"standstill\" feature-- if the sensor is stationary at any time, a recalibration process is triggered. As the system is designed to monitor movement, a stationary state is interpreted as a new starting position. The recalibration process recalculates the acceleration readings and sets this new position as the origin. When executed, the recalibration re-estimates the system's reference point based on the updated acceleration values.  
Motion detection in this phase differs slightly from that in the training routine. During each reading, the system checks whether the values differ from the standstill values. If there is a change, the new values are stored, and the algorithm proceeds to compare the entire set of input data, adding the criteria that the first 10 sets (X, Y, Z) are in motion, out of the total 40 sets per sample.  
The reading phase is conducted similarly to the recording step, as the two data series need to be compared. Thus, the timing remains unchanged: 40 sets of values are read every 50 ms, totaling 2 s for each gesture.  
Afterward, the system engages in an algorithm that outputs a similarity score based on how closely the gesture matches the stored pattern (the recorded mean). Two algorithms are employed for this verification: the Dynamic Time Warping (DTW) algorithm and the Pearson Correlation Coefficient (PCC); used in separate test.