日記・備考録

...................................................................................................................................

Russian Federal Space Agency, Proton-M/Cluster of Three Glonass-M's - Roll Out, August 30, 2010
3機のGLONASS-M衛星の打ち上げ準備が整ったようだ。打ち上げは9/2 00:53 UTCの予定。

第54回宇宙科学技術連合講演会, 2010年11月17日～19日, 静岡県コンベンションアーツセンター
暫定プログラムがアップされている。原稿〆切9/6 17:00。

ちょっと秋の学会を整理。GPSシンポ、測地学会、MGAはまだ参加は未定。

日付	学会	場所	申し込み	原稿〆切
9/21-9/25	ION GNSS 2010	米ポートランド	済	10/1
10/26-10/28	IS-GPS/GNSS 2010	台湾台北	済	9/27
11/4-11/6	GPS/GNSSシンポ2010	海洋大越中島	9/30	10/11
11/8-11/10	日本測地学会講演会	京大宇治	9/10	9/17
11/17-11/19	宇科連	静岡	済	9/6 17:00
11/21-11/22	MGA Workshop	豪メルボルン	?	-

...................................................................................................................................

InsideGNSS, IS-GPS-200E: Flexing Power and Fixing Phase Ambiguities, August 27, 2010
Flex power modeとL2P(Y)-L2C搬送波の位相関係についてはずいぶん以前に書いているが (参照)、新しいIS-GPS-200Eではこれについての仕様が追加された。新しいICD 3.3.1.5.1によると、CNAV中にL2P(Y)-L2Cの位相関係を示すビットが追加され (CNAV MT10のbit273が0なら直交、1なら同相)、CNAVが有効でない場合は固定 (直交) となるとのこと。Quarter cycle phase shift問題についてはRTCM 3でもずいぶん議論が有ったようだし (この扱いについてはRTCM 3.1 addendment 3で既に規定が追加されている)、受信機側でも混乱が有る様で、L2Cを異機種受信機間の相対測位に使うのは色々とリスクがあったのだが、GPS Wingと受信機メーカ間で調整が続けられて最終的にICDに規定が取り込まれたという経緯の様だ。
ところでCNAVは既に放送開始されているはずだが、CNAVを出力できる受信機って既にあるのかな。ちょっと中身を確認してみたいのだが。

...................................................................................................................................

> 政府の宇宙開発戦略本部（本部長＝菅直人首相）は２７日、本部会合を開き、９月１１日に打ち上げ予定の
> 準天頂衛星「みちびき」の２号機以降の開発に向け、各省の政務官で作るプロジェクトチーム（ＰＴ）の発
> 足を決めた。９月をめどに初回会合を開く。準天頂衛星は全地球測位システム（ＧＰＳ）の機能を補完・補
> 強する。日本の真上の空に近い場所から地上に向けて信号を送るため、ＧＰＳが苦手とするビルの谷間など
> でも受信でき、精度も上がる。日本上空を常時カバーするには最低３機が必要だが、２機目以降の打ち上げ
> は民間の事業化を含めて判断するとされ、現段階では白紙状態。ＰＴは内閣、文部科学、農林水産、総務、
> 経済産業、国土交通、防衛、警察の各府省庁からなる。前原誠司宇宙開発担当相（国交相）は「やる以上、
> ２機目以降の打ち上げが前提になる」と話した。

初のGPS Block IIF衛星SVN62/PRN25の運用が開始された (NANU2010113)。5/28の打ち上げから約3カ月かかっているが、当初から90-120日のチェックアウト期間をかけるとしていたので概ね順調と考えてよいと思う。
実際の信号受信を確認。といっても自分の受信機ではなく、IGS局GRAZのリアルタイム観測データをNTRIP経由RTKNAVIで受信した。GRAZの受信機がL5対応しているか良く分からないが、RTCM3.1ではまだL5データフィールドが未定義なので現状のRTCMではL5は受かり様がない。RTKLIB 2.4.0は3周波有効のオプションでビルドしているが、実はまだL5を使えるリアルタイム入力ソースはない。(動作確認していないが、後処理ではRINEXにL5が含まれていれば3周波のKGPSもちゃんと動くはず)。
Skyplotでみると多くの局でPRN30とPRN25が殆ど重なっていておりPRN30に隠されて識別できない。調べてみるとやはりSVN30/PRN30と同じB2スロットに入っている (参考)。ちょっと近すぎて幾何学配置が悪いので、これから軌道位置を少し離すマヌーバをするのかもしれない。

...................................................................................................................................

GNSS Data Center: Realtime Precise Point Positioning Monitor
BKG GDCのリアルタイム軌道・時計のモニタ頁。連続運転でIGS-IPを使ったリアルタイムPPP解をグラフ表示している。Monitor Scenario 13として昨日からRTKNAVI v.2.4.0による結果が追加されている。これはGPSとGLONASSの両者を使っている。
全体を見てすぐにわかるように、現状ではリアルタイムPPP解の品質はそれほど良いわけではない。これはサーバ側 (リアルタイム暦)、クライアント側 (測位アルゴリズム) の両者に問題が有るわけだが、いま自分でモニタしている範囲ではCLK11, CLK20, CLK51のリアルタイム暦の品質は悪くない。おおざっぱに言って収束後のキネマティック解のRMS誤差で水平5cm、垂直10cmの精度は出ている。ただ、少し安定性に乏しいのとGLONASS暦には改善の余地が大きい。また上記モニタで使っているPPPクライアントのBNC 2.3は、ソースを読む限り測位アルゴリズムの手抜きが目立つ。多分この辺、商用リアルタイムPPPであるStarFireやSeaStarは受信機のクライアントF/Wも含めてもう少し良いのではないかと思う。
リアルタイムPPPの問題は、この程度の性能でネットワークRTKに比較して有利となる応用がどれだけあるかという点にある。

補足: StarFireの基になったJPLのGDGPSシステムに関しては同様のリアルタイムPPP解モニタがこの頁でみられる。明らかにこちらの方が解品質が良い様に見える。IGSの担当者もこれは認めており、向こうは10年以上の蓄積が有るからと言っていた。なお、JPLもIGS RTPPの活動に参加しているが、この前RTPPのスプリンタに参加した感じではそんなに積極的に参画していると言う風ではなかった。まあ自分のところは既に技術開発済みでビジネス展開もしている訳で、当然と言えば当然。(19:32追記)。

...................................................................................................................................

http://www.rtklib.com
年間料金\1,800で独自ドメイン使えるみたいなので取ってみた。まあ気分の問題 (登録したばかりなのでまだDNS引けないかも)。

...................................................................................................................................

8/14にubloxのcapture & processは記録容量の点で実用的でない、と書いてしまったが、デジタル一眼レフ用に既に製品化されている様だ (Bilora Photo Geotagger GT-01)。検索すると既に使われている方がいて、特に瞬時動作と低消費電力は「使える」と結論付けている。確かに50g以下で2000点の位置が記録でき、4週間バッテリが持つのであれば、geotagging用としては十分実用的と言えると思う。野生動物のトラッキング等への応用も有力だろう。

RTKLIB: Support information
オープンの問題が溜まってきてしまった。ご指摘を受けた問題のうち、すぐ処置可能なものは即日対応しているので残っているのは原因究明に手間取っているものばかりである。特に通信関係の安定性に関わる問題は一般に障害再現が難しいので対策には時間と手間がかかる。本格的に試験環境を整えて過負荷試験やり直さなければいけないなあと思い始めている。

...................................................................................................................................

International Symposium on GPS/GNSS 2010, October 26-28, 2010, Taipei, Taiwan
preliminary programがupされたので貼っておく。ちょっと見る限りなんかGPS/INS integrationの発表が多い。今の流行なのかなあ。論文〆切9/27。

...................................................................................................................................

blip.tv + newcastle 2010 igs
恥ずかしいのであんまり貼りたくないのだが、先日のIGS WS 2010のプレゼン資料と録音が公開されている。

...................................................................................................................................

www.u-blox.com
ubloxのオンラインショップでLEA-6TとEVK-6Tの取扱いが始まっている。いつもだったらすぐ飛びつくのだが正直気が進まない。現在のF/WではGalileoにも対応しないのでせっかくの50chも宝の持ち腐れである。TシリーズはユーザF/W更新も出来ないので、来年Galileoが上がったらまた買い足さなければいけない。LEA-5Tから測位解の更新レートが5Hzに改良されている様だがrawの更新レートも5Hzなのかな。rawで10Hz出るのならちょっと買ってみようと思うのだが。

補足: データシートで確認したらやはり生データの更新レートも5Hzまでの様。もしかすると5Tの様にSBASをdisableにするともっと高レートが出るとかいう隠し技もあるのかも。いずれにしてもGalileo対応F/Wがリリースされるまでは見送り。(11:40追記)

EVK-CKというCapture & Processのエバキットは少し心が引かれる。キャプチャデータフォーマットが公開されるならソフトウェア受信機の研究用に使えるかもしれない。なお以前書いたC&Pのデータ容量の件、1ショット200KB位という話を聞いた。まあ妥当な容量であるが実用的かどうかというのはやはりちょっと疑問。なおiP-SolutionsのBGPS^TMも似たような技術であるがこっちは5ms分しか要らないのでデータ量をもっと減らせるようだ。ただ、結局データ量は(積分時間に比例するので) 受信感度とのトレードオフになる。信号の弱い条件でちゃんと測位するのは多分難しいのではないか。このワンショット記録・後処理測位と言うのは面白い技術で、将来的には何らかの信号処理技術と組み合わせて記録容量を劇的に減らして実用的に使えるようになるかもしれない。(12:03追記)

...................................................................................................................................

Space Daily, India Launches Satellite-Based Navigation System, August 13, 2010
検索した範囲では他のニュースソースでの確認がとれないのだが、このニュースサイトによるとインドが火曜日にインド版SBAS GAGANを打ち上げたとある。GAGAN用トランスポンダはインドの試験用通信衛星GSAT-4に搭載されて今年4/15に打ち上げられたが3段目ロケットの不調で失敗に終わった。年内に予備衛星を打ち上げるという情報はあったが、ちょっと早すぎるのでこの記事本当かなあ。

...................................................................................................................................

RTKLIB 2.4.0、自分では頑張って試験したつもりだったのだけど、やっぱり機能が増えて色々と漏れがあったようで、ぼちぼちと細かいバグの指摘を頂いている。この調子だと早めにマイナバージョンアップが必要になるかも。とりあえずパッチが10まで溜まったら2.4.1にバージョンアップします。

...................................................................................................................................

RTKLIB 商用化しないの? という質問もらったし、過去何度も、何でフリーで公開するんですか、という質問も受けているので2.4.0をリリースして良い機会なので何故RTKLIBをフリーで公開しているかについてちょっと書いておく。

(1) RTKLIBの開発は大学の研究員の立場で行ったもので、色々なしがらみ (例えば共同研究・委託研究のNDAとか著作権規定) に抵触しない範囲で一般公開するのは当然。幸いRTKLIBは完全スクラッチ開発で問題ない (というか問題ない様にしている)。
(2) 実際問題、商用プロダクトにするとサポート義務が生じるし、その業務に時間が取られて好きなコードが書けなくなる可能性が高い。商用ソフトとして売り出す方法良くわからないし、もはやパッケージソフトの時代でもない。
(3) 研究としての価値を考えると世の中にインハウスで作った研究用測位コードなどいくらでもあるので、それだけではインパクトが弱い。フリーで公開して皆が使えるようにすれば少しは研究としての価値が高まるのではないか。
(4) 精密測位応用という面でみると、現在やはり精密測位用の受信機や測位コード (F/W、S/W) の価格が高いことが一般普及を妨げている。実用的な精密測位用コードが誰でも使えるようになれば、これらの応用研究や実応用が促進されるのではないか。実用的な精密測位用コードを書くことは多分 (世界中でも) 誰でもできることではない。
(5) 一般公開して沢山の人が使ってくれれば広範なユーザからフィードバックが得られる。結局これは技術上のノウハウ蓄積になる。コード公開してノウハウが流出するという人もいるが、現実的にはこれは嘘でコードの中身のホントのノウハウなど書いた人以外に理解できるはずがない。
(6) 別にpublic domainにするわけでもないので、将来気が変わったらクローズドライセンスに変えればいいじゃん。
(7) せっかく苦労して書いたコードを皆が使ってくれて "great" とか "amazing" とか言ってくれるのはやはり内心嬉しい。

まあ、最近は (7) が大きいかも。ということで先のことは分かりませんが当分オープンソースで配布を続けることは間違いありません。

補足: (3)に関して。論文で非公開コード使った結果示してもコードがなければ厳密にはその結果の再検証できないのだから価値が低いのでは、と前は思ってたこともあって。でも昨年のIONでリジェクト食って (これはアブストの出来が悪かったのかも) コードの公開・非公開は学術研究では内容評価とは関係ないことが良く分かったので、今となってはあんまり理由になっていない。(20:00追記)

...................................................................................................................................

IGS-IP CLK11のGLONASS暦に問題を見つけたのでIGSに問い合わせを送った。記録のため転載。

> I checked IGS-IP CLK11 stream with RTKLIB 2.4.0 and found a problem on GLONASS
> ephemeris computation.
> The attached file rtklib240_ppp_with_igsip_clk11.jpg shows the 1Hz 24H real-time PPP
> solutions of RTKLIB 2.4.0 with IGS-IP CLK11, which enables both of GPS and GLONASS.
> As you can see, 30 min cycle large noises up to a few 10 cm indicate in this case.
>
> I guessed it is due to incompatibility of GLONASS ephemeris computation between
> IGS-side and RTKLIB. So I checked your BNC 2.2 source code.
>
> At BNC22-Source/RTCM3/ephemeris.cpp L186, BNC does not incorporate acceleration
> terms of GLONASS ephemeris.
>
> RTCM SSR states:
> For SSR, the GLONASS broadcast ephemeris computation "Simplify of algorithm for
> re-calculation of ephemeris to current time" must be used (see GLONASS ICD Version
> 5.0, A.3.1.2)
>
> GLONASS ICD A.3.1.2 inlucdes acceleration terms of xdotdot, ydotdot, zdotdot
> provided by GLONASS ephemeris.
>
> To confirm the cause of the problem, I modified RTKLIB code to eliminate GLONASS
> acceleration terms and replayed real-time PPP with IGS-IP CLK11. The result is shown
> in rtklib240_ppp_with_igsip_clk11_nogloaccterm.jpg
>It seems to have no problem on ephemeris computation.
>
> Additionally, BNC code does not comply with the J2 value in GLONASS ICD (ICD J02:
> 1082625.7E-9. BNC C20: -1082.63e-6)
>
>Would you check IGS side code for GLONASS ephemeris computation?

rtklib240_ppp_with_igsip_clk11.jpg (left), rtklib240_ppp_with_igpsip_clk11_nogloaccterm.jpg (right)

普通に使うには別に加速度項入れても入れなくても大した差はないのだけど、10cm以下精度の補正を保証するためにはサーバ側、クライアント側で同一のエフェメリス計算をしなければいけないということ。この辺SSRの仕様自体に結構危うい点が多い。

JAXAChannel, 見上げれば宇宙から照らす道しるべ準天頂衛星初号機「みちびき」, Youtube
9/11に打ち上げられるQZSS衛星初号機のプロモビデオが公開されている。沢山の人がとても苦労して進めているプロジェクトなので、ここまできたら上手く行って、ぜひ2号機、3号機の開発に繋げてほしい。

補足: QZSSのデータ公開webサイト QZ-vision も予告編がオープンしている。「みちびき」のペーパークラフト (QZクラフト) 作らなくちゃ。(16:46追記)

...................................................................................................................................

やっと2.4.0が出せたのでちょっと一息。今後のためにかなりコードを書き変えたという理由もあり、開発は当初想定していた以上に難航した。
今までの版はフリーであるということ以外に市販・既存の受信機や解析ソフトに対して大した優位点があった訳ではないが、今回の版は一応先端研究に近いところまで追いついたという意味で少しは価値があるのではないか。ただまだ不満な点も多いので、少し次や次の次のことを考え中。というか、その前に不義理している件、早く処置しなくちゃ。

...................................................................................................................................

RTKLIB 2.4.0引き続き。
試験用にReal-time PPPをずっと流しているのでその画面スナップショットを貼っておく。受信機はNovAtel OEMV-3でSTRSVRで5つのRTKNAVIにデータを分配している。リアルタイム暦は全部NTRIP配信されているIGS-IPで (1) CLK11: BKG RTNet+BNS, (2) CLK20: GSOC/DLR RETICLE, (3) CLK31: ESA/ESOC COMBI+BNS, (4) CLK51: ESA/ESOC RETINA+BNS, (5) CLK61: TUW RTIGSMR+BNSである。グラフ原点は近隣GEONET点との基線解析で求めているのでcm精度はあるはず。CLK61はデータは来ているが昨晩から内容が更新されていない。ここのところ見ている範囲では CLK20, CLK51の暦品質が良い様だ。なおGLONASSに関しては、まだIGS-IP側に問題が残っているので使っていない。

Snapshot of real-time PPP kinematic mode by RTKLIB 2.4.0, 2010/8/5 19:05-22:05
with www.igs-ip.net:2101/CLK11, CLK20, CLK31, CLK51, CLK61

...................................................................................................................................

http://www.beidou.gov.cn/index.html
Compass 5号機打ち上げのニュースが更新されていたので、Google翻訳版を載せておく。

> 北京5 時半8月1日、ロケットで西昌衛星発射センターのキャリア中国との"ロングルート"北斗のナビゲーション衛星
> に空間5が正常に意図トランスファ軌道は、傾斜静止衛星は、今年起動すると、中国、最初の3つの連続したコンパス
> の衛星航法システムのネットワーク。中国の衛星ナビゲーションシステムは、特別な管理事務所のナビゲーションシ
> ステム、衛星責任者のコンパス航法衛星システム音訳中国、コンパス（名前としての北斗）我々独立して開発、自己
> 実行グローバル使用されて重要な空間情報の状態がインフラ整備を広くすること、することができます分野での経済
> 社会。システムが提供できる正確で信頼性の位置決め、防災や救援の予防、交通、通信、火災森林、水漁業マッピン
> グ、ナビゲーションとタイミングサービスとナビゲーションおよび通信サービスを組み合わせ機能の開発を、19年測
> 量と国家安全保障のアプリケーションや他の多くの分野、利益の社会的、結果に大きな経済的。特に玉樹の?川、四
> 川、救援で青海省の地震の役割を果たして、非常に重要です。アジア太平洋の戦略、コンパスの衛星航法システム
> 2012年の地域のサービス機能、周辺の開発"の手順に"3 - 2020に基づき、セグメント地上建てられた30以上の衛星、
> およびカバレッジグローバル端末、ユーザの構成の様々な種類の大規模な宇宙システム。コンパスは、衛星航法シス
> テム技術の複雑さとスケールは、そのアプリケーションの建設は、成功ネットワーキングを確保するpolicyバッチ生
> 産からなる有効宇宙開発を中国の衛星を1つからグループのコア、コアシステムとして、衛星に成功した星から大量の
> ユーザーが歴史的な転換のユーザーに業界の業界宇宙中国の旅を開いて新しい。衛星放送、キャリアロケット技術の
> 開発車両が所有する中国航空宇宙科学起動と技術の株式会社の中国アカデミーアカデミー宇宙技術と中国。これは、
> フライトは"長征126最初のロケット"シリーズのキャリア。

JAXA, H-IIAロケット18号機による準天頂衛星初号機「みちびき」の打ち上げについて, 2010/8/4
公式に発表された様なので貼っておく。射場でリアクションホイールの部品交換が完了した様で、QZSS初号機打ち上げは2010/9/11 11:17-11:16 UTC (20:17-21:16 JST)。夜の打ち上げは必要な軌道面への投入の都合から。ところでQZSS twitterのフォロアーが何時の間にやたら増えている。これって中の人は誰?

RTKLIB 2.4.0引き続き。
GEONET 12局データ一年分もダウンロードしたので、記録のためstatic PPP解の結果も貼っておく。IGS局に比較してGEONET局は受信機データ品質が安定しているので取り扱いが易しい。逆に問題が出ないので解析ソフトの試験や改良用にはあまり適していない。ちなみに解析時間は全部で 1h 8' 40"だった (間隔120s)。

Repeatability of 24H Static PPP solutions by RTKLIB 2.4.0, 2009/1/1-12/31 with IGS Final

GEONET Station	Repeatability after Linear Fitting (cm)			Notes
GEONET Station	E-W	N-S	U-D	Notes
0601	0.65	0.34	1.07	graph
0837	0.44	0.29	1.08	graph
0369	0.33	0.24	0.81	graph
0579	0.31	0.22	0.86	graph
0586	0.44	0.31	0.94	graph
0241	0.33	0.23	0.84	graph
0324	0.36	0.24	0.88	graph
0174	0.37	0.27	0.89	graph
3023	0.33	0.27	0.78	graph
0905	0.37	0.28	0.81	graph
2110	0.30	0.23	0.74	graph
0562	0.32	0.22	0.81	graph

RTKPLOTで地理院のF3解読み込みも出来るようにしてF3解との比較もしているが、さすがにF3解はPPP解よりrepeatabilityは明らかに良い。ただどうもPPP解比較で南北に1cm位のオフセットが出る局が多い。例えば0324 (緑: F3解、赤: RTKLIB-PPP解)。上下も5mm位差がある局が多い。上下はmapping関数、潮汐補正やアンテナモデルの差が考えられるが、南北は原因不明。あとF3解の2009/12/31の値は明らかに全局数cmずれていますよ→国土地理院さん。

補足: 2009/12/31のF3解の問題についてはF3解の基準点としている「つくば1」の位置算出に問題があり暫定的な値を使った結果である、と地理院の辻課長から回答を頂いた。本件については、地理院の電子基準点データ提供サービス - おしらせ - 2010/1/21の記事に「再解析結果の値についても、当該日周辺の値に比べ数cmほどのオフセットが見られます。したがって、暫定的な値として取り扱うようお願い申し上げます。」と注記もある。辻さんわざわざ丁寧な回答ありがとうございました。(8/12追記)

...................................................................................................................................

RTKLIB 2.4.0引き続き。
3月に取った屋根上のNovAtelとNGDS配信のリアルタイムGEONETデータ (0225 千葉花見川、基線長151km) をプレイバックして長基線RTKの性能評価していたのだけど、全然性能が出ないので色々と調べたらGEONETデータ側に問題発見。解析結果のメモ。

(1) リアルタイムGEONETデータ (RTCM3) に多数のスリップが認められる (参照)。1時間半に一回ぐらい定期的に全衛星がスリップしており、そこでAmbiguityが全初期化されてしまうのがRTK性能が出ていない一番の原因。
(2) 上記スリップはRTKLIB内部でRTCM3 MT1004のlock time indicatorを使って判定している。
(3) リアルタイムGEONETデータのRTCMダンプを取ってみると、全衛星スリップするタイミングで、全衛星のMT1004のlock time indicatorが、61→0に戻っている (参照: 1:01:36)。これをスリップと判定するRTKLIBの動作は正常。
(4) RTCM 3規格を見てみると、lock time indicatorは7bitで0～127 (ロック時間により割り当て) の値を取るはずだが、リアルタイムGEONETデータは0～61までの値しか取っていない。これは異常。
(5) 国土地理院のサーバから当日 0225 千葉花見川の30s RINEXをダウンロード。こちらはLLIが出力されていない (参照)。
(6) リアルタイムGEONETデータをRINEX変換したもの (参照) と、国土地理院サーバRINEXは疑似距離、搬送波位相の値が共に一致していない。ただし、それぞれをRTKPOSTで単独測位させた測位解はRTCM 3の量子化誤差内で一致する (参照、参照)。
(7) (6)の結果の受信機時計バイアスの推定値は一致しない。国土地理院サーバRINEXによる受信機クロック推定値は良くある鋸歯ステアリング (参照)。リアルタイムGEONETデータによる受信機クロック推定値は変である (参照)。なお国土地理院サーバRINEXを見る限り受信機はTOPCON NETG3 (昨年度更新した受信機)。
(8) 国土地理院サーバRINEXから解析した受信機クロック飛び (1ms) タイミングとリアルタイムGEONETデータの全衛星スリップのタイミングは一致している。

以上より結論として、GEONET受信機→NGDS NTRIPサーバの経路のどこかに問題があり、リアルタイムGEONETデータのRTCM3 MT1004に異常な疑似距離、搬送波位相、lock time indicatorが出力されている。特に受信機クロック飛びをスリップと誤認している点、疑似距離にバイアスが載っている点が問題 (疑似距離へのバイアスは全衛星共通の様だが受信機クロックに0.5ms以下のオフセットを生じている)。

GEONET受信機からNGDS NTRIPサーバまでどういう経路でデータが配信されているか細かくは分からないので、その途中のどこに問題があるのかは分からない。この問題はNGDSに問い合わせるのが筋であるが、実は研究室予算の関係でNGDSのデータ配信契約を3月で解約してしまい現在公式には問い合わせ先がない。さて、この件どうしようか。

補足: リアルタイムGEONETのRTCM3データはlock time indicatorだけでなく観測値も変 (参照)。RTCM3の場合データ圧縮するためL1疑似距離のフル観測値とそれに対する差分を送るのだが、どうもL1疑似距離に変な操作が加えられているので全部の観測値に波及している様だ。どちらのデバッグをしているのか分からなくなってきたのでこの辺でやめるが、GEONETデータ使えないとするとION用の長基線RTKの評価どうやってやろうか。(8:40追記)
リアルタイムGEONETデータをRTCM3→RINEX変換したもの (左) と国土地理院サーバRINEX (右) をそれぞれ基準局データとして使った後処理基線解 (ほぼRTKと同条件) を貼っておく。基線長151.9km。右はFirst Fixに1.5H位かかっているが概ね結果は良好。(9:50追記)

Long baseline KGPS solutions by RTKLIB 2.4.0 (BL length=152km)
with real-time GEONET RTCM3 by NGDS NTRIP (left) and GSI RINEX (right) for base-station

...................................................................................................................................

IGS Workshop Programme and oral presentation, June 28 - July 2, 2010, Newcastle upon Tyne, England
先日のIGS WG 2010のプレゼン資料が公開された。ポスターはこちら。プレゼンのビデオも公開すると言っていた様な。恥ずかしいので別にこれは公開しなくて良いのだけど。

RTKLIB 2.4.0引き続き。
あんまり精度が出ていないがとりあえず評価したので記録のため貼っておく。GTとの差はモデルよりQCの差である。特にスリップの検出が甘い。大きく飛んでいる解は大体スリップを取りこぼしている。

Repeatability of 24H Static PPP solutions by RTKLIB 2.4.0, 2009/1/1-12/31 with IGS Final

Station	Repeatability after Linear Fitting (cm)			Notes
Station	E-W	N-S	U-D	Notes
ALIC	0.70	0.35	2.11	graph
ALRT	0.29	0.46	1.66	graph
BARH	0.49	0.28	0.92	graph
GUAM	0.67	0.35	1.55	graph
HARB	0.53	0.27	0.80	graph
KOKB	0.45	0.26	0.98	graph
STJO	0.46	0.29	1.26	graph
SYOG	0.31	0.28	0.70	graph
THTI	0.68	0.35	1.22	graph
USN3	0.37	0.21	0.70	graph
WHIT	0.75	0.54	1.98	graph

...................................................................................................................................

RTKLIB 2.4.0引き続き。
多数局のPPPの性能評価をしていて実行時間が気になって、もうちょっとのつもりで高速化を始めてしまって時間が取られている。
とりあえず132局1カ月180s間隔PPP-staticで43分まで来た。1局1日あたり0.69s (i7 930 2.80GHz)。一応目標はGIPSYの10倍。昨年10/31に紹介した論文では、ほぼ同一条件のGIPSYの解析時間が1局1日あたり5.6sなので目標に近いところまでは来た。GTとの比較でも15倍程度の速度はあるだろう。モデルが違うので速いのは当たり前だが、とりあえずこの辺で打ち止めかな。これでGEONET 1200局1年分の解析が概ね3日半で終わることになる。MKLを使っているので行列演算だけマルチコアで動いていて、実行中のCPU負荷は88～93%を上下している。行列演算以外はシングルスレッドでしか動いていないので結局もう行列演算がボトルネックになってしまっているということで、ここをなんとかしないとあと数倍の高速化は難しいということになる。
なお以前GTの精度検証のため2004年のGEONET 1年分のPPPを流したときは4台のPC (Pentinum 4 3.2 GHz) で分割処理して1週間以上かかっていた。

やっとちゃんと1年分流せるようになったので、TSKBの2009年1年分のPPP static解の結果を貼っておく。暦はIGS Finalで300s間隔データの24H毎の結果である。原点は2010/1のIGS解。実行時間は4' 52"。処理そのものは大丈夫そうだがちょっと上下の精度が出ていない。GMF、ocean loading、yaw rateモデルの導入は次のバージョンで。

...................................................................................................................................

www.beidou.gov.cn, August 1, 2010 (Google翻訳)
2010/08/01 5:30 (21:30 UTC), Compass衛星5号機, 中国西昌宇宙センタから長征3号ロケットで打ち上げ成功。軌道はIGSOであるという事前情報もあるが細かい情報はまだ公開されていない。

補足: Spacefight Now。軌道上のCompass衛星はこれで5機。そのうちGEOが3機、MEOが1機、IGSOが1機。ただしGEO 2号機は軌道ドリフト中で制御不能になっていると推測されている。昨年の情報では2010年末までに10機打ち上げるとしていたので、まだ今年中に打ち上げはありそうだ。 (22:30追記)

-------------------

さて8月。IGS WGから帰って土日なしで用事のない日はほぼ1日16Hはコーディングとデバッグをしているのだが、結局7月中にリリースできなかった。すいませんがまだもう少しかかります。

...................................................................................................................................