GpxFix Blog

Cadence Shows 90 Instead of 180: Why Running Cadence Comes Out Halved or Doubled

By Roy Lachica on October 20, 2026. Last updated October 20, 2026.

Your run shows an average cadence of 88. You know you run at about 176 steps per minute, and the watch said so during the run. Nothing is broken in your legs or your sensor, the file simply recorded cadence per leg instead of per stride, and whatever read the file afterwards took the number at face value. This is an old ambiguity in fitness data, and once you know which side of it you are on, the fix is trivial.

One foot or two, the ambiguity in one paragraph

Running cadence can be expressed two ways. As total steps per minute, both feet counted, which is what every coach and every watch screen means by cadence, typically 150 to 190 for runners. Or as revolutions per minute of one leg, which is exactly half of that, typically 75 to 95. Cycling settled this question long ago, cycling cadence is always crank revolutions per minute, normally 60 to 100. Running never settled it, so both conventions exist in the wild.

The GPX trackpoint extension that carries cadence stores a single number with no unit and no statement of convention. A file that says 85 could be a correct cycling cadence, a correct one-foot running cadence, or a wrong value, and nothing in the file says which.

Where the halved values come from

• Footpods and some running sensors report per-leg revolutions, which is their native measurement, and the export writes it straight through.
• Conversions between formats. TCX has both a generic cadence field, intended for cycling, and a separate running cadence extension. A careless conversion can write a running value into the cycling field, or copy a per-leg value as if it were per stride.
• Third-party apps and syncs that read from a phone or a health platform often normalise cadence to one convention, not necessarily the one your platform expects.
• Activity type confusion. A run recorded or exported with a cycling activity type gets interpreted with cycling assumptions, where 85 is a perfectly reasonable number and nothing looks wrong.

How to tell which problem you actually have

1. Compare with what the watch displayed during the run, that is your ground truth.
2. Look at the average. For running, 150 to 190 is normal, 75 to 95 means per-leg values, and anything around 350 means something doubled a value that was already correct.
3. Check the activity type in the file, since a run marked as a ride will be read with cycling assumptions, see why setting the correct activity type is essential.
4. Load the file into GpxFix and read the cadence figures in the summary, which always reports the raw recorded values, so you see what is genuinely in the file rather than a corrected display.

How GpxFix corrects it

The correction is part of the Just fix it pass. GpxFix checks whether the activity is a running type, then computes the average of all non-zero cadence values in the file. If that average comes out below roughly 95 steps per minute, the values are treated as one-foot cadence and doubled, point by point, to express the full stride rate. The result is written into the file itself, so the GPX you download carries the corrected numbers rather than relying on a viewer to interpret them. GpxFix tells you how many track points it changed.

Two deliberate limits are worth knowing. The check only applies to running activities, so a ride at 85 rpm is left alone, as it should be. And the summary view never applies the correction, it reports what the file actually says, so you can always see the original data before deciding to change it.

If your cadence is doubled rather than halved

Values around 340 to 360 for a run mean something already doubled a correct figure. There is no automatic halving in GpxFix, deliberately, because halving a legitimate value would do real damage and the two cases cannot be told apart with confidence in every file. The practical options are to remove the cadence channel with the Strip tool and leave the rest of the file intact, or to leave it and treat the number as unreliable. Stripping is also the right move when cadence is obviously garbage rather than merely in the wrong unit.

Why it matters beyond the number on the page

• Training analysis: cadence trends over weeks are one of the few form metrics that is cheap to track, and a halved series makes them meaningless.
• Comparisons between activities: if half your files use one convention and half the other, nothing lines up, see comparing activities.
• Running dynamics and efficiency estimates that take cadence as an input will be off by a factor of two.

Frequently asked questions

Is doubling the cadence inventing data?

No, it is a unit conversion. The recording measured your real stride rate, it expressed it per leg, and doubling restates the same measurement in the convention everything else uses. Nothing about your effort is changed, which puts it on the right side of the line discussed in the ethics of editing fitness data.

Why was my ride not corrected?

Because cycling cadence of 85 rpm is correct and doubling it would be wrong. The correction is limited to running activities on purpose.

My cadence is missing entirely, not halved

Then no sensor data was written for those points, which is the same class of problem as missing heart rate, see heart rate data missing or corrupted.

Does converting from FIT or TCX cause this?

It can, since both formats carry cadence in fields with different intended meanings. A conversion that preserves the values but not the convention is one of the common ways a file ends up halved, see FIT to GPX and TCX to GPX.

Cadence looking half of what you ran? Load the file into GpxFix, check the raw values in the summary, and run Just fix it. Related reading: fixing incorrect heart rate data and how to get accurate GPS and heart rate data.