2010/11/01〜

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

2010/10/31

Nvidia GeForce GTX470カード購入 (\24,800也)。目的は察しの通り。これから寒くなるので暖房用も兼ねている。今のところGeForce GTX480が最高峰の様だが470も480の8割位の性能はある様。とりあえずCUDA Toolkit入れてcuFFTの性能を測る。

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

RTKLIB: SDR (Software Defined Radio) Receiver Module
SDR関係の情報はここに集めることにした。まだリンクぐらいしか情報がないが、今後進捗に応じて追加していく。

補足: ソフト相関器性能を追加。今のコードで概ね350Msps位。Panyの今年のIONの論文で、IFENのSX-NSRのtracking capabilityが20MHz 20CH/coreと書いてあるので (使っているCPUは不明)、近いところまでは来た。あと性能を上げるためには何があるかなあ。(17:10追記)

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

2010/10/30

www.beidou.cov.cn

明日か明後日、Compass衛星6号機が打ち上げられる様だ。Google翻訳。

> 中国は第六Beidou航法衛星を起動します
> 公開:2010 - 10?29
> 情報は、本ウェブサイト上：新華ファイナンス10月29日西昌西昌衛星は、センターの関係者を起動し、
> 中国はすぐに、"長征三C"のキャリアは、第六Beidouナビゲーション衛星が打ち上げ選択するにはここ
> を使用されることを発表した。

他のサイトの情報では打ち上げは10/31でGEO衛星らしい。これで打ち上げ順はMGGGIGとなる。10/25に書いたように、2012年までにG×5+I×5+M×2の構成なので概ね構築日程は順調と言える (2機目のGEOは使えるのかどうか良く分からないが)。

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

2010/10/29

M.Barachi-Frei et al., Real-Time GNSS Software Receiver: Challenges, Staus, and Perspectives, ENCGNSS 2009, Naples, 2009
リアルタイムソフト受信機の現状技術についてコンパクトにまとまっている。ソフト受信機の信号処理にSIMD演算を使うなんて誰でもすぐ考えそうな気がするのだが、結構論文になっている様だ。

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

T.Takasu, Development of Real-Time PPP Client for Precise Satellite Orbit and Clock Corrections via NTRIP, International Symposium on GPS/GNSS 2010, Taipei, Taiwan
IS-GPS/GNSS-2010の発表資料をup。paperは色々あって結局10/15の〆切に間に合わず。

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

IS-GPS/GNSS-2010から帰還。
最終的に参加者は200名前後だったと聞いた。 2日目は講演キャンセルが多かったし今ひとつ盛り上がりに欠けた大会であった。 来年はシドニー、再来年は北京とのこと。 昨年のJejuでも今年のIONでも思ったけれど、新しいGNSSが次々と登場しようとしているし、 テーマはまだ色々と残っているのに、誰かがずいぶん前にやったことをなぞっただけという研究が多い。 特に若い人には、粗削りでも全く新しい観点での研究を期待したい。 聞いた話ではTeunissenが私の発表を褒めてくれていたらしいのでその点は少し嬉しい。

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

2010/10/27

いつも書いているように酷い英語だなあと思いながらとりあえず発表終了。 後は、セッションを渡り歩いて色々と聞いたけどピンとくる発表はほとんどなかった。 ちょっとソフト受信機に関して新しい情報仕入れて帰りたいのだけど明日は面白い発表聞けるだろうか。

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

昨日聞いたplenaryとprogram statusについて少しメモ。

(1) G.Heinの発表でGaliloの18衛星限定サービス開始"2014/15"年、30衛星全サービス開始"2016/17"年となっていた。 IONでのGalileoの発表資料を確認してみたら、それぞれ2014年、2016年となっていたので、ここ1ヶ月で既に半年(?)延びたことになる。 この世界の常識として日程が早まることはないので、今の時点でサービス開始が2015年以降になることは間違いない。 本当に計画通り行くの? という質問もあって、ムニャムニャと答えていたが、 感触としては、初期サービス(18機)はなんとか計画通り進めようと努力しているが、 全サービス(30機)はまだ目途が立っていない、という感じで最悪サービス開始が遅れた上で18機体制のまま運用を続ける可能性もある。

(2) 今まで知らなかったのだけど、インドがGINS (Global Indian Naivagation System) という、 globalな測位衛星システムを検討してるらしい。 "GINS india GNSS"で検索するといくつか資料が引っかかるが、24機体制で検討している様。

(3) SBASの将来について。L5追加の話。ロシアSDMSの追加や南半球でのRIMS (ranging and integrity monitoring station) の追加で将来的にはカバレッジがほぼ全世界に広がるとのこと。

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

2010/10/26

OSQZSS: オープンソース準天頂衛星(QZSS)受信機

QZSSの信号を手作り受信機で受信しようとしている方がおられることを教えてもらいました。情報感謝。 中の人が誰かは知っているわけですが、特に公開していない様なのでここには書きません。 このサイトの情報によると既にQZSSは試験用信号を非標準コードで送信開始しているとのこと。 せっかくソフト受信機の開発始めたので、こっちでも受けてみたいなあ。

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

IS-GPS/GNSS 2010@台北なう。
ホテルが開催場所と一緒なので、レジストだけして部屋に戻って明日の発表準備。 午後からは、plenary、status of GNSS、reception。2-3日目は4×7本のセッションで それぞれ4-5本の発表があるのでポスターを入れて全部で150本位。 参加者は200-300人という所か。昨年のJejuもそうだったが結構こじんまりした シンポジウムである。 台北101の入場券くれたのでせっかくなのでどこかで時間を作って上ってこよう。

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

2010/10/25

China Satellite Navigation Office, BeiDou Navigation Satellite System, 5th meeting of International Committee on GNSS, October 18-22, 2010, Turin Italy
先週イタリアのトリノで行われたICGで発表のあったCompass (BeiDou system) の資料が公開されている。この資料によるとCompassのシステムはphase I (〜2012)、phase II (〜2020)、phase III (2020〜) に分けられ、phase IではGEO×3、phase IIでGEO×5+IGSO×5+MEO×2、phase IIIでGEO×5+IGSO×3+MEO×24(+3 spare)　の構成。信号構成はB1, B2, B3であるが、phase IIIでは他GNSSとの互換性を考慮して、周波数や変調方式が変更になる様だ (OS用にL1C, L5相当の信号が追加になる)。今後の衛星打ち上げは11月に4機目のGEO、12月に2機目のIGSOの予定。ICDについては触れていないのでまだ発行されない様だ。

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

2010/10/24

シコシコと最適化。38.2MHzデータ50秒の相関時間5.5秒 (シングルスレッド)。とりあえずこれくらいが限界かな。また暇な時に続けるとして次に進もう。

sampling rate=16.368MHz (64bit)
tau= 1ms: ns=  16368 time=0.054ms rate=304.2Msps
tau= 2ms: ns=  32736 time=0.091ms rate=357.9Msps
tau= 4ms: ns=  65472 time=0.185ms rate=354.2Msps
tau= 8ms: ns= 130944 time=0.368ms rate=355.4Msps
tau=16ms: ns= 261888 time=0.928ms rate=282.3Msps

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

2010/10/19

少し実行時間の中身を解析。原始的に一部だけ残してコメントアウトして実行時間を測る方法でコリレータ内部の実行時間を測ってみる。ということでSSE2命令を使って最適化した部分は殆ど実行時間に差はないが、普通のfor文で回している部分の実行時間が倍くらい違う。これはレジスタのアサインの問題かなあ。
なお、昨日PMADDWD命令を使った積和の実行時間が8サンプルで15クロックと書いてしまったが (これはPanyの本から取ったものでCore 2の結果) 、これを見る限りi7ではずっと速い (8サンプルで4クロック位)。従って普通のfor文で回している部分をアセンブラで書き直せばもう少し速くなるかもしれない。ということでまだ最適化の余地がありそうということが分かったのでとりあえず、この先の最適化は後回し。
コード相関があんまりCPU負荷に効いていないということは、それほどコストをかけずに多点コリレータの実装が可能であるということでもある。とりえずStrobe Correlatiorを入れてみようかなあ。
補足: SSE2命令を使わない場合の実行時間を追加。SSE2利用有無はやはりかなり大きい。(15:37追記)

16.368MHz, tau=2ms, ns=32736
               64bit    32bit
mulcarr()  : 0.062ms  0.117ms 
gencode()  : 0.056ms  0.117ms
dot_int16(): 0.031ms  0.030ms
dot_int16(): 0.138ms  0.234ms (NO SSE2)

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

下に書いた結果は、コンパイラはVS 2008でかつ64bitモードでのコンパイル結果である。32bitモードだと以下の様に何故か性能が半分くらいに落ちてしまう。メモリ帯域か実行環境の問題かな。(OSはWindows 7 64bit)

sampling rate=16.368MHz (32bit)
tau= 1ms: ns=  16368 time=0.140ms rate=116.7Msps
tau= 2ms: ns=  32736 time=0.286ms rate=114.4Msps
tau= 4ms: ns=  65472 time=0.570ms rate=114.8Msps
tau= 8ms: ns= 130944 time=1.264ms rate=103.6Msps
tau=16ms: ns= 261888 time=2.620ms rate=100.0Msps

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

昨日貼ったコリレータのコードをもう少し最適化して実行時間をちゃんと測ってみた。サンプリング周波数を38, 16, 8MHz、積分時間を1, 2, 4, 8, 16msに変えて実行した結果。CPUはi7 930 2.8GHz、シングルスレッドである。これを見る限り4コアを使えば一般的な16MHzサンプリングで40chはいけそうである。

sampling rate=38.192MHz
tau= 1ms: ns=  38192 time=0.174ms rate=219.0Msps
tau= 2ms: ns=  76384 time=0.356ms rate=214.3Msps
tau= 4ms: ns= 152768 time=0.712ms rate=214.4Msps
tau= 8ms: ns= 305536 time=1.476ms rate=207.0Msps
tau=16ms: ns= 611072 time=3.611ms rate=169.2Msps
sampling rate=16.368MHz
tau= 1ms: ns=  16368 time=0.083ms rate=197.0Msps
tau= 2ms: ns=  32736 time=0.150ms rate=218.7Msps
tau= 4ms: ns=  65472 time=0.305ms rate=214.7Msps
tau= 8ms: ns= 130944 time=0.608ms rate=215.4Msps
tau=16ms: ns= 261888 time=1.238ms rate=211.5Msps
sampling rate=8.184MHz
tau= 1ms: ns=   8184 time=0.042ms rate=194.5Msps
tau= 2ms: ns=  16368 time=0.083ms rate=197.9Msps
tau= 4ms: ns=  32736 time=0.150ms rate=218.4Msps
tau= 8ms: ns=  65472 time=0.304ms rate=215.2Msps
tau=16ms: ns= 130944 time=0.610ms rate=214.8Msps

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

2010/10/18

昨日書いたソフト受信機の件、リアルタイム対応の鍵はコリレータの性能である。40MHzサンプル16CHの受信機であれば、1秒間に640M回の2 (I, Q) サンプル-キャリア乗算 + 6 (I_P, I_E, I_L, Q_P, Q_E, Q_L) コード積和を実行する必要がある。これは最新のCPUでもかなり厳しい。後者の積和演算は、SSE2でサポートされるPMADDWD命令 (128bitパックされた16bit整数の積和) を使うと、8サンプルを約15クロックで処理できる。2.8GHz 4コアCPUであれば、2.8GHz×8/15/6回×4=1Gs/s。キャリア乗算やキャリアやコードのリサンプリングを入れると入るか入らないかギリギリというところである。多分ソフト受信機を開発されている方には参考になると思うので、かなり最適化した現在のコリレータのソースを公開する (correlator.zip)。このコードで38.2MHzサンプル50秒分のコリレータ実行時間が9秒弱、SSE2を使わない場合だと約15秒かかっている (i7 930 2.8GHzシングルスレッド)。来春にも出荷されると言われているIntelの次世代CPUではSSEレジスタ幅が256bitに拡張されるので、ここはすいぶんと余裕ができると思うが、CPU-メモリの帯域幅も結構厳しいのでリアルタイムで実用的な性能を出すのにはかなりのチューニングが必要になると思う。
以上は信号追尾だけに的を絞っているが、信号捕捉に使うFFT性能も重要であり高速捕捉にはGPUが欲しくなる (GPUのFFTはCPUの数倍は速いらしい)。ただ通常は小型低消費電力のLSIで実現できている処理を、電力馬鹿食いのGPUで実行するのは、なにか他のメリットがなければ技術開発として意味有るのかなあとは思う (ソフト受信機そのものも既存の受信機をそのまま実装するだけであれば技術開発の意味はない。何らかの付加価値が必要である)。

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

2010/10/17

隠す必要もないので、ここ1週間位でスクラッチから実装したプロトタイプソフト受信機画面を貼っておく。
本体はMatlab、コリレータやコード/搬送波生成だけC-MEX。最初コリレータの性能が全然でなかったのだが結構頑張ってチューニングした。データはBorreの本のDVDに入っていたもの。ビットシンク、フレームシンクはまだ。これは動作確認/性能評価用のプロトタイプなので、最終的には本体はCで書き直す予定。FFTはFFTWかIntel IPPを使う。RFフロントエンドは、とりあえずSparkFunで手に入れて眠っているSiGe4120ベースのサンプラーを使う。これはドライバソースが公開されているのでリアルタイム用に改修して使う。最終的にはMAXIM2769×2+IMU+OCXOのGPS/GLONASS/Galileo/QZSS対応RFフロントエンドを開発したいのだが、これは何時になることやら。やりたいのはINS-Aided PLLを使ったRTKなのだが、出来てしまえばそれ以外にも色々と使えるかも。
ソフト受信機そのものの実装は思ったより簡単なのだけど、CPUのメモリ転送帯域が性能をリミットするのでリアルタイムで実用的な性能を出すには色々な妥協が必要になると思う。信号処理ソフトって初めて書いたのだが、新しいことが出来る様になるという点で実装そのものはとても楽しい。今までなかなか理解できなかったGNSS受信機の動作原理が、実際に実装してみるとすっきり分かる、という点もなかなか楽しい。

補足: 分かる人は分かると思うがRFフロントエンドにIMUとOCXOをつけるのはINS-Aided PLLの実装のため。いわゆるdeeply-coupled integrationで、搬送波追尾性能を上げて都市部移動体におけるRTK性能を上げたいというのが第一の目的。あと、ソフト受信機化の目的は出来るだけ早く新しい衛星を使うことと、VDLLやPLL帯域幅の動的制御で移動体の測位性能を上げること。多点コリレータでマルチパス低減というのも面白いテーマであるが、相関点数を増やすのはCPU負荷に直接影響するので、次世代CPUが出てからかなあ。(10/18追記)

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

SSE2の128bitパック整数積和演算を使った16bit整数ベクトルの内積ルーチン。VSの64bit版はインラインアセンブラが使えないことが分かったので、イントリンシック命令を使っている。これで、38.2MHz 50秒信号の相関処理時間が9秒を切ったので、4コアマルチスレッドでなんとか16CHまでいけるかなあという感じ。8MHzなら楽勝だろう。と書けば何をやっているか分かる人は分かるはず。
なお、a, bは16B境界にアラインしている必要はないが、末尾は16B単位のゼロ詰めが必要。

#include <emmintrin.h>

/* dot product of int16 vectors ---------------------------------------------*/
static int dot_int16(const short *a, const short *b, int n)
{
    const short *p=a,*q=b;
    int sum[4];
    __m128i x,y,z;
    
    z=_mm_setzero_si128();
    
    for (;p<a+n;p+=8,q+=8) {
        x=_mm_loadu_si128((__m128i *)p);
        y=_mm_loadu_si128((__m128i *)q);
        x=_mm_madd_epi16(x,y);
        z=_mm_add_epi32(z,x);
    }
    _mm_storeu_si128((void *)sum,z);
    
    return sum[0]+sum[1]+sum[2]+sum[3];
}

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

2010/10/13

C.Shi et al., Seismic deformation of the Mw 8.0 Wenchuan earthquake from high-rate GPS observations, Advances in Space Research, 2010
1HzキネマティックPPPで、2008/5/12の四川地震を解析した事例。解析ソフトはPANDA、暦はCODE、MFはVMF1、sidereal-filterを適用し、ネットワークモードでambiguityを解いている。精度は水平RMS 1cm以下でambiguityを解くことが精度に大きく寄与しているとしている。ただやっぱり垂直解は精度が出てない様でちょっと本文で触れただけでグラフを示していない。
キネマティックPPPによる地震波の解析は少しずつ改良されているとは言えるが、現在のところ実用的かと言われるとちょっとどうなのかなといった感じである。

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

2010/10/12

9/2に打ち上げられたGLONASS-M-738 (R16) の信号を確認。まだunhealthyなR12も一時的に受かっている。現在日本で利用可能なGNSS衛星数の合計はGPS×31+GLONASS×21+MSAS×2。利用できない衛星はG01,R03,R04,R06 (G01はSVN49、R04とR06はメンテ)。15度マスクでの衛星数とDOPも貼っておく。これにGLONASS×3+QZSS×3+Galileo×27+Compass×35が追加されると30〜50衛星が同時利用可能になる。

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

2010/10/11

TechCrunch, Google has a secret fleet of automated Toyota Priuses; 140,000 miles logged so far, October 9, 2010
Googleの自動車自律走行プロジェクトで、プリウスの改造車を含む7台の車が人間の補助なしに既に1,000マイルの自動走行を実現したとのこと。センサはカメラ、レーダ、レーザレンジファインダ、GPS、IMUで、当然、Googleが収集した多量の地図情報を使っている。GoogleはこのプロジェクトのためにDARPAチャレンジから最優秀のエンジニアを集めたとのこと。ただ最も楽観的な予測でも実用化まで8年かかるとしている。

補足: このGoogleの例の様に、10年後位を見越すと、マルチGNSS/RTKベースの精密測位+マルチセンサ統合による航法システム、というのが色々な応用領域で一般的になって行くのではないか。GNSSベースの航法システムで一番問題になる信頼性・可用性も、定性的にはまだ改善されるし、コストはユーザ数が増えれば劇的に下がる。ただ、普及するかどうかはキラーアプリケーションが現われるかどうかにかかっている。これに対して悲観的な意見も聞くが、まあこれは予測してもしかたないので、まずは要素技術開発と普及活動が大事だろうとは思っている。(10/12追記)

NewYork Timesの記事。写真を見るとGPSはTopcon。(10/12追記)

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

MAXIM, MAX2769 Universal GPS Receiver
ちょっとソフト受信機の情報を集めていて見つけたので貼っておく。GLONASSのL1帯域に対応したRFフロントエンドIC。ミックスする周波数やフィルタ帯域幅を変更できるので、ほとんど外付け部品なしでGPS/GLONASS/Galileo対応の受信機フロントエンドが構成できる。Galileoがまた遅れそうで、当面はGLONASSの価値が相対的に大きくなりそうなので、これ使ってGLONASS対応のソフト受信機作ってみたいなあ。なおGPSとGLONASSのL1は中心周波数が25MHzも離れているのでGPS/GLONASSを同時受信するには1つでは帯域が足らない。従って両対応受信機にはこのICが2つ必要である。

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

2010/10/09

G.Petit and B.Luzum eds., IERS Technical Note No.36, IERS Conventions (2010), 2010
IERS Conventions 2010のほぼ最終稿。10/18までエディトリアルなチェックをして確定するとのこと。

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

2010/10/08

GLONASS-M-722の件、IACに問い合わせメールを送ったら回答があった。結論として一時的な試験用にAlmanacのスロット3を使っているだけで、軌道位置を動かした訳ではない様だ。ということで、プレーンI のスロット3は12月のGLONASS-Mトリオ打ち上げで埋められることになり、これでFOC完成となる。

>> According to the information by NAGU:
>> 058-101004
>> NOTICE ADVISORY TO GLONASS USERS (NAGU) 058-101004
>> SUBJ: SLOT CHANGING SV 722
>> 1.CONDITION: 01.10.10 SV 722 HAD BEEN MOVED FROM SLOT 9
>> TO SLOT 3
>> 2.USERS ARE REMINDED TO UPDATE ALMANACS IF NECESSARY
>>
>> GLONASS-M-722 has been moved to slot 3 in plane I on 2010-
>> 10-01. But the latest Almanac shows the GLONASS-M-722 is still in plane
>> II near slot 9. But the slot 9 is already filled with a newly
>> launched GLONASS-M-736.
>> The NAGU has just a mistake or "slot 3" is placed in plane II instead of
>> plane I ?
>> I am confused by the NAGU. I appreciate further information for the
>> GLONASS-M-722 orbit position.

> SV "Glonass-M-722" had been designated as that in orbital slot 3 in the
> almanac only. You can see for the other details our web-page also:
>
> http://www.glonass-iac.ru/pls/htmldb/f?p=202:1:8188634331380300

補足: NAGU 058-101004 の文言が以下の様に変更になっている。(10/9追記)

058-101004
NOTICE ADVISORY TO GLONASS USERS (NAGU) 058-101004
SUBJ: SLOT CHANGING SV 722
1.CONDITION: 01.10.10 SV 722 HAD BEEN DESIGNED AS THAT
IN SLOT 3 IN THE ALMANAC.
2.USERS ARE REMINDED TO UPDATE ALMANACS IF NECESSARY

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

ちょっとくどいが、まだ納得いかないのでGLONASS-M-722の軌道の件。2010/10/7現在のGLONASS Almanacは以下の通り (参照)。今後の変動を追うために現在値を貼っておく。

これを基に衛星軌道位置をプロットすると、

ここで横軸は日先頭におけるの昇交点経度、縦軸は昇交点から軌道に沿って測った角度を表す。左下でR03とR09がほぼ重なっている。やはりGLONASS-M-722 (R03) はまだプレーンII にいることが分かる。ということで、以下のNAGU058-101004は間違っているか、"SLOT 3" の定義を変えたかどちらかということになる。(メンテ中の衛星のAlmanacは値が保証されないのだろうから、ホントはプレーンI に移動しているという可能性も全く無いわけではないが、以下書いたようにプレーン間の移動は現実的には無理だと考えられる。GLONASS-M-722は、多分このままR09のスペアとして今の軌道位置を維持するのではないか。)

058-101004
NOTICE ADVISORY TO GLONASS USERS (NAGU) 058-101004
SUBJ: SLOT CHANGING SV 722
1.CONDITION: 01.10.10 SV 722 HAD BEEN MOVED FROM
SLOT 9 TO SLOT 3
2.USERS ARE REMINDED TO UPDATE ALMANACS IF NECESSARY

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

2010/10/07

GPS daily, EU's Galileo satnav sytem over budget, late: report, October 7, 2010
Galileoのbudget overと遅延について書いている。元ネタはFTD (ドイツ語) の様。現在のところ公式にはGalileoは2014年に18機で限定サービス開始としているが、この記事によると予算超過でこれが2017-18年まで延びる可能性が有るようだ。ということで、Galileoの実際の運用開始までまだ前途多難という感じである。

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

GLONASS-M-722のプレーン間移動について、面内制御で軌道半径変えてJ2使って軌道面回転させればもっと少ないΔVで移動ができるのでは、というご指摘を頂いた。この方法は以前ちょっと考えたのだけど、もう一度ちゃんと考えてみる。

地球重力非球面成分による昇交点赤経の永年摂動は以下で計算できる。

ΔΩ=-3/2*J2*sqrt(μ)*Re²*cos(i)/((1-e²)²*a^3.5)

ここでaは軌道長半径、iが軌道傾斜角、eが離心率である。これにGLONASSの軌道要素を代入すると、

ΔΩ=-0.033 deg/day

となる。すなわち何もしなくても10年位かければ120度軌道面は回転するということである。これではあまりにも時間がかかりすぎるので軌道を下げて軌道面回転を速くするとする。例えば高度1,000 kmの円軌道に下げるとすると、

ΔΩ=-2.548 deg/day

となり2カ月弱で軌道面を120度回転させることができる。ただ高度19,100kmから1,000kmまで軌道を下げるには、ホーマン遷移を使うとして、

ΔV1=-1305 m/s, ΔV2=-1803 m/s

かかる。下げて、回転して、上げる必要があるから、最終的に必要な総ΔV=6216 m/sとなる。遷移軌道の高度を変えて、120度回転に必要な期間と共に表にしてみると、

ということでやっぱりこの方法も現実的ではないようだ。

補足: 以上は慣性系に対しGLONASS軌道面を維持する制御がなされているという前提での計算結果である。多分軌道面回転を許す運用をしていると思うので、軌道高度を変えなければ何時まで経っても別の軌道面には移動できない。ということで現実の軌道では上記よりもう少し条件が悪くなる。(19:43追記)

補足: 最新 (2010/10/7) のNORAD TLEを見ても、まだGLONASS-M-722 (COSMOS 2435) はプレーンIIから動いていないし、高度も変えていない。どうもNAGUがガセの可能性が高い。(21:24追記)

COSMOS 2435 (722)       
1 32394U 07065B   10279.48174878 -.00000062  00000-0  00000+0 0  5382
2 32394  65.2686  27.1789 0003414 119.3015 337.1530  2.13103293 21573

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

2010/10/06

昨日GLONASSのプレーン間衛星移動が難しいのではと書いたが、実際軌道移動にどれくらいΔVが必要になるか考えてみる。GLOASSの軌道要素は軌道傾斜角64.8度、高度19,100kmの円軌道で、全体としては (スペアを除くと) いわゆるWalker constellation 24/3/1を構成している。3プレーンの昇交点は赤道面で120度ずれているから以下の様に、プレーン間角度=43.3度で、プレーン交差点で必要なΔV=2917m/sとなる。衛星質量が1.3t、スラスタ推力が200Nとして加速度は0.15m/s^2だから、5時間以上スラスタを吹き続けなければいけないことになる (正確にはスラスタ比推力を使って推薬質量減を考慮する必要がある)。GLONASS-Mが装備しているスラスタや推薬量の情報が見つからないので細かくは分からないが、ちょっと現実的とは思われない。GLONASS-M-722の軌道制御には魔法でも使ったのだろうか。

re=6378137; mu=3.986005E14; i=64.8*pi/180; h=19100000;
v=(re+h)*sqrt(mu/(re+h)^3);
p1=           Rx(pi/2-i)*[0;0;1];
p2=Rz(2*pi/3)*Rx(pi/2-i)*[0;0;1];
alpha=acos(p1'*p2);
dv=2*v*sin(alpha/2);
disp(sprintf('dv=%.1f m/s alpha=%.1f deg',dv,alpha*180/pi))

function R=Rx(t), R=[1,0,0;0,cos(t),sin(t);0,-sin(t),cos(t)];
function R=Rz(t), R=[cos(t),sin(t),0;-sin(t),cos(t),0;0,0,1];

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

2010/10/05

GLONASS constellation status, Information-Analytical Center, Federal Space Agency Russia
9/2に打ち上げられたGLONASS-M衛星のうち1機 (736) が運用開始。残りの2機 (737, 738) ももうすぐ運用を開始する様だ。複雑な移動を行っている様なのでNAGUから拾っておく。

10/1: 722 (09/-2) unusable from 0:11 MT
10/1: 733 (04/06) unusable from 0:11 MT
10/1: 733 slot/freq ch change (04/06) -> (06/-4)
10/1: 727 slot/freq ch change (03/05) -> (04/06)
10/1: 722 slot/freq ch change (09/-2) -> (03/-5)
10/4: 736 (09/-2) in operation from 07:29 MT

slot 3: 727 -> 722
slot 4: 733 -> 727
slot 6: ??? -> 733
slot 9: 722 -> 736 (新)

これをみるとプレーンII にあった722がプレーンI に移って、プレーンI の衛星の入れ替えで空いていたスロットを埋めた様だ。これが本当なら12月の打ち上げを待たずにFOC完成ということになるが、プレーン間の衛星移動なんてホントに可能なのかね。

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

2010/10/02

杉本, 柴崎編, GPSハンドブック, 朝倉書店, 2010
Amazonで届いた参考書。献本してくれるのかと思ったら筆者増え過ぎで割引購入しろとのことだったので、面倒なのでAmazonで注文、正規価格で購入。沢山知り合いの方が書いているから誉めるという訳ではないのだけど、日本の衛星測位技術の専門家をオールスターで集めて来たとといった感じの専門書である。日本語でこのレベルの技術書を読めるなら専門家の方は買いだとは思う。でも全492頁で\15,750 (税込) はやっぱり高い。\8,000くらいなら学生さんにもお勧めなのだけど。
ざっと読んだが、あまり明るくない後半、特に姿勢計応用、カーナビ応用、気象学応用は大変参考になった。また、付録で立命館久保先生が書かれている単独測位アルゴリズムに関する丁寧な導出も素晴らしい。

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

T.Takasu et al., Kalman-filter-based integer ambiguity resolution strategy for long-baseline RTK with ionosphere and troposphere estimation, ION GNSS 2010
ION 論文完。1日で終わらせるつもりが、やっぱり完徹を含めて丸二日かかった。提出が10/1 24:01 EDT。〆切を1分オーバーしたけどメールで送ったので多分受け付けてくれるのではないかと思う。いい加減にこういう、じでんしゃ (なぜかへんかんできない) 操業はやめにしないといけない。

補足: 見直していたら細かいミスを結構見つけてしまって反省。まあほとんど読み返す時間がなかったのだから当たり前か。IS-GPS/GNSS 2010の原稿は10/2はあきらめて10/15までに仕上げることにしたので、これはもう少しちゃんと書こう。(18:00追記)

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

〜2010/09/30