小ネタ

　とっさに操縦桿を握った乗客、惨事を免れたのはテレビ番組のおかげ　イスラエル行き旅客機 - CNN.co.jp

　そのうち映像化されるんだろうな。家で過去作を見ているシーンから始まって……

　古めのB級映画で、操縦できなくなったパイロットに変わってゲーマーが旅客機を着陸させて、日本語版では「神様プレステ様！！」と叫ぶシーンがあるけど、あながちフィクションと笑うこともできなくなった。

　ある地方のテレビ局がYouTubeに上げてるニュースの切り抜き、解像度が1920x1300で結構違和感があるけど、レターボックスの上に放送日、下に放送局名と放送地域が書いてあって、わかりやすくていいな。他の局だと1920x1080で画面上に放送日を表示したりするパターンがあるけど、上下に広げれば文字がゴチャついたりしない。

　スマホだと縦画面なら上下に広げたほうが見やすいけど、PCや横画面のスマホだと横のほうが余裕があるけど、とはいえ横に広げて文字を足すと見づらそうだしな。やはり上下に広げて追記してくれる方がありがたいか。

　最近ノギス使ってなさすぎて、毎回使うたびに電池を交換している気がする。モノタロウのヤツ、LR44だから電池は安いけど、こうも何度も交換するとな…… しかし、数カ月に1回位の頻度でしか使わないんだし、ミツトヨなど買えるはずもなく。

　電池交換を繰り返しているせいか、電池カバーを押すと瞬断するような挙動も出ている。サムホイールを避けてスライダを動かそうとするとちょうど指が電池カバーにかかるから、スライドさせようとすると電源が抜けて、原点が消えるとか。結構不便。こういうところが安物の安物たる所以なんだろうな。

　ISDB-Tの復調は、Releaseビルドで1/2倍速くらい。つまり実時間の2倍程度の処理時間がかかる。パイプラインの効率化でもうちょっと稼いで、残りはViterbi側で吸収しなきゃいけないのだが、ビタビ復号はもうあまり効率化できるような場所が残っていない。純粋に差や和を取って分岐する処理を繰り返すから、攻めどころが少ないのよな。頑張ってSIMDで書けばあるいは。

　今のところ、フルセグ放送は1フレーム231msの間に2600パケット弱流れているわけだから、少なくとも1ブロックで最大2600スレッド程度まで分割できるわけで、たぶんGPUで実装すればそれなりにスループットは出るんだろう。あるいは、拘束長7ならノードが64個あるから、小さな差和を64分割することもできるし。膨大な分岐処理をGPUで高速に流せるかどうかは別として。

　SIMDでビタビ復号を実装する場合、ノード毎のハミング距離の計算を並列化する場合と、複数のパケットを並列処理(例えばAVX2の256bit幅で32bit整数演算を8並列化)する、2つの方向性がある。

　というあたりまで考えて、放置中。……続きはそのうちやる。。。

　ちょっと方針転換して、Airspy R2でGPSを受信するヤツを試作中。そういえば、R2買ったはいいけどGPS受信してなくね?ということで。L1 C/AだからR2の帯域幅を活用しているとは言い難いけど。ドプラスキャンで綺麗な(多少はガタガタとしても)三角形が出ると、さすがサンプリングレート高いだけあるな、という感じ。

　とりあえず、GPSを基準にして受信機のクロックエラーが見えるところが目標。受信機のクロックの特性が把握できれば、それを基準にして地デジ側の割り当ても理解できるはずだし。

　一応、キャリア・コードにロックするところまでは実装。ただ、特定のPRNでキャリア位相が飛ぶ謎の挙動が出ている。別のPRNでは別の場所で飛んだり、あるいは問題なかったり。こういう挙動だと受信機(IQファイル以前)の問題ではなく、十中八九NCO周りのフィードバックが問題だと思うんだけど、とはいえ処理速度度返しのシンプルなコードだし、そんな変な挙動はしないはずなんだけど。フィードバックループを廃してキャリア・コード共に完全なフリーランで5秒くらい走らせても位相が飛ぶから、いよいよNCOが怪しいんだけど、しかしなぁ。

　というあたりが、今週の進捗。

　思いつきで別の遊びもちょっとやっていたんだけど、なんか思った感じにならなかったので、割愛。

　C#のreadonlyとDisposeの相性が悪いのどうにかならんかなー。あと、nullableも。Disposeの中ではreadonlyとnullableを無視してnullで上書きできる、みたいなオプションが欲しい。変数宣言で適当な修飾子を与えて、それがついた変数はvoid Dispose() or void Dispose(bool)の中に限ってreadonlyや非null型を無視する、みたいな(nullableは警告だから消せるけど)。

　ただ、readonlyや非nullableは変数の中身が存在することを保証するための構文だから、それを無視してもいいのかとなると、また別の話なんだろうな。かといって、readonlyを外してnullable型として宣言すると色々めんどいし。その「色々めんどい」に対応しないと、Dispose後に使おうとしたときに面倒になるんだろうけど。

　とはいえ、Dispose後に呼んだら適切にはObjectDisposedExceptionを投げる必要があるけど、nullを入れた変数にアクセスしたらNullReferenceExceptionが飛ぶだけだし、デバッグが若干面倒とはいえ、結果としては例外が出るから同じじゃねって思ってしまうのだが。そういう思考が保守性の悪いコードを生んでるんだろうけど。

　Math.NETのFourier、いくつかの型の固定長配列しか受け取れないのが結構不便。せめてMemory<Complex32>だけでも使えれば色々と楽になるだろうに。

　ArrayPool<T>.Sharedは現状では2^nで取れるけど、逆に言えば2^n以外のFFT点数が必要な場合はArrayPoolで確保できないとか、あるいは2^nのFFTを使う場合でも、2^nで渡されるのは仕様として固定されているわけではないからこれに依存するのはどうなんだとか。

　あとは、段階的に窓の大きさを変えてFFT処理したい場合(最初は荒く1024ptsで処理して、それで目的の信号が見えればその付近を8192ptsで処理するとか)、いちいち配列を作り直さなきゃいけない。Memory<T>に対応していれば適当に切り出して与えればいい。

　ついでに言えば、Memory<T>だけでなくSpan<T>にも対応してくれるとありがたいが。上のレイヤがマルチスレッドで走っているからFFTもシングルスレッドで走ってほしい、みたいな。

　そもそもMath.NETの更新頻度がかなり低いというのもあるし、だいぶトリッキーなコードを使っているらしく、互換性を確保するとコードが面倒になる、というような理由でMemory<Complex>とかの対応は先送りしているらしい。

　.NET11でComplex<T>が増えることを考えると、Memory<Complex<T>>やSpan<Complex<T>>に対応したそこそこ早い(&安心して使える/汚染されない)FFTライブラリがあると便利なんだけど。

　あと、System.Numerics.Vector3<T>とかも欲しいなーという感もありつつ。現状のVectorNはfloat固定だから精度が必要な計算に使い難い。Vector2,3,4が<T>に対応すれば色々楽になる。