明明爬了一段又短又陡的坡，爬升数字为什么几乎没动

先说结论

爬升这个数字不是直接从传感器读出来的,而是把一串高度读数加总出来的,加总之前,这些读数会先过一遍降噪:不这样处理,平地上普通的高度抖动就会被当成假的爬坡。这道降噪要猜测信号里哪部分是真实的高度变化,哪部分只是传感器噪声,而它的判断方式,大体上就是对又窄又突然的变化多留一个心眼。一段岩石台阶,或者几步就结束的快速攀爬,形状上恰恰就是「又窄又突然」。这类变化里的一部分,会跟噪声一起被磨平,这就是为什么记录下来的数字,会比腿告诉你的感觉要小。

在原始高度数据里，一段短而陡的爬升长什么样

所有报爬升的 App,用的都是同一种原始素材:轨迹上大致每个点都挂着一个高度值。一段缓慢展开的长坡,在这串数据里表现为连续几十个、上百个点稳稳地往上抬。而一段短而陡的爬升,形状完全不同——只有寥寥几个读数一下子跳上去,紧接着地面变平,读数也几乎同样快地重新落到一条平线上。如果只看数据本身的形状,不知道脚下的地面实际发生了什么,这种窄窄的尖峰,跟平地上 GPS 或气压计噪声常见的那种短促、剧烈的抖动,其实很难分辨。

保护平路的那道过滤，为什么也会让陡坡吃亏

任何 App 在把高度数据加进总数之前,都得先做某种过滤——不这样的话,一段彻头彻尾的平路,光靠传感器抖动就能攒出几十米的爬升。这道过滤通常的做法,是对短促、狭窄的变化多留一份怀疑:要么忽略掉只持续一两个读数的上下摆动,要么把曲线整体拉平一些,让一个短促的尖峰向它两边更平的地面靠拢。对付平地上真实的抖动,这样处理完全正确。问题在于,一段短而陡的爬升,形状上恰好也是个尖峰——于是同一套用来不让平路显得有坡的平滑处理,还没等数值加进总数,就先把一段真实的陡峭爬升削掉了一部分。

为什么缓慢展开的长坡，不会这样被削

一段缓慢展开、跨越很长一段路的坡,相对于 App 用来平滑数据的那个窗口来说是「宽」的,过滤能碰到的,基本只有坡的起点和终点这两头,中间那段又长又稳的上升几乎不受影响。而一段短而陡的爬升,论宽度反而跟过滤本来要清除的那种噪声更接近,所以落进同一个平滑窗口的比例要大得多。两段爬升的高度完全一样,最后计入总数的量却可能相差很大——不是因为哪一段测得更不准,而单纯是因为各自花了多长时间爬完。

什么时候值得多看一眼

• 一段你确信爬了实实在在高度的岩石台阶或攀爬,在高度曲线上几乎看不出来,而它两边比较缓的路段却看得很清楚——这就是上面说的正常情况,不代表记录出了问题。
• 一段路上连着好几个短而陡的爬升,总的爬升数字,明显比一段你知道爬了差不多高度、但更长更缓的坡要低——这是同一个原因造成的,在只靠爬升数字比较两条形状很不一样的路线时,值得留个心眼。
• 在你记得攀爬的那个位置,曲线本身确实有一小段短促陡峭的跳升——这说明真实的爬升其实留在了记录的数据里,只是没能完全算进总数。
• 体感和总数之间的差距很大,而且那段爬坡实际上并不短、反而挺长——这种情况不太符合这里说的过滤效应,更值得从别的原因去找答案。

和 TrailCam 的关系

TrailCam 会给每条记录的路线画出爬升曲线,放在地图下方,不管是正在记录还是之后回放都能看到,所以一段短而陡的爬升,可以直接在曲线上看到,而不只是看最后那一个总数。这条曲线和爬升总数,在把路线导出成 GPX 1.1 或 CSV 时都会带上,GPX 1.1 / CSV 导出是可选的 TrailCam Pro 里的功能;App 本身免费下载。