之前一直以為 cold start 的 TTFF (Time To First Fix) 至少需要 30 秒才能完成定位。這個認知來自於一個看似合理的邏輯：GPS 衛星需要傳輸完整的 5 個 subframe 才能提供所有必要的導航資訊,而每個 subframe 需要 6 秒,因此 5 × 6 = 30 秒。
然而,最近與晶片廠商合作時,他們提供的測試數據徹底顛覆了我的認知——TTFF 竟然有時候可以達到 25 秒!
初始的困惑
當我第一次看到這個數據時,內心是充滿質疑的:
“這怎麼可能?數據還沒傳完怎麼定位?”
“是不是測試方法有問題?”
“還是這根本不是真正的 cold start?”
帶著這些疑問,我開始找資料研究 GPS 導航電文的結構和定位計算的最低需求。(同時也去詢問晶片廠商確認)
GPS 導航電文結構回顧
讓我們先回顧一下 GPS L1 C/A 導航電文的基本結構:
- 1 個 Frame = 5 個 Subframes = 30 秒
- 1 個 Subframe = 10 個 Words = 6 秒
- 傳輸速率: 50 bps
各 Subframe 的內容
| Subframe | 內容 | 更新頻率 |
|---|---|---|
| Subframe 1 | 衛星時鐘校正參數、衛星健康狀態 | 每 30 秒 |
| Subframe 2 | 衛星軌道參數 (星曆) – 前半部 | 每 30 秒 |
| Subframe 3 | 衛星軌道參數 (星曆) – 後半部 | 每 30 秒 |
| Subframe 4 | 電離層模型、UTC 參數、Almanac | 每 12.5 分鐘 |
| Subframe 5 | 衛星健康狀態、Almanac | 每 12.5 分鐘 |
真相大白：18 秒的可能性
經過研究後我才恍然大悟：接收器要完成定位,並不需要等待全部 5 個 subframes!
定位所需的最低資訊
要計算出第一個位置座標,接收器實際上只需要:
- ✅ Subframe 1: 衛星時鐘校正參數 (6 秒)
- ✅ Subframe 2: 星曆資料前半部 (6 秒)
- ✅ Subframe 3: 星曆資料後半部 (6 秒)
也就是說,理論上最快 18 秒後就可以開始計算座標!
為什麼不需要 Subframe 4 和 5?
- Subframe 4 & 5 主要包含:
- Almanac (粗略的衛星軌道資訊,用於快速搜尋衛星)
- 電離層模型參數
- UTC 時間轉換參數
這些資訊對於提高定位精度和加速後續定位很有幫助,但並非第一次定位的必要條件。
實際的 25 秒 TTFF
那麼為什麼實際測到的是 25 秒而不是 18 秒呢?
這涉及到幾個實際因素:
1. 訊號捕獲與追蹤時間
- 接收器需要時間搜尋和鎖定衛星訊號
- 通常需要 2-5 秒
2. 資料解碼與驗證
- 需要正確解碼導航電文
- 進行 parity check 確保資料正確性
- 可能需要重傳錯誤的資料
3. 多顆衛星的同步問題
- 定位至少需要 4 顆衛星
- 不同衛星的 subframe 起始時間不同
- 需要等待所有必要衛星都傳輸完前 3 個 subframes
4. 位置計算時間
- 解算導航方程式
- 迭代計算收斂
因此,25 秒的 TTFF 是一個相當優秀的表現,代表接收器在捕獲訊號後,幸運地在較短時間內收集到了足夠的資訊。
實際應用的考量
雖然理論上可以在 18-25 秒內完成 cold start,但在實際應用中:
大部分情況 TTFF > 30 秒的原因
- 訊號環境不佳
- 都市峽谷效應
- 室內或遮蔽環境
- 多路徑干擾
- 可見衛星數量不足
- 需要等待更多衛星升起
- 某些衛星訊號品質不佳
- 接收器性能限制
- 訊號處理能力
- 天線靈敏度
- 演算法效率
- 初始條件不確定
- 完全不知道大概位置
- 時間誤差較大
- 需要更多資訊來確保定位可靠性
結論
這次經驗讓我學到:
- 理論最小值: 18 秒 (接收完 Subframe 1-3)
- 優秀表現: 25 秒左右
- 典型表現: 30-60 秒
- 困難環境: 可能超過 2 分鐘
GNSS 定位是一個理論與實踐結合的領域,很多時候我們習以為常的”常識”背後,其實還有更深層的原理值得探討。這次對 TTFF 的重新認識,也提醒我要持續保持好奇心和學習態度。
長知識了! 原來 cold start 不一定要等 30 秒,但實際上大部分時候還是會超過 30 秒。這就是理論與實務的差距啊! 📡🛰️