GnssClock 結構體參考資料
#include <
gps.h
>
資料欄位 |
|
size_t | size |
GnssClockFlags | flags |
int16_t | leap_second |
int64_t | time_ns |
double | time_uncertainty_ns |
int64_t | full_bias_ns |
double | bias_ns |
double | bias_uncertainty_ns |
double | drift_nsps |
double | drift_uncertainty_nsps |
uint32_t | hw_clock_discontinuity_count |
詳細說明
欄位說明文件
double bias_ns |
double bias_uncertainty_ns |
double drift_nsps |
double drift_uncertainty_nsps |
int64_t full_bias_ns |
自 1980 年 1 月 6 日 00:00 世界協調時起,GPS 接收器內的硬體時鐘 (「time」欄位) 與實際 GPS 時間的差異,以奈秒為單位。
值的符號由下列方程式定義:GPS 時間的本機預估值 = time_ns - (full_bias_ns + bias_ns)
如果接收器有預估 GPS 時間,則必須提供這個值。如果計算的時間是針對非 GPS 星座,則必須套用該星座與 GPS 的時間偏移值,才能填入這個值。這個值和 bias_ns 的總和誤差估計值為 bias_uncertainty_ns,呼叫端負責使用這個不確定值 (在 GPS 時間解決之前,這個值可能會非常大)。如果資料可用,則「標記」必須包含 GNSS_CLOCK_HAS_FULL_BIAS。
uint32_t hw_clock_discontinuity_count |
如果硬體時鐘有任何中斷情形,則必須填入這個欄位。
「不連續」是指從一個時鐘來源切換到另一個時鐘來源的情況。單一自由運作晶體振盪器 (XO) 通常不會有任何中斷情形,因此可以將此值設為 0。
不過,如果 time_ns 值 (硬體時鐘) 是從組合來源衍生而來,而該來源不像一般 XO 那樣流暢,或以其他方式停止及重新啟動,則每次發生中斷時,這個值都會增加。(例如,這個值可能會在裝置開機時從零開始,並在時鐘連續性發生變化時遞增。在這個值達到全尺度的情況下,需要使用捲動 (而非夾持),這樣在後續中斷事件期間,這個值才能持續變更。
雖然這個數字在 GnssClock 報告之間保持不變,但可以放心假設 time_ns 值一直在持續運作,例如來自單一高品質時鐘 (類似 XO 或更優質,通常用於持續 GNSS 信號取樣)。
尤其是在 GNSS 訊號較少的期間,硬體時鐘應盡可能避免中斷,這樣一來,當您使用連續 GnssData 報告的隨附測量資料時,就不會需要使用 (浪費) GNSS 測量資料來完全解決 GPS 時鐘偏差和漂移問題。
int16_t leap_second |
int64_t time_ns |
double time_uncertainty_ns |
這個結構體的說明文件是由下列檔案產生:
- hardware/libhardware/include/hardware/ gps.h