2025年4月2日水曜日

小ネタ









 4月1日の動画……じゃ、無い、だと!?

 本国のアカウントだと#aprilfoolのタグが付いてるんだけど、日本語アカウントだとそういうのが無くて、投稿日も含めてマジネタかと思ってしまう。日本時間だと4月2日0時の投稿だけど、欧州だと4月1日の午後だし、アメリカだと4月1日の午前なんだよな。英語圏のアカウントで4月1日中に投稿するようにして、他言語版はそれに歩調を合わせて、とするとタイムゾーンが早いエリアだとエイプリルーフルが終わったあとになっちゃうんだな。




 面白かった。ストーリーはあまり長くなくて、サクサク読めば1時間足らずで終わる。

 PV段階だとIDPAっぽい感じを想像していたけど、ちょっと違うベクトル。ゲームセンターのシューティングゲームっぽい感じなのかな?

 UIがシームレスでポップなのは結構好き。

 アーケードはかなり奥深い。レートが全然上がらない。手ブレはランダムっぽい感じがあるけど、マウスのコントロールである程度軽減できるような気もする。上手い人がやると上手そう。

 頑張ってもAAまでしか行けない。それもあまり好みじゃないプレイスタイルでようやく。Steamの実績によると20%位のプレイヤーがSまで行ってるらしい。SSSまで行っている人も結構いる。どうやったらそこまで行けるのか全く見えない。



 3Dプリント(PLA?)のヘルメット(自転車用)って、相当危険そうな気がするけどなぁ(某社のPV)。自転車のヘルメットが義務化されているわけじゃないだろうし、安全基準に則ったものを使わないと罰則がある、というわけでもないはずだから、安全性なんて気にせず好きなの使おうって話なんだろうけど。



 SETI的な文脈で、進んだ文明は強い電波を出している(文明の程度と電波強度が比例する)と想定している場合があるけど、どうなんだろうか。電波ってかなり限られた資源なので、人口が増えると一人あたりの電波強度は落とさざるを得ず、惑星全体での電波放射量はある程度のところでリミットするはず(少なくとも指数関数的な増加よりは対数関数的な増加になるはず)。

 技術レベルが発達すれば単位情報あたりの通信に必要なSNRはある程度下がるだろうし、人口密度が高くなったり、あるいは経済的に余裕がある場合は、通信網の基地局をより高密度にできるから、電波強度はさほど高い必要はないはず。ラジオとかテレビみたいな放送にしても、利便性を考えれば移動体通信にデータを乗せるほうが楽そうな気がする。地球だってラジオやテレビはradikoやTVerで配信するような時代になってきているし。SNRにはシャノン限界みたいな下限があるとしても、基地局を密にするとか色々な工夫次第で電波強度は下げられるはず。というか下げてセルを小さくしていかないと莫大な人口をカバーしきれないはず。

 レーダーみたいなものにしても、例えばアメリカではADS-Bを必須化して民間の空港ではPSRを削減するみたいな方向になっているし、軍用レーダーが必要だとしても、信号処理が発達すれば電波強度は低くていいわけだし、むしろ敵に攻撃されるのを防ぐためにLPIレーダーみたいなものが普及するだろうし。SETIで探す対象になるような進んだ文明が惑星内で戦争をするような状況かどうかは別にしても、民間用レーダーだって符号変調とかを使う利点はあるわけだから、巨大な尖頭電力を持ったレーダーに期待してSETIの探索条件を設定するのは厳しい気がする。


 光学SETI(OSETI)専門の人が書いた本で「緑色のレーザーを見たらそれはYAGレーザーだと思って間違いない」みたいな話が出てくるんだけど、高出力レーザーだけじゃなく、民生用のレーザーポインターとかも含めて説明しているのが怪しい気がする。レーザーポインターで使われているレーザーダイオードってYAGとは別物じゃね?

 OSETIでYAGの第2高調波をターゲットにする理由が、「肉眼で見えるから放射がわかりやすくて安全」という理由らしくて、うーん。スペクトルが太陽と同じ恒星系が相手ならその理論は成り立つけど、長波長側の恒星系のほうが宇宙での分布としては多いだろうしなぁ。もっとも、長波長側はエネルギーが低いから生命が誕生したとしても知的生命体(人類と交信できる程度の技術レベル)まで進化しないはずだ、という理由で除外しているわけだが。それとて自分が使える望遠鏡が可視光付近しか観測できないからそういう理論を作っているだけじゃないか、という気もするけど。



 25日22時55分頃に外を歩いていたら火球が見えた。東北からも見えたらしい。火球ってかなり広い範囲から見えるんだな。

 火球を専門的に取り扱っている研究組織とかないものかと思ってちょっとググってみたけど、なさそう。あくまでも有志が設置したカメラで写ったらラッキー、みたいな感じなのかな。これだけ広範囲で見えるなら、100kmくらいの間隔で全天観測していれば問題ないのかな。1箇所で天気が悪かったってこれだけ広範囲で見えるなら他の観測点からは見えるだろうし。あとはどうやって検出するかだけど、今は観測報告から録画を確認するみたいな感じなのかな。それにしたって今後はAIで自動的に怪しい現象をリストアップするとかの方向になるだろうし。

 国土交通省/気象庁とか、ウェザーニューズとか、全国的にカメラを配置している組織は色々あるだろうし、用途から感度とかもある程度高いはずだし、火球の観測とかに使おうって話はないんだろうか。個人が問い合わせたところで対応してくれるとも思えないけど、NAOJとかある程度権威のある組織から「何月何日何時何分頃、緯度xxx・経度yyyの方向を向いていた画像データありませんか」みたいに問い合わせたら対応してくれないのかな。NAOJも予算不足とか色々大変でわざわざ火球なんか関わってられねぇって話はありそうだけど。



 新しいマウス、3日くらい使ったところで充電インジケーターが赤く点滅を始めた。ユーティリティのアイコンだとまだ50%程度残ってそうなのだが。2日毎程度で充電したほうが良さげ。DODを低めに維持したいなら毎日充電でいい。

 充電ステータスLED、サイドボタンの手前側にあって、普通に右側に置いたときにLEDが顔に正対するからかなり見やすくて良い。マウスに内蔵したRGB LEDは設定した色を維持したまま、インジケータだけ小さく光る。このデザインはかなり好き。

 ただ、RGBで光るのって、手のひらで握り込むと見えなくなる場所のロゴだけなんだよな。ゲーム中はマウスを動かしているからロゴが光っているけど、このときは見えない。手を離すと見えるようになるけど、数分程度で消えてしまう。Razerのマウスは手のひら部のロゴとホイールがRGBで光るから、持っていてもホイールは光っているのが見える。とはいえ、これをやろうとすると結構複雑な光学系が必要になる(RazerはわざわざLED専用の基板をFPCで接続している)から、コスト的にかなり厳しいはず。エントリー価格帯のブランドとしてはロゴを光らせるのが精一杯、充電インジケータを別につけるだけかなり頑張ってそう。

 Type-Cコネクタは少し奥まった場所にあるけど、穴がテーパーになっていて挿しやすい。こういう使いやすさに直結する細かい作り込みはさすが日本の老舗メーカーって感じ。



 ACSを遊んでて、移動が結構楽なのが好きなポイント。山をまっすぐ突っ切ろうとすると木とか崖が邪魔だけど、ナビに従って道を走る分にはかなり楽。Zでオートランにしてマウスで方向だけ微調整するなら片手だけである程度の速度で移動できるから、移動中に軽く飲み物を飲んだりなにかつまんだりができる。たとえば某配送ゲームは移動がゲームのメインコンテンツなのに(だからこそ)移動の難易度が高くて、つねに両手操作が必要だったから、長時間の移動中にプレイヤーが飲み物を飲んだりすらできないのが不満だった(ゲームの中の主人公は好きなタイミングで飲食できるのに!)。

 ゲーム内に温泉(湯気が立ち上るちょっとした池)があるけど、温泉に入ってもなんのアクションも無い。が、フォトモードに入ると画面が真っ白になって何も撮影できなくなる。海外版だとなにかアクションがあって、それに応じてフォトモードにも光を入れているけど、日本版ではアクションだけ削ってフォトモードはそのまま、みたいなことなんだろうか? 疲労ゲージがあるわけでもないし、戦闘すると体力は削れるけど、敵から離れれば自動回復するし、温泉に入って回復するようなゲームシステムじゃないからな。

 ファストトラベルで季節が変わるのはいいとしても、キャラクター切替時にも季節が変わるのが結構面倒なんだよなー。ステルスキャラで敵の大型拠点をクリアリングしてからゴリ押しキャラに切り替えて倉庫の扉を壊す、みたいな遊びができない。攻略前に季節を切り替えてタイマーをリセットしてから爆速でクリアリングしてキャラ切り替え、ならいいのかもしれないけど。ちゃんとそれぞれのキャラで遊べよ、ってことなんだろうけど。


 ACS、ゲーム規模がクソでかいのにリリース後何日か経って安定性改善の1.0.1を配布しただけで、自分の環境では安定性は全く問題ないし、バグも全然無いし、すごく良くできていると思う(稀にステルスキルした敵がバネ仕掛けのごとく起き上がってくるから、KIAは確実に確認する必要があるけど)。

 遊んでいて体験が単調になりすぎるということもあまり無い。敵が少なすぎたらプレイ時間の大半が移動で占められてしまうし、敵が多すぎたら数十秒歩いてすぐ戦闘の繰り返しになる。敵の多い場所と少ない場所の調整がかなりちょうどいい。例えば敵の少ない市街地なら自由に動き回ってその場で戦闘をしても敵が集まってくることはないし、敵が多い市街地で戦闘を始めればあっという間に増援が集まってきて乱戦が始まる。戦闘に飽きたときは街を出ればすぐ敵の密度が減るから気ままに歩き回れる。それに敵の難易度調整もかなり良くて、うまく隠れながら進めばほとんど戦闘は起こらないけど、時々はしっかり負けるし、負けたときもほとんどの場合は1,2回やればしっかり勝てる(同じ敵に負け続けて萎えることがない)。

 強いて言うならマップ&クエストボードがでかすぎてどれだけプレイしても埋まらねぇって問題はあるけど、それは嬉しい悲鳴というやつだし。

 個人的には近接より遠距離のほうが好きだけど、とはいえSCAR-Hとか使うわけにもいかないしね。クナイを強化するとサプ付き1911くらいには便利だから、近接しか使えないというわけでもないし。クナイを持てる数はあまり多くないけど、銃弾と違って回収して再利用できるし。スキルを上手く組み合わせれば大人数も一気にステルスで殲滅できるっぽい雰囲気があるし。

 一部のゲームはUbiから分離するらしいけど、ゴーストリコンとかはUbiで開発を続けるらしいし、俄然ゴーストリコンの次回作も期待したい。



 先日、たまたま機会があったので札幌に行ってきた。いつぶりだろう? 最近札幌行ってないなーと言ってるあいだにコロナ禍に入ったから、10年ぶりとか? いや、そんなわけ……

 あんまり時間がなかったのでヨドバシをちょっと眺めて科学館に寄って帰ってきた。

 ヨドバシ狭くなった? 前はもっと広かったような気がするんだけど。あと、前はもっと活気があった気がする。今回は特に欲しいものがあるわけでもないので、軽く眺めて終了。最近のノートPCってすげー高いのな。MacBook Proの最小構成のほうが安いんじゃねって気がするんだが。自分の用途的にx86のWindowsが条件だからMacとかChromebookは選択肢外だけど。あとはDJIのジンバルが置いてあったから、ちょっと触ってみたり。NATOポートって本当にNATOなんだな、とか。

 科学館は正直ちょっと期待外れ。土地柄というか、自然科学系の簡単な展示しかない。宇宙論的な説明(ビッグバンや大規模構造)が少し、太陽系の説明がもう少し、北海道の地質に関する説明も少し、人体に関する説明が少し多め、残りの大部分は雪関連の説明、以上。という感じ。大部分はボタンを押して説明動画を見るだけの展示だし。もう少し色々あるとしても。地元に自然以外の題材が何も無い田舎の科学館って雰囲気。

 旭川の科学館のほうがもう少し展示内容が豊富だと思う(展示内容のベクトルはほとんど同じだけど)。スタッフの人数も旭川のほうが多い。札幌は展示スペースにスタッフが皆無で、警備員の制服を着た人が何人か歩いている程度。旭川はボランティアスタッフが多いから、気になったことがあったらすぐに聞ける。まあ、青少年科学館(「子供向けの施設」)に期待しすぎるなと言うことなのかもしれないけど。そもそも札幌は建物が狭いから展示を増やせないしスタッフが立つスペースもない、ということもあるのかな。旭川は広い分で展示もスタッフも増やせる。あとは来場者数の違いありそう。札幌も休憩スペースとかで結構場所食ってるから展示増やそうと思ったら増やせそうだけどなぁ。学校単位とかでまとめて団体を受け入れようとするとあれくらいの空間が無いとだめなんだろうか。それにしちゃ展示スペース狭くねえかって気がするが。



 rtlsdr.dllを直接叩くロガーアプリを作ってみた。いちいちrtl_tcpを起動したりIPアドレスやポート番号を管理するのも面倒でな。。。

 とりあえず周波数・サンプリングレートを固定して、固定時間でファイルを分割して、一定時間を過ぎたら自動的に削除して、というような処理(自動削除はON/OFF可能)。ついでにヒストグラムとスペクトルの表示も行っている。

 自動分割・削除機能を使うと、30分でファイルを区切って、サンプリング終了後2時間待って削除する、みたいな処理を裏で勝手にやってくれるので、事前に発生が予想できないイベント(通信・放送)を記録したいときに便利なはず。削除待ちを12時間とかに設定しておけば、寝ている間に起きたイベントも起きてから取り出せる。

 ただ、ウチのPCは全部SSDしか乗っていないから、総書き込み容量が怖いので、この使い方はできない。メインPCのデータドライブはHDDだけど、3本でRAID5を組んでいるので、連続書き込みはちょっとやりたくない(単に容量の問題もある)。当面は連続記録は使わず必要なときだけ単純な記録として運用かな。気が向いたら4TBくらいのHDDを買ってメインPCに増設しよう。2.4Mspsで24時間記録して420GB程度だから、2ch同時に記録しても1TB/day程度、24時間程度で自動削除なら埋まることはない。

 あとはキャリアスケルチでスケルチが開く前/閉じた後の適当な範囲も含めて、信号があるときだけ記録するような機能があると便利かな。アマチュアとかエアバンドとかMode-3/A/Cとかを受信するときに。

 欲を言えば追加のデコード機能(たとえばMode-3/A/Cとか)やその表示機能もあれば便利だけど、さすがに機能を増やしすぎると使いづらいからなぁ。


 rtlsdrのReadAsyncをTask.Runで包んでIAsyncEnumeratorで返すようなラッパーを作ってあるので、GUIスレッドからawaitで呼んでGUIスレッド内でファイルへ書き込んだりスペクトルを更新したりみたいな機能が一通り走る。最初設計思想を把握できなくて結構大きな手戻りが発生したけど、実装し直したらかなり信頼性の高い記録ソフトが作れた。前に作ったやつはISDB-T(フルセグ)用にドングル3本同時サンプリングが標準機能だったから(1chとか2chとか単独でも使えるけど)、1chだけ記録したいときにはちょっと機能が過剰だった。



 GNSSのオンボードクロック、10.23MHzに対してGPSが約-4.6mHz、QZSSが約-850mHz、くらいに調整しているらしい。軌道半径が1.6倍になるだけでこんなに違うのか。

 軌道が低いほうが速度が早くて特殊論での遅れが大きくなるし、重力が強いから一般論での遅れが大きくなる。地上と時間の進みが同じになるのは高度約3000kmの円軌道だから、それより高度が高いGPSは地上より時間の進みが早くなるし、さらに高いQZSはさらに早くなる。とはいえ、すごい効くんだな。


 GPS Block IIIF(2027年打上げ予定)、WikipediaによるとUSBに対応したよ、とのこと。むしろGPS衛星ってUSB使ってなかったんか。軍用衛星と民間衛星はアーキテクチャが違うみたいなことなのかな。通信衛星とか放送衛星はXとかK前後とか使うことも多いし、観測衛星とかでもXとかを使ってるはずなのに、今更USBに対応したところで、という感がなきにしもあらず。半世紀以上も前の通信プロトコルやぞ……



 C#でIEnumerable<T?>をOfType<T>でIEnumerable<T>に変換するやつ、IEnumerable<(int,T?)>をOfType<(int,T)>でIEnumerable<(int,T)>に変換しても、T?がnullの要素を除外できない。nullを除外するにはWhereを使わなきゃいけないし、その後でnullableのnullチェックを行わないと警告が出るから、OfTypeも呼ばなきゃいけない。結構面倒。


 C#のLibraryImport、ノーコストで使えると思ってたけど、Visual Studioが勝手にunsafeを許可してたんだな…… 自分のコードでunsafeを宣言しなければ問題ないんだけど。

 charポインタを受け取って文字列を書き込むタイプの関数をLibraryImportで呼ぶ方法がググっても出てこない。なんとなくそれっぽく実装してみて、いちおう動いているけど、本当に使えるのかはよくわからない。

 C# 8.0からローカル関数に属性を付けれるようになったけど、LibraryImportはpartial属性が必要だから、ローカル関数にできない。DllImportならローカル関数で宣言できるから、ラッパー関数の内側に隠すことで、外部に公開せずに済む。privateでクラス内に閉じ込めているとはいえ、クラス内の他の処理から必要ないならローカル関数内に隠せるほうが便利だけど、それができない。

 LibraryImport、いまいち便利な感じがしないな。マルチプラットフォーム云々とかも、そもそもDLL呼ぶ時点でWindows専用だろって感じだし。


 StringBuilderで固定長を確保した場合、GC.AllocateUninitializedArrayでpinned=falseな配列を確保するけど、これをDLLに渡してヌル終端文字列を書き込んでもらった場合、sb.ToString().TrimEnd('\0')と処理した場合に、最初に確保したバッファにゴミデータが書き込まれていた場合、それが読み出されてしまわないんだろうか? あと、確保した配列はピン留めされていないけど、直接DLLに渡して大丈夫なんだろうか? DLL呼び出しの例を探すとたいていこの書き方だし、うまいこと対応してくれてるんだろうけども。

 結局、そこら辺が心配なら自分でピン留めした配列を確保して(or小さい配列ならstackallocで確保して)、IndexOf<byte>(0)で最初のヌル文字を探して、みたいにしなきゃいけないのかな。それならDllImport/StringBuilderを使う利点はないから、LibraryImportでもいいのか(ローカル関数で宣言できないデメリットだけ残るけど)。


2025年3月26日水曜日

小ネタ


 オペアンプをコンパレーターとして使って見る:今岡通博の俺流!組み込み用語解説(12)(1/2 ページ) - MONOist

 直流用フォトカプラをAC100Vに繋いでた人。この人にこの手の記事書かせ続けて大丈夫? 個人運営ブログの学習メモとかじゃあるまいし、「モノづくりスペシャリストのための情報ポータル」を謳うサイトが組み込み(電子回路)をターゲットに解説記事を連載するなら、その分野である程度経験のある人に頼んだほうがいいと思うんだけど。



 今週は某ゲームを遊び込んでたので進捗だめでーす。

 YouTubeのアルゴリズムの問題なのか、某ゲーム、「殴ったり燃やしたりしても良いコンテンツ」として扱われているような印象になってて残念。大手ゲームメディアとかだとそこまで火をつけて遊んでるわけじゃないし、というか普通のゲームとそう変わらない扱いだし、一部のメディア(主にYouTubeとか個人運営サイトの「反応まとめ」的なコンテンツ)がそういう遊びをしてるんだろうけど。/* そういうコンテンツ1回も見たことないしなんなら時々チャンネル自体ブロックしてるのにそれでもなお執拗にクリックベイトをオススメしてくるYouTube君のアルゴリズムさぁ。。。 */


 プレイキャラの切り替えができるようになるまでプレイ時間24時間くらいかかった。あちこち寄り道したとはいえ、序盤だけでこのボリュームか……

 ゲーム内時間経過で一定時間が経つと次のファストトラベルで季節が入れ替わるシステムは面白いけど、それがゲーム性に反映されているかというと微妙な気がする。冬は走るのも遅いし、遮蔽になる植生もないし、植物に入るとカサカサ音がなったり屋根の上を歩いたら氷柱が落ちたり。冬はちょっと面倒。せめて積もった雪に隠れることができればよかったんだけどな。夏と冬でゲーム性結構変わる気がする。うまく季節に合わせた立ち回りを考えないと。

 エンジンが同じだからか、GRBPっぽさもある。GRBPは平面方向でしか動けなかったけど、ACSはパルクール的に建物の上とかに行けるのが楽しい。操作性に若干難ありという感じだけど。

 オープンワールドは移動が多くて、ACSは世界観的に車とか飛行機とかヘリコプターとかが使えないから、とにかく走るしかない(or馬に乗る)。GRBPと違って体力ゲージが無いから、走るときに体力管理が必要なのが嬉しい。あと崖を滑り降りるときにHPが削られないし。Zキーで自動で歩き/走りしてくれるるけど、それでも進行方向は自分で調整しなきゃいけないから、長距離を移動したいときにちょっと面倒。まっすぐ突っ切ろうとすると地形が厳しいし、道なりに行こうとすると遠回りだし。せめて馬に乗ってるときは目的地の近くまでは自動で歩いてほしいな。ゆっくり周りを見て移動するとかもできるし。

 ゲームの設定でキー入力のソースを1個しか設定できないのが地味に不便。例えば回避のデフォルトはAltだけど、これをマウスのサイドボタンに割り当てようとするとAltが削除されるから、クセでAltを押すと回避できない。せめてキーボードとマウスは区別して(重複して)設定できると便利なのだが。

 例によってサブスクで遊んでるけど、ゲーム自体は楽しめているし、ライセンス1本買おうかな、と思ったり。Ubi版で遊んだ履歴ってSteam版を買っても引き継げるんだろうか? 今までのUbiのゲーム、例えばThe DivisionとかGRBPはSteam版で買ってもUbiのランチャーで起動するからSteam版/Ubi版の区別なくセーブは共通だろうけど、ACSのSteam版はUbiランチャー不要だそうだから、セーブデータの引き継ぎに難がありそう。どうしてもSteam版を買わなきゃいけない理由もないので、Ubiで買ってもいいんだけど。



 安いゲーミングマウスを買ってみた。ちょっと前に買ったキーボードと同じブランド/デザインのやつ。

 FPSだとあまり気にならないけど、剣を振り回したりするゲームだととにかくクリックを連打するから、マウスの寿命が心配。/* ACSの場合、1段くらいのキュー経由っぽくて、連打するとパリィが間に合わなくなるから、本当は連打しちゃだめなんだろうけど */

 今まで使っていたやつと並べて使うと新しい方のカーソルがめっちゃ引っかかる。amazonのレビューも低評価ちょっと多かったしなぁ……と思いつつ有線で接続したら問題なく動く。試しに古い方のドングルを抜いてみたらヌルヌル動くようになった。USBハブにドングル2個並べていたから、古い方のドングルから出ている電波が新しい方のAGCをリミットさせているのかな。無線機器を並べて使う経験がほとんど無いので、目に見えて抑圧を受けたのは初めてのような気がする。

 古い方は海外のブランドなので結構大きいし重い。新しいやつは国内のメーカーだからかひと回り小さくて持ちやすいし軽い。ガッツリ肉抜きしてあるFPS用のマウスならもっと軽いんだろうけど。

 古い方は充電ドッグ(別売り)に乗せれば簡単に充電できるけど、新しい方はType-C専用なので充電するたびに挿抜しなきゃいけないのが面倒。ただ、古い方は1日で50%くらい電池を消耗するから毎日の充電が必須だけど、新しい方はそこまで極端に放電するわけじゃないから、数日毎に充電すれば良さそう。それはそれで忘れそうとか不安だけど。

 コネクタがもっと手前にあれば磁石で簡単に着脱できるアダプタを使えるのに、なぜかゲーミングマウスのUSBコネクタってかなり奥まった場所にある印象。新しい方は普通のType-Cケーブルが使えるだけまだ良心的。古いやつはコネクタこそMicro Bだけど、細い穴の奥にコネクタがあるせいで市販のUSBケーブルが使えない。テーパーみたいな構造もないからUSBを刺すのがかなり面倒だった(だからしょうがなくドックを買ったわけだが)。新しい方も、付属のケーブルは普通のType-Cより被覆が大きくて、スリットが入った構造になっている。もしかしたらマウスを振り回したときにType-Cコネクタじゃなくてその周りの樹脂パーツで負荷を受けるような意図なのかな? 古い方のマウスも同じ思想なのかも。専用ケーブルしか使えない古い方に比べて、市販のケーブルでも(コネクタにダイレクトに負荷がかかるとはいえ)使い回しができる新しいほうが親切感がある。

 ユーティリティでいろいろ設定できるけど、ボタンに割り当てられる機能が少なめなのがちょっと不満。例えばDPIはいくつかの種類を設定できて、ボタンで切り替えられるけど、DPI切り替えが1方向しかない。2個のボタンでDPI Up、DPI Downみたいな操作が作れない。不思議。ホイールの手前に2個のボタンが付いていて、普通のマウスはここにDPI Up/Downが割り当てられていたりするはず(デフォルトでは無割当)。

 左右クリックとサイドボタンはマイクロスイッチっぽい感触だけど、中クリックはタクタイルスイッチっぽい感触。あっという間に死にそうだなー。ホイール手前のボタンに中クリックを割り当てるという手もあるが。

 ホイールはクリック感強めで結構好み。

 最初は軽すぎる感触とかが不慣れで変な感じだったけど、慣れてしまえば結構快適。

 古い方のマウスはサイドパネルを交換すれば12ボタンにいろいろな機能を割り当てて、右手だけでほとんどのPC操作が完結するのが便利だったけど、マウスがスリープに入るとウェイクアップに時間がかかるのが不便だったんだよなー(立ち上がるはテンキーモードになっているから数字が連打されて、いちいち消さなきゃいけないのが面倒だし、YouTubeとか見てると不用意にシークしてしまう)。あと、FPSを遊ぶときにサイドボタンが邪魔で2パネルに交換していたから、サイドパネルのショートカットも使えていなかったし、普通のマウスに変えてもそんなに違和感無い。もう一つマウスを買ったんだから12ボタンパネルに戻してもいいんじゃね、とは思いつつ、抑圧の問題がなぁ。こっちのマウスは有線で接続すれば、抑圧もないし、スリープに入ることもないし、「右手デバイス」的に使うのであれば問題ないかな? マウスを2個も置くスペースが無いという大問題を除けば。



 世界の重要インフラを強くする!時刻同期は2周波GNSS受信の時代へ | 技術 | GPS/GNSSチップ&モジュール | フルノ製品情報

 あくまでも周波数ダイバーシティ的に使っているだけであって、L1/L5で電離層遅延を推定する、みたいな感じではないのかな。L1を妨害されてもL5を受信できていれば問題ないよ、L5を妨害されてもL1を受信できていれば問題ないよ、L1もL5も妨害されたらフリーランするけどそれでも短時間なら十分な精度を維持するよ、みたいな。



 衛星の打上げ、神社等で成功祈願を行っていない衛星はトラブルを起こしやすい、というジンクスがあるらしい(1990年前後の話)。祈願に行ける程度にスケジュールに余裕があるときは地上で対応できるトラブルは対応済みだが、祈願に行けないほど打上げ直前まで対応に追われていると不具合を潰しきれていないから、という相関関係らしい。まさに人事を尽くして天命を待つという感じの。天命を待てない場合は人事を尽くせていない。



 1980年代末頃にESAから提案されていた測位衛星NAVSAT、18機とか24機とか何種類か提案されていたけど、地上の原子時計をベースにベントパイプで測位信号を放送して、4機から信号を受信することで測位する。

 SBASは静止衛星でGPSの補正信号を送るシステムで、これはベントパイプで放送を行うが、オプションで測位信号を放送することもできる。

 ベントパイプで測位信号を放送する場合、衛星軌道に起因する相対論的効果は発生しない。全地球規模でベントパイプで放送するには地上局を満遍なくある程度の数(最低3箇所、できれば6箇所とか8箇所とか?)配置する必要があるから、今の地球のみたいに陸地の配置が非等方的な惑星の場合は地上局の配置に制約があるけど、それにしたって例えば衛星間中継を行うとか、どうにでもできるはず(衛星間通信みたいな方式だとアンテナゲインを稼がなきゃいけないから機械可動部が不可欠で、そのあたりの信頼性が、黎明期のオンボード原子時計と比較してどうかという問題はある)。

 多少なりとも相対性理論を解説しようとする文脈では「衛星測位を行うには相対性理論が必須」というような説明が判で押したように出てくるけど、本当にそうなのか怪しい気がするんだよなぁ。人間のスケールではほとんど効いてこない相対論の研究に無理やり理由をつけるために使っているだけのような気がする。

 結局、現在の衛星測位システムはすべて軌道上に原子時計を搭載しているから、なんだかんだ原子時計を軌道上に置くほうが色々と楽なんだろうけど。そのせいで飛行機とか高信頼性の用途で使おうとしたときに面倒なことになってるんだけどな。。。

 ベントパイプなら軌道上で時計が壊れたり計算をミスって誤った信号を放送する心配がほとんどない。中継機が壊れた場合は単に信号が中断する場合が多いから受信機はそれを無視するだけで済むし、そもそも全ての衛星が地上局から可視なのが前提だから、中継機の特性が悪化して測位精度が劣化するような場合でも地上局で検知して放送を中断すればいいだけだし。

 軌道上に原子時計を置くもう一つの利点として、地上局から独立して動作できるという利点がある。つまり地上局が壊れたり壊されたりしても、しばらくはシステムとして稼働できるから、軍用のシステムとして考えたときに便利(1箇所の地上設備が破壊されるだけでその周辺数千kmで軍事作戦が全部支障を受ける、みたいな脆弱性が無い)。NAVSATがベントパイプ方式で考えていたのは民間用の測位システムとして考えていたからだろう。



 なんとなく思い至ってrtlsdr.dllをC#から叩いてみた。

 非協調型のDLL(Visual Studioでメソッド一覧を取れないという意味で)をC#から叩くのってもっと大変だと思ってたけど、かなり簡単に叩けるんだな。リンカで公開されている関数の一覧を得て、ソースコードから引数とか戻り値がわかるから、それに従ってLibraryImportを書いていくだけ。

 rtlsdrライブラリはOpenに構造体のポインタのポインタを渡して、その他関数(Close含め)は構造体のポインタを渡す。構造体の中身に触らないのであれば、C#側からはIntPtr(Openはref IntPtr)を渡すだけ。基本的に全部静的メソッドとして定義するので、いちいちIntPtrを渡さなきゃいけない(or IntPtrを持つインスタンスとそれを使ったオーバーライドを作らなきゃいけない)のが面倒くさい。

 前にC#のRTLSDRラッパーのコードを見たときに、結構複雑そうなことをやっていた記憶があるけど、最低限必要な部分だけ書くなら、結構簡単。

 まだ複数ドングルの同時接続は試していないから、もしかしたらそのあたりは大変かもしれないけど。rtl_tcpだって実際はrtlsdr.dllを呼ぶような実装だろうし、多分問題ないと思うんだけど。


 試しにDLL直叩きで1575.42MHzを2.4Mspsでサンプリングしてみた。問題なくデコードできるけど、長時間サンプリングしても数分程度しかデコードできない。適当な時刻オフセットを与えてやれば別の場所をデコードできるけど。たぶんドロップしているんだろう。

 ドロップがrtl_tcp.exeとかの問題ではなくて、少なくともDLLレベル以下か、ハードウェアに起因するんだろう、というのがわかっただけでも収穫。まあ、DLLから配列を受け取ってファイルに書き込むなんて非常に簡単な処理だし、こんなところにバグの入り込む余地はほとんど無いだろうし。


 rtl_tcpとDLL直叩きを比較して、どちらに大きな優位点があるというのはあまりなさそう。DLLで叩ける機能はだいたいTCP経由でも叩けるし。

 DLL経由とrtl_tcp経由で一番違うのがゲインの設定かな。DLL経由の場合、R820T2(orその他のフロントエンドIC)が対応するゲインを正しく設定する必要があって、対応していない数値を与えた場合は単に無視される(近いゲインに設定されるわけじゃない)。対応していない値を設定した場合に無視されるのはrtl_tcpでも同じ(rtl_tcpも結局同じ関数を呼んでいるだけなので)。

 ただしrtl_tcpはゲインを番号で指定するコマンドがあって、この場合、範囲内の番号を指定すればゲインを設定できる。この番号は例えばR8xxの場合0以上28以下の範囲の自然数を指定する。ゲインを指定する場合は規則性のない数値(R8xxの場合0から496までの29種類)を指定する必要があるから、インデックスで指定するほうが簡単。

 しかし、このインデックスはフロントエンドICによって指定できる数は異なり、対応するインデックスより大きい値を設定した場合は単に無視されるから、結局、適当な巨大な数(例えば1000とか)を設定しても無視されるのはgainコマンドもgain by indexコマンドも同様。

 DLLを叩く場合、対応したゲインの数値の一覧を得ることができるから、適当な値(例えばR8xxでは対応していない40dB)を設定しようとしたときに、対応するゲインの一覧から一番近い数値を自動的に設定する機能を作ることができる。この場合、適当な巨大な数を設定すれば、それに一番近いゲイン、すなわちそのフロントエンドICで設定できる最大のゲインが設定されるから、フロントエンドICの種類とか使用できるゲインの数値とかを気にする必要がない。

 ただしこの一覧を得る関数はintポインタを引数に取って一覧を配列に書き込むから、呼び出し側でmalloc/freeで取得した配列(あるいはあまり多くないことを期待してスタック領域で宣言した配列)を渡す必要がある。こういう処理は普通のC#に比べるとちょっと手間がかかる。とはいえ、数行程度のメソッドを1個書けば隠せる程度の処理ではあるが。



 GPSの受信もちまちま実装中。

 C/Aコードのロックオフの検出をPLLで実装してみた。今までは航法メッセージのパーサで検出していたので、数秒程度の遅れがあって、その間の測位データが大きな誤差を持っていた。

 PLLがロックオンした状態ではフィードバックは±1rad程度に十分収まるが、ロックオフした状態ではフィードバック値が±πradにランダムに分布することを利用して、閾値(例えば±π/4rad)を超えたフィードバックが適当な割合(例えば25%)を超えた場合、ロックオフしたと判定し、相関器・受信機をリセットしてドップラスキャンを行う。閾値にもよるけど、数百ミリ秒程度で搬送波ロストを検出できるから、航法メッセージを見るより1桁早い。閾値を狭くすればもう1桁早くなるけど、ノイズに弱くなる。

 以前遠出したときにサンプリングした30分くらいのIQファイル(途中で何回かドロップしている)を解析して、結果全期間を復調できるようになった。観測値(GPS衛星時刻)を100Hzで出力して、そのまま測位演算してNMEA0183で出力しているから、GGAだけしか出していないのに12MB(17万行)を超えている。点数が多いせいかGoogle Earthで表示できない。高度ビューは見れるし、カーソルに合わせて三角形のマーカーが移動するから、正しそうな位置が得られているのはわかるんだけど。

 今のところ、IQファイルの復調は各GPS衛星が放送している時刻(普通のGPSで言うところの擬似距離に近い情報)をファイルに書き出して、その後で測位演算を行っているので、GPS衛星の捕捉に推定値を使うことができない(最後にロックオンしていたときのドップラを持っておくとかの方法はあるけど)。GPS衛星の受信と同時に測位演算を行っておけば、現在位置・速度・受信機クロックエラーから衛星のドップラや航法メッセージの位置(ビット内外の位相)を推定できるから、より早く再補足ができる。ただ、この場合は測位演算が継続していることが大前提であって、例えばRTL2832Uのサンプルドロップは全衛星が同時に断してその量もわからないから(数us程度のはずだけど)、相関器や復調器はリセットする必要がある。


 PLLの記事で、IC用のクロックとか無線機の修理とか、いろいろな文脈で「PLLのロックが外れる」みたいな表現が出てくるけど、ではそれをどうやって検出するか、という話はほとんど出てこない気がする。一部のPLL ICにロック検出回路を内蔵しているものがあるけど、とはいえその詳細な説明とかは見当たらない。

 クロック回路のエンジニアとしては安定して動作するPLLの設計が腕の見せ所(というか安定して初めてマトモな設計になる)だし、古い無線機の修理とかではPLLが外れる=正常に動作していないわけだから、いちいちPLLのロック状態を把握しなきゃいけない状況ってのは少なそう。どうしてもクロックの監視が必要なら、そのクロックでカウンタをインクリメントしたうえで、適当な高信頼のクロック(数十kHz程度)でカウンタをリードandクリアして、カウンタがゼロ(or適当な範囲外)の場合はクロックエラーとして割り込みをかける、みたいな機能でいいはずだし、PLLだけ見てもあんまり意味ないだろうし。

 通信分野だと相手の信号の有無を検出したいみたいな場合もあるけど、それにしたって例えば放送(デジタルテレビとか)ならOFDMのガードインターバルを探すとか、受信した情報の誤り率を見るとか、そもそも信号の判定をしない(SNRが悪ければ単にブロックノイズとしてユーザーに提供する)とかだし、通信(移動体通信とか)にしても上位プロトコルで判定することが多いだろうし、搬送波レベルで信号のロストを検知したいって用途は結構レアなのかもしれない。

 宇宙機の通信だと地上からCWをスイープしてオンボードのPLLでこれを検出・ロックして地上に折り返して、地上でもキャリアを検出してロック判定、みたいなことをやるけど、こういう手順の(搬送波レベルでハンドシェイクする)通信方式って宇宙通信の他にあるんだろうか。



 C#のメソッド(というかコンストラクタ)でトップのブロックを書かずに;で終端するような機能欲しいよなー。record Hoge(int Value){public Hoge(string str)this(int.Parse(str));}みたいな感じで、thisで別のコンストラクタを呼ぶだけで、中で何も処理しないときに空のブロックを書かなくて済むように。わざわざ専用の文法を用意するくらいなら空ブロック書くほうがマシ、ということなんだろうけど。


 C#のSpan<T>/ReadOnlySpan<T>と同じように使えるSpan<T1, T2>/ReadOnlySpan<T1, T2>みたいな構造が欲しいなーと思ったり。

 大量の複素数をComplex[]で持つのでなく、float[]real, imaginaryで分けて持ったりするときに、それぞれを一体として扱ったり、必要に応じてFirst, Secondで個別にSpan<T>を切り出したりできるようなやつ。

 既存のC#でも例えばArrayとかSpanのSort<TKey,TValue>(TKey[],TValue[])みたいに2種類の形(2個の配列)をあわせて使うような機能はあるわけだし、それを積極的に使うようなサポートがあっても良さそうな気がする。Arrayならともかく、Spanの場合は切り出して使うのが前提だろうし、それなら両方をまとめて切り出すような機能も欲しい(切り出しを2回書かなくていいから、ソースコードが半分で済む)。

 ついでにSpan<int,int>spanみたいなやつをvar(a,b)=span[0];とかforeach(var(a,b)in span)みたいな感じで一括で読めるような機能があるとなお嬉しい。


2025年3月19日水曜日

小ネタ



 女子高生・部活青春FPS『シューターズ レディ!』発表、3月28日発売へ。群馬から全国出場を目指す、汗と涙と硝煙のスポーツシューティング - AUTOMATON




 量子コンピュータみたいに極低温へ大量の同軸線を引き回したい用途へのソリューション。1束240本のRF(12GHz)を通せる。最大で6束1440本を引き回せる。おそらくセミリジッド同軸線より1本あたりの熱流束も少ないだろうし。チャンバの外側で1500本も同軸線引き回すのは結構悪夢な気がするけど、さすがにBNCで接続するわけじゃないだろうし…… /* 量子コンピュータの周辺機器にフォーカスした解説動画どっかに無いかな。何百もの微弱なアナログ信号をどうやって処理してるのか、冷凍機はどういうふうにおいてあるのか、等々 */

 ユーザー側にも色々利点はあるんだろうけど、どちらかというとメーカー側が大量のセミリジッド同軸線を注文されて「こんなもの作ってられるか!」ってキレてFPC化したんじゃないかと邪推。



 宇宙の電波を受けたりするPART 1 『45m電波望遠鏡の謎』 - YouTube

 宇宙の電波を受けたりする PART 2『 並ぶパラボラの謎』 - YouTube

 NAOJの動画。一見子供向けっぽいけど、かといって子供用に手抜きをして作っている感じでもない。

 電波干渉計の説明、この動画や他のNAOJの資料でも「アンテナの距離を広げるとより小さい時間差を測ることができ、角分解能が高くなる」みたいな説明があるけど、これは間違っている気がする。距離が大きくなると到達する時間差が大きくなるから時間分解能を維持したままでも角分解能を向上できる、というのが正しいはず。



【USB Type-C】USB-TTLシリアルコンバータ(3.3V) - サポート | ストロベリー・リナックス

 Type-C版は現状この3.3V品のみとなっております。ご要望が多ければ5V品も生産いたします。

「生産します」ってことは、FTDIでなくストリナが製造(あるいは委託)しているのかな? 型番の命名規則がType-Aの製品と違うから、FTDIの製品ではないのかな。


 別のサポート

 現状、Type-Cになっても通信スピードはUSB1.1(12Mbps)=UARTは最大3M baudのままで (中略) FT232HのICが大きく、また外付け部品も多いので、USB Type-Cのプラグの中に回路を収めるのが難しいからだと思われます。もし小さい1チップでUSB2.0対応のシリアル変換が出れば、高速USBシリアル変換ケーブルは可能かと思われます。

 たかだか6MHzの矩形波とはいえ、12Mbaudを不平衡のまま6ftとか引き回すのもちょっと気持ち悪いし、USBコネクタ内蔵にこだわらなくてもいい気がするけどなー。ストリナの製品でFT232H変換ボードがあるけど、これは色々端子が出ていてちょっと大きい(フルサイズType-Bだし)。最低限必要なピンだけ出して基板を一回り小さくしてType-Cを乗せたボードがあると便利そう。裏面にCH224を乗せてくれるとなお嬉しい。


 高速なType-C-シリアルの変換ならSTLINK-V3MINIを買うのが良さそう。15Mbaudまで対応しているし、マルツで2000円前後で売っているし。裏面にJTAGコネクタが出ているのがちょっと邪魔ではある。あと電力出力が無いのが難点。STM32F723IEはUCPD非対応っぽいな。残念。



 YouTubeの再生画面にある動画一覧でチャンネル名をクリックすると、以前はチャンネルに飛べたはずなんだけど、最近は動画に飛ぶようになっていて、地味に不便。アプリ版の挙動に近くなったのかな? アプリ版はトップページでもチャンネル名タップで動画に飛ぶのが不便なのよな。今のところブラウザ版のトップページでチャンネル名をクリックするとチャンネルに飛ぶけど、そのうち動画に飛ぶようになるんだろうか。

 チャンネルではなく動画に飛ばすと非Premiumユーザーだと広告が再生されるから、YouTube的には広告再生数を稼げて良いんだろうな。せめて広告関係ないPremiumユーザーはチャンネルに飛ばせよ、と思うんだけど。



 宇宙論の本を読んでいて、広大な宇宙空間を表現する文脈で「アンドロメダ銀河など遠くの銀河」という文が出てきて。そりゃ宇宙論やってる人からすれば近所の銀河なんて興味ないだろうけどさぁ。まあ、「遥か遠くのアンドロメダ星雲」とか書かないだけマシではあるか。



 Android(Pixel6a)にワコムの液タブを接続してOneNoteアプリを起動してみたら、普通に使えた。PCのユーティリティみたいな細かい設定はできないけども。

 OneNoteでは筆圧対応で、ペンのボタンを押しながら書くとオブジェクト削除として使える。縦画面だとタブの左側の狭い領域だけ使える。横画面だとタブの上側の大部分が使える。タブの横幅が216mm、分解能が0.01mm、スマホの縦解像度が2400pxだから、横画面で使うと9bin/pixelくらい。かなり細かい書き込みができる。

 Type-C - Micro USBケーブル1本あればペンで入力できるし、画面に指で書くとか静電容量ペンで書くよりはるかに細かく書けるけど、便利かというと、うーん…… 普段使いするにはコード類が邪魔だし、イザというときのために持ち歩くには板タブは結構大きいし。デジタルのノートにゴリゴリ書き込むならiPad Airとか買いなさいって話になるし。


 Acrobatは一部のファイルはペンで上書きできるけど、筆圧とかサイドボタンは非対応。画面の小ささとか、余計な機能(「AIアシスタント」のアイコンを消せなくて邪魔、とか)の関係で、あんまり便利な感じはしないかな。


 ワコムの欧州法人がPlayストアで無料公開しているアプリが、ちょっとしたメモ書きには便利そう。筆圧も対応しているし(若干レンジ狭めな印象ではあるが)、サイドボタンに消しゴムと色変更が割り当てられている。鉛筆と半透明の塗りつぶしブラシ(筆圧非対応)以外でイラストを書こうとすると有料のペンを買う必要があるけど、アプリ自体は日本語化されているし、わりと使いやすい(色を選んだあとにパネルを消さなきゃいけないのがちょっと不便)。

 一応PDFでのエクスポートも対応しているのかな? PCと連携することを考えるとOneNoteとかを使うほうが便利そうな気もする。

 ただ、液タブ/板タブメーカー純正のアプリ(現地法人とはいえ)が開発したアプリと期待すると損するかな。基本は普通にタッチスクリーンに指で書き込むようなアプリだと思う。

 Bamboo Paper - Google Play のアプリ


 板タブはともかく、液タブをAndroidと組み合わせるのは結構便利そうな気がする。iPad買うより安いし、普段使いのスマホとノート用のタブレット間でデータを同期するとか考えなくていいし。Android+液タブってどんな感じになるんだろうか。ちゃんと別画面として、液タブ側でノートアプリとか使いつつスマホ側で資料を読んだりとかできたらだいぶ便利そうだが。

 Artist12セカンドをAndroidスマホに接続する方法 - YouTube

 液タブでドローソフトを起動したままAndroid側は自由に使えるっぽいな。ただ、液タブはそれなりに重そう(iPad Airのほうが軽い)。値段とかデータ管理とかが問題ないならスマホとiPad Airの2台持ちの方が楽そう。



 C#の関数呼び出しで、タプルとかDeconstructの型が一致していれば直接投げられるような機能欲しいよなー。いちいち分解して渡すのめんどい。


 LINQのWhere、falseなら通すみたいなWhereNot的なヤツも欲しい感じが。double[]arrから非NaNを取り出したいときにarr.WhereNot(double.IsNaN)的に。


 C#の生文字列リテラル、改行コードがソースコードの改行コードになるの、地味に不便な気がする。生文字列リテラルの接尾辞にCRとかNFとかCRNFつけて明示できるようになってほしい。せっかくReadOnlySpan<byte>に直接突っ込めるのに、Replaceで書き換えてEncoding.UTF8.GetBytesでbyte配列を取り出すのもアホらしいし。



 breakとかcontinueで整数を引数に取る機能がほしいよなー。break 1;やcontinue 1;がbreak;やcontinue;と同じ作用。break 2;やcontinue 2;は2重ループを抜ける。同様にbreak n;やcontinue n;でn重ループを抜ける。break 0;やcontinue 0;はそのbreakやcontinueを無視する。負数の場合は無視するか例外を投げる、ループ数より多い数(例えば1重ループで2以上)を指定した場合は一番外側のループを抜ける。言語仕様で論理値が0と1と定義してあるならif(flag)break;とbreak flag != false;が同じ動作になる(それが目的ではないにしても)。

 多次元配列を舐めるときとか、1次元配列でもその中で別の配列をスキャンして一番外側のループを抜けたり継続したりしたいことがままある。そういうときにスッキリした書き方がほしい。

 break n; continue n;のnが定数の場合は追加の実行コスト無しに作れそうな気がする。ネストされたループの木構造から、n個上のラベルを呼ぶだけ。nが変数の場合はnをswitchで展開するコードが必要になるので追加コストが結構多そう。あるいは適当なレジスタにnを突っ込んで、各break/continueでレジスタをデクリメントした結果が!0なら上のラベルに飛ぶみたいな処理ならn回の分岐コストで処理できるか。break n; continue n;を大量に使うならswitchでコードが増えるより分岐コストを払ったほうがマシかな?

 break n;とcontinue n;が使えれば便利なところ多いと思うんだけどなー。



 ふと思い立って、テレビの同軸線をオシロに接続。

 オシロのスペックが1Gsps、帯域幅200MHz。いろいろスペクトル見えてる。500MHz付近が地デジだと思う。指向性の地デジアンテナで受信してるんだから当たり前だけど、それなりに強く入ってるな。

 400-500MHz付近の拡大

 このあたりでは16-28chの偶数番でデジタル放送を行っている。16chが488-494MHzあたり、18chが500-506MHzあたりで、18ch以上はゾーン2の折り返し。

 さらに拡大

 一つの幅が5.58MHzくらいで、ISDB-Tの幅(高度化だと5.83MHzまで増える)。

 ついでに、FMラジオの周波数

 平均化するとピークが消えるので1回分のスペクトル。FMラジオっぽく見えないこともないかな、という程度。地デジ用のアンテナだからFMラジオはケーブルで受信しているんだろう。ほとんどノイズみたいなレベル。

 さすがに1Gspsのオシロだと折り返されるから微妙なところだけど、とはいえ地デジの電波もちゃんと見えるんだな。

 4K放送非対応の衛星アンテナだとIFが2.1GHzあたりまであるから、5Gspsあたりのオシロがあると全部見えて面白そう。とはいえ、5Gspsまで見えるオシロって2千万コースとか? R&Sの安いやつで700万とか。携帯電話とかを見ようとすると2.5Gspsくらいの30万~くらいがあると良さそう? R&SとTLのオシロ、似たようなスペックで1桁以上値段違って謎い。ちゃんと比べれば色々違うんだろうけど。

 学習用に、生徒とかにスペクトルを見せるだけならスペクトラムアナライザを使えばいいだけだし、そういう施設ならスペアナくらいおいてあるだろうしな。わざわざオシロで見せる利点はあまりなさそう。


2025年3月12日水曜日

小ネタ



 GNSSコンパスの見た目がすごいな。コンテナでブロックされないように、ということだろうけど。港湾は周りにコンテナを積み重ねていたりガントリークレーンがあったりでGNSSには環境が悪そうだ。かといってLiDARでマーカーに使えるようなわかりやすい構造物は設置されていないだろうし。



 アサシン クリード シャドウズ:二つの道 奈緒江と弥助 ウォークスルー - YouTube

 英語版プレイ動画だけど、Yumi Bow(弓矢)とKanabo(金棒)でちょっと笑ってしまった。英語訳された資料を探すときに謎に苦しめられたやつ。「Bow(弓)」と「棒(Rod)」の曖昧さ。

 日本の古典的な武器を英語に翻訳しようとして「ボウ(弓)」と「ボウ(棒)」を取り違える、みたいなことってあったんだろうか。あってもおかしくはなさそう。とはいえ、「棒」単体で使うってことはあんまりなさそうな気もするけど。「棒術」を「Bow-jutsu」みたいに聞き間違えたりするのはありそうか。棒術の応用で、矢がなくなったときに弓で近接戦をするみたいな武術ってないんだろうか。刃物の1本持っておけって結論になりそうだけど。アクション映画だと弓で相手の首を絞めるみたいなシーンはありそうよな。



 [SHIMADZU] 世界初、小型化に成功した光格子時計を発売開始 次世代の時間計測技術の実用化へ | 島津製作所

 5億円(構成による)で、3年で10台売りたいとのこと。

 秒の定義に光格子時計を使うならある程度の数の研究機関で比較したいだろうし、それなら世界中で数十台程度は設置する必要があると思うけど、今後ほかのメーカーの製品も出てくるだろうから、その中の何割かのシェアを取りたい、ということなのかな。まあ、1社の製品だけでSI単位を決めるわけにもいかないしな。

 あるいは、定義だけ先にSrとかに変えて、TAIにはCs/Rb/HMから少しずつ切り替えていく、という運用になるのかもしれないけど。今だって秒の定義はCsだけど、参加しているのはHMが多いだろうし。


 秒の定義って「こんなの意味わからんwww」みたいなネタにされがちだけど、とはいえ理解しようとしなければそう変な定義じゃないような気がするんだよな(間接的に量子力学を引用して、離散化された周波数の値を定義しているだけ)。ところが、光格子時計を定義にしようとすると、トラップ用のレーザーの波長とか、トラップする原子の数とか、色々決めなきゃいけないはず(レーザ波長(周波数)なんてそもそも秒の定義が必要なわけだし)。格子時計(格子に大量に原子を捕まえて統計的に処理する)というからには原子は1個じゃだめなわけで、それが100個あればいいのか、1000個必要なのか、とか。そのあたりの文言ってどうなるんだろうか。それとも、Csと同程度の簡潔な文言で定義して、実際に必要な条件等は別の文章で指定するんだろうか。


 100億年に1秒しか狂わない「光格子時計」 島津製作所が5億円で販売 | 毎日新聞

"より正確に時間を刻むことでうるう秒などの時間の補正が不要となる"

 時計精度とうるう秒は関係ない話では? むしろうるう秒は時計の精度が上がったから出てきた問題だろう。


 光格子時計のTAIとか物理定数の検証とか以外の分野ってどういう用途があるんだろう?

 例えばVLBIに使えば積分時間を1,2桁増やして、1,2桁暗い天体(or 2-4倍遠い天体)が見えるようになる、とか? 感度が1桁増えても見える距離は2倍程度しか伸びないけど、体積は1桁増えるわけだから、結局見える物は1桁増える。と考えると、例えば使えるクエーサーが1,2桁増えれば色々便利そうだな。逆に、天体数を維持したまま望遠鏡の大きさを3分の1とか10分の1に小さくもできるわけだから、より多くのVLBI受信局で(より密なUV平面で)観測ができるようになる、とか。

 VLBI以外の用途だとどうなるんだろう。ここからさらに低コスト化して1台1億円とか5千万円くらいまで下がったとしても、携帯電話の基地局に1台置くような話にはならないだろうし(それだけ量産するならもうちょっと値下がりしそうではあるけど)。テレビの放送局くらいの密度だと導入できるかもしれないけど、そこまで精密なクロックを使う需要もないだろうしなぁ。

 少なくとも次世代地デジは現行の時計で実現できるような仕様にするわけだし、もし次のテレビ放送を規格化するとしても四半世紀くらい先だろうし、その頃なら光格子時計も安くなってるかな? そんな精密なクロックを使ってどんな変調方式にするんだ、という話だけど。送信側を-18乗オーダーにして、受信側もコモディティ化したCSACで-15乗くらいで維持して、OFDMのサブキャリア間隔をものすごい狭く設定するとかはできるかもしれないけど。でもフレーム長をあまりに長くしすぎると、移動受信をする場合にその間の加速度でICIが悪くなるから、日本だとそういう規格は作りづらそうだな。



 1週間ぶりくらいにDelta Forceで遊ぼうと思ってとりあえずウォーフェア入ってみたら、またOSを巻き込んでクラッシュした。自動再起動だと起動できなくて、電源長押しで落としてから起動して、OSの修復が走って、起動。前と同じ。

 最近Chromeの更新があって、それがバックアップに入る前だったらしく、Chromeが起動しなくなった。とりあえずEdgeで落としたインストーラーを入れて、無事なく起動。再インストールしたのでログイン状態が全部解除されて、ログインし直したり、特にログイン状態じゃないと見れないページを開いていてエラーページに飛ばされていると手動で開き直さなきゃいけないのが面倒。再インストールしたからと言ってChrome自体のアカウントをログアウトしているわけじゃないから、保存されたパスワードはそのまま使えるし、セキュリティ的になにか利点があるわけじゃないのが謎い。意図的にログアウトさせてるわけじゃなくて、インストール時に乱数を生成していて、例えばCookieを暗号化して保存しているみたいな関係だったりするのかな? その他いくつかのアプリも起動しなくて、再インストールが必要なものがちらほら。

 DF、アンチチートの誤検知しかり、OS巻き込んだクラッシュしかり、なんか調子悪そうだなー。ということで、折角の機会だし、アンインストール。インストールしてあるとマッチングに入らない分生産で頑張らなきゃみたいな考えになってしまうからな。。。あと、他のゲームもいくつかアンインストールして、データ用SSDの空き容量を確保。だいぶ空いた。こういう機会でもないと遊んでないゲーム含めアンインストールなかなかやらないからな。。。



 チートツール内蔵FPS

 マップとかルールとかもう少し改善の余地があるような感じもあるけど、面白い。

 フラッグ戦でせっかく味方が後ろまで持ち帰った旗を背負って前線に突っ込んでくテメー! 最低限のゲームルール(勝利条件)くらい把握しておけ!! 名前とかアイコンが見たことあるなーと思ってTwitchを見たらフォロワー数十万人のVtuberだった。Vtwitcher? Twitchのスケジュールに残ってないし、名前騙ってるだけかもしれないけど。

 内蔵チートツールはあまり性能良くないから、オートエイムが強めの普通のオンラインFPSって感じ。敵の居場所に向かって線が伸びてるし、壁の向こうの敵も見えるし、マップがシンプルだし、参加人数も少ないから、「どこから撃たれたかわからない」みたいな状態で負け続けるようなことは無いから、オンラインFPS初心者向きまであるかもしれない。まあ、このモードになれると普通のFPSが遊びづらい気もするけど。

 いくつかのモードを遊んだ感じだと、チームデスマッチで圧倒的な差がつくとリス地まで簡単に入られてリスキルされ続けるのがちょっと厳しいかな。圧倒的な差がついたときは負けてる側にテレポーテーションチートを与えて敵の後ろから襲えるようにする、みたいなギミックがあるといいかも。



 寿司

 6.6kps14ミスで順位自己記録更新。ミスが多いのが難点。100位台中盤って微妙な順位よなー。

 kpsは多少低くても、ミスが少なければその分時間ボーナスを得られるからスコアを稼ぎやすくなる。あと、最初に文全体を見ると誤字りやすい気がする。左側だけ見て、最初の文字を入力しながら文全体を把握すると安定して入力できる。後で入力したいキーが近いと先に反射で入力しているっぽい。符号間干渉っぽい挙動。

 普通に日本語っぽいテキストを入力する分にはある程度の速度で入力できるけど、いざソースコードを書こうとすると、急激に入力速度が落ちてしまう。たぶん記号系とカーソル移動の入力が苦手。



 家のストーブを買い替えたらしい。

 表示部は白抜きのLCDで、一定期間操作していなければ表示が消えるけど、バックライトLEDは点きっぱなし。真っ暗なときに見るとうっすら光っているのがわかる。不思議な設計だ。LEDも消せばいいのに。バックライト輝度の設定が可能だから回路的にはバックライトのOFFも可能なはずなんだが。

 ストーブ自体は50/60Hz両対応だけど、点火時の電力が300Wを少し超えるらしい。古いストーブは100W未満だったけど、50Hz専用。手持ちのJackeryは60Hz200Wなので、古い方も新しい方もどっちも使えない。ストーブをポタ電で起動できたら冬場に停電したときに安心だけど、残念。

 メーカーが変わったので設計思想とかが違うからちょっと使いづらそう。まあ、自分はその部屋にいることはほとんど無いので、あまり影響は無いかな。



 BS(ゆり初号機、'78年打上げ)、一応日本全国で個別受信できるようにという放送衛星だけど、放送は直線偏波で行っていたらしい(設計当時の電波割当が直線偏波だったのかな?)。

 TT&Cはミッション系(K帯パラボラ)経由でも行えるらしい。ただしK帯は指向性が強いので、姿勢静定まではではSバンド(ブロードな指向性)しか使えない。コマンド1kbpsに対してテレメ512bpsというのがちょっと不思議。USBはNASAおよびNASDA局から、K帯はRRL鹿島から使用。

 AKMでドリフト軌道へ投入。その前に20N級でスピン軸を135度程度方向ける。ドリフト軌道へ投入したあとは1N級デスピンスラスタを使用。3軸確立後は6本のスラスタ(1N級)でアンローディングとスロット維持。プリセッション用20N級、デスピン1N級、アンローディング・SK用1N6本はそれぞれ2系統で、合わせて16本のスラスタを積んでいる。スラスタの配置が謎い。3軸の速度と角速度で6成分、正負で12成分を制御しなきゃいけないわけだけど、6本のスラスタでどうやって制御しているんだろう。適当なキャント角をつけておいて、角速度6方向+加速度5方向、南北制御は昇降点と降交点を選んで制御、みたいな感じだと6本で11成分が制御できるのかな?

 ホイールアンローディングはY/Rを約2日に1回、Pを約7日に1回の頻度で実施。結構高頻度に吹いてるんだな。3軸安定化衛星として比較的初期のもの(GEO初の3軸安定化はATS-6の’74年打上げ)だから、外乱の見積もりが甘かった時代というのもあるかもしれないけど。ホイールは80%以上で非直線になるので80%未満で使用。アンローディングする際は10%くらいまで落とすらしい(反対側まで戻すわけではない)。別の資料によると、約1年間でピッチ軸を45回、ロール軸/ヨー軸を233回、アンローディングしたそうだ。

 SK制御は東西を3週間毎に、南北を2ヶ月毎に実施。南北の制御頻度が結構低いな。静止衛星って南北方向のほうが乱れやすそうな印象だったけど。実験用の衛星だし、多少の傾斜角は許容していたのかな。

 BSはデルタロケットS/N140で打上げられたけど、S/N139(Landst 3、3月5日)を打上げた際に第1段酸化剤(液体酸素)の漏出が発生して数日程度(3月23日→4月8日)延期したらしい。Landsat 3のen.wikipediaの記事には特に書いてないから、漏出量は大したことはなくて、投入軌道には問題なかったんだろうけど。しかし、LOXが漏れたのに1ヶ月位で次を打てるんだな。

/* テレビジョン学会誌33巻10号など */



 測月衛星という空想。EGS的なパッシブな衛星を月周回軌道へ投入する。月面からSLR観測を行えば月重力場のモデルを改善できるし、逆に衛星を観測すれば自身の居場所を知ることができる。月面でのナビゲーションシステムとして使うことができる。

 月には大気がないから、衛星の質量/断面積比が小さくても空気抵抗で軌道が乱れる心配がない(太陽光圧を除けば)。衛星が軽くてもいいということはつまりインフレータブル構造が使える。Echo2のような内圧で塑性変形する高反射率の風船を月周回軌道へ投入するのは、EGSのようなリジットな構造物を投入するのに比べて容易。特にナビゲーション用途としても使う場合、複数のベクトルを引けるように多くの衛星を投入したい。衛星の軌道を放送するビーコン程度は積みたいが、とはいえ無くても問題はない(GPSのように大多数のユーザーが使うわけではないから、地上から送るなり、適当な中継衛星を高軌道に置いておけばいい。有人にしろ無人にしろ、ある程度の通信回線を持っていることは前提としていいはずだし)。

 パッシブな光学観測の場合、月には大気がないから、昼夜関係なく観測ができる。背景の恒星と比較することで慣性空間にある程度正確なベクトルを引くことができる。DEMで地表面との交点を求めるか、あるいいは比較的長い時間観測して衛星の移動を待つ、または複数の衛星を使って複数のベクトルを引けば、DEMに依存しない測位も可能。

 SLRを併用する場合は恒星との比較で単位ベクトルが得られ、SLRでベクトルの長さが得られるから、一つの衛星で測位ができる。大気による減衰がないのと、地球よりも軌道を低く設定できるから、地球のSLRに比べて1,2桁程度小規模な機材で実現できるはず。

 高頻度に測位するためにはある程度の数の衛星が必要になるのが欠点(GPS的な電波航法の場合は衛星高度を高く設定することで機数をある程度削減できる)。反射衛星でも軌道高度を高くすることは可能だろうが、その場合は見かけ上の角速度が小さくなるから、衛星と恒星を分離するのが少し面倒になる(高度が低く角速度が高い場合は短時間の2フレーム間の単純な差分で分離できる)。とはいえ、インフレータブルな反射器を使う場合は輸送コストが小さい(質量が小さく、体積も小さく運べる)のが利点だから、ある程度の数を投入するのは不可能というほどではない。おそらくフルスペックの測位衛星を必要数運ぶよりは遥かに容易。

 インフレータブルの場合、CCRをつけるのが難しそう。曲率が大きい場合はSLR反射光が減ってしまう。

 反射衛星だけで測位する方法は画像処理だけで測位できるのが特徴だけど、とはいえ画像処理も結構高コストだからなぁ。GPS受信機みたいにRF信号処理のほうがシンプルに作れそう。むき出しのセンサ(画素)が不要なのも電波航法の有利な点。


 月ナビゲーションシステム(LNSS)の初期には衛星が足りないから地球の地上局から互換信号を送信してシュードライト的に使うみたいなこともあるんだろうか。やるとしてもだいぶ細いビームで出すだろうし、地上で受信して航法メッセージを復調したりして遊ぶのは難しそう。



 IKAROSの姿勢制御で液晶を使っていたけど、宇宙用で考えたときに、液晶とe-inkの有利不利ってどんな感じなんだろうか。液晶は直流なり交流なり適当な電力を突っ込んでおく必要がある。e-inkは最初に物理的な運動が必要だから液晶よりは大きな電力が必要だけど、維持のための電力が必要ない。例えば静止衛星の光圧のアンバランス、特に周期の長いもの(例えば赤道面・黄道面の差から発生する1年周期のもの)を除去するのに、e-inkがあると便利そう。

 あるいは熱制御デバイスとしても使える。電力を消費せずにアルベド(吸熱量)を調整できるから、OSRよりきめ細かい制御ができるし、サーマルルーバほど大型の稼働物ではないから、信頼性の面でも有利。

 e-inkは液体に粒子を浮かべているから、宇宙用として考えるとちょっと厳しそう。液晶と比べるとそう大きなデメリットはなさそうな気もするけど、OSRとかルーバに比べるとちょっと使いづらそう。


 そういえばIKAROSってJAXAのページには後期運用中って書いてあるけど、運用どうなってるんだろう。たぶん生きているのを確認したのって10年くらい前(’16年頃)が最後だと思うんだけど。キューブサットみたいな感じでズルズル運用した結果まとまった報告がされないパターンっぽい雰囲気が。。。運用コストを下げようとして人間の割当を下げた結果、報告書を書く暇もなく、得られた経験を残すこともできず……

 ソーラー電力セイル(OKEANOS)は2016年頃の資料だと「2020年代前半打上げ目標」って書いてあるが、どうなっているのやら。2022年に打上げて’33年到着予定だった。10年くらい遅れそう。



 WS2812のテープを紐のれん状にたくさんぶら下げて、画像認識でそれぞれのLEDの位置を推定する、みたいなモノって作れないかな。その隙間を人が通ったり、風で揺れたりして、LEDの位置が変わっても、平面のディスプレイとして表示を維持できる。実用性はともかく、表示デバイスとしては面白そう。人が通るときに画像処理ができなくなるから、位置のトラッキングが難しそう。相当巨大なものじゃないと十分な画素数が得られないだろうから、店の暖簾程度の大きさだと使いづらいだろうけど。あと、通るときにめちゃくちゃ目がチカチカしそう。



 行列式をベタ書きで計算するコードを試しに機械的に生成

 6次までは普通に計算できるけど、7次はCS8078エラーが出るので、一旦変数を経由する必要がある。7次だけで2500行くらいある。3次以上は余因子でAijをかけるけど、これは木構造だから、真面目に計算したいならこの部分をまとめればだいぶスッキリしそう。まあ、真面目に行列を計算したいならライブラリ使えという話ではある。



https://www.denshi.e.kaiyodai.ac.jp/wp-content/uploads/pdf/investigation/20040323-2.pdf

 GPSのソフトウェア相関器、5ページ目のtrackingループの図、下側がキャリア追尾のPLL。これ、ソフトウェアに慣れた考え方だと位相をatan2(im,re)で検出したらBPSKの180度曖昧さが効いてくるけど、atan(im/re)で計算すると、atanでは象限の曖昧さがあるから、そこで180度の曖昧さを打ち消せるのか。atan2で180度を超えた部分を戻すのと、atanで0divが発生しないように分岐するの、結局どっちもどっちな気もするけど。

 あるいは、微小角ではatan(y/x)をy/xで近似できることを踏まえると、追尾はatan自体不要で、単に割り算を近似するような回路で位相を追尾できるのかな。捕捉時(位相誤差が大きいとき)は近似できないけど、ハードウェア受信機なら捕捉用の受信機と追尾用の受信機は別回路ってこともあるだろうし、スキャン用のC/Aコード相関器だけ、捕捉用のatan回路を含む受信機、追尾用の割り算回路を使った受信機、みたいな感じで実装してあったりするんだろうか。


2025年3月5日水曜日


 TOBはいわば公開ラブレター、ニデックが経緯と見解を改めて表明:製造マネジメントニュース - MONOist

 相手が嫌がっても札束で殴って逃げ道塞ぐタイプのラブレターは笑えない。



 バーチャルISS内で球形ロボット操り、実機と比較検証。KDDI×スペースデータ | TECH+(テックプラス)

 スペースデータのISSシミュ、実機と比較するまでもなく、物理エンジンとしてだいぶひどい実装だというのは1分も触れば十分わかると思うんだけど、一体何を比較するんだろう? もしかして更新入ったのかな?と思ってアップデートしてみても相変わらずだし。

 宇宙に興味はあるけど詳しくはない、みたいな人にSteam経由で遊ばせるならともかく、こんなクソみたいなエンジンをありがたがって使うって、日本の宇宙開発のレベルはそこまで低くないと思いたいんだけど、実は結構ヤバいんか? それとも、Steam版は「素人向け」であって、実際に使っているやつはもっとマシなんだろうか? じゃあそれを公開してくれよ、と思うのだが。Int-Ballの推力だとまともに動けないから、とかなら推力等のパラメータだけ調整すればいいわけで、なんでわざわざオイラー角で演算したりロール軸を拘束したりするねん。新入社員の研修用に自分でググらせて書かせたコードじゃねーんだぞ。



 Steam:ステラーコード

 体験版が公開されたよ(製品版のリリースは8月の予定)。

 ざっくり最後まで遊んでみたけど、面白かった。

 ストーリーの進み方が冗長(説明が多い)だったり急展開(途中をすっ飛ばしたり)といった印象があるけど、ゲームとして作ろうとするとどうしてもしょうがない部分なのかな、という感じ。未知のビットストリーム(2値x2次元空間)の解析とかいちいち全部手順追って説明してたらそれだけで飽きられるだろうしな。

 あとは誤っている点とか、あるいは誤っているというほどではないけど適切ではないような点がいくつか。体験版プレイ後アンケートで「宇宙開発や理論物理を専攻している人に協力してほしいからそういう人は連絡先ちょうだい」みたいな記入欄があるから、設定考証はこれから作業するのかな。今から作業したらストーリーの根幹部とかはさわれないだろうし、表面的な部分だけ直して終わりって感じになりそうだけど。



 今まで使っていたキーボードは65%キーボードみたいな感じで、Enterキーの下に矢印キーがあった。テキスト入力中に矢印キーを使いたいときに、手の移動をあまりしなてくても矢印キーに届くのが利点。新しいキーボードはEnterの外側に矢印キーがあるのでちょっと遠い。

 新しいキーボードはキーピッチが8%近く大きいのと、Enterの右側に矢印キーがあるので、キーボードの幅も今まで使っていたものに比べて27%ほど大きい。普通に作業する分には特に問題ないけど、FPSとか、マウスを広く使いたいときは邪魔。

 今まで使っていたキーボードはZキーの下にWinキーがあるけど、新しいキーボードはZキーより左側(今までのキーボードではFnキーが有る場所)にWinキーがついている。自分のブラウザの使い方として、新しいウインドウを開いてから検索ワードを入力して、読み込んでいる間にWin-矢印で画面の適当な場所に配置する、という操作が多いんだけど、今までWinキーだった場所がAltキーになっているので、ウインドウを左に移動しようとしてWin-←を入力したつもりがAlt-←を入力していて、ホーム画面に戻ってしまう、という挙動が度々発生する。結構不便。

 ゲーミングキーボードは普段遣いには向かないよね、という当たり前の結論が得られそう。

 あと、HMIデバイスを通販で買ってはいけない、という、HMIを買うたびに実感しているやつを再確認。まあ、実店舗で買うと交通費で値段がほぼ倍になるから、半額で買えたと考えれば。。。

 適当な台をパームレスト代わりに使うと、一見楽なようで、実は文字入力速度が結構遅いような気がする。手を浮かせて入力するより、むしろ机につけて入力したほうがいいかも。というか、立って入力する高さだと、かなり文字入力しやすい気がする。座って文字入力するより誤入力が少ない気がする。実際、立った状態で寿司打をやるとスコアが結構上がる。とはいえ前のキーボードでガチってた頃よりは落ちるけど。

 そういえば、このキーボード、根本がType-Cなので、C-Cケーブルを使えば(OTG変換とかを使わず)スマホに直結できる。パソコンがなくてもどこでも寿司打が遊べるぞ! こんなクソ重いもの持ち運べんが。。。



 SELENE(’07年10月に月軌道投入)のホイールアンローディング、定常運用中は1日2回、RW1基故障(’08年7月)以降は1日4回行っていたらしいけど、地球周回衛星に比べてやたらと高頻度な気がする。地球(LEO)だとそもそも外乱トルクの平均値を吸収できるようにMTQを設定しているからRCSアンローディング自体が不要という可能性もありそだけど。1周120分として、アンローディングは6周毎くらい。月重力場の解析とかをやるためにはある程度長い安定した軌道があったほうが便利だろうけど、この程度でも十分なのかな。

 2008年10月上旬までは南極上空でアンローディング運用。高電圧を使用する機器(e.g. LALT)はアンローディング直前からある程度の時間は使用できないから、南極付近に観測頻度が低い範囲が発生する。’08年10月以降は北極でアンローディングすることで、南極付近の観測が増えた。

 人工衛星のアンローディングの頻度って情報ほとんど見当たらないような気がする。情報公開に消極的な準天頂衛星が数少ないアンローディング周期の情報源。アンローディングに由来するΔVは測位精度やサービス可用性の悪化に直結するので、QZS-1で評価が行われていて、それによるとアンローディングの頻度は実績値平均92日間隔とのこと。静止衛星だとスロットの維持でΔVを吹く機会が多いとか、そのついでにアンローディングも行うとか、色々違いはあるだろうけど。

 ASTRO-HはEOB伸展が2月28日、通信異常が3月26日で、この間1ヶ月はMTQでアンローディングを行い、RCSを吹いていない。科学衛星だから姿勢変更もある程度多めに想定していて、ホイールの容量が大きいというのもあるだろうし。特殊な例だとMUSES-Cとかはや2はIESをジンバリングできるので、加速中の2軸はそれでアンローディングできる。残りの1軸はRCSでのアンローディングが必要だし、小惑星ランデブ中はRCSで安定化させる必要があるとしても。



 NOVA衛星のドラッグフリー制御の名前がDISCOSなの、もしかして衛星内で浮かせた金属球をミラーボール(英語でdisco ball)に見立ててつけた名前ってことなのかな? ボールの位置計測とかは光学的にやっているわけではないと思うので(検出は静電容量のはず)、ミラーボールみたいに光を反射するようなものではないはずだけど。

 見た目的にも機能的にもミラーボールっぽいのはEGSとか。EGSは太陽光を反射するために普通の鏡(平面ではなく多少のR)を貼ってあるけど、それ以外のSLR用ターゲット衛星、たとえばLAGEOSなんかはCCRしか貼ってないので、ミラーボールみたいな反射はしない。ECHOみたいな風船はたぶん一定輝度で反射していて、ミラーボールみたいにキラキラするわけではないはず。



 キューブサットの放出機構、例えば3Uだと長軸方向に速度をつけて放出するけど、角運動量を与えて放出してくれるポッドってないんだろうか。3Uなら長軸の両端で持っておいて、片方のラッチを外してバネで跳ね起こして、立ち上がったら反対端のラッチが外れてそのまま運動量が与えられて分離する、みたいな。3U程度の大きさなら姿勢安定化を(能動にしろ受動にしろ)行わない衛星もあるだろうし、どっちを向くか(スピン軸がどうなるか)わからないくらいなら、多少のスピン安定を与えて分離してくれたほうが便利な場合もありそう。後で外れる方のラッチの設計が難しそうだが。

 軌道面が回転するとスピン軸と軌道面の関係も変わるけど、スラスタを1個積んでおけば修正できるから、3軸制御(最低4器のスラスタ)に比べればかなりシンプルな構成になる。電力配線の通し方次第でトルクが出てスピン軸とか周期が変わりそうだから、長期的には不安定な安定化方式なのが難点。スピン周期を変えるなら2器のスラスタが必要になる。MTQで打ち消すなら気にならないけど、それなら最初から3軸安定で設計しろって話になるし。

 やっぱり分離機構の機械的な複雑さが嫌がられるのかな。あるいはキューブサットの放出機構はもう規格化されているから、みたいな理由もありそう。スピン放出の場合、ポッドにいれる必要がないから、少なくとも大面積3面+小面積1面は比較的自由に突起物を作れるという利点がある。例えばスピン軸と同軸にアンテナ素子を突き出しておけば、展開機構無しに安定した通信ができる(無指向性ゆえのデータレートの低さはさておき)。Dawn/Duskのrolling-wheelなら回転軸方向に太陽があるから、うまく作れば3Uで30x30cmくらいの発電面が作れそう。




 電子基準点の南側10m位の場所で取ったサンプルの再解析

 前回、サニャック効果を含めるのを忘れていた。それを含めると基準点の真南13m位の場所に中心がある分散になる。ということで、東側にズレて出ていたのはこれが原因。上にずれる原因は不明だが、VDOPの問題かな?



 適当なサンプルデータが欲しくて、アンテナを持って外で取ってみたんだけど、うまく復調できない。クイックルックでもスペクトル全体が時系列で暴れるので変な発振が起きてたっぽい。前回移動中にサンプリングした組み合わせなのであんまり問題はないはずなんだけどな。前回は車の屋根にマグネットで貼り付けて、今回は手で持っていたので、GNDの有無が問題なのかな? 何回かサンプリングしてみたんだけど、なかなか安定して受信できない。この時期はまだ寒すぎて外でアンテナとノートPCを持ってサンプリングするのは結構きつい。寒いというか痛い。

 amazonで数千円で売ってるポールマウントのGPSアンテナ(船用想定?)ってGND無しでサクッと使えるようなものなんだろうか。ポールマウントってことはその下に金属プレートをいれるような想定ではないはずなんだけど。ある程度大きさがあるから開口面積もありそうだけど、中国製の安物だとセラミックアンテナとか車載用のアンテナをケースに突っ込んだだけって可能性も捨てきれないのがなぁ。。。



 rtl-sdrで設定できるサンプリングレート(1kHz分解能)と、2^13と2^14で割った値

 1.6Msps以下であれば2^13ptsで200Hz未満の周波数分解能が得られる。1.8Mspsより高いサンプリングレートの場合は2^14ptsFFTが必要になる。FFT窓が2倍になると同じ範囲をスキャンするのに2倍のIFFTが必要になるし、FFT自体の計算量も増える。2^13と2^14ではスキャンに必要な時間がだいぶ違う。

 2.4Mspsをドロップ無しでサンプリングできたとして、それを単純に(CICとかFIR無しに)2分の1にデシメーションして2^13ptsでスキャンしたりってできるんだろうか。あるいは2点の単純加算でLPF特性とか。

 ただ、FFTで畳み込んでからコヒーレント積分する場合、FFT窓が狭くなるとその分SNRが落ちるデメリットが有る。窓が狭くなって計算が早くなる利点がデカいので、とりあえず端から端までスキャンして、一番相関値が高いところを長い窓でもう一度相関取って、みたいな処理にしてもいい。



 相関器のロスト判定ってどうやってやるのがいいんだろうか。現状はサブフレームを受信したタイミングでパリティチェックを行ってエラーでロスト判定を行っているけど、最悪6秒の遅れがあるし、その間に相関器がフリーランするから位置誤差が急激に発散する。Early,Prompt,Lateを一定程度(0.5秒程度?)平均化したうえで、最大値と最小値の比が一定以下になったらロストと判断する、みたいなロジックとか?



 GPSの相関器に入っているDLL、今どきのシリアルバスだと必要ないだろうし、GPSに名前を残すだけの古の回路なのかな、と思っていたけど、どうやらDDR-SDRAMにもDLLが入っているらしい。DDR5の資料にもDLLの字面は出てくるから、最近のメモリにも入っているようだ。ただ、あくまでもクロックとデータのズレを吸収するのが目的であって、32bitとか64bitのデータバス全体にDLLが入っているわけではない? データバスは等長配線で頑張って、それとは独立に引き回すクロックはDLLでズレを吸収する、というようなことなのかな。

 CDRにもDLLが入っているらしいけど、ググってもいまいち出てこない。CDRは用途(プロトコル)によっても実装はまちまちだろうし。


2025年2月26日水曜日

小ネタ


 Amazon Musicで天月, 狂蘭メロコ, 八雲べに & ライトのNocturnal Night Feverを再生する

 サブスク各社で配信開始された模様



 学術会議法案は撤回を、歴代会長が声明 処理水〝沈黙〟に元会長「議論の余地あったかも」 - 産経ニュース

 大学は軍事研究には一切関わりたくないが、軍事研究の内容の評価は行う、みたいな話。自分が知らない分野をどうやって評価する気なんだろう。君たち、影響力を持った素人から「お前の研究なんか無駄だからやめろ」とか言われたら猛反発するだろに。

 国と分離すると軍事研究を強要されるって文脈が謎い。むしろ国の下にいたほうがそういう要求されるものなんじゃないの。



 NHKの『ザ・バックヤード』、エンドクレジットで差し込んである映像を見ると、放送されてないシーンで面白そうな話がたくさんありそうなんだよなー。地上波の本放送では枠が足りないから放送できないとしても、YouTubeとか、ある程度大きな配信サイトで拡大版というか、「バックヤードの裏側」みたいなコンテンツを配信してくれたら面白いだろうに。もちろんナレーションとかいう余計なものはつけず。それぞれの研究者が自分の専門分野を語るだけのコンテンツ。素人相手だから噛み砕いて説明してるだろうし。



 Kindle PWは端末の検索画面から検索すると、ライブラリにある本の本文からも検索して、その本の中でそのワードが何回出現したかを表示する機能がある(もちろん出現箇所にも飛べる)。ただ、PWはe-inkに応じたプロセッサしか入っていないからレスポンスが悪いのが欠点。あと、1冊の中の検索画面に入ると、ライブラリの検索画面に戻ることができないから、いちいち検索画面に入力する手間がかかる。

 Fire TabletのKindleアプリ(Android版Kindleアプリ)は検索画面から本文検索ができないのが欠点。

「前にKindleで読んだはずなんだけど、どの本か覚えてないんだよなぁ」を検索したい場合、PWでライブラリ検索して出てきた本をFireタブで開いて書籍内検索する、ってあたりが落としどころかな? もっとも、検索性能はあまり良くないので、直交性の高いキーワードをズバリ思い出しておく必要はある。



 ゲーミングキーボードを衝動買いしてみた。国内OA機器メーカーのゲーミングブランド。デザインで選んで流通在庫(生産終了品)を購入。ガチのゲーミングブランドの製品に比べると安価な製品。

 動機としてはDelta Forceを遊んでいるときに明らかにWASD周りで追加のキー入力が認識されてないな、という挙動があったので、組み合わせ制限の緩いゲーミングキーボードがほしいな、と思ったのはあるけど、最近はDelta Forceを遊ばなくなってしまったのでな。普通のゲームならそこまで同時押しを求められることもないし。強いて言えば、今使っているキーボードのShiftが若干認識されづらくなって、ChromeでCtrl-Shift-Tabがうまく使えないのが不便、というくらい(以前はマウスのサイドボタンに割り当てていた操作)。

 キーボードとしてはそう変なものではない。全キー同時押しとかRGBライトとかがついているのが普通のキーボードとは違うところ。あとはよく言えば重量感がある。悪く言えばクソ重い。

 今まで使っていたキーボードは普通のものだと思ってたけど、大きさが結構違う。実測でキーピッチ17.8mmくらいかな。買ったやつは実測19.2mmなので、7.8%くらい大きくなった。結構違和感ある。指が届かないというほどではないにしても。

 ここ10年くらいはずーっとパンタグラフ式を使っていたので、高さのあるキーボードは変な感じ。パームレストがないので腕を浮かせる感じで使っている。ストロークに対して閾値が浅いので、少しでも力を入れると入力される。結局腕から指先まで浮かせて使うので、タブレットのソフトキーボードに入力しているような気分になる。20mmとか1インチとかそれくらいのパームレストがあると良さそう。20x20の押出材をおいてみたけど、高さ的にはちょうどいいかな? 冷たいのが難点。。。

 全体的に違和感が大きいけど、大部分は慣れかな。寿司打で軽く遊んだ感じ前のキーボードと大して違いのないスコアだし。

 今まで使っていたやつはBluetooth接続なので、数分操作していないとスリープに入って、再接続に1秒とかかかるので、操作性が少し悪かった。今回買ったのは有線なので、あらゆるタイミングでレスポンスがいいのが快適。ただ、机の周りが狭いので、キーボードを片付けようとするといちいちUSBを抜かないといけないのが面倒。もっと軽ければ適当に物の上に置けばいいんだけど、重量感があるのでそういうわけにもいかず、手間がかかる。



https://www.jstage.jst.go.jp/article/conf/35/0/35_107/_pdf

 2022年。船舶を想定した天文航法の自動化の研究。スタートラッカのアルゴリズムと通じるような内容。ただし視野角が広めでロバスト性高め(雲等の掩体を想定)がSTTと違うところかな。

 星の距離(離角)をカタログ化して探すようなアルゴリズム。ペアの数を2個、3個、4個と変えてモンテカルロシミュレーションで検証。

 あくまでも特定の星ペアの同定しか行っていないのかな。カタログを投影して姿勢をイテレーションするみたいな処理はしていないと思う。そのあたりは次の年の人に任せる、って感じか。まあ、大学の論文ならそんなものか。

 この段階でのモンテカルロシミュレーションだと、恒星ペアを誤認すると、そのパラーメタ(アルゴリズム)は使えない、という判断になるけど、実際には視野内の輝点とカタログを比較してマッチ率が低ければ棄却する、みたいな処理ができるから、実際にSTTを作るのであれば星の同定で誤認率が多少あっても全く問題はない(多少処理速度にペナルティがあるとしても)。院生が1,2年で作業できる範囲に絞ると特定の星を数学的に同定する手法を開発する、みたいな範囲しかできないんだろうけど、実用化を考えるともう少し広い範囲で作業したほうがいいだろうなー、って気がする。STTはわりと簡単に作れる(作れた)し、民間企業なら1,2年もあれば実際に船に乗せて運用テストとかまで行けそう。



https://www.jstage.jst.go.jp/article/jacc/67/0/67_19/_pdf/-char/ja

 太陽位置を使用した位置推定の研究。偏光カメラを使うことで太陽が雲に隠れていても方位・仰角が得られる、みたいなやつだと思う。ヴァイキングのサンストーンの逸話を現代化したって感じかな。

 航空機でGNSSが使用できないときにINSと組み合わせて、INSが発散しないようにする、というような使い方を想定しているんだと思うけど、ちょっと誤差が大きそう。2,3桁改善すれば、信頼性とかコストによっては民間機のバックアップには使えそうだけど、とはいえ偏光カメラか……

 空中衝突(異常接近)はTCASで回避するとして、あくまでもGNSSが無くなったときに紛争地域(or情勢が悪い国)の近くに行かないように、位であれば10kmオーダーの精度があれば使えそう。その程度の精度があれば着陸時はVORに引き継げるだろうし。

 誤差の要因がエアロゾルだとすると、高高度を飛行する航空機であればもう少し良い精度が得られるのかな? 太陽を使うので昼間しか測位できないという問題はあるけど、夜間は恒星を使えばいいだけだし。太陽観測だと低仰角まで見える偏光カメラ、恒星観測だと天頂狙いの挟視野角・高感度カメラが必要になるけど。



 アメリカでの国からの研究資金の提供で、研究補助金は伝統的に軍事研究に限られていて、民間の研究に対して国が補助金を出すことは避けていた(民間の研究は民間で競争させて、国が歪めるようなことはしない)、みたいな話を見かけたんだけど、本当なんだろうか。あと、同じような文脈で、ベトナム戦争後の厭戦気分で軍事研究に対する否定的な意見だけでなく、国からの研究資金自体が自由な研究に対する脅威である、みたいな話もあったらしい。前者が事実だとして、後者の発言も実際にあったものだとすると、つまり国の研究資金というのは軍事的な成果を得るためのものであって、それ以外の研究ができないから、国からの研究資金はだめだ、みたいな話なんだろうか。

 フェルミ加速器研究所の初代所長の「国防に資する施設ではないが、守るに値する国になるために必要なものだ」(意訳)的な発言を考えると、「軍事研究目的の予算」といっても、結構幅広い分野で認められるのかな。まあ、軍の研究予算で折り紙の研究をする国だしな。軍事予算の幅も広そうだが。

 アメリカでは軍事と民間の境界がキッチリ分けられていて、軍事的な組織と民間の組織もかなり分離していたらしい。例えばF-2の共同開発では、MHIがボーイングの旅客機部品を製造していることを理由に、日本に戦闘機技術を渡すとそれが民間航空機部門に流用されて、ひいてはアメリカの民間航空機企業への脅威になる、みたいな考え方。FAA(連邦航空局)も、民間航空機の安全運行を目的としたシステムにGPS(米軍が作ったシステム)を使うことに否定的だった。

 ただ、コンピューターが出てくると軍と民間の分離なんてことは言ってられなくなって、ARPAの資金で民間の研究開発を支援したり、というような状況になってきた。軍の装備品はライフサイクルが非常に長くて、近代化改修を入れても数十年毎になる。複数機種を含めても、せいぜい10年に1回とかの頻度でしか開発ができない。F-14に積んだフライトコンピュータは当時の民間のプロセッサより高性能な計算機が使われていたが、その後は民間の半導体技術(の中でも更に枯れた技術)が軍に採用されるようになった。

 米軍がデュアルユースとかCOTSとかを本格的に使い始めて、アメリカで軍と民間の境界が曖昧になったのは、1980年から2000年あたりのことなのかな。F-14の初飛行が’70年。湾岸戦争で軍用GPSが足りなくなって民生用GPSを大量購入したのが’90年。タイコンデロガにWindowsを乗せたのが’97年だから、民生用コンピュータがある程度普及してから結構時間がかかっている。大型のドンガラにCOTSハードウェアを乗せるようになったのは、パーソナルコンピュータが普及してからかな。

 ただ、このあたりの話を読みたくてググってもいまいちそれらしい資料が見当たらない。大抵は防衛装備庁の補助金制度以降の倫理観とかの議論が大量に出てくる。日本の状況を考えると、数十年くらい前までの、民間と軍事をキッチリと分離したアメリカの予算制度とかは結構参考になりそうな気もするんだけど。なぜアメリカは軍と民間を分離して成長させたのか(国内でクリーンルーム設計を行う非効率性を許容するだけの理由があるはず)、なぜその境界線が薄まったのか、その結果どうなったのか、等。日本の補助金制度の是非はともかくとして、アメリカの制度がどうなったのかを理解するのは意味がありそうだが。日本では防衛装備庁の補助金に対する反対意見(あるいは少なくとも問題提起の形を取ったもの)が非常に多くて、結論ありきで書かれている論文が多い印象。少なくとも、軽くググって出てくる大部分はそういう内容。もっとも、タイコンデロガからまだ30年も経ってないわけで、歴史を振り返るというほどの歴史にはなっていないような気もするが。


***


 波形のSinc補間

 橙が補間前の波形、青が補間後(32倍)の波形。Sincの長さは128(-64~+63)。Sincをそのまま使っているので振動が強い。

 SincをBlackmanで末端処理。振動がだいぶ減る。

 拡大すると、補間前と補間後のサンプルが重なっていて、かつある程度正しそうに補間できていそうな事がわかる。


 畳み込むSincの波形(8倍補間の0と1の波形、Blackman)

 Sincの波形は帯域幅が1のSincのそれで、最初の波形は中央が1のインパルス、それ以外は非対称の波形になる。


 Sincの畳み込み処理はFIRフィルタと全く同じ処理だから、例えば32倍に補間するならFIRを32個並べて、一つのサンプルを順番にFIRに入れていくと、補間した波形が得られる。

 やっていることはただのインターポレーションなので、1個のFIRに長い係数を設定しているのと同じ。ただし長いFIRだと計算量がかなり多いと思う。SincでN倍にするならN個のFIRを並べたほうが計算コストが桁違いに低いはず。感覚的には、FIRインターポレーションでは途中に0を大量に挿入して、それに対しても係数の掛け合わせが発生する。帯域幅1のSincフィルタを複数個並べた場合、0挿入は行わないから、その分で計算量を減らせる。おそらくこれがいわゆるポリフェーズフィルタというやつだと思う。

 さらに言えば0番目のFIRはインパルス応答だから、これをFIRでなく遅延線で処理すればFIR1個分計算リソースを減らせる。FIRで実装するなら全部FIRで処理したほうが楽だろうけど、ポリフェーズフィルタとして実装するならその辺は好きに処理すればいい。


***


 若干遠出する用事があったので、GPSのサンプリング

 ところどころドロップしている。1.92Mspsでも落ちるときは落ちる。

 3区間で前後が移動中(50km/h前後?)、途中が停止中、のはず。移動中はSNRがかなり悪い。相関器のチューニングの問題だと思うけど、停止中のアンテナで取ったサンプルしか使っていないので、移動すると性能がかなり悪化するらしい。

 別PRN

 だいぶSNRが安定している。単に視線速度の問題かもしれないけど。


 相関器を25msブロックで走らせて、40Hzで測位演算。NMEA 0183形式で出力。

 Google EarthでNMEA 0183を読み込む場合、最低限GPGGAとGPZDAが必要。GGAで4次元空間を拘束できるが、GGAには年月日が無いので1日の曖昧さがある。それを解決するためにZDAの日時情報が必要。RMCは年月日があるけど高度がないので4次元を表現するには不便(船舶みたいにジオイド面に張り付いている前提なら問題ないんだろうけど)。

 0183のセンテンス、基本的なフォーマットだと垂直速度(3次元速度ベクトル)の出力はできないのかな。船舶で垂直速度が問題になるような状況なんてないからということなんだろうか。どうしても必要なら$PECEFでISO 8601に続けて位置と速度を出力するようなセンテンスを勝手に作ればいいんだろうけど。

 0183のデータフォーマットが度分秒じゃなくて度分なの、ずっと不思議だったんだけど、これってもしかして海里の近似ってこと? いや、そんな緯度にしか使えないテクニックを採用するわけが…… 経度にしても適当なスケーリング(緯度45度なら3割引)で海里として読めないこともないけど、ちょっと不便。秒で表示されるよりはわかりやすい気もしないでもないが。

 0183はインターネットが普及するより前に機材が普及しているはずだから、それ以前の規格(0180~0182?)はググっても情報がほとんど出てこない。以前の規格はLORAN-C受信機で使っていたフォーマットらしい。主に船舶を想定していた機材だろうし、そもそもNMEA自体が海洋向けの規格化団体だから、最小単位を分に設定して海里に合わせたという可能性は無いとは言えなそう。



 適当な時間範囲の測位結果をGoogle Earthで表示すると、擬似距離で測位演算した場合は誤差がかなり大きくて、水平10m、垂直50m程度の楕円で暴れる感じ。

 ドップラを使うと受信機の移動速度を推定できるけど、これはかなりいい精度で得られる。初期値だけ擬似距離で得た位置を使用して、その後は速度を積分すると、実際に通った距離をかなり高い精度で推定できるし、ノイズ成分(高周波成分)もほとんどない。速度の積分でこんなにきれいに位置が得られるとは思わなかった。ただ、衛星のロックが外れたタイミング?で距離が飛ぶ時がある。速度推定に使う衛星の組み合わせが変わると推定値のバイアスもステップ状に変わるんだと思う。あとは、それなりに精度がいいとはいえ、積分する以上は多少の誤差は防げないわけだし、速度積分だけで長時間の位置推定は厳しいとしても。適当な係数を設定して、位置=(擬似距離位置*k)+((前回位置+速度*計測間隔)*(1-k))みたいな感じで組み合わせると、高周波ノイズをあまり含まず、積分誤差もあまり増えない位置情報が得られる。本来は運動モデルを想定してカルマンフィルタとかを作るべきなんだろうけど。



 NMEA 0183は楕円体高ではなく標高で出力する必要があるので、何らかのジオイドモデルを使う必要がある。

 国土地理院のジオイド2024(ベータ版)を計算してみた(正式に公開されるのは4月1日の予定で、現在のデータセットは正式な計算には使用できない)。

 データセットは一定の間隔(緯度1分角、経度1.5分角)でジオイドの値が固定長文字列で入っているシンプルなデータ。ただ、素直にテキストファイルからfloat配列に読み出すと0.4秒くらいかかる(Releaseビルドだともっと早いかも?)。float配列のバイナリに適当なヘッダ(オフセットとか間隔とか)を含めて保存しておくと、20ミリ秒とか、デバッガの分解能程度の短時間で読み出せる。gzipで圧縮すると読み込みに70ms程度かかるけど、それでもテキストをパースするより圧倒的に早い。テキストファイルは未圧縮で35MB、圧縮しても11MB程度ある。バイナリで書き出すと13MB弱、gzip圧縮で10MBくらいまで小さくなる。

 任意の地点のジオイドを計算する場合、周辺4点から線形補間するような感じで使うらしい。そういうふうに実装して、付属しているexeで計算した乱数列と比較すると、十分な精度(exeで出力される分解能(0.1mm)以下)で得られるから、正しく計算できているはず。オンラインの地理院のジオイド計算機と比較すると多少(数十cm程度)差があるけど、モデルの精度の問題だと思う。補間せずに一番近い点を使うと最大で0.5m(大部分は0.1m以下)程度の誤差になる。ジオイドって結構勾配あるんだな。



 以前電子基準点付近で取ったサンプルから擬似距離で測位演算

 約30秒間のデータを40Hzで出力。サンプルは電子基準点の南側に10mくらい離れた場所で取っている。少し東寄りで上に上がった場所に、上下方向に広く分散している感じ。断面積が一番細い部分では直径10m程度かな。

 このサンプル、2.4Mspsで取っていたので時々ドロップしている。一番長いところで13分くらい連続している。13分間のNMEAでも最小断面積の場所で15m程度かな。単独測位でも水平方向はそれなりに安定している。



「GPSのしくみと応用技術」32pの図1-6「GPS衛星に搭載されている送信系のシステム」の図、出典はどこなんだろう。少なくともIS-GPS-200にはこういう図は見当たらないと思うだが(見逃してるだけかもしれないけど)。


 GPSの搬送波、L1,2,3,5はシンプルな整数比なのに、L4(1378.9133..)だけ10.23*1214/9という分数比になっているのはなんでだろう? 1381.05MHzとかじゃだめなんだろうか。他の割当との関係とかなのかな。


https://www.echiba.org/wp-content/uploads/2022/12/kenrenshi_054_2.pdf

 1999年頃? 千葉県の遺跡のデータベース化に関する話。

 途中にNMEA 0182の簡単な説明がある。「NMEA 0183で細かいデータが得られるが、詳細なデータは必要ないからNMEA 0182で十分」みたいな感じで選んだらしい。

 0182も度分で表現するのは0183と同じ。度と分のそれぞれにDと'がついているので、桁区切りの曖昧さが無いのが便利そうだ。



***


 C#でclassからrecordに派生できない制限、地味に不便な気がする。例えばrecord HogeEventArgs(int Index):EventArgs;的なことができなくて、class HogeEventArgs(int index):EventArgs{public int Index=>index;}みたいに書かなきゃいけない。


 C#のswitchのパターンマッチでcase TypeA a: case TypeB b: case TypeC c:みたいに複数型を列挙して、マッチしなかった形にはnullが入る、みたいな処理が欲しいような気がする(現在は全変数で未初期化エラーが出る)。

 結局変数のnullチェックが必要になるから、ifとかで分岐するくらいなら内側でもう一回switchでパターンマッチしたほうがいいとかなのかもしれないけど。


2025年2月19日水曜日

小ネタ


 ニデックが2度目の質問状に回答、「企図するシナジーの定量化は困難」:製造マネジメントニュース - MONOist

 我が社(ニデック側)が欲しいから買う、牧野側への利点は特には無い、株主には牧野独立では得られない利益を与えるんだから文句を言うな、みたいな雰囲気。


 フォトカプラを使って商用電源の周波数を捉えるプローブを作製する:電力ブラックアウトを予測する(2)(2/3 ページ) - MONOist

 普通のフォトカプラをRだけでAC100Vに接続するのってやっちゃだめじゃね? このフォトカプラの発光部の逆電圧(絶対定格)は5Vだから、AC100Vだと数十倍オーバーしてる。AC100Vをフォトカプラに突っ込むならAC対応型のフォトカプラを使うか、あるいはフォトカプラと並列に逆電圧を逃がすためのダイオードをいれる必要があるはず。

 ブラックアウトって周波数で予想できるのかな? 最近のブラックアウトってトラブル(発電所の停止とか運用ミスとか)で突発的に起きてる印象。周波数の監視って10年くらい前に話題になってた気がする。この人の記事、話題が10年くらい前の雰囲気がある。


 高知に宇宙港を。「スペースポート高知」発足、目標は'29年ロケット打ち上げ | TECH+(テックプラス)

 イメージ図、生成AIで作ったものとはいえ、なんだかなぁ。



 Delta Forceで遊んでたらいきなりOSが落ちてびっくり。しかもOSが起動できなくなって、電源長押しで落としてから再起動したらWindowsの修復が走った。以前遊んでいたゲームではOSが落ちるのはよくあることだったけど、DFでは初めて。今シーズンはour system detected irregular data activityでゲームが落ちる頻度も高いし、なんか調子悪そう。とはいえ、irregular data activityはアンチチートの誤検知としても、OS巻き込んでクラッシュはちょっとやることが大きすぎるというか。

 誤検知で落とされるのもプレイのモチベーションにかなり悪影響が大きいし、最近はウォーフェアで猛者がモサモサしてるマッチに入れられてリスキルされまくったり、DF遊んでて楽しくなくなってきた。そろそろ潮時かなー。



 自分は遊んだことのない某PvPメインのゲームジャンルを興味本位でぐぐってみたら「初心者だから勝てないとか言ってる暇があったら基礎的な部分を学んでからゲームをやれ」みたいなことを大手ネットメディアが書いてて、うーん、厳しい世界、って感じ。自分で座学をやってガチってからじゃないと入門すらできない世界ってあっという間に衰退しそうだが。


***


https://jjy.nict.go.jp/QandA/reference/Proceeding/sympo-pro6.pdf

 JJYを使った高安定クロック。-11乗くらいの安定性。Rbを内蔵しているので数時間程度の停波でも安定。国家標準の周波数に同期できる。感度の高いアンテナに接続する必要がある。いつ頃の話かわからないけど、2005年前後あたり? もう少し前かも。


https://www.jstage.jst.go.jp/article/jinnavib/62/0/62_KJ00004995621/_pdf

 1979年。NAVSTAR/GPSに関する解説。Block Iの時代。

 我が国では最近、小型の漁船にまでNNSSの受信機が普及をして、衛星航法が非常に身近なものとなってきている。(後略

 NNSS、そんなに普及してたのか。

 PコードとC/Aコード。C/Aについては「Clear/Acquisition(明瞭/捕捉)」という説明。

 CMDAの原理とか色々。

 軍用のPコード受信機。2周波4chを受信する。

 民間用のC/A信号受信機。1周波1chの受信機で4衛星を時分割受信。「なお、C/A信号のみの受信機の価格は、量産の個数にもよるが15000~25000ドルと言われている」すげー値段だ。1980年から2025年のインフレ調整を行って現在のレートで940~1600万円くらい。半世紀経って、高性能化したうえで3,4桁安くなっている。電子技術の発達ってすごいんだな。


https://www.jstage.jst.go.jp/article/itej1978/41/4/41_4_334/_pdf

 1987年。衛星航法の説明とか。

 NNSS。改良型のNOVAの仕組み。衛星の中に金属球を浮かせ、それを一定の位置に維持するようにスラスタで制御を行う。これにより空気抵抗による減速を除去する。ドラッグフリー制御をやっていたらしい。

 その他のシステムの解説とか。GPS(米軍)、GEOSTAR(米民)、GLONASS(露)、NAVSAT(欧)、GRANAS(西独)。


https://www.jstage.jst.go.jp/article/jinnavib/67/0/67_KJ00004995745/_pdf/-char/ja

 1981年。NOVAの解説。NNSSの精度改善に必要な事項など。

 ドラッグフリー制御(DISCOS; Disturbance Compensation System)の説明。内径40mmの空間に直径22mmの合金球を浮かべ、その位置変化を衛星の軌道制御にフィードバックする。合金は非磁性と質量の要求から、金70%、プラチナ30%の合金で、重さは111g(衛星全質量の0.13%、水との比重でほぼ20)。軌道制御は小型のイオンエンジンを使うらしい。最初は3次元で、以降は1次元で軌道修正を行う(進行方向のドラッグが支配的らしい)。衛星のイラストに「テフロン推進器」というのがあるけど、これがDISCOSのスラスタかな。

 衛星にコンピュータを乗せて、衛星側でいろいろな計算を行う試み。

 スペクトラム拡散の追加。コード周期19.66ms(NNSSの航法メッセージの1bitに相当する時間)の拡散符号を使用して時刻同期を行う。ドップラとレンジングを併用したDOPRANという手法で測距したり、USNOとNBS(現NIST)で時刻比較の実験を行ったり。


https://www.jstage.jst.go.jp/article/zogakusi/665/0/665_KJ00001777323/_pdf

 1984年。GNSSの解説とか。

 NNSS。米軍が使用している受信機のマニュアルを実費で販売することになり、様々な組織で受信機が作られるようになった。測位の原理等。NOVAの改良点。受信機の概観。受信機は28社が製造し、中23社の集計で、’83年までの累計で5万台程度が販売されている。その中1周波型が93%を占め、全体の中で軍用は400台程度。GPS運用開始後5年後(’94年頃想定)まではNNSSとNOVAをそれぞれ2基ずつ運用する計画。

 NAVSTAR GPS。NNSSの欠点を解消できるように計画。原理とか色々な解説。当初計画で24個の衛星が、予算的な問題から18個(+予備3個)へ削減。予備無し(18個)では1日に2回、測位ができなくなる地点が発生する。予備を含めた21個でも1日に1,2回測位精度の劣化が発生する。受信機の試作。4-5chの受信機を使用し、航空機等に搭載するもの。1chを1秒程度ずつ切り替えて使う、低速な乗り物に使用するもの。1chを小型軽量化しマンパック形にしたもの。C/Aコードを使用する1chの受信機で、輸送機等に使用(後に民間用へ変更)。1chだけだとメッセージの受信にそれぞれ30秒ずつ受信する必要があるから、2chのモデルがあったり、あるいは1bit区間で複数の衛星を切り替えて1chで受信できるモデルだったり、いろいろ提案されている。フェーズドアレイアンテナの提案も。’83年の大韓航空機撃墜事件の後、大統領がGPSを民間航空機で使用する決定を行ったが、軍用システムであることから民間機で使用することに対する根強い反対がある(この頃のアメリカはデュアルユースに対してかなり否定的)。事件前には議会はGPSユーザーから使用料を徴収しようとしていたが、事件後は態度を軟化させ、無料で使えるようにする方針。ただしC/Aコードでも測位精度が高いため、意図的に精度を劣化させる措置を行う。

 ソ連のシステム。NNSSと同様のCicada(Tsikada)と、GPSと同様のGLONASS。Cicadaをイギリスが解析した報告。GLONASSについては詳細は不明。

 欧州が提案する民間用の測位衛星NAVSAT。衛星に原子時計を搭載せず、ベントパイプで放送する。3軌道面8個ずつ24衛星。DSSS(10Mcps程度) or CWを予定。DSSSは測距しやすく、CWはドップラ解析しやすい。データ133ms+ガードタイム17ms(1周期150ms)のTDMA形式。地球の裏側にいる衛星とはフレームを共有できるので、12フレーム(1.8秒周期)で1巡。

 IMOでの検討。今のところGPSが唯一のシステムだが、軍用(デュアルユース)への拒否感がある。米民間が構想しているGEOSTARもあるが、これは静止軌道上のトランスポンダを使用した地域測位システムであって、IMOが求める全地球規模で測位する能力はない。GPSかNAVSATかどちらを使うか、という感じ。

 最後に「(前略)最終的には腕時計程度の大きさの利用者装置による個人用の衛星航法装置が実現される可能性も考えられている。21世紀の前半のある時期にはそのような時代が来るであろう」とのこと。GPSを内蔵した世界初の腕時計とされるのがカシオのPROTREK PRT-1GPJで、発売が1999年。15年後、20世紀の末にはすでに実現していた。



https://www.hitachi.co.jp/New/cnews/month/2009/02/0218.pdf

 2009年。IMES送信機の試作例。かなり小さい。

 L1 C/Aの送信ってどんな感じでやるんだろうか。変調方式を工夫して少リソース化したみたいなことが書いてあるから、本来はある程度複雑な演算が必要なんだろうけど。しかし、GHz帯とはいえWiFiやBluetoothよりは低い周波数だし、BPSKだし。そこまで複雑になるものかな。


https://www.jstage.jst.go.jp/article/sicejl1962/20/2/20_2_236/_pdf/-char/ja

 1981年。m系列に関する数学的な解説とかが色々。

 単に乱数としての特性を求めている感じ。100bitのレジスタで乱数を発生させれば1Gbpsで出力しても地球の年齢の8000倍くらいの長さの乱数が得られる、とか。

 デジタル回路(フリップフロップとかXOR素子)でm系列を作る場合、200Mbps程度で頭打ちで、将来的にもさほど改善はしないだろう、という予測。遅延線を使うと700Mbps程度で出力できた報告がある。


https://www.jstage.jst.go.jp/article/safety/31/2/31_117/_pdf/-char/ja

 1992年。土木工事で発破作業を行うときに、起爆タイミングをm系列で遅延させればスペクトルのピークを下げられて、低周波音の問題(窓のガタツキとか)を減らせるのではないか、という提案。ググってもあまり出てこないので本格的に導入するほどの効果は無いんだろうけど。共振が問題なら各段で遅延時間を増す(or減らす)シンプルなチャープ変調で良さそうな気がするが。


https://www.jstage.jst.go.jp/article/jasj/53/6/53_KJ00003054009/_pdf/-char/en

 1997年。エアコンのファンを等間隔でなくm系列に従った間隔で配置することで、ノイズのスペクトルを分散させる提案。


***


 rtlsdrblog v.1.3.4のrtl_tcp.exe経由でサンプリングした1575.42MHzの特定の衛星に対する時刻差

 やっぱりドロップする。バージョンの問題ではないのか。


 受信時のクイックルック画面

 1575.42MHzを2.4Mspsで受信中(切断しているのでbias teeのチェックが外れているが、どちらもB-T ONで受信)。ゲインはテーブルから28を設定している。ppmの設定をリセットするの忘れてるけど、5ppm程度なら誤差ということで。

 一番下が周波数スペクトル、その上がサンプルのヒストグラム。左が1.3.4、右が1.3.6で受信(同じドングルに対してrtl_tcp.exeを切り替えて受信)。1.3.4に比べて1.3.6はヒストグラムが広く、スペクトルも高めに出ている。1.3.5でLバンドの感度が改善したそうだが、ちゃんと効果はありそう。まあ、この図だけだとノイズが増えただけという可能性も捨てきれないが……


 rtl_tcpでなく、rtl_sdrで直接ファイルに保存

 やっぱりだめっぽい。

 rtl_sdr、オプションでBias-Teeを指定できないのがつらい。運が良いとrtl_tcpとかで有効にしたBias-Teeが残っているけど、残る条件がよくわからない。結局10分とかサンプリングしたあとに解析してみないとわからないので、作業効率が著しく悪い。毎回rtl_eepromでBT強制有効化とかするのも嫌だしな。


 rtlsdrblog版でなく、フォーク元のosmocom版のrtl_tcp経由でサンプリング

 やっぱりドロップする。rtlsdrblogがフォークしたのが6年前だから、それより前からあるバグなんだな。


 PCの処理能力の問題かと思って、SDRのサーバーとして同軸ケーブルを引き込んでいる場所においてあるNUC(N5105)から、ノートPC(core i5 gen2 M)に変えてみたけど、相変わらずドロップする。i5とはいえ10世代以上前だし、N5100のほうが早そうな気がしないでも。。。とにかく、悪化も改善もしないから、PCの問題(含USBの帯域幅等)ではなさそうというのがわかっただけでも収穫。


 サンプリングレートに2.4Mspsを設定したのは、帯域幅が広いほうが良かろうみたいな理由もあるけど、もう一つはサンプル数が多いほうが相対的にノイズを減らせる(信号はコヒーレントだがノイズはインコヒーレントだから、コヒーレント積分すれば信号はN倍になるがノイズは√N倍になるはず)みたいな理由もある。



 NUCのrtl_tcp経由でいくつかのサンプリングレートで取得

 1.024Mspsと1.44Mspsを除いて、2.048Msps以下はドロップしていない。2.304Mspsや2.4Msps、2.56Mspsは高い頻度でドロップする。

 0.96MspsはC/Aコードのチップレート(1.023Mcps)よりも帯域幅が狭いが、それでも一応コードの追尾やメッセージの復調はできる。

 それぞれのサンプルを15分ほど記録しているので、0.96Mcpsと2.56Mcpsでは3時間以上の時間差があって、衛星の配置や伝播状況も違うだろうから、単純な比較はできないとしても、やはり帯域幅が広くなればそれだけSNRが改善する傾向は見て取れる。1.28Mspsの500秒付近とか、1.6Mspsの300秒前後とか、1.8Mspsの500秒付近とか、相関値がかなり低下した部分でもメッセージの復調が行えている。ここまでロバストだとは思わなかった。BPSKの多数決ってすごいんだな。

 途中、メッセージの復調率が極端に低下する事があった。そういう場合、TOWは適当な値(今回は144972)に固定されて、メッセージは6秒(サブフレーム)毎ではなく、30秒(ページ)毎に復調された。おそらくSF1,2,3のどこかに偶然プリアンブルが出てきて、しかもそれらの前後で正しいパリティのビット列が生成されてしまったんだと思う。LNAVメッセージって偶然にプリアンブルやパリティが出てくることは防げないっぽい。あくまでも1ページ毎の繰り返しなので、例えばサブフレームを挟んで2箇所のプリアンブルをチェックするとかで、誤った位置にロックすることができる。正しいプリアンブルは必ず300bit周期で出てくるが、偶然なプリアンブルが300bit離れた場所に出現して、しかもその周囲のパリティも正しくなるという確率はかなり低いはず。絶対に有り得ないかと言うと、わからないけど。念を入れるなら例えば1ページ30秒のビット列を持っておいて、プリアンブル5個とサブフレームIDの連続性を確認する、みたいな手法は考えられるけど、計算量とか、メモリ使用量とか、実装の手間とか、色々高コスト。一番大きいのはTTFFがその分遅くなる点。まあ、同期ができた時点で1ページ丸ごとメモリに入っているから、その時点でエフェメリスとか必要な情報は全部持っている、という利点はある。うまく実装できればこっちのほうが楽な可能性もあるな。PCで処理する前提ならPRN1個毎に3.6万ポイント(int型複素数なら約300kB)は問題になるような量じゃないし。


 RTL-SDR Blog V4ドングルならなにか変わるかな?と思ったけど、これダウンコンバータが変わっただけでADC以降はRTL2832Uのままだから、サンプリング周りは変わらないのか。


 別のタイミングでサンプリング

 今度は2.048Msps以上はすべてドロップしているが、1.92Msps以下は問題ない。


 ドロップしたサンプリングレートを捨てて別のサンプルを取り直す

 ↑2回戦。1.28Mspsと1.536Mspsが脱落。

 ↑3回戦。脱落者なし。

 ↑4回戦。うーん、落ちない。。。。。。

 その後、第5回戦、6回戦でも脱落者なし。第7回戦でようやく1.8Mspsが脱落。もっと高頻度にドロップするような印象があったけど、なかなか落ちないな。


 1.92Mspsで4フルフレーム分サンプリング

 2800秒あたりで途切れてる

 ドロップした場合はある程度高い相関値から急激に落ちるけど、落ち方がゆっくりしている。衛星が障害物に隠れたみたいな感じ。急に高い相関値で現れているけど、これは相関器をリセットして再同期したため。別のPRNを指定すると途切れずに復調できるので、データのドロップではない。

 この時の衛星の方向には立木(松)が1本あって、この日は雪が降っていたので、木に積もった雪がLバンドをブロックしていた可能性は無きにしもあらず。とはいえ、GPS衛星の軌道速度(2.3万km先で4km/s)でこんなに動くものかな。100秒で1度くらいしか動かないはずだが。回折とか反射で干渉したみたいなことなんだろうか。

 1.92Mspsは結構優秀かも。ほとんどドロップしないし、サンプリングレートは高いし。



 逆に、超低SPSでサンプリング

 0.3Msps、C/Aのチップレートの29%の速度。短時間のサンプルで、最後の方はデコードに失敗しているし、Early/Late/PromptのMagnitudeの差が無くてなんで追尾できているのかわからないけど、それなりにメッセージの復調ができている。取得したTOWも受信時刻に対して整合的。復調処理も高spsに対してかなり早い(データ量が1桁少ないんだから、1桁早い)。ただまあ、復調の性能はかなり悪いと思う。



 やはりワンセグチューナー(RTL2832U)系のSDR受信機は安定性にネックがある、ということなのかな。もう少し上のグレードの受信機がほしいけど、とはいえHackRF Oneとかだとちょっと大げさじゃね、と思いつつ、でもそれ以外の選択肢ってあんまりなさそう。Airspy MiniとかR2はプロプライエタリな感じっぽい。libusbデバイスのはずだからWin32で叩けばアクセスはできるんだろうけど。HackRF OneはWindowsのツール郡の入手性が悪そう。最近はWindows版バイナリは配布されていないっぽい? Ubuntuが推奨環境だそうだ。HRO本体が4万円~、それを叩くためのUbuntuの実機を買うのに中古のノートなり安いNUCを買うなりで3-5万円~、気軽に買える値段じゃない。SDR#でHROの受信に対応しているらしいから、IQバイナリを数秒取る程度ならWinでもサクッと行けそうだけど、長時間(4GB以上)とかリアルタイムに処理したいとか中途半端なサンプリングレート(8.127Mspsとか、16.254Mspsとか)を設定したいとかだと困りそう。



 試しにPコードを生成してみた。first 12 chipsを見る限りは多分正しく生成できている。Pコードは約1.5秒のコードを繋げていくので、せめて数十秒くらい確認しないと本当に正しいかはわからないけど。

 Pコードって頭の数十チップは全PRNで共通なんだな(PRN番号が低い方ほど共通部が短い)。時間にすれば数マイクロ秒程度だけど。C/Aコードに比べれば複雑ではあるけど、リアルタイムに生成するのが前提のコードだから、極端に複雑というものでもない。

 P(Y)コードってPコードだけで逆拡散したらどんなスペクトルになるんだろうか。幅500kHzくらいのSinc型に見えるんだろうか? 20Mspsくらいの受信機か……


 GPSのWコードってどうにか解析できないんだろうか? 何らかの法規制でP(Y)コードを使う機器がアメリカで販売できないとしても、例えば中国で作って国内で使う分にはどうなんだろうか。DJIのRTKキットでWコードを解析してドローンとPコードでRTKを行う、みたいな。

 アメリカのDJIに対する規制ってどうなったんだろうか。あんまり規制しすぎるとアメリカ市場を完全に分離して、中国国内でGPSの機密コードを積極的に活用するような方向に行きそうな気もするが。それともYコードはそう簡単に解析できるようなものじゃないのかな。



 amazonで先月22日に注文したU.FL-SMA変換コネクタがようやく届いた。当初予定だと1週間くらい前には届いていたはずなんだけど、春節にぶつかった感じ。

 小さなGPSアンテナをSDRドングルに接続できる。ただそれだけ。窓際に置いてサンプリングしてみたけど、1個も相関強度でなかった。まあ、アンテナがこの大きさだしね。。。暖かくなったら(その時に覚えていたら)外でサンプリングしてみよう。

 一応、Bias-TeeをONにすればヒストグラムが広がるので、DCは通るし、Lバンドも通っているはず。アンテナ自体はNEO-6Mに接続して野外で受信できたから、問題ないはず。SDRと組み合わせたときの感度が十分かはまた別の話。