測位方法
【課題】 ＧＰＳ受信機用リアルタイムクロック
【解決手段】 ナビゲーション衛星受信機は、ＧＰＳシステムの高精度の時間ベースに対してスレーブとなることができるリアルタイムクロックを備える。そういう時に、補正量及び動作温度が観測される。後でリアルタイムクロックがＧＰＳの時間ベースのスレーブになれなくなると、周波数エラーに最も影響するのは動作温度であると想定している。受信機のパワーダウン時でも、リアルタイムクロックは通電状態に保たれる。自走周波数は温度補正される。次回受信機をパワーアップすると、他の受信機の初期化処理に使用できるように一日の誤差が１ミリ秒以下の精度の時刻を即時に得ることができる。
【解決手段】 ナビゲーション衛星受信機は、ＧＰＳシステムの高精度の時間ベースに対してスレーブとなることができるリアルタイムクロックを備える。そういう時に、補正量及び動作温度が観測される。後でリアルタイムクロックがＧＰＳの時間ベースのスレーブになれなくなると、周波数エラーに最も影響するのは動作温度であると想定している。受信機のパワーダウン時でも、リアルタイムクロックは通電状態に保たれる。自走周波数は温度補正される。次回受信機をパワーアップすると、他の受信機の初期化処理に使用できるように一日の誤差が１ミリ秒以下の精度の時刻を即時に得ることができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はナビゲーション衛星受信機に関し、より具体的には、起動直後の受信機の時間の不確定さを減らすことによってナビゲーション衛星受信機の初期定点化時間（電源投入から最初の測位までの時間）（time-to-first-fix）を向上させるための方法並びにシステムに関する発明である。
【背景技術】
【０００２】
全地球測位システム（ＧＰＳ）受信機は、ユーザの位置及び速度、その他のナビゲーションデータを判定するのにＧＰＳ衛星群の中のいくつかの地球の軌道を回る衛星から受信した信号を使用する。従来技術のナビゲーション受信機では、電源投入直後、その現在位置、現在時刻、或いは水晶発振器にどのくらいの誤差があるか分かっていない。これらは全て、衛星の送信を見つけ出して捕捉するのに必要だから、その可能性のあるところの探索を行なわなければならない。時間の節約のために最も有望な候補が先ず最初に探索される。
【０００３】
高感度ＧＰＳ受信機は、初期の時間及び周波数の不確定性が大きいときに問題になる。信号のエネルギーが極めて弱いときに信号エネルギーを見出すにはステップを小さくし且つステップ毎に留まる時間を長くしなければならない。そこで、ローカルの基準発振器の初期推定値がより優れているとそれだけ初期測位の時間を短くすることができる。
【０００４】
−１４５ｄｂｍ以上の信号レベルを有するＧＰＳ受信機は、ナビゲーション（ＮＡＶ）データを解読するのに強力なＧＰＳ衛星（ＳＶ）を容易に捕捉することができる。そうすることによりＧＰＳ衛星の衛星暦及び位置を得ることができる。その後、ハードウェアのコード位相から全擬似距離を形成しなければならない。従来のＧＰＳ受信機は整数ミリ秒及びいわゆるＺカウントを判定する。
【０００５】
信号レベルがほぼ−１４５ｄｂｍから−１５０ｄｂｍにも満たないとき、実用の高感度ＧＰＳ受信機ではエニウェア（anywere）測位のためにＺカウント或いは整数ミリ秒を得るのにパターンマッチングを採用する。
【０００６】
一つ以上のＧＰＳ衛星を捕捉して追跡しているＧＰＳ受信機は時刻を非常に高度な精度で知っている。これはＧＰＳシステムが原子時計に基づいているからで、原子時計は使用する時間及び周波数の基準値を設定する。ＧＰＳ衛星から送信されたコースアクイジション（Ｃ／Ａ）コードは１ミリ秒の伝搬波長毎の繰り返しなので、ＧＰＳ受信機がどのミリ秒を観測しているかに関して基本的なあいまい性がある。例えば、時刻を１ミリ秒よりも正確に知っているなど、整数ミリ秒が分かっている場合には、整数あいまい性を解く必要はない。Ｚカウントが分かっている。Ｚカウントを見つけて整数ミリ秒を設定するステップを飛ばすことによって、ＧＰＳ受信機がコールドスタートから最初にナビゲーション解の測位を実現する作業でかなりの時間と労力を節約することができる。
【０００７】
【特許文献１】米国特許第５，７８１，１５６号
【発明の開示】
【発明が解決しようとする課題】
【０００８】
従って、本発明の目的は、パワーダウン後時間を記録することによってナビゲーション衛星受信機をより高速に初期化するためのリアルタイムクロックを提供することである。
【０００９】
本発明のもう一つの目的は、ナビゲーションデバイスの初期化に必要な時間を短縮するための方法並びにシステムを提供することである。
【００１０】
本発明のさらなる目的は、安価な衛星ナビゲーションシステムを提供することである。
【課題を解決するための手段】
【００１１】
間単に言えば、本発明におけるナビゲーション衛星受信機の実施例は、ＧＰＳシステムに対する精度の高い時間ベースのスレーブとなることができる。そういう時に、補正量ならびに動作温度が観測される。リアルタイムクロックがＧＰＳ時刻ベースのスレーブになれないとき、動作温度が周波数エラーの影響を一番受けると想定される。受信機がパワーダウンになってもリアルタイムクロックは通電状態になっている。その自走周波数は温度補正される。次回受信機をパワーアップした時に、他の受信機の初期化処理に使用できるように一日につき１ミリ秒よりも優れた精度の時間を直ちに得ることができる。
【発明を実施するための最良の形態】
【００１２】
図１に、本発明の実施例におけるネットワークシステム１００を示す。ネットワークシステム１００は、基準局サーバシステム１０２、ＧＰＳ測定プラットフォーム１０４、及びインターネットなど介在型コンピュータネットワーク１０６を含む。サーバシステム１０２はナビゲーション衛星受信機を備え、ナビゲーション衛星受信機はナビゲーションＧＰＳ衛星１０８、１１０、１１２からなる衛星群を捕捉して追跡している。これらのナビゲーションＧＰＳ衛星の中にはＧＰＳ測定プラットフォームから見えるものもあるかもしれない。ナビゲーション衛星１１４、１１６を含む別の衛星群はクライアントシステム１０４から見ることができる。ＧＰＳ測定プラットフォーム１０４には自分のナビゲーション衛星受信機があるが、それはまだナビゲーション衛星１１２、１１４、１１６の衛星群を捕捉しておらず、追跡もしてないかもしれない。
【００１３】
概して、本発明のＧＰＳ測定プラットフォームの実施例は４タイプあり、それはサーバとはどれだけ無関係に独立して作動できるかによって分けられる。自律型クライアントは、例えば、ディファレンシャル補正データなど、サーバ１０６から最低限の支援を受けるだけで機能し、ユーザにナビゲーション解を提供することができる。デミクライアントは、例えば、軌道暦及び時間のバイアス計算を簡素化する多項式モデルなど、もう少し支援を必要とする。シンクライアントはほとんど全てのナビゲーション計算をサーバ１０６に頼り、基本的にそのＧＰＳ衛星群に対する視点からの観測測定値を提供するだけである。ユーザがそこにいてナビゲーション解を見たければ、ローカルに表示するためにナビゲーション解が返送される。
【００１４】
４番目のタイプのクライアントは、クライアント１０４として接続された高感度ＧＰＳ受信機で、本明細書ではＯＭＮＩと称する。そうした４番目のタイプが本明細書で問題としているものである。
【００１５】
図２に示すのは、本発明におけるＯＭＮＩクライアントナビゲーション衛星受信機ネットワークの実施例である。本明細書では参照番号２００で示す。ＯＭＮＩクライアントナビゲーション衛星受信機ネットワークはネットワークサーバ２０４によってサポートされたナビゲーションプラットフォーム２０２を少なくとも一つを含む。
【００１６】
一般に、ＧＰＳ測定プラットフォーム２０２はそれぞれ、ＧＰＳアンテナ２０６、低雑音増幅器（ＬＮＡ）２０８、ＧＰＳ弾性表面波（ＳＡＷ）フィルタ２１０、中間周波数（ＩＦ）ＳＡＷフィルタ２１４を有する無線周波数（ＲＦ）特定用途向け集積回路（ＡＳＩＣ）２１２、ディジタル信号処理プロセッサ（ＤＳＰ）２１６、基準水晶発振器２１８、及び基準水晶温度センサ２２０を備える。
【００１７】
自律型クライアント２２２はサーバ２０４からほとんど支援を受けずに機能してユーザにナビゲーション解を提供することができる。デミクライアント２２４は、例えば、軌道暦及び時間のバイアス計算を簡素化する多項式モデルなどの支援を必要とする。シンクライアント２２６はナビゲーション解の処理の負担をローカルのホストにかけることをしない。ほとんど全てのナビゲーション計算をサーバ２０４に頼り、基本的にそのＧＰＳ衛星群に対する視点から観測測定値を提供するだけである。ナビゲーション解をユーザがそこにいて見たければ、ローカルに表示できるようにナビゲーション解を返送する。シンクライアント２２６において、ＤＳＰは何か他の非ＧＰＳアプリケーションとの共用部分となる。そうしたことから、クライアントではマルチスレッドのアプリケーションプログラムは必要なく、単純なプログラムループだけが実行される。
【００１８】
ＯＭＮＩクライアント２２７はほぼ完全に自律走行するが、周期的にコンピュータネットワークで完全セットの軌道暦を収集する。さらに、後からパワーアップされたときその位置の不確定性sigmaPosを１５０ｋｍ以下に保持できるように電力供給切断時にも動作する。こうした状況により高感度オペレーションが可能になる。高感度オペレーションでは信号パワーを見出すのにはるかに細かい探索ステップが用いられ、各ステップに留まる時間が長い。ＯＭＮＩクライアント２２７は、水晶発振器２１８を温度センサ２２０の温度測定値を使用するソフトウェア補償型にすれば、利することが多い。ナビゲーションプラットフォーム２０２がパワーアップされる毎に、真の時刻に１ミリ秒と違わない精度でリアルタイムクロック（ＲＴＣ）は動き続ける。
【００１９】
ローカルの基準発振水晶発振器２１８は温度の関数として変わる周波数ドリフト誤差を有する。ローカルの基準発振水晶発振器２１８の温度を測定するのに基準水晶温度センサ２２０が用いられる。ナビゲーションプラットフォーム２０２が初期化されＧＰＳ衛星を追跡しているとき製造時の校正曲線を構築するデータを収集するのに最初に使用される。次に、ナビゲーションプラットフォーム２０２を初期化しながらその最初のＧＰＳ衛星へのロックオンを試みている間に、保持された係数から９次の多項式を計算できるように指針値を提供するために使用される。
【００２０】
一般に、サーバ２０４は、基準局マネージャ２３２へのＧＰＳ信号入力を可能にする多数の基準局アンテナ２２８、２３０を備える。ロケーションサーバ２３４は初期測位時間及び位置解の質の向上のためにデミクライアント２２４、シンクライアント２２６、ＯＭＮＩクライアント２２７にサポート情報を提供することができる。ＯＭＮＩクライアント２２７が高感度モードで動作している場合には、サーバ２０４によって収集され転送された情報により−１５０ｄｂｍ以下のＧＰＳ衛星からの信号レベルのエニウェア（anywhere）測位が可能になる。
【００２１】
本発明の方法の実施例では、例えば、クライアント１０４及びナビゲーションプラットフォーム２０２などＯＭＮＩクライアントがいつどのようにしてサーバ２０４に接続するかの決定が行なわれる。バイトあたりの通信費用が高い場合や、ネットワークに周期的にしかアクセスできない場合は、サーバ接続を少なくし、多くの場合最低限に抑えなければならない。
【００２２】
信号の強度が高いとき、ＮＡＶデータを収集することによりＺカウント及びＢＴＴが実際に測定される。コード位相のロールオーバがあるときに、それをクリーンアップするためにＢＴＴが使用される。概して、２０ミリ秒以下の部分は一致するはずである。ＢＴＴはＺカウントと比べ雑音がわずかに多い。しかしながら、コード位相がロールオーバする付近では短時間の間１ミリ秒だけＺカウントがずれる可能性がある。
【００２３】
sigmaTimeを１ミリ秒以下に抑えるためにＯＭＮＩクライアントは優れた時間ソースを必要とする。パターンマッチを行ない、間接的に時刻を見出すために５０ＨｚのＮＡＶデータを用いることができる。そうすることにより、Ｚカウントを復調できないときにＧＰＳ受信機に妥当な時間ソースを提供することができる。パターンマッチに十分な信頼度があれば、ＧＰＳ衛星に対して整数ミリ秒intMsを判定することができる。
【００２４】
開始時刻の不確定性sigmaTimeが＋／−１０ミリ秒よりも大きければ、位置測位の解決ににいわゆる大デルタＴ項（ＤＴ）を使用しなければならない。そうすると必要なＧＰＳ衛星の数が一つ増える。位置の不確定性sigmaPosが１５０ｋｍ以下で且つＧＰＳ衛星に対してintMsを利用できないときにはgridFix法を活用することができる。sigmaTimeが１０ミリ秒以上のときは非Ｚカウント測位タイプが使用される。
【００２５】
全てのＧＰＳ衛星の衛星暦ではなく軌道暦を有するサーバから完全なＧＰＳ衛星暦highAccAlmが送られる。もう一つの完全なＧＰＳ衛星暦mixAccAlmをサーバから送ることができる。それにはいま追跡していないＧＰＳ衛星の古い軌道暦が含まれている。
【００２６】
完全なＧＰＳ衛星群を連続観測する能力を有するWWserverサーバが実現されるのが好ましい。同じ時刻に世界中でＧＰＳ衛星全てを見ることができる程度に空間的に離れた十分な数の基準局がある。サーバ２０４はローカルサーバLAserverを表わす。ローカルサーバは完全ＧＰＳ衛星群の部分集合しか観測しない一つ以上の基準局を有する。従って、LAserverはhighAccAlmを提供することはできず、mixAccAlmしか提供できない。
【００２７】
電源投入後、衛星暦は軌道暦を含み、その軌道暦は実際は衛星暦である。１２時間サイクルが一回終わると、衛星暦の中のいくつかは軌道暦に基づく衛星暦で置き換えられる。
【００２８】
ＧＰＳ衛星からのＮＡＶデータを−１４５ｄｂｍの低信号レベルまで直接収集することができる。従って、軌道暦、Ｚカウント、ＢＴＴをこのレベルで導出することができる。このレベルのＧＰＳ衛星はサーバとは別に動作することができるし、開始位置の精度を必要条件としない測位、例えば、エニウェア測位に使用することもできる。−１４５ｄｂｍからパターンマッチングが必要となり、低いところで−１５０ｄｂｍまで続行することができる。それによりＺカウント又はintMsを得ることができるので、ＧＰＳ衛星をエニウェア測位に使用することができる。しかしながら、そうした信号レベルでは、サーバ１０２、又は他のソースからネットワーク１０６で軌道暦を取得しなければならない。信号レベルが−１５０ｄｂｍ以下になると、ＮＡＶデータはパターンマッチに使用できるほどの信頼性がない。ＮＡＶデータをサーバ１０２又は２０４から得なければならないし、そうした弱い信号のＧＰＳ衛星は、不確定性が１５０ｋｍ以下のときにしか測位に加担することができない。
【００２９】
初期のＧＰＳ衛星捕捉中、軌道暦レベルは正確でなくてもいい。プレポジションに必要なデータを予測するには、衛星暦、もしくはダウングレードされた軌道暦で十分である。測位を行なうのに軌道暦レベルは正確でなくてもいい。測位のための軌道暦のエージ（Age）のタイムアウトが定義される。そうしたしきい値を緩和しても、時間の関数として精度の質の低下が正しくモデル化されていれば、かなりの精度の測位を維持することができる。顧客が望ましい性能レベルを選択できるようにエージ（Age）のしきい値は制御可能なパラメータにすることができる。
【００３０】
初期測位又は時刻を設定するにはサーバ１０２からのＮＡＶデータのサブフレームデータが必要である。その後、クライアント１０４はsubFrameを二度と要求
しない。クライアント１０４によって解読されたＮＡＶデータはサーバがパターンマッチングを行なうためにサーバ１０２に送られる。
【００３１】
ＧＰＳ衛星が３つ以上あってその全てが−１４５ｄｂｍ以上の信号レベルを有していると、ＯＭＮＩクライアント１０４はサーバ接続不要である。軌道暦を収集しなければならない場合には初期定点化時間（電源投入から最初の測位までの時間）（ＴＴＦＦ）が長くなる。場合によっては、前に収集した軌道暦を使用することができる。
【００３２】
前に収集したＧＰＳ衛星の軌道暦が手元にあってしかもsigmaPosが１５０ｋｍ
以下のとき、ＯＭＮＩクライアント１０４はサーバ接続を必要としない。必要な最低限度のＧＰＳ衛星の数はsigmaTimeによって決まる。そうした時間の不確定性は、温度ドリフトをソフトウェア補償することのできるリアルタイムクロック（ＲＴＣ）によって抑えることができる。そこで、ＲＴＣを用いる場合は３つのＧＰＳ衛星が、ＲＴＣを用いない場合には４つのＧＰＳ衛星が必要である。
【００３３】
さもなければ、測位の解を見出すのにＯＭＮＩクライアント１０４はサーバ１０２に接続して特定の情報を要求しなければならない。ＧＰＳ衛星の信号が−１４５ｄｂｍから−１５０ｄｂｍで且つsigmaPos＞１５０ｋｍになると、ＮＡＶデータサブフレームが必要となる。これらのＧＰＳ衛星が初期測位に加担するにはそうしたＧＰＳ衛星に対するintMsが要る。−１４５ｄｂｍ以下のＧＰＳ衛星が３つしか利用できなくて、しかも正確な時間のいい手立てが他にない場合には、パターンマッチングを採用することができる。その場合には４つのＧＰＳ衛星によるいわゆる非ｚカウント測（no-z）位を用いる。
【００３４】
ＧＰＳ衛星の信号の強度が−１４５ｄｂｍまでいかず、しかもその軌道暦にタイムアウトがあると、軌道暦を要求しなければならない。そうした場合、可能な限りの高速なＴＴＦＦが望ましい。
【００３５】
主のプログラムアプリケーションがＧＰＳ受信機を周期的にオンにして測位を得ることができる。そうすることにより、受信機が最後の測位からどれだけ遠くに移動したか、或いは単にＧＰＳ受信機が予め定められたゾーンを出たかどうかが決定される。−１４５ｄｂｍ以下の弱いＧＰＳ衛星に対するintMsが不要となるように、sigmaPosを１５０ｋｍ以内に保つべく測位間の時間間隔が選択される。そうすることにより、サーバ接続してＮＡＶデータsubFrameを要求しなくても高感度測位を保持する能力を延長することができる。サーバ要求のタイミングは適応型である。これは、変動の少ないクライアント／サーバ接続がなくても変動の少ないクライアント／サーバ接続を十分な性能があるときに実現するのに必要である。
【００３６】
ＯＭＮＩクライアントは手持ちのデータ、そのデータの年齢、及び捕捉成功の可能性、例えば、ＧＰＳ衛星の数及び信号レベルを評価しなければならない。ＯＭＮＩクライアントは次に、接続すべきかどうか、またどのデータを要求すべきか決定する。適応性をディセーブルにし、コマンドを出すことによってサーバ接続を行なうことができる。マスタアプリケーションが一時間毎にサーバ接続するように決定するようにしてもいい。従って、５分置きに行なわれる測位では、１２番目の測位がサーバ接続を行なう。
【００３７】
放送形軌道暦サービスを使用することができる。放送形軌道暦サービスではマスタアプリケーションが先ずデータを収集してそれを汎用のＡＰＩでクライアントに送り出す。クライアントはセッション中いつでもサーバ接続することができる。
【００３８】
一般に、クライアントは、測位前、１ミリ秒以上の時間の不確定性を有する。そのために、完全なコード位相の探索は従来、最初の測位の前に行なわれる。最初の測位後、或いはＲＴＣを用いて何回か再起動すると、クライアントは１ミリ秒以下の時間不確定性を有する可能性がある。こうしたケースでは、クライアントはコード探索の時間帯を小さくすることができる。従って、クライアントが測定されたＺカウントからの時刻を得た場合でも、全１０２３チップのコード不確定性を探索しなければならない。
【００３９】
本発明の実施例全てにおいて、パワーダウン後もＤＳＰ２１６の一部（図２）は通電状態になっており、クライアントセッション間の時間ソースとして維持されることが非常に重要である。パワーダウン中、ＲＦＡＳＩＣ２１２、sampleClock、sampleMem、ＯＳＭへの電力供給は実際切断される。しかし、水晶発振器２１８及びＤＳＰ２１６内部のミリ秒割り込みへの電力供給は活きているので、ＤＳＰ２１６は割り込みを処理することができる。
【００４０】
クライアント２０２は、発振器が最後の位置で計算された時間を次のＧＰＳセッションまで比較的長い期間維持できる安定性を有するので有利である。
【００４１】
クライアントは実現可能な精度を経験的事実に基づいて判定する。そうするために、クライアントは測位から時刻を先ず設定し、その後或る任意のオフ時間の間追跡を停止する。次に、クライアントは再び追跡をイネーブルにし、測定されたＺカウントをクロックがどれだけ動いたかを示す表示として用いる。クライアントが測位の際中行なうクロック調整によりクロックがＧＰＳ時刻に対してどれだけ動いたか知ることができる。
【００４２】
この技法では、クライアントが水晶発振器２１８及びＤＳＰ２１６への電力供給を維持しなければならない。クライアントはデバイスが見かけ上電力供給が切断されているときでもＧＰＳ回路への電力供給を維持する能力を有していなければならない。
【００４３】
一般的なシャットダウンでは、全てのファームウェアのステートマシンがアイドル状態になると、全てのint1活動が止まるべきである。クライアントは自動出力もディセーブルにするのでint0活動も停止するべきである。この時点で、バックグラウンド活動さえもなく、ＤＳＰ２１６はそのタスクを終えて休止モードになるべきである。休止モードは、割り込みがあるまでアイドル状態に留まりその時点で自動的にその割り込みサービスルーチンにジャンプするＤＳＰ２１６の特別な低電力機能である。
【００４４】
ミリ秒割り込みが到着すると、ＤＳＰ２１６は目を覚ましてその割り込みを処理して、ＧＰＳ時刻推定値を含む全てのタイマを１ミリ秒だけ進ませる。その後、割り込みが終わるとＤＳＰ２１６はまた休止モードに戻る。
【００４５】
クライアントは絶対時刻を出力する必要がある。そのために、ＧＰＳ−ＴＯＷ（秒単位）が６０４７９９から０に過ぎていくたびに、クライアントも週のカウンタを増分すべきである。クライアントはいまＤＳＰ２１６に絶対ＧＰＳ時刻を保持していないので、このＲＴＣモードの機能を追加しなければならない。但し、ＤＳＰ２１６での処理のいずれも週番号を使用しない。ＤＳＰ２１６の外に絶対ＧＰＳ時刻を提供するために備えるだけである。クライアントは、再起動するときにクライアントが判読できるタイムオフ変数を維持していると有利である。
【００４６】
そのサイクルはもう一つのクライアントセッションが始まると完了する。この時点で、クライアントは再び時刻メッセージの連続出力を要求し、且つクライアントはＤＳＰ２１６がオン又はオフのままかどうか、或いはその時刻を信頼しているかどうかを観測することができる。従って、クライアントは、ＤＳＰ２１６からの時刻をどのように使用できるか決めるためにクライアントが使用できるバイアス及びドリフトの不確定性を構築することが必要となる。
【００４７】
クライアントは時刻調整値を送るとき、時刻セットの推定精度も送るべきである。ＤＳＰ２１６はこの精度を受け入れる。この精度は温度に対する水晶の安定性のモデルに従って自動的にＤＳＰ２１６内に伝搬される。温度変化が多ければ多いほど、バイアス及びドリフト不確定性がより高速に伝搬されるべきである。しかしながら、温度が一定の場合には、不確定性はよりゆっくりした速度で伝搬される。
【００４８】
クライアントがセッションを終えようとしているとき、クライアントは全てのＧＰＳ追跡機能をディセーブルにするようＤＳＰ２１６に通信する。これによりＲＦＡＳＩＣ２１２への電力供給が切断され、全てのＧＰＳステートマシンがディセーブルになる。クライアントはディープスリープモードかＲＴＣモードかいずれかを選択することができる。ディープスリープモードを選択すると、クライアントは水晶発振器２１８への電力供給を切断することになる。しかしながら、ＲＴＣモードを要求すると、クライアントは水晶をオン状態に保つ。
【００４９】
クライアントは、ＤＳＰ２１６がそのミリ秒クロックを維持することを要求することもできる。電力消費を最低にしたければ、ミリ秒を含み、全てをシャットオフすることもできる。消費電力が最も大きいのはトランジスタが状態を変えるどきだけだから、全ての回路をオフにすれば、電力消費は最低限度に抑えられる。ディープスリープでは、ＤＳＰ２１６がdeepSleepモードを検出し、休止命令が送られてくると、発振器への電力供給も切断される。
【００５０】
クライアントがＤＳＰ２１６への電力供給を切断してもミリ秒のオプションを要求する場合には、ファームウェアができる限り全てのモードをディセーブルにするが、ミリ秒と発振器だけをアクティブに保つ。ＤＳＰ２１６を極力静かにしておくために、クライアントは時刻メッセージの自動出力をディセーブルにすることもできる。
【００５１】
埋め込み型アプリケーションでは、しかるべきシャットダウン処理を用いずに電源が切られる可能性が常にある。クライアントを用いるアプリケーションからクライアントがターンオフ要求を受け取るのが理想的である。これにより、次のテーブルに示す事象連鎖が始まる。
【００５２】
クライアントが、ＧＰＳをオフにしない要求をホストアプリケーションから受け取る；
クライアントが、全てのＧＰＳ追跡エンジン（ＯＤＳＭ，ＩＤＳＭ，ＴＳＭ）をオフにするようメッセージをＤＳＰ２１６に送る；
クライアントが、好ましいＤＳＰ２１６シャットダウンモードを送り、受入応答が来るのを待つ。最低限のパワーモードにしたければ、DEEP_SLEEP_MODEを要求する。最大限の情報が欲しければ、RTC_MODEを要求する；
クライアントが、シリアルバッファから全てのデータをフラッシュする；
クライアントが、全ての事象の処理を終え、しかるに、バッテリで支援している主要なメモリ要素がスタティックになる；
バッテリ支援データが保存される；
クライアントが、シャットダウンしても安全な状態になっている旨のメッセージをホストアプリケーションに返信する；
ホストアプリケーションが、クライアントアプリケーションの割り当てを解除する。
【００５３】
こうした処理は、シャットダウンが制御されたやり方で発生する場合好ましい方法である。
【００５４】
それほど秩序正しくないシャットダウンが発生する可能性もある。そうしたケースでは、シャットダウン処理を実行できるようになる前に、ホストアプリケーションがクライアントコードを突如終了する。例えば、ＤＳＰ２１６が正しくシャットダウンされなかった、或いは電力供給がシステムから取りはずされた。これは、誰かが電池を取り外したり、しかるべき動作レベルを維持できる程度の電流を電池が供給できないときに発生する。
【００５５】
ＤＳＰ２１６に未だ電力が供給されている場合、クライアントとの通信が停止しているかどうかの検出を行なうために検査ロジックを組み込むことができる。その場合、ＤＳＰ２１６は自分のパワーダウンシーケンスを行なう。ＤＳＰ２１６が単にパワーダウンされていたら、再び電源投入したときデフォルトの状態になるので問題ない。しかしながら、クライアントがそのときバッテリで支援されているファイルの或るセクションに書き込みを行なっているとデータが破損する危険性がある。ＤＳＰ２１６が正しくシャットダウンされたことを示すフラグに変数を書き込むことができる。その変数が起動時のデータ書き込み時に設定されていなければ、そのデータは無効と考え、明示的に無効状態に設定される。
【００５６】
電源投入時に、クライアントアプリケーションは起動されて、ＤＳＰ２１６を起こすために合図を送り、時間のステータスを要求する。そうした合図によりＤＳＰ２１６の中のＴＣＯも直ちに起動する。時間のステータスを受け取ると、クライアントは、時間のステータスが無効の場合、自分のバイアス及びドリフトの不確定性を未知の状態に設定する。このようにして、電池で支援されているデータ或いはサーバからのデータは最小のシグマになるように自ら解決する。クライアントが他の情報ソースに問合せるまで、ＧＰＳ時刻もこの時点でゼロになる。
【００５７】
時間のステータスが有効ならば、クライアントは時間の不確定性データをコピーし、内部データ構造をそのデータを用いて初期化する。他のソースからもっと良好なデータを利用できる場合には、その良好なデータが使用可能になると不確実性を解決することができる。クライアントは次に電池バックアップデータに関するステータスを読み取る。クライアントはデータ有効性フラグが設定されているデータセクションを同化する。そして、クライアントは利用可能な情報を評価してサーバにデータを要求し始める準備ができる。
【００５８】
手順通りのシャットダウン時に、RTC_MODEが選択されると、時間データがＤＳＰ２１６に送られる。シャットダウン処理の一部として受入応答が来るのを待つ。時間データがシャットダウン処理中にだけ送られる場合には、クライアントの手順通りでないシャットダウンが発生し、ＤＳＰ２１６への電力供給はオンのままである。この場合には、RTC_MODEはイネーブルにされず、ＤＳＰ２１６は走行し続ける。ステートマシンは相変わらず走行しており、時間の情報が失われる。
【００５９】
クライアントとＤＳＰ２１６間に周期的ハンドシェイクがあるのが好ましい。そのハンドシェイクが失われても、ＤＳＰ２１６に未だ電力供給されていれば、ＤＳＰ２１６は自らを静状態にしなければならない。
【００６０】
タイミングデータが定期的に送られてくる場合、クライアントは相変わらず時間をアクティブに保つことができる。しかしながら、タイミングデータの維持は計算上高価になるので、クライアントは優先順位を非常に低くするためにこうした計算を調整する必要がでてくる。
【００６１】
下記の時間及び不確定性の維持方程式を設計に用いることができる。いつか或る時点で、クライアントは、位置測位、Ｚカウント、パターンマッチからか、又は別のリアルタイムクロックなど他のソースからか、或いはサーバのレイテンシ推定量からか、いずれかから時刻情報を得る。クライアントはバイアス並びにドリフトに関する各データソースの精度のモデルを生成することができる。バイアスはメートルで、ドリフトはｍ／ｓで、計算される。使用するＳＣＸＯモデルは単位がｍ／ｓである。予備測位では、クライアントが必ず先ず擬似距離、擬似距離レートを計算してから、６４チップというハードウェア単位と搬送波ＮＣＯ単位に変換する。従って、クライアントがＤＳＰ２１６にその番号を直接使用したい場合には、クライアントはＮＣＯ単位に変換しなければならない。
【００６２】
Drift(m/s)／λ(m/cycle)＊bits／Hz
=drift＊(1575.42e6／2.99792458e8)＊224／528,000
=drift＊166.9789113
Drift NCO units (bits／Hz)＝drift(m/s)＊166.9789113
【００６３】
クライアントは周期的に下記の原子時計データセットを送るべきである：
1. 2-6をＬＳＢとしメートルを単位とした今のバイアス(bfix)
2. 2-12をＬＳＢとしメートル／秒単位の今のドリフト(dfix)
3. 2-6をＬＳＢとしメートルを単位をとした今のバイアスシグマ(σbf)
4. １ミリ秒をＬＳＢとしミリ秒を単位としたミリ秒シグマ(σmillisecond)
5. 2-12をＬＳＢとしメートル／秒を単位としたドリフトシグマ(σdf)
6. をＬＳＢとしカウントを単位としたドリフト推定値に最も近いＴＣＯ測定値(TCOfix)
7. バイアスに正確に一致し且つその他のパラメータにも一致する
【００６４】
周波数の不確定性の場合、クライアントは一つのパラメータσdfしか有していない。しかしながら、時間の不確定性の場合、クライアントは２つのパラメータを使用できるのが好ましい。多くのケースで、最初の測位前、時間の不確定性が多数ミリ秒にもなるので、クライアントは時間の不確定性を２つの成分、つまり、多数ミリ秒の部分と、ミリ秒以下の部分、に分割するのが好ましい。
【００６５】
【表１】
【表２】
【００６６】
伝搬方程式は、ＴＣＯ及び前のドリフトを更新し、ドリフトと共にバイアスを伝搬し、バイアスが＋／−１／２ミリ秒を超えるとミリ秒調整を行ない、ドリフトの不確定性を更新し、そしてバイアスの不確定性を更新する。バイアス及びバイアスシグマを伝搬するために、クライアントはドリフト及びドリフトシグマを更新する必要がある。基本的に、バイアスはドリフトの積分で、バイアスシグマはドリフトシグマの積分である。
【００６７】
クライアントは、測位時のドリフトデータに基づいてドリフトを推定するとともに判読中の今のＴＣＯに基づいて今のＳＣＸＯデータを推定する。
driftHat＝function(drift at fix, SCXO drift at fix, current SCXO drift)
【００６８】
バイアスがドリフトの推定値とともに伝搬される。バイアスが＋／−１／２ミリ秒を超えると、クライアントはミリ秒が正確なまま変わらないようにＤＳＰ２１６のミリ秒を調整する。
Bias＝bias＋driftHat＊dt
If(bias＞millisecond/s)｛
Bias−＝millisecond
Adjust DSP 216 millisecond＋1 millisecond
｝
else if（bias＜−millisecond/2）｛
bias＋＝millisecond
Adjust DSP 216 millisecond−one millisecond
｝
【００６９】
クライアントは、フィックス時のドリフトに基づいてドリフトシグマを更新し、今のＴＣＯに基づいて今のドリフトモデルを更新する。
driftSigma(t)＝function(drift sigma at fix, SCXO sigma at fix, current SCXO sigma)
【００７０】
クライアントはバイアス不確定性をドリフト不確定性の積分として伝搬する。
biasSigma＝biasSigmaAtFix＋integral(driftSigma(t))＊dt
【００７１】
次のセッションが始まると、クライアントはバイアス、ドリフト、並びにシグマを送り返す。バイアスシグマは大きくても１０又は２０ミリ秒以下で、言い換えれば、クライアントは他のソースに基づく時刻に頼らなくても実際に測位を行なえるのが望ましい。
そこで、下記のパラメータは観測に基づき定義される：
1. δ(tfix)＝dfix−dscxo(tfix). この符号付きパラメータは測位時に測定され、その測位時のモデル誤差を表わす。プロセスが再開されるまで不変である。
2. δ(tnow)＝dscxo(tnow)−dscxo(tfix). これは符号付きパラメータで、測位時からのモデルの変化を表わす。
【００７２】
最初のゴールは最良のドリフト推定値とともにバイアスを伝搬することである。言うまでもなく、推定バイアスシグマが真のバイアスエラーの最小上界（ＬＵＢ）になるという必要条件がクライアントにもある。このようにすると、クライアントがバイアスシグマを伝搬すると、それは十分に小さいままだから、長時間経過した後シグマはクライアントが測位を計算するためにバイアスを使用できることを示す。逆に言えば、バイアスシグマが大き過ぎると、クライアントは測位を計算するのに自信をもってバイアス推定値を用いることができない。
【００７３】
測位時刻付近で、測定ドリフト値はクライアントが使用できる最良の推定値であることは間違いない。温度が測位時の温度に近い温度のままで変わらない限り、クライアントは伝播ソースとして測位時のドリフトを使用したがる。これにより、最小のドリフトシグマを得ることができるので、バイアスシグマがゆっくりと積分し、ＬＵＢ判定基準の生成の助けになる。
【００７４】
逆に、最後の測位からの時間が長いと、クライアントは基準点としての測位時のドリフトに対する信頼を失う傾向があり、クライアントは完全にモデル化されたデータに移行したがる。しかしながら、クライアントは伝搬するために大きい方のシグマを使用しなければならない。
【００７５】
この二つの極端なケースの中間で、２つのソース（測位とモデル）をブレンドして一つにするのが論理的なように思える。経験的事実に基づくと、クライアントはドリフト軌道が長時間ＳＣＸＯモデルから幾分片寄ってるのは普通であることを知っている。しかしながら、一日一日では、バイアスがモデル以上又は以下になる可能性も同様に高い。クライアントがデータをブレンドして、今日のバイアスを得るためにできるだけ長く測位時のドリフトに頼る場合、クライアントはより正確なドリフトを得て、それを小さめのドリフトシグマに反映できるのが望ましい。
【００７６】
一つのキーとなる測定は、測位時の測定ドリフトとモデル化されたドリフトとの差｜δ(tfix)｜である。クライアントは測位に使用した測定値及び測位自体に何らかの完全性検査を行なうと仮定しよう。例えば、計算された速度がゼロに近ければ、これは安定点のようなもので、ドップラー測定誤差は小さい。従って、クライアントは、測位からの測定ドリフトは高い信頼度を有していると想定する。屋内の測定値を使用することに起因する精度の低下は測位からのドリフトシグマを反映している。この観点から、クライアントは最近の測定データにより高い信頼を寄せがちである。
【００７７】
水晶のエージング又は衝撃は水晶とモデルとの間にバイアスが生じさせやすい。クライアントは、測定されたデータとモデル化されたデータとの間には食い違いがあることを受け入れなければならない。クライアントは、測定から時間が経つにつれて測定データに対してより強力な重み付けを有するけれどもモデル化されたドリフト寄りにゆっくりと収束する、バイアス及びバイアスシグマをドリフト及びドリフトシグマとともに伝搬するための方法論を開発することになる。
【００７８】
測位時に推定されたドリフトとＳＣＸＯに基づくドリフト推定値との間のマイグレーション用の単純な公式化が定義される。クライアントは２つの単純なパラメータを介してマイグレーションの速度を制御する。
【００７９】
クライアントは、ドリフトの２つの推定値、すなわち、一つは今のＴＣＯに基づくＳＣＸＯモデルで、もう一つは調整された測位スドリフト、をブレンドしている。調整された測位ドリフトとは、現在時刻と測位時刻との差に起因するモデルの変化を補正した測位からのドリフトである。
調整後の測位ドリフトは：
da(tk)＝d(tfix)＋dscxo(tk)−dscxo(tfix)
クライアントはブレンド後のドリフト推定値を次のように定義する：
d^(tk)＝[1−α]＊da(tk)＋α＊dscxo(tk)
なお、クライアントは、クライアントがパラメータαとブレンドする２つのドリフト推定値を有する。このパラメータは下記を実現する：
1. tk＝tfixのとき、クライアントはd^(tk)＝da(tk)にしたい。そうするにはα＝０でなければならない。
2. tk≫tfixのとき、クライアントはd^(tk)＝ｄscxo(tk)にしたい。そうするにはα＝１でなければならない。
従って、パラメータＮ、すなわち、フィルタが更新された回数を次のように定義する：
ｋ＝１ならば、Ｎ1＝1
ｋ＜＝Ｎmaxならば、Ｎk＝ｋ
ｋ＞Nmaxならば、Ｎk＝Ｎmax
クライアントは整数計算を用いて乗算も実行したいので、クライアントは下記を定義する：
a＝Ｎk／２M
1−a＝(２M−Ｎk)／２M
Ｎmax＝２M
クライアントは一つのパラメータＭだけを指定するだけでいい。そうすると、変化率が完全に定義される。
【００８０】
【表３】
【００８１】
ドラフトシグマに同じ公式化を採用する。
σd(tk)＝[1−α]＊σfix＋α＊σscxo (tk)
モデルは毎秒更新されるので、間接的に１秒を掛ける掛け算があり、クライアントはバイアスを次のように更新することができる：
b(tk)＝b(tk-1)＋d^(tk)
クライアントはバイアスシグマをドラフトシグマの積分として更新するので、次のように暗に１秒を掛ける掛け算がある：
σb(t1)＝σbfix
σb(tk)＝σb(tk-1)＋σd(tk)
【００８２】
モデルの精度を検証するとともに正しい時刻定数を選択するのに水晶発振器２１８及びＤＳＰ２１６のハードウェア類を使用することができる。クライアントは常に真のバイアス及びドリフトを測定できるように、実際のＤＳＰ２１６ハードウェアは少なくとも一つの衛星を追跡している。クライアントはこれを次のように真の位置を中心として擬似距離及び擬似距離レートを線形化することによって行なう：
a. LPR＝intms＊cmsec＋codePhase−rangeHat−corr
b. LPRR＝rangeRate−rangeRateHat
c. モデルは、LPR＝biasTrue and LPRR＝driftTrue
【００８３】
一番最初の測定で、クライアントはLPR及びLPRRがゼロになるように受信機のクロック項を設定する。+/- 1/2ミリ秒よりも
大きいLPRを有する成分はすべてミリ秒クロック調整値に入れられる。ミリ秒以下の部分残余が開始バイアスとなる。一回目の調整後、クライアントは今ではＳＣＸＯデータ及び上記の方程式からバイアス及びドリフトを形成し始める。バイアスが+/- 1/2ミリ秒台以上に大きくなった場合には、クライアントはいつものようにクロック調整を行なう。LPR及びLPRRは真のバイアス及びドリフトを提供し、方程式は推定バイアス及びドリフトを提供する。また、Ｚカウントを測定している場合でも、クライアントが７０を推定するよりも真のintMsを用いてこれを補正すれば、クライアントは真のミリ秒時刻誤差を得ることができる。
【００８４】
現時点で好適な実施例により本発明を説明してきたが、開示は限定と解釈してはならないことが理解できる。上記の開示を読めば、当業者なら、様々な変更並びに変形が明白になることは疑いの余地がない。従って、添付した特許請求の範囲は発明の「真の」精神並びに範囲から逸脱しない限りにおいてあらゆる変形・変更を含むと解釈されるものと考える。
【図面の簡単な説明】
【００８５】
【図１】本発明におけるネットワークシステムの実施例の機能ブロック図。
【図２】本発明におけるナビゲーションプラットフォームの実施例の機能ブロック図。
【符号の説明】
【００８６】
１００ ネットワークサーバ
１０２、２０４ サーバ
１０４、２０２ ＧＰＳ測定プラットフォーム
１０６ インターネット
１０８、１１０、１１２、１１４、１１６ ＧＰＳ衛星
２００ ＯＭＮＩクライアントナビゲーション衛星受信機
２０６、２２８、２３０ アンテナ
２０８ 低雑音増幅器
２１０、２１４ ＳＡＷフィルタ
２１２、２１６ ＡＳＩＣ
２１８ 基準水晶発振器
２２０ 温度センサ
２２２ 自律型クライアント
２２４ デミクライアント
２２６ シンクライアント
２２７ ＯＭＮＩクライアント
２３２ 基準局マネージャ
２３４ ロケーションサーバ
【技術分野】
【０００１】
本発明はナビゲーション衛星受信機に関し、より具体的には、起動直後の受信機の時間の不確定さを減らすことによってナビゲーション衛星受信機の初期定点化時間（電源投入から最初の測位までの時間）（time-to-first-fix）を向上させるための方法並びにシステムに関する発明である。
【背景技術】
【０００２】
全地球測位システム（ＧＰＳ）受信機は、ユーザの位置及び速度、その他のナビゲーションデータを判定するのにＧＰＳ衛星群の中のいくつかの地球の軌道を回る衛星から受信した信号を使用する。従来技術のナビゲーション受信機では、電源投入直後、その現在位置、現在時刻、或いは水晶発振器にどのくらいの誤差があるか分かっていない。これらは全て、衛星の送信を見つけ出して捕捉するのに必要だから、その可能性のあるところの探索を行なわなければならない。時間の節約のために最も有望な候補が先ず最初に探索される。
【０００３】
高感度ＧＰＳ受信機は、初期の時間及び周波数の不確定性が大きいときに問題になる。信号のエネルギーが極めて弱いときに信号エネルギーを見出すにはステップを小さくし且つステップ毎に留まる時間を長くしなければならない。そこで、ローカルの基準発振器の初期推定値がより優れているとそれだけ初期測位の時間を短くすることができる。
【０００４】
−１４５ｄｂｍ以上の信号レベルを有するＧＰＳ受信機は、ナビゲーション（ＮＡＶ）データを解読するのに強力なＧＰＳ衛星（ＳＶ）を容易に捕捉することができる。そうすることによりＧＰＳ衛星の衛星暦及び位置を得ることができる。その後、ハードウェアのコード位相から全擬似距離を形成しなければならない。従来のＧＰＳ受信機は整数ミリ秒及びいわゆるＺカウントを判定する。
【０００５】
信号レベルがほぼ−１４５ｄｂｍから−１５０ｄｂｍにも満たないとき、実用の高感度ＧＰＳ受信機ではエニウェア（anywere）測位のためにＺカウント或いは整数ミリ秒を得るのにパターンマッチングを採用する。
【０００６】
一つ以上のＧＰＳ衛星を捕捉して追跡しているＧＰＳ受信機は時刻を非常に高度な精度で知っている。これはＧＰＳシステムが原子時計に基づいているからで、原子時計は使用する時間及び周波数の基準値を設定する。ＧＰＳ衛星から送信されたコースアクイジション（Ｃ／Ａ）コードは１ミリ秒の伝搬波長毎の繰り返しなので、ＧＰＳ受信機がどのミリ秒を観測しているかに関して基本的なあいまい性がある。例えば、時刻を１ミリ秒よりも正確に知っているなど、整数ミリ秒が分かっている場合には、整数あいまい性を解く必要はない。Ｚカウントが分かっている。Ｚカウントを見つけて整数ミリ秒を設定するステップを飛ばすことによって、ＧＰＳ受信機がコールドスタートから最初にナビゲーション解の測位を実現する作業でかなりの時間と労力を節約することができる。
【０００７】
【特許文献１】米国特許第５，７８１，１５６号
【発明の開示】
【発明が解決しようとする課題】
【０００８】
従って、本発明の目的は、パワーダウン後時間を記録することによってナビゲーション衛星受信機をより高速に初期化するためのリアルタイムクロックを提供することである。
【０００９】
本発明のもう一つの目的は、ナビゲーションデバイスの初期化に必要な時間を短縮するための方法並びにシステムを提供することである。
【００１０】
本発明のさらなる目的は、安価な衛星ナビゲーションシステムを提供することである。
【課題を解決するための手段】
【００１１】
間単に言えば、本発明におけるナビゲーション衛星受信機の実施例は、ＧＰＳシステムに対する精度の高い時間ベースのスレーブとなることができる。そういう時に、補正量ならびに動作温度が観測される。リアルタイムクロックがＧＰＳ時刻ベースのスレーブになれないとき、動作温度が周波数エラーの影響を一番受けると想定される。受信機がパワーダウンになってもリアルタイムクロックは通電状態になっている。その自走周波数は温度補正される。次回受信機をパワーアップした時に、他の受信機の初期化処理に使用できるように一日につき１ミリ秒よりも優れた精度の時間を直ちに得ることができる。
【発明を実施するための最良の形態】
【００１２】
図１に、本発明の実施例におけるネットワークシステム１００を示す。ネットワークシステム１００は、基準局サーバシステム１０２、ＧＰＳ測定プラットフォーム１０４、及びインターネットなど介在型コンピュータネットワーク１０６を含む。サーバシステム１０２はナビゲーション衛星受信機を備え、ナビゲーション衛星受信機はナビゲーションＧＰＳ衛星１０８、１１０、１１２からなる衛星群を捕捉して追跡している。これらのナビゲーションＧＰＳ衛星の中にはＧＰＳ測定プラットフォームから見えるものもあるかもしれない。ナビゲーション衛星１１４、１１６を含む別の衛星群はクライアントシステム１０４から見ることができる。ＧＰＳ測定プラットフォーム１０４には自分のナビゲーション衛星受信機があるが、それはまだナビゲーション衛星１１２、１１４、１１６の衛星群を捕捉しておらず、追跡もしてないかもしれない。
【００１３】
概して、本発明のＧＰＳ測定プラットフォームの実施例は４タイプあり、それはサーバとはどれだけ無関係に独立して作動できるかによって分けられる。自律型クライアントは、例えば、ディファレンシャル補正データなど、サーバ１０６から最低限の支援を受けるだけで機能し、ユーザにナビゲーション解を提供することができる。デミクライアントは、例えば、軌道暦及び時間のバイアス計算を簡素化する多項式モデルなど、もう少し支援を必要とする。シンクライアントはほとんど全てのナビゲーション計算をサーバ１０６に頼り、基本的にそのＧＰＳ衛星群に対する視点からの観測測定値を提供するだけである。ユーザがそこにいてナビゲーション解を見たければ、ローカルに表示するためにナビゲーション解が返送される。
【００１４】
４番目のタイプのクライアントは、クライアント１０４として接続された高感度ＧＰＳ受信機で、本明細書ではＯＭＮＩと称する。そうした４番目のタイプが本明細書で問題としているものである。
【００１５】
図２に示すのは、本発明におけるＯＭＮＩクライアントナビゲーション衛星受信機ネットワークの実施例である。本明細書では参照番号２００で示す。ＯＭＮＩクライアントナビゲーション衛星受信機ネットワークはネットワークサーバ２０４によってサポートされたナビゲーションプラットフォーム２０２を少なくとも一つを含む。
【００１６】
一般に、ＧＰＳ測定プラットフォーム２０２はそれぞれ、ＧＰＳアンテナ２０６、低雑音増幅器（ＬＮＡ）２０８、ＧＰＳ弾性表面波（ＳＡＷ）フィルタ２１０、中間周波数（ＩＦ）ＳＡＷフィルタ２１４を有する無線周波数（ＲＦ）特定用途向け集積回路（ＡＳＩＣ）２１２、ディジタル信号処理プロセッサ（ＤＳＰ）２１６、基準水晶発振器２１８、及び基準水晶温度センサ２２０を備える。
【００１７】
自律型クライアント２２２はサーバ２０４からほとんど支援を受けずに機能してユーザにナビゲーション解を提供することができる。デミクライアント２２４は、例えば、軌道暦及び時間のバイアス計算を簡素化する多項式モデルなどの支援を必要とする。シンクライアント２２６はナビゲーション解の処理の負担をローカルのホストにかけることをしない。ほとんど全てのナビゲーション計算をサーバ２０４に頼り、基本的にそのＧＰＳ衛星群に対する視点から観測測定値を提供するだけである。ナビゲーション解をユーザがそこにいて見たければ、ローカルに表示できるようにナビゲーション解を返送する。シンクライアント２２６において、ＤＳＰは何か他の非ＧＰＳアプリケーションとの共用部分となる。そうしたことから、クライアントではマルチスレッドのアプリケーションプログラムは必要なく、単純なプログラムループだけが実行される。
【００１８】
ＯＭＮＩクライアント２２７はほぼ完全に自律走行するが、周期的にコンピュータネットワークで完全セットの軌道暦を収集する。さらに、後からパワーアップされたときその位置の不確定性sigmaPosを１５０ｋｍ以下に保持できるように電力供給切断時にも動作する。こうした状況により高感度オペレーションが可能になる。高感度オペレーションでは信号パワーを見出すのにはるかに細かい探索ステップが用いられ、各ステップに留まる時間が長い。ＯＭＮＩクライアント２２７は、水晶発振器２１８を温度センサ２２０の温度測定値を使用するソフトウェア補償型にすれば、利することが多い。ナビゲーションプラットフォーム２０２がパワーアップされる毎に、真の時刻に１ミリ秒と違わない精度でリアルタイムクロック（ＲＴＣ）は動き続ける。
【００１９】
ローカルの基準発振水晶発振器２１８は温度の関数として変わる周波数ドリフト誤差を有する。ローカルの基準発振水晶発振器２１８の温度を測定するのに基準水晶温度センサ２２０が用いられる。ナビゲーションプラットフォーム２０２が初期化されＧＰＳ衛星を追跡しているとき製造時の校正曲線を構築するデータを収集するのに最初に使用される。次に、ナビゲーションプラットフォーム２０２を初期化しながらその最初のＧＰＳ衛星へのロックオンを試みている間に、保持された係数から９次の多項式を計算できるように指針値を提供するために使用される。
【００２０】
一般に、サーバ２０４は、基準局マネージャ２３２へのＧＰＳ信号入力を可能にする多数の基準局アンテナ２２８、２３０を備える。ロケーションサーバ２３４は初期測位時間及び位置解の質の向上のためにデミクライアント２２４、シンクライアント２２６、ＯＭＮＩクライアント２２７にサポート情報を提供することができる。ＯＭＮＩクライアント２２７が高感度モードで動作している場合には、サーバ２０４によって収集され転送された情報により−１５０ｄｂｍ以下のＧＰＳ衛星からの信号レベルのエニウェア（anywhere）測位が可能になる。
【００２１】
本発明の方法の実施例では、例えば、クライアント１０４及びナビゲーションプラットフォーム２０２などＯＭＮＩクライアントがいつどのようにしてサーバ２０４に接続するかの決定が行なわれる。バイトあたりの通信費用が高い場合や、ネットワークに周期的にしかアクセスできない場合は、サーバ接続を少なくし、多くの場合最低限に抑えなければならない。
【００２２】
信号の強度が高いとき、ＮＡＶデータを収集することによりＺカウント及びＢＴＴが実際に測定される。コード位相のロールオーバがあるときに、それをクリーンアップするためにＢＴＴが使用される。概して、２０ミリ秒以下の部分は一致するはずである。ＢＴＴはＺカウントと比べ雑音がわずかに多い。しかしながら、コード位相がロールオーバする付近では短時間の間１ミリ秒だけＺカウントがずれる可能性がある。
【００２３】
sigmaTimeを１ミリ秒以下に抑えるためにＯＭＮＩクライアントは優れた時間ソースを必要とする。パターンマッチを行ない、間接的に時刻を見出すために５０ＨｚのＮＡＶデータを用いることができる。そうすることにより、Ｚカウントを復調できないときにＧＰＳ受信機に妥当な時間ソースを提供することができる。パターンマッチに十分な信頼度があれば、ＧＰＳ衛星に対して整数ミリ秒intMsを判定することができる。
【００２４】
開始時刻の不確定性sigmaTimeが＋／−１０ミリ秒よりも大きければ、位置測位の解決ににいわゆる大デルタＴ項（ＤＴ）を使用しなければならない。そうすると必要なＧＰＳ衛星の数が一つ増える。位置の不確定性sigmaPosが１５０ｋｍ以下で且つＧＰＳ衛星に対してintMsを利用できないときにはgridFix法を活用することができる。sigmaTimeが１０ミリ秒以上のときは非Ｚカウント測位タイプが使用される。
【００２５】
全てのＧＰＳ衛星の衛星暦ではなく軌道暦を有するサーバから完全なＧＰＳ衛星暦highAccAlmが送られる。もう一つの完全なＧＰＳ衛星暦mixAccAlmをサーバから送ることができる。それにはいま追跡していないＧＰＳ衛星の古い軌道暦が含まれている。
【００２６】
完全なＧＰＳ衛星群を連続観測する能力を有するWWserverサーバが実現されるのが好ましい。同じ時刻に世界中でＧＰＳ衛星全てを見ることができる程度に空間的に離れた十分な数の基準局がある。サーバ２０４はローカルサーバLAserverを表わす。ローカルサーバは完全ＧＰＳ衛星群の部分集合しか観測しない一つ以上の基準局を有する。従って、LAserverはhighAccAlmを提供することはできず、mixAccAlmしか提供できない。
【００２７】
電源投入後、衛星暦は軌道暦を含み、その軌道暦は実際は衛星暦である。１２時間サイクルが一回終わると、衛星暦の中のいくつかは軌道暦に基づく衛星暦で置き換えられる。
【００２８】
ＧＰＳ衛星からのＮＡＶデータを−１４５ｄｂｍの低信号レベルまで直接収集することができる。従って、軌道暦、Ｚカウント、ＢＴＴをこのレベルで導出することができる。このレベルのＧＰＳ衛星はサーバとは別に動作することができるし、開始位置の精度を必要条件としない測位、例えば、エニウェア測位に使用することもできる。−１４５ｄｂｍからパターンマッチングが必要となり、低いところで−１５０ｄｂｍまで続行することができる。それによりＺカウント又はintMsを得ることができるので、ＧＰＳ衛星をエニウェア測位に使用することができる。しかしながら、そうした信号レベルでは、サーバ１０２、又は他のソースからネットワーク１０６で軌道暦を取得しなければならない。信号レベルが−１５０ｄｂｍ以下になると、ＮＡＶデータはパターンマッチに使用できるほどの信頼性がない。ＮＡＶデータをサーバ１０２又は２０４から得なければならないし、そうした弱い信号のＧＰＳ衛星は、不確定性が１５０ｋｍ以下のときにしか測位に加担することができない。
【００２９】
初期のＧＰＳ衛星捕捉中、軌道暦レベルは正確でなくてもいい。プレポジションに必要なデータを予測するには、衛星暦、もしくはダウングレードされた軌道暦で十分である。測位を行なうのに軌道暦レベルは正確でなくてもいい。測位のための軌道暦のエージ（Age）のタイムアウトが定義される。そうしたしきい値を緩和しても、時間の関数として精度の質の低下が正しくモデル化されていれば、かなりの精度の測位を維持することができる。顧客が望ましい性能レベルを選択できるようにエージ（Age）のしきい値は制御可能なパラメータにすることができる。
【００３０】
初期測位又は時刻を設定するにはサーバ１０２からのＮＡＶデータのサブフレームデータが必要である。その後、クライアント１０４はsubFrameを二度と要求
しない。クライアント１０４によって解読されたＮＡＶデータはサーバがパターンマッチングを行なうためにサーバ１０２に送られる。
【００３１】
ＧＰＳ衛星が３つ以上あってその全てが−１４５ｄｂｍ以上の信号レベルを有していると、ＯＭＮＩクライアント１０４はサーバ接続不要である。軌道暦を収集しなければならない場合には初期定点化時間（電源投入から最初の測位までの時間）（ＴＴＦＦ）が長くなる。場合によっては、前に収集した軌道暦を使用することができる。
【００３２】
前に収集したＧＰＳ衛星の軌道暦が手元にあってしかもsigmaPosが１５０ｋｍ
以下のとき、ＯＭＮＩクライアント１０４はサーバ接続を必要としない。必要な最低限度のＧＰＳ衛星の数はsigmaTimeによって決まる。そうした時間の不確定性は、温度ドリフトをソフトウェア補償することのできるリアルタイムクロック（ＲＴＣ）によって抑えることができる。そこで、ＲＴＣを用いる場合は３つのＧＰＳ衛星が、ＲＴＣを用いない場合には４つのＧＰＳ衛星が必要である。
【００３３】
さもなければ、測位の解を見出すのにＯＭＮＩクライアント１０４はサーバ１０２に接続して特定の情報を要求しなければならない。ＧＰＳ衛星の信号が−１４５ｄｂｍから−１５０ｄｂｍで且つsigmaPos＞１５０ｋｍになると、ＮＡＶデータサブフレームが必要となる。これらのＧＰＳ衛星が初期測位に加担するにはそうしたＧＰＳ衛星に対するintMsが要る。−１４５ｄｂｍ以下のＧＰＳ衛星が３つしか利用できなくて、しかも正確な時間のいい手立てが他にない場合には、パターンマッチングを採用することができる。その場合には４つのＧＰＳ衛星によるいわゆる非ｚカウント測（no-z）位を用いる。
【００３４】
ＧＰＳ衛星の信号の強度が−１４５ｄｂｍまでいかず、しかもその軌道暦にタイムアウトがあると、軌道暦を要求しなければならない。そうした場合、可能な限りの高速なＴＴＦＦが望ましい。
【００３５】
主のプログラムアプリケーションがＧＰＳ受信機を周期的にオンにして測位を得ることができる。そうすることにより、受信機が最後の測位からどれだけ遠くに移動したか、或いは単にＧＰＳ受信機が予め定められたゾーンを出たかどうかが決定される。−１４５ｄｂｍ以下の弱いＧＰＳ衛星に対するintMsが不要となるように、sigmaPosを１５０ｋｍ以内に保つべく測位間の時間間隔が選択される。そうすることにより、サーバ接続してＮＡＶデータsubFrameを要求しなくても高感度測位を保持する能力を延長することができる。サーバ要求のタイミングは適応型である。これは、変動の少ないクライアント／サーバ接続がなくても変動の少ないクライアント／サーバ接続を十分な性能があるときに実現するのに必要である。
【００３６】
ＯＭＮＩクライアントは手持ちのデータ、そのデータの年齢、及び捕捉成功の可能性、例えば、ＧＰＳ衛星の数及び信号レベルを評価しなければならない。ＯＭＮＩクライアントは次に、接続すべきかどうか、またどのデータを要求すべきか決定する。適応性をディセーブルにし、コマンドを出すことによってサーバ接続を行なうことができる。マスタアプリケーションが一時間毎にサーバ接続するように決定するようにしてもいい。従って、５分置きに行なわれる測位では、１２番目の測位がサーバ接続を行なう。
【００３７】
放送形軌道暦サービスを使用することができる。放送形軌道暦サービスではマスタアプリケーションが先ずデータを収集してそれを汎用のＡＰＩでクライアントに送り出す。クライアントはセッション中いつでもサーバ接続することができる。
【００３８】
一般に、クライアントは、測位前、１ミリ秒以上の時間の不確定性を有する。そのために、完全なコード位相の探索は従来、最初の測位の前に行なわれる。最初の測位後、或いはＲＴＣを用いて何回か再起動すると、クライアントは１ミリ秒以下の時間不確定性を有する可能性がある。こうしたケースでは、クライアントはコード探索の時間帯を小さくすることができる。従って、クライアントが測定されたＺカウントからの時刻を得た場合でも、全１０２３チップのコード不確定性を探索しなければならない。
【００３９】
本発明の実施例全てにおいて、パワーダウン後もＤＳＰ２１６の一部（図２）は通電状態になっており、クライアントセッション間の時間ソースとして維持されることが非常に重要である。パワーダウン中、ＲＦＡＳＩＣ２１２、sampleClock、sampleMem、ＯＳＭへの電力供給は実際切断される。しかし、水晶発振器２１８及びＤＳＰ２１６内部のミリ秒割り込みへの電力供給は活きているので、ＤＳＰ２１６は割り込みを処理することができる。
【００４０】
クライアント２０２は、発振器が最後の位置で計算された時間を次のＧＰＳセッションまで比較的長い期間維持できる安定性を有するので有利である。
【００４１】
クライアントは実現可能な精度を経験的事実に基づいて判定する。そうするために、クライアントは測位から時刻を先ず設定し、その後或る任意のオフ時間の間追跡を停止する。次に、クライアントは再び追跡をイネーブルにし、測定されたＺカウントをクロックがどれだけ動いたかを示す表示として用いる。クライアントが測位の際中行なうクロック調整によりクロックがＧＰＳ時刻に対してどれだけ動いたか知ることができる。
【００４２】
この技法では、クライアントが水晶発振器２１８及びＤＳＰ２１６への電力供給を維持しなければならない。クライアントはデバイスが見かけ上電力供給が切断されているときでもＧＰＳ回路への電力供給を維持する能力を有していなければならない。
【００４３】
一般的なシャットダウンでは、全てのファームウェアのステートマシンがアイドル状態になると、全てのint1活動が止まるべきである。クライアントは自動出力もディセーブルにするのでint0活動も停止するべきである。この時点で、バックグラウンド活動さえもなく、ＤＳＰ２１６はそのタスクを終えて休止モードになるべきである。休止モードは、割り込みがあるまでアイドル状態に留まりその時点で自動的にその割り込みサービスルーチンにジャンプするＤＳＰ２１６の特別な低電力機能である。
【００４４】
ミリ秒割り込みが到着すると、ＤＳＰ２１６は目を覚ましてその割り込みを処理して、ＧＰＳ時刻推定値を含む全てのタイマを１ミリ秒だけ進ませる。その後、割り込みが終わるとＤＳＰ２１６はまた休止モードに戻る。
【００４５】
クライアントは絶対時刻を出力する必要がある。そのために、ＧＰＳ−ＴＯＷ（秒単位）が６０４７９９から０に過ぎていくたびに、クライアントも週のカウンタを増分すべきである。クライアントはいまＤＳＰ２１６に絶対ＧＰＳ時刻を保持していないので、このＲＴＣモードの機能を追加しなければならない。但し、ＤＳＰ２１６での処理のいずれも週番号を使用しない。ＤＳＰ２１６の外に絶対ＧＰＳ時刻を提供するために備えるだけである。クライアントは、再起動するときにクライアントが判読できるタイムオフ変数を維持していると有利である。
【００４６】
そのサイクルはもう一つのクライアントセッションが始まると完了する。この時点で、クライアントは再び時刻メッセージの連続出力を要求し、且つクライアントはＤＳＰ２１６がオン又はオフのままかどうか、或いはその時刻を信頼しているかどうかを観測することができる。従って、クライアントは、ＤＳＰ２１６からの時刻をどのように使用できるか決めるためにクライアントが使用できるバイアス及びドリフトの不確定性を構築することが必要となる。
【００４７】
クライアントは時刻調整値を送るとき、時刻セットの推定精度も送るべきである。ＤＳＰ２１６はこの精度を受け入れる。この精度は温度に対する水晶の安定性のモデルに従って自動的にＤＳＰ２１６内に伝搬される。温度変化が多ければ多いほど、バイアス及びドリフト不確定性がより高速に伝搬されるべきである。しかしながら、温度が一定の場合には、不確定性はよりゆっくりした速度で伝搬される。
【００４８】
クライアントがセッションを終えようとしているとき、クライアントは全てのＧＰＳ追跡機能をディセーブルにするようＤＳＰ２１６に通信する。これによりＲＦＡＳＩＣ２１２への電力供給が切断され、全てのＧＰＳステートマシンがディセーブルになる。クライアントはディープスリープモードかＲＴＣモードかいずれかを選択することができる。ディープスリープモードを選択すると、クライアントは水晶発振器２１８への電力供給を切断することになる。しかしながら、ＲＴＣモードを要求すると、クライアントは水晶をオン状態に保つ。
【００４９】
クライアントは、ＤＳＰ２１６がそのミリ秒クロックを維持することを要求することもできる。電力消費を最低にしたければ、ミリ秒を含み、全てをシャットオフすることもできる。消費電力が最も大きいのはトランジスタが状態を変えるどきだけだから、全ての回路をオフにすれば、電力消費は最低限度に抑えられる。ディープスリープでは、ＤＳＰ２１６がdeepSleepモードを検出し、休止命令が送られてくると、発振器への電力供給も切断される。
【００５０】
クライアントがＤＳＰ２１６への電力供給を切断してもミリ秒のオプションを要求する場合には、ファームウェアができる限り全てのモードをディセーブルにするが、ミリ秒と発振器だけをアクティブに保つ。ＤＳＰ２１６を極力静かにしておくために、クライアントは時刻メッセージの自動出力をディセーブルにすることもできる。
【００５１】
埋め込み型アプリケーションでは、しかるべきシャットダウン処理を用いずに電源が切られる可能性が常にある。クライアントを用いるアプリケーションからクライアントがターンオフ要求を受け取るのが理想的である。これにより、次のテーブルに示す事象連鎖が始まる。
【００５２】
クライアントが、ＧＰＳをオフにしない要求をホストアプリケーションから受け取る；
クライアントが、全てのＧＰＳ追跡エンジン（ＯＤＳＭ，ＩＤＳＭ，ＴＳＭ）をオフにするようメッセージをＤＳＰ２１６に送る；
クライアントが、好ましいＤＳＰ２１６シャットダウンモードを送り、受入応答が来るのを待つ。最低限のパワーモードにしたければ、DEEP_SLEEP_MODEを要求する。最大限の情報が欲しければ、RTC_MODEを要求する；
クライアントが、シリアルバッファから全てのデータをフラッシュする；
クライアントが、全ての事象の処理を終え、しかるに、バッテリで支援している主要なメモリ要素がスタティックになる；
バッテリ支援データが保存される；
クライアントが、シャットダウンしても安全な状態になっている旨のメッセージをホストアプリケーションに返信する；
ホストアプリケーションが、クライアントアプリケーションの割り当てを解除する。
【００５３】
こうした処理は、シャットダウンが制御されたやり方で発生する場合好ましい方法である。
【００５４】
それほど秩序正しくないシャットダウンが発生する可能性もある。そうしたケースでは、シャットダウン処理を実行できるようになる前に、ホストアプリケーションがクライアントコードを突如終了する。例えば、ＤＳＰ２１６が正しくシャットダウンされなかった、或いは電力供給がシステムから取りはずされた。これは、誰かが電池を取り外したり、しかるべき動作レベルを維持できる程度の電流を電池が供給できないときに発生する。
【００５５】
ＤＳＰ２１６に未だ電力が供給されている場合、クライアントとの通信が停止しているかどうかの検出を行なうために検査ロジックを組み込むことができる。その場合、ＤＳＰ２１６は自分のパワーダウンシーケンスを行なう。ＤＳＰ２１６が単にパワーダウンされていたら、再び電源投入したときデフォルトの状態になるので問題ない。しかしながら、クライアントがそのときバッテリで支援されているファイルの或るセクションに書き込みを行なっているとデータが破損する危険性がある。ＤＳＰ２１６が正しくシャットダウンされたことを示すフラグに変数を書き込むことができる。その変数が起動時のデータ書き込み時に設定されていなければ、そのデータは無効と考え、明示的に無効状態に設定される。
【００５６】
電源投入時に、クライアントアプリケーションは起動されて、ＤＳＰ２１６を起こすために合図を送り、時間のステータスを要求する。そうした合図によりＤＳＰ２１６の中のＴＣＯも直ちに起動する。時間のステータスを受け取ると、クライアントは、時間のステータスが無効の場合、自分のバイアス及びドリフトの不確定性を未知の状態に設定する。このようにして、電池で支援されているデータ或いはサーバからのデータは最小のシグマになるように自ら解決する。クライアントが他の情報ソースに問合せるまで、ＧＰＳ時刻もこの時点でゼロになる。
【００５７】
時間のステータスが有効ならば、クライアントは時間の不確定性データをコピーし、内部データ構造をそのデータを用いて初期化する。他のソースからもっと良好なデータを利用できる場合には、その良好なデータが使用可能になると不確実性を解決することができる。クライアントは次に電池バックアップデータに関するステータスを読み取る。クライアントはデータ有効性フラグが設定されているデータセクションを同化する。そして、クライアントは利用可能な情報を評価してサーバにデータを要求し始める準備ができる。
【００５８】
手順通りのシャットダウン時に、RTC_MODEが選択されると、時間データがＤＳＰ２１６に送られる。シャットダウン処理の一部として受入応答が来るのを待つ。時間データがシャットダウン処理中にだけ送られる場合には、クライアントの手順通りでないシャットダウンが発生し、ＤＳＰ２１６への電力供給はオンのままである。この場合には、RTC_MODEはイネーブルにされず、ＤＳＰ２１６は走行し続ける。ステートマシンは相変わらず走行しており、時間の情報が失われる。
【００５９】
クライアントとＤＳＰ２１６間に周期的ハンドシェイクがあるのが好ましい。そのハンドシェイクが失われても、ＤＳＰ２１６に未だ電力供給されていれば、ＤＳＰ２１６は自らを静状態にしなければならない。
【００６０】
タイミングデータが定期的に送られてくる場合、クライアントは相変わらず時間をアクティブに保つことができる。しかしながら、タイミングデータの維持は計算上高価になるので、クライアントは優先順位を非常に低くするためにこうした計算を調整する必要がでてくる。
【００６１】
下記の時間及び不確定性の維持方程式を設計に用いることができる。いつか或る時点で、クライアントは、位置測位、Ｚカウント、パターンマッチからか、又は別のリアルタイムクロックなど他のソースからか、或いはサーバのレイテンシ推定量からか、いずれかから時刻情報を得る。クライアントはバイアス並びにドリフトに関する各データソースの精度のモデルを生成することができる。バイアスはメートルで、ドリフトはｍ／ｓで、計算される。使用するＳＣＸＯモデルは単位がｍ／ｓである。予備測位では、クライアントが必ず先ず擬似距離、擬似距離レートを計算してから、６４チップというハードウェア単位と搬送波ＮＣＯ単位に変換する。従って、クライアントがＤＳＰ２１６にその番号を直接使用したい場合には、クライアントはＮＣＯ単位に変換しなければならない。
【００６２】
Drift(m/s)／λ(m/cycle)＊bits／Hz
=drift＊(1575.42e6／2.99792458e8)＊224／528,000
=drift＊166.9789113
Drift NCO units (bits／Hz)＝drift(m/s)＊166.9789113
【００６３】
クライアントは周期的に下記の原子時計データセットを送るべきである：
1. 2-6をＬＳＢとしメートルを単位とした今のバイアス(bfix)
2. 2-12をＬＳＢとしメートル／秒単位の今のドリフト(dfix)
3. 2-6をＬＳＢとしメートルを単位をとした今のバイアスシグマ(σbf)
4. １ミリ秒をＬＳＢとしミリ秒を単位としたミリ秒シグマ(σmillisecond)
5. 2-12をＬＳＢとしメートル／秒を単位としたドリフトシグマ(σdf)
6. をＬＳＢとしカウントを単位としたドリフト推定値に最も近いＴＣＯ測定値(TCOfix)
7. バイアスに正確に一致し且つその他のパラメータにも一致する
【００６４】
周波数の不確定性の場合、クライアントは一つのパラメータσdfしか有していない。しかしながら、時間の不確定性の場合、クライアントは２つのパラメータを使用できるのが好ましい。多くのケースで、最初の測位前、時間の不確定性が多数ミリ秒にもなるので、クライアントは時間の不確定性を２つの成分、つまり、多数ミリ秒の部分と、ミリ秒以下の部分、に分割するのが好ましい。
【００６５】
【表１】
【表２】
【００６６】
伝搬方程式は、ＴＣＯ及び前のドリフトを更新し、ドリフトと共にバイアスを伝搬し、バイアスが＋／−１／２ミリ秒を超えるとミリ秒調整を行ない、ドリフトの不確定性を更新し、そしてバイアスの不確定性を更新する。バイアス及びバイアスシグマを伝搬するために、クライアントはドリフト及びドリフトシグマを更新する必要がある。基本的に、バイアスはドリフトの積分で、バイアスシグマはドリフトシグマの積分である。
【００６７】
クライアントは、測位時のドリフトデータに基づいてドリフトを推定するとともに判読中の今のＴＣＯに基づいて今のＳＣＸＯデータを推定する。
driftHat＝function(drift at fix, SCXO drift at fix, current SCXO drift)
【００６８】
バイアスがドリフトの推定値とともに伝搬される。バイアスが＋／−１／２ミリ秒を超えると、クライアントはミリ秒が正確なまま変わらないようにＤＳＰ２１６のミリ秒を調整する。
Bias＝bias＋driftHat＊dt
If(bias＞millisecond/s)｛
Bias−＝millisecond
Adjust DSP 216 millisecond＋1 millisecond
｝
else if（bias＜−millisecond/2）｛
bias＋＝millisecond
Adjust DSP 216 millisecond−one millisecond
｝
【００６９】
クライアントは、フィックス時のドリフトに基づいてドリフトシグマを更新し、今のＴＣＯに基づいて今のドリフトモデルを更新する。
driftSigma(t)＝function(drift sigma at fix, SCXO sigma at fix, current SCXO sigma)
【００７０】
クライアントはバイアス不確定性をドリフト不確定性の積分として伝搬する。
biasSigma＝biasSigmaAtFix＋integral(driftSigma(t))＊dt
【００７１】
次のセッションが始まると、クライアントはバイアス、ドリフト、並びにシグマを送り返す。バイアスシグマは大きくても１０又は２０ミリ秒以下で、言い換えれば、クライアントは他のソースに基づく時刻に頼らなくても実際に測位を行なえるのが望ましい。
そこで、下記のパラメータは観測に基づき定義される：
1. δ(tfix)＝dfix−dscxo(tfix). この符号付きパラメータは測位時に測定され、その測位時のモデル誤差を表わす。プロセスが再開されるまで不変である。
2. δ(tnow)＝dscxo(tnow)−dscxo(tfix). これは符号付きパラメータで、測位時からのモデルの変化を表わす。
【００７２】
最初のゴールは最良のドリフト推定値とともにバイアスを伝搬することである。言うまでもなく、推定バイアスシグマが真のバイアスエラーの最小上界（ＬＵＢ）になるという必要条件がクライアントにもある。このようにすると、クライアントがバイアスシグマを伝搬すると、それは十分に小さいままだから、長時間経過した後シグマはクライアントが測位を計算するためにバイアスを使用できることを示す。逆に言えば、バイアスシグマが大き過ぎると、クライアントは測位を計算するのに自信をもってバイアス推定値を用いることができない。
【００７３】
測位時刻付近で、測定ドリフト値はクライアントが使用できる最良の推定値であることは間違いない。温度が測位時の温度に近い温度のままで変わらない限り、クライアントは伝播ソースとして測位時のドリフトを使用したがる。これにより、最小のドリフトシグマを得ることができるので、バイアスシグマがゆっくりと積分し、ＬＵＢ判定基準の生成の助けになる。
【００７４】
逆に、最後の測位からの時間が長いと、クライアントは基準点としての測位時のドリフトに対する信頼を失う傾向があり、クライアントは完全にモデル化されたデータに移行したがる。しかしながら、クライアントは伝搬するために大きい方のシグマを使用しなければならない。
【００７５】
この二つの極端なケースの中間で、２つのソース（測位とモデル）をブレンドして一つにするのが論理的なように思える。経験的事実に基づくと、クライアントはドリフト軌道が長時間ＳＣＸＯモデルから幾分片寄ってるのは普通であることを知っている。しかしながら、一日一日では、バイアスがモデル以上又は以下になる可能性も同様に高い。クライアントがデータをブレンドして、今日のバイアスを得るためにできるだけ長く測位時のドリフトに頼る場合、クライアントはより正確なドリフトを得て、それを小さめのドリフトシグマに反映できるのが望ましい。
【００７６】
一つのキーとなる測定は、測位時の測定ドリフトとモデル化されたドリフトとの差｜δ(tfix)｜である。クライアントは測位に使用した測定値及び測位自体に何らかの完全性検査を行なうと仮定しよう。例えば、計算された速度がゼロに近ければ、これは安定点のようなもので、ドップラー測定誤差は小さい。従って、クライアントは、測位からの測定ドリフトは高い信頼度を有していると想定する。屋内の測定値を使用することに起因する精度の低下は測位からのドリフトシグマを反映している。この観点から、クライアントは最近の測定データにより高い信頼を寄せがちである。
【００７７】
水晶のエージング又は衝撃は水晶とモデルとの間にバイアスが生じさせやすい。クライアントは、測定されたデータとモデル化されたデータとの間には食い違いがあることを受け入れなければならない。クライアントは、測定から時間が経つにつれて測定データに対してより強力な重み付けを有するけれどもモデル化されたドリフト寄りにゆっくりと収束する、バイアス及びバイアスシグマをドリフト及びドリフトシグマとともに伝搬するための方法論を開発することになる。
【００７８】
測位時に推定されたドリフトとＳＣＸＯに基づくドリフト推定値との間のマイグレーション用の単純な公式化が定義される。クライアントは２つの単純なパラメータを介してマイグレーションの速度を制御する。
【００７９】
クライアントは、ドリフトの２つの推定値、すなわち、一つは今のＴＣＯに基づくＳＣＸＯモデルで、もう一つは調整された測位スドリフト、をブレンドしている。調整された測位ドリフトとは、現在時刻と測位時刻との差に起因するモデルの変化を補正した測位からのドリフトである。
調整後の測位ドリフトは：
da(tk)＝d(tfix)＋dscxo(tk)−dscxo(tfix)
クライアントはブレンド後のドリフト推定値を次のように定義する：
d^(tk)＝[1−α]＊da(tk)＋α＊dscxo(tk)
なお、クライアントは、クライアントがパラメータαとブレンドする２つのドリフト推定値を有する。このパラメータは下記を実現する：
1. tk＝tfixのとき、クライアントはd^(tk)＝da(tk)にしたい。そうするにはα＝０でなければならない。
2. tk≫tfixのとき、クライアントはd^(tk)＝ｄscxo(tk)にしたい。そうするにはα＝１でなければならない。
従って、パラメータＮ、すなわち、フィルタが更新された回数を次のように定義する：
ｋ＝１ならば、Ｎ1＝1
ｋ＜＝Ｎmaxならば、Ｎk＝ｋ
ｋ＞Nmaxならば、Ｎk＝Ｎmax
クライアントは整数計算を用いて乗算も実行したいので、クライアントは下記を定義する：
a＝Ｎk／２M
1−a＝(２M−Ｎk)／２M
Ｎmax＝２M
クライアントは一つのパラメータＭだけを指定するだけでいい。そうすると、変化率が完全に定義される。
【００８０】
【表３】
【００８１】
ドラフトシグマに同じ公式化を採用する。
σd(tk)＝[1−α]＊σfix＋α＊σscxo (tk)
モデルは毎秒更新されるので、間接的に１秒を掛ける掛け算があり、クライアントはバイアスを次のように更新することができる：
b(tk)＝b(tk-1)＋d^(tk)
クライアントはバイアスシグマをドラフトシグマの積分として更新するので、次のように暗に１秒を掛ける掛け算がある：
σb(t1)＝σbfix
σb(tk)＝σb(tk-1)＋σd(tk)
【００８２】
モデルの精度を検証するとともに正しい時刻定数を選択するのに水晶発振器２１８及びＤＳＰ２１６のハードウェア類を使用することができる。クライアントは常に真のバイアス及びドリフトを測定できるように、実際のＤＳＰ２１６ハードウェアは少なくとも一つの衛星を追跡している。クライアントはこれを次のように真の位置を中心として擬似距離及び擬似距離レートを線形化することによって行なう：
a. LPR＝intms＊cmsec＋codePhase−rangeHat−corr
b. LPRR＝rangeRate−rangeRateHat
c. モデルは、LPR＝biasTrue and LPRR＝driftTrue
【００８３】
一番最初の測定で、クライアントはLPR及びLPRRがゼロになるように受信機のクロック項を設定する。+/- 1/2ミリ秒よりも
大きいLPRを有する成分はすべてミリ秒クロック調整値に入れられる。ミリ秒以下の部分残余が開始バイアスとなる。一回目の調整後、クライアントは今ではＳＣＸＯデータ及び上記の方程式からバイアス及びドリフトを形成し始める。バイアスが+/- 1/2ミリ秒台以上に大きくなった場合には、クライアントはいつものようにクロック調整を行なう。LPR及びLPRRは真のバイアス及びドリフトを提供し、方程式は推定バイアス及びドリフトを提供する。また、Ｚカウントを測定している場合でも、クライアントが７０を推定するよりも真のintMsを用いてこれを補正すれば、クライアントは真のミリ秒時刻誤差を得ることができる。
【００８４】
現時点で好適な実施例により本発明を説明してきたが、開示は限定と解釈してはならないことが理解できる。上記の開示を読めば、当業者なら、様々な変更並びに変形が明白になることは疑いの余地がない。従って、添付した特許請求の範囲は発明の「真の」精神並びに範囲から逸脱しない限りにおいてあらゆる変形・変更を含むと解釈されるものと考える。
【図面の簡単な説明】
【００８５】
【図１】本発明におけるネットワークシステムの実施例の機能ブロック図。
【図２】本発明におけるナビゲーションプラットフォームの実施例の機能ブロック図。
【符号の説明】
【００８６】
１００ ネットワークサーバ
１０２、２０４ サーバ
１０４、２０２ ＧＰＳ測定プラットフォーム
１０６ インターネット
１０８、１１０、１１２、１１４、１１６ ＧＰＳ衛星
２００ ＯＭＮＩクライアントナビゲーション衛星受信機
２０６、２２８、２３０ アンテナ
２０８ 低雑音増幅器
２１０、２１４ ＳＡＷフィルタ
２１２、２１６ ＡＳＩＣ
２１８ 基準水晶発振器
２２０ 温度センサ
２２２ 自律型クライアント
２２４ デミクライアント
２２６ シンクライアント
２２７ ＯＭＮＩクライアント
２３２ 基準局マネージャ
２３４ ロケーションサーバ
【特許請求の範囲】
【請求項１】
ナビゲーション衛星受信機の高速初期化のための方法であって、当該方法は、
一般的なパワーダウン時にディジタル信号処理プロセッサのリアルタイムクロック部分を通電状態に保ち、水晶発振器を用いてミリ秒以下の正確な時刻を維持するステップと、
前記水晶発振器を含むナビゲーションプラットフォームがＧＰＳ衛星を捕捉して追跡しているときに前記水晶発振器を原子標準精度に設定するステップと、
前記ナビゲーションプラットフォームが見かけ上電力供給されていない期間に前記水晶発振器の温度を測定するステップと、
１）前記水晶発振器のドリフト変化がモデル化されたモデル式に前記水晶発振器による現在時刻を代入することで求められる発振器ドリフトと、２）前記モデル式に前記水晶発振器による現在時刻を代入することで求められるドリフトと測位によって算出される測位時刻を代入することで求められるドリフトとの差で、前記測位時刻のドリフト変化がモデル化されたモデル式に測位時刻を代入することで求められるドリフトを補正した測位ドリフトとをブレンドしてドリフト推定値を算出するステップと、
前記ナビゲーションプラットフォームがＧＰＳ衛星を追跡していないときに前記温度測定ステップで得たデータを用いて前記水晶発振器の自走時刻を補正するステップと、
次の測位の前に前記ナビゲーションプラットフォームにミリ秒以下の正確な時刻を供給するステップと、
を有するとともに、
前記維持ステップは、１）前記水晶発振器のドリフト変化がモデル化されたモデル式に前記水晶発振器による現在時刻を代入することで求められる発振器ドリフトと、２）前記モデル式に前記水晶発振器による現在時刻を代入することで求められるドリフトと測位によって算出される測位時刻を代入することで求められるドリフトとの差で、前記測位時刻のドリフト変化がモデル化されたモデル式に測位時刻を代入することで求められるドリフトを補正した測位ドリフトとをブレンドしてドリフト推定値を算出するステップを有し、この算出されたドリフト推定値を用いて正確な時刻を維持するステップである、
方法。
【請求項２】
前記ドリフト推定値算出ステップは、前記発振器ドリフトと前記測位ドリフトとの重み付けを可変してブレンドするとともに、前記水晶発振器による現在時刻と測位時刻とが同じ場合には、前記測位ドリフトを前記ドリフト推定値とするように前記重み付けを可変する請求項１に記載の方法。
【請求項１】
ナビゲーション衛星受信機の高速初期化のための方法であって、当該方法は、
一般的なパワーダウン時にディジタル信号処理プロセッサのリアルタイムクロック部分を通電状態に保ち、水晶発振器を用いてミリ秒以下の正確な時刻を維持するステップと、
前記水晶発振器を含むナビゲーションプラットフォームがＧＰＳ衛星を捕捉して追跡しているときに前記水晶発振器を原子標準精度に設定するステップと、
前記ナビゲーションプラットフォームが見かけ上電力供給されていない期間に前記水晶発振器の温度を測定するステップと、
１）前記水晶発振器のドリフト変化がモデル化されたモデル式に前記水晶発振器による現在時刻を代入することで求められる発振器ドリフトと、２）前記モデル式に前記水晶発振器による現在時刻を代入することで求められるドリフトと測位によって算出される測位時刻を代入することで求められるドリフトとの差で、前記測位時刻のドリフト変化がモデル化されたモデル式に測位時刻を代入することで求められるドリフトを補正した測位ドリフトとをブレンドしてドリフト推定値を算出するステップと、
前記ナビゲーションプラットフォームがＧＰＳ衛星を追跡していないときに前記温度測定ステップで得たデータを用いて前記水晶発振器の自走時刻を補正するステップと、
次の測位の前に前記ナビゲーションプラットフォームにミリ秒以下の正確な時刻を供給するステップと、
を有するとともに、
前記維持ステップは、１）前記水晶発振器のドリフト変化がモデル化されたモデル式に前記水晶発振器による現在時刻を代入することで求められる発振器ドリフトと、２）前記モデル式に前記水晶発振器による現在時刻を代入することで求められるドリフトと測位によって算出される測位時刻を代入することで求められるドリフトとの差で、前記測位時刻のドリフト変化がモデル化されたモデル式に測位時刻を代入することで求められるドリフトを補正した測位ドリフトとをブレンドしてドリフト推定値を算出するステップを有し、この算出されたドリフト推定値を用いて正確な時刻を維持するステップである、
方法。
【請求項２】
前記ドリフト推定値算出ステップは、前記発振器ドリフトと前記測位ドリフトとの重み付けを可変してブレンドするとともに、前記水晶発振器による現在時刻と測位時刻とが同じ場合には、前記測位ドリフトを前記ドリフト推定値とするように前記重み付けを可変する請求項１に記載の方法。
【図１】
【図２】
【図２】
【公開番号】特開２００８−１９７１１４（Ｐ２００８−１９７１１４Ａ）
【公開日】平成２０年８月２８日（２００８．８．２８）
【国際特許分類】
【出願番号】特願２００８−７２１４９（Ｐ２００８−７２１４９）
【出願日】平成２０年３月１９日（２００８．３．１９）
【分割の表示】特願２００３−４１７０３（Ｐ２００３−４１７０３）の分割
【原出願日】平成１５年２月１９日（２００３．２．１９）
【出願人】（０００００２３６９）セイコーエプソン株式会社 (51,324)
【出願人】（５０１３９６０２６）イーライド，インク． (10)
【氏名又は名称原語表記】ｅＲｉｄｅ，Ｉｎｃ．
【住所又は居所原語表記】Ｏｎｅ Ｌｅｔｔｅｒｍａｎ Ｄｒｉｖｅ，Ｂｌｄｇ．Ｃ，Ｓｕｉｔｅ ３１０ Ｔｈｅ Ｐｒｅｓｉｄｉｏ ｏｆ Ｓａｎ Ｆｒａｎｃｉｓｃｏ Ｓａｎ Ｆｒａｎｃｉｓｃｏ，ＣＡ ＵＳＡ
【Ｆターム（参考）】
【公開日】平成２０年８月２８日（２００８．８．２８）
【国際特許分類】
【出願日】平成２０年３月１９日（２００８．３．１９）
【分割の表示】特願２００３−４１７０３（Ｐ２００３−４１７０３）の分割
【原出願日】平成１５年２月１９日（２００３．２．１９）
【出願人】（０００００２３６９）セイコーエプソン株式会社 (51,324)
【出願人】（５０１３９６０２６）イーライド，インク． (10)
【氏名又は名称原語表記】ｅＲｉｄｅ，Ｉｎｃ．
【住所又は居所原語表記】Ｏｎｅ Ｌｅｔｔｅｒｍａｎ Ｄｒｉｖｅ，Ｂｌｄｇ．Ｃ，Ｓｕｉｔｅ ３１０ Ｔｈｅ Ｐｒｅｓｉｄｉｏ ｏｆ Ｓａｎ Ｆｒａｎｃｉｓｃｏ Ｓａｎ Ｆｒａｎｃｉｓｃｏ，ＣＡ ＵＳＡ
【Ｆターム（参考）】
[ Back to top ]