2010/2/27 Chilean EQ. IGS CONZ displacement by RTKLIB 2.4.0 (bug-fix) PPP-Kinematic 1Hz
GPS only+CODE EPH+CLK 5s (Left: orign by igs10P1566.snx, Right: orgin by igs10P1590.snx)
|
日記・備考録 |
2005 | 2006 | 2007 | 2008 | 2009 | 2010/ 1 2 3 4 5 6 7 8 9 10 11 12 | 2011 |
| June | July 2010 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 |
...................................................................................................................................
RTKLIB2.4.0引き続き。
昨日のバグに懲りてRTKLIBにユニットテストのコードを追加して試験していたら、GTのNMFとRTKLIBのNMFのhydro項に食い違いを発見。原因を調べたらどうも元論文のバグらしい。
現在Googleで"niell mapping function"で一番最初に検索されるのは (多分オリジナルをスキャンした)、
A.E.Niell, Global mapping functions for the atomosphere delay at radio wavelenghts, JGR, 1996
だが、この論文では (5)式の第2項の符号が+になっている。ただFigure 2をみると (北半球の) 冬に最大値を取るのでこの式では明らかに180度位相がずれている。Haystack研のwebで公開されている同一論文、
A.E.Niell, Global mapping functions for the atomosphere delay at radio wavelenghts, JGR with correction, 1996
では(5)式の符号が反対になっており、オリジナルのJGR論文の修正版の様だ (JGR版は(4)式も間違っている)。GTの実装をした際は修正版を基にコードを書いて、RTKLIB実装時にはJGR版を基に再実装したのだと思う。こういう大きなバグでも注意深く試験しないと見つからないし、小さなバグは見つけること自体難しい。この前IGS
WSで話をしたドイツの研究者はGLONASS ICDのバグ知らなかったし、こういうのも結局ノウハウ蓄積の一部なんだなあ、と実感した。
...................................................................................................................................
RTKLIB 2.4.0引き続き。
IGS reference frame局132局分のPPPを1カ月分程流して精度チェック。なんか南半球の局だけ数10cmの上下オフセットが出る。どこかでで見た問題だなあと既視感。調べたらやはりNMFの実装にバグ。GTのNMFバグ修正に伴い同時に直した際に、新たなバグを入れ込んだらしい。試験していないコードには必ずバグがあるというソフトウェア開発の鉄則通りの結果である。でも全部のユニットテストちゃんと書くの結構しんどいんですけど。
補足: v. 2.3.0では公式には長基線RTKをサポートしていないのでv.2.3.0に対するパッチは出しません。どうしても使いたい人は自分でバグを見つけて直してください。(3:35追記) 問題がでるのは南半球だけで北半球の解析には問題ありません。 (9:25追記)
NMFバグがPPP解に影響を与えている可能性があるので、NMFバグ修正版でチリ地震のCONZを解析し直してみた。パラメータもチューニングし直している。絶対値も見るため2010/1のIGS解原点 (左)、2010/7のIGS解原点 (右) でプロットしてみた。地震直後の解が7月のIGS解に対し少しオフセットを持っているのは地震後動いたものの様だ。特にPPP解の上下はパラメータにセンシティブで、かつこのケースの様に2回データギャップがあるとギャップ間の解の信頼性はかなり落ちる。これはAmbiguityを決めれば改善されるはずなので今後対応したい。
2010/2/27 Chilean EQ. IGS CONZ displacement by RTKLIB 2.4.0 (bug-fix) PPP-Kinematic
1Hz
GPS only+CODE EPH+CLK 5s (Left: orign by igs10P1566.snx, Right: orgin by
igs10P1590.snx)
補足: GLONASSを入れるとこうなるのでやはり6:34:45-6:35:40の上下解は信用できない。もともと1分程度の観測値ではAmbiguityを解かないPPP解で精度は出ない (9:25追記)。
...................................................................................................................................
RTKLIB 2.4.0引き続き。
たまに必要になるので、RTKPLOTにTEQCを起動して結果を表示するメニューを追加したのだが、なんか最新版TEQC (2010-03-17版)
でもRINEX 2.11がサポート対象外ではじかれてしまう。しかたないのでRINEX ver.2はバージョン番号を2.10で出力するように改修。でも、OBS中のGLONASSやSBASは読み込んでくれるけど、GLONASS
NAV (G) やGEO NAV (H) をちゃんと読み込んでくれない。これなんか手立てはあるのかな。
いずれにしてもRINEX 2.11の規格は2007年、2.12は2009年には出ているので、ちょっと対応が遅すぎるのではないかと思う。どうもまともにメンテしていないようで、この調子ではTEQCがRINEX
ver.3に対応するのはあと10年くらいかかるのではないか。GalileoやQZSSが入ってきたらRINEX 3に移行しないと色々と不都合が多いと思うのだけど。
...................................................................................................................................
RTKLIB 2.4.0引き続き。
RTKLIBの後処理 PPP kinematicモードで解析した2月のチリ地震のCONZ観測点 1Hzデータ。暦はCODE EPH+CODE
CLK 5s。4/1に書いたGT-PPPの結果に比較して、データギャップ間の (みかけの) 上下変動が抑制されて、概ね綺麗に解析できていることが分かる。ここまで来るのにずいぶん苦労している。コード観測値に拘束をかけないと安定しないが、CONZの場合C1しか取れていないのでP1-C1
DCB補正が必須である。最終的にCODEのDCBファイルの読み込みとPPP時のDCB補正機能を追加した。ここまでくるとPPPでAmbiguityを解きたいけど、これはver.
2.5.0かver. 2.6.0くらいになると思う。
2010/2/27 Chilean EQ. IGS CONZ displacement by RTKLIB 2.4.0 PPP-Kinematic
1 Hz
(Left: GPS only CODE EPH+CLK 5s, Right: GPS+GLO ESA EPH+CLK 30s)
補足: GPS+GLONASS PPPの結果 (右) を追加。GPSがロックを外しているところでもGLONASSは外れていないのでここは綺麗に取れている。暦の補間の問題か、GLONASSの雑音特性の問題かGPS only+CODEに比較して少しノイズが大きいのと、上下の変位がちょっとあやしい。(3:40追記)
GPS+GLO+ESA解の差分で解析した変位速度。1Hzなので1秒内の平均速度しかとれないが最大 30cm/s位。USGSの解析結果と概ね整合的と言えると思う。やはり地震用には10 Hzが欲しいなあ。(10:55追記)
こういう応用にPPPは強い。チリ地震の場合、震源から400km位の所にSANT観測点があるが、基線長が長すぎて単純な基線解析には条件が悪いし、基準点自身も動いてしまっているので変動を分離できない。PPPの問題は高時間分解能の時計入手に現状では2週間程度かかること。以前やったように時計を自分で推定するのも可能だが、これはとても手間がかかる。暦はIGUかIGRを使って近隣1000km程度の基準点数局のデータを入力すれば自動的に高時間分解能解を求めてくれる解析ソフトがあると嬉しい人が多いのではないか。これは実装はそれほど大変ではないし実用的でとても有用な機能の様な気がする。ということでRTKLIBのTo Doリストに入れておこう。(11:13追記)
...................................................................................................................................
W.Gurtner and L.Estey, Proposal for a new RINEX-type Exchange File for GEO SBAS Broadcast Data, December 19, 2003
ちょっとRINEXの仕様を読んでいたら、SBASの放送データファイルは別文書で規定、と書いてあったのでちょっと検索。一応RINEX Bファイルとして既に7年前に提案されている様だが、多分殆ど使われていないのではないかと思う。
...................................................................................................................................
RTKLIB 2.4.0引き続き。
PPPでコード-搬送波位相間のcoherencyが乱れる受信機の対応して大体機能的には完。やっぱりKinematic PPPでは条件の悪い局ではなかなか性能でないなあ。GTでも性能出ないので多分モデルの問題ではない。まあもう仕方ないので今後改良することにして、v.2.4.0は仮凍結して試験。今後のこともあるのでちゃんと試験スイート書いた方が良いのだけど。
研究業績を更新。最近の発表を追加。査読付き論文をちゃんと書かなくてはいけない。
...................................................................................................................................
試験用に追加したので、EMS (EGNOS message server) のGT downloader用アドレス定義。なおEMSのファイルはファイル名が重複するので出力ローカルディレクトリにキーワード置換を入れないと上書きされてしまう。GTとほぼ同機能のwindowsネイティブのオンラインデータダウンローダAPをRTKLIB 2.4.0に入れたかったのだけれど、これはちょっと間に合いそうもない。多分2.4.1か2.4.2で。
ems ='ftp://131.176.49.48'; % EMS server
2,'EMS PRN120', [ems,'/pub/PRN120/y%Y/d%n/h%h.ems']
2,'EMS PRN122', [ems,'/pub/PRN122/y%Y/d%n/h%h.ems']
2,'EMS PRN124', [ems,'/pub/PRN124/y%Y/d%n/h%h.ems']
2,'EMS PRN126', [ems,'/pub/PRN126/y%Y/d%n/h%h.ems']
2,'EMS PRN131', [ems,'/pub/PRN131/y%Y/d%n/h%h.ems']
...................................................................................................................................
RTKLIB 2.4.0引き続き。
RINEX 3.0の対応をしたのでRTKLIBのヘッダファイル (rtklib.h) に入れた観測データコード一覧を以下に転載しておく。RINEX
3対応ということはobs typesとして以下全部の対応をする必要がある。L8 (E5a+E5bの広帯域トラッキング) なんて使う受信機がホントにあるのかね。なおv.3.00ではQZS用のコードは定義されていないのでこれはJAXA案に従った拡張分。
ずいぶん前に規格は出ているのだけど、IGSでRINEX 3対応が進んでいない理由は、観測データのQC用に標準的に使われているTEQCがまだRINEX
3に対応していないためである。こないだのIGS WS (補足: この集合写真、2日目の朝とったのだと思うのだけど、寝過したので私は写っていない) でUNAVCOのオジサン (Estey) が発表してたところによるとTEQCのRINEX
3対応は当分先になる様。
RTKLIB 2.4.0の試験用に他のツールで出力したRINEX 3のファイルを探しているのだけど、なんか殆ど見つからない。特にNAVファイルは全然見つからない。(JavadのRINEXコンバータがRINEX
3に対応していたはずだが) 今回、RTKCONVとCONVBINの入力フォーマットとしてRINEXを追加したので、RINEX 2→RINEX
3→RINEX 2と変換して、内容がちゃんと保存されることはとりあえず確認した。できればGalileoのOBSやNAVデータが含まれているRINEX
3ファイルのサンプルが欲しいのだけど。
#define CODE_NONE 0 /* obs code: none or unknown */ #define CODE_L1C 1 /* obs code: L1C/A,E1C (GPS,GLO,GAL,QZS,SBS) */ #define CODE_L1P 2 /* obs code: L1P (GPS,GLO) */ #define CODE_L1W 3 /* obs code: L1 Z-track (GPS) */ #define CODE_L1Y 4 /* obs code: L1Y (GPS) */ #define CODE_L1M 5 /* obs code: L1M (GPS) */ #define CODE_L1N 6 /* obs code: L1codeless (GPS) */ #define CODE_L1S 7 /* obs code: L1C(D) (GPS,QZS) */ #define CODE_L1L 8 /* obs code: L1C(P) (GPS,QZS) */ #define CODE_L1E 9 /* obs code: L1-SAIF (QZS) */ #define CODE_L1A 10 /* obs code: E1A (GAL) */ #define CODE_L1B 11 /* obs code: E1B (GAL) */ #define CODE_L1X 12 /* obs code: E1B+C,L1C(D+P) (GAL,QZS) */ #define CODE_L1Z 13 /* obs code: E1A+B+C (GAL) */ #define CODE_L2C 14 /* obs code: L2C/A (GPS,GLO) */ #define CODE_L2D 15 /* obs code: L2 L1C/A-(P2-P1) (GPS) */ #define CODE_L2S 16 /* obs code: L2C(M) (GPS,QZS) */ #define CODE_L2L 17 /* obs code: L2C(L) (GPS,QZS) */ #define CODE_L2X 18 /* obs code: L2C(M+L) (GPS,QZS) */ #define CODE_L2P 19 /* obs code: L2P (GPS,GLO) */ #define CODE_L2W 20 /* obs code: L2 Z-track (GPS) */ #define CODE_L2Y 21 /* obs code: L2Y (GPS) */ #define CODE_L2M 22 /* obs code: L2M (GPS) */ #define CODE_L2N 23 /* obs code: L2codeless (GPS) */ #define CODE_L5I 24 /* obs code: L5/E5aI (GPS,GAL,QZS,SBS) */ #define CODE_L5Q 25 /* obs code: L5/E5aQ (GPS,GAL,QZS,SBS) */ #define CODE_L5X 26 /* obs code: L5/E5aI+Q (GPS,GAL,QZS,SBS) */ #define CODE_L7I 27 /* obs code: E5bI (GAL) */ #define CODE_L7Q 28 /* obs code: E5bQ (GAL) */ #define CODE_L7X 29 /* obs code: E5bI+Q (GAL) */ #define CODE_L6A 30 /* obs code: E6A (GAL) */ #define CODE_L6B 31 /* obs code: E6B (GAL) */ #define CODE_L6C 32 /* obs code: E6C (GAL) */ #define CODE_L6X 33 /* obs code: E6B+C (GAL) */ #define CODE_L6Z 34 /* obs code: E6A+B+C (GAL) */ #define CODE_L6S 35 /* obs code: LEX-S (QZS) */ #define CODE_L6L 36 /* obs code: LEX-L (QZS) */ #define CODE_L8I 37 /* obs code: E5(a+b)I (GAL) */ #define CODE_L8Q 38 /* obs code: E5(a+b)Q (GAL) */ #define CODE_L8X 39 /* obs code: E5(a+b)I+Q (GAL) */
以上の様に今後はデータに色々な周波数やコードが混在して含まれることになるので、現在のRTKLIBの採用している衛星毎の固定長レコード配列で観測データを表現する方式はメモリ格納効率が悪い。これは将来のバージョンで構造変更が必要と考えている。というかその辺を考慮してバージョンアップ毎に少しずつデータ構造やAPIの整理をしている訳で、それもあって2.4.0ではかなりのAPIが変更になる。いるのかどうか知らないが、従来のAPIを前提にAPを書いている人はすいませんがご了承を。(しかし、良いAPIの設計というのはとても難しい。殆どArtの世界である。)
...................................................................................................................................
RTKLIB 2.4.0引き続き。
本バージョンではRINEX 3対応はしないつもりだったのだけれど、ちょっと必要があってRINEX 3のコードを書き始めたら止まらなくなってしまった。仕方ないのでこのまま突っ走ることにする。ということでRTKLIB
2.4.0にはRINEX ver.3.00対応とRINEXのQZSS拡張が入ります。
...................................................................................................................................
RTKLIB 2.4.0引き続き。
まずはIGS Finalを使って後処理24H PPP staticで水平3-4mm, 垂直〜8mm程度の性能がちゃんと出るかどうかとresidualsが想定以内になっているかを評価中。やっぱりGPTとGMFを入れたいのだけど、Fortranのソースをf2cで変換して組み込もうかなあ。でもlibF77がBorland環境ででちゃんと構築できるかどうかが問題。IGSのyaw
attitudeモデルはちょっと今回は入らない。やっぱりPPPだとeclipse期間中のBlock IIAはとても条件が悪くなるので、これは単純にデータを除外する様にする。あとday
boundaryの衛星軌道補外精度がやっぱりイマイチ。どうしても誤差が10 cmを超える。幾つか改良を試しているのだけど、これなんとかする方法ないだろうか。
...................................................................................................................................
昨日書いたIGS WS 2010関連の話題のうち、RTCM (SC-104) フォーマットについて少し補足。
RTCM SSRは衛星軌道・時計に関してはほぼ最終版になっていて、この夏にも正式規格化される予定。RTCM SSRとしては次に電離層補正情報の追加が審議されている。HP-RTCM
(またはRTCM-HP) はhigh-precision用の拡張規格で、RINEXとの互換性を確保し十分な精度の観測値を表現できるようRTCM
v3の追加メッセージとして実装される。まだ内容審議中で規格化されるのはもう少しかかりそう。IGSは既にRTCMのメンバ入りしており現在のRTCMの規格決定にかなりの部分関与している。なお、RTCMのメンバ以外には審議中の情報は公開されないので、正式規格以外のRTCMを入手するのは結構大変である。
ちなみに、RTKLIB 2.4.0のRTCM SSRの実装にあたっては、G.Weberから審議中のRTCM規格の情報提供を受けている。
Real Time Pilot Project Minutes of Teleconference IGS RTPP, 21 October, 2009
検索していてこんな資料を見つけた。現行のIGS RT WGの活動や誰が何をやっているのが良く分かるのではないかと思う。
...................................................................................................................................
iPhone 4来た。
ナビとデジカメ目的でIGS WSに持って行きたかったのだけど、予約が初回出荷にちょっとだけ間に合わなかった様で結局出張中に届いた。GPSや地磁気センサが入っているので、外に持っていけば地図上にちゃんと正確な位置と方位が表示されるのは当たり前ながらちょっと感動する。
iPad (WiFi版) は出張に持って行って英国の列車内でちょっとフリーのWiFiに繋いで使ったのだけど、知らない土地のナビ用にiPadを使うのはとても楽しい。ただ市街地なら周りのWiFi電波を拾って大体の位置を出してくれるのだけど、不正確だしWiFiアクセスポイントのない田舎ではうまく働かない。やはりiPadにもGPSが欲しい。今後、Bluetooth
GPS受信機のNMEAを拾って位置を取ってくれるAPが出ればよいのだけど。位置情報関係のAPIが充実しているみたいだし余裕があればそのうちiPhone/iPad用のAPも書いてみたいなあ。
-------------------
IGS WS 2010から帰還。とりあえず全体的な印象とメモ。
(1) 多分Galileo関係で人もお金も掛けているということなのだと思うのだけど、衛星軌道・時計決定に関する衛星モデリングの地道な研究開発が進んでいる。特にESA。現在既にこれらの研究開発の中心はCODEではなくESOCの様だ。
(2) 色々な理由があってRINEX 2系から3系への移行はなかなか進みそうもない。
(3) リアルタイムでは、HP-RTCMの対応、GLONASS/GalileoやAmbiguity resolutionサポートが主な議題。応用という面ではリアルタイムプロダクトへの期待は大きいが、進展は少しずつという感じ。
(4) リプロ1が終わって各ACの状況報告があったが皆結構苦労したらしい。プロダクトが整備されたという意味だけでなく、解析ノウハウの蓄積という意味ではこれらの活動は大きかった様だ。
(5) 対流圏、電離層、潮汐モデルに関しては地味なことしかやっていないという印象 (一応WGはあるが、IGSの活動として研究開発する分野でもない)。
今回の私の発表は、リアルタイムWGの主要メンバーであるBKGのGeorg Weberからの要請で行ったものであるが、IGSとしてもオープンソースのPPPソフトウェアに対する期待は大きい様だ。以前から何度も書いているのだがIGSに対する日本の貢献は小さいので、その意味でも今後も微力ながら何らかの寄与ができればよいと考えている。色々な研究者と話をして現行の世界の解析技術レベルを肌で感じることができた点も大きな収穫だった様に思う。
補足: 後処理PPPまたはリアルタイムPPPをサポートしたRTKLIB 2.4.0のリリースは7月下旬または8月上旬の予定です。現在試験と評価中につきもう少しお待ちください。(15:19追記)
...................................................................................................................................
| Home | by T.Takasu |
