『ゴースト・オブ・ヨウテイ』開発者いわく、舞台が北海道なのは“山と熊”がきっかけ。度重なる調査で見つけた、美と危険 - AUTOMATON
北海道が舞台のゲームはそもそも数が少ないので、ちょっと興味がありつつ、とはいえどうせS◯NYハード専売、数年後にPCへ移植してもPSNアカウント必須、とかだろうしな。
北海道が舞台のゲーム、Wikipediaの一覧を見るとそれなりの数があるけど、基本的にはADV(特に18禁作品)が多いらしい。この一覧に書いてある範囲だと、アクションゲームはHITMANだけかな? (「北海道」とか「日本」が舞台のゲームを遊びたいときにHITMANが適切かどうかはさておき)
話し上手な犬と聞き上手なギャルの最強コンビ。
久しぶりにWindowsがほぼハングアップの挙動。前にもあったような挙動。
タスクバーの時計は正常に動いている(1秒毎に秒が更新される)。最初の頃は、マウスやキーボード)は数秒とか数十秒遅れて反応するが、しばらくすると一切反応しなくなる。マウスもキーボードも使えないから、OSの操作が一切不能。Bluetooth(USBドングル)のイヤホンも切断されたりして、USB周りが応答しなくなっている感じもある。USB以外の反応は不明。少なくともEthernetは問題なく動く(リモートデスクトップで正常に入れる)から、すべてのIOが反応しなくなるわけではない。一応マザボにはおそらくチップセット直結であろうCOMポートの端子があるけど、シリアルマウスなど持っているわけもなく。
以前はノートPCからshutdownでリモートから再起動を叩いてたんだけど、今回はスマホのリモートデスクトップアプリで入ってみた。リモートデスクトップから入れば問題なく操作できるのは以前とも同様の挙動。再起動すれば問題なく使えるのも、以前と同様。
Windowsの操作ができなくなる不具合、低頻度ではあるけど、ある程度再現性はあるんだよなぁ。
数日前からRazerマウスが調子悪かったから、またRazerのバグなんか? ただ、再起動したときにOneDriveのバックアップを有効化にするか確認するダイアログが出たんだよな。これも前に出た気がする。OneDriveの処理が走ってストレージ周りに負荷がかかって、それが引き金になってRazerの挙動が不安定になって、最終的にWindowsがハングアップする、みたいな挙動なんだろうか。
スマホのリモートデスクトップは結構便利だけど、スマホのネイティブ解像度で表示するとPC側のウインドウサイズが変わるので後々不便(例えばChromeは画面サイズが保存されるから、再起動後も配置が大きく変わってしまう)。解像度の設定を4K(3840x2160)に設定してスケーリングさせればPC側でウインドウ配置が変わることはなくなるけど、表示が見づらそうだな。
久しぶりにWindows Update以外で再起動したけど、やっぱりたまにシンプルな再起動をやるとめちゃくちゃ早くて驚くんだよなー。こんなに早いなら週に何回か再起動してRAMを掃除するのもアリだよなー。って、PCがハングアップするたびに同じこと考えてる。
ここ1ヶ月近く、だいぶ前に買ったPCゲーを遊び直しているので、ストレージ周りは比較的負荷が高い(アクセスが多い)状態が続いていた気もする。AFOPで遊んでいたときも頻繁に再起動していれば問題なかったし、ディスクアクセス周りの負荷が蓄積すると臨界点を超えたときに急に顕在化してくるのかも。このPCはCドライブが2xNVMeのRAID1、データドライブが3xHDDのRAID5、ゲーム本体みたいな壊れても問題ないデータは生のNVMeに入れているので、ストレージ周りは結構独特の構成で、ストレージ周りで不具合が出ても、まあ、そりゃねぇ……という感じではある。
データ保存のソリューション、なんかもっといい方法ないものかなぁ。データドライブに入っているデータ、大部分(10TB程度)はコールドデータだから、HDDに入れておく必要はないんだよな。とは言いつつ、Blu-ray200枚に焼くなんてのもアホらしいし。数百TBくらいまでならHDDに入れておくのがコスパ高いんだろうなー。ペタバイトを超えるような量で大レイテンシを許容できるならLTOあたりを使ったほうが良いんだろうけど。
***
25日に見かけたヘリ
ほぼ直上通過。体感的にはかなり高い場所を飛んでいた。Fr24の表示は無し。
この機体が通過した周辺の時間は、かなり大量のMode-3/A/Cリプライが入っていた。
ドットのマーカーは、橙がSPIアサートを、赤がXビットアサートを、紫がSPIアサートかつXビットアサートを、緑がそれ以外のMode-3/A/Cリプライを示している。また薄緑の縦の線(大量に連続すると塗りつぶしに見える)はMode-3/A/Cとしてデコードできなかった信号(Mode-Sや明らかに重なったMode-3/A/C等)を示している。
この中で、Mode-CはFL63(QFE1.6km)が一番下でその上はFL210(QFE6.3km)になる。FL63はインコヒーレント、FL210はコヒーレントなリプライだった。ヘリに乗せるような比較的安価なMode-3/A/Cトランスポンダはインコヒーレントだと考えると、FL63がこのヘリの応答かな?
Mode-3/A/Cを受信してもどの機体からのリプライかがわからないのが結構厳しいんだよなぁ。FIM-92とか91短SAMのIFFアンテナ、どっかに落ちてないかなぁ…… 試しにebayで探してみたけど、さすがにFIM-92のIFFアンテナは売ってないっぽい(AIM-7とかAIM-9のフィンとかは(本物かはさておき)売ってるから、もしかしたらと思って探してみたんだが)。
まあ、92とか91のIFFアンテナはともかくとして、ログペリなり八木なり、適当な指向性のアンテナは1本あると便利そう。普段はダイポールで受信して、必要に応じて別のドングルで受信するような運用で。ログペリはamazonでも売ってるけど、帯域が0.6-6GHzあたりだから、SDRで遊ぶにはちょっと小さいんだよな。0.1-1GHzあたりの製品があればUHFの広い範囲+αをカバーできるからSDRで遊ぶのに便利なんだけど、PCBで作るにはこのあたりは大きすぎるんだろうな。
試しに波形ビューで位相を表示する機能を追加してみた
ピーク-6dBまでのサンプルに対して位相をドットで表示している。この波形は2つのリプライ(Mode-3/A 2421とMode-3/A/C 2420/FL140)が重なっている。コヒーレントなレスポンスの場合、一つのトランスポンダからの応答は直線状の位相を示し、二つのトランスポンダからの応答が重なった場合はその中間値的な(厳密に言えば振幅で重み付けした)位相になる。振幅が近く目視で分離しづらい場合でも、位相を見れば容易に分離できる。
インコヒーレントっぽい応答の例
フレームパルスだけの応答
結構珍しいけど、受信できるときは多くのレスポンスがある。ATCでスコーク0000を割り当てることってあるんだろうか。欧州だと割り当て禁止みたいな運用らしい。高度計から有効な高度が得られない場合(例えば起動直後とか)にフレーミングパルスのみのMode-C応答が返るらしいけど、こんなに大量に(間欠的に8時間程度の応答ということは、おそらく単一の機体からではない)高度応答を返さないトランスポンダがあるんだろうか?
フレーミングパルスとXパルスの不思議な応答。一応F1, X, F3の位相は直線に乗ってる。ふーむ…… コード0000はMode-Cっぽいけど、Mode-CトランスポンダがXパルスを出すんだろうか? XパルスはMode-3専用だと思ってたんだが。それともMode-3がコード0000に設定されていたんだんだろうか?
蛍光灯を点けたり消したりしたときのノイズ
点けるときには比較的長いノイズが、消すときには短パルス的なノイズが出る感じ?
電子ライター
さすがに出力が低いから同軸線の直近あたりで着火させないと微動だにしないけど。ドングルにアンテナ直結して直近で着火すれば単パルス程度には入る。トリガのテストくらいには使えるけど、パルス幅が短すぎてデータロガー(特にゲート時間の自動設定とか)のテストにはちと厳しい。
回避指示の調整は機体に搭載されている TCAS に割り当てられている固有番号の大小によって行われる。例えば大きい方が上昇、小さい方が降下というように。
この説明どうなんだろ。そんな場当たり的なアルゴリズムに何十人とか何百人とかの人命を預けているものなの?
ACASはMode-Cを使っているから、相手機の高度や高度変化率を把握している(もちろん、自機も既知)。彼我の高度が既知なんだから、上に避けるべきか下に避けるべきかは簡単なモデルで判定できるはず。あるいは、Mode-S非対応機から避ける場合(小型機を避けるには必須能力)、Mode-CトランスポンダはACASと通信することはできないし、そもそもMode-Cトランスポンダには固有番号といったものは存在しないから、比較はできない。
双方共にMode-S対応かつTCAS II搭載機である場合は双方向に通信して回避指示が出せるけど、それにしたってMode-C相手と同様に、高度・高度変化に応じて回避指示を出すはず(Mode-C相手の場合は相手が直線運動を行う前提で、Mode-S相手の場合は相手と同じ方向に動かないように、という指示になるはず)。双方ともにMode-S対応かつTCAS II対応で、双方が同じ高度(Mode-S分解能の25ft目盛り)を高度変化なしに飛行している場合(あるいは全く同じ高度・高度変化率で飛行している場合)はICAOアドレスに応じてどちらが上に行くかを判断することはできるだろうけど、これがプライマリではないはず。
Mode-A/Cのトランスポンダ、10秒位でタイムアウトさせてリプライを自走させるような仕組みがあれば便利なのにな。それがあれば受動なシステムでも航空機が存在していることを検出できる。空港の近くとかTCAS機が近くにいる場合はそれらのインテロゲーションで自走はリセットされるから、他のレーダーに対してはほとんど影響はない。そもそも通常のレーダーは数秒に1度程度のランダムな応答は無視するし(そうじゃなきゃACASからの影響が出てくる)。
***
L1 C/Aに対して128個のPRNの相関処理
左側のいくつかはGPS、右側のいくつかはQZS、その間はSBAS。20msのコヒーレント積分だけど、SBASも結構強く相関が出ている。
L1 C/Aを逆拡散してLNAVを取り取り出して、衛星位置を求めるようなところまではとりあえず動くようになってきた。GPSの週内の秒数は1サブフレーム(6秒)毎、週数は5サブフレーム(30秒)毎に取得できる(衛星位置の計算に週数は不要)。UTCとの差はサブフレーム4のページ18で12.5分毎に取得できる。GPSとUTCは現在18秒の差があるから、SGP4の時刻はGPS時刻から18秒遅い時間を指定する。それで計算すると、誤差が少ない衛星は200m程度、誤差が大きい衛星は7kmくらいずれる(GPSは誤差少なめ、QZSは誤差多め)。
衛星8基(6xGPS、2xQZS)からの擬似距離を元に、ブルートフォース的に受信地点を推定してみると(初期値地球中心)、実際の受信地点から400kmくらいの位置が得られた。だいぶ精度が悪い。実際の受信位置から距離を計算したものと、実際に計測した擬似距離は、本来は一次関数に乗るはずだけど、ある程度大きな誤差がある。擬似距離の計測をミスってるとか?
今回は、LNAVは正秒を基準に放送していて、受信機は座標系に固定されていると想定して、LNAVのサブフレーム開始点のタイムスタンプ(ファイル内位置)を擬似距離として利用している。つまり地上からすべての衛星の時計を同時に観測してその時刻を見ているのではなく、すべての衛星から同時に出された信号を受信した時刻を使用している。
L1 C/Aの受信は二乗検波的な感じでやっている。本来は再生検波で同相軸だけ使うべきなんだろうけど。もちろん、搬送波の位相ロックも行っていない。搬送波にロックできれば衛星との距離変化を精密に求められるようになるから、高精度な受信機を作ろうとすれば必須なんだろうけど。
コードのトラッキングは、物の本だとEarly/Prompt/Lateの3点で相関処理を行う、みたいな説明だけど、5点で相関処理を行って前後2点から直線を伸ばして交点の位置を求める、みたいな処理でサンプリングレート未満の時間分解能で計測する、みたいな処理って無いんだろうか?
GPSのアルマナックって、どうして全部の衛星から同じタイミングで放送しているんだろうか。例えばランダムなパターンで(必要な個数の中でシャッフルして)放送すれば、1個の衛星から受信するより3個の衛星から受信すれば約3倍の速度でアルマナックを取得できる、みたいな仕組みであっても良かったはずなのに。特定の衛星のアルマナックだけ必要なときに、それ以外のタイミングでは受信機を一時的に止めておく、みたいな処理をやりたいときは周期的な放送は便利だろうけど、特定の衛星の軌道要素が知りたいなんて需要も無いだろうし(強いて言えばSVヘルスで使えないことが既知の衛星を読み飛ばすとか?)。
あと、GPSクロックってなんで1.5秒刻みなんだろう? 航法メッセージの長さは6秒なんだから、GPSクロックも6秒刻みでもいいはずなのに。そうすれば「29bitの19LSBsの17MSBs」みたいな変な切り取り方をせず、「27bitの17LSBs」として扱えるのに。
***
C#のreadonly record struct Hoge(int a, ... );みたいなやつでhoge = hoge with { a = 1 };みたいな構文を使うことがあるけど、楽に書ける構文が実装されないかなー。hoge.a with= 1;みたいな感じで記述できれば便利そう。まあ、readonly structを頻繁に書き換えるな、という話ではあるんだけど。
LINQのZipみたいな感じでSpanで使えるforeach用の構文無いかな。ReadOnlySpan<int>hoge,fuga;/* hoge.Length=fuga.Length */があったとして、foreach(var(a,b)in(hoge,fuga))みたいな感じで。インデックスが不要なときでもfor(int i=0;i<hoge.Length;i++){var(a,b)=(hoge[i],fuga[i]); ... }みたいに書かなきゃいけないのはちょっと冗長。
0 件のコメント:
コメントを投稿