DATAGNSSからPocketSDR FE 4CHが購入できるようになりましたが、
FE 2CHを入手したいという問い合わせが何件かありましたので、
またリピートで最小注文数だけ製作しました。
Boothショップにて再頒布いたしますので、入手をご希望の方はこの機会にどうぞ。
レジストの色指定を忘れていたため、今回は普通にグリーンです。
アルミの角パイプからケースを切り出して加工するのがとても面倒ですし、
FX2LPもEOLとのことなので、FE 2CHの製作はこれで最後にします。
CRPA（controlled reception pattern antenna）の調査をしていたら、NovAtelが民生向けにITAR-freeのCRPAを発売したというニュースが。
CRPAはITARで輸出規制品だったのに、いつのまにITAR-freeになったのだろうと、最新のITARをチェック。
ITAR（International Traffic in Arms Regulations）は米国の武器関連の品目や技術の取引を規制する規則で、
Code of Federal RegulationsのTitle 22 Foreign Relations / Chapter I / Subchapter Mになります。
さらに、規制対象の一覧は、Part 121 The United States Munitions Listで規定されています。
CRPAに関連する規則は、Category XI Military Electronics / Paragraph (c)に、以下のように定められていました。
(10) Antenna, and specially designed parts and components therefor, that:
(i) Employ four or more elements, electronically steer angular beams, independently steer angular nulls,
(i) Employ four or more elements, electronically steer angular beams, independently steer angular nulls,
create angular nulls with a null depth greater than 20 dB, and achieve a beam switching speed faster than 50 milliseconds;
(ii) Form adaptive null attenuation greater than 35 dB with convergence time less than one second;
(iii) Detect signals across multiple RF bands with matched left hand and right hand spiral antenna elements
(ii) Form adaptive null attenuation greater than 35 dB with convergence time less than one second;
(iii) Detect signals across multiple RF bands with matched left hand and right hand spiral antenna elements
for determination of signal polarization; or
(iv) Determine signal angle of arrival less than two degrees (e.g., interferometer antenna);
(iv) Determine signal angle of arrival less than two degrees (e.g., interferometer antenna);
細かい機能の規定はありますが、4素子未満であることがITAR-freeのひとつの条件になります。
NovAtelの製品も3素子のCRPAであり、(i)の規制を回避しているようです。
P.S. ついでに、GNSS受信機の速度規制についてもアップデートがないか確認してみました。
GPS受信機に関して以前に調べたときは、Category XV Spacecraft and Related Articles / Paragraph (c)で規定されていたのですが、
これがReservedとなり削除されています。
高度規制もなくなったのかと思いきや、Category XII Fire Control, Laser, Imaging, and Guidance Equipment / Paragraph (d)において、
新たにGNSS受信機の規制として次のように規定されていました。
(2) Global Navigation Satellite System (GNSS) receiving equipment, as follows:
(i) GNSS receiving equipment specially designed for military applications (MT if designed or modified
for airborne applications and capable of providing navigation information at speeds in excess of 600 m/s);
さすがにミサイルに搭載できてしまうような機能に関して、規制は緩和されないか。
P.P.S. GNSS信号のジャミングやスプーフィングが現実的な問題になっている近年、
このCRPAに関するITARの規制に意味があるのか、さらには民間でのR&Dを阻害しているのではないかという議論が、
National Space-Based Positioning, Navigation, and Timing Advisory Board でされています。
CRPAはジャミングやスプーフィングの対策に有効な技術であり、このあたりの規制もまた変わってくるのだろうな。
中国のLEO-PNT衛星であるCentiSpace-1が10機、洋上打上げロケットのSmart Dragon 3（Jielong 3）で打ち上げられました。
CentiSpace-1は、北京のFuture Navigationが構築している商用のコンステレーションで、GNSSと同じ測位信号を放送します。
これまでに6機（内1機は軌道投入に失敗）が打ち上げられており、今回はまとめて10機。
最終的には120～160機のコンステレーションになる計画。
拡散コードとか公開されてないのかな。PocketSDRで受信してみたい。
P.S. LEO-PNT衛星のいわゆる放送歴の生成には、従来のGNSSを使ってオンボードで推定された軌道が使われる。
CentiSpace-1の軌道決定誤差は、3Dで3cmほどと報告されている。
リアルタイムでこの精度が出るのか。すごいな。
Lin Chen, et al., "Performance Evaluation of CentiSpace Navigation Augmentation Experiment Satellites," Sensors, 2023.
NT1066はSバンド専用でPocketSDRに使えそうだけれど、将来のLEO-PNTのCバンドなどにも対応できるように、
自由度の高い汎用的な市販のSDRデバイスでも使えるようにしたい。
USRPやbladeRF、LimeSDRなどのI/Qサンプルの量子化ビット数は12ビットなので、
それを一般的なGNSSフロントエンドと同じ2ビットに変換する必要がある。
さらに、サンプル毎に変換が必要なので、出来る限り計算負荷を削減したい。
どう実装しようか考えたけれど、12ビット（N = 4096）くらいであれば、Lookup Tableでいけるだろう。
入力信号のレベルがそれほど頻繁に変化することはないので、バックグラウンドでLUTを更新すれば良い。
2ビット（N = 4）の量子化で重要なのが閾値の決定。
入力がガウス分布に従うと仮定したとき、閾値が1σで量子化によるロスが最小になる。
それ以外では急激に劣化し、1ビット（N = 2）のcomparatorと同じになってしまう。
C. J. Hegarty, "Analytical Model for GNSS Receiver Implementation Losses," Navigation, 2011.
閾値の決定に、入力信号の標準偏差を求めないといけないけれど、2乗や平方根の計算はなるべく避けたい。
シンプルに、3σの範囲外に最大値と最小値があるだろうから、その差を6で割れば近似できそう。
もう少し良い近似方法はないかなと探したところ、Range Rule of Thumbなるものを発見。
サンプル数に応じて、最大値と最小値の範囲を割る最適な値が与えられている。
A. Ramirez and C. Cox, "Improving on the Range Rule of Thumb," Rose-Hulman Undergraduate Mathematics Journal, 2012.
これによると、1000サンプルのときは、最大値と最小値の範囲を6.4で割ると最適な標準偏差の近似になるようだ。
とりあえず、Range Rule of Thumbで閾値を求めて、LUTを生成するという方針で、
bladeRFで取得したNavICのSバンド信号を2ビット量子化に変換。
オフラインで確認したところ、PocketSDRで問題なく信号捕捉に成功。I/Qサンプルの分布も良い感じ。
2ビット量子化は上手くいっているようなので、pocket_trkに組み込もう。
P.S. LUTを生成するだけの違いなので、3ビット（N = 8）の量子化でも良いかも。
ロスも低減されるし、なにより閾値の誤差に対する感度が下がるのがありがたい。
LANS AFS受信機の開発に向けて、NT1066でSバンド信号の受信を試してみました。
NT1066は、Lバンド対応の3チャンネルに加えて、独立したSバンドの受信チャンネルがあります。
SバンドのI/Qサンプルのみを、PocketSDRのファームウェアを書き込んだFX2LPで、RAWデータとしてキャプチャしています。
レジスタの設定で、Lバンドのチャンネルはすべてスリープさせ、Sバンドのみをアクティブにします。
LPFのカットオフ周波数は3.1MHz、サンプリング周波数は10MHzです。
Sバンド用のRFポートには、bladeRFでGPS信号をSバンドで生成して入力しています。
キャリアの中心周波数が異なるだけで、中身はGPS信号なので、問題なく信号捕捉ができました。
しかし、いくつか不具合も発生。
まず、I/QサンプルにDCオフセットが目立ちます。これは、NT1066のAGCの設定でどうにかなるかもしれません。
不可解なのが、受信信号のスペクトラム。
設定した3.1MHzのカットオフ周波数らしきものは見えるものの、完全に上下反転しています。
こちらの原因は、いまのところまったく不明。どうしたら、こうなるのだろう？
まだ微調整やデバッグが必要なものの、LANS AFS受信機開発の目途が立ったかな。
フロントエンド基板を設計しよう。
P.S. NT1066でL/Sバンド両方に対応したフロントエンド基板をPocketSDR用に設計したいところだけれど、
これを両立するのがちょっと難しい。
NT1066のLバンドのチャンネルは、ワイドバンドでGPS L1C/AとGLONASS L1などを、まとめて受信する設計思想になっている。
そのため、LPFのカットオフ周波数はデフォルトで30MHz程度、最小でも13MHzまでしか絞れない。
そのため、デフォルトのサンプリング周波数も72MHzとかなり高い。
PocketSDRの処理負荷は、ほぼサンプリング周波数で決まるので、72MHzは高すぎ。
一方で、SバンドのチャンネルはLバンドとは独立してナローバンドで設計されている。
それでも、LPFのカットオフ周波数は最小で3.1MHz。サンプリング周波数もTCXOの周波数までしか落とせない。
そうしたわけで、Sバンド専用であれば、PocketSDRをベースにリアルタイム処理ができそう。
ちょっと自由度が少ないけれど、BPSK(5)のパイロットチャンネルを受信するには、丁度良いかもしれない。
GUI版のPocketSDRのアプリケーションであるpocket_sdr.pyの使い方が分からずにいたけれど、高須さんが設定手順の動画を公開してくださった。
まわりが建物に囲まれたオフィスの窓際にアンテナを置いているので、可視衛星が少ないけれど、FE4CHで問題なく動いてくれた。
リアルタイムでPSDや相関波形が観測できるのは楽しいね。
LANS AFSの拡散コードが分かったので、とりあえずデータやoverlay codeなしでベースバンド信号を生成してみました。
受信機側の信号捕捉も確認できるよう、ドップラーとコード遅延を指定できるようにもしておきます。
IチャンネルとQチャンネル、それぞれのpower spectrumはこんな感じ。
これらの包絡域が、AFSのpower spectrumとして観測されることになります。
このベースバンド信号に対して、IチャンネルとQチャンネル、それぞれの信号捕捉をした結果がこちら。
PRNは1番で、コード遅延は0.5ms、ドップラーは-2kHzで設定しています。
コード遅延を中心に拡大すると、綺麗な相関波形が確認できます。
ベースバンド信号の生成は問題なく出来ているようなので、ソフトウェア無線の信号シミュレータに組み込もう。
P.S. 相関波形を確認するためにサンプリング周波数を24MHzにしたけれど、そもそもAFSのスロットは16.5MHzしかない。
受信機のサンプリング周波数は8～12MHzあたりになるかな。
現在、Version 5のドラフトがレビュー中のLunaNet Interoperability Specification、略してLNIS。
年明けにはリリース版が出そうなので、いまのうちに予習しておく。
LunaNetは、将来の月面、月近傍、月－地球間などの通信とナビゲーションの国際的なフレームワークの名称。
NASAが推進するLunar Communications Relay and Navigation System (LCRNS)に加えて、
ESAのMoonlight、JAXAのLNSS（Lunar Navigation Satellite System）が参加している。
これらの相互運用性を確保する仕様がLNISとなる。
LNISの測位サービスは、LANS（Lunar Augmented Navigation System）と呼ばれている。
このLANSは、GNSSのようなbroadcastの測位サービス以外に、特定のユーザに対するP2Pによる測位も提供する。
GNSSのようなbroadcastの測位信号は、AFS（Augmented Forward Signal）と呼ばれ、その仕様は
LunaNet Signal-In-Space Recommended Standard - Augmented Forward Signalで定義されている。
AFSの周波数は、2483.5-2500.0MHzのSバンドでほぼ決まりらしい。中心周波数は2492.028MHz。
測位信号は、IチャンネルとQチャンネルの両方で放送され、Qチャンネルは航法メッセージを含まないpilot信号となる。
変調方式はBPSKで、Iチャンネルは1.023Mcps、Qチャンネルは5.115Mcpsのチップレート。拡散符号ははまだ未定義。
Iチャンネルの航法メッセージのシンボルレートは500sps、Qチャンネルのpilot信号には20ビットのsecondary codeが重畳される。
このあたりはまだTBCなので、リリース版で変わってくるかも。
航法メッセージのフレーム長は12秒（6000シンボル）。各サブフレームは1/2 LDPCで符号化され、さらにinterleavingが掛けられる。
メッセージIDやコンテンツは決まっているけれど、具体的な中身は未定義。
これは、月の時刻系や座標系が決まらないと、なかなか具体化できないかも。
総じてL1CやL5のような今風の測位信号のアーキテクチャでありながら、変調方式はBPSKとシンプル。
まだTBCが多いけれど、AFSのシミュレータや受信機は、いまあるGPS信号シミュレータやPocketSDRをベースに開発できそう。
P.S. InsideGNSSの記事に、まだLSISのドラフトでは定義されていない拡散コードがなぜか掲載されている。
Iチャンネルの拡散符号は、ドラフトと同じ1.023Mcpsだけれども、2msのコード長で2046チップのGold符号らしい。
Qチャンネルの拡散符号は、L1Cpの拡散符号をそのまま流用するようだ。
コード長は2msで10230 チップのため、チップレートはドラフトと同じ5.115Mcpsになる。
Qチャンネルのpilot信号のoverlayコードは、secondaryだけではなく、さらにtertiary codeが重畳される。
Iチャンネルのdataフレーム長である12秒に同期できるけれど、実用上役に立つのかやや疑問。
そもそも、pilot信号って、GNSS受信機でもどの程度有効に活用されているのだろう？
いろいろと便利なのは理屈では分かるけれど、複雑な信号処理を追加してまでの利点があるのかな。
とりあえず、ユーザの要求に対して受信機側の自由度が高いことは良いことなので、Qチャンネルの受信機能も実装はする。
月面でGNSS信号を受信する測位ペイロードを搭載した月着陸船のBlue Ghostが来年1月中旬に打ち上げられる。
今年中の打ち上げ予定だったので少し遅れているけれど、Lunar GNSS Receiver Experiment（LuGRE）の成果が楽しみ。
受信機は、GPSとGalileoのL1/L5信号に対応。
アンテナは、9個のエレメントからなる3x3のアレーで、最大16dBのゲインが得られる。
Lauren Konitzer, et al., "Science Objectives and Investigations for the Lunar GNSS Receiver Experiment (LuGRE)," ION GNSS+ 2024.
いまさらながら、University of Texas at AustinのRadionavigation Laboratoryからの
スピンオフであるLOCUS LOCKというスタートアップを知る。
ソフトウェアGNSS受信機によるサービスを提供しており、RadioLionというフロントエンドは
かなりPocketSDRに近い。
2つのアンテナ入力に、それぞれMAX2771を3個が使われており、3周波対応。
画像からICの型番を読み取ってみると、I/QデータはXilinxのCoolRunner II（XC2C128）で集められて、
EZ-USB FX2LP（CY7C68013A-56）に送られているようだ。
Xona Space Systemsと組んで、LEO-PNTサービスに向けた受信機を提供するみたい。
P.S. 高須さんの過去の日記で紹介されていた。
Z. Clements, et al., "Optimized Bit-Packing for Bit-Wise Software-Defined GNSS Radio," ION GNSS+ 2021.
P.P.S. 綺麗にRaspberry Piの上に載っているけれど、結局USBケーブルで繋がるのね。
Nichols, H. A., "Locus Lock : a business proposal for the commercialization of software-defined GNSS," Thesis, 2022.
