SS-520の軌道でfireflyを試す

OpenTsiolkovskyでSS-520観測ロケット4号機の予測軌道が生成できたので，
これからGPS信号シミュレータ用のモーションファイルをつくります．

OpenTsiolkovskyの出力は，各段の軌道に分かれていますが，
全行程をシミュレーションできるよう，1段目から3段目までの軌道を
分離時間ごとに繋げます．

さらに，射点でGPS信号が補足できるよう，発射前の1分間は
初期位置に留まっていることにします．

この予測軌道をss520-4.csvというuser motion fileとして，
リアルタイム版のGPS信号シミュレータであるbladeGPSに入力します．

github.com / osqzss / bladeGPS

gps-sdr-simは，SDRデバイスに入力するI/Q信号のサンプリングデータが
巨大になり，長時間のシミュレーションには向いていませんでした．
しかし，bladeGPSでは，user motion fileの位置情報から，リアルタイムで
I/Q信号を計算するため，データ量を気にすることなく，長時間の連続した
シミュレーションが可能です．

シミュレータから出力されるGPS信号は，firefly GNSS受信機で受信します．



予測軌道の加速度をみてみると，3段目が20Gを超える高ダイナミクス．

　（クリックで拡大）

しかし，fireflyは，ロケット搭載も考慮して，最大25Gの加速度でも
信号を追尾できるように設計しています．シミュレーションの結果も，
打ち上げから一度も信号を失うことなく，測位できています．

　（クリックで拡大）

測位誤差をみてみると，大きな加速度の変化に関係なく，測位精度は
5m以下を維持しています．

　（クリックで拡大）

bladeGPSもfireflyも，控えめに言って最高だ！

OpenTsiolkovskyを試す

OpenTsiolkovskyによるSS-520観測ロケット4号機の軌道予測が
紹介されていたので，自分でも試してみる．

ina111's blog: 衛星打上げロケットSS-520 4号機の予測（妄想）

軌道予測から，bladeGPS（またはgps-sdr-sim）用のモーション
ファイルを生成するのが目的です．

Windows 10なので，OpenTsiolkovskyのwikiを参考にMSYS2をインストール．
しかし，「$ pacman -Su」の途中でこんな警告が出て，止まってしまいます．

　（クリックで拡大）

警告メッセージにしたがって，一旦terminalを閉じてから，
スタートメニューのショートカットを編集．

Qiita: MSYS2の更新に伴う起動用ショートカットの修正

再度「MinGW-w64 Win64 Shell」を起動して，
パッケージのアップデートとインストールを進めます．

その後，OpenTsiolkovskyをcloneしてmake．
binフォルダに，「OpenTsiolkovsky.exe」ができました．

SS-520観測ロケット4号機のパラメータをbinフォルダにコピー．

　（クリックで拡大）

OpenTsiolkovskyを実行すると，outputフォルダに予測軌道が
csvファイルで出力されます．

　（クリックで拡大）

続いて，Google Earthで軌道を表示するKMLファイルを生成するために，
pythonや関連ツールをインストール．

$ pacman -Sy mingw-w64-x86_64-python2-pip
$ pacman -Sy mingw-w64-x86_64-python2-numpy

KMLファイルの生成に必要なsimplekmlモジュールもインストールします．

$ pip install simplekml

これでKMLファイルを生成する準備が整いました．

　（クリックで拡大）

KMLファイルもoutputフォルダに出力されます．
Google Earthで開くと，それらしい軌道が！

　（クリックで拡大）

グリグリ廻して眺めると，とても楽しいです．
動作も確認できたので，次はモーションファイルをつくろう．

複数のu-blox受信機を同時接続

やっと重い腰を上げてWindows 10にアップグレードしたら，
u-bloxのNEO-M8T受信機が接続できなくなる不具合発生．

これまでCOMポートとして認識されていたに，なにやら
u-blox GNSS Location Sensorというデバイスになってしまう．
もちろんu-centerにも繋がらない．

　（クリックで拡大）

Google先生に質問しても，解決法が見つからずハマる…

高須さんの方法だと，一旦はCOMポートになるものの，
再接続するとGNSS Location Sensorに上書きされてしまう．
また，複数の受信機を接続した場合，COMポートに変更
できるのは，ひとつだけだ．

日記・備考録：2016/01/30

試行錯誤のすえ，なんとか解決したのでメモ．

まず，GNSS Location Sensorデバイスを右クリックして，
「ドライバーソフトウェアの更新」を選択．

　（クリックで拡大）

「コンピュータを参照してドライバーソフトウェアを検索」を選択．

　（クリックで拡大）

「コンピュータ上のデバイスドライバーの一覧から選択」をクリック．

　（クリックで拡大）

ここで，u-bloxが提供するドライバではなく，Microsoft標準の
「USBシリアルデバイス」を選択します．

　（クリックで拡大）

これで，ドライバの更新が完了．

　（クリックで拡大）

デバイスの一覧には，COMポートとして認識されるようになりました．

　（クリックで拡大）

複数の受信機を接続したときも，同じことを繰り返すことで，
同時接続もできるようになります．

　（クリックで拡大）

u-centerからも，問題なく接続できます！



ちなみに，COMポートの番号は，個々の受信機ではなく，
USBのポートに割り振られるみたい．

【追記】他のWindows 10 PCで試してみたら，u-blox Virtual COM Port
としても認識され，u-centerと接続することができました．

しかし，こちらも複数台の受信機を接続すると，GNSS Location Sensor
だけが認識されるだけで，Virtual COM Portは増えません．

　（クリックで拡大）

ドライバーソフトウェアの更新後，u-blox Virtual COM Portは削除
しておきます．

　（クリックで拡大）

「このデバイスのドライバーソフトウェアを削除する」を選択して削除．

　（クリックして拡大）

【追記2】ドライバーソフトウェアを削除したはずのu-blox Virtual COM Portが
COM6として復活していた．これを消すと，次はCOM7として復活する．
このままではCOMポートの番号を食いつぶしてしまうので，放置することにした．
u-blox大好きユーザだが，さすがにこれは…

GPS jamming実験の中止

カリフォルニア州のChina Lakeで実施されていたGPS jammingの実験が
キャンセルされたらしい．

AOPA: NAVY CANCELS PLANNED GPS OUTAGE IN SOUTHERN CALIFORNIA

結局，jammingを実施したのは6月7日だけのよう．
実験の詳細と同様に，キャンセルの理由も不明．

民間機に影響が出ていたから，批判が大きかったのだろう．

AndroidでRAWデータにアクセス

これは楽しみ．

gpsworld.com: Google opens up GNSS pseudoranges

記事のタイトルはpseudorangesになっているけれど，
Googleのアナウンスはraw GPS measurementsだ．

搬送波位相にもアクセスできて，RTKとか試せるといいな．

GPS Interference Notam

カリフォルニア州全域を含む西海岸で，大規模なGPS信号干渉の
実験があるらしく，注意を呼びかけるNOTAMが出ている．

FAA: GPS Interference Testing, CHLK GPS 16-08, 07-30 June, 2016, China Lake, California



どうやらミリタリーの実験らしいけど，やることが派手だな．
SDR持ち込んでログ取りたい．

【追記】本当にGPS信号をロストしている．



いくつか記事が出ているけれど，実験の詳細は不明．
中心地付近には，海軍のAir Weapons StationやWeapons Centerがあるらしい．

GIZMODO: FAA Warns of GPS Outages This Month During Mysterious Tests on the West Coast

【追記2】redditのスレッド．GPS信号をロストした写真もあり．

reddit.com: GPS Interference NOTAM For Southwest US



【追記3】ちょっと調べてみたら，軍事演習で頻繁にGPS jammingをしてる．

ofcom.org.uk: GPS jamming exercises

それでも，ここまで大規模なのは，今回が初めてだろうな．

RTL-SDRとAirSpy

高須さんの日記でRTL-SDRによるGPS信号受信が紹介されています．
RTKLIBにSDRの機能が実装されることを妄想しながら，少し情報を補足．

RTL-SDRに搭載されているフロントエンドのR820Tは，IF信号の帯域として
3.2MHzあるのですが，それをADCでサンプリングしているRTL2832Uにおいて，
I/Q信号の帯域がLPFでそれぞれ0.8MHzにカットされてしまいます．そのため，
全体で1.6MHzの帯域しか確保できず，GPS信号を受信するには微妙に狭いです．

つまり，RTL2832Uでは，フロントエンドの帯域を生かしきれていません．
そこで，その部分をLPC4370マイコンに置き換えたものが，AirSpyになります．
AirSpyでは，LPC4370の高速なADCとUSBインターフェイスが，RTL-SDRより
周波数の高い広帯域なサンプリングを可能にしています．

さらにAirSpy R2には，新しいフロントエンドであるR820T2が搭載されています．

airspy.com: AirSpy R2

R820T2の帯域は，ユーザの実験などから（非公式に）10MHz程度と確認されています．
ノイズフロアも数dBほど改善されているようです．

superkuh.com: RTL-SDR and GNU Radio with Realtek RTL2832U software defined radio receivers

そのため，AirSpy R2では，最大9MHzの帯域でalias-freeな観測を実現しています．
RFポートからの給電も，ホスト側のソフトウェアでON/OFFできて便利そう．

しかし，お値段は$199と，RTL-SDRの$19.95の10倍…

itead.cc: AirSpy R2

高額なデバイスに手を出す前に，まずは安価なR820Tのワンセグチューナを購入して，
SDRを体験してみるのが良いかもしれません．

aitendo.com: ワンセグRX DVB-T+DAB+FM R820T高性能受信機