小ネタ

　IC-R6でALOS-4 SARの電波を受信。PALSAR-3はfc1257.5MHz、BW84MHz、8kWくらいだから、そりゃ簡単な受信機でもAM復調でガーガー聞こえるか。/* R6は1300MHzあたりまで受信できる */

「自分が住んでいる場所を誰でも見られる(ただし関東に限る)」ぐぬぬ。。。

***

　この間Pixel6aを買ったばかりだけど、またAndroidデバイスを買ってみた。といってもFire HD 10だけど。

　このデバイスをAndroidと読んでいいのかはちょっと怪しい。ChromeとかPlayストアとかが無いので。とはいえ、中身はAndroidだし、Chromium系ブラウザが入っているから、クラウド系のサービスは一通り使える。もちろんAmazonのサービスはKindleやPrimeビデオをはじめとしてネイティブのアプリが入っている。

　初期設定だとネットワークが不安定で、1日に1回程度再起動する必要がある。設定で省電力モードからネットワークのスリープを止めれば安定して使えるようになる。

　画面サイズはA5程度なので、Kindleでマンガを見開きで読むのにもちょうどいい大きさ。PDFも1ページを表示して支障のない程度。自分は主にPDFビューアーを目的として買った。が、Kindleのマンガを読むのにも結構使ってる。PC(24")だとちょっとでかすぎるし、スマホだと小さすぎるし、Kindle PWもマンガを読むにはちょっと小さいけど、10”だと見開きでちょうどいい。

　SilkブラウザはAndroidのChromeと同様に、ブラウザ内でPDFを開くことはできない。KindleアプリでもPDFは開けるようだが、自分はAdobe Acrobatをインストールした。便利機能はAdobeのサブスクだけど、無料(&アカウントなし)でもPDFを開くだけなら支障なく使える。タブ機能はないけど、ファイルごとにAcrobatも複数起動してくれるから、OSのタスクマネージャー(3個並んだ右端の■ボタン)からファイルを切り替えられる。画面の下左寄りから弓なりに右へスワイプしてタスクを切り替える、みたいな機能がないから、アプリを切り替えるには2,3回タップしなきゃいけないので、ファイルを頻繁に取っ替え引っ替えして開くのには向かないけど、数分に1回切り替える程度ならそれほど煩雑ではないかな。

　FireタブレットはBluetoothでのファイル交換に対応しているから、PCからPDFをBluetoothで転送すれば、PCでダウンロードしたPDFをタブレットで読むこともできる。転送時にはタブレット側で通知から受信を開始する必要があるけど、一旦受信を始めればスリープにできるから、転送の遅さはあまり気にならない。ただしBluetoothのファイル転送は同時に複数個行うことはできず、またキューイングもできないから、複数のファイルを転送する場合は1個1個順番に転送する必要がある。大容量とか複数個のファイルを転送したいならUSBで直結するほうが楽そう。

　タブレットは見た目の割に結構軽いので、持っていてもあまり苦にならない。とはいえスマホの2倍程度の重さはあるから、気がつくと腕がつかれている。PCの前に延々同じ姿勢で座ってPDFを読み続けるのと、適当に動きながらタブレットで読むのと、どっちもどっちという感じ。

　YouTubeはSilkブラウザで再生できる。デスクトップ版を開けばPnPっぽい表示(PCでiキーを押したときの表示)もできる。さすがに動作はカクつくけど、動画の視聴は1080pなら問題ない。2160pだと途切れるけど、タブの解像度が1920x1200なので事実上支障なし。YouTubeはタブを切り替えると再生が止まる。YouTube Musicはブラウザをバックグラウンドにしても再生できる。とはいえ、タブで音楽を再生してもな…… Amazon Musicアプリだとアートワークと歌詞を表示できるが、かといって表示しておいたところで。

　カメラの性能はお世辞にも良いとは言えない。ついていることに意味がある、という程度。例えば、ブラウザベースのQRコードリーダーを使えば(ある程度大きなQRコードであれば)読むことはできる。PCで読んでいるWebサイトからQRコードを作ってSilkブラウザで認識して開いたり、といったりもできる。カメラアプリにQRデコーダがついてればよかったのに。最短撮影距離がちょっと遠めなので小さいQRコードはピンボケして認識できない。

　理想的にはChromeがインストールできれば開いているタブの共有とかができて便利なんだけど。そうでなくても、せめてPC版Chromeの拡張としてSilkブラウザにURLを転送できるような機能があればいいのに。その拡張機能でLAN内でのファイル転送にも対応していればなお良し。まあ、そういう便利機能は無いので、工夫して頑張るしかない。意外と不便はしていない。

　URLの共有用に、PCでHTTPサーバーを立ててリダイレクトするようなプログラムを作ってみた。C#のHttpListenerで待って、指定されたURLに飛ぶJavaScriptを返すだけの単純な機能。HttpListenerは管理者権限が必要で、かつWindows側で任意のポートを開く必要もあるので、ちょっと面倒。あと、結構不便。PC側にうまくGUIを作り込めばもう少し便利になるのかもしれないけど。QRコードならPC側はクリック2回、タブレット側は新しいタブを開いてQRリーダーにアクセスしてカメラの使用許可を出して認識したURLをクリック。手間は多いけどスムーズに操作できる。

***

　GPSで言うところのECI座標系(20.3.3.4.3.3.2)、X軸を春分点に固定したECIじゃなくて、X軸を任意の方向に取る慣性固定座標系(=回転座標系(ECEF)に対して)という程度の意味なのかな。

　20.3.3.4.3.4曰く、衛星から受信機までの距離はECI座標系で計算しろ、とのことなので、そういうふうに処理

　↑回転させない場合(ECEFで更新)

　↑回転させる場合(ECIで更新)

　水平面の誤差が大幅に減って、水平面は分散の中心でほとんど正しい位置が得られている。

　対流圏遅延量のモデル

　横軸が高度[km]、縦軸が遅延量[m]。仰角90度なら高度7kmあたりで1m未満になる。このモデルだと対流圏を出たあたりでも傾斜としてはあまり変わらない。このモデルってどの程度の高度まで近似してるんだろう。

　↑対流圏遅延量の補正なし

　↑対流圏遅延量の補正あり

　若干改善。まだ少し高く出ている感じはあるけど、かなり良くなった。

　正解値は地理院地図から拾った緯度・経度・高度に、国土地理院のジオイド計算機で求めたジオイド高を足して、楕円体高に変換した数値をECEFに変換して、推定位置とのENUを求めている。つまりこの正解値は地面の高さを採用しているが、受信アンテナは2階のベランダから少し上げた場所に設置しているから、地面から6m弱の高さにある。そう考えるとほとんど誤差のない結果が得られていると考えてもいいかもしれない。

　適当に書いた復調・位置推定コードでこんなに確度の良さそうな結果が得られるなんて思ってなかったから、評価方法なんて考えてない。どうしたものか。

　時間ドメインでの誤差

　横軸が秒、縦軸が基準位置からのズレ(3D)。完全にランダムじゃなくて、数秒くらいの周期で振動している感じがある。

　測位計算を1kHz(受信機時刻系)で行って、1000ポイント(1秒)の動きをプロット

　ランダム誤差というよりふらふらと動き回るような誤差。キャリア/コードのトラッキングのパラメータを変えるとふらつき具合が変わるから、アナログ部の特性かな? アナログ処理の調整メンドクセ。。。

　そもそも、C/Aコードは1chipで300mだから、10mオーダーの精度にこだわってもあまり意味が……という感じがなきにしもあらず。とはいえ、位相は細かく数えようとすれば1/100くらいは行けるだろうし、短期的には5m程度の精度があっても良さそうな気もする。C/A位相(というか周波数)へのフィードバック帯域幅を減らして(フィードバックゲインを絞って)やれば固定受信で長時間の安定性は改善するはずだけど、今度は受信開始時のセトリングとか、動きながら受信した場合の特性が犠牲になる。本来は適当な運動モデルを想定して、それにあったチューニングをするべきなんだろう。固定受信ならしっかり絞った帯域幅で、自動車なら少し加速度を広めに、みたいな感じで。

　屋根の上に三脚で1m程度浮かせてGPSアンテナを置いて、なるべく物陰が無いように受信。10Hz60秒分をプロット

　7xGPS+2xQZSで9個の衛星を受信できて、DOPはG2.76,P2.29,H1.47,V1.76,T1.55と、かなり良くなっている。受信位置のLat/LngはPixel6aで撮影したアンテナ部の写真から、高さは地理院地図の標高とジオイド高、それと地面からの高さをレーザー距離計で計測したものを足している。ほぼ誤差無しで計測できている。若干南北方向にズレているかな、という気はするけど、十分誤差の範囲だろう。

　スマホのGNSSとは1時間差くらい(1時間くらいサンプリングして、解析は最初の1分程度、写真は撤収時に撮影)。上の図はWGS84空間での相対航法を見ている感じ。受信機の外側の長期的な誤差要因(衛星のクロックエラー、電離層遅延、対流圏遅延、等)は打ち消して、主にコード追尾や測位計算の誤差だけが見えているはず(スマホはGLONASSとかBeiDouとかも使っているはずだけど)。Google Pixelに乗っているちゃんとした受信チップで得た位置情報とほぼ差がないので、正しく測位計算ができている、と考えていいはず。

　ちなみに、屋根の上に登るときのはしごの長さは6m弱。サムはこの2倍弱の高さを登っているのか。そして僕はそれに対して「はしごが短すぎる！」とか言ってるわけか。

　復調処理は、9衛星の60秒分の復調で55秒(シングルスレッド、デバッグビルド)程度。かろうじて等倍以上、、、程度。衛星ごとにスレッドを分けてやればもう少し早くなるはずだし、リリースビルドにしてもだいぶ早くなるはずだけど。

　元々1分40秒くらいかかっていて、Complex32を(int,int)のタプルで似たような処理にすると結構早くなる(それが50秒台)。で、readonly record struct Complex32I(int,int)を作ってみると、1分台まで遅くなる。実はC#のstructって遅い? それともDebugビルドだから?

　OSが珍しい挙動の調子の悪さで再起動をかけたので、Visual Studioのプロファイラが使えるようになった。で、CPU使用率を見てみると、カーネルが99.8%位を占めている。このカーネルって何なんだろう。言語のコア部分とか? OSの起動時間が2,3日経つとまたプロファイラが使えなくなる。定期的に再起動しろっていう話なんだけど、地味に不便。

　GPSの測位計算で、ECEFでなくECIで距離を測る必要があるのは、光速度不変の法則(いわゆる特殊相対性理論)による効果なんだろうか?

　相対性理論がどれくらい身近であるかを説明する文章でGPSがよく出てくるけど、今まで触っていた範囲(af0、af1、af2、Δtr、のあたり)はすべてのユーザーが等しく同じように処理する必要があるから、本来はユーザーが行う必要がない処理のはず、という気がしていた。言うなれば’80年代の宇宙技術の未熟さによるものをユーザー(受信機)に押し付けたものであって、身近な部分(ユーザーセグメント)で相対論を処理する必要はないのではないか、と。

　ECEFではなくECIで計算しなきゃいけない、というのはユーザー固有の処理なので、このあたりはなんとなく「身近な相対論効果」っぽい感じがする。

　L5 SBASの話題で、コードの長期的なジッタを1usから1msへ広げる、というような話題が出てくる。L1 SBAS(静止衛星からの放送専用)の場合は衛星にはベントパイプを乗せてメッセージは地上で作るから、地上の高精度なクロックを使うことができ、非常に少ないジッタ(それでも距離換算300m)の信号を作ることができる。L5 SBASでは非静止衛星からの放送が追加されて(主に極地向けサービス)、ベントパイプではなくオンボードでメッセージを作るようになった。そうすると、コードの基準は高精度な地上のクロックではなく、オンボードのクロックを使うわけで、ジッタを増やす必要がある。どれくらいの範囲に広げればいいかというと、既存の測位信号と同じ程度に設定すれば、既存のクロックを流用できる。ということで、af0で補正できる程度の1msへ広げる、ということらしい。

　ということは、最近のミッション機器でも高精度なタイミングでの放送はできないのか。クロック(原子時計+水晶)と放送機器の間にNCOを1段挟んでやれば正しいタイミングで航法メッセージを出せそうだけど、そう簡単な話ではないのか。

　SBAS関連の細かい話、ググってもあまり出てこないんだけど、IS-GPS-200とかIS-QZSS-PNTみたいなドキュメントって公開されてないのか? SBASを作ったのがICAOだとすると、非公開かなぁ。

　日本で遊ぶならQZSS SLASを受信するのがいいのかな? これはたぶんドキュメントが公開されている。

　SLASはビットレートが高い代わりにCRCとFECで誤り訂正・誤り検出ができる。FECは畳み込み符号で拘束長7の171,133だって。おっ、ISDB-Tで見たやつだッ!

　測位演算もある程度のところまで来たし、気分転換にSLASの復調。

　試しに適当なコードを500spsでBPSK復調して、適当な長さ(とりあえず30秒)のブロックでビタビ復号(硬判定)してみると、プリアンブルっぽいビット列がチラホラと出てくる。ペイロードの中にもプリアンブルに一致するビット列があるから正確に250の整数倍のタイミングではないけど、いくつかの間隔を積算すれば750bit間隔で同じプリアンブルが現れたり、隣のプリアンブルと250bit差っぽかったり、という感じで、いかにもそれらしい雰囲気はある。

　SLASは1パケットの長さが1秒で、航法メッセージ(6秒)に同期して6個のパケットが送られてくる。航法メッセージにタイミングを合わせてSLASの3000symbolsをビタビ復号すると1500bitsが得られて、250bit毎の最初の8bitは概ねプリアンブルに一致する。頭に6bit分のゼロをパディングして256bit(32byte)にしたうえで、CRC24を計算すると、正しくゼロが得られる。このCRCはプリアンブルとかメッセージタイプも含めて計算するようだ。

　時々プリアンブルが正しくなかったり、CRCが正しくないパケットがあるけど、ビット反転させたら正しいCRCに戻ったりするので、デコーダのBPSK復調エラーらしい。20codes/bitの航法メッセージに合わせたデコーダだから、2codes/symbolのSLASのデコードはちょっと厳しい。現在は2symbolのコヒーレント積分が閾値未満になったらビットが反転したと判定する、みたいな処理だから、これが誤ると正しく復調できなくなる。1パケットより長い周期でビット反転が起きるのであれば、プリアンブルを見てパケット全体をビット反転させる、みたいなアルゴリズムでおおよそ除去できる(途中のパケットは復号できないけど)。これならBPSKの180度の曖昧さも除去できて一石二鳥。

　同期検波できているならビット反転の問題もないし、ビタビ復号で柔判定が使えるのだが、今のところFLLしか実装していない。同期検波も結局180度の曖昧さの解決判定が必要になるしな。十分なSNRが確保できる遊びの復調なら非同期検波のほうがはるかに楽に処理できる。/* 本物のGPS受信機(というかBPSKデコーダ)って搬送波の180度の曖昧さはどうやって除去しているんだろう? */

　SLASのビタビ復号は6秒ブロックで処理するより、もう少し小さいブロックで処理したほうがいいかもしれない。1秒周期の頭に6bit分を含めて、後ろはビタビ復号の収束用に32bit程度をつけて、SLASメッセージ1個毎にビタビ復号を行う。こうすればパディングビットをマスクして末尾を切り捨てれば直接バイト列として使えるから、CRC判定だったり後処理だったりが楽になる。CRCは24bitだから、ペイロードだけほしいならCRC判定後に3バイト分切り詰めればいい。

　ISDB-Tではビタビ復号用に1パケット(204バイト)の末尾が常に固定(同期ワード)という仕様だけど、SLASはそういう便利機能は無いのかな? 自分が実装したビタビ復号処理は簡易化のために一定のブロックサイズを頭からパスメトリックを計算して後ろからビット列に戻す処理だけど、本来は(専用の計算回路を作るのであれば)1symbolを入れたら少し前の1bitが出てくる、みたいな逐次処理になっているはずだから、そういう場合は末尾を固定値にするみたいな必要もないはず。SLASもそういう処理を想定しているのかな。あるいは、プリアンブルのパターン(3種類)は航法メッセージのタイミングと比較することで既知になるから、次のメッセージのプリアンブルまで含めて復調して、その時のレジスタ値を使うのかもしれない。

　久しぶりにISDB-Tもちょっと触りたいなー。ワンセグを受信して受信機のクロックエラーを推定するようなやつを作りたい(手持ちのRTL-SDR blogドングルのクロックエラーが5ppmを超えているような疑惑があるので、定量的に測る機能が欲しい)。

　あと、R820は1ppm単位でしか調整できないけど、Si5351Bを使えば外部電圧でクロックを微調整できるはずだから、ボリュームとかで調整できるようにすれば短期的には手動で1ppm未満のクロックが作れる。もっとも、VCO感度は55mV/ppmくらいらしいから、細かく追い込めるかは微妙だけど。Si5351ってどれくらい自由にクロックを作れるんだっけ? VC入力で微調整できる、コヒーレントな28.8MHzと10MHzが作れれば便利そうだなって。まあ、ウチには10MHz入力対応の計器なんぞはないわけだが。/* SIGのDSO、微妙にクロックがズレてるのがムカつくんだよなー。10MHz入力に対応していてくれれば。。。それがないのが廉価帯たる所以 */

　RTL2832はR820とかEEPROMにI2Cで通信できるし、確かlibrtlsdrにはI2Cを叩くようなコマンドもあったはずだけど、rtl_tcp.exeにはI2C系のコマンドがないのがちょっと残念。I2Cが使えればI2C制御のPLLを追加するとか色々遊べるのにな。まあ、そういう使い方をしたい人間なんて世界中でも2桁いるかどうか程度だろうし、そいつらのためにわざわざコード書くとも思えないし。ほしいなら自分でビルドしろって話だろうし。

***

　Excelでctrl-zがファイル間で共有な問題。

　Excelは普通に起動すると一つのプログラムで複数のファイルを開いている、という認識になるらしい。要するに見えないところでMDI(Multiple Document Interface)的な挙動になっているようだ。例えばタスクバーのExcelをホイール中クリックで新しいウインドウを開いた場合、それは複数のExcelが起動していても、内部的には一つのExcelのインスタンスであって、操作履歴も共有している。

　Excelの新しいインスタンスを作成するには/xオプションを与えて起動すればいい(自分の環境ではAlt押し起動は使えなかった)。例えばWin-Rでexcel /xを起動すれば新しいインスタンスで起動できる。

　それが面倒な場合は/xオプション付きのショートカットを作るという手もある。デスクトップで"C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE" /xのショートカットを作って、タスクバーにドラッグ・アンド・ドロップして、デスクトップのショートカットを削除、といった手順で、新しいインスタンスを起動するボタンをタスクバーに追加できる。そのボタンをクリックすると、Excelの新しいインスタンスを起動できる。ただし新しいインスタンスも古いインスタンスと同じグループに入る。

　Wikipedia曰く、最近のMS OfficeはMTI(Multiple Top-level Interface)と呼ばれるものらしい。複数のドキュメントでプロセスを共有するからリソース(メモリとか)の消費量を下げられる、ということらしい。

　事務用の低リソースなPCでも比較的快適に使えるように、ということでMTI設計になったのかな。特にRAM空間が狭いパソコンだと仮想メモリの退避が行われてパフォーマンスめちゃくちゃ落ちる、みたいな状況を避けたかったのかも。

　Excelのインスタンスを複数作った状態。1個で数十MBから100MB程度のメモリを消費するので、RAMに余裕のないPCで大量のファイルを開こうとするとちょっと厳しいかも。とはいえ、RAMに余裕のあるPC向けの機能(毎回インスタンスを用意する、操作履歴を分離する)があってもいいと思うんだけどなぁ。そのための/xオプションか。exeのプロパティでデフォルトのオプションを指定できれば便利だけど、そういう機能はなさそう。

***

　デスストで超弦理論って出てきたっけ? ゲーム内で「ひも」とか「ストランド」がキーワードになっているし、「ヒッグス」も出てきたけど、超弦理論は見かけてない気がする。DS2では小さいキャラクターが出てくるけど、ミクロな世界に降りていったりするんだろうか? ヒッグスは人名由来だからキャラ名に使いやすいけど、stringは使いづらそうだな。

/* デススト、車を引っ張るための「ストランド」がほしいよなぁ。物理エンジンの変な挙動で車がスタックすることがよくあるから、牽引できたら便利そうなんだが */