At the beginning of the project, we decided to build the first prototype using proven and widely available components. We selected the ESP32 DevKit V1 microcontroller as the core element—it offered both high computing power and built-in Wi-Fi connectivity, opening the door for future expansion. To measure heart rate and blood oxygen saturation, we chose the MAX30102 sensor—a compact, energy-efficient component well documented in the literature. It operates on the principle of reflective pulse oximetry, analyzing red and infrared light passing through tissue. Based on this, it calculates SpO₂ and heart rate by detecting changes in blood volume and differences in light absorption by hemoglobin.

We assembled the circuit on a breadboard, which allowed for rapid iteration and testing without the need for soldering. The ESP32 communicated with both the sensor and a 16×2 LCD display via the I²C bus. The LCD served as the user interface, effectively displaying real-time heart rate and oxygen saturation readings. Thanks to readily available libraries (DFRobot_MAX30102, LiquidCrystal_I2C), we were able to focus on the application logic. Immediately after powering on, the device displayed the data in a clear format: “HR: 75 bpm” and “SpO₂: 98%”.

Even the first tests conducted in home conditions yielded positive results. The readings were close to those from a medical-grade pulse oximeter—the differences of a few percentage points were considered acceptable. However, we quickly noticed how crucial proper sensor contact was—any looseness resulted in unstable or unrealistic readings (e.g., SpO₂ of 41% when the finger was moving). To address this, we implemented error messaging—if the sensor failed to detect a pulse or saturation, the device would display a warning after a few seconds: “No signal. Check sensor placement.” This ensured that a responder would not be misled by faulty data, but instead would receive a clear message indicating the need to reposition the tag correctly.

We spent the following days testing the device in various conditions—each team member took turns acting as the “test patient.” We placed the sensor on a finger and observed the effects of movement, lighting, and contact pressure. It became clear that even minor variations could significantly impact signal quality. This helped us better understand the limitations of PPG sensors, and we adjusted the code to respond dynamically to errors. We reduced the LCD refresh rate to 1 Hz, added calibration messages such as “Applying tag…”, and began considering further UX improvements.

Work on the housing was carried out in parallel. Using FreeCAD, a two-part structure was designed—the lower section housed the electronics and battery, while the upper part snapped into place. It was printed on a 3D printer using light blue PLA. An opening was added at the bottom, precisely dimensioned for the sensor to ensure direct contact with the skin. A simple snap-fit mechanism enabled quick access to the interior. The entire assembly was lightweight and compact enough to be attached to the body with a strap. Even the first print successfully secured the sensor in the correct position.

At this stage, we also began considering ergonomics in high-stress situations—how to attach the tag quickly and securely, without causing discomfort to the patient. We explored both adhesive surfaces (like medical plasters) and mounting options using straps or bands. Meanwhile, the mechanical team worked on the next version of the housing—more streamlined, with space for an RGB LED to indicate triage status using color.

In summary, the first prototype was completed within a few weeks, operated reliably, and measured basic vital signs with satisfactory accuracy. We tested it across various scenarios, implemented error handling, developed the initial housing, and optimized the user interface. The total cost of components did not exceed 100 PLN, and the final result proved that the concept is both feasible and effective. At this stage, we focused on building a solid technical foundation—and we achieved exactly that.

The first prototype confirmed that the measurements worked, but it also revealed some limitations. The most significant was the local LCD display. While it served its purpose, we began to ask ourselves: in a real emergency, does a responder have time to walk up to each patient and read a tiny screen? The answer was obvious—no. We concluded that instead of a built-in display, a centralized application—mobile or web-based—would be a much better solution. It could aggregate data from multiple devices in one place, allowing the medical team to monitor all patients simultaneously and respond more effectively.

Thanks to the built-in Wi-Fi on the ESP32, we were able to wirelessly transmit data to a command computer or even a smartphone. This allowed us to simplify and reduce the size of the tag itself—we removed the display and all related components. Instead, we kept only a multi-color RGB LED, which clearly indicates the patient's triage status from a distance (green, yellow, red, black). In case of sudden deterioration (e.g., drop in SpO₂ or loss of pulse), the tag blinks red—alerting responders even from several meters away. Thus, the device still works locally, but the main user interface is shifted to the central application.

At the same time, we added an AD8232 ECG module to make the heart rate measurement more resistant to external factors. While PPG sensors are sensitive to movement and perfusion, ECG—based on electrodes—provides a stable signal even in unfavorable conditions. We used three electrodes in an Einthoven configuration (RA, LA, RL), connected to the ESP32’s analog input. The microcontroller samples the signal at around 100 Hz and transmits the data via a serial port to a computer.

On the computer side, we developed a Python script (using matplotlib, numpy, scipy) that visualizes the ECG waveform in real time and detects characteristic QRS peaks—based on which we calculated the heart rate. We applied a Butterworth filter to eliminate noise. After filtering, we obtained a clear and stable waveform that allowed not only heart rate detection but also full cardiac cycle visualization—P, QRS, and T waves. Importantly, the ECG results matched the optical sensor data, confirming the accuracy of our system.

The addition of ECG required changes to the enclosure—we removed the display slot and added a connector for the electrode cable (e.g., 3.5 mm jack) and a dedicated side port. We retained the compact and durable design, keeping the enclosure two-piece, either snap-fit or screw-mounted. The RGB LED was fitted with a diffuser cap to ensure visibility from wider angles. The entire case was planned for 3D printing in PET-G or ABS—materials resistant to heat, impact, and moisture—so the device could withstand drops and continue functioning.

In parallel, we began preparing for full wireless communication. While ECG testing still relied on a wired USB/UART connection, the code architecture was adapted to transmit data in JSON format via Wi-Fi. The ESP32 can function as a TCP/UDP client or local WebSocket server. Although we didn’t fully implement the network layer at this stage, we successfully tested stable connections and the core protocol.

In this phase, we redefined the concept of the tag—readings are now sent to a central application, and the tag acts as a standalone sensing node with visual triage signaling. Heart rate is measured via both optical and electrical methods, ensuring greater data reliability and resistance to interference.