小ネタ

　XRISMのマイクロカロリメータを製造したのはNASA GSFC。

　GSFCとスミソニアン博物館ってかなり近いんだな。スミソニアン天体物理観測所の初代館長も努めたラングレー氏が活動していたのがこのあたりのはずだけど、ラングレー氏はボロメータの開発も行っていた。ボロメータを小型化したのがマイクロカロリメータで、ほとんど同じ場所で150年近くも開発が続けられてるんだな。/* 映画とかでよくCIA施設として出てくる「ラングレー」もスミソニアン博物館からほど近い場所だけど、ラングレー氏とは無関係のはず */

　PCの表示領域が狭く感じるようになってきて、4K液晶1枚追加したいなと思っている今日このごろ。メインに23.8"4Kを置いてサブに23"FHDを置いているので、このFHDを4Kに変えたい。ただ、24"くらいの4Kってほとんど選択肢が無い。メインで使っている液晶と同じ機種を中古市場で買おうかな、とかも思ったり。

　ドローンのローターで、プロペラのパラメータをちょっと広めに取った製品ってないのかな? 例えば先端部分を切削して個体ごとにkgf/rpmを少しずらすとか。1機のドローンで複数枚(大型のドローンだと8枚とか)のプロペラを使う場合に、それぞれのプロペラで同一の推力を生むのに必要な回転数が異なるから、可聴域のスペクトルを分散させることができるので、静音化ができそう。あるいは、切削加工を行うわけだから、ダイナミックバランスや回転軸と推力軸のオフセットを軽減したプロペラも作れる。機械振動が減って良さそう。

　とはいえ、大型のドローンだとモーターを背中合わせに2個積んでペラを同軸に2枚みたいな形になるから、それだと制御で回転数を分散させられるんだよな。上のモーターは早めに回して下のモーターは遅めに回して1組で発生する推力は一定を維持して、各組毎にずらし方を少しずつ変えて、みたいな感じで。そもそも必ずしも各推力点毎に推力をバランスする必要もないわけだし。とするとわざわざペラの特性を変えるまでもなく、可聴帯をスペクトル拡散できる。わざわざ切削してまで作るほどの利点はあんまりなさそう。

　小型の太陽電池、防災とかポータブルとかを重視したやつ、インフレータブルなリフレクタと組み合わせた製品ってどうだろう。アルミ蒸着シートみたいなやつで球面とか放物面を近似して光を集める。太陽電池の発電量は基本的に受光面積で決まるけど、ポータブルな用途だと大面積化が難しい。リフレクタで集光するなら格納状態ではかなり小さく作れる。

　太陽の向きに合わせて10分毎くらいに向きを調整しなきゃいけないのが使いづらいところ。あと、風とかの影響も受けやすい。それと、凹面鏡を作る必要があるので陽圧でなく負圧にしなきゃいけないので、何らかのフレームが必要になる(フレームを陽圧で作る手もあるけど)。

***

　1090MHz、モード3/A/C/Sあたりの復調

　1列目がタイムスタンプ(秒、ファイル先頭から)、2列目がパルス幅(マイクロ秒)。モード3/A/Cの場合は3列目にスコークを、4列目に高度(有効な値の場合)を表示している。モードSの場合はバイナリ値を表示している。

　24bitアドレスとかスコークが正しそうなのが見えていて、高度の値もほぼ同じ値が得られている。VSが0じゃないのと、Fr24とIQに多少の時刻差があるのと、モードCで送られてくる気圧は規正していない気圧なので、高度値は多少ずれた値が出ている。

　モード3/AはPRI20ms(PRF50Hz)くらいで何発かまとめて出てる。とりあえず頭の1秒程度をデコードしてみてるけど、モード3/A/Cは何回も安定して出ているので、空港のSSRが質問しているわけじゃなさそう(空港のインテロゲータはモードSだろうし)。

　ADS-B(パルス幅120usくらいでDF17)は時々出てくるけど、10秒に1個とかその程度でしか出てこないのがちょっと謎い。飛行中ってもっと高頻度に出してるはずなんだけど。

　時々、1090MHzにモードSのプリアンブルで88us前後のパルスが大量にあるんだけど、用途がわからない。

　モードCで送るギルハム(Gillham)コード、変形グレイコードで、スコーク3桁目(10の位)が0, 5, 7は高度として不正な値。あるいはD1も0固定(4桁目が偶数)。全体として、モード3/Aで送れる4096個のコードの中、モードCで送れるコードは(en.wikipediaの表に従うなら)1280個、送れないコードは2816個と、全体の7割近くはモードCで送れないコードになっている。スコークの割当でモードCで使えないコードを優先的に使うみたいな運用ってあるんだろうか? 普通のATC SSRで使う分には全く不要の気遣いだけど。

　ギルハムコードのエンコード、設計思想としてはおそらく機械式気圧高度計の1千ftの針と1万ftの針を機械式エンコーダで読み出したものだと思うんだけど、アネロイド式気圧計で10接点くらいの機械式エンコーダを回すって相当な負荷になりそうだけど、ちゃんと動くんだな。

　ギルハムコードは気圧未規正の値が送られてくるけど、計器パネルの気圧高度計は必要に応じて規正した高度値を表示するはずで、そのニードルを読み取るエンコーダも規正値を送るはずなんだけど、どういう処理になってるんだろうか。

　ja.wikipediaのトランスポンダの説明で「モード3/A」と「モード3/C」という分類があるけど、これって間違いじゃね? モード3とモードAは互換性があるから3/Aという表記になるけど、モード3とモードCは別物だから3/Cという表記はできないはず。en.wikipediaでもモードCがモード3の中に入っているような表記になってるけども。。。

　ATCトランスポンダ、東芝とか三菱電機が地上で使うやつ(インテロゲータ)を作っている話題は見かけるけど、オンボード用のやつ(トランスポンダ)の話題はほとんど(というか全く)見かけないのが不思議。日本でATCトランスポンダって作られてないんだろうか?

https://uavionix.com/downloads/IFF/IFF_Mode_5_Brochure.pdf

　トランスポンダのカタログ。無人機向けの50-100g程度のやつ。モード5まで対応。

　一部の製品で、ミリタリーユース用にモードAのX-bitの制御ができる、みたいな記述。用途は特に書いてないけど。

　モード3とモードAの違いがX-bitの使用の有無のはずなんだけど、ググってもほとんど情報が出てこない。

***

　rtl_tcp.exeのクライアントソフトを試作中。復調機能は無しで単純にクイックルックとIQの保存だけ。

　とりあえず同時に最大3chをサンプリングできるようにしてみた。チャンネルごとに共通の機能はユーザーコントロールで作ってあるから、必要に応じてコピペすれば増やすこともできる。

　サンプリングレートとか周波数は個別に設定できるようにしている。接続先(サーバーやポート)も個別に設定できる。サーバー側でドングルとポートの対応を固定すれば、クライアント側からドングルを指定できるから、例えばドングルAは広帯域の無指向性、ドングルBはVHFのワイドビーム、ドングルCはUHFのナロービーム、みたいな使い分けもできる。

　グラフは上段が信号レベルのヒストグラム、中段が瞬時のスペクトル(平均値を色で、最大値を白で、最小値を黒で表示)、下段がスペクトルの時系列。ウォーターフォールは約1px/0.1sくらいの速度だけど、サンプリングレートが違うと速度が多少変化する。

　左端が1Msps、中央が2.56Msps、左端が3.2Mspsでサンプリングしている。ゲインはインデックスで22,22,28、という感じ(このドングルは28が最大)。3.2Mspsは感度がかなり悪い。デシメーションでの処理利得が少ないからかな。

　PCの負荷が高い時(特に描画周り)に送信バッファが埋まってる感じのエラーログが出ることがあるけど、大抵は3.2Mspsでも問題なく受信できる。全体の受信処理はGUIからasyncメソッドを呼んでその中でTCPから読んでいて、そのループの中でグラフの描画も行っているから、Windows側の描画負荷が高くなるとC#の描画も止まって、受信処理も止まる。このあたりは要改善。

　あとは周波数の設定ファイルとかに対応したいな。ドングル単体だったり複数個の組み合わせだったり。

　試しに周波数とかサンプリングレートを同じにして受信したIQファイルを相互相関させてみたんだけど、全くフラットで何もピークが出てこない。もう少しなにか見えても良さそうなのになぁ。インコヒーレントって本当にインコヒーレントなんだな。とはいえ、ドングル間のクロックエラーが5ppmくらいあったとしても数十秒の1秒くらいの長さではコヒーレントなはずなんだけど。

　試しに地デジ28ch(NHK G)の上端付近(566.1MHz)を2.048Mspsでサンプリング

　短いモノポールなのであんまり強度は高くないけど。橙が明らかに周波数がズレてるな。

　上端付近(無変調キャリア周辺)を拡大

　青と緑も結構ずれてる。2.4kHzくらいずれてるかな? 2.4k/566.1M=4.3ppmくらいか。データシート曰くTCXOの初期オフセットが最大2ppmだから、経年劣化も含めれば5ppm弱ずれてても不思議ではないか。橙はだいぶ前に買ったものなので、ロット差とか経年劣化で更にズレが大きい。

　2Mspsで2kHzのズレだと2Mpts(1秒)で2000回転、1kptsで1回転。片方は256ptsくらいで相互相関すればコヒーレントかな。

　ということで、片方を2^21pts(2.1Mpts)、相手を256ptsで相互相関(横軸ミリ秒、512ミリ秒以降は負の時間の折り返し)

　14msあたりに強いピークが出てるな。

　横軸が時間、縦軸がクロックエラーで相関値を画像化

　結構きれいにピークが出る(輝度・縦軸は対数スケール)。ヒートマップで上の方にある直線はクロックエラーがゼロの行で、IQ信号のDCオフセットが見えている成分。

　FFTの長さが262kpts(2^18)でサンプリングレートが2.048Mspsなので、時間分解能は0.488us、積分時間は0.128s、周波数分解能は7.8Hz。周波数方向は±4096で±16kHzの範囲を処理して、その中で最大値を探している。

　周波数方向のスキャンはFFTのbinをずらしているけど、クロックエラーと周波数オフセットは本来は別のパラメータ。とはいえ、今回の場合は比帯域幅が狭い(0.36%)から、特に気にする必要はないはず。

　この計算にスレッドを10本並列で回して17秒くらいかかる。周波数方向は単に総当たりで探すだけなので、クロックエラーの推定値があるなら数十倍とか数百倍早く処理できる。FFT長は探索時間・周波数分解能・時間分解能に影響があるから、FFTを短くすると推定誤差が増える。ただ、500MHzに対して7.8Hzは0.0156ppm程度だから、受信機の性能(調整分解能1ppm)より明らかに過剰なので、FFT窓はもっと短くてもいい。FFT窓は主に時間軸のズレが問題になる。ただしFFT窓が長いほうがSNRを稼げる。

　とりあえず、特定のドングルを基準にして、同じ周波数とサンプリングレートで取得した波形を相関処理して、ドングル間のクロックエラーとタイミングエラーを推定できるのは動きそうな気配。計算コストは高いけど、そう頻繁に行う処理でもないし。

　なんかVLBIの信号処理じみてきたな。このドングルは何箇所かはんだ付けすれば複数の受信機でコヒーレントに受信できるので、電波干渉計も作れるわけだが。適当に運動量があって、それなりに帯域幅が広くて強度の強い電波源か…… そんなに都合の良いものがあるかな。。。

　ちなみに、FMラジオを1Mspsで相関するとこんな感じ

　何も見えない。256kspsでも似たような結果。シングルキャリアは相互相関を取るには使えなさそう。

*

　C#のユーザーコントロールで(int?, double?)みたいなプロパティを作ると、デザイナが変な初期化コードを書いてビルドエラーになる? 自動生成コードを手動で書き換えてやれば一応ビルドは通るけど、気持ち悪いし、次に自動生成が走ったらまたエラーになるコードが生成される。

　タプルとかレコードが駄目なのかな? タプルだと型の判定がミスって、レコードだとプロパティにそれぞれ初期値を入れようとしてinitに値をいれるからコンパイルエラーになる。

　タプルのプロパティを自分で{ get; set; }に上書きしてやれば、一応コンパイルは通るようになる。クラスで等価判定とか色々自分で書くよりは、レコードを上書きするほうが楽かな。

　ユーザーコントロールの仕様をゴリゴリ変えながらフォーム側も同時並行で作っているからか、デザイナー周りに変な挙動が出て困惑してる。イベントハンドラの登録が、VSのGUIで登録したものと、そこから生成されたコードで登録している先が違うとか。