2011/07/01〜

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

2011/06/30

QZ-Vision, QZSS+GPS Data Custom Downloads: カスタムダウンロード

QZSS用のエフェメリス (放送暦) のダウンロードが可能になっている。ということで早速JAVAD受信機の出力をRTKCONVで変換した結果と比較してみた。

JAVAD Raw - RTKCONV 2.4.1:

J 1 11  6 23  5  0  0.0 -.702682882547E-06  .568434188608E-12 -.555111512313E-16
      .910000000000E+02  .133000000000E+03  .247260299384E-08  .382528848879E+00
      .520236790180E-05  .758627771866E-01  .130385160446E-04  .649310024452E+04
      .363600000000E+06 -.968575477600E-06 -.132251908384E+01 -.184401869774E-06
      .712040875086E+00 -.211875000000E+03 -.157397689795E+01 -.277154401736E-08
      .174292974288E-09  .200000000000E+01  .164100000000E+04  .100000000000E+01
      .240000000000E+01  .700000000000E+01 -.465661287308E-08  .910000000000E+02
      .360006000000E+06  .000000000000E+00

QZ-Vision (brdc1740.11q):

J 1 11  6 23  5  0  0.0-6.998889148235D-07 1.591615728103D-12 2.775557561563D-17
     9.100000000000D+01 1.330000000000D+02 2.472602993839D-09 3.825288488791D-01
     5.202367901802D-06 7.586277718656D-02 1.303851604462D-05 6.493100244522D+03
     3.636000000000D+05-9.685754776001D-07-1.322519083840D+00-1.844018697739D-07
     7.120408750862D-01-2.118750000000D+02-1.573976897953D+00-2.771544017362D-09
     1.742929742877D-10 2.000000000000D+00 1.641000000000D+03 1.000000000000D+00
     0.000000000000D+00 7.000000000000D+00-4.656612873077D-09 8.590000000000D+02
     3.627540000000D+05 1.000000000000D+00

ということでクロックパラメータが合ってないんですけど。QZ-Visionの方はIODCとIODEの値が食い違っているので、単に異なるレコードのエフェメリスとSVクロックパラメータを混合して出力してしまっているだけかも。ただTOCとTOEの値は食い違っていないので、ここはQZ-VisionのRINEXコンバータのバグではないかと思う。よく調べてみるとJAVADの方もちょっと変な場合があるので、JAVADのF/Wの動作に怪しい所もないことはない。

(本解析にはJAXA殿からお借りしているJAVAD受信機を使用しました。)

補足: ついでなので JAVAD Raw - JPS2RIN (GUI版) (v. 2.0.36) 解:

J01 11  6 23  5  0  0.0-7.026828825474D-07 5.684341886081D-13-5.551115123126D-17
    9.100000000000D+01 1.330000000000D+02 2.472602993839D-09 3.825288488791D-01
    5.202367901802D-06 7.586277718656D-02 1.303851604462D-05 6.493100244522D+03
    3.636000000000D+05-9.685754776001D-07-1.322519083840D+00-1.844018697739D-07
    7.120408750862D-01-2.118750000000D+02-1.573976897953D+00-2.771544017362D-09
    1.742929742877D-10 1.000000000000D+00 1.641000000000D+03 0.000000000000D+00
    2.000000000000D+00 7.000000000000D+00-4.656612873077D-09 9.100000000000D+01
    3.600300000000D+05 4.000000000000D+00

JPS2RINは相変わらずレコードの2行目以降が1カラムずれる問題とヘッダ1行目に衛星系識別 (J) が抜ける問題が解決されていない。(→ JAXAさん)。この問題が原因でRTKLIB 2.4.1ではJPS2RINが出力したQZSS NAVファイルを正常に読み込みできない。なおRINEX 2.12はまだ正式規格にはなってないはずで、RTKCONVは昨年7月位に関係者限定で流されたこのJAXA案に従っている (RINEXヘッダは"2.10"で出力。これは"2.10"にしないとエラーとなる解析ソフトがあったため)。やはりまだフォーマットに混乱があるので、データを公開するのであれば何の規格に従っているかを明記してほしい。(21:05追記)

補足:
少し曖昧なことを書いてしまった。GPS航法メッセージのIODCは10bit、IODEは8bitで下位8bitは一致する。GPSの場合、SVクロックの特別な状態を表すためIODCの上位2bitが0以外の場合もある。さて、上記のケースでQZSS航法メッセージのIODE, IODC, TOE, TOCがどう切り替わっているかダンプしてみた。ここではJAVAD 受信機が出力する [qd] メッセージを直接デコードしている。

0 SAT=84 IODE= 90 IODC= 858 TOE=360000 TOC=360000
0 SAT=84 IODE= 91 IODC= 91 TOE=363600 TOC=363600
0 SAT=84 IODE= 91 IODC= 347 TOE=363600 TOC=363600
0 SAT=84 IODE= 91 IODC= 859 TOE=363600 TOC=363600
0 SAT=84 IODE= 92 IODC= 859 TOE=367200 TOC=363600 *
0 SAT=84 IODE= 92 IODC= 92 TOE=367200 TOC=367200

以上のように、やはり同一IODEでIODC上位2bitだけ切り替わっていることがわかる。なお、*をつけたケースはIODEとIODCが不整合を起こしており、航法データの整合性チェックで捨てられている。これは、衛星の送信データ自身が不整合を起こしているのか受信機F/Wの問題かを判断するのは難しい。過去きちんと調べているわけではないが、GPSの場合、同一IODEでIODCの上位2bitだけ更新されるという運用は多分ないのでないか。RTKLIBでもエフェメリス切り替えはIODEだけを見ていて、IODCの更新はチェックしていない。従って、RTKCONVでも、特別なオプション (-EPHALL) を使わない限り、IODEが同一なら、前のエフェメリスと同一と判断されてRINEX NAVファイルには出力されない。

IS-QZSS-1.2を調べてみた。

> 5.1.2.2.1 IODE, IODC
>
> 異なるデータセットのIODE とIODC の送信に関しては以下のルールが適用される。
> (1) 送信されるIODC はその前の７日間衛星から送信される値とは異なる。
> (2) 送信されるIODE はその前の６時間衛星から送信される値とは異なる。
> (3) エフェメリスデータを更新せずにSV クロックパラメータだけ更新する場合は、IODC の上位
> 2 ビットだけが更新される。この時、SV クロックパラメータの元期は更新されず、エフェメリス
> データの元期と同一である。

ということで以上のようなIODE, IODCの運用はQZSSでは明確に規定されており、仕様違反という訳ではない。(上で「QZ-VisionのRINEXコンバータのバグ」と書いてしまったのは取り消します) ただ (3) はQZSSの独自仕様なので、GPS-QZSS間のこの仕様差が原因で、QZSSのSVクロックパラメータ更新が認識されない受信機が今後現れるかもしれない。

この問題直すの結構大変なのだけど、QZSS正式サポートを標榜している以上、RTKLIBではちゃんとパッチ出しますかねえ。(とりあえず忘れないようにSupport Infoには追加した) (7/1追記)

再補足:
JAVAD受信機で出力されるQZSS航法データのIODEとIODCの不整合の件、JAXA殿でわざわざ調査いただいて衛星側は問題ないと、ご連絡いただいた。JAVADの[qd]データはサブフレーム単位で出力されるので、#1 フレームがパリティチェックエラー等で欠落し、#2, #3だけ出力されたようなケースでは一時的に上記の様な事象が発生し得る。正常動作の範囲内であり「受信機F/Wの問題」とも言えないので上記記述を削除した。どうもお騒がせしました。(7/8 追記)

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

2011/06/29

JAXA, Call for applications: Hosting sites for Multi-GNSS Monitoring Network

JAXAから複数GNSSモニタ網 (MGM) の基準局募集が始まっている。MGMはJAXAが進めている複数GNSS対応の基準局網を構築しようとする活動。主な目的はQZSSを含めた複数GNSSの軌道クロック推定精度を改善し、最終的にそれらを使ったPPPの性能を上げること。MGM構築のため、JAXAは計60式のJAVAD受信機およびアンテナを参加機関に提供する、参加機関はこれらの受信機を自分のサイトに設置・運用し、それらの観測データをJAXAにオンライン提供する。参加するメリットとしてはこれら基準局網の観測データを相互利用できる。その目的からして、主な対象は海外の大学や研究機関である。第1ステップとしてQZSSが受信できるアジア太平洋地域で20局の基準局網を構築し、第2ステップで全世界に40局を追加する。今後、IGSのパイロットプロジェクト"Multi-GNSS Pilot Project"で活用することも考えている様だ。複数GNSS対応基準局網の構築は、昨年からJAXAが進めている"Multi-GNSS Demonstration Campaign"活動の柱の一つとなっている。応募締め切りは8月末。

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

2011/06/25

5/26,27に行われたRTCM年次総会でRTCM v.3 SSR (state space representation) wide area corrrection メッセージが正式標準として承認されたとのこと。予定よりずいぶん遅れたが、程無くRTCMのサイトで文書が入手できるようになるはず。これは教えてもらった。

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

2011/06/24

6/22のQZSSユーザミーティング時のL1-SAIFに関する質問の回答に関し、発表者のENRI伊藤さんから後から直接訂正があったと海洋大安田先生からお聞きした。結構重要な点で、ここで書いてしまって問題ないと思われるのでちょっと紹介する。もともとの質問は「現在のQZSS L1-SAIF信号ではQZSS用に拡張した (SBAS非互換の) メッセージが放送されていない様だが、その通りなのか」との趣旨 (その場での回答は「放送されているはず」というもの。23:58追記)。訂正後の回答は、

(1) 事前には拡張メッセージの生成・評価を行っていたが、解析の結果SBAS互換メッセージのみで目標精度が得られることが分かり、スケジュール制約から現在の処理システムではSBAS互換メッセージの生成のみ実装した。従ってQZSS用拡張メッセージは放送していない。
(2) 今後、拡張メッセージ生成機能を追加予定であるが、時期および内容はまだ検討中である。

実は、大学の学生さんのテーマとしてL1-SAIFの評価ということでMSASとの比較評価をしているのだが、東京エリアでのデータではMSASと比較して殆ど測位性能の改善は確認されていない。既に実運用し技術的にも確立しているMSASと同じ補強方式のシステムを多大な予算を使って開発する価値については、今後問われるべきだろうと思う。

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

2011/06/23

BBC news, Europe's Galileo sat-nav in big cash boost, June 22, 2011

バジェットオーバーのためIOC 18機以降のシステム構築の目途が立っていなかった欧州のGalileo計画で、コスト削減により追加6機の衛星調達が可能となったという明るいニュース。これで2015か2016年には24機体制でFOCに近いサービス提供ができそうとのこと。

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

JAXAから、昨日「みちびき」のアラートフラグを解除した、と発表 (参照) があったので本当に解除されたのか調べてみた。以下衛星: TOE: L1C/A Health Flag (6 bits)

J 1: 2011 6 22 0 0 0: 111111
J 1: 2011 6 22 1 0 0: 111111
J 1: 2011 6 22 2 0 0: 000111
J 1: 2011 6 22 4 0 0: 000111
J 1: 2011 6 22 5 0 0: 000111
...

IS-QZSS-1.2によると、QZSSの航法データフレーム1のHealth Flagは

(MSB) L1:L1C/A:L2C:L5:L1C:LEX (LSB)

なので、TOE=2011/6/22 2:00:00から、L1, L1C/A, L2CはHealthyに切り替わっている。ただしL5, L1C, LEXはまだUnhealthyに設定されている。
なお、RTKLIB 2.4.1では、このフラグがAll 0にならないとその衛星を除外するので、QZSSを測位に組み込もうとするとまだ特別なオプションを設定する必要がある。

(本解析には、JAXA殿からお借りしているJAVAD受信機のデータを使用しました。)

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

GDC GNSS Data Center, Realtime Precise Point Positioning Monior

No.13の解析をRTKLIB 2.4.1に切り替えてもらった。ただし、2.4.1はエフェメリス切り替えにバグがあって、インストールしてもらったのはバグフィックス済みの版 (これは動作に問題なければ公式バッチを出します)。他の解 (BNC解) と比較して、RTKLIB解はずいぶん短周期ノイズが多いのだけど、これはたぶん補正データのレイテンシのせい。現状IGSリアルタイム暦は5〜15 sの遅れがある。また補正データ間隔が10 sなので補正は最大25 s遅れることになる。従って単純な処理ではこの遅れの間の衛星クロックドリフトが解の誤差を増す。BNCにはこのレイテンシを隠蔽するため、受信機データを一定時間バッファリングし解を遅らせて出力するオプションがあるらしい。これって厳密に言えば「リアルタイム」と言えないよなあとは思うが、リアルタイム性を犠牲にしても精度を高めるオプションがあってもよい。RTKでも基準局データのレイテンシに対応するため、"Low-latency"モードと"Matched-solution"モードを切り替えられる受信機もある。ということで将来の版では何らかのオプションを追加するかもしれません。本質的にはIGS側で補正データのレイテンシを低減してほしい訳だけど、これは結構大変な様だ。

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

2011/06/22

W.Bertiger et al., Single receiver phase ambiguity resolution with GPS data, Journal of Geodesy, 2010

EGU PPPセッション資料でよく参照されているJPL Bertigerの2010 JOG論文。PPP-AR関係。ちょっとこれはひっかかていなかった... と思って検索したら昨年3/23にこの備考録で貼っていた。otz... 覚えていないということは読んでないということ。最近こういうのばっか。

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

2011/06/21

連合大会のリアルタイムPPP発表資料 (参照) p.6の表にIGS-RTPPのキーマンESOCのLoukisからコメント貰った。

(1) ESOCはVeriposとは協力関係にはない。でもVeriposは確かにESOCの解析パッケージ (NAPEOS) 使ってる。
(2) ESOCはFugroとは協力関係にあるので表は正しい。(でも、"Fuguro"は"Fugro"なので間違えないように。)

とのこと。Loukis指摘ありがとう。しかし、いい加減なことを (特に英語で) 書くと、誰が見てるか分からないなあ。

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

EGU11 session, GNSS for Geosciences: PPP applications and modeling improvements, Vienna, Austria, April 6, 2011

今年4月 EGUのPPPセッション発表資料一式見つけた。
RTCM3 MSM (multi-system-messeges) の標準化が始まっているようだ。これって前はHP-RTCMと言ってたのが名前変わったのかな。 でもこの分野、めまぐるしく技術が動いていて、はっきり言ってフォローするのが大変。
ところでCONGOってJAVAD DELTA受信機がかなり入っているようだけど、当然QZSS受かるんだよなあ。

補足: BlewittのAmbizapがAmbizap3になってGIPSY-PPPのキネマティックでもアンビギュイティが解けるようになったらしい。 基線解析に比較したPPPの最大のメリットは明らかにスケーラビリティで、原理的には広域に分散した100万台の受信機位置 でも分散して解くことができる。まあ皆最終的にはそこを狙っているわけだけどまだまだ課題は多い。(11:10追記)

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

2011/06/20

日立造船, GPSによるリアルタイム超長基線高精度測位法を開発 〜高精度測位の制限距離を20kmから1,000kmへ、GPS波浪計への実用化も目指す〜, 平成23年6月20日

日立造船が米GPS solutions社と共同で開発した"PPP-AR"測位技術を発表。
別にいちゃもんつけるつもりはないんだけど「基準点を必要としない」というのはたぶん嘘で、補正データ生成のために複数「基準点」を含んだ「補正網」が必要なはず。 実は、リアルタイムPPP with ARにしても長基線RTKにしても解決すべき課題がたくさん残っていて、 実用化にはまだ時間がかかると思うけど、色々な応用に実際に使ってみてその知見を蓄積・フィードバック することが現実の技術開発には重要だと思うので、ぜひ頑張って下さい。

補足: GPS Solutions社のPPP-ARってあんまり細かい情報が公開されていないのだけど、たぶん今のところグローバルな 基準網をつかってアンビギュイティ解けないのじゃないかな。すなわちローカル基準網限定。 そうすると単一基準点を使った長基線RTKとそれほど条件は変わらない。まあ複数基準点使うので基準点側 のノイズが少し低減されるとか、補正データ量を減らせるとかのメリットがないわけでないけど。
デメリットはシステムが複雑になって、サーバ処理のため補正データのレイテンシが増えること。 あと、懸念事項だけど補正データが本当に安定に推定できるか。
ローカル基準網限定と予想しているのは単純で、軌道としてIGUをそのまま使っているから。 現状ではIGUはグローバルPPP-ARには精度や品質が足らない。 あと、システムとして考えるとIGUの更新止まったら使えなくなってしまうというのもちょっと問題。 特に防災とかに使おうとするとなんらかのバックアップが必要 (これは長基線RTKも同じ)。 最終的にはマルチGNSS対応のグローバルなPPP-ARでどこでもcm級測位というのが目標なわけだけど、 これには色々と技術開発が必要なのではないかと思う。(6/21追記)

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

2011/06/19

RTKLIBの長基線RTKの評価のため3/11のIGS MIZUとUSUDの1Hzデータで長基線の基線解析をしてみた。 2011/03/11 03:00-08:38 GPST。 基線長413km。暦はIGUの予報値だけ抜き出して使っている。パラメータはかなりチューニングしているがRTKと同条件。 USUDは西側の山と64m鏡の影響で基準局としては条件が良くないのだけど他に公開データないので。 First Fixまで30分弱かかっているのは仕方ないけど、ちょっと上下の長周期ノイズが厳しい。 対流圏のモデルをなんとかもうすこしFineにしないといけない。 あと、5:49辺りの変動はたぶん基準局の変動を拾ってしまっている。 解はこちら。 設定はこちら。 解はRTKPLOTで、設定はRTKPOSTでそのまま読み込んで表示したり解析したりすることができます。 観測データもIGSサイトからダウンロードできますので興味のある方はお試しを。

補足: PPPの結果はこちら (図, 図, 解, 設定)。 RTKLIB 2.4.1。暦はCODE-5S。PPPは基準局変動の問題はないが上下ドリフトが酷い。 あとは現状ではCODE-5Sクラスの品質のリアルタイム暦が手に入らないのが問題。 結局現状では一長一短。 どっちを改良するのが早いかは分らないけど、たぶん長期的には手法として統一されると思う。(15:40追記)

GPS Solutions, PPP Kinamatic Solution for the Great Tohoku Earthquake, M9.0 1Hz Post-processing with Global Satellite Clock Estimated with Real-time, April 5, 2011

GPS Solutions社RTNetとVERIPOS/APEXリアルタイム暦によるGEONET 1Hz PPP結果。 実はRTKLIBで解析をしてみようと思ったのはこれを見つけたから。アンビギュイティは解いていないはず。 リアルタイム (相当の) PPP解としてはかなり良いが、やはり細かく見るとPPPの長期ドリフトの悪影響が見える。 (垂直だけでなく水平も) VERIPOSってESOCのT.Springerが絡んでいてESAの解析エンジン使って自前で軌道時計を決めてるはず。 GLONASSサポートしないのかな。(16:28追記)

基準局をIGS DAEJに変えて再度基線解析。基線長1246km。 図, 図, 解。 ついでに基準局IGS SHAO。基線長2009km。 図, 図, 解。 設定は基準局USUDと基準局座標以外同じ。 DAEJ基準解の5:54位の変動って明らかに基準局の変動だよなあ。 DAEJって震源から1400kmは離れているはずだけどP-Pで上下20cmは動いている。 改めて物凄い地震であったことが分かる。 2000km基線でもそんなに悪くないけどこれはたまたま衛星配置が良かったから。 長期で見ると2000km基線では共通衛星の数が減るのでかなり厳しい。 (18:25追記)

The M9.0 2011 Tohoku-oki Earthquake (March 11, 2011)

名大鷺谷先生によるMIZU-USUDの基線解析結果を見つけた。Bernese 5.0+IGS Final。 Berneseってちゃんとキネマティック解けるんだ。(6/20追記)

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

2011/06/17

6/14の産経の記事、再度、何度も何度も読み返したのだけど、「南北アメリカは米国...」云々はWAASとEGNOSのことを指しているのかなあ。そうするとこの記事を書いた記者はSBASのことを「次世代衛星網」だと思っている訳だ。でも「米国は独力で全世界に次世代衛星網を構築することを断念した」なんて事実はないはずだし、やっぱり聞きかじった色々な話が記者の頭の中でごっちゃになって自分で勝手なストーリーを作り上げている様に思える。「米が一極支配する現状から、地域大国が並立する多極型の構図へ変わる」というのは正しい認識だと思うけど、やっぱり「次世代型」というのが具体的に何を指しているのか曖昧なので、全体としては何を書いているのかさっぱり分からない。あと、少なくとも中国には日本と「覇権バトル」をしているという認識はほとんどないと思う。中国が、そして欧州もだけど、独自の衛星測位システム構築を促進しているのは、自国の社会インフラを米国GPSに依存することの安全保障上のリスクを軽減するいう意図が大きい。特に中国においては、米国に対抗して世界における軍事「覇権」を拡大したいという意図も当然あるだろう (衛星測位システムの元々の目的は軍事、例えば弾道ミサイルの誘導だから)。別に日本とアジアでの地域覇権 (?) 争いしている訳ではない。どうも記事では以上の様な基本的な現状認識が変なため、覇権争いに乗り遅れるので日本も「次世代」衛星網開発を戦略的に促進すべき、という主張に説得力が全くなくなっている。

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

2011/06/16

S.Ozawa et al., Coseismic and postseismic slip of the 2011 magnitude-9 Tohoku-Oki earthquake, nature, 2011

国土地理院のグループによる主にGEONETデータを使った東北大地震のメカニズム解析。多分今後この地震の解析結果を発表する際のreferenceになりそうなので購入。$32也。英語ではTohoku-Oki earthquakeが正式名称 (?)。日本語ではなんかまだ一定しないみたいだけど。
GPSはBernese 5.0とIGUを使って1,400 km基線で解いているとのこと。でも6Hのスタティック解 (Q2解?) らしいので地震による細かい時間変動は追えてないのではないか。先日、RTKLIB 2.4.1の試験を兼ねて3/11のGEONETデータをダウンロードして最大1,300 km位の基線でGEONET全点のキネマティック解を解いてみたのだけど、本震後1H以内に起きた余震でも各地でかなり大きく動いているのが明瞭に観測できている。ということでぜひキネマティックでの解析も今後追加して下さい。

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

2011/06/15

NHK、クローズアップ現代：災害に威力 GPSの可能性, 2011/06/16

というのが明日放送予定とのこと。なかなか興味深い応用である。

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

NHK NEWSWeb, マグニチュードGPSで迅速計算, 2011/06/14
jijicom, 海溝型地震規模を即時推定=GPS利用、津波高さ予想も - 東北大, 2011/06/14

大規模地震の規模推定や津波予測をGPSを使って迅速に求めるという研究。実はGPSデータ解析にRTKLIBによる長基線RTKを使って頂いている。こないだの連合大会の時に東北大の太田さんに東北地震の解析結果アニメーションを見せて頂いたのだけど、とてもインパクトのある成果であった。自分のやっていることがちょっとでも人の役に立っているというのはとても励みになることである。このニュース、直接太田さんに教えて頂いた。いつも色々とありがとうございます。

補足: 東北大地震で気象庁のマグニチュード予想が当初過小で後から大きく修正された様に、現状の地震計による地震規模予想は誤差が大きい様だ。この原因はよく分からないのだが地震計の多くは加速度を測っているので、機器誤差により正確な絶対変位が求められないというのが大きいのではないか。GPSはノイズは大きいのだが絶対変位を地震計より正確に求められるというメリットがある。数100km基線以上のRTKを使えばローカルな地震であればかなり正確な変位をリアルタイムで求めることができる。今回の太田さんらの研究は、長基線RTKによるGEONET 1Hzデータ解析から、インバージョンにより地震断層モデルを推定し、その結果からさらに発生する津波の大きさや到達時刻を推定するというものである。以上の解析を地震発生後数分以内に行うことにより有効な防災対策に繋げるというのが研究の動機であろう。
ただ、GPS解析という観点でみるとまだ課題は多い。長基線RTKの安定性の問題は当然ながら、RTKではどこに基準点を置けばよいか分からないというのも大きい。今回の解析でも通常のRTKでは、震源から数100 km以上離れた基準点変動を拾ってしまって、全観測点の解がフラフラするというのが明瞭に観測されている。太田さんらはこの点を改善する工夫を入れられているのだが、逆の悪影響もあって必ずしもうまくいっているとは言えない。ここは複数基準点を使って基準点変動の影響を緩和する手法とかを本格的に導入する必要がある。もちろんここはリアルタイムPPPというのも有力な訳であるが、現状では精度不足である。リアルタイムPPPのもう一つの問題点は全体システムが複雑になりすぎるという点で、個人的にはここ5年位のスパンでは長基線RTKを改良する方が有力ではないかと思っている。(7:46追記)

再度, 記事を読んでみたら地震計は振り切れが問題だった様。GPSは当然 (ちゃんと解析すれば) 原則サチらないので、大きな地震になればなるほど有利であるとは言える。あとGPSは日本では既にGEONETという世界でもまれな稠密なリアルタイム観測網が出来上がっているので、ちょっと強化すれば少ない費用で多大な効果が上げられるというメリットも大きい。でも今回の地震では通信網もかなりやられたらしいので、本当にリアルタイム防災に使おうとすると通信系の強化も必須になるとは思う。(21:20追記)

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

2011/06/14

MSN産経ニュース, 次世代GPS戦略打ち出せない日本 中国との覇権バトル激化, 2011/06/14

なんか変な記事。事実誤認も多いし２機目以降QZSS開発を推進したい誰かに取材した記者が自分の思い込みで書いたという印象。もう少し色々と勉強した方が良いのではないのかなあ。

補足: 例えば図の「衛星測位・補強システムの現状」って何を表しているのだろう。ご存知のようにガリレオはまだ一機も上がっていないし、QZSSは「補完・補強」だし、補強の「インド」はGAGAN？ IRNSSは? 測位は世界全体で、補強は地域というのも変だし、この図1枚取ってみても突っ込みどころ満載。別に衛星測位システムに対する意見を書いても良いけど、全国紙の一面に載せるならまずは正確な現状認識をした上でないと新聞の信用落とすだけだと思うけど。(20:53追記)

あんまりつっこんでもしかたないのだけど、「南北アメリカは米国が担当、欧州・アフリカは欧州の連合体が担当」とか、はっきり言って頭痛い。(22:03追記)

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

2011/06/13

ということで積み残しになっていた事項が色々完了。やっと次のステップに進めるかも。

アクセスログを見てみると、昨日だけでRTKLIB 2.4.1は300件近くダウンロード頂いた様で、ありがたいことである。新しく作ったチュートリアル頁のサンプルデータをダウンロードしてRTKNAVIを動かしてみるとRTKの強力さが実感できると思う。ぜひ誰か、ビジネス化できる良い応用を見つけて下さい。

IS-GNSSのアブスト締切が今日なのだけど、迷った結果出さないことに。春のシドニーは魅力的だったのだけど。多分秋まで全然時間がとれないので。IONも見送ったし今年は発表は最低限に絞る予定。

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

2011/06/12

RTKLIB: Tutorial and Demonstration for RTK

RTKLIB 2.4.1 tutorial for RTK page is added. Sample data for RTK can be found in the page.

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

2011/06/11

RTKLIB: An Open Source Program Package for GNSS Positioning

RTKLIB 2.4.1 is just released. Enjoy RTK.

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

2011/06/08

NOAA Center for Tsunami Research, DART (Deep-ocean Assesment and Reporting of Tsunami)

今回の東北大震災の大津波被害を受けて、GPSによる津波ブイの開発や実験の話が色々な所で出ている様だ。私のところにもRTKやPPP応用ということで複数の所から別の案件として話が来ている。ということで教えてもらった米NOAAのDARTブイ。20年位前から広域展開済みの様。津波ブイの場合、通信回線をどうするかが常に問題になるが、DARTの場合は現在はIridiumを使っている様だ。GPSも載っているが津波検知自体は他のセンサを組み合わせて行っているらしい。

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

RTKPOST_MKLの解析処理があんまり速くならないなあとお思いのRTKLIB利用者の方へ。
環境変数 OMP_NUM_THREADS=<CPUコア数> を設定ください。MKLが複数コアを使う様になり、処理速度が改善します。CPU負荷も100 %近くに上がるはずです。マニュアルに書くのを忘れてたのでver. 2.4.1のマニュアルには入れます。なお一般的に数値演算の覆いAPやはりHT=OFFの方が性能が良いようです。

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

2011/06/07

NVS Technologies AG, NAVIOR-24 GPS/GLONASS Receiver

あまり聞いたことのないスイスのメーカの24ch OEM GPS/GLONASS受信機ボード。ボードそのものは提携しているロシアNAVIS社の製品らしい。BINRというプロトコルでraw dataが出る様で、今後RTK用にちょっと評価してみるかもしれない。この情報は教えてもらった。

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

できれば今週中にRTKLIB 2.4.1の正式版を出したいのだけど、まだ結構バギーでちょっと無理かなあ。

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

Matlab R2011aを入れて恒例のベンチ。ちなみにエクスぺリンスインデックスの値は7.8, 7.8, 4.8, 6.2, 7.7 (過去のメインPCは7.4, 7.7, 7.6, 7.6, 7.8, VGAは低消費電力化のためGeForce GTX470からRadeon HD5450に入れ替えている)

Sandy BridgeからSIMD演算レジスタ幅が256bitに拡張されているので、行列演算速度はもう少し上がってよいはずだがあまり改善されていない。もしかするとHTはOFFにした方がよいかも。まだMatlab内部で使っているMKLがAVX対応になっていないのかもしれない。

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

JCASTニュース, 大震災40分前から電子量が急増　地震予知実現にわずかな可能性, 2011/6/4

元の記事は中日新聞らしいが既にリンクが切れている。こないだの連合大会で北大 日置先生が発表されたらしい。日置先生のグループはずいぶん前からGPSによる電離層電子密度計測を使って色々な地球科学的現象を観測しようとしているので、その研究の一環。でも解析テクニック的に新しい手法を開発したという訳でもなさそう。地震発生後の電離層擾乱は色々な地震で確認されているので多分間違いないと思うが、本当に地震発生前に起こっているとすると予知に使える可能性がない訳ではない。でもM9クラスでないと検知は厳しいとなると、事例が少なすぎて通常の電離層擾乱との差異を判断出来る程のデータを集めるのは無理なのではないかと思う。

補足: 「わずかな可能性」って、誰も本気で実用的な地震予知なんて出来ると思っていないことが良く分かる記事タイトル。まあ過去の研究からするとこの認識は当然なんだが、しかしなんだなあ。(11:32追記)

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

2011/06/03

IS-QZSS (1.3版) ドラフト, 準天頂衛星システムユーザインタフェース仕様書, 2011/6/2

IS-QZSS (1.3版) ドラフト公開。コメント・改善提案受け付けは6/30迄。6/22にはユーザミーティングも予定されている。

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

2011/06/02

u-blox to demonstrate GLONASS positioning at Telematics Detroit, May 31, 2011

u-bloxも次期モジュールからGLONASS対応になるようだ。"second half 2011" ということは今年後半にはサンプルが出るということ。LEA-7T (?) が出れば実用的な低価格RTK用の有力なモジュールになるはずである。NovAtelのOEMStarは性能は問題ないけど、ちょっと高いし、14ch制限はやはり少し厳しいので。できれば10 Hzのraw出力を要望したい。

あとは高性能 低価格L1-GPS/GLONASS用アンテナの良いのがあれば良いのだけど。Tallysman wirelessのTW-2400がちょうど今手元にあるので今後ちゃんと評価してみるつもり。

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

いつのまにか6月だあ。

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

〜2011/05/31