---
title: 'Fitplotter: Endurance Data Visualization'
url: https://www.emergentmind.com/topics/fitplotter
type: topic
---

# Fitplotter: Endurance Data Visualization

Searching arXiv for the specified paper to ground the article in the cited source.
arXiv search query: id 2509.05961
Fitplotter is a browser‑based analysis and visualization tool built specifically for endurance training data, with a focus on running. In "A Longitudinal Evaluation of Heart Rate Efficiency for Amateur Runners" [2509.05961], it is presented as a client‑side web application designed for the visualization and analysis of data associated with fitness and activity tracking devices, and specifically as a transparent environment for computing and studying Heart Rate Efficiency (HRE). Its defining characteristics are local computation in a standard browser, file‑based ingestion of activity records, privacy by design, and an emphasis on explainable, exploratory visualization rather than automated recommendations.

## 1. Motivation and conceptual positioning

Fitplotter was created to address a practical problem in long‑term self‑tracking: watches and platforms like Garmin or Strava collect rich data, including pace, heart rate, and GPS, but make it hard to pull out transparent, long‑term, explainable metrics that a non‑expert can reason about. Two issues motivate the system. The first is explainability and long‑term reflection: commercial platforms emphasize summaries and “smart” metrics such as training readiness and VO\(_2\)max scores, computed with opaque algorithms that often fluctuate in ways users cannot interpret. The second is access to raw data and privacy: getting to the underlying `.FIT` files or raw time series often requires export pipelines or cloud services, and few tools allow an athlete to take files directly from a device and explore them locally without uploading anything to a third‑party service [2509.05961].

Fitplotter is positioned as an answer to these gaps. It is not framed as a prescriptive coaching system, and the emphasis is explicitly not on automated recommendations. Instead, the tool is meant to let runners look at their own data in detail, compare sessions, and interpret the data themselves. This suggests a design orientation closer to reflective analytics than to algorithmic scoring.

A recurrent contrast in the source material is between transparent metrics and proprietary dashboards. Fitplotter is intended for researchers, developers, and athletes who want reusable, transparent tools rather than proprietary dashboards. In that sense, it serves both as a software artifact and as a methodological stance on how fitness data should be inspected over long time spans.

## 2. Architecture, ingestion, and privacy model

Fitplotter is implemented as a client‑side web application. It runs in a standard browser, with no installation beyond visiting the page, and all computation is done locally in the browser. There is no server‑side processing or database in the background. This architecture is central to its privacy model: data never leaves the user’s machine, and there is no cloud upload or account.

The ingestion model is file‑based. Users load activity files directly, and the tool supports common formats such as `.FIT` and `.TKL`. It is compatible with devices and platforms that can export these formats, including Garmin, Suunto, and the broader ecosystem of GPS devices that produce FIT. Raw streams extracted from such files include timestamp, distance, heart rate, pace or speed, and GPS coordinates.

For large‑scale analysis, the paper situates Fitplotter within a small ecosystem of companion tools.

| Tool | Role | Notes |
|---|---|---|
| Fitplotter | Analysis and visualization | Client‑side web application |
| Fitalyser | Batch aggregation | Computes statistics across many sessions |
| GChandler | File acquisition | Automates downloading of activity files from Garmin Connect |

Fitalyser is described as a batch interface that aggregates statistics across many sessions, for example to compute average HR, pace, and HRE per run, per month, or per year. GChandler automates downloading of activity files from Garmin Connect. All the high‑level plots in the study, including 14‑year HRE trends and multi‑runner comparisons, are generated by first extracting data via Fitplotter and Fitalyser, then plotting with Python. Fitplotter itself is released as open‑source under the MIT license [2509.05961].

## 3. Visualization and interaction model

Once files are loaded, Fitplotter exposes several per‑sample time series within a session: pace in min/km, heart rate in bpm, HRE in beats per kilometer, GPS position, elevation, and an optional breathing rate derived from HRV. At the session level, computed via companion tools like Fitalyser, it can support exported summaries that include date, distance, average pace, average heart rate, and average HRE.

The interaction model is built around exploratory analysis. Rich, zoomable charts are provided via CanvasJS, and a synchronized map is provided via Leaflet. Selecting a segment on the chart highlights the corresponding path on the map, which allows inspection of how hills, turns, or environmental changes affect pace, HR, and HRE. Users can zoom in time or distance, toggle individual series on and off, and overlay multiple sessions for comparison, including several long runs on the same route or different races.

Lap‑based segmentation is a central feature. Runs can be segmented by laps or user‑defined intervals to examine within‑session dynamics such as intervals, fatigue transitions, course segments, 5 km segments in a marathon, or repeated tempo efforts. Fitplotter also supports basic data smoothing to reduce sensor noise, and visual inspection is used to reject anomalous segments such as obvious HR dropouts. The source additionally notes a derived breathing rate estimate from HRV for users interested in additional physiological signals.

These capabilities collectively support interpretability. The tool links time series to route geometry, allows inspection at multiple temporal scales, and exposes both raw streams and derived metrics in the same interface. A plausible implication is that Fitplotter treats explainability as an interface property as much as a metric property.

## 4. Heart Rate Efficiency as Fitplotter’s central analytical construct

In the study, Heart Rate Efficiency is formalized as a simple product of heart rate and pace:

$$
\text{HRE} = \text{HR} \times \text{Pace}.
$$

Here, \(\text{HR}\) is heart rate in beats per minute and \(\text{Pace}\) is running pace in minutes per kilometer. The resulting unit is beats per kilometer. The paper glosses the quantity intuitively as “how many heartbeats does it cost me to run one kilometer?” Pace is often converted to decimal minutes per kilometer for computation. For example, 5:25 min/km is converted to 5.42, and with HR \(= 140\) bpm, \(\text{HRE} = 140 \times 5.42 \approx 758\) beats/km [2509.05961].

No additional normalization or scaling is applied. HRE is used in its raw units, with typical values ranging roughly from 600 beats/km for highly efficient, well‑trained runners to 900+ beats/km for less trained runners with higher cost. The metric is used at several scales: per‑run HRE, per‑segment HRE, and monthly or yearly aggregates.

The conceptual rationale is that HRE couples two commonly observed variables that, when examined in isolation, are difficult to interpret. Pace alone is strongly influenced by terrain, wind, temperature, and effort choice; heart rate alone is affected by caffeine, stress, heat, dehydration, and day‑to‑day variability. By combining them, the authors argue that in sustainable, steady‑state running the counterbalancing effects of pace and HR make HRE less influenced by short‑term conscious actions than either variable alone. If pace increases, HR typically rises; if HR is consciously kept low, pace typically slows. Within a moderate range, this leaves HRE relatively stable. The paper therefore characterizes HRE as providing objectivity over the short term and sensitivity over the long term.

Fitplotter operationalizes this construct directly. It reads raw HR and pace streams, computes per‑run averages locally, displays HRE directly in the browser, and can compute HRE by segment across a run. This makes the formula inspectable and the output visually traceable to its inputs.

## 5. Datasets, workflow, and empirical findings

The empirical use of Fitplotter in the paper relies on three datasets. The first is the longitudinal self‑tracking of Athlete A over 2011–2024, comprising over 4,000 sessions and including marathon and ultra‑marathon training, mountain trail, and triathlon sessions. The second is public training logs from 12 additional runners, labeled B–M, sourced from RunningAHEAD and selected for public HR data and at least one year of consistent training. The third is a set of sixteen race‑specific activity records from Strava, including several marathons such as Larnaca 2017 and 2018, Prague 2016, Berlin 2017, Chicago 2018, Boston 2019, Valencia 2019, Bedford 2020, London 2021, San Sebastian 2022, and La Rochelle 2023.

The computational workflow proceeds through ingestion and parsing, cleaning and smoothing, per‑run aggregation, intra‑run segmentation, and longitudinal aggregation. For each run, average pace in min/km and average HR in bpm are computed, pace is converted to decimal form, and session‑level HRE is calculated as

$$
\text{HRE}_{\text{run}} = \text{HR}_{\text{avg}} \times \text{Pace}_{\text{avg}}.
$$

For long runs and races, distance bins or laps are used to compute

$$
\text{HRE}_{\text{segment}} = \text{HR}_{\text{segment}} \times \text{Pace}_{\text{segment}}.
$$

Yearly summaries include average monthly distance, yearly averages of pace, HR, and HRE, and the minimum HRE across all runs in a year.

The principal findings are qualitative but specific. For Athlete A, 2011–2013 shows strong improvement: average monthly distance increases from 186 km to about 290 km, pace improves from about 6:01 to about 5:18 min/km, and average HRE drops from 902 beats/km to 776 beats/km, with minimum yearly HRE dropping from 740 to 710. From 2013–2016, average HRE stabilizes or slightly improves, and minimum HRE reaches 685 beats/km in 2016, the athlete’s personal best year. From 2018–2024, as volume declines to 167 km/month in 2022 and 105 km/month in 2024, average HRE rises back to approximately 795–825 beats/km and minimum HRE drifts higher to 742–754. The paper interprets this as a clear signal of reduced training load and age‑related decline.

A short‑term example from August 2018, following injury, shows HRE improving from around 870–857 beats/km early in the month to about 758 beats/km by the end of the month, representing approximately a 10–15% efficiency gain over a few weeks of consistent, moderate training. Across the RunningAHEAD runners, experienced, high‑volume runners F and G maintain consistently low HRE at approximately 600–650 beats/km, while a low‑volume runner such as K shows low monthly distance and high HRE. The paper describes these patterns as support for the claim that HRE correlates with training volume and aerobic maturity [2509.05961].

Intra‑run analyses further show that in long, steady runs over 90 minutes on flat routes, well‑trained runners often maintain stable HRE throughout the session even when HR drifts upward slightly and pace varies. Less trained runners often begin with reasonable HRE but show degradation after 30–40 minutes. In marathons, “well‑fitted” races are characterized by low, stable HRE under approximately 700–750 beats/km, whereas “poorly‑fitted” races are associated with HRE above approximately 800 beats/km and late‑race degradation, especially after 30–35 km.

## 6. Interpretation, applications, and limitations

The practical uses proposed for Fitplotter and HRE center on longitudinal tracking, fatigue detection, pacing analysis, and coaching support. A downward trend in HRE over weeks or months at similar intensities and conditions is interpreted as improved aerobic fitness, while plateaus or upward drift suggest stagnation or regression. For long runs and races, upward within‑run drift may indicate starting too fast or being under‑recovered. The paper also suggests that runners can estimate a sustainable HRE band for marathon pace from prior long runs and races, and use post‑race HRE review to connect pacing decisions with “hitting the wall.”

The source is explicit that HRE is not context‑free. Hills increase HRE on climbs and decrease it on descents; heat and humidity elevate HR and thus HRE for the same pace. Fitplotter’s synchronized map is intended to help separate terrain‑driven HRE changes from fitness‑driven ones. This is an important corrective to the possible misconception that a transparent metric is automatically immune to confounding conditions.

The comparison with commercial metrics is framed in terms of transparency and trust. Commercial platforms often provide VO\(_2\)max estimates, training readiness, performance condition, training load, or body battery metrics, but these are described as proprietary and black‑box. HRE, by contrast, uses only two familiar, directly observable metrics, has a simple formula that can be computed by hand, and yields a physiologically intuitive quantity in beats per kilometer. From an HCI perspective, the paper argues that users are more likely to trust and act on feedback when they understand how it is computed, can see how it relates to their own data, and can verify improvements over time.

The limitations are also clearly stated. The findings are exploratory; the deep analysis centers on one primary athlete over 14 years, supplemented by 12 public runners and a small set of race logs. The analysis focuses on running, does not systematically examine age, health conditions, or gender, and does not yet tie HRE directly to gold‑standard laboratory measures such as lab‑measured VO\(_2\)max or lactate threshold. Proposed future directions include broader validation studies, integration of power, cadence, ground contact time, or perceived exertion, adjustment for elevation gain or environmental conditions, interface studies of daily HRE use, coaching dashboards, and extension to cycling, triathlon, or HRE‑like metrics such as beats per watt [2509.05961].

Taken together, Fitplotter can be understood as a privacy‑preserving, transparent analytical environment in which HRE functions as the central explainable metric. The paper presents it not as a replacement for physiological testing or as a universal performance score, but as a practical means of making long‑term endurance data inspectable, interpretable, and usable for reflective self‑monitoring.

Source: https://www.emergentmind.com/topics/fitplotter