Reproducing DFA alpha 1 on Apple Watch and Wear OS

Watchletic can calculate DFA alpha 1 live on Apple Watch and Wear OS when a connected heart-rate monitor provides beat-to-beat R-R intervals. But showing a plausible number is not enough. I wanted a calculation I could reproduce, compare against a documented reference, and implement consistently on both watch platforms.

This investigation started after a knowledgeable user questioned some of the implementation details. Until then, I had primarily checked Watchletic's output against services such as Runalyze and AI Endurance. That was useful, but it was not a strong reference: another service can differ for reasons that are difficult to observe, including its artifact correction, window timing, detrending and DFA scale selection.

The user pointed me towards Fatmaxxer, an open-source Android application created by Ian Peake. That was especially useful because Fatmaxxer has also been compared directly with Kubios in a peer-reviewed study. In 23 participants, the study reported DFA-a1 bias of 0.03–0.05, correlations and ICC above 0.96, and heart-rate variability threshold estimates within 1 BPM. That validates Fatmaxxer, not Watchletic, but it gives me a much better implementation reference than simply comparing two unexplained output graphs.

So I used Fatmaxxer for two different checks:

1. Can Watchletic reproduce a known DFA calculation from the Fatmaxxer source?
2. How close are the two pipelines when they receive the same real Polar H10 R-R intervals?

The calculation implemented in Watchletic 3.2.0

For each live DFA-a1 value, Watchletic now uses:

• a rolling 120-second R-R window
• at least 160 source beats before the window is accepted
• artifact classification and correction on the derived stream, while preserving raw R-R intervals for storage and export
• automatic adjacent-beat thresholds of 5% during harder exercise and 25% at lower heart rates
• smoothness-priors detrending with lambda 500
• forward and backward segment placement
• recalculation on five-second boundaries relative to the start of the workout

The five-second update interval controls how often a result is produced. It does not shorten the two-minute analysis window.

One detail turned out to matter more than I initially expected: the DFA scales. Fatmaxxer does not simply use each integer scale from 4 through 16 once. Its pinned source uses this 30-element sequence:

3,
4, 4, 4, 4,
5, 5, 5, 5,
6, 6, 6,
7, 7, 7,
8, 8,
9, 9, 9,
10, 10,
11,
12, 12,
13, 13,
14,
15, 15

The repetition is intentional. These are logarithmically spaced scales rounded to integer beat counts, so repeating a scale preserves its weight in the final regression. Watchletic 3.2.0 uses this exact sequence on both Apple Watch and Wear OS.

After detrending, the mean R-R value is removed and the cumulative profile is calculated:

y(k) = sum from i=1 to k of (RR(i) - mean(RR))

For every scale, the profile is divided into segments from both the beginning and the end. A linear trend is fitted within each segment, and the root mean square fluctuation F(s) is calculated from the residuals. DFA-a1 is the slope of the line fitted to the logarithms:

DFA-a1 = slope(log(scale), log(F(scale)))

Using natural logarithms or base-2 logarithms does not change that slope as long as the same base is used for both axes.

Proof 1: reproducing Fatmaxxer's reference value

Fatmaxxer contains a built-in R-R reference vector and an expected DFA result. I extracted that vector from the source pinned at commit 3b10aa0 and passed it through an independent implementation of the same DFA core.

Fatmaxxer expected: 1.5503173309573228
Independent result: 1.5503173309573204
Absolute difference: 0.000000000000002442

That is an absolute floating-point difference of approximately 2.44 × 10^-15. This verifies the scale weighting, segment placement, fluctuation calculation and log-log regression used by the comparison harness. It is a numerical implementation check, not evidence that DFA-a1 itself predicts a particular physiological threshold.

Proof 2: the same result in Swift and Kotlin

I also created a deterministic 180-beat synthetic sequence containing a slow trend and two oscillating components:

RR(i) = 0.82 - i × 0.0008
        + sin(i × 0.35) × 0.01
        + sin(i × 0.91) × 0.004

After smoothness-priors detrending and the complete DFA calculation, both native implementations return:

Apple Watch / Swift: 1.8647678968382868
Wear OS / Kotlin:    1.8647678968382868

That expected value is now part of the automated tests for both platforms. It protects against accidentally changing the weighting or other mathematical details on only one platform in the future.

Replaying the same Polar H10 recordings

Reference vectors verify the mathematics, but they do not exercise real sensor artifacts. For that I searched my own Watchletic history for workouts recorded before I switched away from the Polar H10 on June 24, 2026.

I found 11 historical workout files marked as using an external heart-rate monitor. Ten contained stored R-R intervals. Nine produced windows that were valid in both the Watchletic and Fatmaxxer-compatible paths; one short recording did not pass Watchletic's 5% artifact-quality limit.

For every comparable five-second endpoint, both paths received the same underlying R-R recording and the same 120-second time range. This produced 3,353 common windows:

| Recordings | Common windows | Correlation | Watchletic bias | Mean absolute error | Same side of 0.75 | | ----------- | -------------: | ----------: | --------------: | ------------------: | ----------------: | | Apple Watch | 2,438 | 0.9146 | +0.0036 | 0.0218 | 92.29% | | Wear OS | 915 | 0.9893 | +0.0083 | 0.0194 | 97.49% | | Combined | 3,353 | 0.9544 | +0.0048 | 0.0211 | 93.71% |

The combined agreement at the lower 0.50 reference was 97.91%.

These windows overlap heavily: a value is calculated every five seconds from the previous 120 seconds. They must not be treated as 3,353 independent observations. The recordings also all come from one person. The useful information here is implementation agreement across real data, not a population-level confidence interval.

Across the seven full-length workouts, the window-weighted bias was +0.0068 and the mean absolute error was 0.0193.

What changed when the scales were corrected

Two recordings had already been analyzed before I changed Watchletic from one copy of every scale in 4...16 to Fatmaxxer's weighted sequence. Replaying them after changing only that part made the effect visible:

| Recording | Measurement | Previous scales | Fatmaxxer scales | | -------------------- | ------------------- | --------------: | ---------------: | | Apple Watch, June 12 | Correlation | 0.9165 | 0.9597 | | Apple Watch, June 12 | Bias | +0.0316 | -0.0027 | | Apple Watch, June 12 | Mean absolute error | 0.0474 | 0.0185 | | Apple Watch, June 12 | Same side of 0.75 | 71.57% | 84.79% | | Wear OS, June 23 | Correlation | 0.9857 | 0.9877 | | Wear OS, June 23 | Bias | +0.0259 | +0.0170 | | Wear OS, June 23 | Mean absolute error | 0.0381 | 0.0267 | | Wear OS, June 23 | Same side of 0.75 | 100.00% | 100.00% |

The scale sequence accounted for most of the systematic Apple Watch bias in that recording. It also improved the Wear OS comparison, although artifact handling remained the larger difference there.

The outlier is important too

One approximately five-minute test recording was a clear outlier. It provided only 15 common valid windows, with Watchletic averaging about 0.44 below the Fatmaxxer-compatible result.

At the first common window, both paths reported 2.26% artifacts, but Watchletic calculated 1.335 while the Fatmaxxer-compatible path calculated 1.665. Detecting the same amount of questionable data does not mean the resulting corrected R-R series is identical.

Fatmaxxer rejects a beat when its adjacent timing difference crosses the configured threshold and removes that beat from the DFA series. Watchletic uses a more detailed beat classification process. It can combine an extra beat with the following interval, split a likely missed beat, or interpolate ectopic, long and short beats. Raw R-R storage remains unchanged; correction is applied only to derived values.

This outlier is why I have not changed Watchletic to unconditionally discard beats just to match Fatmaxxer more closely. It is also why Watchletic now makes artifact percentage visible during the workout and includes it in the dedicated Alpha 1 CSV export. A DFA-a1 value is much easier to interpret when its data quality is visible beside it.

A small source-versus-documentation detail

Fatmaxxer's README currently describes Auto artifact selection as 5% above 90 BPM and 25% below 85 BPM. In the pinned implementation source, the actual thresholds are above 95 BPM and below 80 BPM, with the previous mode retained between those values.

For reproducibility, Watchletic follows the source behavior used in this comparison.

What this does and does not prove

The evidence supports the following claims:

• Watchletic reproduces Fatmaxxer's core DFA reference value to floating-point precision.
• Apple Watch and Wear OS produce the same result for a deterministic full-pipeline test vector.
• Fatmaxxer's weighted scale sequence substantially reduced the observed systematic difference.
• With the same real R-R recordings, the remaining average difference is small across the full workouts tested.
• Artifact correction can still create large differences in an unusually noisy, short recording.

It does not establish that Watchletic has been clinically or physiologically validated. The replay uses workouts from one person, overlapping analysis windows and a source-compatible Fatmaxxer calculation rather than the original APK. The .watchletic history files preserve reconstructed R-R timestamps but not their original BLE notification packet boundaries, which could create small timing differences from an exact app replay.

The published Fatmaxxer validation is encouraging because it shows that this open implementation can align closely with Kubios. A comparable independent study would still be required before making the same validation claim for Watchletic.

What is available in Watchletic 3.2.0

This work is included on both Apple Watch and Wear OS:

• Fatmaxxer-aligned DFA scale weighting
• a complete two-minute and 160-source-beat requirement before the first DFA-a1 value
• automatic exercise/rest artifact thresholds
• five-second updates aligned to workout elapsed time
• current RMSSD as a workout layout value
• current R-R artifact percentage as a workout layout value
• a dedicated Alpha 1 CSV export containing timestamps, elapsed time, BPM, raw R-R intervals, DFA-a1, artifact percentage and RMSSD

The update cadence remains five seconds and the scale sequence is static, so this change does not add another sensor subscription or high-frequency timer on either watch.

References

• Fatmaxxer source pinned to the comparison commit
• Rogers, Murias and Fleitas-Paniagua: Fatmaxxer validity compared with Kubios
• Tarvainen, Ranta-Aho and Karjalainen: smoothness-priors detrending
• Lipponen and Tarvainen: beat classification and artifact correction
• Gronwald, Rogers and Hoos: DFA-a1 for endurance exercise intensity

Related articles