GPS：方法NTPタイムインジェクションの仕組み
私は最近gps.confファイルの/system/etc/ディレクトリ。 NTP_SERVERの値をNTP通常の場所により近いサーバーに調整するとTTFFが改善されるようです。
LocationProviderクラスのソースコードを読み取ると、起動時にNTP serverから取得され、計算で「注入」されたように見えます。原子時計、および星座内のすべての人はいわゆる「GPS時間」に同期されます。受信機が4つ以上の衛星を取得すると、4つの未知数がある方程式を（何らかの方法で）解決します：x、y、z 、b;ここで、（x、y、z）は受信機の位置であり、bは受信機の内部時計と（正しい）GPS時刻との時差です。aが修正されると、受信機の時計は正しい時刻と同期します（間違っている場合は修正してください）。
これまでのところ、私はNTP時間注入が機能する方法に関するいくつかの質問があります：
- GPS時間は、おおよそTAI（国際原子時）にオフセットを加えたものです。これらの2回は地球の回転に依存しませんが、UTCは依存します。 NTPサーバーがUTC時間を返す場合、UTC時間からGPS時間を推測できますか？
- より近いサーバーからNTP時間を取得すると、GPS時間近似の「品質」がどのように向上しますか？
- 初期GPS時間値（NTP時間から推定）があると仮定すると、注入は何ですか？この時間値はx、y、zのみの方程式を解くために正しいと見なされますか？その場合、最初の修正は単なる近似でもありませんか？
- GPS時間の高品質の初期近似はどのようにTTFFを改善しますか？これは、品質が低いNTP時間で最初の修正が受け入れられないと見なされ、破棄されるためですか？
- おおよその初期位置を持っていると、次の正しい修正を取得するのに役立ちますか（satsのサブセットのみを聴くなど）。
ウィキペディアやその他の情報源を少し調べて、いくつか推測をさせてください。
はい、UTC時間からGPS時間を推測できます。 15秒ごとに送信され、約18か月に1回変更されるオフセットを知る必要があります。ソース： Wikipedia
NTPは正確な時間を提供しません。メッセージがクライアントからサーバーに到達する時間と、応答がサーバーからクライアントに到達する時間を測定します。これらの時間は、接続の遅延を計算するために使用されます。これは、受信時間のオフセットとして適用されます。これは対称ルートに対して機能します。ルートが非対称の場合、エラーが発生します。サーバーに近いほど、非対称性の可能性とレベルを下げ、エラーを減らします。ソース： Wikipedia 再び
NTP信号は、GPS修正の取得に直接使用されません。ただし、正確な修正を行うには、非常に正確なクロックが必要です。ここではナノ秒を話しています。 GPS衛星は現在のGPS時間を送信しますが、光の速度で移動する場合でも、多少の遅延があります。 GPS受信機は遅延が何であるかを知る方法がないため、複数の受信信号から近似する必要があります。送信されるたびに、クロックはより正確になります。そのため、最初から良い時間があればあるほど、正確な時計を得るために受信する必要がある時間信号が少なくなります。ソース： Wikipedia
3で十分に説明されています-クロック誤差が小さいほど、正しい時間を近似するために必要な信号が少なくなります。
ここではほとんど推測していませんが、おおよその位置を把握しておくと、衛星からの距離と遅延をより適切に見積もることができます。 （それが本当に使用されているかどうかはわかりません。）
私はそれが少なくとも少し理にかなって願っています;-)
私の答えは、あなたの質問のNTP側に焦点を当てます。GPSについては、 this PDF paper ミラビロスによるコメント。
その文書によれば、GPS受信機のウォームスタートについては、20秒以内の時間、100km以内の位置、25m /秒以内の速度、および暦を知る必要があります最大で数週間前のデータ。各衛星からエフェミライドデータをダウンロードする必要がありますが、GPS受信機のタイプに応じて30秒から3分かかります。
hot startの場合、エフェメライドデータも必要です（4時間有効です）。また、A-GPS経由でも利用できます（以下を参照）。
NTPプロトコルは、元のタイムソース（GPS、原子時計など）から始まるサーバーの階層を使用します。これはstratum-0ソースと呼ばれます。 NTPこのソースに直接接続されているサーバーはstratum-1と呼ばれます。これを上流サーバーとして使用するサーバーはstratum-2などです。1ミリ秒未満のエラーを達成するために特別な調整ハードウェアが必要です。 stratum-1サーバーの場合（CPU割り込みレイテンシ、シリアルポートレイテンシ、温度発振器の変更による）。
通常のネットワーク上の通常のハードウェア（飽和DSLリンクではないなど）を使用すると、約10ミリ秒の精度を達成できます。たとえば、 NTP pool は、サーバーが100ミリ秒以内の正確な時間を持っている場合、そのサーバーを有効かつ十分であると見なします。 NTPからの時間の精度は、あなたとNTPサーバーとの間の地理的位置に依存しませんが、層、そのサーバーの品質、サーバーはネットワークトポロジに基づいています。
Androidフォンは通常、少なくとも1秒の精度で時間を認識しています。 GSMネットワークを介した定期的な時刻同期、またはデータ接続（wifiまたはセルラー）が利用可能な場合、NTPを介して。
上記のアプリケーションの場合FasterGPS-NTPサーバーをより良いものに変更しても、TTFFの高速化には役立ちません。 NTPでは不可能なナノ秒以内の精度での時間。GPSチップのみがその精度で時間を追跡できます。Android TTTTを高速化するのに役立つのは：
- 20秒以内にAndroid電話
- Wifi経由またはGSMネットワーク（送信塔に基づいて数km以内）からのおよその位置を持つ
- A-GPS を使用すると、インターネット経由ですべてのGPS衛星の暦と天体暦の新しいコピーがダウンロードされるため、GPS衛星からダウンロードする必要はありません（天体暦では30秒、15分かかります）暦用）。 A-GPSを使用すると、ホットスタートを使用して、TTFFを10秒未満にすることができます。
Ianは、GPSレシーバーが実際にどのように機能するかに関係する答えであるとコメントしています。受信機は、受信機のクロックバイアスのより正確な推定値を持っていると、より迅速に解決策を見つけます。多くの受信機は、受信機の位置とクロックバイアスの初期推定に依存する反復ソリューションを実装しています。これらの推定値がすでに真の値に近い場合、必要な反復は少なくなります。これは、TTFFが少なくなる理由の一部にすぎません。他にも重要な要素があります。初期の位置と時間の推定値が良好な場合、受信機はどの衛星を表示するかを計算できるため、衛星信号を取得するための検索プロセスにかかる時間が大幅に短縮されます。受信者の参照フレームに。