Measurement Methodology and Accuracy Disclosure — Pulsehaven

Last updated: 23 July 2026. This document describes how Pulsehaven derives a heart-rate and heart-rate-variability estimate, which hardware it requires, what the readings are and are not, and how the app behaves when the signal is not good enough to report a number.

1. Sensing principle

Pulsehaven uses contact fingertip photoplethysmography (PPG). The user places a fingertip over the rear camera and its LED flash. The LED illuminates the tissue, and the camera records the light returned through the finger. Blood volume in the capillary bed rises and falls with each cardiac cycle, which modulates the amount of light reaching the sensor. The per-frame mean intensity of the red channel therefore carries a waveform whose fundamental period is the cardiac cycle.

This is a standard optical measurement, and it is the same principle used by pulse oximeters and by wrist wearables. Pulsehaven does not attempt to infer a physiological quantity that the hardware cannot observe: it reads the timing of an optical pulse waveform that the camera genuinely records, and reports quantities derived from that timing.

Independent peer-reviewed work has evaluated smartphone contact PPG against reference electrocardiography and clinical monitors. Reported agreement for heart rate at rest is close, with correlation around r = 0.99 and root-mean-square error of roughly 1 to 2 bpm in the cited studies. Representative sources:

Pulsehaven cites this literature to describe the physical basis of the technique. It does not claim clinical equivalence for its own implementation, and the app's user-facing text does not present readings as clinical measurements.

2. Required hardware

Fingertip PPG requires a rear camera and a controllable LED flash. Without an LED, no illumination reaches the tissue and there is no pulse waveform to read.

Pulsehaven therefore declares still-camera and camera-flash in UIRequiredDeviceCapabilities, so the App Store will not install it on devices without an LED flash, including iPad models. In addition, the app checks at runtime that a rear camera with an available torch exists before a measurement can start. If no such camera is present, the app states plainly that measurement is not possible on that device and does not produce a reading. Under no circumstance does Pulsehaven display a heart-rate or HRV number on hardware that cannot perform the optical measurement.

3. Signal processing

All processing runs on the device. There is no server component, no model inference, and no upload of camera frames. The pipeline is deterministic signal processing, implemented independently in Kotlin Multiplatform and shared by the iOS and Android clients so that both produce identical numeric results:

  1. Per-frame mean intensity of the red channel of the camera image, timestamped per frame.
  2. Resampling onto a uniform 30 Hz grid to compensate for capture jitter.
  3. Detrending with a moving mean of approximately 1.2 s, which removes baseline drift and respiratory modulation. Without this step, drift leaks into the lower band edge and can be mistaken for a slow heart rate.
  4. Zero-phase band-pass filtering, an RBJ biquad applied forward and backward so that peak positions are not shifted. The default pass band is 0.7 to 4 Hz, equivalent to 42 to 240 bpm.
  5. Peak detection by topological prominence, followed by an adaptive refractory interval that suppresses the dicrotic notch being counted as a second beat.
  6. Inter-beat intervals in milliseconds, from which heart rate is computed as 60000 divided by the mean interval, and HRV is computed as RMSSD and SDNN over the accepted intervals.

The first seconds of a session are discarded, because the pressure transient while the finger settles produces intervals that are not representative.

4. Quality gating: when the app refuses to report

The most important accuracy control in Pulsehaven is that it declines to produce a number when the signal does not support one. A reading is released only if all of the following hold, evaluated by a single shared gate used by both platforms:

For an HRV result the gate additionally requires:

A capture that passes the heart-rate conditions but fails the HRV conditions is reported as heart rate only. A capture that fails the basic conditions is reported as "could not get a clear reading", with guidance on finger placement, and nothing is stored. The app also monitors optical coupling throughout the session: if the fingertip blanches, the perfusion index collapses even though overall brightness stays high, and the session is downgraded rather than allowed to produce an inflated HRV value.

5. Verification performed

Pulsehaven's numeric core is covered by an automated regression suite that runs on every build, over 100 assertions across the shared engine. The measurement-relevant cases include:

Pulsehaven has not been validated against a reference electrocardiogram or a regulated monitor by its developer, and the app makes no clinical accuracy claim on the basis of the literature cited in section 1. This limitation is stated to reviewers here and to users in the app and in the published health disclaimer.

6. Scope of what is reported

Pulsehaven reports heart rate, HRV as RMSSD and SDNN, and a qualitative load description derived from HRV relative to the user's own previous readings.

Pulsehaven does not measure or estimate blood pressure, blood oxygen saturation, body temperature, blood glucose, or an electrocardiogram, and does not detect arrhythmia or any other medical condition. It performs no continuous or background monitoring.

Until a user has accumulated enough comparable readings, the app shows a calibrating state that presents the numbers without any interpretive verdict, rather than judging a single reading against a population average. Interpretation is always framed against the user's own history.

The app is presented throughout as a wellness and informational product, not a medical device. Result screens carry the line that readings are a wellness reference and not a diagnosis, and the health disclaimer directs users with symptoms or cardiac concerns to a qualified healthcare professional before relying on the app.

7. Data handling

Camera frames are processed in memory on the device and are never written to storage or transmitted. Measurements, context notes and history remain in the app's local storage on the device. No account is required, nothing is written to iCloud, and health data is not used for advertising or shared with third parties. Users can export their records as CSV or erase all local data and withdraw health-data consent from within the app.

8. Related documents