2007/03/01〜

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

2007/02/28

2月も終わり。何となく身辺が慌ただしい気分がする。

E,-J.Euler, The Use of Standardized Network RTK Messages in Rover Applications for Surveying, ION NTM 2003
Master-Auxiliary Conceptに基づくネットワークRTKの性能評価。この方式では補正値は基線 (Master-各Auxiliary RS間) 毎に生成されるのでユーザ側で補間を行う必要がある。この補正値補間方法や補正値誤差につき評価している。

Kinematic
Kinematicと呼ぶフリー(GPL)のDGPS測位ソフトパッケージ。コードDGPSだけでなくphase DGPSもサポートしている。まだARはサポートしていないようだが、$200以下のOEM受信機ボードで6-8km基線2cm程度の精度を長期目標 (long term goal) にしているらしい。ダウンロードしてC++のソースを少し読んでみたがまだ開発途中といった感じ。精密暦(SP3)をサポートしているがこれは何を狙っているのかよく分からない。ただ受信機I/Fの部分等は参考になる点が多い。

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

2007/02/27

RTCM 10403.1, Differential GNSS (Global Navigation Satellite Systems) Services - Version 3, The Radio Techinical Commission for Maritime Service
RTCM3は昨年10月に改訂されてRTCM3.1となっている。RTCM3.0からの大きな変更はMaster-Auxiliary Conceptに基づくネットワークRTK補正メッセージの追加。規格になっているということは誰でも使えるということなので分散型ネットワークRTKプロトタイプにはこれを使う予定。

E.-J.Euler, Implovement of Positioning Performance Using Standardized Network RTK Messages, ION NTM 2004
Master-Auxiliary Conceptに基づくネットワークRTKの性能評価。基準局間隔は30-100km。これ位の基線長では従来型ネットワークRTKと性能差が出るとも思えない。補正量の評価があるが30km基線では補正量があまり大きくなく補正情報ありなしでそれほど差がでないとある。

ところで1周波受信機でのネットワークRTK性能評価と言うのはほとんど見ない。1周波受信機をターゲットにした安価なネットワークRTKシステム構築が可能なのか、技術的に目処があるのか見極めたい、というのが実は分散型ネットワークRTKプロトタイプの第一の目的であったりする。

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

2007/02/26

2/23にFKPはVRSに対しデータ送信量が増えると書いたが、FKPではVRS方式で補正データを送ることもできる (サーバ側でFKP補正量と基準局観測値からVRS観測値を生成してローバに送る) のでその場合はVRS方式との差は出ない。ただ日本でのFKPサービス (三菱PAS) がどのような運用方法を取っているかはあまり情報が公開されていないので良く分からない。

H.J.Euler, Study of a Simplified Approach in Utilizing Information from Permanent Reference Station Arrays, ION GPS 2001
2/22に書いた新しいネットワークRTKシステムの件、アイデアとしては単純なのでやはり既に発表されてしまっていた様だ。残念。簡単に書けば基準局観測値と(副)基準局-基準局基線補正量をローバに送りその補間でユーザ補正量を生成する方法。従来型ネットワークRTKと比較した最大のメリットは補正値計算や配布を完全に各基準局独自に分散実行出来ること。すなわちデータセンタがいらない。インターネットを使うとこのメリットが最大限に利用できる。(厳密に書けば従来型でも分散処理は出来るのだがそれに適した実装になっていない)

Leica GPS Spider Software, Leica geosystems
以上概念 (Master-Auxiliary Corrctions : MAXと呼んでいる) を実装したネットワークRTKソフト。SpiderNET。技術詳細はDownload-White paperから得られる。プロトコルはRTCM3とNtripを使う。NtripはTCP/HTTPベースなので現行の日本の携帯 (パケット) 網では最適とは言えない。ここはUDPベースにしたいところ。
もともと補正量生成や配布はたいして重たい処理ではないので非力なCPUでも1000ユーザ程度までは容易にサポート可能なネットワークRTK基準局サーバが構築できるだろう。新しいプロトコルを使うので既存GPS受信機を使う場合ユーザ側に通信アダプタが必要になるがまあこれも大したことはない。安価な基準局サーバ網が構築出来るようになると基準局メッシュを細かく取ることが出来るのでうまくすれば1周波受信機で実用的なFIX率が得られるかもしれない。ということで既にRTKLIBを使って基準局サーバとクライアントソフト実装を始めているのだった。移動体の基準局切り替えやディレクトリサーバ等考えなければいけない点は色々あるがまあ大体目処はついている。これ誰か買いません。

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

2007/02/24

昨日書いたネットワークRTKの通信量の件、携帯のダイヤルアップを使う限りは削減してもあまり意味無いので、現行のままになっているということなのかもしれない。ただ買い物を使っている限りその国のインフラや通信サービスに最適化したシステム構築は難しいので独自の方式開発も重要な気はするのだが (日本の測位技術では多くの研究機関やメーカで最新技術のフォローアップを諦めてしまって買い物ですまそうとしている現状は、私には嘆かわしいと思える。)
考えついたネットワークRTKシステムもあと3年早ければビジネスになったかもしれないがもう既に遅いかなという気もしてきた (まあ研究テーマとしては面白いので少しやってみるつもりではいる)

ネットワークRTKで使う通信量は大したことはないので、結局現行システムの問題は携帯通信料金がべらぼうに高すぎる (特にパケット) という所に行き着く。これは将来的には多分劇的に改善されるだろうから、今頑張って通信量削減の工夫をしても仕方がないという割り切り方もできるかもしれない。

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

2007/02/23

昨日書いたネットワークRTKシステムの件、結構画期的ではないかと思う。問題は既に誰かが同じアイデアを発表していないかどうか。少しION論文、特許公報やネット検索した範囲ではまだ誰も出していないようだが。

現在日本で提供されているネットワーク(型)RTKサービスを調べてみた (順不同)。

全てキネマティック使い放題のプラン。従量制や年間契約等では料金が異なる。詳細は各社Webサイト参照のこと。また受信機/アンテナ、通信機器費用は含んでいない。三菱の場合、FKP対応受信機で無い場合にはPAS端末も必要になる。以上以外に独自のネットワークRTKとして日本GPSソリューションズが自社GPS受信機NetSurv用にサーバ側RTK解析サービスを提供している。これはVRS補正情報を使うこともできる様だ。

現行のネットワークRTKサービス利用にはサービス提供料金以外に携帯等の通信料金が必要で、一般にこれがネットワークRTKの利用コストを引き上げている。現在のRTKではほぼ例外なくOTF ARを使うので測位していない際は回線を切っても問題ないのだが、移動体測位の場合は連続的な回線接続が必要になる。携帯の料金プランは複雑怪奇で全然分からないのだが、例えばドコモFOMAパケットパックなら定額なしで\0.2/パケット (128B/パケット) である。VRSの場合、NMEAで自位置をデータセンタに送信するのに1パケット。RTCM 2.3 Msg18/19が2周波10衛星分で(2+3)word×10×4×4Bt/word=800Bで8パケット。1Hzで送信したとして\0.2×(1+8)×60=\108/分。(補足: TCPを使うとこれ以外にプロトコル制御用パケットも必要) これは高い。むしろダイアルアップ (例えばドコモ\15〜40/分)の方がずっと安いが、今度はモデムなので通信確立に時間がかかり運用性が悪い。パケット定額プランもある (ドコモ/AU) もあるが良く調べるとi-modeやez-web以外は定額は適用されない様だ。FKPの場合、片方向リンクが使えるメリットがあるがその代わりにエリア内基準局データや補正量を全部送らなければならないという問題が有るようで、携帯経由の通信量は実はVRSに比較し大幅に増える。(補足: 三菱以外は携帯パケットに対応していないようだ。ジェノバの専用通信装置はKDDIパケット網を使って通信コストを下げられるがこれも時間課金なのは少し辛い。2/24)
以上より現行サービスでは移動体にネットワークRTKを適用するのは通信コスト面で実用的でない。データ通信量を減らす方策は色々考えられる。
(1) データ送信頻度を減らす(例えば1Hz→0.1Hz)。
(2) 生観測値ではなく補正量を送る (RTCM 2.3 msg 20/21)
(3) RTCM 3.0を使う (データ量削減のため色々な工夫をしている)
(4) 補正量を高速変動量(時計)、中速(電離層)、低速(軌道+対流圏)に分解しそれぞれの送信頻度を変える。
(5) (基準局依存でない) 共通補正量は放送サービスで別途送る。
これらの通信の最適化のためには各補正量がどの様に時間/空間変動するかをきちんと押さえておく必要がある。今度の合同大会発表はこの辺を狙っている。(もちろん通信コスト問題はインフラが整備され無線回線コストが大幅に安くなれば解決する問題ではあるが)

ネットワークRTKの技術的な課題は実は測位面ではなくシステム構築/運用面にある。(普及の鍵はあと二周波受信機価格の問題であるがこれは受信機メーカに頑張って貰うしかない)

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

2007/02/22

面白いネットワークRTKシステムを思いついてしまった。これ多分売れると思う。よしプロトタイプを実装するぞ。内容は秘密。

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

2007/02/21

RTCM Recommnded Standards for Differential GNSS Service version2.3, 2001
ネットワークRTKに興味が出てRTCM SC104の関連部分を調べる。Msg 20/21のRTK補正メッセージに関連して、Appendix D GNSS Carrier Phase Corrections for Real-Time Kinematic NavigationにRTK補正メッセージ方式の技術解説、生観測値送信方式との比較がある。D.5 Advantages of Carrier Phase Correctionsに合同大会向けテーマに関連する重要な記述があるので引用してみる。

>> One advantage is that the time sensitivity of the data is reduced. Since corrections change much more slowly than the raw
>> measurements, the error in the correction caused by its delay is less serious. This means that time synchronization at the
>> reference site and user site is less critical. An exact match is not requared between the measurement time of the data used to
>> generate the corrections at the reference site and the measurement time of the data to which the corrections are applied. ...

RTK補正メッセージ方式では生観測値送信方式に比較し時刻の同期がルーズで良いとある。ただこれは嘘である。実は生観測値の二重位相差を取る場合でも厳密な時刻同期など必要ない (ローバ-基準局で少しずれた時刻の観測値間で差を取っても問題ない)。もし厳密な時刻同期が必要ならばそれは実装が間違っている。どうもこれを読むと世の中の多くのRTKの実装が間違っているのではないかという気がしてきた。

OEM4 Volume 1 Installation and Operation, NovAtel
基準局とローバ観測値間の時間差がRTK精度にどう影響を与えるか評価した結果を探しているのだがなかなか無い。NovAtel OEM4マニュアルに少し値があったので引用しておく。(6.5.1.2, RT-20は2周波RTKモード1周波RTKモード、2周波RTKモードRT-2でも同等性能、訂正 3/14)

この表に従うと30s遅れで測位精度1×2+2×5+5×23=127cm(CEP)の悪化となる。SA ONの時代じゃあるまいしこれは明らかに悪すぎる様に思う (仕様だから最悪値を書いているのかも知れないが)。

U.Vollath et al., Multi-Base RTK Positioning Using Virtual Reference Stations, ION GPS 2000
色々な論文から引用されているので多分VRSのオリジナル論文。今はTrimble社のVRS(TM)だがこの時はまだTerrasat社。VRSのメリットは既存受信機内蔵RTKファームのみで演算処理できること。双方向通信リンクが必要なところがデメリット。ただ、精度やTTFF (Time to First Fix)等の性能は各方式あんまり差はない様だ (まあ基本的な考え方は皆同じなので)。

東京海洋大学 情報通信工学研究室 (安田研究室) 論文集
お世話になっている海洋大安田研。今年の卒業/修士/博士論文発表資料がupされている。日本では数少ない本格的なGPS研究成果集だと思う。

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

2007/02/20

G.Wubbena et al., RTK Networks based on Geo++(R) GNSMART - Concepts, Implementation, Results, International Technical Meeting, ION GPS-01, 2001
合同大会に向け少し既存のネットワークRTKについて調べる。独Geo++社のネットワーク型RTK (通称FKP)。FKP方式はコードDGPS PRC方式の搬送波位相版といった色彩が強い。補正情報をPRC+空間依存補正項に分離し空間依存項は基準局網データからstate space estimationと呼ぶカルマンフィルタ+状態遷移モデルで推定。補正情報はPRC(?)+空間依存補正項2次元傾斜係数としてローバに送信。ネットワークRTKの場合、ARのためにバイアス整数性を崩すような補正はダメなのだがうまく考えられている。良く分からないのは各補正情報の送信頻度。(phase) PRCには衛星時計誤差変動 (+衛星軌道誤差変動)が載るので精密測位精度では時定数は長くない (補足: 基準局時計誤差変動も載るがこれはローバ側で最終的に2重差をとるので消える)。今度の合同大会発表ではその間隔を30sにしてもそんなに精度劣化は起こさない、ということを最終的に言いたいのだがFKPではどうしているのだろう (まあ運用パラメータなのかもしれないが)。
ところでDGPSでもよく使われるPRC方式ではPRC生成時と使った暦が食い違うと誤差が増大するので補正情報にIODを付加する。それより生観測値をそのままローバに送った方が処理が簡単になると思う (大した違いはないが) (補足: PRCでは基準局座標を送る必要がない、PCV等の基準局依存精密補正を導入できるというメリットはある。再補足: PRC方式では基準局のコード測定値を必ずしも送る必要がないという大きなメリットがあった。データ容量削減面でこれは大きい。2/21 10:53)

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

2007/02/19

RTKLIBへの電離層遅延推定の組み込み続き。2005/12月の備考録を読み返してみると同じ様なことをしていて簡単にできているのだが今回はちゃんと動かない。やっぱりmatlabで一度プロトタイプを作り直した方がよいか。この辺はさっと通過できないと新しいことまでたどり着かないのだが。

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

2007/02/18

H-Star technology explained, Trimble
Trimble社の後処理GPS解析技術H-Star。2分の計測でProXH内蔵アンテナ(L1)で30cm、Zephyrアンテナ(L1+L2)で20cm以下の精度が得られる。基準局は200km以内3点の二周波一般局(米国ならCORS, 日本なら電子基準点)データをダウンロードして使う。他技術比較でRTK/VRSは運用上のオーバヘッド、一般的なGPS受信機は長いロック時間、OmniStar HP (GDGPS) は長い収束時間の問題があるとしている。H-Star Base Station Mapに使える基準局地図があるが日本と米国の空間密度の高さが際だっている。競合する後処理VRSとの比較で二周波20cmはあまり高精度とは言えない。もしかすると間隔の狭い電子基準点を使えばもっと精度が出るのかも知れない (TrimbleはVRSも売っているのであえて競合を避けているという可能性も無いことはない)。またタダで使える基準局データで解析できるというメリットもある。

Continuously Operating Reference Stations CORS, National Geodetic Survey
米国NGSが運用するGPS基準局網CORS。1, 5, 10, 15, 30秒サンプリング局が混在する。30日以内は全データ、30日より古いものは30秒に間引きされたデータが一般入手可能なようだ。地域により密度に差があるが50km〜500km位の間隔。特にオハイオ 、ミシガン州近辺の1Hz観測点密度の高さが特徴的。これは何の目的で整備されたのだろう。

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

2007/02/17

合同大会に向けてRTKLIBに電離層遅延推定の組み込み。うーん今でも充分に複雑なのにもっと複雑になっていいく。複雑化に対して抵抗感が強いのは正常な感覚だと思っているが、これが段々と麻痺していくとプログラムが手に負えなくなってくる。自制せねば。

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

2007/02/16

Borland Turbo Explorer
Borland Delphi/C++ BuliderがいつのまにかフリーになってTurbo Explorerと名前が変わっていた。少し古いプログラマなら多分Turboの名前は懐かしいだろう。フリーとはいっても商用プログラム開発もOK。C++ Bulider 6で作ったプロジェクトもほぼそのまま移行できた。Windows用GUI開発環境としてBorlandのVCL (Visual Component Library) は、MicrosoftのMFCやATLに比べてずっと使いやすく修得も容易。Microsoftが.NETへの移行を強めているので新APIのサポートはされなくなる可能性が高いが簡単に普通のWindows APを作るのには充分。統合開発環境の出来にはあまり興味がないが機能もかなり追加されている様だ。これのLinux版が出るとGUI APの可搬性確保が随分楽になるのだが。(実はBorlandは昔KylixというDelphi/C++ BuilderのLinux版を出しているのだが安定性が低く実用的ではなかった。現在はサポートもうち切られている様)

覚え書き
intel MKLライブラリのオブジェクト形式はCOFFでありBorlandがサポートするOMFと互換性がないためそのままではリンクできない。C++ Builder/Turbo C++でのMKLリンク方法。(impdef及びimplibを使って.dllファイルからからOMFのインポートライブラリを作る。参考)
(1) cd ??\mkl??\ia32
(2) mkdir libomf
(3) impdef -a libomf\mkl_p4.def bin\mkl_p4.dll
(4) impdef -a libomf\mkl_lapack64.def bin\mkl_lapack64.def
(5) cd libomf
(6) implib mkl_p4.lib mkl_p4.def
(7) implib mkl_lapack64.lib mkl_lapack64.def
(8) (6) (7)のlibをプロジェクトに追加しビルド。
54000エポックの後処理キネマティック解析、MKL1分13秒、互換ルーチン4分58秒。やはり圧倒的な性能差がある。

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

2007/02/15

古籏, Google Maps API 逆引きクイックリファレンス, 毎日コミュニケーションズ, 2007
移動体RTK結果をGoogle Mapで表示出来る様にしたら面白いかなと思って買ってみた。Google MapにはJava Scriptの高機能APIがありユーザプログラムによりインタラクティブな地図頁を構築できる。日本の都市部はゼンリンのデータを使っているようでZ8と殆ど変わらない解像度の地図が表示できる。2/9の地図と同一地点。座標系はTokyoではなくWGS84の様。航空写真との切り替えが楽なのと地図データをインストールする必要がないのがメリット。色々と遊べる様だ。

Windows Vistaをインストール。でも最初の起動途中で停止してしまって立ち上がらない。XPと別パーティションに入れたのでデュアルブート出来てあんまり困らないのだが何だなあ。メイリオフォントだけXPのシステムにコピーしてこれでVistaにする必要性はほぼ無くなってしまった。(補足: 大体起動途中で止まるのはHW初期化に失敗しているので使ってないVGAカードを外して起動するようにはなった。でもやっぱり使う必然性は全然ない。14:07)

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

2007/02/14

高須, 時間・空間補間した基準局網観測値によるキネマティックGPS性能の評価, 2007年日本地球惑星科学連合講演会予稿

春の合同大会予稿。相変わらずの見切り発車でネタはこれから。従来空間補間の評価はあっても時間補間(補外)についての評価はあまりされていない。ネットワークRTKまで行かなくても入手容易な30s電子基準点観測値を基準点データとして使って1Hz後処理キネマティックGPSの精度、FIX率が出るだけで実用上は価値がある。またRTKにおいて通信回線切断時にも測位を継続できるというメリットもある。キーになるのは衛星時計安定度。原理的には精度が出るはずであるがどうなるか。

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

2007/02/13

春の合同大会申込み締め切り間近。さてどうしよう。

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

2007/02/11

3連休。しかしホントに今年は異様に暖かい。2月とは信じられない。一応休養。でも色々気になることがあってプログラムをいじってしまう。

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

2007/02/09

世界測地系座標変換(TKY2JGD), 国土地理院
ゼンリン地図(Z8)がTokyoにしか対応して無いので結局0から測地系変換ルーチンを書く。TKY2JGD.parだけ国土地理院から拝借して、jgd2tokyo(), tokyo2jgd() 関数をRTKLIB ver1.1に追加。テーブル引きはqsort()して2分検索というつまらない実装だがまあ速度いらないからこれでいいだろう。JGD2000とWGS84の変換も多分いらないだろう。これで概ね道路を走ってくれるようになった。でもこの手の細々したルーチンでライブラリが膨らんでいくのは本当はあんまりうれしくない。

ゼンリン地図(Z8)に表示したRTK結果 (実際は後処理結果のプレイバック。右下はコンパクト表示のRTKプログラム。速度は推定していないので出力していない)。概ね車線の真ん中を通るがたまに外れる。これは測位解の問題か地図精度の問題か、あるいは本当に車線をはずれているのか、もっと実データで評価してみないといけない。COMポート2ポートをクロスケーブルで繋いでいるが、ホントは仮想COMドライバで内部でクロス接続したい。でもこれは結構面倒なよう。

Copyright(C) 2005 ZENRIN CO.，LTD.

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

2007/02/08

GUIの可搬性は最初から諦めているが、シリアル入出力の様な基本的な部分で機種依存コードを書かなければならないのは辛い。OS依存部がそんなに多いわけではないからうまく仮想化すれば有る程度の可搬性は確保できるのではあるが。

RTKプログラムからcomポート経由でゼンリンZ(ver.8)にNMEAを入れてあげるがデータが全然認識されない Tera Termで見るとちゃんとセンテンスは出ている様に見えるのだが。NMEAは方言が多いしNMEA対応と言ってもソフトによって色々な制限があるよう。試験用にちゃんと認識されるGPSデバイスが一つ必要なのでGarminの安いのを買うか。(補足: bitrateが合ってなかったのが原因。NMEAは標準4800bpsなので出力をそれに合わせなければいけない。でもZ8は測地系TokyoしかサポートしていないのでWGS84出力では数100mずれてしまう。Tokyoへの高精度変換は少し面倒。10:43)
あと受信機から出力されるRTCMにしても必ずしも規格そのままでは無いよう。NovAtel OEM4マニュアルを読むとやたら効率の悪いデコードをしている (もともとの規格は1word 30bitのバイナリ)。多分これも受信機毎にコードを書かなければならない様。実際にRTKするのは面倒だなあ、とめげ中。RINEX入力の後処理に限定すれば簡単なのだが。

MapInfo豆知識 よくわかる新測地系講座 - 日本測地系 2000 (JGD2000), 株式会社アルプス社
旧測地系と新測地系との変換手順につき良くまとまった解説。厳密にいえばWGS84、JGD2000、ITRF(2005)は全部違っていてそれらの間でmm精度の変換は困難なのだが、Tokyoとの差に比べると微々たるもの。しかし国土地理院も変換プログラムを提供するのはいいのだがもう少し汎用的に使えるライブラリにしてほしい。最初から書くのは面倒だしどうするか。そうか日本近傍メッシュ点の全座標を入れてTKY2JGDで計算した結果をテーブルにしてbi-linearで補間すればいい。と思ったらTKY2JGDではJGD→Tokyoの一括変換機能が無い様。仕方ないので順方向変換テーブルを作って逆引きするか。(やりたいのはWGS84座標をTokyo座標の地図に表示したいだけなのだが)

笠原, Windows Vistaインストールレポート(前編), PC Watch
Microsoftが開発者だけじゃなく利用者のことも全然考えていないことがよく分かる商品体系。買ってあるVistaをインストールする気力も萎える。メイリオフォントだけは入れたいのだが。

坂井, GPSのための実用プログラミング, 東京電機大学出版局, 2007
朝Amazonで頼んだら夜届いた。ENRI坂井さんのGPS測位計算プログラミング。ソースプログラムリストを基に親切丁寧に解説している。単独測位、DGPSまで網羅する実用的な参考書。しかし坂井さんは色々な学会では沢山発表しているし本を書く時間などどうやって作っているのだろう。

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

2007/02/07

windowsのfopen()で開いたCOMポートからは出力はできても入力ができないようだ。こんな制限どこのマニュアルにも見つからないのだが、cygwinでも fopen("/dev/com1","r") で開くのはできても入力が入らない。従ってcomポートから入力するためにはwin32 APIを使わなければならない様だ。2/5の例を見て分かるようにwin32では呪文のようなAPI仕様を一つ一つ丹念に調べないと一文字入出力もできない。エラーが出ても内容を調べるためだけにエラーコードを文字列に変換する呪文の様なAPIがまた必要になる。全く酷い設計。

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

2007/02/06

RTKプログラムは一寸置いて、ちょっとしたアルバイト作業。でもこれはこれで勉強になる。

随分前に注文したのだが、やっと昨年9月のION GNSS 2006論文集CDROMが届く。パラパラと眺めるが量が多すぎでどれが重要なのか分からないし、読む気力もわかない。PPP関連が少ないのは寂しい限り。世界中にGPS研究者はこんなにもいるんだと再認識させられる。

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

2007/02/05

RTKプログラム引き続き。概ねUI部分は完成。通信回りの実装。win32 apiを駆使したcomポート送信コード例。昔書いたコードだが今や殆ど理解できない。でも複数ポート入出力でブロッキングやwasteループを避けようとすると複雑にならざるを得ない。もともと通信はプログラミングの中でも結構高度な部類に入る。

unsigned int __stdcall CCommPort::WriteThread(void *arg)
{
  CCommPort* p=(CCommPort *)arg;
  OVERLAPPED ov={0,0,0,0,NULL};
  HANDLE events[]={p->EventWrite,p->EventStop};
  DWORD size,sz;
  char buff[CP_WRSIZE_MAX];
  
  if ((ov.hEvent=CreateEvent(NULL,TRUE,FALSE,NULL))==NULL) return 0;
  for (;;) {
    events[0]=p->EventWrite;
    if (::WaitForMultipleObjects(2,events,FALSE,INFINITE)!=WAIT_OBJECT_0) break;
    ::ResetEvent(p->EventWrite);
    if ((size=p->TxBuff->Read(buff,sizeof(buff)))<=0) continue;
    sz=0;
    events[0]=ov.hEvent;
    if (!::WriteFile(p->Port,buff,size,&sz,&ov)) {
      if (::GetLastError()!=ERROR_IO_PENDING ||
        ::WaitForMultipleObjects(2,events,FALSE,INFINITE)!=WAIT_OBJECT_0||
        !::GetOverlappedResult(p->Port,&ov,&sz,FALSE)) break;
    }
  }
  CloseHandle(ov.hEvent);
  return 1;
}

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

2007/02/04

試験用のUSB-シリアル変換ケーブル2本が届く。これはシミュレータ用。でもPCをよく調べるとCOMポートが1個しかない。最近は1個が普通? クロスケーブルも1本しかないのでもう一本ずつ必要。あと携帯電話モデムが2つ必要(必ずしも基準局側は携帯でなくてもいい)なのだが携帯もパケット契約に変えた方がいいのかな。パケット契約だとモデム、携帯とも同一機種にしないと通信できないのだろうか。ここ暫くこのあたりを全然いじっていないので最近のことが殆ど分かっていない。

移動体用高精度位置標定システムに関する研究報告書, 財団法人日本自動車研究所
自動車にRTK-GPS(VRS)を乗せて市街地走行実験した結果が含まれている。でも結局既存のGPS受信機や補正システムをブラックボックスで評価しているだけ。日本では受信機や測位/補正方式を自前で開発・改良して評価している研究は数少ない。でもそこまで踏み込まないと研究開発とは言い難いと思うのだが。

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

2007/02/03

RTKプログラム設定画面案。電離層/対流圏推定は拡張用オプションで本バージョンでは未実装。入力でRINEXを指定すると後処理でも使える設計。

家族全員、私を除いてインフルエンザでダウン。多分もう少しすると私にもうつるかも。

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

2007/02/02

RTKプログラム引き続き。UIに凝りだして止まらなくなってきた。いい加減にしなければ。

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

2007/02/01

RTKプログラム引き続き。windows上でcomポートを使うのは恐ろしく面倒。cygwinなら/dev/com1を開いて低レベルI/Oとselect()を使えばいい。windowsでは複雑なwin32 apiを使って非同期I/Oのためスレッド生成も必要。随分前に書いたVCL用comポートクラスを引っ張り出してきたが暗号のようで殆ど理解不能。RTKLIBの実証のためちょちょっと作りたいだけなのだが大がかりすぎる。何か良い手はないだろうか。(補足: Windowsでもファイル名"COM1"等で開けば標準入出力関数を使えるよう。後、winsockにはselect()が有るようだがCOMポートでも使えるかは調べる必要がある。18:13) 作ったRTKプログラムのGUI。シンプルで見易いレイアウトだと思う。英文字で °(度)をどう出せばいいかがまだよく分からない。(補足: °は英文字フォントを使ってコード0xB0で出力できる。2/2)

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

〜2007/01/31