日記・備考録 |
2005 |
2006 |
2007 |
2008 |
2009 |
2010 |
2011 |
2012 |
2013 |
2014 |
2015 |
2016 |
2017 |
2018 |
2019 |
2020 | 2021/
1
2
3
4
5
6
7
8
9
10
11
12 |
2022 Search |
| November | December 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 |
January | Home |
....................................................................................................................................
今年も終わりなので、例年通り、今年の測位衛星の打ち上げまとめ。3回4機。皆さまよいお年を。
| Date/Time (UTC) | Satellite | Orbit | Launcher | Launch Site | Notes |
| 2021/06/17 16:09 | GPS III SV05 | MEO | Falcon 9 | Cape Canaveral, US | G11 |
| 2021/10/26 02:19 | QZS-1R | IGSO | H-IIA | Tanegashima, Japan | J04 |
| 2021/12/05 00:19 | Galileo FOC-23, 24 | MEO | Solyz-ST-B | Kourou, Franch Guiana | E34, E10 |
参考: 2010年 (13機)、2011年 (14機)、2012年 (12機)、2013年 (3機)、2014年 (13機)、2015年 (15機)、2016年 (16機)、2017年 (12機)、2018年 (26機)、2019年 (14機)、2020年 (6機)。
来年の予定は、GLONASS-K2 (Q1?)、GLONASS-K2 (Q2?)、Galileo-FOC x 2 (3月下)、GPS III SV-06 (Q1)、Galileo x 2 (?)、IRNSS-1J (?)、GLONASS-M/K/K2 x ? (?)、BeiDou-3 x ? (?)。打上予定はSpaceFlightNow、NASA SpaceFlight.com ForumとRocketLaunch.Liveから拾っている。
以下、各衛星系のConstellation Statusへのリンク：
GPS (NavCen), GLONASS (IAC), Galileo (GSA), QZSS (QZSS), BeiDou (CSNO-TARC), NavIC (ISRO)
-------------------------------------
注意深い人は、昨日のウインドウスナップショットの四隅が丸くなっていることに気付いたはず。Windows 11ではWSL2が標準でXウインドウに対応したらしいのでバージョンアップしてみた。USBデバイス対応も期待していたけどこれはダメみたい。Windows 11、色々と使いずらくなった部分もあるのだけどまあ慣れるかな。
-------------------------------------
2021/12/26 07:30 UTC頃, QZS-1 (J01, PRN193) L1C/A信号送信再開。ただL6Dは止まったまま。23:30 UTC現在まだ衛星ステータスはunhealthyとなっているが、程なく正常に復帰するのではないかと思われる。これで運用関係の方々も年を越せそうでよかったです。
補足: 2021/12/27 05:00 UTC頃、L6D信号の送信も再開。(16:36追記)
....................................................................................................................................
https://github.com/tomojitakasu/PocketSDR
ver. 0.4を公開した。pocket_trk.pyの動作確認のため、PocketSDRでキャプチャした、L1+L5 (24MHz)、L1+L6 (12MHz) 30秒サンプルIFデータもアップ。URLはPocketSDR/sample/*.linkを参照。
どうも、MAX2771が出力するQサンプルの符号が反対みたいなんだよね。もしかするとコードのどこかに間違いがあるのかもしれないが。キャリアエイドを入れて、概ねDLLは安定したが、L5捕捉でたまにドップラをミスる問題が残っている。その他まだ不可解な挙動もあるが、概ね全部の動作確認が終わったので。L5はSeptentrioに比較して、少しC/N0が落ちる感じで、もしかすると少し帯域が足りていない可能性もある (スプリアスの影響の可能性も)。
最終的にGalileo E5BIの航法データ復調にも対応。残りの航法データ復調は、L1CD、L2CM、L6D、L6E、G1CA、G2CA、B1I、B1CD、B2I、B2AD、B2BI、B3I。正直、処理は同じようなパターンが多いので、全部対応したとしても、凄く大変という訳でもない。市販受信機が対応していないB2BI (B-CNAV3、PPP用) は対応したいと思っているが。あと、BOC用のBump-jumpとかクロス追尾の対応とかは、意欲のある人がフォークして改造してくれればと思う。
Pythonスクリプト中で、LIBFECとRTKLIBの共有ライブラリをctypes使って呼んでいるが、共有ライブラリはMINGW64と、WSL2-ubuntu 20.04で作って動作確認しているので、それ以外の環境では正常動作しない可能性があります。その場合、自分で何とかしてください。
せっかくなのでアップしたサンプルを使ったpocket_trk.pyの動作例を。コマンドプロンプトではESCシーケンスに対応していないので表示が流れてしまうかも (Windows 11のPowerShellはOKだった)。
この例では12MHzサンプル30秒分を使って、全GPS衛星L1C/Aの捕捉 (積分10ms) と8衛星追尾を行っているが、実行時間は102.6秒 (LG Gram 17, Core i５-1035G７）。シングルスレッドでしか動いていないはずなのでまあまあ速い。なお、-pオプション付けてプロット表示すると、相関器80個追加するのでかなり遅くなる。ただ遅い方がむしろ受信機動作が分かり易いかも。
補足: L5の帯域が足りてないということはないか。E5bは問題ないので。PSDで見るとL5は中央周波数付近に大きめのスプリアスが載っているのでこれが原因かもしれない。これらスプリアスは主にMAX2771内部で発生している様で、レジスタ設定変更で状況が改善するか試してみる予定 (EZ-USBの水晶も24MHzなのでこれの可能性も。もしそうならTCXO周波数を少し離した方が良いかも)。あとL5のIFフィルタは23.4MHzより16.4MHzの方が少しC/N0が良い様で、23.4MHzの場合隣のイメージ帯域の雑音が混入している可能性があります。今後PocketSDRを製作される方は、この辺の条件を色々と変えて試して見てください。あとサンプルIFデータの取得条件を書き忘れましたが、HX-CSX601A - RG58A/U (10m) - GPS410 (Splitter 4P, passive) - RG316/U (1.5m) - PocketSDR、です。HarxonのLNAゲイン が40dBで、ケーブルと分配器のロスが合計で20dB位。PocketSDR内部にも分配器が入っているので、条件としてはそれほど良くないですが、L1C/AのC/N0は市販受信機 (Septentrio, u-blox) と遜色ないです。2bit ADCなので、3bit以上のADCに比較して、量子化ロスが0.5 dB位は出るはずですが、これを見るとMAX2771自身のNFは充分低そうです。この辺はさすがに専用設計ICというところ。PocketSDR自身にSAWフィルタは入ってないですが、とりあえず問題は出ていません。といっても動作環境によっては干渉電波を拾う可能性はあるので、SDRによるノッチフィルタとかは研究テーマとして面白いと思います。(12/27追記)
再補足: WSL2上のpocket_trk.pyでSBAS航法データの復調がうまく行かない。MINGW64上では問題ない。最初はPythonのバージョン差かと思って追っていったら、どうもWSL上でビルドしたLIBFECとMINGW64上でビルドしたLIBFECで動作が違うみたい。ということで、いまのところMINGW64上での実行を推奨しておきます。(12/27追記)
再々補足: 結論からするとPythonのバージョン差。WSLの方は3.8.10、MINGW64の方は3.9.7。3.8.10ではint型のポインタを外部ライブラリに正常に渡せないみたい。int32型ならOK。これctypesのバグじゃないかな。(1/5追記)
....................................................................................................................................
まだ、ちょっとノイジーなんだけど、QZSS L5SI 航法データ復調も出来た。市販受信機ではL5Sを受信できるものはないはず。これで、GPS L1C/A, L5I, QZSS L1C/A, L1S, L5I, L5SI, SBAS L1C/A, L5I, Galileo E1B, E5AI, E6B までの航法データ復調実装完了。年内にはなんとか公開したい。L1CとBDSはこのままモチベーションが続けば。
-------------------------------------
QZS-1 (J01, PRN193) の信号送信が復旧しない。3日目。あと３カ月なんだけど。
....................................................................................................................................
ということで、ようやくGalileo E6B C/NAVデータ復調に成功。中身を見る限りこの衛星は固定パターンしか送っていない様だが。これでGalileo HAS ICDがいつ公開されてもOK。さて公約通り年内に公開されるだろうか。
-------------------------------------
2021/12/21 03:20 UTC頃、QZS-1 (J01, PRN193) L1C/A信号停止。05:43 UTC現在、まだNAQU (参照) には出てないけど、これトラブルじゃないかな。
補足: NAQU2021229 (参照)。(15:41追記)
-------------------------------------
PyPI, cssrlib 0.1.0
Pythonで書かれたオープンソースのPPP/PPP-RTK用 CSSRライブラリ。開発はCLASの開発に深く関わっておられる三菱電機 廣川氏 (参照)。いくつかのコードはRTKLIBをPythonに移植したものの様だ。
-------------------------------------
RINEX The Receiver Independent Exchange Format Version 4.00, December 1, 2021
RINEX 4.00が公開。3.05からの主な変更はCNAV等の新しい航法データ対応。QZSS L1C/B信号の観測コード (x1E) も追加されている。CNAV対応しないの、というRTKLIBに関する問い合わせに、RINEXがまだ対応していないから、と苦しい回答していたのだが、これで使えなくなった。
-------------------------------------
Galileo E6Bの航法データ復調には、1/2 FECをデコードするため普通にはビタビデコーダ (参照) が必要になる。ということで新規に実装しようと色々と調べていたら、予想以上に大変そうでかつPythonでは速度が出そうもないことが分かった。それでは、LIBFEC (参照) をPythonから呼び出せば良いのでは、ということで、2日位色々としていた訳であるが、大体動くようになったのでメモ。
(1) 最初に、LIBFECの共有ライブラリを作る。上記リポジトリをgit cloneして ./configure -> makeすれば終わり。libfec.soが出来る。MINGW64でもWSL2でも問題なく作れた。ただし両者のオブジェクト形式が異なる様で (COFFかELF) 別の環境で作ったライブラリはロードできない (多分、32bitと64bit間も)。なお、ubuntu 20.4ではLIBFECはパッケージに含まれており、sudo apt install libfec-devで標準ライブラリパスの下に入る。自作関数の場合、gccなら-fPICをつけてコンパイルして、-sharedをつけてリンクすれば共有ライブラリにできる。
(2) Pythonからの外部ライブラリ呼び出しはctypes (参照) を使う。基本は簡単で以下の様な感じ。ctypes.cdll.LoadLibrary() で共有ライブラリパスを指定する。絶対パスを指定しなくても、標準ライブラリパスに含まれていれば検索してくれる様。
from ctypes import *
extlib = cdll.LoadLibrary('extlib.so')
...
extlib.extfunc(...)
...
(3) 外部ライブラリ関数呼び出し時の引数はctypesの型変換関数 (c_int(), c_float(), ...) でラップする。なおint型は変換しなくても良い。
(4) 関数戻り値はctypes型の変数を作って代入する。ctypes型変数の値はvalue属性として取り出せる。戻り値がint型の場合、ctypes型の変数である必要はない。 外部ライブラリ関数の戻り値型がint型以外の場合、関数のrestype属性を設定する必要がある。
(5) (3)(4) の代わりに、外部ライブラリ関数のargtypesとrestype属性を設定してあげると、関数呼び出し時に自動的に型変換してくれるらしい。
(6) Numpyのndarrayを、外部ライブラリ関数に渡したい場合は、最初に型を指定してndarrayを作る: a = np.array([0, 1, 2], dtype='uint8')。次にctypesポインタ型に変換する: p = a.ctypes.data_as(POINTER(c_uint8))。これを引数にして外部ライブラリ関数を呼び出せばよい: extlib.extfunc(p, len(a))。
ctypesは標準ライブラリなのでインストールの必要ないし結構簡単。ということで、RTKLIBも共有ライブラリ化した。Pythonから自由に呼び出せる様になったので色々と作業がはかどる。外部ライブラリ関数との構造体のやり取りはちょっと面倒そうなので、これは今後ちゃんと調べる。
ついでに、GNSSで良く使われるコンボリューションコードはR=1/2, K=7のものだが、どうもG1, G2生成多項式が標準的なものとは逆順の様。LIBFECを使う場合、外部でシンボル順序をひっくり返すか、set_viterbi27_polynimial() で設定しなおす。またGalileo航法データの場合、G2出力にインバータが入っている (参照、Figure 13) ので反転する必要があることに注意。GNSS-SDRLIB (参照) がなかったら、この解決にどれだけ時間がかかったことだろう。貴重なコードを公開してくれていることに感謝。
補足: restype属性を指定しない場合、外部ライブラリ関数の戻り値の自動型変換はしてくれない様で訂正。例えば関数がポインタを返す場合、明示的に extlib.extfunc.restype = c_void_p 等とする必要がある。参考のためLIBFECの1/2 FEC デコード呼び出しを参考に以下に (エラー処理は省略)。 (15:16追記)
from ctypes import *
import numpy as np
libfec = cdll.LoadLibrary('libfec.so')
def decode_conv(data):
N = len(data) // 2 - 6
libfec.create_viterbi27.restype = c_void_p
dec = libfec.create_viterbi27(N)
p = data.ctypes.data_as(POINTER(c_uint8))
libfec.update_viterbi27_blk(c_void_p(dec), p, N + 6)
bits = np.zeros((N + 7) // 8, dtype='uint8')
p = bits.ctypes.data_as(POINTER(c_uint8))
libfec.chainback_viterbi27(c_void_p(dec), p, N, 0)
libfec.delete_viterbi27(c_void_p(dec))
buff = np.zeros(N, dtype='uint8')
for i in range(N):
buff[i] = (bits[i // 8] >> (7 - i % 8)) & 1
return buff
再補足: LIBFECのビタビデコーダは軟判定復号器なので上記関数引数dataとしては型uint8, 値0〜255のndarrayを与える。(16:24追記)
-------------------------------------
SDRを教材に使ったGNSS受信機技術の教育プログラム。ちょうど「CSK変調の信号追尾の可能性について」が発展的課題 (参照) として上げられている。これは個人的な希望だが、MATLAB/Simulinkは利用上の制約が多いので、使うツールとしてはPythonベースにして欲しい。
-------------------------------------
u-blox, NEO-D9C series: u-blox QZSS L6 correction data receiver
u-blox NEO-D9Cのマニュアル等詳細文書が公開。データシート見ると、RFフロントエンドはシングルの様だが、とすると、L2CとL6両方受けるために60MHzの帯域が必要な訳で結構大変な実装。コードが長い (20 ms) のでL2Cの捕捉大変だしね。L6単独なら10MHz帯域で良いので、ずっと単純な構成にできる。といってもパイロット信号なしでL6 CSKを追尾・復調できるのか、という話を、今ちょうど色々と試している所なのである。SDRあると、色々と研究テーマが見つかって面白いよ。
-------------------------------------
R.Hirokawa et al., PPP/PPP-RTK open formats: Overview, comparison, and proposal for an interoperable message, Navigation, 2021
PPP/PPP-RTK用補正情報フォーマットの現状についてまとめている。
....................................................................................................................................
J.Curran and T.Melgard, The paticular importance of Galileo E6C, Inside GNSS, 2016
なんとかGalileo E6B/Cの追尾が出来る様になったんだけど、仰角の高い衛星でもかなりノイジーでBERが高そうな感じ。ということで、これ読むと、ビット (シンボル) レートが高い (500 bps/1000 sps) ので、E6B+Cのクロス追尾しないと実用的じゃないみたい。シンプルな信号追尾コードがどんどん複雑になっていく。(下はGalileo E6C (パイロット) の追尾状況、セカンダリコードは除去している)
-------------------------------------
信号追尾には相関演算性能が重要なので、これもちゃんと実行時間を測る。(LG Gram 17, Core i5 1035G7, WSL2-Ubuntu 20.4, Python 3.8.5)
DTYPE RESULT N = 6000 12000 24000 48000 96000 (ms)
int8 int8 0.00672 0.00968 0.01925 0.03664 0.07064
int16 int16 0.00553 0.00942 0.01844 0.03776 0.07401
float16 float16 0.03621 0.07555 0.14720 0.28535 0.58784
float32 float32 0.00169 0.00249 0.00406 0.00715 0.01416
float64 float64 0.00249 0.00771 0.00917 0.01257 0.01799
complex64 complex64 0.00500 0.00667 0.00966 0.01786 0.03248
complex128 complex128 0.00436 0.00849 0.01307 0.03836 0.03830
相関演算と言ってもだだの内積で、Numpyではdot()。int8, int16が遅いのは内部で浮動小数に変換して実行しているのではないかと思われる。最速はfloat32。N=12000で2.25μ秒。演算数は、乗算:N+加算:N-1なので (12000+11999) / 2.25E-6 = 10.7 GFLOPS。最近のCoreはAVX2で256bit幅のFMA演算が実装されているので、理論最大性能はコア当たり16×2×クロック (FLOPS、単精度)。クロックは高負荷時に2.5GHz位までは上がるようなので 16×2×2.5 = 80 GFLOPS。ということで最大性能の1/8位は出ており、Pythonとしてはかなり速い。これ位なら低サンプリングレートならリアルタイムも行けるかもしれない (マルチスレッド化は必須だが)。
補足: サンプリング6MHzなら1msの相関時間は0.00143×6 (I,Q×E,P,L) = 0.00858 ms。BOC用5点相関器なら0.00143 × 10 (I,Q×VE,E,P,L,VL) = 0.0143 ms。相関器だけなら1コア当たり数10CHは入りそうだが、それ以外が遅いからなあ。(10:50追記)
再補足: 最近のPythonはAI用にfloat16 (半精度浮動小数) が実装されているのを思い出したのでそれも追加して測り直し。このCPUとPythonバージョンではfloat16は実用に耐えない。(11:00追記)
再々補足: なんだかんだ言って、結局10年位前 (参照) と同じようなことを繰り返しているだけという気もする。全く進歩がない。(11:18追記)
....................................................................................................................................
s-taka.org, USRP B205mini-i とGNSS-SDRを用いた衛星測位
高橋先生が、USRP B205mini-i (参照) + GNSS-SDR (参照) の構成で、結構苦労しながらソフト受信機を試されている。GNSS-SDRは設定が複雑で難しく、PocketSDRのデジタルIFデータをGNSS-SDRで処理させようとしていて、まだうまく動いていないのであるが、今後リアルタイムでもちゃんと接続できるようにしたい。
USRP B205mini-iのチップセットはAD9364 (参照) か。Pluto SDR (参照) のAD9363 (参照) と同じファミリで、汎用SDR向け。スペック的には、過剰なの部分と不足の部分があって、GNSS用に必ずしも使いやすいとはいえない。やっぱり、MAX2769やMAX2771の様なGNSS専用の石が使いやすいと思う (性能面でも現実の受信機に使われている様に問題も出にくいと思う)。
....................................................................................................................................
なんとかGalileo E1Cの追尾に成功。やっぱり条件が悪いとサイドローブを追いかけちゃうので5点相関器が必要そう。なおPythonでも、12MHz x 3CH位ならリアルタイムでも動きそうな感じ (シングルスレッド)。threadingも使ってみたけどむしろ遅くなってしまった。これは使い方が悪いのかも。
....................................................................................................................................
TaobaoのMAX2771も在庫がないところが多く、ある所も@430元 (\7675) 以上と通常価格の7倍。待つしかないのか。
....................................................................................................................................
まだPLLが安定しないけど、とりあえず追尾できた。
-------------------------------------
QZSS, みちびき初号機後継機のサービス提供開始に向けた準備状況について, 2021年12月10日
昨日から、QZS-1Rから (アラートはオンだが) 正常な航法データが送られるようになった。また、AlmanacにもPRN196が含まれる様になったので、多くの受信機で、QZS-1Rの信号を受信できるのではないかと思われる。
ID: 196 Health: 254 Eccentricity: 7.548480988E-02 Time of Applicability(s): 135168.0000 Orbital Inclination(rad): 0.595418238 Rate of Right Ascen(r/s): -3.097271871E-09 SQRT(A) (m 1/2): 6493.309082 Right Ascen at Week(rad): 4.167139704E-01 Argument of Perigee(rad): -1.562416358 Mean Anom(rad): 7.453745973E-01 Af0(s): 1.115798950E-04 Af1(s/s): 1.455191523E-11 week: 140
....................................................................................................................................
献本頂きました。
-------------------------------------
TaobaoにはMAX2771の出物が結構ある。他の部品が余っていてPocketSDRをあと5式位作りたいので、ちょっと不安だが代行頼むか。
....................................................................................................................................
技術雑誌 電子復刻, 共立出版 コンピュータサイエンス誌『bit』
懐かしのbitがKindleで復刊。
-------------------------------------
https://github.com/tomojitakasu/PocketSDR
GLONASS G1CA, G2CA, BDS B1I, B2I, B1CD, B1CP, B2AD, B2AP, B2BI, B3I に対応。
$ pocket_acq.py ch1.bin -f 12 -sig B1CP -prn 19-46
-------------------------------------
CQ出版, トランジスタ技術 2022年1月号、特集 実用元年 ! cm級GPS大実験
イントロと7章の記事書きました。12/10発売です。
....................................................................................................................................
SpaceFlight Now, Live coverage: Soyuz rocket lifts off from jungle launch pad with Galileo Satellites, December 3, 2021
2021/12/05 00:19 UTC, 2機のGalileo衛星 (Galileo FOC衛星 23, 24号機), フランス領ギアナ クール―宇宙センタより、Soyuz-ST-Bロケットで打ち上げ。
補足: 打ち上げ成功の模様。Youtubeビデオ (参照)。リフトオフは28:08。セパレーションは4:19:13。(14:36追記)
再捕捉: 打ち上げられたFOC衛星は23, 24号機だったので修正。これで軌道上のGalileo衛星はIOV4機、FOC24機。うちIOV4, FOC1, FOC2, FOC4がサービス停止中 (参照)。NASASpaceFlight.comの記事 (参照) によると2025-26年までにFOC衛星の打ち上げを終える。次世代Galileo (G2) 衛星の打ち上げは2024年からとのこと。(16:41追記)
-------------------------------------
FFTW3とMKLの実行時間もついでに。(LG Gram, Core i5 1035G7, WSL2-Ubuntu 20.4)。FFTWF, MKLFが単精度複素数、FFTW, MKLが倍精度複素数。_Mはマルチスレッド。事前にFFTW_PLAN (参照) をFFTW_ESTIMATE指定で計算して高速化している。これ見るとPythonで実用リアルタイムコード書くのは厳しい様に思う。
N FFTWF_FFT FFTWF_IFFT FFTW_FFT FFTW_IFFT (ms)
24000 0.094 0.073 0.127 0.126
32768 0.095 0.097 0.175 0.170
48000 0.162 0.163 0.258 0.260
65536 0.229 0.223 0.401 0.411
96000 0.394 0.388 0.821 0.877
131072 0.577 0.538 1.004 1.150
N MKLF_FFT MKLF_IFFT MKL_FFT MKL_IFFT (ms)
24000 0.203 0.104 0.124 0.139
32768 0.130 0.047 0.085 0.111
48000 0.135 0.143 0.206 0.197
65536 0.150 0.107 0.217 0.206
96000 0.257 0.243 0.397 0.421
131072 0.313 0.312 0.902 0.922
N MKLF_FFT_M MKLF_IFFT_M MKL_FFT_M MKL_IFFT_M (ms)
24000 0.026 0.023 0.028 0.028
32768 0.028 0.027 0.052 0.075
48000 0.034 0.040 0.074 0.093
65536 0.054 0.074 0.126 0.163
96000 0.086 0.059 0.164 0.215
131072 0.137 0.204 0.450 0.465
補足: SDR実装においてFFT速度は重要なのでWSL2上で測り直し。ついでに最新のMKL
(2021.4.0) もWSLに入れて測ってみた。MKLはNが大きいところで速い。MKLはradix-2
FFTも速いので2のべき乗にゼロパディングした方がよいかも。(12/7追記)
再補足: マルチスレッドMKLの結果も追加。(12/7追記)
-------------------------------------
Numpy, Scipy FFT/IFFT速度の比較 (LG Gram, Core i5 1035G7, Python 3.8.10)。NP-*がnumpy.fft/ifft, SP-*がscipy.fftpack.fft/ifft。まあまあ速い。L6航法データ復調にFFTを使う場合、サンプリング12MHzで4ms N=48000、ゼロパディング入れてN=96000。N=48000なら、なんとかリアルタイムで間に合うかなあという感じ。ただしノートPCだと、連続動作でCPU温度が上がってクロックが下がってしまう可能性が高いので、リアルタイムはあまり実用的ではない。(BIOSでTurbo BoostをOFFして、かつ速度が間に合えば、連続動作も可能かも)
パイロット信号無しでL6航法データを復調できるアルゴリズム思いついたので、ちょっと実装してみたいのだけど。
N DTYPE NP-FFT NP-IFFT SP-FFT SP-IFFT (ms) 24000 float32 0.795 0.806 0.294 0.606 24000 float64 0.799 0.695 0.506 0.601 24000 complex64 0.800 0.894 0.406 0.299 24000 complex128 0.800 0.900 0.494 0.406 32768 float32 0.995 1.106 0.300 0.800 32768 float64 1.094 1.106 0.700 0.599 32768 complex64 1.202 1.094 0.505 0.599 32768 complex128 1.106 1.200 0.800 0.695 48000 float32 1.707 1.599 0.600 1.001 48000 float64 1.594 2.107 1.293 1.200 48000 complex64 1.905 1.700 1.000 1.195 48000 complex128 1.805 1.795 1.407 1.099 65536 float32 2.107 2.200 0.698 1.401 65536 float64 2.197 2.394 1.400 1.700 65536 complex64 2.506 2.495 1.400 1.501 65536 complex128 2.500 2.203 1.596 1.507 96000 float32 3.606 3.400 1.698 2.099 96000 float64 3.403 3.302 1.599 1.702 96000 complex64 3.594 3.600 2.300 1.700 96000 complex128 3.405 3.399 2.700 2.299 131072 float32 4.757 4.695 2.505 3.395 131072 float64 5.805 5.296 2.900 3.300 131072 complex64 5.700 5.904 4.096 3.002 131072 complex128 5.102 4.797 3.100 2.900
....................................................................................................................................
SpaceFlight Now, Live coverage: Arianspace scrubs Soyuz launch due to lightning risk, Decemver 3, 2021
本日予定されていたGalileo衛星2機を載せたSoyuzロケットの打ち上げは落雷リスクのため T-8 min でスクラブ。明日 (2021/12/05 00:19 UTC) に延期。
....................................................................................................................................
PocketSDR サンプルIFデータの面白い応用ということで。日本において受信できるSBAS、QZS L1S信号の一覧。たった100msのIFデータの中に色んな衛星から送信されている信号が含まれている。
$ pocket_acq.py sample\L1_20211125_004000_12MHz_I.bin -prn 120-158,183-189 -f 12 -fi 3
PRN130: BDSBAS (G1), PRN137: MSAS (QZS-3), PRN140: SDCM (Luch-5V), PRN143: BDSBAS (G3), PRN144: BDSBAS (G2), PRN183: L1S (QZS-1), PRN184: L1S (QZS-2), PRN185: L1S (QZS-4), PRN189: L1S (QZS-3) (参照)
....................................................................................................................................
https://github.com/tomojitakasu/PocketSDR
更新した。
信号捕捉用Pythonスクリプト (pocket_acq.py) やPocketSDRでキャプチャしたサンプルIFデータを追加。sample\L1_20211201_054600_24MHz_I.binにはQZS-1R L1C/B (PRN203) の試験信号が含まれている。以下コマンドで相関電力波形を表示できる。なお、実行にはPython 3, Numpy, Scipy, matplotlibが必要。
$ cd PocketSDR\python
$ pocket_acq.py ..\sample\L1_20211201_054600_24MHz_I.bin
-f 24 -fi 6 -sig L1CB -prn 203 -p
-------------------------------------
IS-GPS-800確認したら思ったより簡単そうだったので、L1Cコード生成機能も追加。
QZS-1R L1C (PRN196) 受信も確認。IFデータは昨日と同じ。コードオフセットの端数がL1C/Bのコードオフセットと一致していることに注意。L1Cはコード長が10msでかつMBOCなので、この例で信号探索に8.94秒もかかっている
(L1C/Bは積分4msで0.26秒、Galileo E1Bは1.35秒、サンプリング24MHz)。L1Cに比較して、高速捕捉の点でL1C/Bの優位性はある
(航法データの単純性の面でも)。
補足: よく考えたら、MBOCかどうかは捕捉時間にはあんまり関係ない。捕捉時間は主にコード長 (サイクル) (ms) に依存する。コードサイクルが長いと、FFTサイズが大きくなるのと、ドップラー検索ステップを細かくする必要があるのと、両方が効いて捕捉時間が延びる。捕捉ではコードオフセットの精度は要らないので、捕捉時間を削減するためデータのダウンサンプリングも有効。(14:00追記)
....................................................................................................................................
また、QZS-1R L1C/B (PRN203) の試験送信をしている。今度はサンプリング24MHz。より綺麗に相関電力波形が見える。
-------------------------------------
せっかくなのでPocketSDRでも。QZS-1R L5I (PRN196)。
-------------------------------------
Septentrio mosaic-X5でQZS-1R (PRN196, J04) L1C/A, L2C, L5の受信を確認。L6D, L6Eの受信も確認しているのでこれでほぼ全部の信号受信を確認。正常な航法データはまだ送っていない。Almanacにもまだ含まれていない様でスカイプロットには表示されない。
....................................................................................................................................
| Home | by T.Takasu |