AI processing of wearable device signals: PPG, HRV, sleep

Wearable Device Data Processing: Where the Signal Is Lost

The raw signal from a bracelet is not a neat series but a stream with a floating step. Samples arrive at uneven intervals: the device changes sampling rate depending on charge and sleep mode, so between measurements there are both short and long gaps.

Averaging "by array index" instead of binding to a timestamp shifts peaks and turns an even rhythm into a jittery curve.

The second source of losses is motion artifacts. A step, wrist rotation, or adjusted strap produces outliers comparable in amplitude to the useful wave: a threshold filter either lets them into the metric or cuts real contractions along with them.

Alongside this is baseline drift: overnight, skin temperature and blood filling change, the signal level slowly drifts, and without a reference window the detector looks for peaks where they are not.

The third defect is gaps in the recording. The device was removed from the hand, the battery died, the connection was interrupted — holes appeared in the array.

Some handlers silently fill them with interpolation, and the metric looks plausible although it relies on invented points.

At output this is resting pulse that "floats" between adjacent nights, variability soaring on artifacts, and sleep signal quality where stages are labeled by movement rather than physiology.

The cost is decisions based on incorrect data: deep sleep share jumps, the recovery trend is not confirmed, and warnings about rhythm failures turn out false. We break down how this is addressed: from raw stream to robust pulse, variability, and sleep metrics.

What a Well-Built Signal Processing Pipeline Delivers

A pipeline is a chain of steps from raw signal to metric: resampling to a single rate, signal cleaning, episode labeling, and signal quality control at output.

Sources differ — from Garmin to inexpensive bracelets — so rules for bringing data to a common form are predefined, and each step is measured.

Stable Pulse and Variability Metrics During Movement

A reference motion channel separates artifacts from physiology, so false peaks that appeared during walking and stairs are cut before calculation. In active scenarios, the share of usable recordings grew from 60–70% to 90%+, and variability spread at the same load halved.

Fewer Gaps in Nighttime Recordings

At night the signal weakens due to movement and loose contact, and previously such recordings were simply discarded. Signal quality control labels unusable segments, short gaps are restored, and long ones are honestly marked as missing. The share of nights suitable for sleep stage calculation grew from half to nine out of ten.

Reproducibility of Results from Batch to Batch

Dataset preparation follows a single protocol: reference recordings, fixed labeling and validation rules before model update.

Stability of metrics between device batches is measured in percentage points, so comparison remains valid, and preparing a dataset for analysis takes days instead of weeks.

Where to Compute: On-Device, Server-Side, or Hybrid

The computation point determines two things the user notices immediately: latency of metric delivery and device battery consumption.

The same stream of raw signals — pulse wave, inter-beat intervals, body movements — can be cleaned in different ways, and each option has its own cost in resources and quality of final readings.

When On-Device Computation Is Mandatory

If the result is needed at measurement time — step count, real-time sleep stage estimate, rhythm signal — waiting for synchronization is not possible.

We compute on the device itself, but keep a battery consumption limit: heavy recalculations are launched only with sufficient charge and the sensor at rest.

When Server-Side Cleaning Is More Advantageous

Recordings accumulated overnight are more convenient to process in batch: the server has access to heavier artifact filtering models and one algorithm version for all devices.

Metric delivery latency here is measured in minutes, but reproducibility and quality of readings are higher.

In practice, the working default is hybrid: the device captures the raw signal and computes fast metrics, the server pulls additional data and recalculates heavy ones.

Then we divide responsibilities between the sides so battery consumption and latency remain within specified bounds.

Implementation Stages: From Signal Audit to Handover

The order of work is the same for any carrier — watch, ring, bracelet, chest strap. First we analyze what actually comes from the device, and only then assemble the processing pipeline and touch the models.

Audit of Raw Recordings and Labeling

1. Recording audit. We review exports in full: time gaps, motion artifacts, channel desynchronization, session interruptions. Output — a suitability report and a list of fragments that are not used for training.
2. Pipeline scheme. Acquisition → cleaning → pulse wave peak detection → inter-beat intervals → sleep segmentation → features. We agree on the scheme before code so interfaces between blocks don't need rework.
3. Filtering and labeling. We configure frequency filters and rejection rules, reconcile labeling from several annotators to a single reference, and describe controversial cases in writing.

Validation on a Holdout Set

• Holdout set. We split recordings by people, not by fragments: otherwise one person ends up in both training and validation, and the metric is inflated.
• Comparison with reference. We calculate divergence from a reference device and laboratory labeling — by mean error and share of gross outliers, not by a single averaged number.
• Solution handover. We deliver code, scheme, model weights, retraining protocol, and a quality metrics dashboard — with instructions on how to reproduce the result on a new batch of recordings.
• Support. For the first weeks after launch, we monitor drift on the live stream and fine-tune if the signal distribution has shifted from training.

Models, Pipeline Schemes, and Labeling Protocols

A trained model is not yet a solution: without describing the environment in which it operates, it cannot be fine-tuned, rolled back, or protected from input data drift when bracelet firmware updates.

Therefore we hand over not only inference artifacts, but also the entire set of rules around them. Below is what remains with your team, with the right to change and version.

Pipeline Schemes and Data Formats

• Signal flow scheme — from raw pulse wave and accelerometer recordings to data marts with sleep episodes and rhythm variability metrics, indicating filtering points and which segments are rejected as motion artifacts.
• Exchange formats — agreed structures for batch export and for streaming from a wearable device, including field naming scheme, units of measurement, and rules for handling gaps in time series.
• Post-processing rules — smoothing, recording quality thresholds, logic for stitching interrupted sessions; each rule with rationale so it can be changed consciously.
• Solution documentation — description of layers, dependencies between them, and where the model ends and heuristics begin.

Labeling Protocols and Quality Control

• Labeling instructions — definitions of classes and sleep stages, controversial cases with recording examples, escalation procedure when an annotator is unsure about an episode boundary.
• Quality control protocol — share of recordings for cross-check, allowable spread between annotators, threshold at which a batch is sent for complete relabeling.
• Recording access policies — who sees raw physiological data, what is de-identified before entering storage, how access is revoked when a role changes.
• Known limitations log — classes of recordings where the model errs predictably: high motor activity, reduced perfusion, short sessions. These are applicability boundaries, not a list of shortcomings.

Describe your task — we will return with a scope estimate and a plan for what from this list we cover and what is more reasonable to leave on your side.

Case Study: Variability and Sleep Stages from Raw Recordings

The task came from the research side: continuous overnight monitoring from wearable bracelet recordings — rhythm variability by inter-beat intervals and sleep stage labeling for the whole night were needed.

Data was collected as is: different device batches, segments with movement and signal interruptions. Labeling was done manually — an expert reviewed the entire night, assigned stages, and marked controversial segments as uncertain.

One dataset took several weeks, and comparability of series rested on a specific annotator's memory.

Metrics Before and After

• Rejected recordings: 34% of nights were discarded due to motion artifacts — now 6%, and rejections apply only to unreadable segments.
• Missing intervals: the share of intervals dropped from the variability series decreased from 12% to 1.5% by restoring short gaps.
• Divergence from reference: agreement on sleep stages increased from 0.61 to 0.84, phase boundary shift halved.
• Dataset preparation time: from several weeks to two days, including manual review of controversial epochs.

What changed: artifact filtering was assembled into a single pass with fixed thresholds, short interruptions were restored by interpolation, and automatic stage labeling was left with mandatory review of controversial epochs.

Validation was performed against the open PhysioNet corpus with reference stages, so divergence was calculated identically across all series. Each dataset received a version — one can return to previous labeling if night inclusion criteria change.

How Does Streaming Filtering Differ from Batch Cleaning?

This is not a choice of "one is better than the other," but two points of the same trade-off — accuracy and speed.

Streaming filtering calculates the metric at the moment of signal reception, batch cleaning — over an accumulated array of recordings, and metric delivery latency depends precisely on this.

A streaming scheme returns a result in seconds but does not see future context: a motion artifact will end in a minute, and loss of skin contact is temporary. Thresholds must be set stricter, so part of valid segments is discarded and the sleep curve looks jagged.

Batch cleaning sees the recording as a whole: finds gaps, matches segments, selects filters for a specific night and device model — from Garmin to budget trackers. The cost is latency measured in hours and peak storage load during the run.

In practice, loops are combined: the stream gives a rough estimate for the interface, the batch gives the final one, which also goes into reporting.

Recalculation of recording history becomes a routine operation: the raw signal is stored, the recording is tagged with an algorithm version, and a filter update reruns the archive.

Technical Concerns: Noise, Gaps, Privacy

Objections at the evaluation stage concern not signal processing itself, but the raw material: what to do with an already accumulated archive, how much the result depends on the device, and how to separate sensitive health data from analytics. Below are answers to those that come up most often.

Does the result depend on the bracelet model?

It does: sampling rate, built-in smoothing, and sensor fit differ. We bring the stream to a unified representation and validate accuracy separately for each model. Dynamics and trends are comparable between devices; absolute values only within one model.

How is sensitive health data de-identified?

We do not store the raw signal: at input we discard identifiers, leaving a pseudonym whose key is held on your side. Then we work with features rather than the original waveform. The de-identified array goes into training; personal recordings remain in your environment.

What error is considered acceptable?

The threshold is set by the task: for sleep phases, error within one epoch is not critical; for rhythm variability, interval order matters more than averages.

We fix the threshold before start and accept based on the share of recordings that exceeded it — 85–90% of nights pass without manual correction.

Let's Discuss the Task: What to Send for Evaluation

To return with an estimate and work plan, not assumptions, we need inputs on your data. Below is a list of what removes most uncertainty: the fuller the picture of the signals, the more accurate the composition of stages and order of work.

• Sample export. Several files for a real period — with gaps, noise, and anomalies. A cleaned fragment hides exactly those cases on which processing later breaks.
• Format description. Field schema, sampling step, time and time zone binding, units of measurement, segment labeling, and rules by which absence of signal is recorded.
• Target metrics. What we consider a correct result: share of restored segments, stability of readings at rest, consistency of sleep stages with expert labeling or diary.
• Target scenarios. What conclusions are needed at output — recovery dynamics, weekly trends, threshold alerts — and how they reach the user.
• Privacy constraints. Where raw recordings are stored, whether de-identification at input is required, whether data can be moved outside your environment, which specialists get access.
• History volumes and current scheme. Number of devices and recordings, storage depth, how processing is arranged now and at which step it stops handling the load.

With this set, we return with an estimate, processing scheme, and work plan where each stage has a verifiable result.