Saturday, December 23, 2017

「台灣登山氣象」新版公測啟動!



這個周末邊訓練邊寫扣,再加上幾個晚上熬夜之後,我們終於有新版本了。這一版主要提供了英文的使用者界面及氣象資料 (簡中界面也順便一起加入了)。能夠有英文的氣象資料主要是這個版本的雲端後台連接了中央氣象局在10月份釋出的 OpenData 界面,請透過簡單的兩個步驟協助我們找出潛在的問題:


這個秋天我們前往了日本攀登知名的劍岳及燒岳,然而卻找不到日本的山岳天氣預報。因此我們希望這個應用程式可能幫助使用外語的山友在台灣登山時,能更方便且有效率地取得台灣山區的天氣預報。

若您發現了任何問題或有其它建議,請不吝發信到我們的電子郵件信箱

(已知問題: OpenData 更新速度有時會比官網還慢)

最後,希望能有時間在下一個版本裡加入雷達回波圖了!(雙手合十)

Friday, June 23, 2017

台灣大地羅盤 2.0 發佈 Alpha 版

加入 Google Play 測試人員計畫立即體驗!

  1. 套用Material Design
  2. 將分享座標及傳送簡訊整合為同一畫面
  3. 在羅盤畫面中可啟動轉換工具
  4. 將羅盤校正功能移至選單
  5. 更精確地定位使用者所在地的管轄消防局
這次的改版應該是大地羅盤上架以來改動最大的一次,最大的差別就是在 UI/UX 上採用了 Android 最新的 Material Design 概念。

原本的一頁式設計雖然簡單乾淨,但也因此無法達成先前使用者提出的一些需求。例如想要在羅盤畫面直接開啟轉換工具,或者必須到系統設定中才能把羅盤座標改為TWD97 TM2等。

雖然還是會擔心有許多使用者已經習慣了原本的操作,比較不習慣 Material Design,不過為了讓 App 與時俱進,也開啟未來更多可能,還是決定做這次的改版。

除此之外,很高興在前些日子有志工加入了我們的開發者行列,也在這次利用國土測繪局的開放資料,完成了使用者所在地管轄消防局的精確定位功能。

不過為了達成這項功能,也讓原本的 Android 2.1 最低版本要求提高到了 Android 4.0。如果有朋友對於這需求有困難,可以跟我們說一聲,也許可以再想想辦法。

前些日子看到了日本的YAMAP平台,心中有許多感觸。未來大地羅盤及登山天氣也會著手開始進行國際化,希望有朝一日我們也能提供國外登山愛好者優值的工具 App。

若有任何問題或建議,還請提供給讓我們有改進的機會。^^

Tuesday, June 6, 2017

「台灣登山氣象」畢業了!


台灣登山氣象正式上架 Google Play!

Dija 的測試先進們應該多少都知道甚至使用過天氣預報的功能,而這個功能在前幾天從 Dija 之中拉出來並成為獨立的應用程式。

會進行這個變動有幾個原因:

  1. Dija 還在測試階段,命題有點廣,問題比較多,功能也都還在演進,不適合大量推廣。但天氣資料對山友很重要,所以獨立出來才能讓更多山友都受惠。
  2. 大量測試對改善我們的氣象資料雲端後台有很大的幫助,在穩定之後未來或許可以提供 OpenData 給其它 App 使用 (目前氣象局尚未開放登山氣象)。

然而 Dija 的天氣功能還是有一部份沒有移植到台灣登山氣象:

  1. 以簡訊查詢天氣預報,並以簡訊接收天氣預報。
  2. 預約天氣預報簡訊。

這兩個功能目前還是小規模實驗,主要是因為雲端後台需要負擔發送簡訊的費用,小規模測試還能負荷,但若使用者太多會需要導入收費機制才能確保長期營運。

再次感謝 Dija 測試人員一路來的支持,也期望我們的土地愈來愈好,山林愈來愈美。

Facebook 粉絲專頁成立啦

未來不論是Dija,台灣大地羅盤,台灣登山氣象,或其它相關消息都會發布在粉絲專頁

感謝舊雨新知一路以來的愛護及支持。

Wednesday, May 10, 2017

心血來潮的頭燈評測-Petzl MYO vs Fenix HL60R

手邊剛好多了一顆 Petzl MYO 頭燈,因為曾經聽說這顆法國設計的頭燈有使用「穩壓」晶片,心血來潮就拿另一顆請同學自大陸帶回的 Fenix HL60R 來個 AB Test 吧!

首先我們來大略了解一下這兩款頭燈:

Petzl MYOFenix HL60R
批西家售價3,3002,690
實測重量180g (含3顆Eneloop)151g (含一顆NCR18650B)
電池AAx3 (可使用充電電池)18650鋰電池x1 或 CR123Ax2
防水等級IPX4 (防潑水)IPX8 (水下兩米)
特殊功能各檔次亮度可調整/燈頭有散光片可使用行動電源充電/有兩顆小紅燈

大概把玩一下 MYO 後有幾個比較主觀的看法:
  1. 不管任何頭燈,只要是採用類似 MYO 這樣的分離式設計,防水性就佔不了優勢;外露的電源線似乎也比較可能去勾到樹枝或箭竹。HL60R 的防水性等級很高,但整體重量都集中在前面。且為了要散掉 LED 的高溫跟電池本身的發熱,必須採用鋁合金材質。
  2. MYO 的防誤按設計很貼心,因為 HL60R 在過去使用的經驗裡還蠻常發生誤按的。
  3. 加上散光片的 MYO 感覺很適合作為帳內光源,可以有效把光線打散打柔。相較之下 HL60R 的小紅燈亮度不足以作為帳內照明,但倒很適合夜間攝影。
  4. MYO 採用 AA 電池,在電池管理上可以跟 Garmin 的 GPS 共用電池。HL60R 的 18650 則可以透過 Nitecore F1/F2 這類產品來跟手機共用電池。
接下來就是一些客觀的量測了。首先,要提一個關於電池的冷知識:其實電池的電壓是隨著電量而變動的。(也有某些電池的電壓不太變動,但也因此無法推測電量)

電池上標示的電壓叫作「額定電壓」,原文是 Nominal Voltage。以鋰電池 (正式名稱應該叫鋰離子電池) 來說,雖然標示 3.6V 或 3.7V,但實際上充飽電時大約是 4.2V,用完時大約是 3.0V。額定電壓 1.2V 的鎳氫充電電池,則大概在 1.4V~1.1V 之間。

因此所謂的「穩壓」有點詭異,可能是原廠希望貼近消費者而採用的術語,又或者是其電路的某部份有進行變頻直流轉換。在後面的實驗結果,我們可以發現穩不穩「壓」其實不是重點,一顆好的頭燈應該呈現是「恒定亮度」及「恒定瓦數」。

早前朋友有送測一些較陽春的18650頭燈,價格在兩三百到千元以下的範圍內,測試後發現光電效率很差,而且亮度會隨著電池電壓下降而變暗。可以想見這樣的頭燈並沒有使用高效率的 LED 驅動電路,說到底也無法期待這樣的價錢能買到夠好的頭燈。然而像 MYO 或是 HL60R 這樣的價位,加上原廠的文宣,預期是應該具有高效率的 LED 驅動電路。

手邊的測試設備不多,主要有一台可程式的電源供應器,內建電壓及電流量測功能。除此之外,濫芋充數再用一支 Android 手機,透過其內建的照度感應器來量測照度。
  • 電壓:實驗時模擬單顆鋰電池及三顆鎳氫電池的電壓變化,從 4.2V 到 3.0V,每次調降 0.2V。
  • 電流:這台電源供應器最大可供應3A的電流,量測到的實際電流會用來推算功率 (瓦數)
  • 功率:利用電壓及電流來計算 (P=IV),若功率穩定則可以從電池電量 (mAh) 來推算使用時間。
  • 照度:特別要說明照度不是流明,照度會隨著距離而下降,而 LED 鏡片的聚光或散光也會大大影響照度。這邊量測出的照度及推算出的光電效率不能在不同款頭燈間作比較,只能用來與同一個頭燈的不同電壓間或不同檔次間作比較。
  • 光電效率:照度除以功率,用來概推每瓦可以提供的亮度。注意事項同上。
實驗場地,頭燈與照度計間的距離為 240cm

以下直接列出測試數據,首先是 Petzl MYO。測試時是聚光模式,不使用散光片。


接著是 Fenix HL60R,相較於聚光模式的 MYO,光型比較廣⻆。


以下則是個人對於上面數據的觀察與解讀:
  1. 不管是 MYO 或 HL60R,最亮的檔次都不太「穩」。特別是 HL60R,照度變化有點大,在電池電壓偏低時甚至達不到第二檔的亮度。猜測在最亮檔次時,兩款頭燈都沒有使用「穩壓」電路。(Petzl 的說明有實際提到最亮檔是 Standard Lighting 而非 Constant Lighting)
  2. 排除最亮的檔次,兩顆頭燈都呈現出極佳的「恒定亮度」。因此建議在使用頭燈時,可以的話盡量避免使用最亮檔次。特別是HL60R的最亮檔,不只是LED輸出到12W會有點燙,接近3A的大電流也會讓內阻較高的容量型18650產生較多廢熱。
  3. HL60R 除了「恒定亮度」之外也呈現出優異的「恒定瓦數」,可以想見它的電路設計非常用心。一顆 2600mAh 的鋰電池,大約是 3.7V x 2600mAh = 9.62Wh。以它的高亮模式來說,大約在 3.5W 左右,推算使用時間的話則是 9.62Wh / 3.5W = 2.75h,大約是2小時45分鐘。Fenix 原廠規格中的說明則是 2600mAh 電池可使用三小時,因此可以相信 Fenix 算是一家誠實不灌水的廠商。
  4. HL60R 不論哪個檔次,在 3.0V 時會自動進入節能模式。這時亮度會降很低然後閃紅燈,基本上再不換電池就要過度放電了。
結語

對我來說,一顆好的頭燈至少要呈現出「恒定亮度」的特質,而這兩款頭燈在這一點都表現優異。相信市面上也還有很多優質的頭燈產品,只是店面挑選時若要能鑑別出「恒定亮度」,可能要自己刻意帶著不同電量的電池跟照度計去店裡實測,當然也要店家願意給測才行。至於「恒定瓦數」這部份,就只能在實驗室中才能進行了。

不過我想同一家廠商的更高階產品或更新款產品,應該都會延續這些優點,希望這篇可以提供大家一些參考。

而這顆 MYO 接下來的命運會是什麼呢?我想我應該會把它改裝成使用 18650...

Monday, May 8, 2017

長天數縱走的電池管理

每次為長天數縱走打包背包前,就開始到處找插座把各式各樣的電池充飽。手機要用行動電源,GPS要用AA電池,頭燈要用18650鋰電池,單眼跟無線電則要用各自的專用電池。最後集中起來的電池多到就像要上山賣電一樣...

整合前的各種電子設備及電池

等等,這些不全都是鋰電池嗎?難道不能共用嗎?開始有了這個想法之後,有意無意間也開始留意相關資訊,或者著手開始DIY改裝,最後終於達成了可以用18650供應所有設備的目標。

整合成可共用18650鋰電池的成果

其中,無線電是在網路上購買車用假電池來改裝。車用假電池的內部是一個所謂的變頻式直流降壓電路,或者 DC/DC Buck,用來把車用的12V降壓成大約是兩顆鋰電池串聯的額定電壓7.6V。所以改裝的方向很簡單,只要把降壓電路取出,直接接上18650串聯電池盒即可。


使用兩顆18650的無線電

原本的12V點煙器接頭跟捲線依然可以留作車用,但需要加回拆下來的降壓電路或者到網路上另行購買降壓電路。


將降壓電路移出假電池後即可繼續在車上使用

單眼的部份則因為SONY單眼的DC接頭是特別規格,所以沒有辦法在光華買到。於是就在網路上購買它的直流電源,然而其實需要的只有它的接頭。電池盒則可以跟無線電共用,因為原廠電池也是兩顆鋰電池所組合成的模組。


使用兩顆18650的SONY A77

手機的部份就比較好辦了,原先其實是自行DIY,但後來因為找到了 Nitecore F1 這個產品。F1 基本上是一個可換電池的單槽18650行動電源,雖然單顆會比較需要更換電池,但因為體積很小,搭配短線後就可以跟手機一起收在腰帶的小口袋裡。


使用 Nitecore F1 充電的手機

當所有設備都可以使用18650時,電池管理就相較容易了。以我自己來說,無線電在登山時只設定為緊急用,所以基本上就不需要帶它的專用電池了。單眼的專用電池還是會帶,畢竟外接一個尿袋在操作上也會比較不方便,然而當專用電池沒電要救急,或者需要長曝或拍縮時的話,外接電池盒就很方便了。

最後,只要再大概算出手機跟頭燈需要使用的18650電池顆數,即可完成長天數縱走的電池管理。

關於18650電池,以下是一些個人的心得:

  1. 盡量買品質較高且容量較大的電池,有規格書的電池除了安全之外通常也都有較好的低溫耐受性
  2. 不需要買動力型電池,這類低內阻電池一般來說電量相對較少。一般即使是頭燈的極亮大約都只會用到3A的電流,以我手邊給吸塵器用的三星動力型電池來說,最大輸出高達22A實在是不符實際。
  3. 可以的話買有保護板的電池;雖然有些比較好的頭燈會內建過放保護功能,但DIY給無線電或相機使用的話就無法預期是否會被過度放電。
  4. 如果捨得買好電池,就別捨不得買好的充電器,因為充電電路的好壞攸關電池壽命。我自己是用 Nitecore D4,除了可以充一般 18650 之外也針對 IMR 動力型電池設計專用的充電程序,同時還可以充 AA/AAA 的鎳氫(NiMH)電池。

(未來若有時間的話,希望能評估可為鋰電池充電的太陽能週邊,特別是 PowerFilm 的軟板。)

Saturday, May 6, 2017

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 中整理後的成果

Thursday, March 16, 2017

關於累計爬升的小實驗

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

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

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

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

行義路單車

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

為了滿足好奇心,DIY 寫了支可以讀取 KML 來計算統計值的程式,其中加入了海拔修正的功能,因此跑出來的數據包含:
至於 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)