日記・備考録
Diary/Memorandum

2005 | 2006 | 2007 | 2008 | 2009/ 1 2 3 4 5 6 7 8 9 10 11 12 | 2010
May June 2009
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
July | Home

2009/07/01〜

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

2009/06/30

http://www.silvercircuits.com/
格安プリント基板屋としてマレーシアのSlivercircuitsという所を教えて頂いた。情報感謝。確かにOlimex並に安い。ただ品質はOlimexと変わらないとのこと。

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

異機種間基線RTK-GPS/GLONASS実験のため、先週、研究室のJavadとNovAtelで48H程データを取ってきたのだが、やはりNovAtelはGLONASS R10とR14が正常に受からない様だ (F/W ver.3.620) (左: NovAtel, 右: Javad)。これなんとかならないのだろうか。

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

2009/06/29

覚書: NovAtel OEMVメッセージGLOEPHEMERISのe timeフィールドの値は1msずれている。これはF/Wのバグだと思われる (F/W ver.3.620)。これはNovAtelのデコード中で1s単位に四捨五入することにして対応。

3 decode_gloephemerisb: len=172
1 decode_gloephemerisb: eweek=1538
1 decode_gloephemerisb: etime=87314999

NovAtel Convert4 (ver.3.5.0) のバグ。変換後のRINEX GLONASS NAVデータのepoch of ephemeridesの値が1sずれている。(これは上のバグに起因しているのかも)

17 09 06 29 05 14 59.0 -.267803668976D-03  .000000000000D+00  .195000000000D+05
    -.230200742188D+05 -.882966041565D+00 -.372529029846D-08  .000000000000D+00
     .865425292969D+04  .388182640076D+00 -.931322574615D-09  .400000000000D+01
    -.692193457031D+04  .340882015228D+01  .000000000000D+00  .000000000000D+00
15 09 06 29 05 14 59.0  .998461619020D-04  .000000000000D+00  .195000000000D+05
     .236529199219D+04 -.181060791016D+01  .931322574615D-09  .000000000000D+00
     .157089545898D+05 -.205126190186D+01  .000000000000D+00  .000000000000D+00
     .199161362305D+05  .184294986725D+01 -.931322574615D-09  .000000000000D+00

NovAtel GLONASS関係バグだらけ。なんとかしてほしい。
全部確認した訳ではないが、Leica GRX1200GGPROの出力するRTCM3 type1020のtkの値も3Hずれている様だ (下記はIGS CAS10局)。まともなGLONASSデータを出力する受信機はないのだろうか。(とりあえずtkの値がおかしくても実害はそんなにないが)

1 decode_type1020: tk =12:30:00 LT
1 decode_type1020: tk =34200s UTC
1 decode_type1020: tb =24300s UTC
1 decode_type1020: tk =2009/06/29 09:30:15.0 GPST
1 decode_type1020: tb =2009/06/29 06:45:15.0 GPST

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

2009/06/28

Beagle Boardの記事を読みたくて日経Linuxなどという雑誌を始めて買った。その中の記事で知ったSmartQ5という中国製MID (Mobile Internet Device)。スペックは
・Samsung S3C 6410 (ARM11) 667MHz, 128MB DRAM, 1GB Flash
・4.3" 800x480液晶, WiFi, Bluetooth, USB (Host) x 1, SDスロット
・2000mhAバッテリ, 120x74x14mm, 160g
Ubuntuが動いて値段が899元 (\12,500) (!) とのこと。むちゃくちゃ安い。ただ現状では中国から個人輸入のみなので入手が大変らしい。
なかなか興味をそそられるデバイスである。そのうちRTKNAVIの移植に挑戦するかもしれない。

調べてみると低価格のARM+Linuxベースのハンドヘルド型インターネットデバイスというのは他にもいくつか有るようで、例えばTouch Bookなどは面白い。最近のLinuxはUSBさえあればPC用デバイスの多くはそのまま使えるので拡張容易なところは大変良い。

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

2009/06/27

RTKLIB: Porting to Beargle Board - GPS Receiver Extansion Card
ようやくOlimexに発注。結局10milルールで作り直して色々といじっていたら遅くなってしまった。

なお、Olimexは品質が悪いとアドバイスを頂き、基板発注先について色々と検討した結果、結局安さで再度Olimexに落ち着いた。"Low-Cost" RTK-Receiverというのを考慮したというところもある。検討結果を以下に残しておく。

製造者 コース 値段 *1 納期 *2 備考
Olimex DSS 8mil \0.4万 15日  
Olimex DSS 10mil \0.4万 3-5日  
P版.com ノーマル \2.3万 5日  
P版.com ワークサイズ \1.2万 20日  
P版.com 定額給付金 \1.2万 14日 5枚
ExpressPCB Standard \0.7万 1日 レジスト/シルクなし
ExpressPCB MiniBoard \0.7万 2日 サイズ合わない (2.5x3.8")
ExpressPCB ProtoPro \1.6万 2日 4枚
100×80mm, 両面, 2枚, *1 TAX/Shipping除く, *2 配送除く

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

2009/06/26

T.Springer et al., Saving SVN49 Detailed Look at a GPS Signal Anomaly, InsideGNSS, July/August 2009
5/17に少し触れたgnss blogを書いているT.SpringerがInsideGNSSにSVN49信号異常の解析結果の詳細を書いている。 blogの内容からして専門家ではないかと思っていたが、ESOCの関係者でBerneaseの開発にも携わっていたバリバリの研究者の様だ。

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

2009/06/21

Receiver Boardの基板設計ようやく完。あと配線チェックしてOlimexに発注予定。結局10milルールでは無理なことが分かって、8milルールになってしまった。10milに収まると早いらしいのだが。

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

2009/06/20

D.Jewell, The SVN-49 Story: What Went Wrong, How it Got Found - and Fixed, GPS World, Jun 19, 2009
SVN49の信号異常原因についてGPS関係者に取材した結果を伝えている。これによると

> ... the real problem was determined to be the way the L5 payload is integrated through the auxiliary payload
> port that causes reflected energy from the L1 and L2 signals to be reflected back into the broadcast antenna.
> This reflected signal causes a phase shift between the L1 and L2 signals, which affects how they are being
> formed and transmitted. The physical manifestation of the problem for users is that the resultant phase-center
> bias makes the satellite appear to be up to 150 meters closer to the Earth than is actually the case. 

とのこと。ちょっと信じがたい結論だが本当だろうか。結局もともとの原因は、時間が無くて地上試験をちゃんと行っていなかったことの様で、やっぱり焦るとろくなことがないような気がする。なおBlock IIFの打ち上げは来年3月以降とのこと。

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

2009/06/19

Receiver Board続き。既存ライブラリは殆ど使えなくて、結局0からライブラリ作らなければいけないので時間がかかる。LEA-4Tってよく調べたら電源3.3Vでなくて3V (2.7-3.3V) だということが分かったので3V LDOを追加。なお5Tは3.3Vでも使えるように電源電圧が変更 (2.7-3.6V) されている。あと調べたらSPI接続のLCDって結構有る様なので、後からLCD付けられるようSPIの引き出しを追加。この調子では基板発注は7月にずれ込むので受信機が組みあがるのは早くて8月になりそう。しかし基板を見ていると、LQFPとかのパッケージの実装がホントに自分で出来るのか、とても心配ではある。

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

2009/06/18

Eagle使ってBeagle Boardと合わせるReceiver Boardの設計中。まだ使い勝手が良く分からなくて、LEA-4Tの部品ライブラリ作るだけで半日もかかっている。とても効率が悪い。

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

2009/06/15

R.B.Langley, Launch of Next and Last GPS Block IIR-M Satellited Move Up -- Slightly, 15 Jun, 2009
最後のBlock IIR-M衛星、通称"wet-sat"の打ち上げが予定より少し早まり8/17になったとのこと。SVN49/PRN01はまだhealthyになっていないのに大丈夫なのかという気もするが、問題の解決に目処が立ったということなのかもしれない。

補足: SVN49の復旧は10月までかかる様だが、やはり8月に予定されているBlock IIRMの打ち上げは強行する様だ (参照)。GAOレポートとか出て色々と批判もありGPS Wingも焦っているのかもしれない。焦るとろくなことがない様な気はするが。(6/19追記)

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

2009 International Symposium on GPS/GNSS "Interchangability for PnP GNSS", International Convention Center Jeju, Korea, November 4-6, 2009
IS-GPS/GNSS-2009のアブストが今日までだったことをすっかり忘れていた。とりあえずsubmissionはしたので貼っておく。Paper〆切 9/30。宇宙科学技術連合はネタ切れで今年はパス。

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

2009/06/13

Mainichi jp, ゲリラ豪雨: GPSで予測、今秋にも運用開始「いつ」「どこで」精度向上, 2009/6/9
ということでGPS気象学の成果が天気予報に応用されることになった様。ようやくという感じ。

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

2009/06/12

Beagle Board上で取った実行時間profile。後処理基線解析 (rnx2rtkp) 2880 epoch。85%以上が行列乗算/逆行列計算に費やされていることが分かる (compile options: -O3 -mfpu=vfp -mfloat-abi=softfp)。これを見る限り最適化BLASの導入は有効だと思うが、apt-getで取得できるliblapack-dev packageはvfpが有効になっていないのかリンクするとむしろ遅くなる。これは自分でコンパイルしないと駄目だろう。

補足: 以下は標準ライブラリ実行時間を含んでいない。user timeで68sくらいなので半分以上はmathライブラリの実行時間ではないだろうか。やはりtoolchainを作り直してlibcをvfp対応にしないと駄目だろう。しかしkernelを安定に生成できるtoolchainの構築は難易度が高い。(6/13追記)

補足: arm-ubuntuでは、vfp対応のlibcは標準インストールされていることが分かった (/lib/vfp下) 。ということで LDFLAGS=-L/lib/vfp をつけて見たが速度は改善しない (6/16追記)。

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls   s/call   s/call  name
 74.79     24.18    24.18   296465     0.00     0.00  matmul
 10.52     27.58     3.40    26003     0.00     0.00  matinv
  2.20     28.29     0.71   126327     0.00     0.00  satpos_
  1.48     28.77     0.48   126327     0.00     0.00  eph2pos
  1.39     29.22     0.45     2880     0.00     0.00  lambda
  1.21     29.61     0.39   227574     0.00     0.00  geodist
  1.14     29.98     0.37     5760     0.00     0.00  ddres
  0.96     30.29     0.31     2880     0.00     0.00  filter
  0.90     30.58     0.29    14404     0.00     0.00  zeros
  0.84     30.85     0.27   125829     0.00     0.00  ionmodel
  0.74     31.09     0.24     2880     0.00     0.01  pntpos
  0.71     31.32     0.23     2880     0.00     0.01  rtkpos
  0.31     31.42     0.10   423492     0.00     0.00  str2num
  0.31     31.52     0.10    40414     0.00     0.00  ecef2pos
...

今日の進捗: ubloxとemobileが認識され使えるようになった。あと、USB-LAN Adaptorを繋いでBeagle Board上でaptが使える様になった。WiFiカードはまだ駄目。

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

RTKLIB: Porting to Beagle Board
RTKLIBのBB移植関係は別頁に情報をまとめることにした。随時更新予定。

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

2009/06/11

BB-RTK-receiver続き。最も懸案だった実行性能は大体予想した程度だったので目処は立った。
昨日はとりあえず構築済みのkernelを取ってきて動かしたのだけど、emobileも、ubloxも認識されないし、使ったWiFiカードドライバもサポートされていない。今後のことも考えるとやはりtool-chainやkernel構築からやった方が良いだろう。色々と情報を仕入れないといけないし、まだ時間がかかりそう。RTKSVRのコマンドライン対応とかRTKLIB側の改修やGPS受信機ボードの開発も必要で、まだまだ先が長い。

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

2009/06/10

やっとBeagle Board上でAPのコンパイル・リンクができる様になったのでRTKLIBの実行速度を測る。timeで測ったユーザ実行時間。

(1) 後処理基線解析 (rnx2rtkp) 2880 epoch : 1m12.141s
(2) ublox生データRINEX変換 (convbin) 3645 epoch : 3.156s

ちなみにメインPC (C2Q 2.4GHz) Cygwin上での実行結果 (gcc 3.4.4) は

(1) 後処理基線解析 (rnx2rtkp) 2880 epoch : 3.171s
(2) ublox生データRINEX変換 (convbin) 3645 epoch : 2.843s

Beagle boardはSDカード上での実行結果。両者ともLAPACKはリンクしていない。やはり少し浮動小数点演算が厳しい。KGPSの処理に1epochあたり25msもかかっている。これでは20Hz RTK-GPSがギリギリという感じ。ちなみにBeagle Board上のgccの設定はdefaultのままで以下の通り。チューニングでどこまで速くなるか。

ubuntu@beagleboard:~/rtklib/rtklib_2.2.1/app/convbin/gcc$ gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libssp --disable-sjlj-exceptions --with-arch=armv5t --with-tune=cortex-a8 --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)

補足: オプション --mfpu=vfp --mfloat=softfp を付けてFPUを有効にすると (1) 34.516s、1epochあたり12ms。頑張って最適化して100Hzいけるかどうかという感じ。なお、--mfpu=vfp --mhard-float は "sorry, unimplemented" と出てコンパイルできない。将来のgccバージョンではサポートされるのかもしれない。(18:29追記)

補足: rnx2rtkp v.2.2.1にバグがあって、上は整数バイアスを解かない実行時間だった。整数バイアスを解くと大幅に遅くなることが分かった。ちょっと厳しいなあ。(6/12追記)

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

BB-RTK-GPS receiverのBBM。といってもBeagle BoardとAEK-4TとUSBハブを繋いだだけだが。EmobileとWiFi LANカードはdevice driverが組み込んでないのでまだ使えない。

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

2009/06/09

覚書。Beagle Board Ubuntu。ようやくRTKLIBのBeagle Boardへの移植に入る。
今日やったこと。BB-Dsub9Pシリアルケーブルの製作。開発環境用VMWare再インストール。VMWare上にUbuntu 9.04の導入。BB-Ubuntu開発環境のダウンロード。BB Ubuntu Root FSの生成。gpartedを使ってSDカードにFAT32とext3のパーティション生成しuImageとBB Ubuntu Root FSを書き込み。ようやくSDカードからBB Ubuntuの起動を確認。でもUSBデバイスを繋ぐ為に、USB Mini A付のケーブルが必要らしい。自作しようとしたがちょっと細かすぎて厳しいので、明日買いに行くことにして今日はここまで。

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

昨日「もし今、米国がGPSの信号を止めたとしても、とりあえず困らない」と書いてしまったが、既に色々な社会インフラがGPSに依存してしまっているので、本当は「もし今、米国がGPSの信号を止めたとしたら、社会は大混乱に陥る」が正しいだろう。GPSが止まってしまった場合の社会への影響を分析してみるのは、学生さんの面白い研究テーマだと思う。

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

2009/06/08

GLONASS+MSASによるRTK解。この例でcm精度は問題なく出ている。これで、もし今、米国がGPSの信号を止めたとしても、とりあえず困らないことになる (GPSが止まった場合にMSASが正常運用できるのかどうか知らないが)。

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

NovAtel OEMV受信機から出力されるR9 L2 Tracking status=0x00B1964Bである。OEMV manual Table 74によるとこの意味は、

Tracking state=L2 Phase lock loop, SV ch number=18, Phase lock flag=Locked, Parity known flag=Not known, Code locked flag=Locked, Corrrelator type=PAC, Satellite system=GLONASS, Grouping=Grouped, Signal type=L2P, Forward Error Correction=Not FEC, Primary L1 channel=Not primary.

Party known flagが立っていない以外は特に問題ない様に見えるが、どうもデータが変なので暫定的にGLONASSでparity knownが立っていなければデータを無効にすることにする。

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

やはり、GLONASS R9のL2観測値は変である。大きなresidualsが乗っているし、多分周波数もノミナル値と違うのではないだろうか。これが原因でR9を除外しないと正常にRTK-GPS/GLONASS解が求まらない。どこかにR9 L2の情報落っこちていないだろうか。

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

GLONASSあるいはGPS/GLONASS RTKにおけるARは色々な手法があるようで、例えばGoogle Scholarで"GLONASS ambiguity resolution"でググれば色々な論文がヒットする。ただ、多くの論文が難解で内容をちゃんと理解するのが難しい。今回はこれらを全部無視して、GPS/GLONASSのrover-base間1重差観測方程式が以下で表せるものとした。

Φii + c (dt + Δdts) + λi0s + Ni) + ε
Pii + c (dt + Δdts) + ε

ここで、s = GPS or GLO、Δdts: 受信機H/Wバイアス, Φ0s: 受信機初期位相である。2重差観測方程式を使って、GPS-GLO受信機H/WバイアスΔdtGPS-GLOと衛星毎1重差搬送波位相バイアス Bi=(Φ0s + Ni) をカルマンフィルタで推定する。Φ0GPS, Φ0GLOは定数であると仮定すると、1重差搬送波位相バイアスのGPS-GPS間差、GLO-GLO間差は初期位相項が消去されて整数化できる。ただしGPS-GLO間は整数化できない。確認していないが、異機種受信機間基線でGLONASSのinter-channelバイアスが異なる場合は、Φ0GLO = 定数 の仮定が成り立たないのでGLO-GLOバイアスは整数にならない。この場合はGLO-GLOバイアスを整数化しないで実数のままとすれば良い。RTKLIBが採用しているAR手法はバイアスのFIX/FLOATを自由に選択できるので以上の実装は簡単である。一応OEMV-OEMV基線ではこの手法で問題ないようだ。他の受信機でちゃんと動くかは今後確認予定。(このメモはY君向け)

補足: 今回は2重差観測方程式を立てる際にGPSを基準衛星としてGPS-GLO差分も有効としたが、GPS, GLO毎に基準衛星を選択して、GPS-GPS、GLO-GLO差分のみ使うという方法もある。この方式では、観測方程式の数が1つ減る代わりに、ΔdtGPS-GLOを推定する必要がなくなる。少し推定条件が悪くなるがこの方式のほうが実装は容易かもしれない。(10:30追記)
もっと書けば、Φ0GPS, Φ0GLO 項を明示的に推定する手法も考えられる。この手法のほうが少しだけAR性能が上がるはずであるが、今のところうまく行っていない。(10:40追記)
さらに書けば、この手法のミソは受信機間1重差バイアスを推定パラメータに選んでいる所にある。最初に2重差バイアスを推定パラメータとしてしまうと、GLONASSが入ってくると追加パラメータが現れて処理が複雑になってしまう。(11:25追記)

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

2009/06/07

RTK-GPS/GLONASSの整数バイアスFIX成功。思ったよりあっけなかった。異機種間基線でinter-channel biasが異なる場合に備えてGLONASS-GLONASSバイアスをFloatで泳がせるオプションを付ける方が良いだろう。研究室のJavadを借りてNovAtel-Javad基線で評価もしてみたい。R10とR14がOEMV F/W v.3.500では受からないという情報があったのでF/W versionを3.620にあげたのだが、やはりR10とR14は受からない様だ。まだちゃんと受信機が対応していないのだろうか。

補足: 今回RTK-GPS/GLONASSでRTK-GPSに加えて実装したのは以下の通り。
(1) 衛星毎周波数毎の搬送波波長テーブルを追加。
(2) 単独測位でGGTO項推定を追加。(単純にはGPSのみ場合に最小二乗が解けなくなるので、GLONASSが無い場合、自動的に計画行列をshrinkする)
(3) L1, L2毎のGPS-GLO H/Wバイアスをカルマンフィルタで追加推定。
(4) GPS-GPS, GLO-GLO間の二重差バイアスのみ整数化 (GPS-GLOは整数化しない)。

これだけである。NovAtelの場合 (3) を入れなくても問題が起きない様だ。これはNovAtelのGPS-GLO H/Wバイアスが十分小さい (10cm程度) のが原因で一般には入れないと駄目なはず。衛星数増加は悪条件でのFIX率改善に間違いなく役立つと思われる。(13:37追記)

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

2009/06/05

GLONASS Slot 9は"L1 only"のはず (参照) なのだが何故か今日はL2が受かる。ただしP2に擬似距離誤差が45m位載っている。これは試験運用? NovAtelのF/W updateの影響? 情報が少なくてGLONASSはよく分からない。

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

2009/06/04

初のRTK-GPS/GLONASS解。OEMV-OEMV (F/W v.3.620)。2周波。基線長1m。おかしいなあ。まだちゃんと整数バイアスが解けるはずないのだが、どこか思い違いをしているのかもしれない。

補足: 時間がたってフィルタが収束するとFIXしなくなる。やはり駄目。(6/5追記)

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

内閣官房, 地理空間情報産学官連携協議会
位置づけがあまり良く分かっていないが地理空間情報に関する技術開発推進を目的にした協議会の様。「共通的な基盤技術に関する研究開発WG」の第3回配布資料3-1として「地理空間情報活用に係わるアンケート調査結果のまとめ」が配布されているのだけど「研究開発すべきと考えられる技術」として複数人から、QZS LEXによるNRTKサービスが上げられている (014, 050, 075, 081)。ということで、期待は高そうなので今年から来年にかけて少し本格的に研究開発の予定。

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

アイサンテクノロジー, MMS (モービルマッピングシステム) サンプル走行イメージ
三菱MMSによる地図サンプリング例動画集。デモとしてインパクトがある。MMSを積んだ車を走らせるだけで道路地図の自動生成ができるということなのだろうけど、障害物が多い環境でどの程度実用性があるのかに興味が有る。FOGクラスのIMUを積んでいてもGPSがちゃんと受からなければ10cm精度は出ないわけで、高速道路では使えても都市部道路では厳しいのではないかと予想するが、実際どうなのだろう。MMS自体は仕掛けが大きすぎるのでなかなか一般普及するという訳には行かないだろうが、GalileoやQZSが使えるようになると実用性が増して一部は一般車両に搭載される可能性も有る。新し物好きのGoogleが次期Street View用に採用するかもしれない。レーザスキャナ欲しいな。

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

2009/06/02

金澤他, 国総研資料 第513号: 中低速移動体へのRTK-GPS適用化技術の開発に関する技術資料, 国土交通省国土技術政策総合研究所, January 2009
中低速移動体 (作業用車両) へのRTK-GPS適用研究。QZSシミュレーションやINS複合航法も評価している。評価用に開発したRTK-GPSソフトとRTK-GPS受信機F/W, GrafNav ver.7との比較が興味深い。建設機械を使った大掛かりな屋外実験も行っている。最終結論が良く分からないのだけれど、使い物になる?、使い物にならない? どっちだろう。

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

2009/06/01

古い紙文書を処分して本棚の整理。5年以上前の技術文書と再度印刷すればいい文書はほとんど全部捨てることにした。結局そのままはゴミに出せないA4文書が1m位溜まってしまったのだけど、これどうしよう。シュレッダー買おうかな。

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

5月のアクセスログを見てみるとPoland, Austria, Germany, Italy, Sweden 等特に欧州からのアクセスが増えている様だ。キリが良いので現在のrtklib 2.2.0, 2.2.1, GT 0.6.4のダウンロード数を記録しておく。

588: rtklib_2.2.0.zip (2009/2/1-)
252: rtklib_2.2.0_bin.zip (2009/2/1-)
123: rtklib_2.2.1.zip (2009/5/17-)
63: rtklib_2.2.1_bin.zip (2009/5/17-)
281: gt_0.6.4.zip (2009/5/1-)

なお、ちゃんと集計していないのだがGT0.6.3のリリース先数は50前後だったはずである。

今のところ、RTKLIB 2.2.1にしてもGT 0.6.4にしてもバグの指摘がほとんど届いていないので本当に使って頂いているのか少し心配である。使われている方は (匿名でもOKなので) 何らかのフィードバックを頂くとこちらとしても大変有りがたいです。

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

〜2009/05/31


Home by T.Takasu