Carrer-phase residuals: LEA-5T F/W 6.00, PRN02
|
日記・備考録 |
2005 | 2006 | 2007 | 2008 | 2009/ 1 2 3 4 5 6 7 8 9 10 11 12 | 2010 |
| June |
July
2009 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
August | Home |
.....................................................................................................................................
Inside GNSS, GPS SVN49 Signal Anomaly: USAF Ponders Plan B, July 30, 2009
SVN49信号異常続報。現在、暫定的に実施されているエフェメリスとクロックパラメータに大きなオフセットを加える対策は"best approach"ではないとのコンセンサスの様で他の方策を検討中。"new approach involves mapping the orbit of SVN49" というのが有力な対策と検討されているらしい。ただこの実装にはOCSのソフトウェア改修が必要で1年はかかるとのこと。いずれにしても他のオプションを含め、後数週間から1ヶ月以内に結論を出すとしている。
"mapping the orbit of SVN49" というのが良く分からないのだが、エフェメリスのオフセットを動的に変更するということなのだろうか。もしそうだとしても全利用者に対応した対策にはなりようが無いので本質的とは言いがたい。他のオプションとして
(1) 現行のエフェメリス＋クロックオフセットを維持したままHealthyに設定
(2) 現行のエフェメリス+クロックkオフセットを維持しUnhealthyのまま
(3) エフェメリス+クロックオフセットをやめてUnhealthyのまま
(4) 航法メッセージのURAを通常より上げてUnhealthyのまま
とある。(1)はGPSコミュニティのコンセンサスとして破棄されそうなので、新しい"mapping the orbit of SVN49" 以外はもうHealthyにするオプションは残っていないということになる。多分新しい方法も時間を引き延ばすだけの対策の様なので、結果としてSVN49は永久にUnhealthyのまま運用されることになりそうだ。
.....................................................................................................................................
必要あってGT0.6.4でGPSのPOD。色々チューニングしても3D-RMSで5cmを切るのはなかなか厳しい。
やはりIGSの最新モデルを導入せざるを得ないのかなあ。あと実行速度もホントは倍くらいにはしたいのだけども。GT0.6.5に向けて、本格的に手を入れるか否か検討中。
.....................................................................................................................................
LEA-5Tのcarrier-phase観測値の問題をもう少し詳しく見てみる。以下はANTTOOLのオプション-nmax
[1,1] でPCVを固定して求めた、PRN02のcarrier-phase
multipath。Filter window=1にしたので結局carrier-phaseに含まれる残差を表すことになる。比較のため下は同一条件のLEA-4T。原因不明だがLEA-5Tのcarrier-phase観測値には振幅4cmに及ぶ時定数の長い異常変動が含まれている。これではまともにRTK解が求まるはずはない。LEA-4Tの方はRMSで4mm程度のトラッキング雑音+multipathが含まれているが、この程度ならRTK解を求めるには問題ない。LEA-4Tは正常なのでLEA-5TのF/W
(6.00) に問題があると考えられる。
さてLEA-5Tはcarrier-phaseを正式サポートしているのだから、この件はubloxにクレーム入れるべきなのだろうなあ。
補足: とりあえずublox社のサポートに問い合わせメールを送った。(12:10追記)
Carrer-phase residuals: LEA-5T F/W 6.00,
PRN02
Carrier-phase residuals: LEA-4T, PRN02
-------------------
LEA-5T評価続き。ANTTOOL 1.3で昨日取った26Hのデータを解析。以下 LEA-5T (左)、LEA-4T (右) で上からPCV-Skyplot, Phase multipath-Elevation, Code multipath-Elevation, C/N0-Skyplot。(どうも以前評価したEVK-5H F/W 3.00と同じような問題でcarrier-phaseに数cm以上の誤差が乗っている様) ということでcarrier-phaseの品質が悪すぎて、LEA-5T (F/W 6.00) はRTK-GPS用には使い物にならない。
LEA-5T F/W 6.00 (Left), LEA-4T (Right) receiver
performance, Antenna: GPS-702-GG, Analized
by ANTTOOL 1.3
.....................................................................................................................................
LEA-5T (左)、LEA-4T (右) の受信レベルとスリップ。26H分。アンテナはGPS-702-GGでスプリッタを介して2つの受信機に接続している。以前評価したEVK-5H (F/W 3.00) とは違って受信レベルがLEA-4Tとほとんど変わらないしむしろスリップは多い。
なおPRN18はメンテナンスの様 (NANU 2009046) だが航法メッセージのunhealthyフラグが立っていない。こういう運用されるとちょっと困るのだけど。計画保守という感じではないので、もしかすると何らかの障害かもしれない。
.....................................................................................................................................
H.Bock et al., High-rate GPS clock corrections from CODE:
support of 1 Hz applications, Journal of Geodesy, 2009
CODE 5sクロックの解析手法と評価、応用。30s間隔クロックに比較して、5sクロックを利用することによりキネマティックPPPによるLEO衛星PODで顕著な精度改善が見られる。また1Hzクロックと比較評価して5sクロックの線形補間では2%の精度劣化にとどまるとしている。昔、30sクロックで十分だと書いていた研究者がいたがこれを読んで何と言うだろう。
-------------------
J.A.Farrell, Aided Navigation: GPS with High Rate Sensors, McGraw-Hill, 2008
Amazonで届いた参考書。GPS-INS複合航法についてGPSやカルマンフィルタの理論も含めてよくまとまっている。GPS-INS関係の参考書でどれか一冊と聞かれたら、これかGrovesを勧めると思う。
-------------------
ubloxのモジュール用基板を海洋大 海老沼先生から頂いたのでそれを使って実装し (写真) LEA-5Tの正常動作を確認。ただ事前にubloxから通知されていたようにデータの更新レートは2.5Hzより速くはできない (設定はできるが出力されない)。メッセージはLEA-4Tと互換性がある様でRTKNAVIで正常動作した。
とりあえずRTKの性能を確認。比較のためアンテナスプリッタで分配した信号をLEA-4Tにも入力しRTKNAVIを2つ同時実行した。基準局はNovAtel OEMVで受信機出力をSTRSVRで2つのRTKNAVIに分配している。アンテナは両方ともNOV-702-GG。基線長は約1m。更新周期は1Hz。RTKのパラメータはデフォルト。以下、測位開始後12分後の状態。左がLEA-5T, 右がLEA-4T。
見て分かるようにLEA-5Tは全くambiguityがFIXしない。ratio値も最大で1.8位までしか上がらない。LEA-4Tは測位開始後30秒程度でFIXしてその後順調にratio値が上がっている。Float解そのものはLEA-4TのFIX解と比較して10cm以内に入っているので特に問題ない様に見える。原因はこれから解析するが、LEA-5T (F/W 6.00) はRTK用に使うには問題が内在している様だ。
補足: ちゃんとは解析していないがLEA-5Tではcarrier-phase観測値のHalf-cyle ambiguityをちゃんと解いていない可能性が高い。受信レベルもLEA-4Tとほとんど変わらないし、出力データレートの件といい、全く期待はずれである。TシリーズはF/Wバージョンアップが実質出来ないので、RTK用に購入予定の方にはF/Wのバージョンアップを待つか実績のあるLEA-4Tをお勧めする。(14:45追記)
.....................................................................................................................................
GPS連続観測システム (GEONET) の新しい戦略, 国土地理院時報 (2009, 118集)
GEONETの新解析戦略 (F3解) 関係の特集。当たり前なのかもしれないが、ちゃんとした解析技術を開発して評価・改良・維持していくにはずいぶんと人も時間もかかるなあという感じである。
-------------------
NovAtel OEMV-3G (F/W 3.620) でGLONASS R10, R14が正常に受信出来ない件、7月の初めにNovAtel社のサポートに問い合わせをしていたのだが、やっと以下の回答が返ってきた。ということで、この問題は8月末から9月初頭に予定されている次のF/Wリリースでfixされるとのこと。
> Hello Tomoji-san,
>
> Thank you for your patience. Our
internal group has confirmed that there is
still a minor issue in the
> tracking of GLONASS R10 and R14.
This is in the queue for fixing scheduled
to be included in the next
> official release. The next release
is scheduled to be end August beginning September.
Due to
> unforeseen circumstances these dates
are may change. If you have any further
questions, feel free to
> ask.
> This issue has been assigned case number
2009070613888. Please include this
number in the subject
> line of all future correspondence related
to this issue.
>
>regards,
.....................................................................................................................................
国土地理院, 第38回国土地理院報告会 開催報告, 2009/6/3
6/3に新宿で開催された国土地理院報告会の資料がupされている。辻,
国土を支える位置情報の基盤 - 電子基準点の現在と未来 で電子基準点の今後の整備・更新計画について触れている。この資料によると今年度末までに約450点の電子基準点の受信機更新を行い、その後毎年受信機更新を行う予定。その他今年度補正予算で通信の二重化、リアルタイムフォーマットのBinex対応を図る予定とのこと。
今年度中に更新される受信機はL2C, L5には対応する様だがGLONASS対応がなされるかは不明である。またGPS以外のGNSSについての対応についても今後検討するとしているだけで今一歯切れが悪い。電子基準点はNRTK基準局としての側面をもっている訳で、今後のNRTKの応用発展を考えれば、受信可能な測位衛星を全てサポートするのが当然だろう。GNSSの測位以外の応用
(例えば電離層観測、対流圏観測) を考えても衛星が増え観測データの空間分解能が上がる効果は絶大であり、もう少し広い視野で計画を考えて頂きたいと思う。
「航法分野では，RTCM（Radio Technical Commission
for Maritime Services；海事業務無線技術委員会）の定めるRTCM
SC-104 フォーマットが標準的だが，測量で重要な搬送波位相データの有効桁数に限りがあり，測量での利用には適していないと考えられる」とあるが、実際にはRTCM2で1/256cycle,
RTCM3で0.0005mの分解能があり「測量での利用には適していない」ということはない
(もともとRTCMのRTK規格は測量が主目的である)。別にBinexが悪いとは思わないが、現実のDefacto
StandardがRTCM 2 または3であることは論を待たない。実際、現在Binexをサポートしている受信機は確かTrimbleとLeicaの一部機種だけのはずである。
補足: 調べたらAshtechとTopconにもBinexに対応した機種があるよう。(7/22追記)
.....................................................................................................................................
ubloxのconfig用コマンドを作って10Hz RXM-RAW, SFRMを出力させ、convbinでRINEX変換できることを確認。power on reset時にUART2のTX側だけが正常に動作しない問題に嵌った。回路ミス、半田付不良、コネクタ接触不良等、H/Wの問題も考えられたので確認に時間がかかってしまった。結局u-bootを最新の版で作り直すことで解決。どうもu-bootのバグだったらしい。とりあえずH/Wはちゃんと動くことが分かったのであとはS/W (というかF/W)。
.....................................................................................................................................
u-bootを作り直して、やっとbeagleboardのUART2が認識されubloxからのNMEAを/dev/ttyS1から取り込むのに成功。u-bootの新しい版でmmcinitコマンドが動かない原因を調べるのに時間がかかってしまった。(分かってしまえば簡単でコマンドが変更になっていただけ: mmcinit→mmc init)。あとはublox用セットアップコマンドを作ってubloxのconfigをすれば良い。
.....................................................................................................................................
GPS/GNSSシンポジウム2009, 2009/11/30-12/1, 江東区文化センターホール
いつの間にか今年のGPSシンポジウムのWebサイトが出来ている。ロボットカーコンテストは今回から学生だけでなく一般参加OKとのこと。Arduinoに対応した受信機提供
(開発者ブログ) もあるとのことなので、皆さん奮ってご参加を。
.....................................................................................................................................
ケース (タカチYM-130) に入れた。
受信機ボードの動作試験。ubloxからメッセージが出力されていることは確認したが、UART2がLinuxのシリアルデバイスとして認識されない。どうもu-bootの設定で拡張コネクタ用マルチプレクサ設定をしないといけない様。片手間に作業しても能率が上がらないので一旦中断。
.....................................................................................................................................
RTCM Standard 10410.1, Networked Transport of RTCM via Internet Protocol (Ntrip) - Version 2.0, June 15, 2009
RTCMにNTRIP ver.2.0を注文したらとりあえずPDFで送ってきたので内容をチェック。ver.1.0からの主な変更点は
(1) HTTPとの互換性強化
(2) "chunked" 転送エンコード (データの分割転送)
の追加
(3) ヘッダレコードの追加
(4) ソーステーブルフィルタ機能の追加
(5) RTP/UDPのサポート
機能的には (5) が大きい。以前少し書いたがNRTK用ストリーム転送にはTCPはあまり適していないので、UDPを使えると細い回線上のレイテンシ改善に役立つだろう。さて、実装はそれほど大変ではなさそうだが、Caster側がver.2.0を使うようにならない限り機能を追加しても仕方ないのでRTKLIBへの実装はver.2.6.0位かなあ。
補足: RTCMの注文頁はver.1.0のまま書き換わっていないので、注文時には「ver.2.0送れ」と注記すること ($50)。実は注記したにもかかわらず最初ver.1.0を送ってきたのでクレームメールを送ったら、ver.2.0を送ってきた。
-------------------
Silver Circuitsから基板到着。結局運送 (Fedex) を入れて15日かかった。基板の出来そのものはとても綺麗でシルクが少しずれている以外全く問題ない。ただ今回の注文後、最低注文が4枚 $72に変更になったようで、ちょっと使いづらくなってしまった。次はOlimexかPCBCartかな。
大体実装完。一部部品の手配ミスがあって、まだ動かせないので今日はここまで。
-------------------
覚書: RINEX NAV, GNAVのフィールド並び。いつもすぐ分からなくなってRINEX仕様書を探すので。
RINEX GPS NAVIGATION MESSAGE RECORD: 1: PRN Toc SV_clock_bias SV_clock_drift SV_clock_drift_rate 2: IODE Crs Delta_n M0 3: Cuc e Cus sqrt(A) 4: Toe Cic OMEGA Cis 5: i0 Crc omega OMEGA_DOT 6: IDOT Codes_on_L2_ch GPS_Week_# L2_P_data_flag 7: SV_accuracy SV_health TGD IODC 8: Trans_Time Fit_interval spare spare RINEX GLONASS NAVIGATION MESSAGE RECORD: 1: Sat_no Tb SV_clock_bias SV_rel_freq_bias message_frame_time 2: position_X velocity_X_dot X_acceleration health 3: position_Y velocity_Y_dot Y_acceleration frequency_number 4: position_Z velocity_Z_dot Z_acceleration Age_of_oper_info
.....................................................................................................................................
R.B.Langley, Cause Identified for Psudorange Error from
New GPS Satellites SVN49, GPS World, Jul 13, 2009
SVN49信号異常の続報。信号異常メカニズムについて詳しく解説されている。既に抜本的な対策は無理だと考えられているらしく、SVN49は永久にhealthyにはできない可能性が高くなっている様だ。
.....................................................................................................................................
The MathWorks
7/1からMatlabの販売・保守に関する業務がCybernet
System社からMathWorks Japan社に移管されている。なんかMathWorks社の営業の方から挨拶の電話かかってきたので、せっかくなのでMatlabのシングルユーザライセンスの価格を聞いてみた。新規
\300,000, 年間保守 18.5%, 再加入 5%、とのこと。確か以前は\430,000 373,000 (2003/12価格表による。消費税別。SimlinkやTool
Boxは含まない) .-だったはずなので、少しは安くなっている様だ。米国での価格が$1,900というのを聞いたことがあるのでまだ差があるが、無理すれば個人でも買えないことはない
(?)。ただ、Matlabのバージョンアップ方針が気に食わないので、業務上必要性が発生しない限りもうライセンス更新をするつもりはないのだが。
補足: 5年前に購入した際の価格表を調べてみたら価格が間違っていたので訂正。(7/14追記)
-------------------
笹原他, ITによる長基線KGPSを基準としたMSAS・PPP・DGPSの精度評価について, 海洋保安庁海洋情報部技報 第27号, 2009
船舶の測位手法の比較評価。IT (KGPS), GT0.6.3
(キネマティックPPP), MSAS, DGPSの測位解を比較している。KGPSは基準局3局を使い基線長
数10km程度。GT-PPPでは1Hz衛星クロックを推定している。移動体のキネマティックPPPの精度評価結果はあまり無いので貴重な研究である。
なお、GT0.6.4では、100Hzまでの高時間分解能対応、CODE
5sクロック利用追加、異常衛星取扱改善により、キネマティックPPPがより実用的に使えるようなっているはずである。
.....................................................................................................................................
受信機ボードの実装に向けて温調半田ごて (PX-238) を新しく購入したので、少しハンダ付けの練習。20年前くらい前は結構ハンダ付けしていたのだけど、チップ部品や表面実装パッケージのハンダ付けは初めて。いらない基板から部品をはずして再度付け直す。youtubeにハンダ付けのコツみたいなビデオが結構上がっている。これなんか目から鱗というテクニック。
.....................................................................................................................................
ちょっと必要があって電子基準点の受信機クロック変動を解析。以下GT0.6.4-PPPで解析した電子基準点
93007, 93022の受信機クロック変動。30s間隔4日分の連続セッション。暦はIGS
Final+CODE 5s Clock。受信機はTrimble NETRS。見てすぐに分かるように、この受信機では、Trimble
5700で典型的に見られた鋸歯状クロックではなく、連続的なクロックステアリングに変更されている。
また、クロックバイアス間に明らかな相関が見られる。この2つの局は40km離れているし、PPPであるから受信機間クロックは無相関であってしかるべき気がするが、これは何でだろう。周囲気温変動を拾っているくらいしか考えにくいのだが
(日周変動がある様にも見える)、原因は謎である。
(プログラムの問題の可能性も否定できない)。
補足: 数100km離れた局でも相関が見られるので気温を拾っているのではなさそう。衛星エフェメリス誤差 (これは受信機間でほぼ共通) に起因した時刻同期 (クロック推定) 誤差を拾っている可能性が高いが、それにしてはちょっと変動が大きすぎる気もする。(7/10追記)
-------------------
InsideGNSS, New RTCM Standard Supports Internet Streaming
of GNSS Corrections to Mobile Users, July 8, 2009
NTRIP ver.2が正式に発行されたとのこと。さっそく注文しようとRTCMのonline storeに行ってみたのだけど、まだ掲載されていない様だ。
補足: 記事が更新されてRTCMのサイトでも買えるとのこと。さっそく注文。(7/11追記)
.....................................................................................................................................
gpsvp: GPS navigation software for smartphones,
PDAs and PCs
フリーのGPS対応地図ソフトなのだけど、GoogleMapsのラスタ地図データを事前にダウンロードしておいてオフラインで使えるところがミソ。PCだけでなくPDAやスマートフォンにも対応している。ただGPS対応は結構シンプルな機能のみの様だ。しかしGoogleMaps地図データのこういう使い方って利用規約に抵触しないのかなあ。
ちょっと使ってみたけどUIの出来があんまり良くないし、ubloxのNMEAも認識されない様だ。アイデアは面白いのだけど、ちょっと使えないなあという感じ。ラスタ地図で良いので高解像度の地図を使って高頻度 (10Hz程度) の画面更新を外部APIから可能な地図ソフトってどこかにないのだろうか。(Zenrin ZiもSuper Mappleも更新が遅いし、APIから地図更新できない。Google Earthは地図ではないし、Google Mapはネット接続が必須。結局gpsvpみたいに地図データだけはダウンロードしたものを使って、自分で地図描画ルーチンを書かないと駄目なのかなあ。ちょっとこれは片手間でできそうな感じはしない。)
.....................................................................................................................................
予約注文していたublox LEA-5T F/W 6.00 (rawデータ対応版) がやっと届いた。余っているAEK-4Pのモジュール (LEA-4P) を取り外して代わりにつけて使おうと思っていたのだが、実はモジュールの取り外しに失敗して基板のパターンが剥がれてしまって、修復は不可能っぽい。さてこれどうやって実装しようか。
-------------------
搬送波位相観測値における受信機H/Wバイアスの取扱メモ。もともとはRTK-GPS/GLONASSに関するY君の質問回答なのだけど重要なところなので、少し整理して記録として貼っておく。
搬送波位相バイアスに含まれる受信機初期位相項Φ_0は、
Φ_0=Φ_oci+Φ_ch (cycle)
で表される。ここでΦ_ociはダウンコンバータで掛け合わされた局部発振器位相
(差を使うので符号は逆、多段の場合はそれらの合計)、Φ_chはCH
(周波数) 毎位相遅れ。ここで位相遅れの意味は、どれか一つの受信機CHにおけるアンテナ位相中心から搬送波位相測定回路
(最近の受信機はデジタル処理なので受信信号のA/D変換のサンプリングタイミング)
までの時間遅れを基準にした他のCH (周波数)
の時間遅れ。結局差しか問題にならないので実は基準は何でも良い。
(1) 原理的にΦ_ociは同一エポック観測値間では同一の値をとり搬送波周波数には依存しないはず。(通常の受信機では衛星別に別の局発信号を掛け合わせるわけではないから。また同一エポック観測値では同一タイミングでサンプリングされるから。ただしL1/L2毎に別々のRF回路となる受信機が多いので多くの受信機ではL1/L2間では以上は成り立たないだろう。なおGLONASS周波数CH毎に別々のRF回路を持つ受信機があった場合もこれは成り立たないはず)。なおここで加算される位相はcycle
(あるいは度) 単位でかつ搬送波周波数に依存しない。
(2) Φ_chは搬送波周波数に依存する可能性がある。また受信機に
(さらに言えばアンテナやケーブルにも) 依存する可能性がある。ただしこの値は回路や配線の特性に起因するので時間的に安定でかつ同一機種受信機間ではほとんど同一の値をとるだろうことが期待される。(これ本当か?)
(3) 搬送波位相バイアス推定値 (cycle) の二重差をとった場合に、衛星間差により
(同一エポック観測値間では) Φ_ociが消去され、受信機間差により
(同一機種受信機間では) Φ_chが消去され、(受信機間差で衛星側も消えるので)
その値は整数値に収束することが期待できるはず。(正確にはΦ_chは周波数非依存項と周波数依存項があり、周波数非依存項は衛星間差で周波数依存項は受信機間差で消去される)
以上のうち(2)が本当に現実の受信機で成り立つのか、あるいはどの程度の精度で成り立つのかはかならずしもきちんと検証されている訳ではない。ただ、(まだ状況証拠でしかありませんが)
NovAtel OEMV受信機間では1cm程度以内では成り立っている様だ。厳密に言えばアンテナやケーブルの位相特性も周波数依存性を持っているはずなのでこれらの評価も必要。
GPSの場合を考えてみると (1) は同様に成り立ち、(2)
も同一周波数なら (ある誤差の範囲内で) 成り立つと言える
(これがRTK-GPSで整数バイアスが解ける根拠となっている。ただ、衛星毎に衛星時計やドップラの値が違うので厳密にはGPSでも受信搬送波周波数は異なる。この周波数差に起因するCH間バイアスはほぼ無視できる程度の様だ)。
-------------------
A.Hesselbarth et al., Short-term Stability of GNSS Satellite Clocks
and its Effects on Precise Point Positioning, ION GNSS 2008
こんなの見つけた。GLONASSの短期クロック安定度を解析しているのは貴重。GPSの値は以前自分で解析した結果とすこし食い違いがある様だ。もしかするとどちらかのAllan
Deviationの計算にミスがあるのかもしれない。
.....................................................................................................................................
magicGNSS
スペインGMV社が開発・運用するwebベースのGNSS解析アプリケーションmagicGNSS。ODTS
(Orbit Determination and Time synchronization)
とPPP機能があるとのこと。emailベースでPPPを実行することも出来る様だ。今年秋からはGLONASSの解析機能も追加されるらしい。Brochureを見る限りそれなりの性能が出ている様だが、これってビジネスとして成り立つのだろうか?
GMV社自体はESAからの委託でGalileoの軌道決定等もやっている様なので、その技術を流用しているということなのかもしれない。これは教えてもらった。
-------------------
やはりGLONASSを入れたJavad-NovAtel基線では6/8に書いた手法では正常に整数バイアスが解けない様だ。ΔdtGPS-GLOの値も40m程度になるしGLONASS観測値に関しては受信機依存性が大きい。Javad-NovAtel以外で確認してみたいが、短基線, 異機種間基線条件でGLONASSも取れている観測データは入手が難しい。
.....................................................................................................................................
ちょっとnews groupに投稿しようと思ったら最近のISPはnetnewsサーバのサービスを止めてしまっているところが多いようだ。調べたらGoogle Groupでnews readerの機能を提供していることが分かった。GPS関係の有益な情報が結構流れているnews group。現在のGoogle Groupのメンバー数は2000人強。
http://groups.google.co.jp/group/sci.geo.satellite-nav/topics?gvc=2
.....................................................................................................................................
InsideGNSS, GPS Wing Seeks Manufacturer, User Feedback
on SVN49 Signal Anomaly, Solution, June 29, 2009
SVN49信号異常の続報。GPSの送信アンテナアレイの
(nadirアングルに依存した) 位相特性がL5ペイロード
(L5フィルタで反射されたL1/L2波が30ns遅れで混合された?)
の影響を受けて変わってしまったのが原因らしい。現在一般ユーザへの影響を軽減するためエフェメリス
(軌道と時計) に約150mのオフセットを加えて運用中。今後これらのパラメータを変えて試験する予定。ただ受信機によって信号異常の出現の仕方が異なるようで航法メッセージの操作だけで対応可能かは疑問視されている。
単純には衛星アンテナの位相特性補正だけ行えば良いので後処理解析では何とでもなるだろうが、今運用されている全ての受信機のF/WをSVN49対応のためにupdateするのは現実的ではない。最悪の場合、SVN49は永遠にhealthyに出来ない可能性もある。アンテナ単体での位相特性試験は行っているはずだが、L5ペイロードを接続しての試験がなされていなかったということで、衛星のインテグレーション試験手順も問題になるだろう。来年春以降打ち上げ予定のBlock IIF初号機は既に射場に送られているはずだが、今後、工場での再試験という事態になる可能性も有る。そうなるとまた打ち上げが大幅に遅れる訳で今後GPSの運用がどうなっていくかは予断を許さない。
補足: エフェメリスの150mオフセットの意味だが、これは衛星位置を
(真の位置から) 150m上方にずらし (軌道長半径に150m加え)、その代わり衛星時計バイアスとして
(真の値に) 500ns加えているということだと思う。これらの操作は衛星直下点では相殺されるが、オフナディア角14度の地点では、150m*(1-cos(14度))
= 4.45mの位相特性変動と同等の影響を与える。逆に言えばL5ペイロードの影響でこの程度の衛星アンテナ位相特性異常が発生しているということ。アンテナ特性の変動なので擬似距離だけでなく搬送波位相にも異常を生じる様な気がするのだが、解析結果によると搬送波位相観測値は正常らしい。この辺の理由は良く分からない。(17:05追記)
衛星位置に対する150mもオフセットは、10km基線の基線解析においては、概ね10km*150m/20000km=7.5cm相当の誤差要因となる。これは、RTK-GPSに対しては全く無視できない影響を与える。従って、SVN49がhealthyにされた場合、この衛星を除外しないと大きな性能劣化を生じる。この例で分かるように色々な利用者を考えると、今回の信号異常を航法メッセージ操作のみで対処するのは無理があり、根本的な解決がなされない限り結局衛星をhealthyにはできないという結論になりそうな気がする
(逆に今のままhealthyにすると色々なところで問題が発生するだろう)。(17:27追記)
補足: GPS Worldにも同様の記事が出た。しかし受信機メーカーに解決策を提案させるとは本末転倒である。なんとかしてIS-GPS通りの正常信号に回復させるのが筋であるが現実的にそれは無理だと認めているのだとも言える。(22:21追記)
.....................................................................................................................................
Olimexに送ったorderメールのreplyが全然帰ってこないので、Olimexはやめて昨日教えて頂いたSilver Circuitsにしてみることにした。デザインルールが少し違うのでエラーになったところだけ直して発注。発注はEagleのbrdファイルのままでOK。3時間位でreplyが帰ってきたし、対応は大変良い。OlimexはDSS+AirMailで38.5euro=\5,209。Silver Circultsは6.3"x4.0"+Fedexで$65=\6,266。配送の差を考えるとほぼ同じ。支払いはGoogle CheckoutなのでFAXを送る必要もない。あとは品質だがこれは来てみないと分からない。
補足: Olimexからは7/1になってやっとreplyが送られてきた (orderメールは6/27) がSliver Circuitsに発注してしまったのでOlimexはcancel。しかしOlimexから送られてくるメールはとても簡潔で以下の様な感じ。とてもそっけない。(7/2追記)
>Hi
>attached is your po form
>ok, no problem
-------------------
IGSのGLONASS Navigationファイルのtkの値も3Hずれているレコードが多い (以下brdc1800.09gの例。1行目最後のフィールドがtkでフレーム時刻(s)をUTCで表したものなので、1行目第2フィールドからのtbと15分以内で一致していないと不正)。これはIGS局のLeica受信機が出力している値をそのまま使っている可能性が高い。多分tkの値を使っている解析ソフトはないのだと思うが、内容の整合チェックを行っているものがあるとするとIGSのcombined ephemerisを使うとエラーがでるはずである。
7 09 6 29 0 15 0.0 0.223033130169E-04 0.272848410532E-11 0.107700000000E+05 -0.112307060547E+05 0.281042957306E+01 0.000000000000E+00 0.000000000000E+00 -0.101052973633E+05 0.553712844849E-01-0.186264514923E-08 0.500000000000E+01 -0.205575927734E+05-0.156656646728E+01 0.186264514923E-08 0.000000000000E+00 8 09 6 29 0 15 0.0-0.949911773205E-04 0.909494701773E-12 0.107700000000E+05 -0.241137778320E+05 0.945849418640E+00 0.000000000000E+00 0.000000000000E+00 -0.451856201172E+04 0.210553169250E+00-0.186264514923E-08 0.600000000000E+01 -0.697193408203E+04-0.340716171265E+01 0.931322574616E-09 0.000000000000E+00
.....................................................................................................................................
| Home | by T.Takasu |
