小ネタ

　スミソニアン博物館に併設されたレストランの人気メニュー、酢味噌の和え物、という電波を受信。

　酢味噌はジェームズ・スミソンが考案した洋食が元になっていて、たまたま考案者と使用した調味料の日本語名が似ていた、という説はどうかな。次のエイプリルフールにでも覚えていたら使おう。

　変な知識詰め込んでるやつは夕食に酢味噌の和え物が出てくるだけでスミソニアン博物館の出資人の話題になるぞ! コイツ面倒だから気をつけろ!!

　食べ物関係の話題もう1個。 

　どっかの大学の学食に「えくすてん丼」とかないかな、と思ったり。XRISM搭載Xtend、関係者多すぎてどこで開発してるのやら。。。西の方で開発してるのかな?

　鉄とかカルシウムとか豊富な大学生向けの安くて大盛りな丼物。意外とアリかも? ピザのクォーターみたいに4分割になってると再現度高そう(4ピクセルCCDなので)。

/* Xtendの観測域ってCaとかFeとか入ってるのかな? */

***

　最近いろいろなものが無くなっていくなぁ。今度はデジカメの予備バッテリーが行方不明。本体に入ってる方があるのでとりあえず使うには問題ないのだが。いったいどこに消えていってるんだろうか。時空の裂け目でもあるのか?

　暖かくなってきて暖房器具を片付けたので、ちょっとスペースが作れた。ということでデスクデフラグが行える。頑張って片付けよう。。。暖房器具を片付けた途端にまた寒くなったり嫌な天気でやる気が出ない(オイ

***

　某ゲームに出てくる、火口を利用した大きなパラボラアンテナ(「衛星通信設備」)、こんな熱帯雨林にこんなアンテナ似合わねーよ、とか思ってたけど、よく考えたらアレシボもFASTも湿潤な地域にあるよなぁ。

　FASTは3GHzまで、アレシボは10GHzまで、が観測範囲。皿が大きい分、観測帯域は低め。このくらいの周波数帯なら水の吸収帯からはだいぶ離れてるからあんまり影響ないのかも。もっとも、電子レンジの2.4GHzとか富士山レーダーの3GHz弱を踏まえると、SバンドやCバンドでもある程度は吸収されるはずだが。まぁ、真上を向いてるから、よほどひどい天気じゃなければすぐ突き抜けちゃうか。

　衛星通信設備として考えると、ビームが固定なのってどうなんだろう? 静止衛星相手なら問題ないか。むしろあんなでかい設備いらねーよ、という話も。

　そもそも群島を一つ封鎖して外部との通信が一切不可能ってのが腑に落ちないんだよなぁ。どうやってシールドしてるのやら。イナホ送り込んだらあっさり論破されそうだぞ。「電磁波が出入りできないなら太陽光も入ってこないから真っ暗になるはずだ」とかなんとか。

　昔そんなアニメ映画があったよーな気が。日本が鎖国して他国の諜報員が潜入する、みたいな話だったかな。謎のデバイスを何十秒か何百秒か起動しておくとジャミングを解析して偵察衛星から見えるようになる、みたいな。あらすじとかタイトルとかさっぱり思い出せないのだが。

***

　STM32G4でわりとパフォーマンス重視のコード、「ベタ書きすれば早くなるんべ?」と何も考えずループを展開したらものすごい遅くなった。。。ループの中はC言語で6センテンスくらいでフラッシュのLUTを参照するような処理なので、キャッシュに載せて命令は使いまわして流すほうが早いらしい。

　マイコンでも命令キャッシュを意識しなきゃいけないなんて、時代は変わったんだなぁ。というか、STM32F4でも命令キャッシュ乗ってるし、だいぶ前からそういう時代なんだが。

***

　NTSC調べ直してて、思ったより影響力強くて驚き。

　FMラジオのIFが10.7MHzなのは、3fscで設定したらしい。曰く「大量生産されている水晶を流用できるから」だそうで。本当か? 水晶でWFMのIFフィルタって帯域幅狭いんじゃね? 外部クロックの同期を目的とした水晶なら広めの帯域通せるのかな。

　アマチュア無線でも1fscや2fscに割当があるので、周波数固定のトランシーバでテレビの水晶が流用されていたらしい。特にQRPでよく使われるんだとか。もっとも、3.5MHzや7MHzが割り当てられたのは1920年代で、NTSCカラーシステムが制定された1950年代よりも前なので、NTSC用の水晶が流用できたのは偶然によるものなんだろうけど。

***

　そういえば、NTSCをキャプチャするUSBのヤツ、大昔に買ったよなーと思って、部屋の隅の方を漁ったら出てきた。ドライバはWin7あたりまで提供されてるので、Win10でも使える。付属のソフトだと映像が出てこなくて、アマレコTV入れてみたらちゃんとキャプチャできた。

　異様に画質悪くて設定変えても変わらなかったんだけど、USBポート変えたらめちゃくちゃ綺麗に映るようになった(綺麗と言っても480iなのでしれてるけど)。USBってデジタルデータだけど、結構アナログなんだなー。たぶんハブの電源周りとかの問題だと思うんだけど。

　STM32G4のDACが15MHz通るので、4fscの約14.3Mspsで波形データ投げれば、ワンチップでNTSC映像が出せる。さすがにRAM容量が少ないのでフレームバッファは256x242pxくらいが限界で、ファミリーコンピュータ相当の表現度しかないけど、色情報は結構自由に作れる。最低でもファミコンと同程度の表現力はある。もっとも、映像エンコード方式がファミコンと全く違うので完全に同じ色を再現するのはできないけど。

　しかし、今どきコンポジット映像信号用の低解像度なゲーム機とか作ってもなぁ。CPUもダウンクロックして走らせてるのであんまり余裕ないし、リアルタイムにファミコンのエミュレーションやるのとかも難しそうだし。G4はUSB HostついてないからUSBゲームコントローラみたいなのも接続できないし。いまいち良い使い方が思いつかない。せっかく気軽にNTSCを表示できるようになったのでなにか作ってみたいんだけど。

　アナログ入力に可変抵抗1個繋げばブロック崩しはできるか。いや、それくらいは1個300円の8bitマイコンでもできるんだが。。。カラー映像を活用するならテトリスあたりが良さそうだけど、快適に遊ぼうとするとスイッチ入力がかなり必要だからなぁ。アナログ入力1個で延々遊べるブロック崩しはすごい。

***

　久しぶりにスタートラッカ周りのソフトをチマチマ書いてる。

　SAOカタログ(冒頭のスミソンさんのフラグ回収!)、2020年に更新されてるんね。これどれくらい信用していいんだろう? Vmagの値結構でたらめというか、かなり精度悪い気がする。古いデータだからそれくらいは許容しなくちゃいけないか。あるいは比較相手の精度が悪いというのもありそうだけど。

　拡張子が.gzのクセして生のASCIIデータとか、いろいろふしぎ。

　最近のC#、普通に四元数とか2D/3Dベクトルとか(floatだけど)サクッと使えるしハードウェアアクセラレーションも効くんだけど、当然というか、CGI系の座標系なので、航空宇宙関係とは相性が悪い。まぁ、デフォルトのYawPitchRollを使わずに、脳内で座標変換してやればいい話なのだけど。

　前にペパクラ作ってたときにOrientation Cubeのヤツ、右手座標・左手座標のXYZとかも含めて一通り作ってあったので、それが大活躍してる。やっぱり手で持ってぐるぐる回せる座標があると捗る。

　最近、リモートワーク関係なのか、単にムーアの法則なのか、HDMIキャプチャデバイスが安いやつは異様に安くなってきてるので、ミラーレスのカメラで夜空を撮影したやつを直接PCに取り込んでいろいろな情報をオーバーレイできたら楽しそうだな、と思ってる次第。

　特定の衛星を撮影したいときとかに、恒星の情報からパスを表示できたら便利なので。まぁ、ISSくらいの低軌道が相手だと空が暗くなる前に来るので使えないのだが。静止衛星みたいな、移動が遅くて深夜でも観測できて、かつ肉眼では見えないような衛星を撮りたいときに、そういうツールがあれば便利だよな、と。

　7月13日頃にQZS-1とETS-8が見かけ上かなり接近するので、それを撮りたいなと思っている次第。なのであと1ヶ月で作らないと。気力ゲージ足りるかな?

　元期+70daysくらいだけど、今の所の予測としては、ETS-8とQZSの接近は

* 7月10日4時頃、QZS-4

* 7月10日22時頃、QZS-2

* 7月13日2時半頃、QZS-1

* 7月14日21時頃、QZS-3

　(すべてJST)という感じ。QZS-4の朝4時はすでに明るいので光学撮影はむりぽ。

　いずれにしろ、QZSは結構すばやく赤道を横切るから、接近しているのはかなり狭いウインドウになる。SNRが悪いので、天気も重要。それと、QZS-1に比べて以降の号機はSAPが短くなっているので、撮影条件としても厳しい。通信衛星みたいに大きなSAPがあれば撮影しやすいけど、ひまわり8/9みたいな小さいSAPだと多分写らない。QZSは微妙なところ。大きなお皿もないので、通信衛星に比べて測位衛星や観測衛星は厳しい。

　QZS-3って、準天頂軌道の真ん中じゃなくて、結構外れたところにいるんだよね。東南アジア全体をサービスエリアにできるように西側に振ってるのかな。DOP下げるなら東西に振るしかないし、東は海ばっかりだから西に振ってるんだろうけど。6号機は更に西に置くらしいし。東経90度とか北海道からだと仰角20度くらいにしかならない(JDRS-1もこのあたりに置いてある)。

　とりあえず初期姿勢ありで静止画1枚の慣性空間での座標の解析は動くようになったので、もうちょっとゴリゴリ。リアルタイムに動画の解析をやるとなると、コマ落ちしても問題ないとはいえ、そもそもHDMIのキャプチャも課題。キャプチャデバイス買わないといけないのと、OpenCVとか使わなきゃいけないのと、その他。

　テザー撮影できる機材とかは手持ちにないので、HDMIキャプチャとか使わないのであればいい方法を考えねば。1枚撮るごとにSDカード外して転送するのはめんどくせーぞ(経験者は語る)。

　そういえば、ミラーレスの方ってテザー撮影が使えたような…? あとで調べておこうっと。最近ネット回線マジで遅い。。。YouTubeのFHDとかはそれなりのストレスを許容すれば再生できるので、小さいパケットが通ってないんだろうけども。普通のWebページ見たりするような小さい転送が頻発するような使い方だとストレスフル。