日記・備考録 |
2005 |
2006 |
2007 |
2008 |
2009 |
2010 |
2011 |
2012 |
2013 |
2014 |
2015 |
2016 |
2017 |
2018 |
2019 |
2020 |
2021 | 2022/
1
2
3
4
5
6
7
8
9
10
11
12 |
2023 Search |
| December | January 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 |
February | Home |
-------------------------------------
2022/01/31 01:15 UTC頃 QZS-1R (J04, PRN196) アラートOFF。mosaic-X5は普通にQZSS 5衛星追尾している。F9P (F/W 1.00 HPG 1.30) でも5衛星追尾させようとしたが、CFG-GNSSでQZSS-Channels-max を5に設定しても4に戻ってしまう。F9Pの場合、CH数の関係で最大QZSS衛星数を4に制限している様だ。
補足: F9PのUBX-NAV-SATを良く見たらQS1, QS2, QS3, QS4, Q7と5衛星追尾していた。ただGLONASSを有効にすると4衛星しか追尾しなくなる。どういう基準で選択しているのかは不明だがやはりCH数の都合で衛星数を制限している様だ。(21:56追記)
....................................................................................................................................
Swift Navigation, Skylark Precise Positioning Service
いつの間にかSkylarkのサービスエリアとして日本が追加されている。中身の良く分からなかったSkylark自身の情報も追加されているが、PPP-RTK用SSR配信だけでなく、SwiftNav以外のRTK受信機でも使えるNTRIP/RTCM 3によるOSR配信も使える様。これはSSRからVRS点の観測データ (OSR) を生成しているのであろうか。といっても、正直、精度が "4 cm (50% accuracy mesured over 24 hours stationary)"、収束時間が "5s to 25 cm Accuracy (When using Starling positioning engine)" と、既存のRTK用補強サービスと比較して競争力がある性能には見えないが。プロモコードで1カ月間の無料トライアルが使える様なのでこれも試してみるかもしれない。
-------------------------------------
Hexagon/NovAtel, Firmware Downloads
NovAtel OEM7のF/Wが7.08.10にアップデート。Release NotesによればTerraStar C-PROの対応が主。後はログとしてBDS-3のB-CNAV1, 2, 3エフェメリス用メッセージが追加された位。B2b-PPP用航法データ出力には対応していない様。TerraStar C-PROは、4周波信号 (Galileo E1+E5a+E5b+E6, BDS: B1C+B2a+B2b+B3) を使って、収束時間を3分以内に高速化したグローバルPPP-AR (と思われる) "RTK From the Sky" 技術を売りにしている (参照)。ホントに性能が出るのかは評価してみたいが、無料トライアル期間が5日間しかないのだよなあ。手元のOEM729のF/Wをアップデートして申し込んでみるか考慮中。
....................................................................................................................................
献本頂きました (参照)。ありがとうございます。
....................................................................................................................................
また新しい受信機 (参照) をポチってしまった ...。1100 CHは所持する受信機の中では最もCH数が多い。ACEBOC (B2a+b) が受かるものも他にないはず。B2b (B-CNAV3, BD-PPP) 航法データ出力を期待しているのだが、マニュアル (参照、参照) を見る限り難しいかも。
....................................................................................................................................
遅ればせながら手元の1台のF9P F/Wを1.00 HPG 1.30にアップデート。ALESに接続してRTKの動作確認。UBX-RXM-RTCMを見るとMT1117 (QZSS MSM7) は認識され、UBX-NAV-SATのQS1〜3のDGNSSフィールドもY (使用) になっている。既報の通り、QZSSがRTK (ローバ側) で有効になった様。基準局モードでMT1117が出力できるかどうかは不明。少なくともu-center 21.09のCFG-MSGでは選択できなかったが、裏技があるかもしれない
補足: F/Wアップデート直後、動作が不安定になり正常にNMEAが出力されない不具合が発生したが、使用中のUSB以外のポート (I2C, UART1, UART2, SPI) をすべてdisableにすることで正常に復帰した。u-blox受信機は昔からシリアルI/F周りに問題が発生しやすい様。(18:30追記)
....................................................................................................................................
コア, 準天頂衛星システム (みちびき) 利用による高精度測位で自動化や作業効率の向上をもたらすCLAS対応小型GNSSモジュール「mosaic-CLAS」をベルギーSeptentrio N.V.と共同開発, 2022年2月18日より提供を開始, 2022年1月21日
とのこと。Septentrioの発表はまだ。ところでPolaNt-x MFって仕様上はL6対応していなのじゃないかな (参照) と思ったら、このカタログ (参照) では、Galileo E6は「×」で、QZSS E6 (?) /LEXは「〇」になっている。これは日本で売られているPolarNt-x MFは特別仕様ということ？ (対応周波数は「1160〜1252 MHz」となっていてL6が受かりそうには見えないが)
....................................................................................................................................
相関波形の3D表示機能を追加。移動体のマルチパス解析に使えるかなと思って。
-------------------------------------
GitHub Docs, 行終端を処理するようGitを設定する。
Gitってデフォルトでは自動的に行末文字を変更するんだ。直したはずが、戻ってたりして、謎だったのだが。
....................................................................................................................................
私自身もよく間違えるのだけど、Allan Deviationを「アラン分散」と呼ぶのは厳密には間違いなので注意。
-------------------------------------
Yahooニュース, 4周波帯対応で世界最小の衛星測位端末用アンテナ三菱電機が開発に成功, 電波新聞, 2022/1/17
さて「世界最小」と言うのは本当であろうか。例えばTallysman HC990EXF (参照) は筐体なしながら60Φ×25。VRSCに付属のアンテナはメーカ不明ながらサイズを測ってみると64x64x24。これらは三菱アンテナより少なくとも体積は小さそうだが。
-------------------------------------
単体試験は通らないんだけど、なぜかpocket_trk.pyは動くな。ということで、12MHz60秒分L6D信号捕捉・追尾・航法データ復調の実行時間が18.2秒。1/12の記録が77.7秒なので約4倍。2CHならリアルタイムで動きそう。
$ ../python/pocket_trk.py L6.bin -prn 194 -sig L6D -f 12
TIME(s) SIG PRN STATE LOCK(s) C/N0 (dB-Hz) COFF(ms) DOP(Hz) ADR(cyc) SYNC #NAV #ERR #LOL NER
60.00 L6D 194 LOCK 59.99 46.6 ||||||||||| 1.9508646 328.8 19805.0 BF- 59 0 0 0
TIME(s) = 18.203
....................................................................................................................................
NavIC (IRNSS) L5 SPSの追尾・航法データ復調に対応。これは簡単で2時間足らずで実装。
-------------------------------------
悔しいので、もう少し最適化。なんとかNumpyに勝ったかも。
Python C+AVX2+FFTW3F (ms) N mix_carr corr_std corr_fft mix_carr corr_std corr_fft 12000 0.0750 0.0281 0.3513 0.0281 0.0322 0.1385 16000 0.0969 0.0313 0.4688 0.0365 0.0375 0.1438 24000 0.1445 0.0441 0.7560 0.0469 0.0437 0.2604 32000 0.1939 0.0594 1.1394 0.0625 0.0531 0.2625 48000 0.2943 0.0813 2.2191 0.0814 0.0720 0.5347 96000 0.8328 0.1383 4.2632 0.1657 0.1344 1.7405
-------------------------------------
悔しいので、SIMD (AVX2+FMA) を使って最適化 (コンパイラオプション: gcc -Ofast -march=native)。まだ勝てん。Numpy凄い。
Python C+AVX2+FFTW3F (ms) N mix_carr corr_std corr_fft mix_carr corr_std corr_fft 12000 0.0952 0.0436 0.4847 0.0388 0.0458 0.1823 16000 0.1183 0.0454 0.6165 0.0418 0.0556 0.1840 24000 0.1962 0.0532 0.9821 0.0656 0.0614 0.3519 32000 0.2691 0.0818 1.5354 0.0872 0.1120 0.4254 48000 0.4660 0.1260 3.2578 0.1300 0.1317 0.8963 96000 1.2531 0.2136 7.3802 0.2346 0.2280 1.9904
-------------------------------------
FFT相関器高速化のついでに、搬送波ミキシングと標準相関器もCで書き直したんだけど、標準相関器は、なんと元のPythonコードの方がかなり速い。これはNumpyのdot() が速いということで、内部ではSIMD使って最適化していると思われる。Numpy凄い。なんかもうPythonのままでも良いような気がしてきた。(といってもPythonコードでは、新しいオブジェクト作ってコピー、を避けるのが難しいので高速化には限界があるのだが)
Python C+FFTW3F (ms) N mix_carr corr_std corr_fft mix_carr corr_std corr_fft 12000 0.1100 0.0400 0.4340 0.0440 0.1070 0.2250 16000 0.1240 0.0500 0.5711 0.0540 0.1450 0.2690 24000 0.1790 0.0630 0.9035 0.0810 0.2350 0.5020 32000 0.2280 0.0590 1.1650 0.0990 0.2930 0.5910 48000 0.3390 0.0960 2.7034 0.1550 0.4200 1.0071 96000 0.9659 0.1950 5.5019 0.2930 0.8530 3.0790
....................................................................................................................................
L6追尾・復調のリアルタイム化のため、FFT相関器をFFTWとCで書き直してctypesで呼びだす様に改修したのだけどうまく動いてくれない。追っていったら、単精度FFTW (fftw3f) ってN=46000を超えると正常動作しないみたい。12MHz x 4ms = 48000なのでもうちょっとなんだけど。FFTW再ビルドして直らないかなあ。
....................................................................................................................................
https://github.com/tomojitakasu/PocketSDR/tree/master/sample
PocketSDRでキャプチャしたサンプルIFデータのリンクを追加。キャプチャ環境は前と同じ (HX-CSX601A - RG58A/U (10m) - GPS410 (Splitter 4P, passive) - RG316/U (1.5m) - PocketSDR - PC/pocket_dump)。前に書いたように、MAX2771の出力するQサンプルの符号が反転している可能性が高いので、IQサンプルデータをPocketSDR AP以外で解析する場合は注意ください。
....................................................................................................................................
ver.0.6で追加したL6D, L6Eの単独追尾・復調のアルゴリズムだけど、複雑ではないので興味のある方はコード読んでみてください。大したことをしている訳ではないが、動くようになるまでちょっとは苦労している。そのうち、低C/N0での追尾性能とかをちゃんと測って、どこかで発表をするかもしれない。ちなみに、DLLもPLLも動いているので、少し機能追加すれば擬似距離や搬送波位相の生成も可能。あと、L6DとL6Eを同時追尾すれば信号電力3dB稼げるのでより実用的。低価格 L1+L6 2周波MADOCA-PPP受信機に応用できるかも。
-------------------------------------
rtklibexplorer, Google Smartphone Decimeter Challenge, January 10, 2022
昨年夏に行われたKaggleコンペGoogle Smartphone Decimeter Challengeに、rtklibexplorer版 demo5 RTKLIBコードを使って挑んでいる。当然そのままではまともなスコアは出ないので色々と修正を加えている訳だが、最終的に、本番5位相当 (参照) のスコア (2.15 m) が得られたとのこと。これは凄い。
-------------------------------------
坂井, 2周波SBASの最新動向, QBIC海外展開WG, Feb 4, 2021
この資料見るとL5 SBASの信号仕様はまだ未決定事項が多い様。あとSlide 9と現行BDSBASのPRNアサイン (参照) が合致していない。
補足: QZSS L5Sの現行仕様 (参照, IS-QZSS-TV-003) はここで書かれたL5 SBAS規格案とはまた違って、L5Iにマンチャスタ符号はのっていないし、プリアンブルは8ビット×3である。L5Qにはセカンダリコード (NH20) がのって、データはのっていない。まあ、L5 SBAS用の試験信号なので今後仕様変更がありそうである。SDRだと仕様変更はちょっとコードを直すだけで対応可能。(18:56追記)
-------------------------------------
https://github.com/tomojitakasu/PocketSDR
ver.0.6に更新。機能追加は、信号追尾: L6D, L6E、航法データ復調: L1CD, L2CM, L6D, L6E, G1CA, G2CA, B1I, B2I, B3I。残りはB1CD, B2AD, B2BIでこれはNB-LDPCデコーダが必要。G1CA、G2CAで結構ハミングエラーが出るんだけどこれはRTKLIB側の問題か ? あと、L5 SBASってまだちゃんと規格が決まっていない ? PRN130 (BD-SBAS, 参照) L5Iにセカンダリコードがのっているし、L5Qにはセカンダリコードがのっていない 。BDSからしたら、これはL5ではなくてB2aなのかもしれないけど。
....................................................................................................................................
L6D, L6E信号の (パイロット信号なし) 単独追尾、航法データ復調に成功。これで全信号追尾に対応 (OS, L2CL除く)。航法データ復調は残りL2CM, G1CA, G2CA, B1CD, B2AD, B2BI。
補足: 最適化して、12MHzサンプル60秒分L6D信号の捕捉・追尾・航法データ復調の実行時間が77.7秒 (LG Gram 17, i5-1035G7, シングルスレッド) 。Pythonではこれ位が限界そうで、リアルタイムは無理。Cで書き直せば5〜10倍にはできると思われるので、マルチスレッド化してノートPCで14CHは余裕。(22:50追記)
....................................................................................................................................
メモ: Windows 11 コマンドプロンプト、Power
ShellでANSIエスケープシーケンスを有効にするには、レジストリエディタで以下エントリを追加。(少し前までPower
Shellではデフォルトで有効になっていた様な気がするが、いつの間にか無効になってしまった様だ)
Computer - HKEY_CURRENT_USER - Console: Name:
VirtualTerminalLevel, Type: REG_DWORD, Data:
0x00000001 (1)
....................................................................................................................................
ようやく、PocketSDRのリアルタイム動作に成功。といっても1CHだけど。pocket_dumpに標準出力への出力機能、pocket_trk.pyに標準入力からの入力機能を追加して、パイプで接続して動かしている (右上)。12MHzサンプルの1CH L1C/A追尾でCPU負荷はpocket_dumpが4%、pocket_trk.pyが16%。CPU負荷にはまだ余裕はあるがPythonのマルチスレッド化があんまりうまくいっていない。同時受信しているmosaic-X5の出力を表示しているが (左下)、QZS-2 L1C/AのC/N0が43.5dB-Hz、pocket_trk.pyのC/N0が43.0dB-Hz。リアルタイム動作の問題はUSBのパケット落ちだったんだけど少しは安定したかなあという感じ。まだ、1000秒に1回位の頻度で落とすけど。ということでとりえず1CHならGalileo E6B航法データもリアルタイムで復調できそうなので、早くGalileo HAS ICD公開されないだろうか。
....................................................................................................................................
BDS B1I, B2I, B3Iも完了。残りはGPS: L2CM, GLONASS: G1CA, G2CA, QZSS: L6D, L6E, BDS: B1CD, B2AD, B2BI。
-------------------------------------
なんとか、L1CD航法データ (CNAV-2) 復調に成功。LDPCデコーダは正常に働いている様だ。さて、BDS用のNB-LDPCデコーダで良さそうなものないだろうか。
-------------------------------------
QZS-1 (J01, PRN193) がようやく正常に復帰。今回のサービス停止は17日6時間6分。1/26からのQZS-1R (J04, PRN196) 試験信号送信が通知されている (参照) が、アラートオフでの試験は異例なので、QZS-1の状況を踏まえた上でのサービス開始前倒しの意味合いが強いのかもしれない。
....................................................................................................................................
https://github.com/radfordneal/LDPC-codes
LDPCデコーダの実装は結構大変な仕事だと分かったので、おとなしく既存コードを利用させて頂くことにした。ということでこの公開コードを共有ライブラリ化してctypesで呼び出す。実は呼び出すだけでも調べることが多くて大変なんだけど。ちなみにBDS B1CD (B-CNAV1), B2AD (B-CNAV2), B2BI (B-CNAV3) は全部LDPCコード使っているので、全部の航法データ復調のためには避ける訳にいかない。
補足: ICDを良く読むとBDSのLDPCは64-ary LDPCと呼ぶ、NB (non-binary)-LDPCの様だ。これはparity check matrix (H-matrix) が0-1のバイナリでなく、0-63の多値を取るとのこと。ちょっと調べると、バイナリLDPCに比較して誤り訂正能力が上がるらしい。上記コードはバイナリLDPCしか取り扱えないみたいので、BDS航法データ復調には使えない。さて、どんどん深みにはまっていきそうだが、どうするか。(1/8追記)
....................................................................................................................................
Beyond your wall with Drogger, RWSみちびきRTK対応
この記事によると、F9P FW 1.00 HPG 1.30でQZSSがRTKに利用可能になったとのこと。マニュアルやデータシート等ではRTCM MSM QZSS (MT1114, 1115, 1117) 対応は追加されていないが、実は密かに対応済みということなのであろうか。時間がなくてF/W更新も行えていないのであるが、誰か追試をしてくれると嬉しい。
....................................................................................................................................
予想した通り、L1C航法データ復調は難解。汎用のLDPCデコーダどこかにないだろうか。と思ったらMATLABのCommunication Toolbox にはあるのか (参照)。GNU Radioにもあるのを見つけた (参照)。BDS B1C ICD (参照) のAnnexにもアルゴリズム解説が。この辺参照して実装するか。
-------------------------------------
https://github.com/tomojitakasu/PocketSDR
ver. 0.5に更新。主な変更は、Windows環境におけるpocket_dumpのデータ落ち対策。LIBUSB/WinUSBを捨てて、USBドライバとしてCyUSBを採用。その他細かい不具合修正。WSL2上でのコンボリューションコードデコード不具合も修正。
....................................................................................................................................
結局、昨年12/21に発生したQZS-1 (J01, PRN193) のトラブルは解消されず、アラートオンのまま年越し。
....................................................................................................................................
u-blox, ZED-F9P module
F9P FW 1.00 HPG 1.30がリリース。リリースノート (参照) によると主な変更点は (1) SPARTN対応、(2) CLAS CSSR対応、(3) PL (protection level) 出力、(4) BDS C37-63対応、(5) UART2でのUBX対応。RTCM MSM QZSS対応は見送り。(5) は結構嬉しい。(2) 用にUBX-RXM-QZSSL6メッセージが新設され、これを入力することによりCLASによるPPP-RTKが可能な様だ。UBX-RXM-QZSSL6の形式は2000ビットのL6フレームにちょっとした情報を付加すればよい (参照, 3.17.5)。D9Cがなくても、このメッセージを作ってあげればCLAS使えそうなのでPocketSDRで対応するかもしれない。
....................................................................................................................................
本年もよろしくお願いいたします。
....................................................................................................................................
| Home | by T.Takasu |