明明爬了一段又短又陡的坡，爬升數字為什麼幾乎沒動

先說結論

爬升這個數字不是直接從感測器讀出來的,而是把一串高度讀數加總出來的,加總之前,這些讀數會先經過某種降噪處理:不這樣做,平地上普通的高度抖動就會被當成假的爬坡。這道降噪得猜測訊號裡哪部分是真的高度變化,哪部分只是感測器雜訊,而判斷方式大致上,就是對又窄又突然的變化多留一個心眼。一段岩石階梯,或是幾步就結束的快速攀爬,形狀上恰好就是「又窄又突然」。這類變化裡的一部分,會跟雜訊一起被磨平,這就是為什麼記錄下來的數字,會比腿告訴你的感覺還要小。

在原始高度資料裡，一段短而陡的爬升長什麼樣子

所有回報爬升的 App,用的都是同一種原始素材:軌跡上大致每個點都掛著一個高度值。一段緩緩展開的長坡,在這串資料裡會表現成連續幾十個、上百個點穩穩地往上抬。短而陡的爬升,形狀完全不一樣——只有寥寥幾個讀數一下子跳上去,緊接著地面變平,讀數也幾乎同樣快地落回一條平線上。如果只看資料本身的形狀,不知道腳下的地面實際發生了什麼,這種窄窄的尖峰,跟平地上 GPS 或氣壓計雜訊常見的那種短促、劇烈的抖動,其實很難分辨。

保護平路的那道過濾，為什麼也會讓陡坡吃虧

任何 App 在把高度資料加進總數之前,都得先做某種過濾——不這樣的話,一段徹頭徹尾的平路,光靠感測器抖動就能累積出幾十公尺的爬升。這道過濾通常的做法,是對短促、狹窄的變化多留一份懷疑:要嘛忽略只持續一兩個讀數的上下擺動,要嘛把曲線整體拉平一些,讓一個短促的尖峰往它兩側較平的地面靠攏。對付平地上真實的抖動,這樣處理完全正確。問題在於,一段短而陡的爬升,形狀上恰好也是個尖峰——於是同一套用來不讓平路顯得有坡的平滑處理,還沒等數值加進總數,就先把一段真實的陡峭爬升削掉了一部分。

為什麼緩緩展開的長坡，不會這樣被削掉

一段緩緩展開、橫跨很長一段路的坡,相對於 App 用來平滑資料的那個範圍來說是「寬」的,過濾能碰到的,基本上只有坡的起點和終點這兩端,中間那段又長又穩的上升幾乎不受影響。短而陡的爬升,論寬度反而跟過濾本來要清掉的那種雜訊更接近,所以落進同一個平滑範圍裡的比例要大得多。兩段爬升的高度完全一樣,最後計入總數的量卻可能差很多——不是因為哪一段測得比較不準,單純是因為各自花了多長時間爬完。

什麼時候值得多看一眼

• 一段你確信爬了實實在在高度的岩石階梯或攀爬,在高度剖面上幾乎看不出來,而它兩側比較緩的路段卻看得很清楚——這就是上面說的正常情況,不代表記錄出了問題。
• 一段路上連著好幾個短而陡的爬升,總爬升數字明顯比一段你知道爬了差不多高度、但更長更緩的坡要低——這是同一個原因造成的,在只靠爬升數字比較兩條形狀很不一樣的路線時,值得留意。
• 在你記得攀爬的那個位置,剖面線本身確實有一小段短促陡峭的跳升——這說明真實的爬升其實留在了記錄的資料裡,只是沒能完全算進總數。
• 體感和總數之間的落差很大,而且那段爬坡實際上並不短、反而挺長——這種情況不太符合這裡說的過濾效應,更值得從別的原因去找答案。

和 TrailCam 的關係

TrailCam 會替每條記錄的路線畫出爬升剖面,放在地圖下方,不管是正在記錄還是之後回放都能看到,所以一段短而陡的爬升,可以直接在曲線上看到,而不只是看最後那一個總數。這條剖面和爬升總數,在把路線匯出成 GPX 1.1 或 CSV 時都會一起帶上,GPX 1.1 / CSV 匯出是可選的 TrailCam Pro 裡的功能;App 本身免費下載。