Portable IoT Device with Embedded Machine Learning for Real-Time Heart-Rate and SpO₂ Vital-Sign Monitoring and Classification

Continuous monitoring of vital signs is a cornerstone of preventive and acute clinical care, enabling early detection of cardiovascular and respiratory deterioration [1]. Universal access to simple measurements such as heart rate and peripheral oxygen saturation (SpO₂) has been identified as a priority in regions where hospital infrastructure and specialized equipment remain scarce [1], and the broader literature on wearable sensor-based health monitoring has long emphasized the need for low-cost biomedical instrumentation that remains accurate while operating outside controlled clinical environments [2]. The emergence of integrated photoplethysmographic sensors, such as the MAX30102, has enabled the development of compact, low-cost wearable devices suitable for home and field use [3], while their pairing with Wi-Fi/Bluetooth-enabled microcontrollers such as the ESP32 has facilitated wireless transmission and remote management of biomedical data within Internet of Things (IoT) ecosystems [4, 5].

In many middle- and low-income countries, access to continuous vital-sign measurement devices is constrained by cost and technical complexity, a gap extensively documented in reviews of IoT-based healthcare-monitoring systems [6]. This gap is particularly relevant in Peru, where national health-survey data report that 14.2% of the population aged 15 years and older presented elevated blood pressure readings in 2024, with several regions exceeding 16% [7], underscoring the need for accessible cardiovascular screening tools that can operate outside specialized clinical settings. A portable, economical, and easy-to-use system that streams measurements to a remote platform addresses this gap by enabling preventive telemedicine and telemonitoring while reducing the dependency on dedicated hospital equipment, consistent with low-cost oximeter and IoT vital-sign monitoring proposals reported for similar contexts [8, 9], and aligns with the broader case made for smart-healthcare technologies and large-scale IoT patient-monitoring deployments [10, 11].

The general objective of this work is to design and implement a portable, low-cost device based on the ESP32 microcontroller and the MAX30102 sensor for the real-time monitoring of basic vital signs. The specific objectives are: (i) to develop the hardware architecture integrating the biometric sensor and a local display unit; (ii) to implement wireless connectivity for data transmission and cloud storage; (iii) to embed a compact machine learning classifier capable of mapping the acquired signals to descriptive physiological categories directly on the microcontroller; and (iv) to experimentally validate the accuracy of the optical measurements against a commercial pulse oximeter used as a reference device.

The measurement principle is based on photoplethysmography (PPG), a non-invasive optical technique that detects volumetric blood changes in tissue using red and infrared light, with adaptive filtering techniques commonly applied to improve heart-rate estimation from low-cost sensors [12], and digital signal-processing approaches remaining an active area of research for reducing motion and ambient-light noise in PPG acquisition [13]. The MAX30102 module integrates both emitters together with a photodetector, producing a signal from which heart rate and SpO₂ are derived after digital filtering. The ESP32 acts as the central processing unit, providing sufficient computational headroom, Wi-Fi/Bluetooth connectivity, and low power consumption, which together make it well suited for embedded biomedical IoT applications, as demonstrated by portable ESP32-based health-monitoring frameworks [14] and ESP32-based edge-computing architectures reported in the recent literature [15].

3.1 Research approach

The system was developed following a waterfall methodology comprising five sequential phases: requirements analysis, design, implementation, verification, and maintenance, which provided a structured and traceable development process well suited to a single-iteration hardware/firmware prototype, consistent with the development approach reported for comparable open-source IoT health-monitoring systems [3]. Each phase was completed and reviewed before the subsequent stage began, allowing early correction of design errors and consistent documentation of design decisions, in line with practices reported for other ESP32-based IoT device implementations [5].

3.2 Requirements analysis

Functional requirements specify that the device must: (i) measure heart rate and SpO₂ in real time; (ii) display results clearly on an integrated screen; (iii) transmit data through Wi-Fi/Bluetooth connectivity for later analysis; and (iv) remain portable and low-cost for use in domestic or rural settings. Non-functional requirements specify a minimum autonomy of six hours on a rechargeable battery, low energy consumption through efficient use of the microcontroller, a simple and intuitive user interface, and a compact, modular enclosure resistant to basic environmental conditions.

3.3 System architecture

The architecture is organized into five functional modules, following design principles for low-cost wearable cardiovascular monitoring systems reported in a previous study [16]: (1) a processing and communication module built around the ESP32 DevKit V1, responsible for signal processing, display control, and wireless data transmission; (2) a cloud back-end used for historical data storage, authentication, and the generation of alerts when critical thresholds are detected; (3) a data acquisition module comprising the MAX30102 optical sensor, which communicates with the microcontroller through the I²C bus; (4) a user-interface module composed of a 1.8-inch TFT display and a manual ON/OFF switch; and (5) a power module integrating a 3.7 V lithium-polymer battery, a TP4056 charging circuit, and a step-up/step-down voltage regulator. This modular separation of concerns follows recommendations for scalable embedded health-monitoring architectures, similar to ESP32-based wireless patient-monitor designs that separate sensing, processing, and communication layers [25], and allows future sensors, such as ECG front ends, to be integrated without redesigning the core firmware. Figure 1 summarizes the resulting block-level architecture and the interfaces connecting each module.

tu_pian_1.png

Figure 1. System architecture and module interconnections

3.4 Data flow

Upon power-up, the microcontroller initializes the I²C bus, configures the MAX30102 sensor, and attempts to join the configured Wi-Fi network. Once a finger is detected through an infrared-amplitude threshold, the sensor continuously samples red and infrared PPG signals; a peak-detection algorithm identifies systolic pulses and computes the inter-beat interval, from which heart rate is derived. Each valid beat triggers an SpO₂ estimate and a temperature reading, with continuous temperature monitoring being a recognized complementary indicator for early detection of physiological deterioration in wearable health devices [24], and the addition of a new sample to a rolling measurement session. Processed values are displayed locally and published to the cloud database through HTTP/REST calls. This acquisition-to-cloud pipeline mirrors validation methodologies reported for low-cost wearable vital-sign systems benchmarked against commercial reference devices [18], and the complete acquisition cycle repeats continuously while the device remains powered, minimizing latency between acquisition, processing, and remote visualization.

To specify the acquisition chain in the detail requested during review, the MAX30102 is configured with a sampling rate of 100 Hz (adequate for cardiac signals up to 180 bpm under the Nyquist criterion), an 8-sample internal averaging window to attenuate high-frequency noise, an LED pulse width of 411 μs, and a 12-bit ADC resolution (4096 counts). Finger presence is detected via a fixed infrared-amplitude threshold, below which no samples are processed. Beat detection uses a threshold-crossing peak-detection algorithm applied to the filtered PPG waveform: each detected systolic peak is timestamped, and the resulting inter-beat interval is converted to an instantaneous heart-rate estimate that is accepted only if it falls within a physiologically plausible range of 40–200 bpm, with out-of-range detections discarded as artifacts rather than propagated to the measurement session. This threshold-based scheme was chosen over a more elaborate adaptive filter, such as a Kalman or wavelet-based filter, for its low computational overhead on the ESP32; its robustness under motion artifacts, low-perfusion conditions, and varying skin pigmentation was not systematically characterized in this work, a limitation discussed further in Section 7.

3.5 Embedded classifier design

A compact neural network was integrated on-device using TensorFlow Lite for Microcontrollers, implementing embedded machine learning to provide a descriptive classification layer on top of the raw measurements. The network receives four input features: heart rate, SpO₂, MAX30102 sensor (auxiliary) temperature, and short-term heart-rate variability (computed as the standard deviation of the last ten beat-to-beat intervals), and maps them, through two dense hidden layers of 16 and 8 ReLU units with 20% dropout, to a five-class softmax output: normal, bradycardia, tachycardia, hypoxia, and an arrhythmia-like high-variability pattern. The complete model totals approximately 400 trainable parameters and requires a 10 KB static tensor arena, making it compatible with the memory budget of the ESP32.

Heart-rate variability is computed on-device using a two-pass algorithm over the circular buffer of the last N = 10 beat-to-beat intervals, and each of the four input features is normalized using a z-score transformation with fixed mean and standard deviation constants obtained during training (StandardScaler). The output layer applies the softmax function over the five output logits, and the predicted class is the index that maximizes the resulting probability (argmax), with the corresponding value reported on-screen as the confidence percentage. The formal definitions of these operations are given in Section 5.

The training dataset was synthetically generated rather than collected from real patients, using Gaussian and uniform distributions parameterized according to physiological ranges reported in the literature for each condition (60–90 bpm and 95–100% SpO₂ for the normal class; 100–130 bpm for tachycardia; 82–94% SpO₂ for hypoxia), producing 5000 balanced samples (1000 per class). This straightforward parameterized-distribution approach is considerably simpler than the more sophisticated synthetic-data generation methods described by Tucker et al. [17], but follows the same underlying motivation: producing usable training data for machine-learning healthcare software when access to large annotated clinical datasets is limited. The network was trained in Python with TensorFlow/Keras using the Adam optimizer, a sparse categorical cross-entropy loss, early stopping, and learning-rate reduction on plateau, for a maximum of 100 epochs. The trained model was subsequently quantized and converted into a C byte-array header file for direct inclusion in the ESP32 firmware, following the deployment workflow described for TinyML applications on microcontroller-class hardware [26]. It is important to note that this classifier is presented as a functional demonstrative module: it was exercised successfully on the physical prototype during live testing sessions, but a formal accuracy evaluation on an independent, held-out test partition was not performed at this stage; the full extent of this limitation and the corresponding validation plan are detailed in Section 6.3.

3.6 Communication model

The communication model follows a client-server architecture within the broader Internet of Things ecosystem, supported by the Wi-Fi connectivity of the ESP32. Processed heart-rate and SpO₂ values are transmitted via HTTP/REST to a cloud Realtime Database, where they are stored in a structured, queryable hierarchy. Communication is organized in three logical levels: at the acquisition level, the MAX30102 transmits PPG samples to the microcontroller over I²C; at the local-processing level, the ESP32 filters the signal and computes HR and SpO₂ using digital signal-processing algorithms; and at the external-communication level, processed data are published to the cloud and, when out-of-range values are detected, an instant notification can be issued to a companion messaging channel. HTTP/REST was favored over more specialized IoT messaging protocols for this prototype given its simplicity and broad library support, although a pragmatic comparison of IoT messaging protocols indicates that publish-subscribe alternatives may offer latency and overhead advantages at larger deployment scales [20]. A timeout-based fallback mechanism allows the device to continue local operation and on-screen display even if cloud authentication fails, which is a design requirement for biomedical devices that must remain functional under intermittent connectivity.

3.7 Hardware components and specifications

Table 1 summarizes the technical specifications of the microcontroller, and Table 2 summarizes the optical sensor used for signal acquisition. Component selection followed criteria of biometric accuracy, low power consumption, and ease of use reported as desirable for a non-specialized portable wearable device [3, 5]. Figure 2 and Figure 3 show the actual ESP32 DevKit V1 and MAX30102 modules used in the prototype assembly.

Table 1. ESP32 DevKit V1 technical specifications

Table 2. MAX30102 optical sensor specifications

tu_pian_2.png

Figure 2. ESP32 DevKit V1 microcontroller module

tu_pian_3.png

Figure 3. MAX30102 optical photoplethysmography (PPG) sensor module (GY-MAX30102)

Local visualization is provided by a 1.8-inch TFT display (ST7735 controller, 128 × 160 px) communicating with the microcontroller over SPI, while portable power is supplied by a 3.7 V lithium-polymer battery managed by a TP4056 charging module with overcharge, over-discharge, and short-circuit protection. Table 3 lists the complete bill of materials used to assemble the protoboard prototype.

To substantiate the "low-cost" characterization used throughout this paper, approximate unit prices for the components listed in Table 3 were obtained from public electronics marketplaces rather than from the authors’ own itemized purchase records, which were not retained during assembly: the ESP32 DevKit V1 (approximately US\$5–10), the MAX30102 module (approximately US\$3–8), the ST7735 TFT display (approximately US\$4–8), the TP4056 charging module (approximately US\$1–2), the 2000 mAh LiPo battery (approximately US\$5–10), and minor components including protoboard, wiring, and switch (approximately US\$3–5), together totaling approximately US\$21–43 in component cost at generic-marketplace pricing, before shipping, taxes, or labor. This range is offered as an order-of-magnitude estimate rather than an itemized project expenditure, and should be interpreted accordingly. For comparison, basic single-function commercial fingertip pulse oximeters, including Food and Drug Administration (FDA)-cleared models such as the Contec CMS50D used as the reference instrument in this work, are also available at retail prices in a broadly overlapping or in some cases lower range; the present prototype should therefore not be characterized as unambiguously cheaper than a basic commercial oximeter, but rather as adding capabilities that basic oximeters lack, namely wireless connectivity, cloud synchronization, an on-device classification stage, and automated alerting, at a broadly comparable component cost. A rigorous cost comparison would additionally need to account for the certification, calibration, and quality-assurance costs embedded in commercial medical-device pricing, which are not incurred by this uncertified prototype.

Table 3. Bill of materials

3.8 Physical connections

The MAX30102 sensor communicates with the ESP32 through the I²C bus using GPIO21 (SDA) and GPIO22 (SCL), while the TFT display uses the SPI interface, with chip-select, data/command, and reset control lines mapped to separate GPIOs. All modules share a common 3.3 V supply rail and ground plane on the protoboard. This wiring scheme allowed validation of every subsystem before transition to a dedicated enclosure. Figure 4 shows the assembled prototype, including the ESP32 microcontroller, the MAX30102 sensor module, and the TFT display prompting the user to place a finger on the sensor window. For reference, Figure 5 presents the schematic wiring diagram used to plan these connections prior to physical assembly; a top-down photograph of the actual physical wiring is presented in Section 4.5, alongside the functional validation results.

tu_pian_4.jpg

Figure 4. Assembled prototype hardware

tu_pian_5.png

Figure 5. Schematic wiring diagram of the prototype (ESP32, MAX30102, and TFT display)

3.9 Experimental validation procedure

Before physical assembly, the logical connections among the ESP32, the MAX30102, and the TFT display were verified using circuit-design and simulation tools (Proteus Design Suite and Tinkercad Circuits), employing a generic optical-sensor model with simulated voltage outputs to validate signal flow, since no native MAX30102 library exists for these tools. Firmware routines were subsequently tested through the Arduino IDE serial monitor to confirm correct analog-to-digital conversion and the heart-rate/SpO₂ computation pipeline. HTTP transmission to the cloud database was simulated to confirm transfer integrity prior to live testing.

After verifying the logic of the system, the physical prototype was assembled on a protoboard and tested under real conditions with several volunteer participants for general functional verification, following a real-time field-testing protocol similar to that reported for ESP32-based wireless health-monitoring systems validated under live patient-data conditions [27]. The quantitative accuracy comparison reported in Section 4.1 was conducted separately with a single volunteer participant. Optical readings were compared, beat by beat, against a Contec CMS50D commercial FDA-cleared pulse oximeter used as the reference instrument. Tests were repeated under ambient lighting and moderate-motion conditions to assess the stability of the filtering algorithm and the consistency of the sampling rate maintained by the ESP32. Continuous Wi-Fi connectivity to the cloud database was monitored over a two-hour session to evaluate transmission reliability and latency.

5.1 Heart-rate variability

Heart-rate variability is computed on-device using a two-pass algorithm over the circular buffer of the last N = 10 beat-to-beat intervals B = {b₁, b₂, ..., b_N}. First, the arithmetic mean of the buffer is computed as in Eq. (1):

$\bar{b}=\frac{1}{N}\underset{i=1}{\overset{N}{\mathop \sum }}\,{{b}_{i}}$         (1)

The variability feature is then obtained as the sample standard deviation of the same buffer, as in Eq. (2):

$HRV=\sqrt{\frac{1}{N}\underset{i=1}{\overset{N}{\mathop \sum }}\,{{\left( {{b}_{i}}-\bar{b} \right)}^{2}}}$          (2)

5.2 Feature normalization and classification

Prior to inference, each of the four input features x (heart rate, SpO₂, temperature, and HRV) is normalized using the z-score transformation given in Eq. (3), where μ and σ are the per-feature mean and standard deviation computed on the training set and stored as fixed constants (StandardScaler) for use at runtime.

${x}'=\frac{\left( x-\mu  \right)}{\sigma }$           (3)

The output layer applies the softmax function given in Eq. (4) over the five output logits z, converting them into a probability distribution across the five descriptive classes:

${{p}_{k}}=\frac{exp\left( {{z}_{k}} \right)}{\mathop{\sum }_{j=1}^{5}exp\left( {{z}_{j}} \right)}$           (4)

The predicted class is the index that maximizes p_k (argmax), with the corresponding probability displayed on the local screen and published to the cloud database as the confidence percentage.

5.3 Accuracy metric

Bench accuracy against the clinical reference instrument was quantified using the MAPE, defined in Eq. (5):

$MAPE=\frac{100}{n}\underset{i=1}{\overset{n}{\mathop \sum }}\,\left| \frac{{{x}_{i}}-{{r}_{i}}}{{{r}_{i}}} \right|$        (5)

This work presented the design, implementation, and preliminary experimental validation of a portable, low-cost IoT wearable device for monitoring basic vital signs, namely heart rate and SpO₂, built around an ESP32 microcontroller and a MAX30102 optical sensor, complemented by a compact on-device machine-learning classifier and cloud-based remote storage. A short, single-session bench comparison against a clinical pulse oximeter showed a MAPE of 1.8% for SpO₂ and 2.3% for heart rate, and the system sustained sub-500 ms cloud-transmission latency and approximately six hours of autonomy on a single battery charge. These preliminary results are encouraging and suggest that the proposed architecture is a plausible, accessible alternative for continuous physiological monitoring outside specialized clinical environments, comparing favorably in design scope with related ESP32/MAX30102 prototypes that omit cloud connectivity or persistent alerting, as summarized in Section 4.6; however, the accuracy figures should be read as a preliminary indication rather than a statistically validated claim, given the limited validation sample. The principal novelty lies not in any single component, since each is individually well established in the literature, but in their integration into a single reproducible, low-cost platform that explicitly separates these preliminary bench-accuracy figures from the classifier's current demonstrative status.

The embedded classifier demonstrated correct end-to-end functional operation, including signal acquisition, feature normalization, and on-device inference, but was not subjected to a formal accuracy evaluation in this stage of the work; this is identified explicitly as a priority for subsequent research rather than presented as a validated outcome. Future work should therefore prioritize: (i) conducting a larger, multi-participant bench validation with a statistically meaningful number of paired readings to confirm the preliminary accuracy figures reported in Section 4.1; (ii) collecting a labeled dataset from real participants under institutional ethical approval to retrain and rigorously evaluate the classifier, including precision, recall, and F1-score on a held-out test partition; (iii) migrating the prototype from a protoboard assembly to a dedicated printed circuit board and an enclosed, ergonomic wearable-device housing; (iv) extending the sensing front end with complementary signals such as single-lead ECG; and (v) benchmarking latency and battery autonomy under sustained multi-day operation rather than the two-hour session evaluated here. Taken together, the results support the continued development of compact, edge-capable IoT devices as a practical, technically grounded contribution toward more accessible preventive cardiovascular health monitoring in resource-constrained settings, while transparently identifying the larger-scale validation still required before broader deployment.

In direct response to the additional methodological gaps identified during review, three further items are added to this future-work agenda. First, the planned multi-participant validation should apply internationally accepted instrument-agreement methods, specifically Bland–Altman limits-of-agreement analysis and a correlation coefficient, rather than a mean-error value alone, and should report the calibration status of the reference instrument used. Second, the classifier retraining described above should include k-fold cross-validation in addition to a held-out test partition, with the full confusion matrix and per-class metrics reported rather than aggregate accuracy alone. Third, because PPG-based optical sensing is known to be sensitive to skin pigmentation, motion artifacts, and peripheral perfusion, with documented racial bias reported for clinical-grade pulse oximeters [32], the planned validation protocol should explicitly stratify participants by skin tone and include controlled motion and activity conditions, none of which were tested in the present single-session, single-participant evaluation.

The authors thank the Facultad de Ingeniería Electrónica e Informática (FIEI), Universidad Nacional Federico Villarreal (UNFV), for institutional support during the development of this work.