コダックが1990年代前半に作ったハイスピードカメラの話。
https://www.jstage.jst.go.jp/article/oubutsu/89/2/89_68/_pdf
2020年。固体撮像素子の歴史から最新の技術までいろいろな解説。CMOSイメージセンサの歴史は半導体プロセスの歴史にも近いので、半導体技術の説明が主な感じ。/* 終盤の偏光の説明、0, 90, 180, 270ではなく、0, 45, 90, 135だと思うのだが */
Amazon.co.jp: 知能侵蝕 1 (ハヤカワ文庫JA) 電子書籍: 林 譲治: Kindleストア
試しに1巻だけ読んでみた(2巻刊行済み、3巻を7月に発売)。
僕が好きな作風とはちょっとベクトルが違うかな。『三体』みたいな雰囲気。
1巻では設定の説明ばっかりな感じ。三体では1巻でもある程度は相手の宇宙人の話が出てくるけど、知能侵蝕では相手に関する話がほとんど進展しない。時代設定は10年後くらいだけど、一時が万事AIに依存しているような世界観。民間に限らず、自衛隊も指揮系統の上から現場の状況認識まで全部AI任せ。少子化で人間が少なくなるからAIに任せるという設定はしょうがないとしても、どのページを見てもAIばっかりで胸焼けしそう。
現実世界から出発して設定を練ったSFが好きな人には良さそうだけど、僕が読みたい内容ではない。
https://www.nict.go.jp/publication/shuppan/kihou-journal/houkoku65-2_HTML/2019S-05-03(04-03).pdf
NICTのSDRを使用した時刻比較の例。GPS信号と独自の2周波PRNを使った方式の2種類。
「測位用GPSは時刻比較には使えない」「時刻比較用GPSは高価」という理由でSDRを使っているわけだけど、信号の取得には専用のアナログフロントエンド+VLBI K5用のADCを使っているあたり、汎用的に(NICT以外でも)使おうってものでもなさそう。
K5用のADCって市販してるのかな? NICTのドメインにそれっぽい製品の取扱説明書(PDF)が置いてあるけど、メーカー名と型番でググっても出てこない。メーカーの製品ページにもそれらしいものは無い(汎用的な製品は数個しかなくて、受託開発みたいなのがメインの会社っぽい)。K5受信機が市販されているならアナログフロントエンドも販売して高精度なタイミング同期用の製品としてソフトウェアも合わせて売ればいいだろうけど、NICT(or 関係メーカー)がこういう製品を売る気はあるんだろうか? 「市販品は高すぎて普及しない」と言いつつ、専用ハードウェアを自分たちで作って独占しているのであれば、結局それが普及を妨げる行為になっているのでは(そもそもGPSのPPS以上に精度が必要な時刻比較の行為自体に需要があるかという話ではあるけど)。
計算量が多いからGPU(CUDA)で、ってのはわかるんだけど、使ってるカードがちょっと謎い。このPDF自体は2019年のものだけど、使ってるカードはGTX 470。が、資料中のグラフに書かれた日付(MJDから換算)は2010年4月16日で、GTX 470の発売日('10年4月12日)からわずか4日しか経っていない。SDRだからサンプリングした日と解析した日(GPUを使用した日)にある程度差があるとしても、さすがに近すぎるような気がする。日本の研究機関が発売直後の民生パソコン用の部品なんてポンと買うものかな?
あと、なんで10年近くも前の実験を今更記事にしてるんだろう、という違和感。それ以降に実験を行っていればグラフとかもそれに応じた内容になっているはずなんだけどな。やってないのかな。
それと、DPNを使った周波数比較では商用の通信衛星を使うこともできるけど、この資料中では準天頂衛星を使っているとも書かれている。周回衛星ではなく静止衛星を使うことでドップラーシフトの影響を除く、みたいなことが書いてあるから、QZS-3を使ったんだと思うんだけど、QZS-3ってベントパイプみたいな使い方もできるのかな? QZS-3の通信用ペイロードは帯域幅があまり広くないはずだから時刻比較用に使うのは厳しそうな気がする。もしかしたらQZSの測位信号(GPSの代わり)と商用衛星のDPNを比較に使った、くらいの感じかもしれないけど。
地デジのいくつかのチャンネルの利得がかなり低くて、ブロックノイズが多発するようになった(多発というほどテレビも見てないけど)。感度の低いチャンネルに選択性があって、いくつかのチャンネルはテレビの受信感度表示がサチるくらい強いし、いくつかのチャンネルはブロックノイズが入る。
アンテナの取り付けが悪くて向きが正しくない感じだったので、前に衛星アンテナを捨てるというんでもらってきたブラケットを使って向きを調整。いい感じに受信感度が高くなった。当初の向きとはかなりズレてた。元々はあまりしっかり固定してなかったので、少しずつずれてきたんだと思う。周波数選択性は平面型アンテナだからかノッチがあるのかな?
ベランダに地デジとBS/110度CSのアンテナがあって、屋外のアクティブ混合器で増幅/混合した上で屋内に引き込んで、テレビの近くで分波、という感じの構成。で、この混合器、地デジはボリュームを「利得最大」に回すと利得が最大になるんだけど、BS/CSは「利得最小」に回すと利得が最大になる。謎い。ちゃんとした日本メーカーの製品なんだけどねぇ。
***
日食の撮影中に映り込んだ謎の物体の話。「衛星っぽいけど調べてもよくわからなかった。興味ある人は調べてみてね」(意訳)だそう。
何年か前に作った衛星撮影の計画立案ソフトで、すべての衛星のTLEを計算して画角内に入るかどうかを確認するツールがあるので、それで確認してみた。
ただし動画を撮影したカメラの焦点距離は1100mm(35mm)程度と思われるが、上の図では100mm(FoV 20x14度)として画角を計算している。
上の図で中央に表示された黒背景の画面が画角内の衛星の表示で、この場合は24秒間に衛星が動く範囲を線でプロットしている。画角は静止軌道に近いため、運動量の低い衛星が数多く存在する(1000mm程度の画角であればほとんど画角の外になる)。
4月8日前後(4月1日から5月8日まで)に公開されたTLEはデブリ等も含めて全部で26191個の衛星が存在しているが、結論から言えば、公開されたTLEの中で、2個の衛星が数秒以内にほぼ平行で0.5度程度の間隔で飛ぶ物体は存在しない。
ある程度時間方向の範囲を広げて、14分程度の間に通過する衛星を含めても、それらしいものはない。並行する軌道はあっても、時刻が大きく違ったり、向きが逆だったり。
動画に映り込んだ物体が衛星だった場合、作為的または無作為に、SpaceTrackでは非公開な衛星の可能性がある。
作為的に非公開というのは例えば軍事衛星が考えられる。例えばSIGINT衛星であれば電波信号を干渉させて発信源の位置を絞り込むためにコンスタレーションを組んでいると考えられる。その場合、近い距離を短時間で通過する事に矛盾はない。(SIGINT衛星であればある程度の面積の開口を使うはずだから、輝度も高いはず)
例えばNOSS衛星は並行して飛ぶという条件に一致した写真が撮影されている(NOSS衛星もTLEが公開されていない)。この写真はシャッタースピード10秒で平行部の重なりが半分未満だから、動画中の6秒間隔で通過することとも矛盾しない。
無作為に非公開というのは例えば相乗りで多くの衛星が同時に打上げられた場合、放出直後(各衛星間の距離が近い場合)はレーダで各々を分解できないために、TLEの公開までにある程度の日数を要することがある。この場合も近距離かつ短時間で平行に通過するのに矛盾はない。ただし多くの衛星を一度に打上げる場合は1つあたりの衛星は小さいことが考えられるから、ベイリービーズとはいえ輝度の高い太陽光に合わせた感度設定のカメラに映るかという問題がある(50kg程度の衛星であれば条件が良ければ地上から撮影可能だが、この場合は背景に星が写り込む。件の映像では星は見えないから、かなり感度を低く設定しているはずで、衛星だとするとかなり大きな反射面積が必要になる)。
ただ、この結論は、数年前に遊びで作った自作のソフトが正しく動作している、という前提によるので、ちゃんとした解析ソフトで調べれば別の結果になるかもしれない(一応、ある程度許容できる誤差の範囲で正しく動いていたと記憶しているのだが)。
***
Chromeの履歴で適当な日数(5日)分開いてCtrl-Aで選択すると2000件くらい。1日400ページくらい開いてるのか。意外と多いような、そうでもないような。PCを1日12時間使っていると仮定すると、100秒に1ページくらい。まあ、そんなものか。
基本的にWebサイトを開く際は状況にかかわらずほとんど全部新しいタブで開くし、開いたタブは1枚1枚閉じていくことになるから、マウスに割り当てたctrl-wのボタンも1日400回程度押していることになる。実際には新規タブではないページ遷移とか、あるいは中ボタンでタブを閉じることもあるので、ctrl-wボタンはもう少し少ないはず。これを1年くらい継続すれば10万回くらい押してることになるのか。そう考えれば普通のスイッチとしての寿命はある程度末期に来てると考えられるか。ゲーミングマウス基準だとまだ1%程度な気もするけどな。とはいえ左右クリックとサイドボタンでは寿命要求も違うだろうし。左クリックは作業ゲーとかだと連続してカチカチすることもあるだろうけど、サイドボタンはそう頻繁には操作しないだろうし。とはいえMMORPGとかでも操作によっては頻繁に押すこともあるだろうから、もう少し持ってほしいけど。まあ、MMORPGを1年間毎日12時間も遊ぶ人はそういないか…… それくらいやり込んでる人ならマウスだって消耗品だろうしな。
試しにRazerのマウスのサイドパネルを分解
6ボタン(1回も使ったことない)で内部構造をある程度把握したので、12ボタン(メインで使っているやつ)を分解。一番外側のネジの配置とかは同じだけど、中身は全く違うのな。6ボタンの方はスイッチの樹脂部品がかなり複雑。金型作るの大変そう(小並感
6ボタンの方はタクタイルスイッチとダイオードが乗っているだけ。LEDは無し。
12ボタンの方はタクタイルとLEDが実装されていて、裏面に細々した部品が乗っている。LED付きなので表面のレジストは白。LEDはアノードコモンのRGBタイプ。
12ボタンの表側の拡大
特に面白いところはない。LEDのパターンが6箇所あるけど、実装されているのは4個だけ。まあ、この配置で6個置いたら色ムラがね。。。
裏面
6ボタンはパッドが出ているだけのシンプルなもの。GNDのビアが大量に開いている程度。パッドは3枚がGNDに接続、4個からパターンが出ている。
12ボタンは抵抗・キャパシタ・ダイオードが大量。ダイオードはスイッチ1個にダイオードが1個の割当。典型的なマトリクス配置のスイッチと言う感じか。抵抗はLED1色に1個で、全部で12個乗っている(未実装のLED分の6個の抵抗も未実装)。パッドは3枚がGNDだけど、6ボタンとは組み合わせが違う。装着されたパネルの検知はこの組み合わせで行っているのかな? GND+ID(3箇所)として7種類、GND(2箇所)+ID(2箇所)として3種類、を判定できる。GND以外では12箇所のパッドからパターンが出ている。スイッチは3x4のマトリクスで、これに7本、LEDが3本+アノードで合わせて4本、計11本になる。残りの1本の用途がわからないな。あと、キャパシタが(しかも大きさ違いで2個)乗っているのも謎い。マイコンでも乗ってるのかって感じ。
とりあえずサイドパネルの構造はわかった。封止シールを破れば簡単に分解できるし、組み立ても問題なし。ただ、12ボタンはスイッチが密集しているから、1個だけスイッチを取り出すのが大変そう。スイッチさえ剥がせれば簡単に修理できそうだが、これが鬼門。
タクタイルスイッチは秋月でも売ってる表面実装のやつと寸法は同じかな。入手性は良さそう。操作性は多少違うだろうけど、まずは6ボタンとか2ボタンのパネルを生贄に使って共食いさせればいい。
スイッチの剥がし方を考えないとな。4箇所を同時に加熱する方法か…… ある程度厚さのある銅板を曲げて容量の大きい半田ごてで温めるとか? アルミチャンネルを必要な長さに切って潰すほうが楽かな。まあ、またそのうち。もうちょっと悪化したら否が応でもやらなきゃだし。
なんか、最近はタクタイルスイッチの修理ばっかりやってる気がするなぁ。。。世が世ならタクタイルスイッチの寿命改善を願って魔女になった魔法少女とかいるだろうなぁ。
***
試しに地図タイルの分解能と縦横の歪みを計算
青と橙がタイル1枚を256x256としたときの1ピクセルの分解能(左軸)、緑が東西と南北の比(右軸)。低緯度では南北のほうが分解能が若干高い。とはいえ0.6%程度の違いだけど。そもそも地図タイルとか、座標変換(地図タイル→ECEF)が正しく実装できているかもわからんからな。
***
Math.NetのFourier.Forwardと自作のFFTの計算時間の比較
1024ptsのFFTを約10万回実行して、処理時間でソートしてグラフ化。縦軸が処理時間(ミリ秒)。Math.Netはシングルスレッド、10スレッド、32スレッドで、自作FFTはシングルスレッドと32スレッドで比較(Parallel.For(0, n, _ => { /* ... */ });でスレッドを作って計測)。
テストデータは毎回Random.NextSingleで作るとめちゃくちゃ遅いので、FFTを計測→IFFTで戻す→FFTを計測→IFFTで戻す、を繰り返している(一番最初のデータはスレッドごとにRandom.NextSingleで作成し、RandomのシードはGuid.NewGuid().GetHash()で作成)。
Math.Netはシングルスレッドでは自作FFTと同じ程度の速度が出ているが、マルチスレッドではシングルスレッド(or自作FFT)より1桁程度遅くなる。自作FFTは内部ではスレッド的な処理は行っていないので、シングルスレッドでもマルチスレッドでもほぼ同じ速度になる(OS側とかハード側の負荷で1割程度の差はある)。
ちなみに、上記のグラフはDebugビルドだけど、Releaseビルドだとこんな感じ
Math.Net遅すぎワロス。自作FFTより1-2桁遅いじゃねーか。ただ、自作FFTのワースト10%程度が1桁程度遅いのが気になる(実際のところはワースト10％程度がDebugビルドと同程度で、大半がDebugビルドより1桁早い)。
DebugビルドとReleaseビルドで使うMath.Netは同じモジュールなのかな? ほとんど差がない。とりあえず計測手法の再現性はありそう。
試しに100万回回したら1桁遅くなるワーストは2%くらいまで減った。逆に1万回回すと全部0.1ms程度まで遅くなる。最初の1万回くらいは遅くて、以降は1桁早くなる、みたいな挙動かな。よくわからん。最初の1万回程度は遅いとはいえ、それでもMath.Netよりは1桁早いしな。
Debug/ReleaseやMath.Net/自作FFTにかかわらず、処理速度はほとんど一定だけど、ワースト1%未満程度はパフォーマンスが極端に低下しているのが謎い。
Math.NetのFourier.Forwardは並列で使うとだいぶパフォーマンスが落ちそう。例えばISDB-TのリアルタイムQLはスペクトルの表示とOFDM復調で合わせて少なくとも6スレッドが走る。ISDB-Tは900Hzくらいで処理しなきゃいけないので、Math.Netはちょっと厳しい気がする。自作FFTならマルチスレッドの2kptsが数百kHzで通るから、ISDB-Tの復調でも安心。
Math.NetのFFTがクッソ遅いのが謎いんだよなー。Releaseビルドで素人が書いた最適化していないコードより2桁遅いってどういうこと。。。自作FFTは2^n(n<17)まで(定数1箇所で調整可能)しか対応していないし、Math.NetのFFTは2^n以外にも対応しているので、機能の違いがあるとはいえ。
今回の計測はあくまでも大量に回したとき(数万回オーダー)の特性なので、数十回程度ならMath.Netでも十分に早いと思う。おそらく内部のメモリ割り当て(に起因するGC周り)でパフォーマンスが落ちてるんだと思う。このあたりはちゃんと確認してないので推測だけど。
***
RTL-SDRドングル(v3)でBias Teeを使おうと思って、まず動作確認のためにLEDを……と思って接続したらいきなり点灯してびっくり。Bias Tee OFFコマンドを打っても全くOFFにならず更に困惑。
結局、EEPROMの常時BT ONフラグがセットされていたのが原因と判明。rtl_eeprom.exeでフラグをOFFにして解決。しかし、いったいいつからONに設定されていたんだろう…… ずっとBias TeeをONで使ってたんだろうなぁ。。。最近はDIGAの出力端子に接続していた。まあ、最近のテレビならRFラインに15Vのバイアスくらいは想定しているだろうし、5Vくらい突っ込んでも問題ないはずなんだけど……
*
SDRドングルで2.56Mspsで1575.42MHzをサンプリング、PRN24が仰角84度だったのでレプリカを作って相関処理
2.56Mspsなので2560ptsで1msになる。なんか1ms毎にピーク出てるな??
レプリカの生成が正しいかもわからないし、ドップラーシフトとか諸々で相関は絶対に出ないだろ、と思ってたのでいきなり出てきてびっくりだよ。
周波数を少しずらすと相関値が高くなる。周波数分解能から得られるドップラーシフトと軌道計算で得られるドップラーシフトには多少の差があるけど、受信機側のクロックエラーもあるし、妥当な結果かな。
各PRNで相関を取ってグラフ化
PRN1からPRN36まで。縦方向がドップラーシフト、横方向が遅延。
PRN毎に相関値のピークで輝度を正規化しているので、相関値が低い場合は全体的に赤っぽい色合いになるし、相関値が出れば背景は暗くなる。
PRN18, 23, 24あたりに相関が出ている。PRN5も弱いけど相関がある。
PRN23, 24の部分
PRN23は仰角60度弱で接近中、PRN24は仰角90度弱で接近中で、ドップラーシフトもそれに応じた位置に出ているように見える。
18は離隔中なので低く出る。
QZSSのC/Aコードのディレイも調べて、サクッと対応。L1 C/Aは互換なので相関するだけならいくつか値を追加するだけで対応できた。簡単。
PRN194(QZS-2), 195(4), 196(1R), 199(3)で相関が出ている。この時間は1Rがほぼ直上だったけど、相関値はかなり低い。199はGEO。194と195はオーストラリア上空で、仰角20度未満だった。/* L1 C/Aって西側のGNSSがデフォルトで出してる信号だと思ってたけど、GPSとQZSしか出してないんだな */
相関値の最大値の中央値と、最大値、その比をグラフ化
相関値のグラフはGPS受信機で見かけるような見た目だ。
中央値はドップラbin毎にmagnの最大値を拾ってきて、その中央値を取り出している。レプリカに相関が出るのは数bin程度なので、中央値であれば信号の有無にかかわらずある程度安定した強度が得られるはず。
中央値の3倍前後に閾値を設定して、最大値がそれを超えていればGNSS信号が存在している、みたいなロジックが作れそう。
レプリカを20コードの長さで作って相関処理
上下幅は100Hz、横幅は約1.6秒。C/Aの拡散(1.023Mcps)は相関処理で逆拡散されるから、航法メッセージ(50bps)のBPSKで拡散されているのが見えているんだと思う。今回はスキャン用のロジックを流用しているので周波数方向が見えているけど、トラッキング(BPSK受信)だけなら周波数方向にスキャンする必要はない。
相関値のピーク(1kHz)の強度と位相のグラフ
強度が下がるのはビットが切り替わった場所で、その場所で位相が180度変わっているような雰囲気。かなり強い周波数オフセットがあるけど、おそらくドップラーシフトを周波数空間で相関するときに単純にインデックスの差で吸収している分だと思う。
レプリカとの相関の前にIQデータをNCOで回転
位相の回転が止まった。この方法だとIQとレプリカの(周波数空間での)積でずらすのが不要だから、FFT/IFFTで周波数間引き/時間間引きをする際にビット逆順に並べ直す必要がなくなる。
レプリカを1コード(1ms)の長さにして相関処理
相関処理で統計処理ができないのが欠点、ビット反転が複素平面で綺麗に出るのが利点。レプリカが長い(例えば20ms)場合、ビット反転部分で相関値が極端に低くなってしまうから、トラッキングが難しそうな気がする。
計算コスト的には、逆拡散の畳み込み演算はFFTで行うから、レプリカが長かろうが短かろうが関係ない(相関処理できる長さはFFT長さ-レプリカ長だから、FFT窓が狭い場合は計算コストに効いてくる)。
方針を変えて、あらかじめビット01(20コードのチップを位相反転して2組)で相関処理を行って、ビット反転の位置を推定したうえで、ビットの中央部でサンプリングして、位相をグラフ化
330ビット程度を表示していて、6.5秒くらいの範囲。周波数がものすごいずれるな。仰角が高い場所の衛星なのでドップラーシフトの変動もある程度はあるだろうけど、こんなに大きく出てくるのか。ビットを復元する前にまずドップラーシフトの吸収を実装しないとな。
そもそも、今はC/Aコードの畳み込みにFFTを使っているけど、入力をNCOでドップラーシフト(&受信機クロックエラー)を吸収して、しかも事前にビットに同期しているわけだから、FFT畳み込みが必要かどうかも怪しい気がする。単純に1msずつ逆拡散して位相を見てNCOにフィードバック、ビットの中央の位相を取り出してビットを復元、みたいな処理でいい気がする。
ソフト実装のGPS受信機がFFTで畳み込んでいる例を見ると、時間軸で逆拡散するのはなにかデメリットがあるんだろうけども。
0 件のコメント:
コメントを投稿