野辺山ヘリオグラフ(NoRH)とか。
CoD4MWをTPSにして和風にした感じ。風刺ありコメディありでシナリオも良いし。操作性がちょっと悪いのが難点。
あとグラがちょっと重くて、アップデートでだいぶ改善したけど、現状でもRTX3060で4K表示はかなり厳しいマップがある。グラ設定がほとんどできないから、Windowsで画面解像度を変えるしかない。FHDならリミットの30fpsまでしっかり出る。
細かいアップデートがいくつかあって、だいぶ遊びやすくなってきたけど、もう少し改善の余地あり、といった段階。
Windowsがハングアップするような謎の挙動、再び(3度も)発生。基本的には前回と同じだけど、スマホからリモートで入ったあとにしばらく操作していたら、リモート画面が真っ白になって、再接続しようにも同じように真っ白な画面になる挙動(アプリを再起動しても同様)。ノートPCからは問題なくリモートで入れるので、ホスト側の問題ではなさそうな感じ? とりあえずノートPCからリモートで再起動させたら、今度はスマホからも問題なく入れた。じゃあホスト側の問題?
しかし、ちょっと不具合頻発しすぎじゃないだろうか。リモートで再起動しかければ復帰するとはいえ。あと、スマホがあればリモートで入れるから安心、と思ってたのに、結局Windowsの実機が必要な状況が出てきてしまったな。冗長系、だいじ。SDRサーバーにNUCが動いてるけど、これはリモートで入る前提だからディスプレイとかマウスとかキーボードとかは全くついてないし。NUC側のWindowsが正常なのであれば、スマホからNUCに入って、NUCから問題のWindowsに接続して、みたいに段階を踏むことも不可能ではないだろうけど、さすがに面倒。
スマホのリモートデスクトップの解像度は、任意の値を選べるわけではなく、いくつかの選択肢から選ぶしかないらしい。一番大きなサイズは3972x1888で、これは4Kモニタの約1.03x0.87倍の大きさ。つまり横が広く高さが狭い。この解像度でログインするとChromeが高さ方向に圧縮されて、Windows再起動後にもその解像度が維持されるから、大きさを直すのが面倒くさい。接続する解像度はもう少し自由に選べたら良かったのに。
短期間で3回も発生したので、細々と手を入れてみた。といっても、マザボのユーティリティでいくつかのドライバを更新して、Razerのドッグを外して、程度だけど。Razerのドックは色々と前科があるからなぁ。どれが効いたのかわからないけど、今のところ件の不具合は発生していない。
今回の件とは無関係だけど、CドライブにRAID1で組んでいるNVMeの片方が、CrystalDiskInfoで70％を切っているのがちょっと心配。おそらくプライマリ側で書き込みキャッシュがOFFだから頻繁に書き込んでいて寿命を縮めている感じだと思う。PCを組んでから3年目に入ったあたりだから、線形で進むなら次の1年2年でどうこうなるようなものではないだろうけど、NVMeの交換も考えておかなくちゃ。ノートPCもWindows10だからリプレイス考えなきゃだし。問題を先送りにしていると一気にまとめてやって来る。。。
Webブラウザってアドレスバーに数字+/記号(例えば"3221225984/")が入ると、それをIPアドレスとして認識するんだな。例えばアドレスバーの"3221225984/"という文字列をコピーすると、クリップボードには"http://192.0.2.0/"という文字列が保存される。
試しにC#でConsole.WriteLine(System.Net.IPAddress.Parse("3221225984"));とやってみると192.0.2.0と表示されるから、32bit幅の数字をIPアドレスに変換するのは一般的な実装なのかな。
さすがに42540766411282592856903984951653826560とか20010DB8000000000000000000000000はブラウザやC#ではパースできなかった。もしかしたら別のフォーマットなのかもしれないけど。
C#のIPAddress.ParseのドキュメントにIPv4をパースするときの挙動が書いてある。ドットで分割さた数字が入力された場合、4個に分かれている場合は4個のオクテットとしてそれぞれを認識し、3個に分かれている場合は先頭の2オクテットと後ろの16bit、2個に分かれている場合は先頭の1オクテットと後ろの24bit、1個の場合(ドットがない場合)は32bitとしてパースするらしい。例えば"192.512"は"192.0.2.0"を表す。数字の前に0xプリアンブルがある場合は、ドット区切り内のそのグループだけを16進として認識するらしい。例えば”192.0x200"は"192.0.2.0"を表す。Chromeで試しても同じように認識する。
IPv4って結構いろいろな表現ができるんだな。知らなかった。Chromeに関して言えば、今回は"3221225984/"的な文字列が欲しかったわけで、それを勝手にフォーマットするのはどうなんだって話だけど、まあ、普通はURLパラメータとかの数字が欲しい場合は直接コピーすればいいから、大抵は問題にならないんだろう。
ちなみに、Chromeでは"3221225984/abc"や"3221225984/abc.html"はそのままコピーされるが、"3221225984/abc/"は"http://192.0.2.0/abc/"としてコピーされる。ちょっと謎い。
最近のWebブラウザ、アドレスバーと検索バーが同じUIなのが地味に不便なんだよなー。例えばlocalhostとかを検索したいときってどうやって検索してるんだろう? 普通は単体で検索するわけじゃないから問題ないのかな。とはいえ、英単語+"."記号+英単語みたいな命名(例えばpaint.netとか)って履いて捨てるほどあるだろうに、そういうのが全部ドメインを確保しているわけでもないし、セキュリティ的にもヤバそうだが(例えばpaint.netの公式サイトのURLはhttps://www.getpaint.net/で、アドレス"paint.net"にアクセスすると違うサイトが表示される)。
Mode-3/A/Cのフレーミングパルスだけ(コード0000)の応答、前回から1度も見かけていない。前回あれだけ大量に受信できたからそれなりに出てるんだろうと思ってたけど、実は結構レアなのかも。
GPSの位置推定、前回は正解値に対して400km弱の誤差があったけど、サブフレーム1のクロック補正を適用したら280m程度まで改善した。GPSが放送してる時刻って十分に高い精度で出しているものだと思ってたけど、結構誤差大きいんだな。受信できている6個のGPS衛星は、RMS0.45ms(135km)、最大0.6ms(180km)くらいズレてる。その点QZSはかなり優秀らしくて、受信できている2機はそれぞれ0.001ms(0.3km)と0.022ms(6.6km)くらい。無視できるほど小さいわけではないから、時刻補正は必須だけど。クロック補正ってなんでユーザーがやらなきゃいけないんだろうか。全ユーザーが全く同じ計算をするんだから、衛星側で対応して然るべきだろうに。GPSのクロック補正はせいぜいミリ秒オーダーしか調整できないから、時刻はそれ以上発散しないように時計側で補正しているはず。であればもっと細かく補正して放送したっていいはずなのにな。原子時計(に追従する水晶)は帯域幅が狭いから荒い補正しかできない、みたいなことなんだろうか。
相対論の効果を含めると259m程度。影響はかなり小さい(20m程度の改善)。
電離層遅延はほとんど効果なし。まっすぐ降ってきて10ns程度、斜めに入ってもその2倍、程度だから、擬似距離で10m未満くらいの影響。現在の精度だと効果無し。
試しに擬似距離の解決を連立方程式で実装してみた。条件が良ければ座標原点が地球中心でも5回程度で移動量がmmオーダーまで収束する。当たり前だけどブルートフォースより早い。ただ、擬似距離のオフセット(時計の時間差)が大きいと計算が発散する気がする。短時間で収束させるなら誤差は小さければ小さいほど良い。時計が進むか遅れるかでも特性がだいぶ違う。片方には2万km(67ms)程度離れていても50回程度のイテレーションで正しい位置に収束するけど、反対側は1万kmで収束に500回程度必要だし、2万km離すと正しい位置へ収束しなくなる。衛星の数を減らすと(8→4)、±2万kmくらいでも3000回程度で引き込める(±1.8万kmなら150回程度で引き込めるから、このあたりで発散し始める)。衛星の距離は地表を想定すると2万kmから4万km(GPS/QZSの場合)という感じだから、3万±1万km程度の範囲に収まる。適当な衛星の擬似距離を3万kmになるようにクロックオフセットの初期値を与えてやれば引き込めるかな。
「GPSのための実用プログラミング」3.5(82p)の説明だと、推定値+sと実測値を計算に使っているけど、推定値と実測値-sを計算に使うほうが収束が早いし、擬似距離のエラーが後に残らない気がする(推定値+sだと、擬似距離のオフセットが大きいと収束したあとに位置にズレが残る)。
自前で求めた擬似距離である程度位置推定が動くことが確認できたので、一旦C/Aコードの復調部を作り直し中。といっても、C/AコードからLNAVと擬似距離の取得までが全部密結合だから、結局全部作り直しになるんだけど。
論文とかで見るGPSの受信機(C/Aの復調部)のブロック図でレプリカの生成器がついているの(一度生成したシーケンスを使い回さないの)、なんとなく納得できたような気がする。色々と回り道をしてだんだん正解に近づいていってる感。まあ、今歩いている道が正しい道なのかもわからないけど、それもまた道ということで。
Early/Prompt/Lateの相関強度(2.4Mspsを2.4kptsで平均して1ksps)と、(E-L)/PをLPF(CICでデシメーションして1kHz→FIRで200HzLPF)に通したもの。E/P/Lの相関強度は、計算が間違っていなければ直読みしてGPSの信号強度になるはずだから、信号強度は3LSB程度かな。結構弱いけど、とはいえ1bit(符号のみ)よりはちょっと強い。まあ、信号強度が高い衛星を選んでいるからであって、他の衛星はもっと低いんだろうけど。
(E-L)/PはLPFを通したあとにC/AコードのNCO位相へフィードバックしている。受信開始直後はEが強かったけど、フィードバックしてPの強度が上がっている。ただ、C/Aコードの周期のオフセット(受信機のクロックエラー由来?)があるので、誤差がゼロに落ちきらず、PとEが同じくらいの高さで推移している(擬似距離にオフセットが乗る)。
位相でなく周波数へのフィードバックだと遅れが1段増えるので、発振(発散)する。PD制御なら発散も止まるだろうから、位相へ戻すPI制御か周波数へ戻すPD制御かの選択みたいな感じ。最終的には位相にしろ周波数にしろPIDパラメータのチューニングが鍵になりそうな感じもあるけど。
とりあえず、C/Aコードのトラッキングは動いている感じだし、次はキャリアのトラッキングを作らなきゃ。その後はBPSKの復調を作って……etc...
C/AコードのEarly/Prompt/Late、ノイズやマルチパスを含まない綺麗な信号の場合、±0chipの位置でビークになり、±1chipの位置でゼロになる三角形の形になる。
マルチパスが乗った場合、例えば2chip分遅れた信号を考えると、1chipの位置で相関値がゼロになり、2chipの位置で相関値はピーク(0chipと同じ値)になり、3chipで再びゼロに戻る。2chip以降に単発のマルチパスが乗った場合も同様。2chip以前にマルチパスが乗った場合、ダイレクトパス(0chip)のピークと重なるから、1chipの位置でゼロに落ちきらず、-1chipの傾斜と+1chipの傾斜は異なる角度になる。複数のマルチパスが重なった場合、fallスロープは複雑な形状になる。
前回書いた、5点で相関して内挿すればピーク位置が推定できるのでは?という話は、前後のスロープが同じ形であることを前提としているから、マルチパスを含む信号の場合は成立しない。(そもそも前回の時点では相関機の処理を誤って理解していたから、本来の処理であれば5点で相関させるとかの話は必要なくなった)
また、E/L点を±0.5chipの位置に置いた相関機の場合、マルチパスを含む信号を受信すると、Early点はマルチパスの影響はないが、Late点はマルチパスの影響があるから、Late側が高く出る。そのため、Prompt点は本来の0chipの位置より後ろ側にズレることになる。これは擬似距離が伸びる方向に作用する。0.5chipの位置は150mに相当するから、仰角の低い衛星からの信号が地面やビルに反射するとそれくらいのマルチパスが発生するかもしれない。衛星の配置が垂直軸に回転対称であることはないだろうから、低仰角の衛星にマルチパスが乗ると水平方向にズレることになる。
E/L点を±0.5chipでなく、もっと狭い場所に設定する受信機もあるらしい。狭くすると影響を受けるマルチパスの距離差が短くなる(例えば±0.1chipなら30m)から、市街地みたいに近距離の反射物が多い環境では厳しそうな気もするけど、影響を受けたところでその距離を短くできるならトータルの影響は少なくなる、みたいなことなのかな。E/P/Lを狭く設定した場合、帯域幅が狭いと相関値のピークが鈍るから、帯域幅を広げる(サンプリングレートも増やす)みたいなハード側の対応も必要らしい。まあ、普通のGPSの受信チップはフィルタ回路やC/Aコードのトラッキングはハードウェア実装だろうし、そのあたりをまとめてトータルでバランスを取って作っているんだろう。
C#のローカル関数、ブロックの外からは見えないという当たり前の挙動には納得感しかないけど、とはいえコンストラクタの最初のブロックだけは透過して見えてほしいという気がする。例えばrecord Hoge(int A) { public Hoge(double B) : this(F(B)) { static int F(double x) => (int)x; } }みたいな感じで、あるコンストラクタから別のコンストラクタを呼ぶときに値変換の関数をローカルで持ちたいみたいな用途。
C#のインターフェースで、System.Numerics.IAdditionOperatorsみたいな感じで、キャスト可能な組み合わせを列挙するインターフェースがあっても良さそうな気がする。数値計算(特に整数型を想定)のライブラリを作るときに欲しい機能。大抵はfloatとかdoubleとか使うから問題ないんだろうけど。
0 件のコメント:
コメントを投稿