小ネタ

　わざわざイギリスからクラインの壺(あるいはclimb(登れる)の壺)を日本まで見に来たレポート動画。JAXAでSOLAR-B(ひので)に関わってる友人に案内してもらったけど、件の遊具を作った人は東京大学でプラズマの研究を行っていた人で、ISASとも関わっていたんだとか。

　Desktop Latheを作るってことはDesktop Millも順調に売れてるんだろうなぁ。

　オーストラリア国防軍の求人動画のメイキング。

　Android版のChrome、PDFビューアーがないのが不便というか謎い。

　Android板のYouTube、動画再生ページを経由せずにチャンネルページを開けないのが謎い。

　過去に使ったデバイス、iPod touchとかiPad miniとか、iOS系ばっかりだったのでAndroidの取り扱いがいまいちよくわからない。

　Steam Linkを入れるとPCのゲームをスマホへストリーミングして遊べる。自宅のWiFi環境でも30MbpsくらいでPCとリンクするので、普通に遊ぶ分には問題ないけど、時々ドロップする時がある。APが古いからかな。

　操作はタッチコントローラー以外に、Xboxコントローラーを使ったりすることもできる。AndroidとXboxコントローラーはBluetoothで接続できるけど、WiFiとBluetoothが干渉するらしく、コントローラーを操作すると急激にドロップする。有線で接続するとRF的には問題ないけど、コントローラー側の安定性が悪い気がする(挙動的にコントローラのUSB端子の劣化っぽい)。

　ルーターが5GHzのWiFiに対応しているので、そっちに接続してワイヤレスのXbox Oneコントローラーで遊んだら、結構快適。いかんせん画面サイズがどうにもならないけど。Pixel 8以降だとType-C - HDMI(or DisplayPort)ケーブルで画面出力ができるらしいので、8インチくらいのモバイルディスプレイに接続したらある程度快適に遊べそう。まあ、そこまでしてPCゲームを遊びたいならもう少し良いソリューションがあるのでは、という気もしないでもないけど。

　最近だとSteam DeckとかROG Allyとか、7インチくらいのPCゲームプラットフォームも出てきてるから、もう少し経てばPCゲーも低解像度で支障なく遊べるような感じになってくるのかな。WiFiもどんどん広帯域化・低レイテンシ化してるし、ローカルのPCでレンダリングしてスマホにストリーミングして遊ぶ、みたいなのはあと数年も経てばどんどん快適になっていきそう。まあ、5Gとか6Gとかが普及すればサーバーレンダリングのストリーミングが主流になるんだろうけど。

　VelbonのEX-Miniという小型の三脚、足のデザインが良くて、3本とも縮めた状態でもいいし、1本伸ばしても調整不要で水平を維持するし、もちろん2本伸ばしても水平を維持できる。狭い場所に置いても比較的邪魔にならないし、アンバランスな物を乗せているときも重心側だけ伸ばせば安定する。スマホホルダーを組み合わせれば卓上でスマホを自由な向き(&比較的自由な位置)で固定できるから、スマホを動かす必要のない状況(加速度センサとかジャイロセンサに入力を与える必要がない状況)だとだいぶ便利。机の上にベタ起きするよりかなり操作しやすい。amazonで安いときは1900円台で売ってるのでオススメ。

　C#のTcpClientのConnectのタイムアウト、普通(192.168.1.xxxとか)は21秒くらいだけど、ローカルホスト(127.0.0.1とか)は2秒くらいでタイムアウトする。自分自身にアクセスしてるんだからルーティングの遅延とかもないわけで、数秒待っても接続できないなら今後見込みはない、みたいなことなんだろうけど。

　タイムアウトした場合はエラーコードは10060を使うけど、ローカルホストから2秒程度で投げられるSokcetExceptionはエラーコード10061が返って、タイムアウトではなく接続が拒否されたという扱いらしい。

　TCPのタイムアウト時間はWindowsの場合レジストリで設定されていて、初回3秒、リトライ2回、リトライ毎に待ち時間を倍増で、3+6+12=21秒がデフォルト。つまりローカルホストに接続した場合に2秒ちょっとで例外が出るのはTCPのタイムアウトとは別のロジックらしい。

　SGP4Methods.SGP4Lib.elsetrec、大量に読み込むとそれなりに時間がかかるので、バイナリでキャッシュできないかなと試してみた(PCで実行)。あくまでも一つの大きなTLEをキャッシュするのが目的であって、過去数十年分のTLEファイル(数千個から数万個のテキストファイル)を素早く読み込む、みたいな処理は考慮していない(ストレージ消費量に目をつむれば、読み込むデータが増える分で強烈に効いてくるので、そういう用途が無意味な訳では無いが)。

　テキストファイルからTLEを約5.3万件読み込むのに0.48秒くらい。これを直接バイナリで書き出すのに0.15秒くらい。あるいはGZipで圧縮すると書き出すのに1.8秒くらい。読み込む場合は、直接バイナリを読み出す場合は0.14秒、GZipから読み出す場合は0.2秒くらい。ちなみに、TLEのテキストは8.0MiBくらい、バイナリは52MiBくらい、GZipは14.5MiBくらい。elsetrecは計算の途中の変数とかも一部持つので、全部保存するとめちゃくちゃデカい。なお、GZipはSmallestSizeを指定したけど、Fastestを指定すると0.34秒/15MiB程度で、ほとんど性能劣化無しに処理速度が5倍くらい早くなる。

　読み込み速度は間違いなくバイナリが最速で、続いてGZip、最後にテキストのパース、という感じ。読み込みの場合は同期処理(TLEを読み込まないと次の処理ができない)だけど、書き出しは非同期処理(バックグラウンドで行える)なので、実質的には無視できるから、読み込みだけ考えればいい。

　バイナリは容量が大きすぎるので除外して、GZipが選択肢だけど、速度の改善が2.5倍程度しか無いんだよなー。環境によっては、例えばTLEの読み込みに使う計算が遅いとか、GZipの展開は最適化してあって早いとかで、もう少し倍率が稼げるかもしれないけど。あと、今回はMarshal.PtrToStructureを使っているので、unsafeなら数倍早くなるはず。

　C#のSGP4Methods.SGP4Lib、たぶんFortranとかで書いたものをCに移植してさらにC#に移植した、みたいな流れだと思うんだけど、あんまりC#っぽくないコード。あちこち書き換えたい気は山々なんだけど、引数がout修飾子含めて88個とかアホみたいなメソッドもあるので、下手にさわれない。世の中のコードがこんなのだらけならそりゃプロジェクトも炎上しますわ。

　AndroidのAPIで端末の姿勢を受け取って、TLEから求めた衛星との位置関係から、端末で追尾した衛星の名前を表示するアプリを作ってみた。夜空で動いている物体を見つけたら端末で追いかけるとその物体の名前がわかる、みたいなやつ。実際のところは評価関数で順位付けして順に名前を表示するだけだけど。

　先週時点でほとんどコードはできていたんだけど、うまく動かなかった。原因はSGP4で得られるkm単位の結果を、m単位を想定しているECI/ECEF/BLHライブラリに突っ込んでいたのが原因というよくあるやつ。何回やるんだ。。。

　端末と衛星の位置関係は、例えば端末を向けた方向(画面の奥)にある衛星を探す、みたいな処理じゃなくて、端末のローカル座標で見た衛星へのベクトルの変化を見ている(変化が少ない順に表示している)から、例えば端末の縁を目線に合わせて衛星を追尾する、みたいな使い方ができる。もっとも、部屋で考えたときは端末の縁を目線に合わせるのは便利そうだけど、あくまでも机上の空論であって、衛星が目視できるほど暗い場所じゃ端末の縁は見えないわけだが。

　とりあえず、TLEから求めた方位・仰角の方向を端末で追尾すると妥当な結果が得られているので、おそらく動いているはず。ただ、実環境ではまだ動作確認ができていない。晴れた夜が少ないというのもあるし、簡単に見つけられるほど明るい衛星もそう多いわけではないし。日によってはチラッと見上げるだけで何個も見つけられるときもあるのに、数日夜空を見上げても見つけられないときもある。片手間で肉眼での衛星探しはけっこう大変。

　結局、肉眼で見つけた衛星の名前を逆引きするアプリより、衛星の位置を表示するアプリを作るほうが便利なんだろうな。名前の逆引きはGUIを作らなくていい(テキストだけでいい)から作るのは楽なんだけど。

　.NET MAUI AndroidのPicture In Picture、とりあえずそれっぽいのは動くけど、アプリ内のPIPの方法がわからない。例えばYouTubeアプリは動画を再生中に下にスワイプするとPIPが出て動画はそこで再生されるが、YouTubeアプリ自体は依然表示されていて、動画を探したりの操作ができる。こういう表示をやりたいのだけど、方法がわからない。

　たぶんPIPの後ろで操作できる画面とPIPで小さくする画面を別のActivityとして起動する、みたいな操作のはずなんだけど、.NET MAUIでActivityを追加する方法が調べてもよくわからない。

　.NETを使うMAUIは使い慣れたC#を手癖で書けるとか、既存のロジックをほとんどそのまま流用できるとか、開発環境(Visual Studio)がすでにインストール済みだからMAUI周りだけ追加すれば環境を構築できるとか、色々と利点もあるけど、公式・非公式どちらもドキュメントが少ないとか、MAUI自体が新しいフレームワーク(元Xamarinの非互換)だから既存のドキュメントが流用しづらいとか、デメリットも多いんだよな。結局Androidだけをターゲットにするなら開発環境の構築とか、(自分的には)使ったことのない言語(Java or Kotlin)の学習コストを踏まえても、公式が用意している開発環境を使うほうが良さそう。

　とかいいつつ、なにか作りたいものがあるわけでもなし、わざわざAndroid Studio入れようとかKotlin学習しようみたいなモチベもないのよな。開発端末を衝動買いしたとは言いつつ、実際のところは古くなったiPad miniのリプレイス的な意味も強かったので、普通にWebブラウザとかちょっとしたアプリが走ればそれで十分というか。

　いちおう、5年以上前に自作したTLE表示アプリ(HTML/JavaScript)を置いているサーバーが年度末でサービス終了なので、それの代替手段をどうにかしなきゃなーとうっすら思っているところではあるのだけど、とはいえ当時みたいにキューブサットのダウンリンクを受信したりとか、人工衛星の写真を撮ったりみたいなことは最近はやってないので、あんまり使うこともないしなーと考えつつ。暇になったら作るか……とか思いつつ、とはいえ最近暇してばっかりなんだけどなー。気力ゲージがすっからかんで何もやる気が出ねぇ。