小ネタ

　Wikipediaの干渉法のページに入ってる「サニャック効果による加速度計」の図、これ加速度計じゃなくて角速度計じゃね? エーテルの時代だと加速度計として考案されたんかな?

***

　レーザードップラ流速計、おおよその動作原理はなんとなく把握したつもりなんだけど、ドップラ効果を使うというのが腑に落ちない。

　コヒーレント光を使って空間的に周期的な強度の目盛りを描いて、粒子がその目盛り上を通過する最の散乱光を時間軸で計測してフーリエ変換すると、目盛りの周期と強度の周波数から速度を求める、みたいな原理だと思うんだけど、散乱光の強度振動はあくまでも空間の目盛りの強度分布に従うので、ドップラ効果とは関係ないはず。

　とはいえ、いくつかの動作原理を読んでも全部ドップラ効果で説明してるし、名前にもなってるんだから、ドップラ効果を使ってるのは間違いないんだろうけど。

　合成開口レーダーもドップラで説明していたりするし、相対速度と周波数の関係以外にも、移動と波を使うやつは大部分がドップラに含まれるのかもしれない。

　ドップラ効果の話題を流してたら、カッシーニ探査機・ホイヘンスプローブの話が出てきた。

　Titan Calling - IEEE Spectrum

　ドップラシフトのトラッキングのプログラムが、BPSK信号(8192bps)を考慮せずに設計されたために正常にトラッキングが行えず、設計会社はJPLを競合他社として認識していたために設計資料が開示されず、予算節約のために一部のテストが省略されて、この欠陥が見逃されていたらしい。

　あとになって完全なテストが行われていないことが気がかりになった技術者が、カッシーニに結合された状態ではホイヘンスから電波を出せない(出せてもドップラを模擬できない)ので、地球局からドップラや利得変化(プローブの姿勢変化の成分)を与えた電波を送って、それをデコードさせて、正しく受信できているかを試験したそうだ。電波を送るだけなら(他の技術者が要求する試験に割り込むことができれば)大してコストは掛からないから許可された、とのこと。

　結局、危惧したとおり、正常に通信できないことが発覚し、ドップラシフトの対応はソフトウェアで可能なのだが、オンボードで書き換える方法がなかったので、ドップラシフトが発生しないようにカッシーニの軌道計画を変更して対応したらしい。

***

　ミラーレス、フランジバックが短いので、アダプタを噛ませれば他のマウントのレンズが流用できる。ということで、アダプタをポチってみた。機械的なアダプタなのでF値や焦点距離(電気的な情報)はカメラからは見えなくなる。

　レンズの絞りは機械的な構造で調整するんだけど、電源OFF時に集光するのを嫌ってか、スプリングでノーマルクローズな構造になってる。機械的な可動範囲はレンズの開放絞りに制限されるので、メカニカルな部品で開放に引っ張ることができない。ということで、アダプタを噛ませると最小絞りになるので、星の撮影には厳しい。絞りのレバーの横にいい感じの突起があるので、針金を引っ掛けて引っ張れば開放側に固定できるので、とりあえずはそれで逃げてる。アダプタ側でちょっと強めのバネで引っ張るみたいな構造があれば良さそうな気もするけど、細かい部品点数がかなり増えるのでコスト的に厳しいんだろうな。

　とりあえず撮影してマッチングテスト。アンタレス付近。

　60mm@35mm、F4、1sec、ISO6400、くらいで撮影。

　計算上の画角とちょっと合わないけど、とりあえずマッチングはできることを確認。ズームレンズなので焦点距離の正確な数値なんてわからないし、ピントリング回すだけでもズームされるし、そのあたりは割り切るしかない。中心に既知の恒星を狙って撮影してその向きを初期値に与えれば、マッチングはできなくても想定位置のマーカーは表示されるので、実際の位置と照らし合わせて細かく微調整していくしかない。

***

　試しに静止軌道付近を撮影してみたやつ。

　250mm@35mm、F4、30sec、ISO4000、くらいで撮影。

　なんとなくそれっぽいやつに名前を入れてみた。正しいのかはわからないが。CHINASAT、THAICOM、QZS、JCSAT。QZSの東にも3個ほど点があるけど、この場所はいくつかのシリーズが飛んでるのでどれがどれかわからない。

　他にも点が大量に写ってるけど、たぶん画素のノイズだと思う。

***

　試しにQZS-1とQZS-2の接近を撮ってみた。

　135mm@35mm、F4、30sec、ISO6400、くらいで撮影。

　右側のやつは他の(おそらくはSSOの)衛星だと思う。

　この場所で、シャッター30秒だと、だいたい0.1度移動する。星の移動は15deg/hourだから、15deg/hour * 30sec = 0.125degで、QZSの移動量とだいたい同じ。つまり、星の線より2割短くて、異なる向き(星は東西、QZSはおおよそ南北)に動いている線があれば、それがQZSということになる。

　んで、ものすごい拡大して心の目で眺めてみると、それっぽい線が見えるような気がしないでもない。

　星が東西に移動して、それに直交するのが南北。画像の上側が北、右側が西。上半分が先に撮った画像で、下半分が1分後くらいに撮ったやつ。この時はQZS-1が南西に移動、QZS-2が北西に移動している。線の移動は、右側が右上(北西)に、左側が右下(南西)に移動しているように見えるので、右がQZS-2、左がQZS-1、と考えても、それほど破綻はしてない気がする。ってことは、この薄い線は、本当にQZSなのか?

　少しあとに撮った画像。

　250mm@35mm、F4、30sec、ISO2500、くらいで撮影。

　場所的には予測通りの位置に、うすく南西向きの線が写り込んでるように見える。トリミング範囲外にQZS-2も写ってるはずなんだけど、わからなかった。都合よく考えれば、SAPの長さを反映して、QZS-1は写りやすく、QZS-2は写りづらい、というのは有り得そうな気はする。

「場所的には予想通りの位置」というのも気持ち悪い話で、というのも、「予想」というのは、自作の衛星軌道計算ライブラリ(手抜き)で推定した場所を、なんちゃって自作スタートラッカで求めた姿勢に、なんの補正もせずに書き込んでいるわけで、いろいろな誤差や考慮外の影響(章動とか)が入ってるはずで、なのに「誤差の範囲で一致」となると、ちょっと気持ち悪い。こんなに簡単に計算できてしまうものなのかなぁ。。。

　さすがにLEOは近い&角速度が大きいので誤差が大きいけど。

　もうちょっと使い勝手良くして、LEOもある程度精度良く推定できるようにしておきたいなぁ。ISSの待ち受け撮影とかやりたい。

***

　Winの夜間モードって、グラフィック周りの低い場所で行列演算やってるんだろうけど、その行列って自分で書き換えれないんだろうか? RGBからLumaを取ってRに渡してGとBは0にする、みたいな行列を与えたい。

　ググってもそれっぽい話は出てこないので、できないんだろうけども。

　TOUGHBOOKみたいな特殊用途向けのグラフィックドライバだとそういう機能もあるらしいんだけど、せっかくWinでも夜間モードとか実装されてるんだし、もうちょっと好きに書き換えられたらいいのに。

　まぁ、デフォルトの夜間モード機能でも、最大まで振ればほとんど真っ赤になるので、特に問題はないんだけどね。単に「そういう機能があったら使ってみたいな」ってだけ。

***

　瞳孔が開いてると、2時くらいから、明らかに木々と空の境界線が見えてくる。2時20分ぐらいだと少し離れた所の地面も見えてくる。北海道の朝は早い(物理)。

　とはいえ、北海道と沖縄でもせいぜい15度くらいしか違わないし、いうほど早くないんだけどな。それでも1時間位の差にはなるから、旅行とかで一気に北海道-沖縄間を移動すると、軽い時差ボケ程度にはなるんだろうけども。