Apollo510 Health Monitoring Patch for Heart Rate & Respiration Tracking Development

Project Requirements

This idea was proposed as a new product in the domain of wearable device technology. This wearable device has several purposes, such as assisting in health monitoring processes in both commercial use and scientific research, depending on its final classification and functional uses.

According to the original product brief, the device was supposed to deliver a reliable health-monitoring patch with the following requirements:

• Collect optical pulse signal via PPG sensor or electrical cardiovascular signal via ECG-compatible analogue front-end
• Obtain the trend for heart rate based on accepted signal windows
• Determine the trend of breathing rate using an adequate and validated signal source, such as body movement, impedance, breathing derived from ECG or modulation of PPG
• Detect moments of movements, bad contact and signal overwriting in order to detect the moments when the measurement is unreliable
• Save the measured values in a local storage if the phone is out of reach
• Send the encrypted data to the Android and iOS applications via BLE
• Work effectively using a tiny rechargeable device or with non-rechargeable battery
• Provide information on the state of the device without having a large display
• Provide the basis for proper testing, tracing and future product upgrades

The project's most important requirement was not to maximise the number of data points sent to a mobile app. It was to ensure that the system could distinguish between usable and unusable data. A patch should not turn a poor optical contact, a lifted adhesive edge or heavy motion into a falsely confident health trend.

Designing the Biosignal Acquisition Path

The interaction between the user and devices produces the biosignal response. The parameters that affect the PPG parameter include the kind of LED wavelength, optical layout, photodiode pathway, differences in skin colour, protection from external light, and touch of the sensor on the skin.

As for the ECG device, variables that need to be monitored are electrode positioning, skin-electrode resistance, cable flexing, design of the analog front end, and noise reduction. When it comes to respiration determination, the compromise must be made: the technology must be adequate for the patch site and its purpose.

The firmware architecture separated acquisition from interpretation. The sensor driver was responsible for deterministic sampling, timing, hardware interrupts and safe recovery after an I²C or SPI fault. A data-preparation layer handled filtering, baseline management, saturation flags and sensor diagnostics. The algorithm layer then worked only with time windows that passed defined quality checks.

This separation makes the product easier to validate and maintain. If an algorithm changes in a future firmware release, the original acquisition and quality metadata remain available for comparison. It also prevents application screens from presenting a number when the device has already detected that the underlying signal was unreliable.

In an optical application, the patch may check for the LED's current limitations, saturation of the photodiode, ambient illumination, clips on a sample, and contacts periodically made. In the case of an ECG-based design, firmware will check lead-off status, saturation on input, interference conditions, and amplitude of the signal.

These checks, although not providing the basis for a medical certification in themselves, may offer enough scientific proof to enable the assessment of whether a particular signal can be used for trend calculation.

From Raw Samples to Meaningful Trends

In general, raw waveform data is not suitable for any application intended for user use. The patch firmware has applied configurable digital filters to the data and divided it into small analysis windows. Each window is given a score according to certain criteria, such as amplitude range, noise level, correlation of movement, as well as periodicity and a number of missing samples.

For heart-rate trends, the system identified candidate beats or pulse peaks, evaluated interval consistency and calculated a rate only when the window met the configured quality threshold. Instead of forcing a value every few seconds, the product was designed to preserve an explicit "no reliable reading" state. This is better engineering and better user communication than displaying a precise-looking number generated from poor data.

Respiration trends may be inferred differently according to the selected sensing architecture. A chest-mounted patch could use motion-related information from an IMU, whereas an ECG or PPG signal may contain respiratory modulation that can be analysed carefully over a longer interval. The design team must document the source, applicable conditions, known limitations and validation method for the selected approach. It is not appropriate to treat all respiration algorithms as interchangeable.

The Apollo510 platform is capable of performing local processing of data, meaning it doesn't always need to send every single raw data sample over. The device has the ability to measure quality indicators and trends at the location, save raw data formats necessary for troubleshooting while still complying with privacy policies, as well as transmit any information required by the system.

This means less wireless activity, preventing battery drain as well as the leakage of sensitive personal information.

Firmware Architecture for a Connected Health Patch

The embedded firmware was organised around a robust event-driven design. Core services included:

• Sensor acquisition service – manages timing, sensor registers, FIFO reads and fault recovery.
• Signal-quality service – evaluates contact, motion contamination, clipping, saturation and data completeness.
• Trend-analysis service – processes accepted windows for heart-rate and respiration-related outputs.
• Storage service – saves encrypted or protected records, device events and synchronization state.
• BLE service – handles advertising, pairing, transfer protocol, reconnection and acknowledgement.
• Power-management service – coordinates low-power modes, sensor duty cycles, radio activity and battery measurement.
• Diagnostics service – exposes controlled logs and device-health flags for development, QA and support.

BLE was developed as a resumable synchronization process. The companion application could order certain indexes from records, confirm that files have been sent, and continue from the last successful operation point after disconnection.

This approach allows users to refrain from considering the wireless connection as always available, which is essential for a bracelet that can be worn under clothing or moved from a smartphone.

Security was considered during the development phase, which means the functionality includes authentication pairing mechanisms, bonded devices' controls, and data encoding during the transfer process, as well as secure firmware update methods.

The security functionalities of Apollo510 family, such as secure boot, approved TrustZone inclusion, and hardware-based security capabilities, can facilitate the development of a defense-in-depth system; however, the secured product delivery process also includes the proper key management and update signing process, and access limitations for back-end systems.

Battery-Life Testing Is an Engineering Activity, Not a Marketing Estimate

Patch wearables have limited battery capacity, so every subsystem must have a defined energy budget. In this case, we measured and modelled the current consumed during sensing, local processing, BLE advertising, synchronization, flash writes and sleep.

An effective battery test plan would comprise of:

• Idle current measurement with complete retention states enabled
• Sensor collection current with desired sampling parameters
• BLE communication current in various modes
• Data-upload current for realistic daily operation
• Current consumption during algorithm processing and flash writing activities
• Behavior under low-battery threshold
• Behavior with temperature and battery-voltage changes
• Charging and discharging behavior in regular rechargeable designs
• Worst-case scenarios that are different from best-case laboratory scenarios

This procedure results in accurate runtime estimation. Whatever battery-life claims are made must be related to the specific sensor mode, sample frequency, connection interval, uploading frequency, and environmental conditions.

Data Quality, Validation and Responsible Health Claims

Monitoring heart rate and respiration is valuable, although it needs to be done with appropriate language. Consumer wellness tracking, investigative devices, clinical decision support, and medical devices are all subject to wildly different evidence, quality system, and compliance requirements.

Adequate Infosoft supports teams in implementing a requirements-to-test traceability concept. All user requirements are linked to technical requirements, verification, testing records, and limitations known beforehand.

For example, a requirement to "show a heart-rate trend after adequate signal contact" can be traced to contact-quality conditions, window scoring logic, user-interface behaviour and test acceptance criteria.

When a customer wants to make healthcare or diagnosis claims, the development program must integrate the appropriate regulatory, quality management, clinical assessment, and cybersecurity expertise at the beginning. While firmware engineering is vital, it is still just a section of the broader medical device development process. We are not presenting a prototype algorithm or the output of a sensor as a diagnosis.