2009/01/01〜

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

2008/12/31

今年も今日でお終い。
今年は色々なことがあって一年が短かったが、結構充実していた年でもあった。ただGT0.6.4といいRTKLIB2.2.0といい、年内に何とかしたいと思っていたリリースが出来なかった点が心残り。世の中の不況の影響もあって、来年は私の仕事環境も大きく変わりそうな雰囲気だが、また好きなことをやっていければ良いなあと思う。皆様よいお年を。

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

2008/12/29

年末だというのにまだコードを書いている。NTRIPライブラリを使ったAPとして簡単なNTRIP Source Table Browserを書いた。いい加減にしないと年が越せない。

補足: ntrip caster www.igs-ip.net:2101のストリーム一覧。他のストリームを見ても、RTCM2ではなく既にRTCM3の局が結構多い。RTCM3の主なメッセージは1004 (Extended L1&L2 GPS Observables), 1006 (Stationary RTK Reference Station ARP with Antenna Height), 1008 (Antenna Descriptor & Serial Number)。使うためにはとりあえずこれだけ実装すればよいだろう。(12/31追記)

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

2008/12/28

年末である。ここ1週間、Ntripサーバ/クライアントの実装を通信ライブラリ構築からやり直していた。大体動くようになったのだが、BKGのNtrip CapsterがRTCM仕様と異なる動作をするのを調査したり、winsockの特別な仕様を確認したりして遅くなってしまった。久しぶりにソケットプログラムを書いたのでスティーヴンスを読み返して勘が戻るのに時間がかかったというも大きかった。なお書いたコードはAPと共にRTKLIB2.2.0に入る予定。GT0.6.4は文書の英語化でちょっと止まっている。両方とも今年中に区切りをつけたかったのだが来年にずれ込むことになってしまった。12/27で仕事納めの予定だったので今年はここまででお終い。(2:40)

なお12/17に書いたNtripによるバイナリデータの文字化けの件、結論から書くとBKG Windows Ntrip Server 1.3.1に問題がある様だ。ここでシリアルから取り込んだバイナリデータが一部文字化けしている。COM 2桁未対応やNovAtel USB取り込みが出来ない件といい、Linux用ソースコードを眺めてみてもどうもあまり出来がよろしくない。
さてNtripサーバとクライアントが動くようになったがEmobile経由だと回線が安定しない。頻繁に固まるしTCPなので回復後に急に流量が増えて安定して通信できない。やはり携帯回線はリアルタイムストリームにはあまり条件が良くない (You Tubeなどはバッファを十分大きくとればあまり問題にならない)。年明けにはこの辺も実環境で評価してみたい。

補足: 開発したNTRIPサーバ/クライアントAP画面。左がNTRIP server、右がNTRIP clientとして動かしている。

覚書: winsock版非ブロッキングconnectのコード。簡単な様だがエラーコードが結構微妙(一般にはselectでチェックするのが普通)。スティーヴンスによれば、非ブロッキングconnectに関しては移植性に関する数多くの問題点があるとのこと (15.4)。(gethostbynameをconnect呼び出し毎に行うのは非効率なので最終コードでは改良した) 今回は非ブロッキングソケットを使ってサーバを書いてみた。複数入出力を取り扱うのは入出力毎に別スレッドを起こすのが普通だが、多数スレッド管理は排他やスレッド停止条件等、落とし穴が沢山あってデバッグが大変。その点、非ブロッキングで書くと1スレッドで排他もほとんどいらない。いわゆるポーリング型処理になるので処理効率が少し心配だったが周期を10msにしてもほとんどCPU負荷は上がらない。ただシリアルデバイスのwriteがまだ上手く非ブロックにできていない。

補足: gethostbyname()も非ブロックでは動かないのでdnsが引けないとタイムアウト (普通15s) するまで制御が帰ってこない。ちょっと調べた範囲ではタイムアウト値の変更はできない様。非ブロック化はDNS用別スレッドを起こすしかない様であまり面白くない。ということで完全な非ブロック化は結構難問。dns引くのは最初だけなのでとりあえずこれはあきらめる。(1/1追記)

static int consock(tcp_t *tcp)
{
    struct sockaddr_in addr={0};
    struct hostent *hp;
    int err;
    u_long mode=1; 
    
    /* resolve address */
    if (!(hp=gethostbyname(tcp->saddr))) {
        closesocket(tcp->sock);
        return -1;
    }
    addr.sin_family=AF_INET;
    addr.sin_port=htons(tcp->port);
    memcpy(&addr.sin_addr,hp->h_addr,hp->h_length);
    
    /* non-block connect */
    ioctlsocket(tcp->sock,FIONBIO,&mode);
    if (connect(tcp->sock,(struct sockaddr *)&addr,sizeof(addr))==-1) {
        err=WSAGetLastError();
        
        if (err==WSAEWOULDBLOCK||err==WSAEINPROGRESS||err==WSAEALREADY) {
            return 0; /* in progress */
        }
        if (err!=WSAEISCONN) {
            closesocket(tcp->sock);
            return -1; /* error */
        }
    }
    return 1; /* connected */
}

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

2008/12/25

Moscow News, Russia launches rocket with three new Glonass satellites, Dec 25, 2008
2008/12/25 10:43 UTC、3機のGLONASS-M衛星、カザフスタンのバイコヌール宇宙基地からProton-Mロケットで打ち上げ成功。9/25の打ち上げに続いて今年2度目。昨日までの軌道上GLONASS衛星は19機。うち16機が運用中で2機が保守中。18機でロシア全土、24機で全世界をカバーする連続的な航法サービスを提供できるとしている。今後2011年までに30機構成とする計画。

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

2008/12/24

G.Gibbons, ICG-3 Meeting Reflects GNSS's Competing Interests, Cooperative Objectives, Dec 23 2008, Inside GNSS
Inside GNSSが2008/12/8-12に米パサデナで行われた第3回 ICG (International Committee on Global Navigation Satellite Systems) のレポートを書いている。あんまり面白そうな話はないのだがGLONASS-KやGAGANのステータスは少し新しい情報。ところで未だにICGとCGSICの関係が良く分らないのだけれど、ICGは国連主導、CGSICは米国主導という違い?。

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

2008/12/23

22-12-2008 Proton-M/3 Glonass-M Roll-Out
15-12-2008 Glonass Satellites at Baikonur: Processing in Line with the Schedule
05-12-2008 Prelaunch Processing of Three Glonass-M Satellites Continues
01-12-2008 Glonass-M Prelaunch Processing is Over

クリスマスにに3機のGLONASS-M衛星がProton-Mロケットで打ち上げられる予定だが、写真集を貼っておく。なるほど3機の衛星をあんな風に積むのね。
Baikonur Cosmodromeには沢山Launchpadがあるらしいのだが今度はLC81/24 というのを使うとのこと (Google Map)。写真では寒そうだが朝の気温が-15度と書いてあるから思ったほど寒くない。緯度は北海道より少し北くらいの様だ。

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

2008/12/20

高度460kmで電離層がどの程度効いているか分らないと書いてしまったが、2周波観測値のGeometry Freeの線形結合をとれば大体のところは分かるのでやってみた。PRN09-GRACE-A。上から搬送波位相, コード, 仰角。DCBがあるので絶対値は分らないが1arcの変動で1mもあるので全く無視できない。電離層モデルとして良く使われる350kmの薄膜球殻モデルでは当然0になる訳で、逆にいえば薄膜球殻モデルではその程度の精度しか期待できないと言える (地上で使う分には色々と相殺されて数10cm位の精度はあるようだが)。

補足: 電離層遅延が1mあっても相対測位ではローバ-基準局の差しか効かないので、積分電子密度が地上の1/10以下だとして、200km基線では地上の20km基線と同じ位と見積もって当たらずとも遠からずだろう。(12/21追記)

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

12/17に書いたNtripによるバイナリデータの文字化けの件、バイナリデータのうち値が0x00のバイトが全部落ちてしまっていることが分かった。受信機から出ているバイナリにはちゃんと入っているので、NtripServer-NtripCaster-NtripClientのどこかで落ちているはずであるが、ServerとClientはソースが公開されていないので追いようがない...。確認用コードを書くくらいなら結局ServerとClientを新たに実装してしまってもたいして工数に違いはない。ということでしかたないので自分で書くことにする。しかし人の書いたコードって何でこんなに使えないのだろう。

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

ちょっと思いついてRTKLIB 2.1.1のMoving-BaseモードでGRACE-A - GRACE-B基線を解いてみた。
2008/10/7 10s間隔24hr。GRACE-A/Bは高度約460kmの編隊飛行衛星。左: GRACE-B基準のGRACE-A位置。大体200km位離れて飛行している様だ。電離層は推定していないが結構Fixするものである (電離層F2層ピークの少し上を飛行するのでRTKLIB2.1.1ではちゃんと推定できない)。右: 衛星Skyplot。こんなskyplot普通見たことない。赤線はスリップ。こう見ると結構多いなあ。

補足: 高度460kmで電離層がどの程度効いているかはよく分からない。200km基線なので軌道誤差の影響も大きいと思われる。公開版RTKLIBでは精密暦対応が入る予定なので対応したら評価してみたい。(18:17追記)
補足: 上記skyplotは衛星位置固定で計算していたのでその内容はおかしい。正しいプロット。GRACEはチョークリング型アンテナを使っているので仰角0度までの衛星追尾は無理。(2009/1/25追記)

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

12/17に書いたNtripによるRTK-GPSの構成が良く分らないと言われたのでブロック図を貼っておく。RTKLOGとRTKPOSTは、RTKLIBに含まれるロガーと後処理基線解析ソフト。ロガーは複数CHのCOM入力を束ねてログファイルに書く機能を持っているので、まずはこれで記録して (時間的順序を維持したまま) 後処理で評価する予定だった (データ化けがあってまだうまくいっていないが)。

なお図中、Rover-Base Station間コネクションはRover→Base Stationの方向で張られる。そのためBase Station PCを直接インターネットに公開するようルータのDMZホスト機能を一時的に有効にした。ちょっとセキュリティが怖いのと、より現実に近い環境を模擬するためLinux PCをNtripCaster用専用サーバとして立ち上げる予定。

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

2008/12/19

A.Cameron, Out in Front: Raise a Red Flag, Dec 1, GPS World

GPS WorldのA.Cameronが11月のIS-GPS/GNSS 2008の印象を書いている。

>> Young GNSS scientists and graduate students from Japan, Korea, Taiwan, Thailand, China, and
>> Myanmar who attended the International Symposium on GPS/GNSS 2008 impressed me with
>> their enthusiasm, energy, creativity, and, well, youth. Satellite navigation has a very bright
>> future in the Far East.

これについては私も同印象であった。しかし、現在JAXAが研究開発中のIMESについて、

>> It has also aroused alarm among several attending scientists over the strong possibility of
>> intereference with the GPS L1 signal, through the installation of hundreds, thousands, or even
>> hundreds of thousands of IMES transmitters in high-rise buildings throughout the urban landscape.

と、GPS信号への電波干渉について何人かの科学者が強い懸念を表明したとしている。高感度GPS技術が進み、一部では屋内でもGPSの信号が受かる様になっている現在、もっともな指摘である様に思える。これについてはJAXAの今後の詳細評価を待ちたい。

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

2008/12/18

一昨日の実験で、サーバ側から走行中のEmobile端末に対し連続的にpingを打ってround trip (往復) 時間を測ったのでその結果を貼っておく。左: 時系列, 右: 頻度分布。短いトンネルを潜っているし、一部エリア外に出ている所もある。遅延が階段状になっているところは多分基地局セルの切り替わり点ではないかと思うが、若干の遅れはあるが概ね問題なくハンドオーバしている様だ。走行中10秒程度の不通は何度か発生しているが、これくらいなら移動体RTK-GPSの性能にはそれほど影響しないだろう。なお実験中、接続が切断されることはなかった (というか今まで使っていて6時間の時間制限以外で自動切断されたことはない)。

なおEmobileのカードは短いUSB延長ケーブルを使ってPCに繋ぎ助手席に置いている。
ホテルの部屋でも (窓際でなくても) 全く問題なく受かるし、PC用無線データ通信端末としても快適に使えている。EMOBILEは通信制限がないと前に書いたが、実は6時間の連続接続で強制切断されるという制限がある。EMOBILEのユーティリティでは自動再接続してくれないので普通は手動再接続が必要だが、これはWindowsのダイヤルアップ接続を使うと自動再接続が可能である。再接続時間も十分短い (普通2-3秒) なので実用上は全く問題ない。

補足: 再接続で端末のIPアドレスは割り当て直されるので、TCPコネクションを張っていた場合は再度張り直す必要がある。従って永続コネクションを前提とするAPでは何らかの自動再接続機能が必要になる。(13:30追記)

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

2008/12/17

昨日、NTRIP-Emobile経由で基準局データを受信しながら、周りを1hr程ドライブしてデータをとってきたのだが、受信データがどうも変。OEM-VのRaw (RANGECMPB) が文字化け(?)している様だ。同時にNMEAも取ってモニタはしていて問題なさそうだったので、ちゃんと記録できていると思ったのだが。NTRIP自身でバイナリが通らないということはないはずなので、どこかの通信設定に問題がある可能性がある。時間がないので解析はちょっと後回し。

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

2008/12/16

GT0.6.4試験は一休止してちょっとRTK-GPS用無線通信の試験。
まずはNtrip ServerとCasterを立ち上げてNovAtel受信機につなぎ、Emobile経由でNtrip Clientで受信する。Ntrip ServerはBKGのWindows Ntrip Server 1.3.1, CasterはStandard Ntrip Broadcaster 0.1.5 on cygwin。ClientはGNSS Internet Radio 1.4.11。ClientからCOMに出力されたストリームを再度COMから取り込むためにcom0comという仮想COMポートドライバ (null modem emulator) を使っている。Ntrip ServerとClientにCOM10以上のポートを認識しないバグがあるので強制的にCOM番号を変更した。また何故かNtrip ServerがUSB経由ではNovAtelデータを取り込みできない問題があるので別途シリアル-USB変換ケーブルで繋いだ。ストリームデータ形式はOEM4/V Raw。そのうちちゃんとRTCM変換も実装したい。とりあえず正常に通信ができるところまで確認した。これからRTK-GPS用クライアントを実装する。

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

2008/12/15

GT-PPPによるGRACE-A/BのPOD結果。キネマティック解。2008/10/1-7, 10s間隔 168h連続セッション。暦はIGS Final+CODE 5s時計。Level 1B軌道比較3DRMS誤差で5.12cmと5.42cm。相変わらずスリップ検出のスレッショルド設定に敏感で、スリップ検出漏れを無くすため何度か解析しなおした。解析時間は2衛星で47' 49"だった。最初20cm以上の誤差がでて不具合かと思ったが潮汐補正をOFFにするのを忘れていただけだった。

GT0.5.6解に比較しRadial方向のバイアスが改善されているが、これはIGS暦の衛星アンテナモデル変更が効いているのではないかと思う。

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

引き続きGT0.6.4の試験。LEO衛星POD。GRACEの最近のデータをPODAACからダウンロード。Level 1Bのバージョンが00から01に上がっていたのでその対応で少し改修。GRACE L1B→RINEXコンバータgps1x2rnxも古いものはPRN32に対応していない様だったのでソースをちょっと直して再生成。初めて気づいたがRINEXのヘッダに見慣れない観測型LAを発見。これはRINEX 2.20でLEO衛星用に追加されたC/AコードでトラッキングしたL1搬送波位相らしい。L1とどれだけ違うのか興味があるが時間がないのでこれは後回し。
GRACE-B観測値で見つけたデフォルトパラメータで検出できないサイクルスリップ。多分ΔN=(-4,-5)ではないかと思う (ΔLG=2.5cm ΔMW=-86cm ΔMP1=87cm ΔMP2=85cm 参照)。こういう奇麗な微小スリップは珍しい。スリップ検出スレッショルドを変更して対応。

RINEXを見てみるとちゃんとLLIが立っている。こういう受信機もあるのでやはりLLIによるスリップ検出は追加した方がよさそうだ。

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

2008/12/14

小司, 地上GPS全球リアルタイム解析同化実験計画, 2008

検索で引っかかった最近の資料も貼っておく。リアルタイムGPS-PWVの評価を色々やっている様だ。

西村他, GPS可降水量のラジオゾンデによる再検証, 天気, 日本気象学会, 2003

ついでなので似たような研究結果を貼っておく。GIPSY-PPP解。Sonde-PWVとの差はMEAN-0.3mm, STD2.3mm, RMS2.3mmとGT-PPP解と殆ど同じ。ただしGT-PPPで偏差の大きい父島が評価に入っていない。父島を除くとGT-PPPはMEAN-0.0mm, STD2.0mm, RMS2.0mmとなる (NMF/VMF1共に同じ)「今後のマッピング関数の開発研究が待たれる」とあるが、GMFやVMF1であまり改善されないのを見るとマッピング関数はあんまり効かないのかもしれない。

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

引き続きGT0.6.4の試験。Sonde近傍GEONET19局、2004年1年分のGT-PPPによるGPS-PWVとSonde-PWVとの比較。マッピング関数は、左: NMF, 右: VMF1 (+Gradient推定+Ocean Loading+IGS_01.PCV)。実行時間は6h 3' (前処理)+ 2h 49' (PPP)。ただし前処理実行時間の半分以上はRINEXのHatanaka-compressionを解くのにかかっている。

GT0.5.6結果と比較して、NMFバグ修正、VMF1でそれぞれ僅かに改善されているが微妙な差である (GMFはVMF1と殆ど差はない)。マッピング関数の差がでないのはちょっと納得いかないところだが、バージョンアップでdegradeしていないことは確認できたのでよしとする。

覚書: 気象庁GPVのうちMSMは2006/3から新しい形式とファイル名に変更。またGPVアーカイブは地球流体電脳倶楽部から京大生存圏研究所のデータベースに移管されている。新しいアドレス。GTダウンローダ定義ファイル形式。

rish='ftp://db-dods.rish.kyoto-u.ac.jp'; % Kyoto Univ RISH
4,'JMA MSM ALL T=0-15' , [rish,'/glob-atmos/jmadata/gpv/original/%Y/%m/%d/Z__C_RJTD_%Y%m%d%ha0000_MSM_GPV_Rjp_L-pall_FH00-15_grib2.bin']
4,'JMA MSM SFC T=0-15' , [rish,'/glob-atmos/jmadata/gpv/original/%Y/%m/%d/Z__C_RJTD_%Y%m%d%ha0000_MSM_GPV_Rjp_Lsurf_FH00-15_grib2.bin']

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

2008/12/12

引き続きGT0.6.4の試験。少しチューニングしたパラメータでのPOD結果。日付をunhealthy衛星がない日に変えた (左: 4/1, 右: 7/1)。全衛星3DRMSの平均で7.47cmと6.99cm。PRN29は昨年10月に運用停止した古い衛星でちょうど食期間なので精度が出にくいところ (4/1はPRN1,3,6,7,13,14,17,19,23,26,29が食)。太陽輻射圧は相変わらずCODEのRPR。でもこれでは頑張っても5cmは切れない。最近のIGS Finalの品質は2〜3cmと言われているからもう少しなんとかしたいところだが、整数バイアスを解くようにしないとたぶん無理だろう。

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

兒玉他, 電子基準点「山形新庄」において冬季に見られる地盤変動, 国土地理院時報 2008
電子基準点山形新庄 (940033) 点の冬季における1-2cmの局所変動が、融雪用地下水くみ上げによる地下帯水帯の弾性収縮に起因するものではないか、というのを検証しましたという研究。井戸観測結果があるが冬場には20m以上地下水位が下がるらしい。同一点のGT0.5.6による2004年の結果。明らかに変動は分かるがGAMITの相対解に比較すると少しノイズが大きい様な気もする。PPPだからこんなものかもしれない。

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

2008/12/11

引き続きGT0.6.4の試験。GPSの精密軌道決定 (POD)。観測データはIGS 60局。IGS Final比較。GPS05 (PRN5) はunhealthyなのでたぶんrepositioning。これを除くと3DRMSで8.75cm。パラメータのチューニングをしていないし局選定もいい加減なのでこんなものだろう。オーバラップ6hrで6+24+6hr 2-passの解析時間は25' 51"だった。

最初1000m強の誤差がでたが、調べたらECI→ECEF変換のUTC-TAIを古い値で計算しているバグであった。最近PODをやっていないのがバレバレである。

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

TSKB 1局なら30分程度で解析できるので条件を変えて1年分流してみた。左: NMF+Gradient推定, 右: GMF+Gradientなし。なお昨日の結果は両方Gradient推定を入れている (仰角マスクは全部10度) 。Gradient推定は明らかに夏場の水平成分の安定化に効いているが、マッピング関数の差はほとんど出ていない。いくつかの研究で日本ではNMFはあまり性能が良くないと言われているからちょっと意外である。また、別の研究で筑波は地下水位変動の影響で夏場に地盤が1-2cm下がるとも言われているが、これも今回の解析では陽に見えていない。この辺になってくるとプログラムの問題なのか本当に動いていないのかを切り分けるのは大変である。最低10年くらいの長期で色々とパラメータを変えて検証しないと駄目だろう。

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

2008/12/10

GT0.6.4の評価を兼ねて、マッピング関数を変えて、IGS 67局1年分のスタティックPPP解析を走らせてみた。TSKB局 (左: GMF, 右: VMF1)。結果は微妙。GMFとVMF1の差はほとんど出ていない。プログラムにまだ問題が残っているのか、それともこんなものなのか。ちなみに3年前に解析した結果 (GT0.5.6+NMF, 2004/1/1-12/31) 。暦も良くなっているはずなので今ならもう少し改善されていい気がする。なお、GT0.5.6のNMFにも先に書いたバグが残っていたはずで、GT0.5.6解の上下季節変動は本当か怪しい。いずれにしてももうすこし検証が必要そうだ。

なお2解析を同時並行に走らせて1d 20h 30' (44.5hr) もかかった (C2Q Q6600, Matlab R2007a 64bit, 300s間隔24hrセッション)。6.5s/局/日。ちょっと遅い。CPU負荷は60%前後だったので3解析並行は可能と思うので、GEONET全局1年分で6.5s*365*1200/3/86400=11日。CPUをC2QからCi7に変えて8スレッドで走らせると半分くらいにならないだろうか。でもディスクI/Oも結構効いているはずなので、もしかするとHDをSSDにする方が有効か。

補足: GT0.5.6の結果はグローバルスケールの補正を入れているのでNMFバグの問題はかなり緩和されているはずである。(12/11追記)

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

2008/12/08

所用で大学に出たのでいろいろなところでEmobileの速度やレイテンシを測ってみる。特急あずさの車内。

下り: 3.22Mbps 上り: 1.21Mbps (新宿駅停車中)
下り: 1.36Mbps 上り: 569kbps (中野駅あたり走行中)
下り: 1.45Mbps 上り: 368kbps (上野原あたり走行中)

これくらい出れば文句ない。あずさ車内 (走行中) からgpspp.sakura.ne.jpへのtracert結果。

>tracert gpspp.sakura.ne.jp
Tracing route to gpspp.sakura.ne.jp [59.106.13.58]
over a maximum of 30 hops:
  1   882 ms   309 ms   340 ms  eM60-254-xxx-x.emobile.ad.jp [60.254.xxx.x]
  2   589 ms   500 ms   399 ms  eM60-254-xxx-xx.emobile.ad.jp [60.254.xxx.xx]
  3   299 ms   349 ms   459 ms  eM60-254-xxx-xx.emobile.ad.jp [60.254.xxx.xx]
  4   314 ms   359 ms   379 ms  eM60-254-xxx-xxx.emobile.ad.jp [60.254.xxx.xxx]
  5   313 ms   389 ms   390 ms  218.231.128.65.ep.eaccess.ne.jp [218.231.128.65]
  6   332 ms   349 ms   439 ms  211.14.193.162
  7   339 ms   378 ms   389 ms  210.173.176.63
  8   353 ms   419 ms   419 ms  tkort3-crt2.bb.sakura.ad.jp [59.106.1.101]
  9   392 ms   599 ms   379 ms  tkgrt2b-ort3-10g.bb.sakura.ad.jp [202.181.110.10]
 10   442 ms   409 ms   399 ms  tkgrt15e-grt2b.bb.sakura.ad.jp [202.181.110.206]
 11   375 ms   410 ms   449 ms  www428.sakura.ne.jp [59.106.13.58]

たまに1秒を超えるが数100ms (往復) が多いようだ (80msくらいになることもある)。トンネル内では通じなくなるがトンネルを抜けるとすぐに通じるようになり接続が切れることもない。列車走行中でもYoutubeやGoogle Earthは問題なく使える。初期接続も2-3秒で早いし移動体無線通信回線として十分すぎるくらい快適。どうも無線データ通信というと古い携帯のアナログモデム9600bpsのダイヤルアップで使っていたイメージが強いので、移動体で使い物になるのかと思っていたが全然問題ない。世の中は進歩しているものである。

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

2008/12/07

GT0.6.4の仮凍結。あとは試験と評価、ドキュメント修正をしてリリース予定。なおGT0.6.4からMatlab 6は動作環境対象外。mexバイナリもmatファイルもv7→v6 の下位互換がないのでこれは仕方ない。

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

昨日書いたGT0.6.3のNMFバグの件。対応パッチの提供を開始した。

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

Amazonの予約注文で届いた新刊。

J.M.Samper et al., GPS and Galileo Dual RF Front-end Receiver Design, Fabrication, and Test, McGraw-Hill, 2009

GPS/Galileo受信機のRFフロントエンドの参考書。RFフロントエンドの仕様、回路設計、測定、および応用。ベースバンド部以降はほとんど記載されていない。完全に受信機フロントエンドに特化した参考書は珍しい。既成フロントエンドICの比較もあり、ソフト受信機用に参考になる。\9,069也。現在のAmazon価格は\12,063で差が大きい。為替差額分下げたのだろうか。

補足: これは「予約製品の価格保証」により予約注文時からの最低価格で買えるという制度のおかげらしい。(12/8追記)

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

2008/12/06

GT0.6.3のNMFには (北半球の) Hydrostatic項の季節変動をプラスマイナス逆に加えるというバグがあります。長期解をGTで解析されている方はご注意ください。本件、早急にパッチを提供しますのでしばらくお待ちください (GTバグ情報No.21)。

GT0.6.4に追加するVMF1の試験を行っていて、上記GT0.6.3の致命的バグを見つけた。NMF (修正後), GMF, VMF1の比較。2006〜2007年2年分。仰角5度。筑波。左: Hydrostatic, 右: Wet。

補足: グローバルPPP解のスケールパラメータの季節変動は上記バグが原因だった可能性が高い。GPS-PWVの精度も上記バグを修正することで改善されるかもしれない。バグ修正版で再解析したいところだがIGSはともかくGEONET全局1年分の再解析はかなり気合いが必要である。(17:00追記)
補足: 間違っていたのは北半球のみ。南半球は逆相に変動を入れるので結果的に合っていた。結構気づきにくい (といっても単体試験で時系列を書いてみれば一目瞭然だが) バグなので座標解に上下の季節変動が見られる解析ソフトはちゃんとチェックしてみた方が良いかもしれない。(12/7追記)

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

2008/12/05

12/3に書いたMatlab R2007aのバグがやはり使いづらいのでR2007b (7.5) をインストールした。ついでなので恒例のベンチ。以前とったWindows XP 32bitの結果と比較すると2-D, 3-Dがひどく遅い。これはVGAのドライバが64bitに最適化されていないせいか。

>>bench,a=rand(2000);b=rand(2000);tic;c=a*b;toc,tic;c=inv(a);toc

行列演算は概ね満足なのだが12/3に書いたバグは修正されていない。対応は-nojvmで起動するのをやめるしかなさそうだなあ。

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

2008/12/04

GT0.6.4による、2007/1/1-3/31 3か月連続セッションでのIGS ALGO点のキネマティックPPP結果。300s間隔。暦はIGS Final。対流圏はGPT+GMF+Gradient推定。アンテナPCVはIGS05.atxでAz依存項を入れている。相対論は今版からデフォルトではShapiro Delayを入れないものとした。IGS05比較で上下にすこしオフセットが出ているが概ね安定して推定できている。Unhealthy衛星の取扱いを改善したのがキネマティック解の品質に効いている様だ。なお解析実行時間は18' 52"であった。(C2Q 2.4GHz, Matlab R2007a, 64bit)

補足: Phase windup補正=offで計算していた様なので、補正を入れた結果に差し替え。上下オフセットが消えてほぼ完璧である。(12/05追記)

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

2008/12/03

DLR/GSOC GNSS Technology and Navigation
独DLR (Deutschen Zentrums fur Luft und Raumfahrt, German Aerospace Center) の宇宙用GNSS関連研究のページ。宇宙用GNSS受信機、編隊衛星 (Formation Flying)、GNSSによる精密軌道決定 (POD) が主な研究テーマの様だ。Receiver Testing and Environmental Qualificationの頁にある論文は、受信機の評価手法という面でも色々と参考になる。ざっとしか見ていないが後で調べるために貼っておく。

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

覚書: -nojvm付きで起動したMatlab R2007a (64bit) では、uicontrolのeditにキー入力した文字列がエンターキーを押さないと有効にならず、入力内容をgetで取得できない。6.5.1、R2006b、jvm上ではこんな問題はなかったので、これはR2007a (64bit) のバグだと思われる。色々回避策を試したが、ダメなのでこれはあきらめる。しかしこんなくだらない問題で3hrは時間をとられている。

Matlab Bug Reports
Matlabも頻繁にバージョンアップしている割に細かいバグが多い。別に機能追加は全然要らないのだが、バグが多いので高価なサポート契約を切れない。バージョンアップに伴う挙動変更も多いのでバージョンアップ毎に動作確認のための工数も必要になる。やっぱりMatlabみたいなプロプライエタリな処理系上にAPを作ってしまうと、最終的にお金と時間をMathworksに貢ぐことになってしまう。なんか江戸時代の小作農の気分である。Matlabの便利さは諸刃の剣である、ということをMatlabのAPを書く人は良く認識する必要があるだろう。

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

2008/12/01

師走。

覚書: 64bit MEX生成用mexopts.bat。環境はWindows Vista 64bit + MS VS 2008 standard + Intel Visual Fortran 10.1。

GT0.6.4 64bitがちゃんと動くようになったので実行時間を測ってみた。IGS 10局の300s間隔キネマティックPPP 24H×7日分。(C2Q Q6600 2.4GHz, Windows Vista 64bit)

(1) GT0.6.3 (Matlab R2006b 32bit): 5' 18"
(2) GT0.6.4b (Matlab R2006b 32bit): 5' 14"
(3) GT0.6.4b (Matlab R2007a 64bit): 5' 11"

ということでほとんど変わらない。あまり面白くないので安定したらプロファイルをとって最適化してみよう。

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

〜2008/11/30