2014/06/01〜

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

2014/05/31

IGS Workshop 2014, Celebrating 20 Years of Service 1994-2014, June 23-27, Pasadena, California, US

IGS 20周年記念のワークショップ。今回は米国カリフォルニア州パサデナのカリフォルニア工科大学で。4年前は英国ニューキャッスル、2年前はポーランドオルシュテイン。そういえば、ニューキャッスルもちょうどワールドカップの最中だった。

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

International Symposium on Geodesy for Earthquake and Natual Hazards, GENAH 2014, July 22-26, Matsushima, Miyagi, Japan

地震と自然災害のための測地学国際シンポジウム。GNSSによる地震や自然災害の軽減というのも一つの大きなテーマで、発表のお誘いも受けたのだけど、ちょっと今年は時間がとれなそうで出せなかった。どうもすいません。開催場所は松島のホテル大観荘。プログラム見ると面白そうな発表が多いので、時間がとれれば行きたいなあ。

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

たいした話ではないのだけど、rtklib 2.4.2 p5から、About Dialogでパッチレベルを確認できるようにしました。

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

NANU2014047

ということで、2/21に打ち上げられたGPS IIF SVN64/PRN30がようやく運用開始。2014/5/30 18:45 UTCから。新衛星就役時手順確立のための良い試験ケースなので、確認と対応よろしく。

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

解析のために一時的に多量の計算資源が必要で、それじゃクラウド使ってみようかと思って、Amazon AWSを調べてみた。以下メモ。

(1) CPU沢山使う解析なのでEC2 C3が妥当。1インスタンスあたり最大32コア+RAM 60GB+SSD 320GBまで使える (c3.8xlarge)。CPUはXeon E5-2680v2 なので、物理コアは1620コアだがAVXまでは使える。26,496コアクラスタで484.18TFLOPSと謳っているいるがコア当たり約18GFLOPSなのであまり効率が出ていない効率は90%近く出ている。(6/1修正) スパコンの場合は高速インターコネクトが売りなので、多分ここが弱いのだろう。通信が必要なければ物理CPU性能に近い性能がでることを期待しよう。
(2) 料金は使い方やリージョン (DC設置場所) によって異なり、オンデマンド+Linux+米国東部+c3.8xlargeで料金は$1.68/H。連続的に使う場合は、リザーブドにした方が割引になる。色々とオプションがあるがメニューが多すぎて何が最適か実際使ってみないと良く分からない。
(3) 使えるOSはCentOS, Debian, SUSE, Amazon Linux, Oracle Linux, Ubuntu, Red Hat, Windows Server。OSによっては追加料金がかかる。セットアップ済みのAMI (Amazon machine image) をロードして即利用できる。
(4) インスタンス実行時に保持していたデータは停止時に破棄されるので、データを永続的に保存する場合追加ストレージ (EBS) を利用する必要がある。この料金もオプションで色々変わるが$0.05 /GB/月、$0.05/100万IO から。
(5) 解析に使う場合、(a) 操作のための端末接続、(b) 入力データアップロード、(c) 解析結果回収、のため通信が必要になるが、出力1GB/月までは無料、それ以上10TB/月までは$0.12/GB。

ということで、一番小さなインスタンスなら無料で試用できそうなのでちょっと使ってみた。

(1) 最初にAWSのアカウントを作る。ここからサインイン。途中で認証のための電話番号を入力し電話がかかってくるので、電話から認証番号を入れる。携帯電話番号でも特に問題なかった。
(2) 作ったアカウントでログイン。Amazon Web Services画面でEC2を選ぶ。
(3) EC2 Dashboardで "Launch Instanse" ボタンをクリック。
(4) Step 1: Choose an Amazon Machine Image (AMI) で使うOSイメージを選ぶ。ここでは無料のUbuntu Server 14.04 LTS (PV) - 64bitを選ぶ。
(5) Step 2: Choose an Instance Type で使うCPUインスタンスを選ぶ。ここでは無料のMicro instances (t1.micro) を選ぶ。"Review and Launch"をクリック。
(6) Step 7: Review Instance Launch で内容確認。Instanse Storage がEBS onlyとなっているけど、一時ストレージは使えるのだろうか。"Launch" をクリック。
(7) Select an exsiting key pair or create a new key pairダイアログでSSH接続のための公開暗号鍵を作る。"Create a new key pair"を選んで"Key pair name"を入力。ここでは名前を"testtest"とする。testtest.pemの名前のファイルがダウンロードされる。"Launch Instances"をクリック。
(8) Launch Status画面が出て"your instance is now launchig"と出る。
(9) 起動したインスタンスの状態はEC2 DashboardのメニューInstancesで一覧表示される。接続する場合は、上部メニューConnectを実行すると"Connect To Your Instance"ダイアログが出る。画面の指示に従い、SSHクライアントを起動して接続する。JAVAによるSSHクライアントも選択できる。
(10) SSHクライアントとしてputtyを使う場合は、puttyの鍵変換ユーティリティputtygenで、(7)でダウンロードした鍵ファイルをputty用ppkファイルに変換する必要がある。変換後、puttyのconnection - SSH - Auth - private key file for authenticationでppkファイルを選択し、アドレスubuntu@xxx.xxx.xxx.xxxでSSHログインする。
(11) 無料で使えるインスタンスのOS, ディスク, CPU, メモリは以下の様な感じ。

ubuntu@ip-172-31-xx-xxx:~$ pwd
/home/ubuntu
ubuntu@ip-172-31-xx-xxx:~$ uname -a
Linux ip-172-31-xx-xxx 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@ip-172-31-xx-xxx:~$ df
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/xvda1       8125880 777784   6912284  11% /
none                   4      0         4   0% /sys/fs/cgroup
udev              290480     12    290468   1% /dev
tmpfs              60280    184     60096   1% /run
none                5120      0      5120   0% /run/lock
none              301384      0    301384   0% /run/shm
none              102400      0    102400   0% /run/user
ubuntu@ip-172-31-xx-xxx:~$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 45
model name      : Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
stepping        : 7
microcode       : 0x70d
cpu MHz         : 1795.672
cache size      : 20480 KB
physical id     : 1
siblings        : 1
core id         : 2
cpu cores       : 1
apicid          : 36
initial apicid  : 36
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu de tsc msr pae cx8 apic sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 popcnt tsc_deadline_timer aes avx hypervisor lahf_lm
bogomips        : 3591.34
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:
ubuntu@ip-172-31-xx-xxx:~$ cat /proc/meminfo
MemTotal:         602768 kB
MemFree:          402832 kB
Buffers:            1000 kB
Cached:           143864 kB
SwapCached:            0 kB
Active:            86204 kB
Inactive:          73628 kB
Active(anon):      15028 kB
Inactive(anon):      172 kB
Active(file):      71176 kB
Inactive(file):    73456 kB
...

(12) この状態で自動的にEBS上に8GBくらいディスクが割り当てられている様なので、ファイルをアップロードしてみる。アップロードにはWinSCPを使う。WinSCPで、Host nameに割り当てられたIPアドレス、User nameにubuntu、Advanced... - SSH - Authentication - Private key file で (10) で生成したppkファイルを指定。"login" ボタンをクリックすると接続できる。
(13) WinSCPで某APパッケージ180MB位をアップロード。転送速度は1.9MB/s位出ている。
(14) 某APパッケージをビルドするためにはいくつかパッケージを追加する必要がある。sudo apt-get installで以下インストール。make, gfortran。
(15) MKLを使った行列計算の単体テストを実行。5000×5000はメモリが取れなくてエラー終了する。まあフリーメモリ400MBしかないので仕方ない。

matmul()   200 x   200: time=   0.019 s (   840.0 MFLOPS)
matmul()   500 x   500: time=   0.053 s (  4712.3 MFLOPS)
matmul()  1000 x  1000: time=   0.431 s (  4638.1 MFLOPS)
matmul()  2000 x  2000: time=   3.517 s (  4548.2 MFLOPS)

(16) 無料で使えるインスタンスではかなり遅いが、動作は特に問題ない。あと端末レスポンスがちょっと遅い感じ。インスタンスのステータスでZoneを見ると"us-west-2b"とあるので、米国オレゴン州のDCらしい。VNCで接続するのはちょっと厳しいかも。インスタンスによっては東京のDCも選べるが、米国に比較して料金が少し高い。
(17) EC2 DashboardのElastic Block Store (EBS) のsnapshotsメニューを使うとEBSディスクイメージのスナップショットがとれるらしい。ただ、どこから課金されるのかが良く分からない。AWSのアカウント作る時にクレジットカード番号を入れたので、知らない間に課金される可能性がある。もうちょっと良く調べてからだな。
(18) EC Management Console 上部のアカウント名をクリックして選択できるメニューBilling and Cost Managementを実行すると現在の月毎課金情報が確認できる。
Monthly Spend
$0.00
ということでほっとした。課金発生したらアラートをメールしてくれる様に設定もできる模様。
(19) 起動したインスタンスを停止するためには、EC2 DashboardのInstancesメニューで起動中のインスタンスを指定して、上部メニュー Actions - Stop を実行する。Stop Instances ダイアログで"Warning Please note that any data on the ephmerial storage of your instance will be lost when it is stopped" と警告が出る。"Yes, Stop" を選ぶ。少し経つとインスタンスのステータスが"stopped"に変わる。
(20) 再度 Actions - Startを実行すると、再度インスタンスが起動してSSH接続できるようになる。なお停止してもEBS上のディスクイメージは消されないで残っている様だ。インスタンス自体を完全に終了するためには Actions - Terminateを実行する。"Warning On an EBS-backed instance, the default action in for the root EBS volume to be deleted when the instance in terminated. Storage on any local drive will be lost" と警告が出るので、終了するとそのインスタンスに紐付けされたEBSストレージは消されてしまう様だ。

ということでAmazon EC2をちょっとだけ使ってみた。手軽に仮想環境を使えるのは良いけど、料金体系が複雑でどれくらい使ったらどれくらい課金されるのかが良く分からない点が不安。本格的に使ってみるかはちょっと検討してみよう。

補足: あと感じたのはAmazonの技術力物凄いなあ、ということ。世界中に十何か所かあるDCで合わせて数十万〜数百万台規模のサーバが動いていて、超巨大で複雑なシステムをウェブインターフェースでユーザが簡単に操作できる訳で。障害やセキュリティについても万全の対策とってるはずで、相当のノウハウの蓄積が無いと無理だろう。日本でも、さくらインターネットなんかは頑張っていると思うけど、Amazonと比較すると管理コンソールがなんかしょぼいからなあ。(12:46追記)

再補足: EC2 C3 1インスタンスとほぼ同等のサーバを買うと今なら概ね1式 \80万くらいか。3年で償却するとして\800,000/3/365/24=\30.4/H。電気代\27/kwh位らしいので、サーバ電力800wとして電気代が\21.6/H、あわせて\52.0/H。あと、OSのセットアップとか、バックアップとか、障害時対応とかの人件費。東京だとサーバの設置コストも無視できない。以上を考えても、まだ平均的にはクラウドよりサーバ買った方が安いだろう。ただ、解析の場合には必要な時には有るだけ計算資源が欲しいけど、それ以外の時は殆ど稼働していない訳で、クラウドのスケーラビリティに価値がある。週末ビルの停電で貴重な解析時間が使えないなんてこともないし。(18:45追記)

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

2014/05/29

RTKLIB: support information

恥ずかしながら、また致命的なバグが見つかったので、rtklib_2.4.2_p7をリリース。障害としてはRINEX 2 観測データの読み込み時にメモリアクセス例外で落ちるもの。原因は観測タイプテーブルを追加した際に間違えて終端の空文字列を削除してしまった単純ミス。RINEX 3では発生しないはず。一緒に3周波×(GPS+GLO+BDS) の基線解析で落ちるバグも修正。

RTKLIBユーザの皆様、色々とご迷惑をかけて申し訳ありません。

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

良い機会なので、昨日の続きでもう少し細かいチューニングをしてみよう。

Silip Thres (m) の設定。これはgeometry-free線形結合によるサイクルスリップ判定の閾値。

Outage to Reset Ambの設定。これはデータ連続欠落時にアンビギュイティをリセットするエポック数。

Min Lock to Fix Ambの設定。これは解が得られてからアンビギュイティをfixするまでのエポック数。

Min Fix to Hold Ambの設定。これはF&Hモードでアンビギュイティをholdするまでのエポック数。

Reject Threshold of GDOPの設定。これは単独解を棄却する場合のGDOP閾値。

Reject Threshold of Innovation (m) の設定。これはフィルタのpre-fit残差によるデータ棄却閾値。

以上の最適値で、Rec Dynamics ON/OFFの設定。

Process Noise - Receiver Accel Vertical (m/s2/sqrt(s)) の設定。実行にとても時間がかかるので最後に。

Rec Dynamics ONの効果。U-D解。上からOFF, ON (process noise=1×10¹), ON (process noise=3×10^-1)。ONにすることにより06:17,0:38付近のミスフィックスが改善されているが06:17付近の解を見ると過剰なフィルタがかかってしまっている。また、ONにしても06:12, 06:22, 06:34あたりのミスフィックスが取れていない。また、ここではミスフィックスによる誤差が最大10mを超えている。水平でも5mはずれているだろう。都市部では使える衛星を全部使ったRTKでもこの辺が限界という感じ。これ以上はINS統合が必要だろう。

補足: これ同じ道路を3周しているので06:17-06:22の解は明らかに異常。ということで、Instantaneous AR、GLONASS AR ON, Min Elevation to Fix Amb = 0の解。Rec Dynamics OFF。

うーん。やっぱり、移動体の場合、Instantaneous ARにしないとミスフィックスのペナルティが大きすぎてダメかも。
CPUメータ見てたらMKL版でもCPU使用率が25%までしか上がっていない。調べるとシステム環境変数にいつのまにかMKL_SERIAL = YESなんて設定が。ぐぐるとMKL BLASのマルチスレディングをOFFする設定らしい。これNOにしないとダメだな。
(8:00追記)

システム環境変数のMKL_SERIAL = YESを削除したら、CPU負荷が99%まで上がるようになって実行時間も若干速くなった。
(8:52追記)

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

2014/05/28

このテストデータは移動体におけるマルチGNSS-RTKのとても良い例題なので最新版のRTKPOSTを使って解析してみよう。パラメータ設定で結果がどう変わるかも興味深い課題なので例も兼ねてチューニングしてみる。まず初期設定は以下の通り。

RTKPOSTはrtklib_2.4.2_p7で3周波 (Frequencies=L1+2+5)。p6では下で書いたとおり2周波 (Frequencies=L1+2) までしか正常に動作しない。まずは解析時間の測定。(Core i7 2600K、4コア 4スレッド)

ということで、通常版はシングルスレッドでしか動かないので、パラメータチューニングにはMKL版を使わないととてもストレスがたまる。

さて、移動体RTKで最も性能に効くのは通常仰角マスク (Elevation Mask) なので、まずこれを5度刻みに変えてFix率を評価する。なお、RTKPLOTのステータスバーに表示されるパーセントは母数に解の得られないエポックが含まれていないので、評価用に使うのは妥当でない。以下、表はFix解数 (Fix率) を表し、Fix率 = Fix解数/全エポック数 (20401) で定義する。

35度と40度の間に最適点がありそうなので、次に1度刻み。

仰角マスクは38度に固定。次にARモード (Integer Ambiguity Res (GPS/GLO)) の設定。

F&H (Fix and Hold) モードはもともとは移動体のFix率向上のため2.4.0で追加したもの。ただ、GLONASS入れると悪くなるのはGLONASSの信号品質が悪いのか。F&H/OFFで固定。次に、ARマスク角 (Min Elev to Fix Amb) の設定。

45度と55度との間に最適点がありそうなので、次に1度刻み。

差に敏感で結果がばらつくが、50度に固定。次に雑音パラメータの調整。Code/Carrier-Phase Error Ratio L1/L2の設定。

あまり差が出ないが200/200に固定。次にCarrier-phase Error a+b/sinEl (m)。

0.006/0.006に固定。次にRAIM FDEのON/OFF。RAIMは直接は基線解に関係ないが単独解が求まらないと基線解を求めに行かないので、最終的なFix率に影響がある。

RAIM FDEはONに固定。次にRatio Testのスレッショルド (Min Ratio to Fix Ambiguity)。これはミスフィックス率とのトレードオフなので、最適値は微妙だが結果を貼っておく。なお、この値は経験的には2-5が使われる。RTKLIBのデフォルトは3である。

5でもミスフィックスは無くならない。2.5と3のミスフィックス率は殆ど変わらない様に見えるので、2.5に固定。次にRec DynamicsのON/OFF。これ所謂DR (dead reckoning) を入れるモードで、かつ加速度に0拘束がかかる。拘束条件はProcess Noise - Receiver Accel Horiz/Verticalで指定する。この値はとりあえずデフォルト。

このオプション自動車等ではそれなりに有効ではあるが、現実装ではすごく実行時間がかかるので、利用はあまりお勧めしない。以上の最適設定および測位解を以下に示す。partial fixingでGLONASSおよび50度以下の衛星はアンビギュィティ解いていないのでcm級の精度が出ているかは疑問だが、まあ10 cm級は出ているのではないか。ただミスフィックス解については十分に精査の必要がある。

以上、RTKPOSTの設定を手動チューニングする例を示した。基線解の場合、Fix率は品質指標としてはそれなりに有効なので (というか移動体の場合、高精度の基準軌跡を求めるのはとても大変なので、他に使える指標があまりない) Fix率を評価関数にして、実観測データを大量に入力して、パラメータを自動チューニングさせるというのは割と有効かも。これ教師あり機械学習の応用問題として研究価値があるかもしれない。これ学生さん誰かやりません。

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

また、rtklib_2.4.2_p6にバグ見つけてしまった...。(GPS+GLO+BDS)×3周波 とか(GPS+GLO+GAL+BDS)×2周波の基線解析でメモリアクセス例外で落ちます。(GPS+GLO+BDS)×2周波では問題起きません。配列サイズ増やすの忘れた単純バグ。複雑な解析する人は多分自分で見つけられるはずなので、次のパッチまでは自力で直して使ってください。

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

RTKLIB: support information

ということで、rtklib_2.4.2_p6をリリース。原因はGPSが抜けると正規方程式がランク落ちして最小二乗が解けない問題。GPSが抜けた場合受信機クロックバイアスに0拘束をかける様に修正。なおrtklib_2.4.2_p6にはp5の変更を全て取り込んだのでp6適用前にp5を適用する必要はありません。

補足: RTKPOST内部で推定した受信機クロックバイアス、GLO-GPS時系差、GAL-GPS時系差、BDS-GPS時系差はoptions - output - output solution status をstateに設定すると、solution statusファイルにCSV形式で出力されます。該当レコードは以下の様な形式で、

$CLK,1786,601132.000,5,1,34.919,-405.886,-23.200,21.652

第2フィールドからGPS週, TOW (s), Qフラグ, 受信機識別 (1:rover,2:base), 受信機クロックバイアス (GPST基準) (ns), GLO-GPS時系差 (ns), GAL-GPS時系差 (ns), BDS-GPS時系差 (ns) を表します。厳密に言えば、時系差は受信機疑似距離ISB (inter system bias) を合わせた値です。この値を求めた際のRINEX NAV (3.02) のヘッダを見ると、UTC-BDTが+5.6 ns、UTC-GALTが-1.9 ns、GPST-GLOTが-389 ns、UTC-GLOTが-189 ns、GALT-GPSTが-3.4 ns、UTC-GPSTが0.0 nsとあるので、時系接続誤差、時系差推定誤差や受信機ISBを考慮すると、GLONASS以外は推定値は矛盾しない値と言えるでしょう。GPST-GLOTおよびUTC-GLOTはGLONASSがアルマナックとして放送している値 (TauGPSおよびTauC) ですが、UTC-GPSTは200 nsもないので明らかに矛盾しています。最新のCircular-Tを見るとC1(UTC-GLONASS_Time) が-180 ns位、C1'(UTC-UTC(SU)_GLONASS) が-370 ns位の値となっています。これから推測できることは、GLONASS関係の時系はGLONASS_Time, UTC(SU)_GLONASS, UTC(SU) と3種類あり、航法データのクロックパラメータ(TauN) とTauGPSはUTC(SU)_GLONASS基準、TauCはGLONASS_Time基準である、ということです。GLONASS-ICD 4.4には「TauNはGLONASS Time基準の補正値」と書いてありますがこれはCircularTのGLONASS_Timeとは定義が異なるのかもしれません。ということで、ちょっと調べただけでもマルチGNSSデータの処理にとって時系の取り扱いが相当厄介であることが分かります。なお衛星軌道を表す時系も衛星系によって異なりますが、時系差が1μs未満の場合はその影響は軌道精度に比較して十分小さいためほぼ無視して差し支えありません。(12:23追記)

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

2014/05/27

RTKLIB: support information

ということで、必要があって約9カ月ぶりにメジャーパッチ (rtklib_2.4.2_p5) をリリース。内容的には2.4.3でも良いのだけど。主な修正内容は細かいバグフィックスとGalileoとBeiDouサポート。ソースの変更点はgithubで。

補足: 早々にBeiDou単独で測位できないとのご指摘を貰いました。GPS+BDSは動きますが、GLO, GAL, BDS単独では正常動作しない様です。単独測位アルゴリズムを少し変更したのでそれが悪さをした様で。ということで早々にrtklib_2.4.2_p6を出して、p5を置き換える予定。少しお待ちを。(9:52追記)

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

2014/05/23

Why Python is Better than Matlab for Scientific Software

私自身、過去かなりの量のMatlabコードを書いているヘビーユーザーなのだけど (GTはほぼMatlabだし)、はっきり言ってMatlabに未来はないと思う。本質的な問題はproprietaryなソフトウェアである点に尽きる。といっても、私の周りでも未だにちょっとしたグラフ描くのにMatlab使う人多いのだけど。次はぜひ、python+numpy+matplotlibで。

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

InsideGNSS, China Plans to Complete BeiDou Ahead of Schedule, May 21, 2014

中国は、BeiDouの整備計画を前倒しして2017年までにPhase IIIを完成させる。今週、南京で開催されているCSNC (China satellite navigation conference) 2014で発表された。

この記事によると、新世代BeiDou衛星の打ち上げは来年から開始され、Phase IIIの完成は従来の2020年から2017年に前倒しされる。BeiDou Phase IIIではB1信号がGPS L1C/Galileo E1互換 (周波数およびMBOC変調) に変更される。
なお、GPS IIIの打上は2016年からでOCX完成が2017年、Galileo FOC衛星の打上も今年末までに4機と、当初の計画からかなり遅れている。またGLONASSは将来的に3CHの"full family" CDMA信号に移行し、CDMA信号を送信する次のGLONASS-K2の打上は今年末。

以前の報道では、BeiDou Phase III完成時の衛星数は35機、ただしこの衛星数にPhase IIまでの衛星が含まれるのかは不明。2017年には既存衛星の多くはまだ運用可能なので、新しいL1C互換衛星はグローバルサービス提供用として主にMEO軌道に投入されるのではないか。QZSS4機体制での運用開始は2018年度なので、この時には東京の空はもうこんな感じになっていることになる。

補足: 現在軌道上のBeiDou衛星は16機 (MEO×5+GEO×6+IGSO×5) ただしGEO 1機は軌道制御不能でもう使えないので実質15機 (この情報によるとC30 (MEO) は信号出していないらしい。またC04 (GEO) はエフェメリス異常ではないかとのこと) 2017年までに35機ということはあと3年で最低20機打ち上げるということで、来年からまた打上ラッシュになる。(15:55追記)

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

2014/05/21

Inside GNSS, Danish GPS Expert to Lead New Russian GNSS Studies Program, May 20, 2014

どこかで見たようなおっさんだと思ったら、Kai Borreか。

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

Surface Pro 3 欲しいなあ。結局、iPadもAndroidも問題は開発環境なので。密かにGPS内蔵してると良いのだけど。

補足: ノートPCとして考えるとVaio Pro 13とスペック的にはあんまり変わらないのだけど、タブレット単体で使えるのは魅力的。RTKLIBも次期版ではタッチUI対応しようかなあ。

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

2014/05/18

メモ。ubuntuでの不良HDDデータのサルベージ。GNU ddrescueを使う。

$ sudo apt-get install gddrescue
...
$ sudo ddrescue -r 0 -a 1M -v -f /dev/sdb2 /dev/sda4 rescue.log

/dev/sdb2が不良HDD/コピー元、/dev/sda4がコピー先。-a はこれ以上転送速度が下がったらスキップするオプション。-aオプションをつけないと転送レートが100KB/s以下に落ちてしまう。データがほぼフルに入っている2TBのHDDなので、-aなしでは絶対に終わらない。ログ出力するようにしておくとスキップしたセクタを再サルベージしてくれるらしい。

補足: 以上の途中でもコピー先ディスクを fsck -y /dev/sda4で復旧すればマウントできる。二日間で400GBくらいはサルベージしたけど、徐々に平均レートが落ちて、-aオプションをつけても100KB/s以下になってしまったので全復旧には半年以上かかる。ということであきらめて、うまく行くか分からないけどHDDコピー装置を注文。(5/19追記)

再補足: ddrescueによる中途半端なサルベージでは一見正常な破損ファイルが沢山できてしまい、このチェックにとても手間がかかることが分かって、結局必須のデータだけrsyncでコピーすることにした。これで20GB位は救えたのでとりあえずよしとする。全部のサルベージのためにこういうの使って現在HDDのコピー中。(5/20追記)

再補足: コピーの途中経過は4つのLED点灯でしか分からない。コピー始めて5日目で2つ目のLEDで止まったまま。途中で中断するとまた最初からコピーする必要があるので、こうなるともう絶対に電源を切れない。さて1カ月はかかるのを覚悟しているのだけど。(5/23追記)

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

2014/05/17

T.Suzuki, RTK-GNSS (GPS+QZS+GLO+GAL+BSD) with RTKLIB, May, 2014

鈴木君が改造版RTKLIBでBeiDouを含めた移動体RTK性能評価を行ってくれているので貼っておく。受信機は両方ともTrimble NetR9。仰角マスク20度でGPS+QZS+GLO+BDSの平均衛星数は13.1機。

補足: NetR9って基準局専用で移動体ローバ用に使えないんじゃないのと思っていたら、受信機エンジンは移動体用のものと同一らしい。RTCM3 (MSMはまだ未対応) やBINEXも出るとのことで、RTKLIBと組み合わせてリアルタイムのRTKに利用可能。(16:52追記)

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

NASA SpaceFlight.com, ULA Delta IV launches sixth Block IIF GPS satellite, May 15, 2014

2014/05/17 00:03 UTC, GPS Block IIF-6衛星, 米国ケープカナベラル空軍基地からDelta IVロケットで打ち上げ成功。打ち上げられた衛星はスロットD4に投入されBlock IIA-14衛星 (PRN04) を置き換える。衛星番号はSVN67/PRN06。次のGPS Block IIF衛星の打ち上げは7月、その次は10月で、次回からAltas Vが使われる予定。

なお, 2/21に打ち上げられたBlock IIF-5衛星は、打ち上げ後3カ月近くたっているにも関わらず、まだ正式運用開始されていない。この理由についてのアナウンスはないが、何らかの問題が発生している可能性もある。

補足: 打上ビデオ。この記事によるとIIF-5は"navigation characterizing testing"がもうすぐ終わって、今月末までに運用が開始されるとある。(16:03追記)

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

2014/05/04

RTK-GPS ISOBlue

P.26で"Adding more satellites after locking is the main reason of losing the lock"がバグじゃないかってあるけど、これバグじゃないと思うのよね。"fixable"とあるのでお手並み拝見。

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

2014/05/02

NANU 2014038

2014/04/28 14:30 UTCから、GPS L2C, L5 チャンネルでCNAVの"pre-operational"な送信が始まったはずなので、NovAtel OEM6での取得を試みているのだけど、どうもうまく受かっていない。手順としては、OEM6はデフォルトではL2P(Y)を受けるのでこれをL2Cにするために、
[USB3] forcegpsl2code c
<OK
とやってから、F/W 6.400で追加されているメッセージrawcnavframe (ID=1066) を出力するため、
[USB3] log rawcnavframea onnew
<OK
と送る。エラーにはならなくてOKが返るので有効になっている様だけど、今のところログが出力されない。なおOEM6の場合L5はパイロットのQ CHしかトラッキングしない様で、L5 CNAVを受信するのは無理みたい。ということで、来週になったらJAVADで試してみよう。もし、CNAVちゃんと受かっている人いたら教えてください。

補足: JAVADのデータが手に入ったので [gd] (gps raw navidation data) をデコードしてみた。MTとしては10 (ephemeris 1), 11 (ephemeris 2), 30 (clock, iono & group delay), 33 (clock & utc) が送られている。ちなみに、QZSSはこれらに加えて、14, 28, 31, 34, 35, 37が送られている。(14:42追記)

2 L5CNAV: sat=25 prn=25 msgid=33 tow= 74764 alert=0
2 L2CNAV: sat=25 prn=25 msgid=11 tow= 74764 alert=0
2 L2CNAV: sat=29 prn=29 msgid=11 tow= 74764 alert=0
2 L2CNAV: sat=31 prn=31 msgid=11 tow= 74764 alert=0
2 L2CNAV: sat=12 prn=12 msgid=11 tow= 74764 alert=0
2 L5CNAV: sat=25 prn=25 msgid=10 tow= 74765 alert=0
2 L5CNAV: sat=25 prn=25 msgid=11 tow= 74766 alert=0
2 L2CNAV: sat=25 prn=25 msgid=30 tow= 74766 alert=0
2 L2CNAV: sat=29 prn=29 msgid=30 tow= 74766 alert=0
2 L2CNAV: sat=31 prn=31 msgid=30 tow= 74766 alert=0
2 L2CNAV: sat=12 prn=12 msgid=30 tow= 74766 alert=0
2 L5CNAV: sat=25 prn=25 msgid=30 tow= 74767 alert=0
2 L5CNAV: sat=25 prn=25 msgid=33 tow= 74768 alert=0
2 L2CNAV: sat=25 prn=25 msgid=33 tow= 74768 alert=0
2 L2CNAV: sat=29 prn=29 msgid=33 tow= 74768 alert=0
2 L2CNAV: sat=31 prn=31 msgid=33 tow= 74768 alert=0
2 L2CNAV: sat=12 prn=12 msgid=33 tow= 74768 alert=0
2 L5CNAV: sat=25 prn=25 msgid=10 tow= 74769 alert=0
2 L5CNAV: sat=25 prn=25 msgid=11 tow= 74770 alert=0
2 L2CNAV: sat=25 prn=25 msgid=10 tow= 74770 alert=0
2 L2CNAV: sat=29 prn=29 msgid=10 tow= 74770 alert=0
2 L2CNAV: sat=31 prn=31 msgid=10 tow= 74770 alert=0
2 L2CNAV: sat=12 prn=12 msgid=10 tow= 74770 alert=0
...

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

2014/05/01

5月である。

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

〜2014/04/30