A bench run answers one narrow question: how closely does device B track device A, right now, on this body? It is not a truth measurement. Nobody in this setup is holding a clinical ECG. What you get is agreement with a reference you have chosen to trust — which, for heart-rate work, is exactly the question worth asking.
That framing matters, because it decides how every number is signed. Errors are reported as device under test minus reference. A positive bias means your watch reads high. The reference is correct by construction, and if it isn't, none of the rest is worth reading.
What you need
- A reference strap that reports true RR intervals. A Polar H10 is the usual pick; a Wahoo TICKR or Garmin HRM works too. What disqualifies a device is sending only a rounded BPM value — more on that below.
- The device under test. A watch, a wrist band, an armband, or a second chest strap. Anything that exposes the standard Bluetooth Heart Rate Service.
-
A desktop browser with Web Bluetooth — Chrome, Edge or Opera, over HTTPS
or
localhost. Safari and Firefox do not implement it and cannot connect at all. - Both sensors on one body, in one session. Two recordings made an hour apart are two different physiological states, and comparing them measures your afternoon, not your hardware.
A note on the watch's own app. Many watches only broadcast heart rate over Bluetooth while they are in an active workout or "broadcast" mode. If your device never appears in the picker, start a workout on it first, then scan.
The procedure
-
Wear both sensors at the same time
Wet the strap's electrodes and fit it snugly just below the sternum — a dry or loose strap is the single most common source of junk reference data. Wear the device under test the way you actually wear it, not tightened specially for the test. You want the error you live with, not a best case.
-
Connect the reference to slot A
Open Bench and connect the chest strap to the Reference slot. Confirm it is streaming and that the beat quality looks clean before going further.
-
Connect the device under test to slot B
Connect the watch or band to the Device under test slot. The two slots will not accept the same physical sensor, so you cannot accidentally compare a device against itself and get a flawless score.
-
Let both streams settle for about thirty seconds
Optical sensors run heavy filters that need time to converge, and strap electrodes need to wet out. Starting the run immediately charges the device for a warm-up transient that has nothing to do with its steady-state accuracy.
-
Start the run — and make your heart rate move
This is the step people skip, and it costs them the most useful half of the result. Stand up and sit down. Walk a lap. Take the stairs. Hold a plank.
Two things depend on it. First, the lag between the sensors can only be recovered from a change in heart rate — correlating two flat traces just scores noise, and the analysis will honestly refuse to report an offset rather than invent one. Second, smoothing error only shows up in transitions. A device that looks excellent lying still can be ten beats behind on a stairwell.
-
Stop after three to ten minutes and read the verdict
The live view previews a trailing window while you run; stopping analyses the whole recording. Anything under about a minute is dominated by noise. Rather than one long resting run, do several short ones under different conditions — that is where wrist sensors separate from straps.
-
Export the CSV
The export carries the summary header, the time-aligned heart-rate series, and — when both devices qualify — every matched beat pair. Keep it. It is how you compare the same device against itself after a firmware update, or hand the raw numbers to somebody who wants to check your work.
Reading the numbers
A bench result is deliberately several numbers rather than one score, because a sensor can fail in ways that a single figure hides. A device with zero bias can still be wildly noisy; a device with a perfect correlation can still be three seconds late.
| Figure | What it means | What good looks like |
|---|---|---|
| Bias | Mean of (device − reference). A systematic offset — the device reads consistently high or low. | Within ±1 bpm. A pure bias is the most forgivable error; it is at least predictable. |
| MAE | Mean absolute error. Typical size of a disagreement, ignoring direction. | Under ~3 bpm at rest for an optical device. Straps against straps should be well under 1. |
| RMSE | Root-mean-square error. Like MAE but punishes large misses much harder. | Close to MAE. If RMSE is far above MAE, the device is mostly fine but occasionally very wrong. |
| Limits of agreement | Bias ± 1.96 SD. The band containing ~95% of the disagreements — the honest error range. | Narrow and roughly centred on zero. This is the number to quote, not the bias. |
| r | Correlation of the two heart-rate traces after alignment. Do they move together? | Above 0.9. Note that r says nothing about offset — two traces 10 bpm apart can correlate perfectly. |
| Offset / lag | How far the device under test trails the reference, recovered by cross-correlation. | Under ~1s. Anything past 2s means heavy smoothing: the steady-state value may be right while every change arrives late. |
| Alignment r | Confidence in that lag estimate. Low means the two streams never tracked each other well enough to locate it. | Above 0.5. Below that, treat the offset — and honestly the whole run — as unreliable. |
| Dropouts / coverage | How often the device stopped reporting, and what fraction of the window it actually covered. | Zero dropouts, 100% coverage. Dropouts under movement are the classic optical failure. |
Read the limits of agreement, not the bias. A device that reads 8 bpm high half the time and 8 bpm low the other half has a bias near zero. It is not accurate; it is just wrong symmetrically. The limits of agreement are what catch that, which is why the Bland–Altman plot exists.
Why HRV agreement is sometimes withheld
Bench mode reports two tiers of analysis, and the second one is gated.
Heart-rate agreement is always available. It compares each device's own reported BPM on a common 4 Hz grid. For an optical wrist sensor this is the honest headline number, because tracking heart rate is what those devices are built to do.
RR and HRV agreement is computed only when both devices emit true beat-to-beat
intervals. Many devices send just a rounded BPM value over Bluetooth. When that
happens, the intervals have to be reconstructed as 60000 / bpm — a quantised
step function. It looks like a series of intervals. It is not one. At 60 bpm, one BPM of
rounding is already about 16 ms of fictional "variability", and every genuine beat-to-beat
fluctuation smaller than that has been erased before the data ever left the device.
Run RMSSD on that and you get a number. It is stable, it has two decimal places, and it is an artefact of integer rounding. So rather than print it next to a real one and let you compare them, the analysis withholds the RR tier and says why.
This is the single most important thing a bench run can tell you. If your watch does not stream RR intervals, no app reading it over Bluetooth can give you real HRV — regardless of what that app's own dashboard shows you.
Five mistakes that ruin a bench run
- Lying perfectly still the whole time. The lag becomes unmeasurable and the smoothing error never appears. The result flatters the device.
- A dry chest strap. The reference throws artefacts, and every error is then wrongly attributed to the device under test.
- Running for thirty seconds. Too few samples; the statistics are noise.
- Quoting the bias alone. It hides symmetric error completely. Quote the limits of agreement.
- Comparing HRV from a device that doesn't send RR. You are comparing a real measurement against a rounding artefact.
What the CSV contains
The export is plain CSV with a commented header, ready for a spreadsheet, R, or pandas:
-
Header lines (prefixed
#) — both device names, duration, the measured offset and its confidence, whether each device is RR-capable, beat and artefact counts, and the full HR agreement statistics. -
Section
hr— the time-aligned heart-rate series at 4 Hz: timestamp, reference BPM, device BPM, and the signed difference. Gaps are left empty rather than interpolated, so a dropout stays visible instead of being smoothed over. -
Section
rr— present only when both devices report true intervals: every mutually-matched beat pair with both RR values and their difference.
Long runs are clipped to the beat buffer that is still in memory, and when that happens the result says so explicitly rather than reporting a duration covering beats it no longer holds. For a run over half an hour, export as you go.
FAQ
How long should a sensor bench run be?
Three to ten minutes is enough for a stable read, provided your heart rate actually moves during it. Under about a minute the statistics are dominated by noise; much beyond ten and you are mostly re-measuring the same conditions. Several short runs under different conditions beat one long resting one.
Can I use my watch as the reference instead of a chest strap?
Not usefully. The reference is treated as correct by definition, so it must be the more trustworthy device. It also needs to report true RR intervals — otherwise no beat-to-beat comparison is possible at all and only the heart-rate figures mean anything.
What is a good result for an optical wrist sensor?
At rest, an MAE under roughly 3 bpm with limits of agreement inside about ±5 bpm is a good optical result. The same device will usually be considerably worse during movement. Judge lag separately — a device can be accurate in steady state and still be seconds behind every change.
Why does my run say HRV agreement could not be computed?
One of the two devices is sending only a rounded BPM value rather than real intervals. Its RR series is reconstructed as 60000 / bpm, a quantised step function with no genuine variability in it. Comparing RMSSD against that would produce a confident-looking number that means nothing, so it is withheld. See the RR gate.
Which browsers can run a two-sensor bench?
Bench mode uses Web Bluetooth: desktop Chrome, Edge or Opera, served over HTTPS or localhost. Safari and Firefox do not implement Web Bluetooth and cannot connect to either sensor.
Does anything get uploaded?
No. Both sensors connect straight from the browser over Web Bluetooth and the analysis runs locally. Recordings live in your browser's own storage until you export them.
Run your own bench
Bench mode is built into HRV Dojo. Connect two sensors, press start, and read the disagreement — no account, nothing uploaded.
Open HRV Dojo See a worked example