2021/12/01〜

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

2021/11/30

ということで、PocketSDRでGalileo E5aI, E5aQも信号捕捉できるようになった。E5aI, E5aQコードにはセカンダリコードがオーバレイされているので、zero-padding付サーキュラー相関による並列コード探索。サンプリング周波数 24MHz (IQ)、積分時間 3ms、ドップラー探索 ±5kHz、で全信号探索時間が約1300 ms (LG Gram, Core i5-1035G7, Windows 10, Python 3.8.10, シングルスレッド)。少しはチューニングしたけど、Pythonではこれ位が限界かも。NumpyのFFTは単精度のまま実行できない (内部で倍精度に変換されて実行される) みたいなので、FFTはScipyのfftpack (参照) を代わりに使っている。

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

M. Lichtman, PySDR: A Guide to SDR and DSP using Python

豊富なPythonコードを含んだデジタル信号処理の基礎講座テキスト。とても分かり易いので、(Pythonコードを書かなくても) SDRに興味を持つ人は、ざっと読んでおくことをお勧めする。

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

2021/11/29

S. Jeon et al., Analysis of GNSS Signal Acquisition Methods for the Bit-Transition Problem for a Signal Code Period, Trans. Japan Soc. Aero. Space Sci, 2013

一昨日書いたセカンダリコードによるGNSS信号捕捉問題の解決手法の比較。(1) Zero padding, (2) Energy-based search space, (3) Bit-transition cancellation、の性能をシミュレーションで評価している。

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

「... QZS-3衛星はスマホ受信と測位改善が主たる目的・対象ではなく、SBAS専用衛星であったとの強力な意思統一がなされた ...」なんて事実はないので。デマを流さない様に。この件、前にも書いた様 (参照) に文句を言うならBroadcomかQualcommに。

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

たいした話ではないのだけど、Integer-N PLLとFractional-N PLLでスプリアスの大きさが違う (参照) とあったので、PocketSDR (参照) で確かめてみた。この例ではほとんど差はない様に見える。(F_XTAL=24.000MHz, F_LO=1572.420MHz)

Integer-N PLL (MAX2771 settings: INT_PLL=1, NDIV=26207, RDIV=400, FDIV=0, F_LO=F_XTAL/RDIV*NDIV)

Fractional-N PLL (MAX2771 settings: INT_PLL=0, NDIV=65, RDIV=1, FDIV=542638, F_LO=F_XTAL/RDIV*(NDIV+FDIV/2^20))

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

https://github.com/pmonta/GNSS-DSP-tools

ほぼ全てのGNSSコード生成、信号捕捉・追尾用のPythonコード GNSS-DSP-tools。開発者は3CH GNSS-SDRフロントエンド GNSS Firehose (参照) も開発しているPeter Monta (参照)。Numba (参照) というJITコンパイラ使うと、簡単にPythonのループ (for文) を速くできるみたい。

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

2021/11/27

最近のGNSS用拡散コードは、セカンダリ (オーバレイ) コードが掛け合わされているものが多い。このせいで (プライマリ) コードの切れ目で極性反転する可能性が高い。単純なサーキュラー相関では、この極性反転により相関電力が低下して信号捕捉がうまくいかない。この問題を解決するためには、データ長を (プライマリ) コード長の2倍とり、(プライマリ) コードの後ろに同一長のゼロパディングしたコードでサーキュラー相関を取ればよい。ちょっとしたトリックだが、これは知らないと思いつきずらい。なお、航法データによる極性反転でも同様の問題があるが、L1C/Aの様にデータレートが充分低い場合は、普通問題にならない。ちょっと考えると、相関電力が3dB落ちそうに思えるが、雑音電力も3dB落ちるので、SN比は変わらない。ただ、処理負荷は単純なサーキュラー相関の2倍になる。

現在、PocketPDR用の信号確認APをPythonで書いていて、疑問に思って少し調べた。より効率の良いアルゴリズムも提案されている。

補足: とりあえず、L1C/A, L1C/B, L2CM, L5I, L5Q, L6, E1B, E1C, E6B, E6Cの拡散コード生成用Pythonコードは書いた。あとはE5aI, E5aQを追加する位。L1C、GLONASS、BeiDouはスキップする予定。(17:50追記)

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

2021/11/25

2021/11/25 00:40 UTC、PocketSDRでQZS-1R L1C/B信号 (PRN203) の受信を確認。綺麗なBOC(1,1) 相関波形である (f_s = 12MHz, I-ch, 積分時間 = 4ms)。 次の試験送信が何時になるか分からないので、興味のある方は今のうちにIFデータだけでも記録しておくことをお勧めする。

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

2021/11/24

u-blox, Product summary NEO-D9C

既にいくつかのQZSS L6対応受信機に搭載されていると思われるNEO-D9Cが正式発表。同時受信信号数は2。対応信号帯域はQZSS L2CとL6で、L2CはL6復調のためのパイロット信号の扱いと予想される。F9と組み合わせてQZSS CLASに対応する様だが、現行のF9は (公式には) CSSRに対応していないので、CSSRに対応した特別F/Wが必要なのであろうか。

補足: D9SまたはD9Cと組み合わせてPointPerfectまたはCLASに対応するには、新しいF/Wを搭載したZED-F9P-04Bが必要とのこと (参照)。(11/25追記)

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

2021/11/23

GPSPatron, 680 Forks on GitHub for GPS Signal Simulation, 2021/09/25

GPSスプーファ用のオープンソースソフトで最も有名なものはgps-sdr-sim (参照) で、既にgithub上に680のフォークがあり各種の拡張がされている。Youtubeでも、SDRを使ったスプーフィング手順を紹介する動画がいくつも上がっており多数の視聴者がいる。今や、ジャマ―と同じように、中国企業が手軽なスプーファを開発するのは容易である。GNSSスプーファがアリエクで$150以下で手に入る様になったら、何が起こるか想像してほしい...、とのこと。

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

2021/11/22

QZSS, CLAS分野のみちびき公募実証成果 (農業). 2021年11月18日

オープンスカイ (遮蔽程度：なし) 条件で「FIXまでの時間平均値 (sec)」が204秒もかかっている。CLAS仕様 (≦ 60秒/95%) に比較して悪すぎる感じ。これはCLASの問題？ それとも受信機F/Wの問題？

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

アリエクで注文していた、激安 MAX2769B x 30とEZ-USB FX2LP (100TQFP) x 4が到着。目的は秘密。パッケージを見る限り、多分本物だと思うけど。

補足: MAX2769B x 30 + EZ-USB FX2LP (100TQFP) x 4、全部で$66.28也 (送料含む) (11/28追記)

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

QZS-1R (J04, PRN196) L1C/A信号は2021/11/22 07:50 UTC頃停止。一応PocketSDRのログからQZS-1R L1C/A信号を確認した時間を記録しておく。2021/11/17 03:30-07:10 UTC, 2021/11/19 01:30-02:00 UTC, 2021/11/19 02:20-04:50 UTC, 2021/11/20 05:40-11/22 07:50 UTC。時刻は概算。11/15以前はログが残っていないので、信号送信していたか不明。多くの市販受信機はAlmanacに衛星が含まれない場合や正常な航法データが含まれない場合、信号捕捉または追尾しないはずなので、市販受信機でQZS-1Rの信号を確認するのは望み薄。
なお、先日のGNSSシンポの内閣府 沼田氏の発表によると、2021/11/24〜26にQZS-1R L1C/B信号 (PRN203、参照) の送信試験を行う予定とのことであった。ただし、本件、まだQZSSの公式リリース (参照) にはないので、日程を変更したか、一部受信機メーカ以外は非公開という扱いなのかもしれない。

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

2021/11/21

PocketSDRで、QZS-1R (J04, PRN196) L1C/A信号の受信を確認。ただし、正常な航法データはまだ送信されていない。Almanacにも含まれていないので、F9Pでもmosaic-X5でも受信できていない。ログを確認すると、2021/11/17位から、間欠的に送信している様。ちなみにL6D, L6E信号 (PRN196, 206) の受信も確認できている。こちらはアラートONだが航法データが含まれている。

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

2021/11/20

QZSS, 今期と元期とCLAS座標, 2021年11月18日

CLASによる座標は「測量成果に基づいた地図作製の基準日に合わせた元期の座標に変換しなければ、地図上の座標と整合させることはできません」とのこと。CLASの座標系はITRF2014 (参照, IS-QZSS-L6-004 5.2.2, 5.2.3) なので、JGD2011 (測地成果2011, 参照) とは、現在、水平で10cm以上差がある地点が多いはず。しかし、何かもっと簡単に変換できる様にならないですかね。

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

2021/11/19

Maxim, MAX2771 baseband spurs

PLL fractional-Nモードの方がinteger-NモードよりIF信号にスプリアスが発生しやすい。ただ、これらスプリアスは、GPS信号のベースバンド処理で40dB以上減衰するので、実際にはほぼ問題とならない、とのこと。

補足: Wikipedia (参照) によると、"a spur" は "a spurious tone" とほぼ同義らしい。(9:21追記)

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

2021/11/18

PocketSDRについて質問受けて回答したので、ついでなのでその回答を書いておく。

Q: TCXO周波数を当初16.368MHzから24.000MHzに変更した理由は ?
A: MAX2771のADCクロックマルチプライア/デバイダのx4モードが正常動作しなかったから。L1+L5受信のためにADC周波数を24MHz付近に設定したかったが、TCXO16.368MHzだと、x4モードなしではどうやっても24MHz付近に設定できない。x2モードを使って32.736MHzでは動作したが (24MHzに比較して) PC側のCPU負荷が増えてしまう。TCXO 24.000MHzであればADCクロックを3, 4, 6, 8, 12, 16, 24MHzに設定できる。32MHzは正常動作しないので、GPS+GLONASS L1同時受信は無理だが、これはあきらめる。

Q: EZ-USB FX3ではなくて、EZ-USB FX2LPを使った理由は ?
A: FX3はパッケージがBGAしかなく、端子から線を引き出すためどうしても4層基板とする必要がある。4層は基板が高いし (Fusion PCBで2層 $4.9、4層 $39.9 / 10枚)、BGAが自作リフローでちゃんと付くかにも不安がある (X線検査とか無理なので) 。MAX2771の最大ADCクロックは44MHzなので、USB 2.0 (最大480Mbps) で充分収容できる。

Q: PocketSDRの製作・配布予定はあるか ?
A: OSQZSSさんの方で、某プロジェクト用に10式程度 (?) 製作予定 (参照) とのこと。今のところ、それ以外に製作・配布する予定はない。H/W、F/W、S/Wの情報は全てオープンソースとして公開した (参照) し、部品が入手できれば製作は容易なので、使いたい人は自由に製作してもらってかまわない。ただし現在、世界的な半導体部品供給不足のあおりを受けて、MAX2771も、EZ-USB FX2LP (QFN56) も手に入りにくい状況。早く供給不足が解消して欲しい。

S/Wに関しては、今後GNSS-SDR (参照) 用のI/Fコードは追加・公開予定。Pythonによる信号確認ユーティリティも。それ以外は未定。QZSS L6とGalileo E6の航法データ復調用SDRコードも追加したいとは思っているが、モチベーションが続けばという感じ。

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

2021/11/09

rtklibexplorer, RTKLIB user survey results, October 31, 2021

rtklibexplorerさんによる、RTKLIBユーザアンケートの結果。Linux版GUIアプリの要望が結構多いのね。

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

2021/11/08

CQ出版, トランジスタ技術次号予告

次号 (12月10日発売予定) 特集は「進化を続ける実用cm級 ! GPS大実験2022 〜 日本発 ! 測位衛星みちびきフル活用 〜」とのこと。

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

2021/11/07

Youtube, Share internet connection with your GNSS/GPS receiver over USB - How to

mosaic-X5のUSB経由、外部NTRIPキャスタへのアクセスの件、この方法でうまくいった。情報感謝。これで、LANインタフェースなしでも概ね問題なく使える様になった。

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

2021/11/04

QZS-1R (PRN196) の最新TLEと東京におけるSkyplot (J04)。

0 QZS-1R
1 49336U 21096A   21307.84522279 -.00000200  00000-0  00000+0 0  9997
2 49336  34.0337 105.3803 0746755 270.2652 100.2355  1.00220720   128

軌道傾斜角 (34.03°) がノミナル (41°) に比較してまだかなり小さいが、これはまだ軌道遷移中なのであろうか。ついでに最新TLEによるQZS-1,2,4,1Rの昇交点赤経。これを見るとQZS-1とQZS-1Rの軌道面は大きく異なることが分かる。たまに3つの準天頂衛星が「120度位相がずれた軌道」等の解説記事があるが、間違いなので信用しないように。

QZS-1: 136.52°、QZS-2: 267.37°、QZS-4: 5.03°、QZS-1R: 105.38°

補足: なんか、軌道傾斜角は現状 (34°付近) 以上に上げないみたい。長期摂動を考慮しても、41°まで上がらない様な気がするのだが、ノミナル軌道傾斜角を変更した? (11/21追記)

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

2021/11/02

Softbank, ソフトバンクとu-bloxが高精度測位サービスのグローバル展開に向けた協業に合意, 2021年11月1日

とのこと。次世代高精度測位の覇権をめぐって今後も色んな動きがありそう。au+swiftnavとの比較だったら、さすがにソフバン+u-blox の方が有望な気がするが。

補足: 報道関係発表会に関する記事 (参照)。(11/3追記)

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

ALES, 地殻変動量差をキャンセルするマウントポイントを新設, 2021.07.16

しばらく使っていなかったので気付かなかったのだけど、何時の間に「地殻変動量補正あり」のマウントポイント (参照) が追加されている。中身の詳細が良く分からないが、移動局と基準局の地殻変動量を地理院パラメータで計算して、その差を基準局座標に加えて送ってくる感じであろうか。基線長が長い場合には、少しは効果があるかも。個人的には基準局のITRF座標を送るマウントポイントも欲しい気がするが。

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

2021/11/01

3Dプリンタによるケースに入れた。今回は初めて色付アクリルにしてみたが、高い割に仕上げは今一つ。次からは普通のナイロンでよいかなという感じ。ところでUSB接続でも、RNDIS経由 (アドレス192.168.3.1) でWeb画面が使えることが分かった。ただ、X5からUSB経由で、外部のNTRIPキャスタに直接接続する方法がまだ見つかっていない。("Communication - Outgoing Internet Access Over USB" を on にしただけではダメだった。)

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

〜2021/10/31