Quantcast
Channel: OSQZSS
Viewing all 643 articles
Browse latest View live

GNSS Signal Transmission Using SDR


PocketSDR FE 4ANT

$
0
0
不慣れなKiCADに苦戦しつつも,ちまちまとPocketSDR FE 4CHを4アンテナ版に改造中.4チャンネル用の分配器を取り外し,それぞれのRFスイッチ入力にU.FLコネクタを繋げただけ.アンテナへの電力供給のためのBias-Tも,それぞれに追加.

とりあえずはオフラインでのビームフォーミングアルゴリズムの検証用.Raspberry Piでリアルタイムに動いてくれたら嬉しい.
P.S. メモJLCPCB: How to generate Gerber and Drill files in KiCAD 8?

DATAGNSS PocketSDR FE 4CH

$
0
0
DATAGNSS版のPocketSDR FE 4CHを入手したので,ケースを作る.https://www.datagnss.com/products/pocketsdr-gnss-receiver

基板の厚みが1.2mmとなり,SMAコネクタの基部のサイズも7mm角になっている.オリジナルのパネルではサイズが合わないので,Fusion 360のデータを編集.



Fusion 360からSTEPファイルにExportすると,丸穴のCカットが認識されず空洞になってしまう.STLへの変換であれば問題なさそうなので,こちらでJLC3DPへ発注.

製造条件はオリジナルと同じにしました.https://gpspp.sakura.ne.jp/diary202403.htm#0324

PocketSDR FE 4CH Case

$
0
0
JLC3DP に発注した3Dプリントのパネルが1週間で届いた。https://blog.goo.ne.jp/osqzss/e/2bfd609d9e6e2b10f9fe0faa765fe461

タカチのMX2-4-8と組み合わせて、PocketSDR FE 4CHのケースが完成。https://www.takachi-el.co.jp/products/MX


仕上がりも価格も納期も、全部満足。ただし、SLAのレジンがかなり硬いので、寸法に余裕がないと基板がスムーズにはまらないかも。
P.S. STLファイルをアップしておきます。ご利用ください。https://github.com/osqzss/PocketSDR/blob/master/FE_4CH/HW/v3.0/pocket_sdr_panel_v3_DATAGNSS.stl

PocketSDRのfftw_wisdom

$
0
0
PocketSDRでリアルタイム版のpocket_trkを実行すると、fftw_wisdom.txtが見つからないと警告がでる。これが何なのか分からずに疑問だったけれど、高橋先生の記事で説明されていた。https://s-taka.org/awesome-pocketsdr-realtime/
binディレクトリでfftw_wisdom.extを実行すると、fftw_wisdom.txtが生成される。これをpythonディレクトリにコピーして解決。

PyGPSClient

$
0
0
macOSでubloxのGNSS受信機を扱う必要があり、u-centerに代わるものはないかと探してみたら、PyGPSClientを発見。https://github.com/semuconsulting/PyGPSClient

Pythonで書かれたアプリで、Windowsでも動く。インターフェイスもu-centerより良い感じ。しばらく使ってみよう。

CLAS受信機ケース

$
0
0
JLC3DPとタカチの組み合わせでケースを作るのがすっかり楽しくなったので、ジオセンスのCLAS対応GNSS受信機であるF9PX1+D9CX1のケースを作製。https://qzss.go.jp/info/archive/geosense_221124.html


アンテナ位置を少し間違えたけれど、許容範囲。LEDでステータスが確認できなくなるけれど、基板むき出しで使うよりは良い。
これだけで、いつでもcmオーダーで測位できるのだから、とても便利。

PocketSDR勉強会

$
0
0
研究室のゼミに高須先生をお招きして、PocketSDRの勉強会を開催。配布資料が公開されています。https://gpspp.sakura.ne.jp/diary202411.htm#1119
デスクトップPCとRaspberry Piとのパフォーマンスの差は大きいけれど、8MHzサンプリング、10CHくらいならRaspberry Pi 4でも余裕でいけそう。
月測位受信機のためにSバンド対応のフロントエンドを作らねば。
P.S. Sバンド対応のGNSSフロントエンドICには、NTLabのNT1066を採用。https://ntlab.lt/product/nt1066/
評価基板は入手済みなので、EZ-USB FX2LPかFX3に繋げよう。


ちなみに、NT1068もSバンドが受信できるけれど、出力がIFのみでI/Qは非対応。https://ntlab.lt/wp-content/uploads/2024/04/Comparison_of_NT1065_NT1066_NT1068_NT1069_NT1062_v9-1.pdf
P.P.S. NT1066はJAVADのGNSS受信機にも採用されている?

Raspberry Pi in Space

PocketSDR FE 4ANTの完成

$
0
0
PocketSDR用の4アンテナ版FE 4CHであるFE 4ANTが完成。初期不良ですべての基板がUSBとして認識されない不具合が発生して、全滅かと意気消沈していましたが、高須さんが見事にFIXしてくださいました。ありがとうございます。

いつも通りに、タカチのアルミケースに合うパネルをJLC3PDで製造。ワンポイントアクセサリとしてシリコンのダンパを付けて、良い感じです。




ファームウェアはFE 4CHのものをそのまま使います。アプリ側にGNSS信号のbeamformingやnull steeringの処理を追加して、CRPA(Controlled Reception Pattern Antenna)をSDRでリアルタイムで動かしたい。
次は、FE 8CHを製造しよう。https://gpspp.sakura.ne.jp/diary202411.htm#1125

PocketSDR Device Driver Installation

$
0
0
私的メモ。
InfineonのサイトからEZ-USB FX2/FX3のドライバだけをダウンロードすることが出来なくなりました。PocketSDRのドライバのインストールがちょっと面倒になったので、その手順を高須さんのセミナ資料から抜粋。
1. Get "EZ-USB FX3 Software Development Kit (SDK)" for Windows. You need registration in the Infineon developer site to download the file.
2. Execute the SDK installer (ezusbfx3sdk_1.3.5_Windows_x32-x64.exe). The SDK is installed to "C:¥Program Files (x86)¥Cypress¥EZ-USB FX3 SDK¥1.3" as default.
3. If the error ".NET Framework 3.5 or later required" shown in the SDK installation, download .NET Framework 3.5 from Microsoft site and install it.
4. Attach a Pocket SDR FE 2CH or 4CH to the PC, open Device Manager, and look for the device "EZ-USB" (FE 2CH) or "FX3" (FE 4CH).
5. Select the device, right-click and execute "Update Driver", select "Browse my computer for drivers", and input the directory "driver" in SDK with "Include subfolders" checked.
6. If the driver properly installed, the device could be recognized as "Cypress FX2LP Sample Device" (FE 2CH) or "Cypress FX3 USB StreamerExample Device" (FE 4CH).
オリジナルのセミナ資料はこちら。https://gpspp.sakura.ne.jp/diary202411.htm#1119

PocketSDR FE 4ANTの動作試験

$
0
0
FE 4ANTを4分配の分配器に接続して、FE 4CHと同じセットアップで動作チェック。



実行したpocket_trk_test.batファイルは、以下の通りです。
@echo off
..\bin\pocket_trk.exe ^
-sig L1CA -prn 1-32 -sig L5I -prn 1-32 ^
-sig E1B -prn 1-36 -sig E5AI -prn 1-36 ^
-sig B1I -prn 1-62 -sig B3I -prn 1-62 ^
-c ../conf/pocket_L1L2L5L6_24MHz.conf


問題なく動作してくれています。それにしてもBeiDouの衛星数がすごいな。

LOCUS LOCK RadioLion

$
0
0
いまさらながら、University of Texas at AustinのRadionavigation LaboratoryからのスピンオフであるLOCUS LOCKというスタートアップを知る。https://locuslock.com/
ソフトウェアGNSS受信機によるサービスを提供しており、RadioLionというフロントエンドはかなりPocketSDRに近い。

2つのアンテナ入力に、それぞれMAX2771を3個が使われており、3周波対応。画像からICの型番を読み取ってみると、I/QデータはXilinxのCoolRunner II(XC2C128)で集められて、EZ-USB FX2LP(CY7C68013A-56)に送られているようだ。
Xona Space Systemsと組んで、LEO-PNTサービスに向けた受信機を提供するみたい。https://www.xonaspace.com/locuslockjoinsthexonapulsarecosystem

Blue Ghost Lunar Lander

$
0
0
月面でGNSS信号を受信する測位ペイロードを搭載した月着陸船のBlue Ghostが来年1月中旬に打ち上げられる。https://fireflyspace.com/missions/blue-ghost-mission-1/

今年中の打ち上げ予定だったので少し遅れているけれど、Lunar GNSS Receiver Experiment(LuGRE)の成果が楽しみ。https://www.nasa.gov/missions/artemis/clps/nasa-delivers-hardware-for-commercial-lunar-payload-mission/
受信機は、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.

LunaNet Interoperability Specification

$
0
0
現在、Version 5のドラフトがレビュー中のLunaNet Interoperability Specification、略してLNIS。年明けにはリリース版が出そうなので、いまのうちに予習しておく。https://www.nasa.gov/directorates/somd/space-communications-navigation-program/lunanet-interoperability-specification/


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バンドでほぼ決まりらしい。測位信号は、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のドラフトでは定義されていない拡散コードがなぜか掲載されている。https://insidegnss.com/the-augmented-forward-signal-afs-defining-the-navigation-signal-standard-for-future-lunar-missions/
Iチャンネルの拡散符号は、ドラフトと同じ1.023Mcpsだけれども、2msのコード長で2046チップのGold符号らしい。Qチャンネルの拡散符号は、L1Cpの拡散符号をそのまま流用するようだ。コード長は2msで10230 チップのため、チップレートはドラフトと同じ5.115Mcpsになる。
Qチャンネルのpilot信号のoverlayコードは、secondaryだけではなく、さらにtertiary codeが重畳される。Iチャンネルのdataフレーム長である12秒に同期できるけれど、実用上役に立つのかやや疑問。
そもそも、pilot信号って、GNSS受信機でもどの程度有効に活用されているのだろう?いろいろと便利なのは理屈では分かるけれど、複雑な信号処理を追加してまでの利点があるのかな。とりあえず、ユーザの要求に対して受信機側の自由度が高いことは良いことなので、Qチャンネルの受信機能も実装はする。

LANS AFSのベースバンドと信号捕捉

$
0
0
LANS AFSの拡散コードが分かったので、とりあえずデータやoverlay codeなしでベースバンド信号を生成してみました。受信機側の信号捕捉も確認できるよう、ドップラーとコード遅延を指定できるようにもしておきます。
IチャンネルとQチャンネル、それぞれのpower spectrumはこんな感じ。


これらの包絡域が、AFSのpower spectrumとして観測されることになります。

このベースバンド信号に対して、IチャンネルとQチャンネル、それぞれの信号捕捉をした結果がこちら。PRNは1番で、コード遅延は0.5ms、ドップラーは-2kHzで設定しています。


ベースバンド信号の生成は問題なく出来ているようなので、ソフトウェア無線の信号シミュレータに組み込もう。

pocket_sdr.py ver.0.13

$
0
0
GUI版のPocketSDRのアプリケーションであるpocket_sdr.pyの使い方が分からずにいたけれど、高須さんが設定手順の動画を公開してくださった。https://gpspp.sakura.ne.jp/diary202412.htm#1221


まわりが建物に囲まれたオフィスの窓際にアンテナを置いているので、可視衛星が少ないけれど、FE4CHで問題なく動いてくれた。
リアルタイムでPSDや相関波形が観測できるのは楽しいね。

NT1066でSバンド信号の受信

$
0
0
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)のパイロットチャンネルを受信するには、丁度良いかもしれない。

量子化ビット数の変換

$
0
0
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)の量子化でも良いかも。ロスも低減されるし、なにより閾値の誤差に対する感度が下がるのがありがたい。

PocketSDR FE 2CHの再頒布

$
0
0
DATAGNSSからPocketSDR FE 4CHが購入できるようになりましたが、FE 2CHを入手したいという問い合わせが何件かありましたので、またリピートで最小注文数だけ製作しました。
Boothショップにて再頒布いたしますので、入手をご希望の方はこの機会にどうぞ。https://rtklab.booth.pm/items/5673546


レジストの色指定を忘れていたため、今回は普通にグリーンです。アルミの角パイプからケースを切り出して加工するのがとても面倒ですし、FX2LPもEOLとのことなので、FE 2CHの製作はこれで最後にします。https://www.infineon.com/cms/en/product/promopages/ez-usb-fx2g3/
Viewing all 643 articles
Browse latest View live