Garmin inReach MINI 實測心得分享

(本文同步發表於靠北登山)

原本過年期間預計要走馬博橫斷, 但因天氣預報不佳中途就撤退, 途中因緣巧合也遇到這次八通關事件的當事人, 在當時甚至也曾動過念頭應該把這次借測的衛星通訊器交給他, 因為這位大哥只有一個人. (還好事件圓滿落幕, 否則我也不知道該不該分享.)

inReach Mini 跟 GoPro Hero 3 的大小比較

最後當然沒有借出, 因為這裝備是借來的, 也需要先行測試並熟悉, 更需要先在手機裡安裝App才能使用完整功能. 但也請有獨攀習慣或有計畫獨攀的山友可以繼續看下去, 因為這可能是目前獨攀者最適用的解決方案 -- Garmin inReach Mini.

靠北的重點是自己實在見識淺薄, 還好有神人願意出借黑科技裝備讓自己增廣見聞, 也跟大家分享一下也是台灣之光的 Garmin 推出(併購)的 Iridium 銥衛星追蹤通訊器. 以下是它的運作方式:

1. inReach 本身算是一個留守平台, 登山隊伍可以設定定時發送位置的頻率, 因此山下的留守人就可以追蹤位置. 例如這次我設定了30分鐘一個點, 依官方資料這樣可以持續使用50小時, 因此每晚到達山屋或營地之後再幫它用行動電源透過 Micro-USB 充飽電就可以了.
2. 發送位置時 inReach 會先透過 GPS 衛星 (沒有GLONASS/Galileo/準天頂或北斗喔) 取得座標, 再透過 Iridium 銥衛星送出座標.
3. 留守人可以在 inReach 的網站上即時看到登山隊伍的最新位置, 圖1中的截圖裡比較大的圓點是透過銥衛星送出的定時座標, 比較小的則是透過藍牙跟手機連線後透過3G/4G送出的精細座標, 而對話窗的時間大概就是我們撤退回程時遇到何大哥的位置與時間.
4. 除此之外, inReach 還提供了查詢天氣預報的功能, 圖1裡有很多插紅旗的位置就是事先設定好的航點, 用來作為查詢天氣預報的位置. 不過基本的天氣預報只有2天以內, 也會用掉1則訊息的額度, 但在通訊不佳的深遠山區或已足夠. 如果臨時需要更多天數的天氣預報, 也可以用每則美金1元(約台幣30元)的價格取得7天內的天氣預報.

圖1

整個來說, inReach 跟我們先前提出的 Dija 抵家實驗性服務很像, 差別是 Garmin 用的是 Iridium 銥衛星黑科技.

雖然 Iridium 銥衛星有支援衛星電話, 但 inReach 並不支援電話功能, 只支援文字訊息, 分別是簡訊跟電子郵件. 然而簡訊的中文支援有點問題, 至少在 Android 手機上測試並無法傳出中文內容的訊息, 但英文可以; 電子郵件的部份則中英文都沒問題.

以下再簡單列出一些銥衛星的特點:

1. 不同於舒拉亞等同步衛星系統(GEO), 銥衛星是採用低軌道衛星系統(LEO). 如果地球大概是一個籃球場大, 同步衛星系統大概在2"公尺"外, 而低軌道衛星系統大約就在4"公分"外, 因此通訊干擾相對少很多.
2. 同步衛星系統一般採用3顆在"赤道"上空跟地球自轉同步的衛星, 涵蓋美洲, 歐洲, 亞洲三個主要地區, 但無法涵蓋南北極. 並且有角度限制, 例如對台灣來說衛星都在偏南方的天空. 銥衛星則採用66顆低軌道衛星繞著地球, 隨時都會有衛星飛越上空, 包括極地, 而且沒有角度限制.
3. 銥衛星原本已聲請破產, 但因美國政府援助而東山再起, 目前美國國防部是其最大客戶.
4. 銥衛星目前已經更新為第二代系統, 主要都由特斯拉的姊妹公司 SpaceX 發射升空. 未來特斯拉的執行長 Elon Musk, 現實生活中的鋼鐵人, 甚至計畫發射12,000顆低軌道衛星建立Starlink衛星網際網路.

接下來則是這次 inReach Mini 的不專業使用觀察及心得:

1. inReach Mini 機器本體定價350美元(約10,500台幣)
2. 每個帳號開通費為20美元(約600台幣)
3. 費用有多種計價方式, 這次使用的是35美元(約1,050台幣)可使用一個月的計費方式, 其中包含40封文字訊息及無限制的追蹤航點. 其它還有更便宜及更貴的計價方式, 可參考這個網頁比較下面的部份: https://explore.garmin.com/en-US/inreach/
4. inReach Mini 機身本身就防水, 很輕也很省電, 但需要配合手機App才能發揮完整功能, 例如天氣預報點也要事先建立好.
5. 沒有門號, 留守人需要上 inReach 網站才能發送或回覆訊息給登山隊伍. 多台 inReach 之間的互相通訊需要透過類似電子郵件的 inReach 位址, 例如: example@inreach.garmin.com
6. inReach Mini 可以透過App直接傳送簡訊給手機門號, 但中文支援有問題. 回覆時則需要透過 inReach 網站, 無法直接由接收方簡訊App回覆.
7. inReach Mini 可以直接透過App傳送電子郵件, 中文沒有問題. 回覆時一樣需要透過 inReach 網站, 無法直接由接收方電子郵件App回覆.
8. 然後是目前對於獨攀者來說可能是無可取代的功能: 即使登山者因為意外而失去意識, 只要 inReach 有開啟追蹤功能, 在電力用盡前它都會持續傳出座標.
9. 接下來應該也是無可取代的功能: 留守人可以在 inReach 網站上主動要求機器回報位置 (抓猴神器!?)
10. 最後重點來了: 即使 inReach 在歐美日都合法上市了, 但在台灣卻是 NCC 從來沒審核過的東西. 所以如果真的有需求, 可能要避免直接從國外郵寄進來, 以免被海關扣下並需要跟 NCC 進行冗長的文書作業才能贖回.

以上是初次接觸衛星通訊的粗略心得分享, 如有理解錯誤再請前輩們指正. 目前想到幾個應該能適用的情境:

1. 長程縱走: 中間可能沒有手機收訊
2. 出國登山: 手機可能漫遊的電信公司沒收訊, 天氣預報因為語言或習慣而不易取得.
3. 獨攀: 這就不多說明了.

雖然山永遠在, 現在路卻斷得亂七八糟. 但至少我們有先進的服裝, 裝備跟科技, 因此也可以走出不同於前人的登山方式. 但終究我們的安全都是自己的責任, 也請大家上山前務必做好準備, 都能快樂出發也平安回家.

定位科技的迷思

(本文同步發表於靠北登山)

我要靠北 "基地台定位", "AGPS", 跟 "LINE定位" 被認為有害, 首先我想強調:

科技是中立的

今天如果有山友在求救前關掉了網路才開始用GPS定位, 此時他也關掉了AGPS (透過網路輔助的GPS) 能帶來的最大好處: 大幅縮短GPS首次定位所需要的時間 (即使只有一支基地台)

那首次定位 (TTFF - time to first fix) 需要多久呢? 最長可能要花12.5分鐘.

假設很不幸地這位山友在TTFF完成前昏迷了, 錯失了求救的機會, 那麼我們也要呼籲所有人不該使用GPS? 因為它的定位速度太慢, 是個害人的科技.

但有類似的案例嗎? 沒有, 因為如果真的有, 也沒有機會被知道.

因此:

1. 如果有人因為後方交會法把磁偏角算反了而錯失救援, 那指北針跟地圖也應該被禁止.
2. LINE的定位, 這又是另一個關於準確度故事了. 

用LINE求救已經有實例證明可行, 為何不建議LINE把位置資訊加上準確度? 今天消防單位, 搜救單位, 或留守人收到的位置準確度不足的話, 可以立即引導求助者 (特別是有搜救專業的公機關):

"我們已經收到約略位置, 請保持冷靜並試著等待準確度在50公尺以下再次送出位置."

Q: 準確度500公尺的定位真的沒有用嗎?
A: 首先至少可以確認熱區, 所以我們可以先在地圖上畫一個圓. 若當事人能自述在步道, 稜線或溪流附近, 或能從座標或當事人的氣壓錶得知海拔資訊, 就能推算出約略在哪條等高線上. 於是搜索"面"就可以收斂成搜索"線", 原理等同於紙本地圖定位的扶手欄杆法.

假設新聞沒有誇大, 那更真確的例子就是黑鷹事件是在LINE回報位置不準確的情況由"專業搜救團隊"修正定位而在12小時內結束任務.

結論: LINE定位的問題是它沒有提供準確度, 結果現在連AGPS也一起背黑鍋了.

鄉親啊! 台灣大地羅盤只有3萬多個Android使用者, LINE在台灣有2100萬的雙平台用戶, 讓我們一人一個 App 評價 (但拜託不要給人家一顆星我也是開發者), 建議LINE在分享跟接收位置都能明確看到準確度.

2020一起下架台灣大地羅盤啦!! (咦

Dija 抵家－北二段實測

五一連假前，為了能夠在高山上進行抵家的測試特別加緊趕工了一些功能，希望能透過這次機會評估是不是能夠讓抵家作為 OruxMaps 的替代方案。

然而為什麼會設定這樣的目標呢？主要是因為在上次的能高安東軍行程中，升級到 7.0.x 後的 OruxMaps 在許多操作上都令人感到不便，於是開始思考也許加入一些進階的功能後，抵家或許能夠取代 OruxMaps。

其中最主要的，是加入 Rudy Chung 大大所維護的 MOI.OSM Taiwan TOPO 地圖。原先所使用的 OpenAndroMaps 台灣地圖，首曲線是20公尺，這樣的等高線間距自己感覺對於登山活動還算勉強夠用。但主要問題是它的地形起伏是來自SRTM3，水平解析度大約只有90公尺，因此許多稜線跟谷線在地圖上都消失了。相較之下，MOI.OSM Taiwan TOPO 採用了內政部的20公尺地形模型，再加上10公尺的首曲線，真的是登山者之福。

這次測試大約是這樣進行的：

1. 將上河地圖上的水源及營地 (二度分帶座標) 輸入抵家成為地標。
2. 將網路上找到的 GPX 檔匯入抵家。
3. 每天的行程都使用抵家紀錄航跡，但大部份時間都使用飛航模式。

電力的部份每天大約都用到剩下20%左右，感覺起來似乎有比之前用 OruxMaps 時還要耗電，這部份是因為航跡參數設定或者我的 S7 電池已經老化，可能還要再觀察跟了解。

測試的結果還算是令人滿意，途中遇到不少路跡不明的狀況，基本上都能透過抵家確認正確的方向。而其中一段，因為沒有路條也沒有路跡，在現場對照底圖的路線、匯入的航跡後確認了是新的崩塌。此時也就知道，不需要再找路條或疊石了，而是要設法找路上切到坳口再作下一個打算。

崩塌造成的路徑改變

當然實測過程中也有很多感覺可以改進的，在後續的版本中或許都會陸續作調整。

1. 航點跟地標也許應該合併
2. 也許應該在地圖上顯示航點名稱
3. 自動航點太多時有點造成干擾
4. 測量距離的操作不太順利
5. 地圖載入速度有點慢

然而同時也在思考，在加入了這麼多功能後，似乎也讓抵家出現了學習門檻。所以未來在加入更多功能的同時，似乎也要同時考量到如何維持簡單易用的目標了。

航跡在 Google Earth 中整理後的成果

(GPS 航跡下載)

關於累計爬升的小實驗

在天氣好的時候，回家後只要還有空，幾乎都會騎單車沿著行義路騎到陽明山的小七當作日常運動。同時，我幾乎都會打開 Runkeeper 來作紀錄。某天忽然注意到，當儲存活動時它圖表裡的海拔爬升會先是 0，然後過一會兒才出現數值。

後來用估狗一查，發現原來 Runkeeper 要先把座標送到一個叫作 Topocoding 的網路服務，取得海拔 (Elevation) 之後才開始計算爬升值。

Runkeeper 的圖表

那麼為什麼不直接用 GPS 紀錄到的高度值 (Altitude) 呢？GPS 不準嗎？我想應該不是每台GPS都不準，猜測主要是因為 Runkeeper 為了要讓你跟自己的其它行程比較，或跟朋友進行比較，因此需要一個共同的海拔基準。意思就是，即便 Topocoding 的海拔本身沒有很準 (在台灣)，至少拿來比較是可以比較出活動強度的。

一時興起拿了幾個軟體來計算兩筆 GPS 航跡，這兩筆分別是從兩支不同手機裡的同一個 APP 所紀錄下來。APP 並未對原始數據進行處理，但紀錄者是否有調整過最短距離及最少時間則不得而知。其一是單車從天母沿行義路往上騎至陽明山總站旁的小七，另一則是從南安登山口健行瓦拉米。第一個行程的原始數據基本上還蠻平滑的，即使各家數據有差但尚可接受。然而第二個數據原始數據看起來很「跳」，各家呈現的結果也非常戲劇化。

行義路單車

瓦拉米健行

怎麼會差這麼多？走過瓦拉米的山友大概都會覺得爬升 2870 甚至是 2026 都有點誇張！

為了滿足好奇心，DIY 寫了支可以讀取 KML 來計算統計值的程式，其中加入了海拔修正的功能，因此跑出來的數據包含：

• 無海拔修正 (使用GPS原始值)
• Google Elevation API
• MapQuest Elevation API
• 內政部20公尺網格DTM (使用 Rex Tasi 轉出的 WGS84 格式)

至於 Topocoding 則因為它只能在網站裡執行因此在這裡無法列入比較。

首先來看一下最高及最低海拔的部份。

行義路單車

瓦拉米健行

從實驗結果大概可以發現，OruxMaps 及綠野遊蹤都沒有進行海拔修正，即使我在 OruxMaps 中加入了「在線高度服務」或在綠野遊蹤中加入了 HGT 檔，統計結果都沒有改變，猜想這部份的修正只會套用在正在紀錄的航跡。而 Google Earth 看起來是會修正海拔的，而且數值跟使用 Google Elevation API 一致。合理推測，即使不是使用 Google Elevation API，至少數據來源相同。

問題來了：如果 Google Earth 有進行海拔修正，而且修正的結果也跟內政部DTM差不多，基本上修正的準確度應該是足夠的。然而瓦拉米健行的爬升值還是令人感到意外，到底海拔修正對於統計值到底有沒有幫助？我們直接使用手邊最正確的海拔資料來源，也就是內政部20公尺網格DTM來進行比較。

行義路單車

瓦拉米健行

結果非常出人意表：經過最精確修正的海拔竟然算出最誇張的結果。難道海拔修正是豬隊友嗎？我們展開海拔值來看看。

行義路單車

瓦拉米健行

從行義路單車的圖表看來，GPS 在一開始時海拔錯誤很大，這部份套用了海拔修正是有幫助的。另外我們也可以發現，相較於 MapQuest Elevation API，Google Elevation API 比較接近內政部DTM而且也比較平滑。而 MapQuest Elevation API 不只誤差有點大，而且修正完比原本更「跳」；除此之外同是線上服務，MapQuest Elevation API 的速度非常慢，真的可以說是豬隊友。

此外，修正完的結果似乎也打臉了 Runkeeper。在最前面的手機截圖中我們可以看到行義路單車的高度剖面是未修正的。至於為何與網站上宣稱的不同，也許是 Topocoding 沒有台灣的資料？其根本原因就不在本文的討論範圍內了。

接下來，我們來比較一下不同日期同一路線同一支手機紀錄下來的行義路航跡。

行義路單車

從圖表來看海拔修正真的是有幫助的。原本明明是同一路線，但一開始的海拔差異還蠻大的；在經過海拔修正後，兩者的差異就變小許多。

所以除了 MapQuest 之外，海拔修正不應該是豬隊友。為了更深入探討，在程式計算累計爬升及下降時加入了低通濾波器，用來進行曲線平滑化。其中的 Alpha 參數由 0.1~1.0，值愈小愈平滑，1.0 則代表不做平滑處理。

行義路單車

瓦拉米健行

從數據上大概可以看出，OruxMaps 的統計值大約等於 Alpha 值 0.2 的結果。而綠野遊蹤的統計值大約等於 Alpha 值 0.9~1.0 的結果。而 Google Earth 這邊有點特別，即使可以推測是採用 Google Elevation API 的 DTM，但卻無法對應到某個 Alpha 值。

從手邊另一筆有問題的航跡來推測，原因可能是因為 Google Earth 有進行 Resampling 的處理。

武嶺單車

剖面圖中被選取的部份是 GPS 紀錄因為不明原因中斷的路程，如果直接使用原始資料的話，剖面圖應該會是一條直直的斜坡才對。然而在 Google Earth 上則在地圖上畫出一條沿地表投影的紅線，然後在剖面圖中是有高低起伏的。然而若要考慮 Resampling 則需要更多的時間另開支線任務來討論，在此就先行打住。

綜合以上的實驗，大概可以觀察出：

1. OruxMaps 的統計值「未進行海拔修正」且「經過高度平滑處理」。
2. 綠野遊蹤的統計值「未進行海拔修正」且「經過低度或無平滑處理」。
3. Google Earth 的統計值「有進行海拔修正」且「重新取樣過」，但平滑處理尚未能得知。

也能歸納出一些結論：

1. 相同的 GPS 裝置即使在相同路線也可能會紀錄出差異很大的航跡，更不要說是不同型號的機器了；另外，也不能排除某些裝置在紀錄時已經做過海拔修正甚至是平滑處理的可能性，畢竟低通濾波器在訊號處理中是極為常見的。
2. 海拔修正不能確保「統計值」的正確性，但可以確保「海拔值」的正確性，也能讓不同航跡在進行比較時有「一致性」。
3. 要取得合理的統計結果，某程度的平滑處理是必要的。但 OruxMaps 採取的高度平滑處理或許過猶不及，可能會低估像聖稜線這樣在短距離內有很多起伏的路線。

因此，當自己的航跡要提供給其它人參考，或取得其它人的航跡來參考時，建議先進行海拔校正來取得一致性。然而在比較的時候，最好是使用相同的程式。

簡單地說，就是當你想要比較北一段跟北二段的總爬升時，不要拿北一段在 OruxMaps 裡的統計值跟北二段在 Google Earth 裡的統計值做比較。

註：目前 GPS Visualizer 有提供線上服務可以上傳 KML 或 GPX 轉為海拔修正過的 GPX 格式。但測試程式暫時只能讀取 KML 所以無從與內政部20公尺網格DTM作比較。

(原始統計數據請參考：Google Drive)