|
日記・備考録 |
2005 | 2006 | 2007 | 2008 | 2009 | 2010 | 2011 | 2012 | 2013 | 2014/ 1 2 3 4 5 6 7 8 9 10 11 12 | 2015 |
| July | August 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 31 |
September | Home |
...................................................................................................................................
RTKPLOTのスカイプロットに天頂写真の重ね合わせ機能追加。再サンプリングを入れたので回転やレンズ歪補正も可能。この機能は2.4.3に入る。
...................................................................................................................................
N.Nadarajah et al., The mixed-receiver BeiDou inter-satellite-type-bias and its impact on RTK positioning, GPS Solution, 2014
BeiDouによる異機種間基線RTKにおける搬送波位相のhalf-cycle-shift問題について調査検討している。この論文によるとBeiDouのhalf-cyle-shiftは (1) GEOとIGSO/MEOで拡散コードのsecondary codeが異なる (GEOはなし、IGSO/MEOはNH) (2) NHの極性 (1/0の＋/-へのマッピング) がICDに規定されていないのでその解釈が受信機実装により異なる、のが原因とのこと。実際にTrimble, Septentrio, Javad受信機での動作を実験で確認している。SepentrioについてはF/Wのバージョンによっても動作が異なる様だ。これらにより発生するバイアスをISTB (inter satellite type bias) と呼んでいる。
原因が論文の通りとするなら、受信機メーカ間で統一的な実装方法を調整して、皆それに合わせるだけでよいと思うのだけど。一時的には混乱があるかもしれないけど、今のうちならRTKにBeiDou使っている人ほとんどいないし。解析S/Wの対応としては、単純に周波数ごとに1/2サイクルシフトのオプションを付ければよさそう。
...................................................................................................................................
TechCrunch, 位置測定精度数センチの正確なGPSチップを低コストで作るSwift Navigationが$2.6Mを調達, 2014年8月22日
「リアルタイムの運動力学技術」(笑)。「そしてこれまでの高精度GPSチップが1万ドルぐらいしたのに対して、Swift Navigationのチップの売価は約500ドルだ」って、PiksiでRTKホントに動くの? 計画では昨年11月には完成していたはずだけど、GitHubのコード見る限りまだ動きそうもないんだけど。
補足: BSDライセンスだからRTKLIBのコードを流用してもらうのは構わないのだけど、少なくともreadme.txtに入っている細かい copyright noticeはどこかに表示してほしいのだけど。(8/29追記)
-------------------------------------
RTKLIB 2.4.2 p9 released.
パッチが2桁行かない前にバージョン上げると決めているので次は2.4.3になる予定。
-------------------------------------
ESA, Space in Images
画像検索できるんだけど、"galileo"で検索すると459件ヒットする。高精細イラストや衛星のインテグレーション写真は、機器配置や衛星構造を把握するためにとても参考になる。良く見るとIOV衛星とFOC衛星の送信アンテナの設計は全く異なることが分かる。
...................................................................................................................................
誠, ソニー×カシオで実現! 世界初「GPS+電波時計」G-SHOCKの秘密とは?, 2014年06月28日
「GPS衛星から送られる信号を受信して時刻を知ろうとする場合、位置を時刻の両方を知りたい場合は衛星を4つ捕まえる必要がありますが、自分の位置を割り出す必要が無く時刻だけを知りたいなら、衛星を1つ捕まえるだけで済みます。時刻だけを取得するなら約6秒ですが、位置を取ろうとすると最低30秒はかかります」とあるけど、結局位置が分からないと時刻も解けないはずだけど。まあ、スナップショットとアルマナック使って位置と時刻を解いている可能性はある。そうすれば信号捕捉・追尾は1CHで済むし。ただアルマナックだと精度的に時刻には十分でも位置は使えないので応用は限られる。それなら ... (以下略)。
補足: 時刻だけなら確かに1衛星あれば良いのだけど、それは位置が既知の場合であって、位置が不定の場合は結局4衛星の信号が要る。ただ時刻の場合、普通精度はいらないので、アルマナック使ったり時分割で衛星追尾したりすることによりCH数や稼働時間を十分少なくして低消費電力化をはかることができる。ただ全衛星のアルマナックを取得するためには12.5分かかるので信号捕捉アルゴリズムも工夫する必要がある。この例だと頑張って腕時計の太陽電池だけで駆動できる程度まで消費電力を落とした様。あとはアルマナックではせいぜい精度は数kmなので、もう少し精度の良い暦が得られれば...、という話になる。(8/27追記)
-------------------------------------
GPS World, Trimble Offers GNSS Reference Receiver, Seismic Recorder, August 25, 2014
Trimbleが発表したGNSS地震計SG160-09。公式はこちら。基準局用GNSS受信機に高精度3軸加速度計を組み合わせている。GNSS測位はCenter Point RTXかRTK。"ANSS Class A"というのが何の規格なのか調べてみたらこれみたいだな。従来の地震計は超低周波の計測やサチレーションの問題があるので、INS-GNSS統合で0Hz〜数100Hzの高精度地殻変動計測というのは面白い観点の製品だと思う。ただ、GNSS地震計の場合、アンテナの設置場所を確保する必要があるので、従来の地震計をそのまま置き換えられる訳ではない。
...................................................................................................................................
せっかくなのでGalileo FOC衛星の軌道をプロットしてみよう。まず、TLEをCelesTrakのLast 30 Days' Launchesから取ってくる。
2014-050A 1 40128U 14050A 14235.78746997 -.00000026 00000-0 00000+0 0 75 2 40128 49.6868 87.5872 2327923 24.5353 345.1134 2.04736456 25 2014-050B 1 40129U 14050B 14235.68621972 -.00000026 00000-0 00000+0 0 36 2 40129 49.6897 87.5935 2330669 24.6823 271.0168 2.04928670 16 2014-050C 1 40130U 14050C 14235.78612850 -.00000025 00000-0 00000+0 0 55 2 40130 49.7076 87.5770 2323095 24.6378 345.0419 2.05024164 23
40128と40130がGalileo衛星らしい。こう見ると実際の軌道は離心率が0.23とかなりの楕円軌道の様だ。これをRTKLIBのtle_read()で読み込んで、tle_pos()で位置計算し、緯度経度に変換して、matplotlib/basemap-toolkitで地図にプロットする。
#include "rtklib.h"
int main(int argc, char **argv)
{
tle_t tle={0};
double ts[6]={2014,8,24},rs[6],pos[3];
int i;
tle_read("tle_gal.txt",&tle);
for (i=0;i<1440;i++) {
tle_pos(timeadd(epoch2time(ts),i*60.0),"","40128","",&tle,NULL,rs);
ecef2pos(rs,pos);
printf("%10.5f %10.5f\n",pos[0]*R2D,pos[1]*R2D);
}
return 0;
}
#!/usr/bin/python
import numpy as np
import matplotlib
import matplotlib.pyplot as plt
from mpl_toolkits.basemap import Basemap
lat,lon=np.loadtxt('latlon.txt',unpack=True)
fig=plt.figure(facecolor='w')
fig.add_axes([0,0,1,1])
m=Basemap(projection='cyl')
m.drawcoastlines(linewidth=0.5)
m.drawparallels(np.arange(- 90, 90,10),linewidth=0.5)
m.drawmeridians(np.arange(-180,360,10),linewidth=0.5)
m.plot(lon,lat,'.',ms=3)
plt.show()
もちろん、TLEから軌道描くAPはSTKを始め多数あるのでそれも良い。なお、tle_pos() で衛星番号指定でTLEを引く所にバグがあるので少し直す必要がある。
-------------------------------------
SpaceFlightNow, European navigation craft launched into wrong
orbit, August 22, 2014
SpaceFlightNow, Inquiry into Galileo launch anomaly to focus
on Fregat, August 23, 2014
NASASpaceFlightCom, Arianepace Soyuz ST-B in troubling Galileo
launch, August 22, 2014
InsideGNSS, Galileo Teams Investigating 'Injection Anomaly'
of FOC Satellites, August 23, 2014
InsideGNSS, Galileo Soyuz Launches May Be Frozen Follwing
Launch Anomaly, August 23, 2014
一昨日のGalileo FOC1,2号機の打上は一時成功と報道されていたが、実際には予定軌道に乗らなかったらしい。SpaceFlightNowの記事によると、予定軌道は高度23,500 km 傾斜角55度の円軌道だったが、実際に投入された軌道は高度13,700 km 傾斜角49.7度だったとのこと。失敗原因は調査中だが、初期解析によるとロシア製上段ロケットFregat-MTの飛行フェーズで異常が発生したらしい。2機の衛星が予定軌道まで高度を上げるための燃料を積んでいるか、現在の位置から航法信号を放送できるかは、公式発表されていない。(最後の記事では、高度を上げるのは「非常に難しい。多分不可能」) 次のGalileo衛星2機の打上は12月に予定されていたが、今回の打上失敗を受けて延期は確実。ある関係者は来年3-4月より前になることはないだろうとしている。
打ち上げられた衛星は高度が予定よりはるかに低いので測位衛星として運用するのは多分困難で、軌道上試験用にしか使えないのではないか。先のIOV衛星の障害といい、今回の打上失敗といいトラブル続きで、Galileo計画の正念場と言ったところであろう。特に今回の打上失敗は日程に与える影響も大きく、Galileo計画全体の見直しが迫られそうである。
補足: 練習問題、2機の衛星の現在の軌道が円軌道だとして、ここから当初の予定軌道に軌道変更 (高度及び軌道面) するために必要な総ΔV量 (m/s) と推薬量 (kg) を求めよ。衛星質量は700 kgとし、軌道制御用スラスタの比推力は300秒とする。(15:58追記)
再補足: 時間さえかければ最小燃料で昇交点赤径は回転できる (2010/10/07の記事参照) ので、目標軌道の昇交点赤径は任意で良いとする。(16:16追記)
-------------------------------------
国土地理院, 第10回マルチGNSSによる高精度測位技術の開発に関する委員会 現地試験観測による検証, 平成26年6月23日
昨年度総プロの成果の一部で大変興味深い資料なので貼っておく。
p.11の「SPACによるLEX補強」は所謂CMASによる補強。全般的に厳しい測位環境だが、p.16で後処理なのに測位率が極端に悪い原因が良く分からない。あと、p.21-22のL1-SAIFは殆ど補強が有効になっていない様に見える (端末1,2共)。受信機・アンテナが一般用のものだとしてもF/Wに不具合が残っているのではないか。結論 (p.30) の「大都市のビル街では衛星測位だけで常時cm級の位置情報を得ることは難しい。」は妥当であるが、今後の技術開発で実用的な所まで持って行けるかについては、厳しいと言わざるを得ない。
-------------------------------------
国土地理院, 平成25年度 マルチGNSS解析技術等の開発にむけた衛星系の組合せに関する技術開発業務 報告書, 平成26年2月21日
昨年度地理院総プロ「衛星系の組合せ」報告書が公開されている。主に、マルチGNSS測位で最大の問題である受信機バイアス (ISB) について実験及び検討を行っている。
...................................................................................................................................
NASASpaceFlight.com, Arianspace Soyuz ST-B launches with Galileo mission, August 22, 2014
2014/08/22 12:27 UTC, Galileo FOC衛星1,2号機,
フランス領ギアナ クールー宇宙基地より, Soyuz
ST-Bロケットで打ち上げ成功られたが予定軌道への投入に失敗 (8/24修正)。軌道上のGalileo衛星はこれでIOV衛星×4+FOC衛星×2の計6機。Galileoシステムは27機の運用衛星と3機の予備機、計30機で構成され、高度23,222km、軌道傾斜角56度の3つの軌道面に配置される。残り24機の衛星はSoyuz
6回 (各2機) およびAriane 5s 3回 (各4機) の打上で軌道上に運ばれる。次回の打上は12月で2機の予定。
最終的な構成は27+3機と以前から変わっていないが、調達が決まっている衛星は打上済み衛星を含めて26機で、残り4機はまだ予算が付いていないはず。当初計画では2014年にもサービス開始という話だったが、日程はかなり遅れており、今の状況だと順調に行っても初期サービス開始は2016-17年位か。
補足: GPS Wolrdの記事。打上ビデオも。この記事では、最終構成は24+6機とあり、上記と食い違っている。(10:14追記)
...................................................................................................................................
GPS World, ESA Discusses Satellite Power Loss, Upcoming Launch, August 20, 2014
Galileo FOC衛星1,2号機の打上は天候が悪くて明日に延期になった様だが、7月に発生したGalileo IOV4号機 (E20) 障害についての続報が出ている。この記事によると、原因はまだ調査中だが、復旧したのはE1のみでE5, E6はダメな様だ。なおE1も現在は非標準試験コードで送信されている。また、IOV2号機で1年前に2dBの信号電力低下が発生しており、1号機でも同様の電力低下が観測されている。1号機については主固体電力増幅器の問題であり、バックアップへの切り替えが計画されている。
なんかInsideGNSSの記事では、これらは冗長系を持たないのでほぼ復旧手段はない、とあったはずでかなり情報が錯綜している。
-------------------------------------
IAC, According to GLONASS System Control Center between 13:00 on 18 August 2014 and 01:00 on 19 August 2014 activities aimed at updating GLONASS Time, August 18, 2014
GLONASSから放送されているGLONASST-UTC (SU) 時刻オフセットの高精度化のため、GLONASSシステム制御センタの更新が行われた様だ。IGSのGNAVで確認してみると、
2014 8 16 0.178813934326D-06 CORR TO SYSTEM TIME 2014 8 17 0.178813934326D-06 CORR TO SYSTEM TIME 2014 8 18 0.178813934326D-06 CORR TO SYSTEM TIME 2014 8 19 0.394880771637D-06 CORR TO SYSTEM TIME 2014 8 20 0.394880771637D-06 CORR TO SYSTEM TIME
とUTCパラメータ (-TauC) の値が8/18と8/19の間で220nsも飛んでいることが分かる。GLONASSで放送されているUTCパラメータの矛盾については5/28に書いたが、どうもこれが解消されたようだ。すなわち、Circular-TでいうUTC(SU)_GLONASS = GLONASS Timeに改められた様に見える。
...................................................................................................................................
__builtin_popcount() 使うとportableにならないのとテーブルサイズも考慮して、最終的にはRTKLIBには8bitテーブルバージョンを組み込んだ。こんな速くする必要全くないのだけど。
...................................................................................................................................
__builtin_popcountll() で64bitのpopcountを計算できるらしいのでこれを使ってみた。(Corei7 2600K, gcc 4.7.3, -march=corei7 -O3)。 コードはこちら。さすがにこれが限界か。
table8 : time= 1.834 s table16: time= 1.460 s popcnt : time= 1.138 s popcntl: time= 0.920 s
-------------------------------------
gccのコンパイルオプションで-march=corei7と付けると__builtin_popcount() でSSEを使ってくれることが分かった。あと16bitテーブルバージョンも書いたので計測。(Core i7 2600K, gcc 4.7.3, -march=corei7 -O3)。コードはこちら。
table8 : time= 1.841 s table16: time= 1.460 s popcnt : time= 1.138 s
-------------------------------------
__builtin_popcount() 使ったコードも書いてみた。1億回ループの実行時間。(Core i7 2600K, gcc 4.7.3, -O3)。1回当たり0.19 μ秒しかかかっていないことになるけどホントかね。
table : time= 1.924 s popcnt : time=12.961 s
-------------------------------------
結構苦労して、GLONASS用ハミングコードの計算ルーチン書いたのでせっかくなので公開。これだけで半日はかかっている。これは、次のパッチでrtklib/src/rcvraw.cに追加。多分、以下みたいなテーブル引きで実装するのが最速だと思うのだけど。CPUによっては立ってるビットの数を数える特別命令があるので、これでアセンブラ化すればもっと速くなると思う。
extern int test_glostr(const unsigned char *buff)
{
static const unsigned char xor_bits[256]={ /* xor of bits in byte */
0,1,1,0,1,0,0,1,1,0,0,1,0,1,1,0,1,0,0,1,0,1,1,0,0,1,1,0,1,0,0,1,
1,0,0,1,0,1,1,0,0,1,1,0,1,0,0,1,0,1,1,0,1,0,0,1,1,0,0,1,0,1,1,0,
1,0,0,1,0,1,1,0,0,1,1,0,1,0,0,1,0,1,1,0,1,0,0,1,1,0,0,1,0,1,1,0,
0,1,1,0,1,0,0,1,1,0,0,1,0,1,1,0,1,0,0,1,0,1,1,0,0,1,1,0,1,0,0,1,
1,0,0,1,0,1,1,0,0,1,1,0,1,0,0,1,0,1,1,0,1,0,0,1,1,0,0,1,0,1,1,0,
0,1,1,0,1,0,0,1,1,0,0,1,0,1,1,0,1,0,0,1,0,1,1,0,0,1,1,0,1,0,0,1,
0,1,1,0,1,0,0,1,1,0,0,1,0,1,1,0,1,0,0,1,0,1,1,0,0,1,1,0,1,0,0,1,
1,0,0,1,0,1,1,0,0,1,1,0,1,0,0,1,0,1,1,0,1,0,0,1,1,0,0,1,0,1,1,0
};
static const unsigned char mask[8][11]={ /* mask for hamming codes */
{0x55,0x55,0x5A,0xAA,0xAA,0xAA,0xB5,0x55,0x6A,0xD8,0x08},
{0x66,0x66,0x6C,0xCC,0xCC,0xCC,0xD9,0x99,0xB3,0x68,0x10},
{0x87,0x87,0x8F,0x0F,0x0F,0x0F,0x1E,0x1E,0x3C,0x70,0x20},
{0x07,0xF8,0x0F,0xF0,0x0F,0xF0,0x1F,0xE0,0x3F,0x80,0x40},
{0xF8,0x00,0x0F,0xFF,0xF0,0x00,0x1F,0xFF,0xC0,0x00,0x80},
{0x00,0x00,0x0F,0xFF,0xFF,0xFF,0xE0,0x00,0x00,0x01,0x00},
{0xFF,0xFF,0xF0,0x00,0x00,0x00,0x00,0x00,0x00,0x02,0x00},
{0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xF8}
};
unsigned char cs=0; /* checksum */
int i,j;
for (i=0;i<8;i++) {
for (j=0;j<11;j++) {
cs^=xor_bits[buff[j]&mask[i][j]];
}
if (cs) return 0;
}
return 1;
}
補足: 立っているビットを数えるアルゴリズムは良く出てくる。例えばこれでは各種アルゴリズムの速度を比較しているが、やはり普通にはテーブル引きが最速。ただ、SSE4.2以降のPOPCNT命令を使うとテーブル引きより倍くらい速くなる様だ。(12:29追記)
再補足: gccだとunsigned longを引数にした__builtin_popcount() という標準関数があるらしい。ライブラリの実装がどうなっているか分からないが、内部でPOPCNT命令使っているとするとこれ使う方が速いかも。(12:47追記)
再々補足: コードをもっと簡単にできることに気付いたので差し替え。SSEを使わないコードでは多分これが最速。(14:43追記)
再々々補足: GLONASS-ICDを良く読むと、"a string is considered correct if all checksums (C1,...,C7, and CΣ) are equal to zero, or if only one of the checksums (C1,...,C7) is equal to 1 but CΣ = 1" (4.7(a)) とのこと。以上のコードでは正常データを捨ててしまう場合があるので修正。(8/17追記)
-------------------------------------
一応u-blox NEO-7Nも来たのでTRK-TRKD5のサポートも追加。TRK-SFRBXはM8Nと互換性がある様でそのまま動いた。ただ、GPS/QZSS/SBASとGLONASSが排他利用らしく今さら買う意味はない。M8NでGLONASSかBeiDouのRTKがちゃんと動いてほしいんだけど、今のところ無理そうだなあ。補正方法が見つかれば良いのだけど。
-------------------------------------
NovAtel, Limited Time Offer NovAtel CORRECT with TerraStar
TerraStarのプロモーションやっている。OEMV以前のNovAtel受信機を$4995で1年間のTerraStar利用権付きのFlexPak6とアンテナに取り替えてくれるみたい。OEM6の場合は申し込めば無料で1年間TerraStar使える様。9月末まで。これ日本でも申し込めるのかな。
補足: InmarsatのL-bandはOEM6自体で受かるはずだけど、後ろにLの付いたL-band対応のアンテナが必要のはず。インターネット経由でも使えるなら申し込んでみたいのだけど。なお、TerraStar-Dは海岸線から5 km以上沖合の海上では使えない模様。これはVeriposのApexおよびApex2 とサービスが被るかららしい。多分、受信機F/Wでサービスエリア地図を持っていてエリア外では機能を無効にしているのではないか。なお、StarFireは海上でも使えるけど、海上は陸上とは料金体系が異なる (海上の方が圧倒的に高い)。これは陸上では競合サービスが多いけど、海上では高精度測位のほぼ唯一の手段だという、事業上の判断だと思う。インマルのトラポン借りたり、グローバルな基準局網を運用するのにコストがかかるのは分かるけど、今のところ特に海上では高すぎてなかなか一般利用するには厳しい。将来的に価格破壊が起こるか否かは、前から書いている様にキラーアプリが現れるかどうかにかかっている。(6:02追記)
...................................................................................................................................
GLONASSフレーム欠落時に、複数フレームにまたがる航法データの整合性をどう確保するかも頭の痛い問題。航法データの内容には整合性をチェックできる情報はない。良く調べるとTRK-SFRBX中にsuperframe noを出力していることが分かったのでこの切り替えを見てバッファをクリアする様に修正。これでやっと異常エフェメリスを出力しなくなった。
補足: スーパーフレーム内でエフェメリス切り替えが起こらないというのは3日分位のデータを見る限りは正しいけど、ICDには書いてないので将来にわたって大丈夫かは不明。ただ他に方法無いので。(8/15追記)
-------------------------------------
ubloxのTRK-SFRBXに入っているGLONASS航法データなんだけど受信機F/Wではやっぱりチェックサム計算してくれないみたいで、航法データのビット化けをかなり拾ってしまう。ということでチェックサム計算を追加。ハミングコードなんで1bit誤り訂正可能なんだけど面倒なので訂正はなし。
...................................................................................................................................
次に搬送波位相残差。R11基準。うーん衛星間で位相基準がバラバラに見える。これじゃダメっぽいけど。
-------------------------------------
まずはGLONASSの疑似距離残差をFrequency Number横軸でプロット。データは2時間半。これ同一機種間なので高級受信機ではほぼ0になるはずだけど、NVS等の安い受信機では群遅延周波数特性の個体差が出る。問題は時間安定しているかどうかで、不安定ならアウト。2時間半の間では安定している様に見えるけど。
-------------------------------------
2台目のu-blox NEO-M8Nがやっと届いたので、ゼロ基線、u-blox対抗でのRTKテスト。信号レベルが低いのはアンテナがAntcomだから。GLONASSもBeiDouもやはりアンビギュイティが解けない。GLONASSはコードも位相も結構シフトしているのだけどこれはチップの個体差? 再起動で変化しないなら事前校正でなんとかFIXまでもっていけるのだけど。あと、SBASは1/2位相シフトが残っていることがあることが分かった。まあ、SBAS使わないのだけど。
...................................................................................................................................
Arianspace, Galileo's initial two Full Operational Capability satellites are fueled for launch on Arianspace's medium-lift Solyz, August 7, 2014
ということで、Galileo FOC 1,2号機なんだけど、予定通り8/21に打ち上がりそう。IOV衛星の写真と見比べるとアンテナ形状や機器配置が微妙に異なる。ちなみに、IOV衛星はAstrum GmbH及びThales Alenia Space製、FOC衛星はOHB SystemおよびSSTL (Surrey Satellite Technology Limited) 製と製造メーカが異なる。従って、FOC衛星は太陽輻射圧パラメータを決め直す必要がありそう。
...................................................................................................................................
GPS World, Galileo's Troubled E20 Satellite is Alive, August 7, 2014
おお。生きていたんだ。生きていてくれたんだ (涙)。
...................................................................................................................................
以前の情報では新しく上がったGPS Block IIF 7号機はPRN03だったはずだが、PRN09に代わったようだ。以前はなかったと思うのだけど、UNBによるGPSとGLONASSの衛星コンステレーションの最新ステータスがアップされている。PRN, SVN, Kosmos Number, NORAD ID, International Designatorの対応関係が一覧できるリストは他にないので貴重。なお、IACによると、6/14に打ち上がったGLONASS-M R21は8/3に運用開始した様だ。
...................................................................................................................................
NASASpaceFlight.com, ULA Atlas V successfully launches GPS IIF-7 satellite, August 1, 2014
2014/08/01 03:23 UTC, GPS Block IIF 7号機,
米国ケープカナベラル空軍基地より, Atlas V
ロケットで打ち上げ成功。衛星番号はSVN68/PRN03PRN09 (8/4修正)。衛星はプレーンFスロット3に投入され、GPS
IIR-2衛星 (SVN43/PRN13) を置き換える。SVN43はF3からF2Fに移動され、GPS
IIA (II-14) 衛星 (SVN26/PRN26) を置き換える。またBlock
IIA (II-25) 衛星 (SVN33/PRN03) は運用停止される。次のGPS
Block IIF 8号機の打ち上げは10月中旬に予定されている。
-------------------------------------
I Fernandez-Hernandez et al., The Galileo Commercial Service: Current Status and Prospects, Coordinates, 2014
Galileo CSについて現時点で技術的によくまとまった解説論文。これによると、E6BとE6Cの変調はBPSK(5) でE6Cがパイロット、E6Bがデータ。E6Bは1000spsで1/2 convolutional codeによるFECが入る。sync、CRC、page typeを除くとデータレートは448bps。主なサービスは高精度と認証。高精度はPPPでcm精度。商用PPPサービスに比較した長所は高緯度地域での可視性。認証は拡散コード及びデータ両者の暗号化により提供される。CSの早期実証プロジェクトはEPOC (early proof-of-concept) と呼ばれ2014年末または2015年初めまでに実施される。GSAによる市場調査では1500万の潜在利用者と120Mユーロ/年 (166億円/年) の売上が見込まれている。
論文中にあるように、問題はデータ帯域と低レイテンシを実現するための連続的な通信リンクの確保。データ帯域食うのでGPSやGLONASSは対象にしないのかもしれない。通信リンクのためCS専用アップリンク局を追加する可能性もある。CSの最大の問題は予測している程度まで市場規模が育つか否か。受信機もアンテナも最低2周波 (E1+E6 or E5+E6) が必要な訳で、現在の一般受信機並みに安くできるのか。448bpsでPPP性能でるかも疑問だし、基本的に事業としては多分うまく行かないだろう、と予測しておく。
補足: Galileoに比較して、高精度目的ではQZSSはずっと条件が良いことが分かる。広い帯域幅 (L6, 1.7kbps) があり連続的な通信リンク確保も容易。Galileoと同様に高緯度地方でも使える。問題は受信機だけど、前から書いてる様に大した回路要らないので量産すれば安くできる。GSAの市場調査がホントなら、賭けてみる価値ありそうに見えるけど。(10:27追記)
-------------------------------------
I.Rodriguez et al., Preparing for the Galileo Commercial Service - Proof of Concept and Demonstrtor Development, ION GNSS+ 2014
Galileo CS Demonstratorについて9月のIONで発表があるらしい。もし参加される方がいたら内容教えて頂けるとありがたい。
...................................................................................................................................
InsideGNSS, Galileo Team Reports Successful Tracking of Encrypted Commercail Service Signals, July 19, 2014
Galileo CS (commercial service) の暗号化信号試験がうまく行ったという記事。AALECS (Authentication and Accurate Location Experimentation with the Commercial Service) というプロジェクトで、スペインGMV社が中心となって実験をしているとのこと。
GMVやVeriposの名前が入っているので、CSでPPPライクなサービスを考えている様にも見えるけど詳細は良く分からない。Navipedia見ても内容あんまり書いてないし。E6B, E6Cの2chの暗号化チャネルを使うこと、データレートは500bpsであること、くらいしか公式情報はない。まだ、決まっていないだけなのかもしれないが。ただ今のところ、これら事業化がうまく行きそうな気はあんまりしない。
-------------------------------------
SpaceFlightNow, Atlas 5 rocket to fly Friday night with GPS satellite, July 20, 2014
もうすぐGPS Block IIF 7号機の打上なんだけど、BoeingのYoutubeビデオがカッコいいので貼っておく。
補足: 良く見ると、軌道上衛星のCG、日の当たり方が変だなあ。通常、太陽電池に垂直に太陽光線が当たる様に姿勢制御されるので、太陽電池に衛星ボディの影が落ちることはない。最近この辺のモデル改良をずっとしているので、細かいことだけど結構気になるのである。(8/2追記)
...................................................................................................................................
| Home | by T.Takasu |
