小ネタ

　東芝、家庭用初の半導体発振技術であたためる電子レンジ　加熱ムラ軽減 - 家電 Watch

　マグネトロンは周波数固定だから定在波の節で加熱不足が起こるけど、半導体なら周波数変調で節を移動できるから加熱ムラが減る、というような原理らしい。さすがにまだアクティブフェーズドアレイでピンポイントに加熱、とかじゃないか。使える範囲はISMで決まっているからどれくらい効くのかわからないけど、定在波を崩すだけならある程度の効果があるのかな?

　それにしてもEMIが大変そうだが。例えばBluetoothは妨害波の周波数を避けるような制御が入っていて、電子レンジを使うとその周波数を避けて通信したりするわけだけど、固体化電子レンジでISMを端から端まで使うようになると避ける先がない。WiFiだと最近では5GHz帯を使ったりもできるけど、2.4GHzしか対応していない安価な機器では厳しくなる。あるいは、SSPAを活かしてWiFiやBluetooth用にノッチを入れたり制御するのかもしれないけど。もしくは、ISM全体を使うわけではないのかもしれないし。

　AIの目を欺き、レーダーを遮る　米陸軍が新迷彩と炭素繊維の「雲」を研究開発（高橋浩祐） - エキスパート - Yahoo!ニュース

　もう一つの注目技術が、炭素繊維を使った「ミリ波遮蔽モジュール」だ。特殊なコーティングを施した数千本の炭素繊維を空中に放出し、雲のような幕を作る。従来の煙幕では防ぎにくいミリ波レーダーによる探知を妨げ、装甲部隊や指揮所などを隠すことを想定している。

　ミリ波が相手なら長さ数mmオーダーの炭素繊維の雲ということになるのかな。めちゃくちゃ健康に悪そうだ。人間だけでなく、車両等もエンジンに吸い込んだりベアリングに入ったりすると一気に劣化しそう。まあ、その辺のデータもまとめて取りたいんだろうしな。実用化するかはともかく、データは持っておけば役に立つだろうし。 /* あるいは、もしかしたらWestford Needlesみたいに細かい針状の炭素繊維を使うのではなく、長い炭素繊維の細線を空中に静電気で広げるみたいなものなのかもしれないが */

　AIが開発した迷彩で画像探知の精度を大幅に減らしたという研究もだいぶ怪しそうな気がするが。米軍が自分たちで開発した車両の綺麗な画像で学習した画像認識システムが、別の迷彩とは相性が悪かった、みたいなことじゃないのか?

　空対空ミサイルが使われた初期にフレアの性能が悪くて、自軍が使っているシーカーのスペクトルにはフレアが強烈に効くが、敵が使っているシーカーとはスペクトルが異なっていた、みたいな事があったはずだけど、AI時代にもそういう事はありそうだ。

　燃料集合体を「開閉」して原子炉の反応度を制御、新方式を発明：メカ設計ニュース - MONOist

　制御棒は緊急時に重力で落とすから、無重力環境(宇宙等)や動揺環境(海洋等)では使いづらい、ということで、重力によらない機構で制御する新方式。

　なんか、必要以上に複雑じゃねって気がするのと、ここまで複雑な構造にするなら従来方式でもいいんじゃないのって気が。従来方式に比べてどんな優位性があるんだろう?

　それと、重力で制御棒を落とすのは主にPWRのバックアップで使われている方式で、例えば日本で多く使われているBWRでは制御棒を下から押し上げるから、この系統であれば重力に依存しない(現行の炉は設計上ある程度の重力ベクトルを想定しているとしても)。

　提案方式は「アクチュエータ1個で制御できるから信頼性が高い」というのを目指しているような雰囲気だけど、とはいえ複雑な機構で相互に連動する構造だと、どこか1箇所が固着するだけで炉全体の制御ができなくなりそうな気がする。ドラムにしろ制御棒にしろ、複数の可動部があれば、1箇所が壊れてもほかで制御できる利点が大きそう(普通の商用原子炉は制御棒1本が固着しても(条件付きで)運転を継続できる。つまり2本目の固着までは安全に停止できる)。あと、複数の(2次元的に配置された)制御棒を使うのであれば、中心部と外周部で反応度を個別に制御することもできる。中性子が多い中心部は中性子の吸収率を高めに、みたいな。提案方式の場合は燃え残りの割合が制御量で決まるから、燃焼効率が悪そう(これはドラム式も同様だろうけど)。

　信頼性を要求するのであれば、もうちょっと時代が進むと加速器駆動型未臨界炉みたいに可動部を大きく減らしたような動力源が作れるのかな。しかし、核融合にしろ未臨界炉にしろ、止めたいときに止るモノって、動かし続けるためのエネルギーを突っ込まなきゃいけないから、効率があまり良くないのよな。地上の核融合発電だとスケールで吸収するけど、小型化要求の強い探査機はそれが難しい。海洋での使用はともかくとして、有人安全ほどの信頼性を要求されない探査機用の場合はそれを許容できるかどうか。通常の核分裂炉でも制御棒を押し込む圧力や重力に対してモータ等でエネルギーを常に与えて保持しているけど、核融合炉に比べればたかが知れてる。最大のエネルギー消費は冷却剤の輸送だろうけど、それはどの方式でも大きくは変わらんはず。

　現在開発中の炉でも小型のものでは固体化やパッシブで安定なものもあるけど、これらは基本的には内部の熱は対流で回して表面からは伝導や対流で逃がすから、重力と大気のある場所での使用が前提のはず。ある程度の強度はあるから水深数m程度で使う分にはあまり問題がないか、放熱性の改善で発電性能が改善したりするかもしれないけど、とはいえ海水に沈めたり揺れる場所や深い水深で使うことはできないはず。宇宙空間でも、内部の対流や外部の放熱が厳しいはず。やはり地上で何百個も使うような超小型炉と、海や宇宙で使うような炉は、かなり別個の設計になりそう。燃料集合体くらいのあたりは共通化できるかもしれないけど。

　UE5が出る前あたりのEpic Gamesは開発者指向というか、良さそうな雰囲気だったけど、最近の、特にAIが話題になって以降は段々トゲトゲしてきた感じがする。プラットフォーマーとして稼ぎたいという方向で開発者指向のスタンスから方針転換しつつ、とはいえ今のところは消費者に大きな利点もさして無く、AI時代に入るとバイブコーディングを全面に出して従来の開発者から嫌われて、というような感じがする。

　令和の心霊現象。暗闇に動物の目が光るからスマホで撮影したら、プレビューでは写ってるのに撮った写真には映らない(遠くの動物の目みたいな小さい輝点ピクセルはノイズ判定されて綺麗に消える)。

　星空モードとかも概ね似たような挙動なので、例えば人工衛星みたいな移動する輝点も消えるから、「スマホに映らないUFO」みたいなネタになる(気の利いたノイズリダクションが無い普通のカメラでは引っかき傷みたいに写る)。

　ただ、「常識で考えられないものが写った写真」は実際に写り込んでいるからそれなりの説得力があるけど、「有る物が写らない」は写真として残らないから、説得力に欠けるのよな。

　ひずみゲージで遊び中。具体的にはHX711を、特に複数ch読み出しに関して。単体でたいして動作確認せずに、いきなりSCK共有の複数ch接続ボードを作ってしまったので、あとから大変な目にあった。

　安価に売っているHX711ボードはGND, VCC, SCK, DOUTの4線インターフェースが多い。これを読み出す場合、DOUTの立ち下がりエッジから数ミリ秒(80Hzモード)あるいは数十ミリ秒(10Hzモード)以内に読み出す必要がある。HX711は読み出しの有無にかかわらず常に変換を行い、変換後にはデータレディパルスが出るから、読み出し中にデータレディが出るとデータが化ける(読み出している最中は新しいデータをシャドウレジスタに保管しておくみたいな気の利いた処理がない)。

　1chだけでいい場合は、十分に高い頻度で読み出すか、立ち下がりエッジを待つか、あるいは割り込みが必要。HXのサンプリングレートよりも低い間隔でエッジを待たずに読み出すと、確率的にデータが化ける。

　複数chの読み出しも基本的には1chと同じ。ただ、SCKを共有した場合、複数chで非同期にデータパルスが出るから、立ち下がりエッジを待ってサンプリングする場合はそのパルスを出したch以外は信用できないので、例えば80Hzの8chを順番に読み出す場合はワースト100ms程度かかる。

　立ち下がりエッジで割り込みをかけて時刻を記録し、メインループで読み出して、エッジから読み出しまでの時間が10ms未満(80Hz時)なら有効なデータとして扱い、それ以上なら捨てる、というような処理であれば、おそらく正しくデータを読むことができる。一定の(安定な)間隔で読み出しを行うとサンプリングレートと同期的になって読み出し頻度が低下する可能性があるから、十分に大きなジッタを含めた待ち時間(例えば2±1msの一様分布)で取りに行く必要がある。

　秋月のHX711モジュールで配布しているソースはこのデータレディパルスを適切にハンドリングしていないから、暗黙的に高いポーリングレートを要求している(コード中にはミリ秒オーダー以上のディレイは入っていないから、このコードを無改造で使うなら問題ないはず)。HX711のデータシートに書いてある参考コードも同様。

　とりあえず適当な力をかけるとそれらしい結果が得られるところまでは達したが、測定値から意味のある物理量への変換がかなり難解。既知の力を加えて逆行列を作ればいいんだけど、その既知の力を加えるのが難しい。

　ロードセルは3Dプリンタで作成したフレームに乗せたけど、なんかやたらとドリフトが大きい。ロードセルを締結してPLAにストレスが掛かってるのかな? そもそも、固定側のフレームを軽く押してもかなり値が出てくる。PLAだとひずみゲージで見えるくらいの歪は簡単に出てくる。プラスティックな感じもある。もはや何を測っているのかわからなくなってくる。

　あと、数chのHX711を並べてグラフ化すると、かなり綺麗なチャンネルもあるし、ものすごいノイズが大きいチャンネルもある。安物のロードセル&ADCだし、デバイスの流通経路自体不明だし、あまり期待しすぎても良くない。電源用のトランジスタだってよくわからんしな。

　今回はArduino Nano Everyを使用している。Arduinoを使うのは結構久しぶりな気がする。

　Arduino、ZIPファイル1個をダウンロードすればIDEが使えて、わりと簡単にLチカができるのは便利だけど、タイミングクリティカルな処理(いわゆる組み込み系の処理)をやろうとすると早々に破綻する気がする。結局チップのデータシートを読んで自分でレジスタを叩かにゃいけない。でもまあ、現代の少機能なマイコンだから、自分でレジスタを叩いてもさほどの苦労はない。物理的な規模感はSTBee Miniと近いけど、こっちは開発環境を整えたりCubeMXで初期設定したり、細かい機能を使おうとすると込み入ったレジスタを叩いたり、だいぶ面倒。最初から複雑な処理が必要ならARM系一択だけど、小さいところから始めて手軽に動作確認しようとするとちょっとな。

　オンボードのVCP経由でPCにデータを垂れ流していたけど、時々文字が3Fhに化けるバグが出ている。どうやらこれは既知の不具合っぽい。AI曰くハードフロー制御を有効にすれば解決できるよ、とのことだけど、手元の環境だとハードフローを有効にした場合は化けた文字が捨てられるだけで、結局文字列が壊れることに違いはない。ブリッジが溢れてエラーで3Fhが出てるっぽいから、PC側だけでなく、Arduino側でもハードフローを有効にすればいいのかもしれないけど、どうやるのかは不明。だいぶ前から報告があって、未だに解決できてないということは、そう簡単に対処できる問題ではないのだろう。

　こういう細かい(&結構致命的な)バグが放置されていると、Arduinoを真面目な用途に使うのは難しい感じがする。

　試しにNMEA0183的にXOR値をつけてみたけど、これでも見逃すことがたまにある。XORは同じ文字が消えたり、同じ文字列が固定値に化けると検出できないから、例えば'0'埋めや20h埋めとか、確率的に同じ文字が消える可能性が高い場合は見逃し率も高くなりそう。その点では普通のチェックサム(バイト単位の加算でmod 256)なら検出率は高いか? CRC16やCRC32みたいなものを使えば検出率は稼げるだろうけど、符号化と検出の両方を書かなきゃいけないのが面倒。

　あとは、シリアルポートで高頻度にメッセージを吐いているせいか、ブートローダでの書き込みが正しく動かないことも結構ある。一旦GUIで書き込みをキャンセルして、もう一度書き込めば大抵は書き込めるが、面倒くさい。シリアルポート周りちょっと特性悪そうだなー。

　そろそろ本腰を入れてRasPiPico系を触る頃かな?

　アナログデータの処理なので、試しにPythonで受信してグラフ化。昔は.NET FrameworkのChartで作ってたけど、最近の環境ではChartが使えないのでな。。。

　C/C++/C#を使っていた身からすると、Pythonはかなり違和感がある。スクリプト言語(そのコードが走るまでエラーの有無すらわからない)もそうだし、Pythonのデータハンドリングもそうだし。

　あと、オープンソースのbatteries includedな言語は「みんなが使う機能」に特化していて、そういう領域で作業すると慣れればものすごい楽に書けるし、言語の特徴として「ライブラリが豊富でやりたいことが簡単に実現できる」と紹介されるけど、ニッチな処理をやろうとすると、かなり大量のコードを書かなきゃいけないから、かなり面倒。ある程度の機能であればGit系のオープンソースを探せば見つかるかもしれないし、あるいは最近はAIに課金してP2Wという方向もあるかもしれないけど。

　C/C++/C#ではかなりの部分を自分で書かなきゃいけないとしても、それは最初から想定内だし、C#/VS IDEとかであればコードを書いている途中でエラーにハイライトが出たりするから、チマチマしたコードを書くのにはこっちのほうが便利。スクリプト言語でチマチマした処理を大量に書くと細かいバグを潰すのが大変。

　文法とかを除けば、大雑把には他の言語とそう大きく変わる部分はないけど、いまいち納得できない挙動もあったりして、なかなか大変。JavaScriptだとletみたいにブロックスコープで変数を宣言できるけど、Pythonだと下手すると別の関数で使った変数が波及してくるとか、わけのわからん挙動もある。

　素粒子をやっている人が実験機材を作ろうとして組み込み系のプログラミングをやると、アトミック操作に怒ったりするんだろうか? 「不可分な操作をアトミックって言うな！ クォンタムって言え！！」

　原子の意味じゃなくてギリシャ語だから……

小ネタ

　ロッキード・マーティン系の、オーストラリア東部の地上局。

　何人かの職員でH3-22Sの打上げを見ているシーンがあるけど、JAXAもバックアップとかで枠を確保したりしているんだろうか? それとも手が空いている人が見てるだけ?

　イギリスのスタートアップ企業の工作機械。ベースモデルが2万ポンド弱(400万円くらい)から。カルーセル2個のATCでチップツーチップが高速、TSC対応。かなりアグレッシブに加工するデモ。

　通常のカルーセルATCはツールを取り出したところに戻して、次のツールに回して、回転・停止を待って交換するから、チップツーチップが遅い。カルーセルが2個有ると(工具が左右で均等に分かれていれば)次の工具を呼んでおけるから、アーム式と同じように素早く交換できる。立型MCの主軸の左右にカルーセルが1個ずつついているから、コンパクトながらATC本数も多くできる利点もある。言われてみれば、今まで見たことがないのが不思議な感じ。

　4/5軸とUR10あたりを追加して小さい部品の量産とかに使うと便利そうではあるか?

　ちょっと見ない間にHaasの日本語サイトなくなったんだな。Haasが稼げるほど日本で売れるとも思えんが。

　光学機器としてどれくらいの性能が出るんだろうか?

　多少荒くてもオーダーメイドで(一点もので)しかもそれぞれ細かいカスタマイズをして何十個、何百個も欲しい、みたいな用途で、CNCで作れるようになると、今までできなかった観測や測定ができる場所が出てくるかもな。

　例えば昔の天体の分光は目的の銀河からの光だけを通すように、1箇所1箇所専用のマスクを作って撮影していたわけだけど、そういう「1点物かつ量産品」というような光学機器がある程度安く作れるようになると、今まではコストの面で不可能だったものが見えてくるかもしれない。

　全く同じ光学部品を100個とか1000個とかだとある程度の量産品になるから、もっと狭いところで。特に思いつかないけど。まあ、展示会とかで展示してれば誰かが興味を持って使うんだろう。

　BlueChip: Rebuilding American Computer Manufacturing - YouTube

　AndurilはノートPCの製造にも手を出すらしい。サプライチェーンを完全に国内に置いている、という感じらしい。軍用が前提だから、TOUGHBOOKみたいな耐久性もありつつ、Frameworkみたいな柔軟性もある。底面や天板は破損しても簡単に交換可能できるし、天板にはいろいろな拡張性がある。例えばソーラーパネルをつけたり、あるいはフェーズドアレイレーダーを内蔵したり。

　これでRISC-VとかだとLinuxかなという気もするけど、Snapdragon XならWindowsでも動きそう。コアが日本企業の傘下からライセンスされてるのは良いんか?という気もしないでもないけど、Andurilならそのあたりは柔軟に考えてそうだな。どうせ台湾とか韓国で製造するわけだし、本格的に米中戦争が始まったら安定供給は難しそう。長期化しなければ在庫だけで足りるし、在庫だけで足りないくらい長期化するなら米国内のファウンドリで製造するとか、色々方向性はあるだろうしな。あるいは、ノートPC程度なら最悪市場在庫をかき集めてもいいわけだし、そもそもノートPCの供給が滞るような状況ならミサイルやビークルだってまともに維持できるとは思えないし。

　CXPI(「日本発」のHMI向け低速車載バス)についてちょろっと調べ物。

　最小で8pinSOP程度のトランシーバを使うのはCANと同様、インターフェースはRS232プロトコルを乗せるのでマイコン側はUARTトランシーバを流用できるのはRS485と同様、1本の信号線をプルアップ/OD駆動で使うのは1Wireと同様、コマンダ側がクロックパルスを出すのも1Wireと同様、通信がなくても常にクロックが出続けるのは100BASEっぽい、定常的なクロックでデバイスを同期的できるのはSyncEに似ている、ブリッジICを使えばCXPIとディスクリート信号を計算機無しに直結できるのはSpaceWire RMAPっぽい、という感じかな。あまり突飛な点は無く、その分古いマイコンでも外付けトランシーバ1個でCXPIに参加できるから低コストで通信ができる。

　CXPIの特徴的な点は、コマンダが常にクロック(20kHz程度、おそらく非拡散)を吐き出すから、レスポンダはコマンダとコヒーレントで動作できる。なのでポーリングが決定論的に可能になる。もっとも、東芝が売ってる8ピンのトランシーバはクロックの入出力は無いっぽい。あと、単線を引き回して20kHzを出すので、EMI的にも厳しいらしい。

　CRCで誤り検出を行うらしくて、別にそれは問題ないんだけど、外部ノイズでデータが壊れたときに、クロックのコヒーレンシーを維持できるのかが疑問。インパルスノイズなら内蔵クロックでも十分なコヒーレント長があるからそれで補間すればいいということなのかもしれないけど。

　東芝では今のところはCXPIトランシーバは1種類、あとCXPIレスポンダを1個開発中らしい。このレスポンダはQFN28で、GPIOが16本あるので、ドライバを外付けすればモータやLEDを制御するのに使えるらしい。データシートが未公開なのでよくわからんけど、GPIOというくらいだからスイッチの読み取りもできるだろうし。CXPIの先にQFN28を1個つければIOエキスパンダとして使えるから、ちょっとしたロジックのIOであればマイコンレスでできるからBOMや開発コストが削減できるよ、ということなんだろう。SpW RMAP的に使えるのはBOMコスト/開発コストに有利かもしれないけど、とはいえLINでも同じような仕組みを作れば同じように使えるだろうからなぁ。

　少なくとも、東芝の2製品はクロック出力端子はなさそうだから、CXPIのClock Extensionは有効に使われているとは言い難そうだな。むしろEMI的に邪魔っぽい。開発現場だと、クロックが出続けているとオシロでトリガするのに一工夫が必要だから面倒そうでもある。バス使用率が低い場合はパルス幅でトリガすれば少なくともスタートビットは拾えるはずだから、Data/Strobeよりはマシかもしれないが。デバッグするならCXPI対応オシロを探すか、あるいはCXPIレシーバで一旦UARTに戻してUARTのプロトコルトリガで受けるか。

　ROHMのトランシーバはクロック入出力にも対応しているらしい。クロックを供給できるのであれば、レスポンダのマイコンはマイコン内蔵のRC発振器みたいに精度は悪いが信頼性は高いクロックで計算をしつつ、センサを読むタイミング等はCXPI経由の高精度なクロックを使ったり、あるいはCXPIを基準にしてRC発振器の調整を行ったりできるから、末端(環境が厳しい場所)に高信頼のクロックを置く必要がない、というような利点はありそう。最近は環境が厳しい場所向けの高信頼なCMOS発振子とかもあるから、わざわざデータバス経由でクロックを渡すプロトコルを用意するかというと微妙な気もするけど。

　Googleで車載バスについて調べると車種としてのバス関連の話(観光バスの広報とか)が大量に出てくるのでいまいち要領を得ない。データバス関連のワードを指定しているんだから車種のバスの話は除外しろよ、とも思うけど、とはいえ少し前にはEVバスの事故原因にデータバスが関連していたなんて例もあったしな。この辺の話を追いかけてる人は大変そうだ。

　LINって調べたことなかったけど、ちょろっと見た感じ、LINとCXPIはほとんど同じっぽいな。物理層はクロックの有無とそれに伴って変調方式が違う程度が大きな違いか?

　球面振り子、とりあえず3Dプリンタでナイフエッジ状の機構を作って、1mくらいの紐で重りをぶら下げて、支点の上に延長した磁石と、さらにその上にサーボモータで磁石を接近・離隔できる機構を作って、最初に与えた小さな振幅から、タイミングよく磁石を動かすと、振幅を励起できるところまでは確認。といっても、この程度は一般的なフーコー振り子でよくある機構なので、動いて当たり前という感じではある。

　ナイフエッジはV型の溝にエッジを入れる構造であれば、スイング方向の張力(振り子の重力ベクトルの水平成分)は吸収できるから、普通の振り子時計で使う分には問題ない。ただ、フーコーの振り子で使う場合、ナイフエッジの歯の方向にも負荷が発生するが、この方向は歯が滑って負荷を受け止められない。振幅が小さい場合は摩擦が卓越するだろうが、大きな振幅が必要な場合や、今回のように支点のさらに上で磁石で引っ張るような使い方をすると、簡単に滑る。

　科学館にあるような普通のフーコーの振り子の場合、かなり長い振り子を小振幅で使うから、ナイフエッジでも問題ないんだと思う。時計に使う場合でもV型の溝でなく平らな面の上に置くと滑りそうだけど、これも振幅が少なければ問題ないんだろう(NISTが初期に使っていた機械時計とか、高精度なやつで、宝石でナイフエッジを作ったやつがあった気がする)。

　以前別目的で買って(その用途はうまく使えなくて)積んでいたミニチュアベアリングで、自在継手的な構造を試作。安物のベアリングだけど、かなりスムーズに動く。ナイフエッジの場合は水平面に滑るし、上方向にも拘束されないけど、自在継手なら4軸が拘束されるからだいぶカッチリした印象。

　うまいこと作れば脱進機構は作れそうな気配は見えてきた感じがする。とはいえ、一朝一夕に作れるものではなさそう。3Dプリンタで摺動面を作ると摩擦がアホみたいにデカいので、小さい変な機構を作るのは大変。金属ですべらせれば(少なくとも短期的には)低抵抗で滑ってくれるけど、汎用の金属部品だと細かい構造が作りづらくて大変。

　うまいこと構造を作れば入手性の良い部品だけでもそれなりに動くものは作れそうな気もするけど、今回はこのあたりで棚上げかな。

　せっかくなので、5軸を拘束する機構も試作

　三角柱の頂点にベアリングを配置して、1軸の移動のみ拘束しない。3角棒(今回は6角棒)を通すと、5軸が拘束される。

　自在継手みたいに回転を受ける場合、振り子みたいに長いトルクアームがあるとベアリングの負荷はほとんどないけど、今回みたいにベアリングの直近で回転させると、ベアリングの回転抵抗がそのまま出てくるから、あまり軽く動かせない。

　ベアリング1個でベアリングを固定するネジ1個とベアリングホルダを固定するネジが2個で、ベアリングが6個あるから、ここだけでネジを18本使う。フレームの片端を閉じるために3本使っているから、トータルで21本。結構ズッシリ来る。

　ドライバー(プラスドライバーとかマイナスドライバーとかのドライバー)の先端がER11になっているヤツって無いのかな。ピンバイスみたいに任意の太さのチップをつけて使えるから便利そうだけど。でもERコレットの保持力でドリルを使いたいなら電動工具を使えば済むとか、細かい作業に使うには大げさとか、ちょうどいい使い所がないんだろうな。

　どうしてもそういう工具が必要なら、中華CNC用のERホルダと、それにあった太さのプラスドライバーとかを組み合わせれば、そういう工具は作れそう。というか、ピンバイスよりマシ程度のものがあればいいなら、ホルダー単体にビニールテープでも巻いて滑り止めにする程度でも良さそう。

　Airspy R2の受信周波数の設定、PC側は単に周波数(uint32_t)をUSBで投げるだけ。PLLの設定はR2側のファームウェアで行う。ファームウェアを見ると、指定された周波数と、PLLに設定した周波数の差を、stderrに吐くコードがコメントアウトされている。R2側のstderrなので、デバッグ用に入れていたコードなんだろう。

　librtlsdrの方はPC側で周波数からレジスタ値を作って、それを書いてるっぽい。

　R2にしろlibrtlsdrにしろ、PLLの値は、PLLへ入力するクロックやIF周波数によって変わるから、あまりスッキリとした計算にはならない。RTLは28.8MHzで動いて、それに合わせてR820も28.8MHzを突っ込んでいるはず。R2の場合はよくわからん。多分最近は10MHzのクロックをそのまま(あるいは非常にシンプルな整数倍で)突っ込んでいるはずだし、ゼロIFのはずだから、比較的シンプルなPLL設定になるはずなんだけど、そうはなっていない。

小ネタ

　半裸の鳥頭に比べればまだ常識的な格好よな。

　最近のFormlabsってホビー向け(個人で買える価格帯)からは撤退していたけど、また戻ってきたんかな? /* ホビー向けの樹脂SLSを開発中だった会社を買収したアレはどうなったんだ */

　コールドガスでジャンプしたり軟着陸したりできる車だそうだ。化学エネルギーを使わないので特別な推進剤が不要、コンプレッサーも内蔵していて外部支援無しに(電力ライン程度で)再充填できる、みたいなことなんだろう。これだけの推力を出そうとするとアホみたいな超高圧大容量タンクが必要だろうから、再充填にはめちゃくちゃ時間がかかりそうだが(外部からLN2を「給油」したりできるのかもしれないけど)。

　こういうバカみたいな遊びも大真面目にできるのは純粋に羨ましいな。仮にトヨタとかホンダがこういうコンセプトで試作だけでもしようと思ったら何が必要だろう? トヨタなら水素用に超高圧ガスタンクのベースラインは持ってるかもしれないけど、大容量のバルブやノズルの設計まですぐできるとは思えない。テスラ/SpaceXならその辺に座ってる技術者に「こういうやつを作りたいんだけど」って声をかけたら「じゃあこの部品を使えばいいよ」位の話はすぐ通りそう。本田技研ならRCSの制御はできるだろうけど、だからといってそれを車に積めるかというとなぁ。そもそも日本国内で合法的に試作できるかという点もあるだろうし。

　しかし、これが「空飛ぶクルマ」と紹介されているのを見るとちょっとアレだな。第二次世界大戦の潜水艦みたいな感じ。「空飛ぶクルマ」って、地上を走る車両を空に飛ばすわけじゃなくて、車のように気軽に使える航空機を意図しているものだと思うんだけど。スポーツカー的なレンジだとHondaJetとかだろうし、SUVみたいなあたりだとR-44あたりだろうし、徹底的に切り詰めるとウクライナのアレみたいなやつになるんだろうし。

　もうちょっと発表が早ければ、ワイスピで出てきそうな感じではあるか。でも、あの作品だと市販車でビル間を飛んだり、あるいは普通の車にロケットを追加して極端な使い方をするから面白いのであって、「空を飛べますよ」と言って売ってる車で空を飛んだりしても、F-150でホームセンターに買い物へ行くような、何の面白みもないシーンにしかならないんだろうな。「(テスラ)ロードスターで空を飛ぶの? メーカーの想定用途じゃん」。

　そういう意味では、ロードスターはFalcon Heavyで飛んだ時から、SF的な大衆作品では使えなくなってしまったんだろうな。まるでSFみたいなことをやるとSFに使えなくなるのか。そりゃ、SFが面白いのはフィクションの世界を見せるからであって、我々の世界をそのまま「サイエンスフィクションです」と提供したって面白いわけがないか。それで言うと、今後アクション映画でロケット付きの車を登場させると「あー、テスラのやつね……」ってことにもなるのか。

　Boom Tech.のCEOの子どもの話とかもそうだけど、今後数年くらいで映画を見始めるような世代はワイスピを楽しむのも難しくなってしまったんだな。まあ、技術革新の歴史としては、創作物を時代遅れにしていくのが正しい方向ではあるんだけど。日本の場合、鉄腕アトムとかドラえもんとかガンダムとか、わりと振り切ったものが多いから、その点では当面は安心して見ていられるかな? ドラえもんの道具くらいの感じだと、一部は実際にそれらしいものが作られ始めてはいるし、人型ロボットもだいぶ近づいてきた感はあるけど。

　うるう時間で調整が数千年単位になると、その時代では、例えば我々の時代の朝8時が9時だったり、1時間ズレて生活しているのが当たり前だから、いきなり「明日から社会を1時間早くします」とか「1時間遅くします」ってのはさすがに影響が大きすぎる気がする。1時間の移動は夏時間の調整程度ではあるとはいえ。

　グリニッジ子午面の太陽通過で正午を決めなくなると時刻の定義は天文時から純粋に原子時に変わるだけで、それ以降もわざわざ天文時に合わせる必要はなさそう。そのまま時間のズレが増えていけば、数千年、数万年後には0時頃に日の出や日の入りが観測される、みたいな。コールドスリープで1万年後とかに飛んだ人間は時計の読み方に困るけど、連続的に生きている人からすればそれが日常になる。

　数字全体を移動する(例えば正午を12時ではなくする)のは、現代を生きる我々からすればそんなことは許容できない、みたいなことになるだろうけど、何千年も経てば気にしないはず。我々(主に英語圏の人類)が使ってるカレンダーだって10月がOctだし12月がDecだぞ? 2ヶ月もズレてるのに誰も文句を言わないだろ。2000年も経てばそんなものよ。慣習として「歴史的にこの数字はこの時刻に割り当てられている」として記憶されていれば良い方で、多分その時代になれば誰も何も気にせず14時とかに昼食を食べたりするはず。学校で「今日はやけに腹が減って13時に早弁しちゃったよ」とか、歴史に詳しい友達が「おまえ紀元前の人間かよ」と突っ込んだりとか。

　あるいは、現在でも巨大なダムで地球の自転が変わるみたいな話もあるわけだから、数千年くらいのタイムスケールなら地球の回転速度をうまいこと調整する技術を人類が作るという可能性もあるが。角運動量を直接出し入れするのは大変だから、質量の標高分布を変えて角運動量を保存したまま回転速度を調整する感じになるのかな。遅くするには質量を上げればいいわけだけど、長期的に見れば地球の自転は減速方向だから、加速するように調整しなきゃいけない。となると、山を崩して海を埋め立てる、みたいな話になる。核融合でエネルギー問題を解決してAIで無人土木工事が実用化すれば、数千mの山を切り崩して埋立地を作る、くらいは可能だろうけど、とはいえ。

　電波で直結できなかったアジアは国際原子時に接続されるようになったかなり最近まで天文観測で時刻を決めていたわけだけど、UTCも結局天文観測でTAIとオフセットしていたわけだから、閏秒の廃止によって人類は有史以来続いた太陽で時間を決めていた歴史が終わるのかな。VLBIで時計を結合するみたいなことは続くのかもしれないけど、それはあくまでも間接的に参照しているだけであって、絶対的な時刻を決定する基準にしているわけではない。X線パルサー航法みたいなのが実用化されればまた天文で時刻や位置を決める時代が再来するんだろうけど。

　ダイハツがアンモニア燃料の軽エンジンを開発、プラズマで水素を生成し燃焼促進：Japan Mobility Show Bizweek 2026 - MONOist

　燃焼ベースのゼロエミッション化。トヨタは水素を燃やしているけど、液体水素は極低温かつかなり高い圧力でハンドリングしている。アンモニアなら2MPa弱で常温で液化できる。このエンジンは燃焼をアシストするために水素を混ぜるが、アンモニアの分解で作れる。始動時は外部からのエネルギー供給で、エンジンが温まればその熱を触媒に与えて。

　小型車のゼロエミッション化だとコンパクトに作りやすいアンモニアは便利そう。もうちょっと小さくして、バイクくらいの小さいモビリティのゼロエミッション化でアンモニアを使うみたいなことってできないんだろうか? でもそれくらいの規模なら手で持てるくらいのバッテリーパックを交換すれば済むから、液体燃料を使う利点はあまりなさそうだな。

　逆に航空機向けとか? いくらLH2よりはハンドリングしやすいとはいえ、MPaオーダーの燃料タンクかぁ…… 航空機の電動化を批判する文脈では「燃料は燃やせば機体は軽くなるが、電池は消費してもデッドウエイトになるだけ」というのがあって、そういう意味ではアンモニアは便利そうではある(LH2は極端に軽いしタンクがめちゃくちゃ重たいから、本質的には電池と同じ)。

　South Pole Foucault Pendulum

　2001年に建設中のアムンゼン・スコット基地の階段室でフーコーの振り子の実験を行ったときの記録。

　振り子にエネルギーを与える機構がなかったから、数時間ごとに振り直す必要があって、回転速度の観測値は24時間±50分だそうだ。この記事では24時間というのが出てくるけど、実際には太陽日ではなく恒星日だからおよそ23時間56分のはず。

　フーコーの振り子で安定化した機械式時計って作れないんだろうか? 通常の振り子時計は振り子からシンプルなメカニカルリンクでガンギ車と接続しているから、1次元的な振り子(平面振り子)にしか対応できない。フーコーの振り子のように球面振り子で時を刻むためには何らかの工夫が必要になる。あと、振り子へのエネルギーの供給も問題になる。

　とはいえ、別にさほど苦労せず作れそうな気もする。例えば支点の真上に磁石を置いておいて、振り子の延長線上の磁石が接近して引っ張られるとガンギ車が回る、程度のものでいい。一定以上の力が加わって下に引っ張られるとそれに反応して磁石が引っ込むような形になっていれば、振り子が中心に向かって進むときには磁石が引き合って、一定以上の範囲に近づくと片方の磁石が離れるから、中心から離れる動きの場合は磁石による引力が少なくなる。球面振り子に対応したタイミングの測定とエネルギーの供給はこれでできるはず。磁石の引力みたいな微妙な力を検出しなきゃいけないのが面倒そうではあるけど。あとは、磁石を使うと渦電流でエネルギーが散るから効率が悪い(頻繁におもりを巻き直さなきゃいけない)とかは懸念される?

　フーコーの振り子に連動して文字盤が回転しても面白そうだけど、それは機構が面倒になるだろうし、1日より少し遅い周期で1周する文字盤は見づらそうだ。ビッグベンみたいに4面とかの文字盤を回転させて見やすくさせるとかも可能ではあるだろうけど。しかし振り子に影響を与えずに位相を調整するのはちょっと大変そう。下手にプローブを当てるとそれで振り子の垂直軸の角速度が影響を受ける。なんだか量子論じみた話になってくる。

　比較的小さいフーコーの振り子なら支点の上に時計をつけてもいいし、支点を見上げるのが大変なくらい巨大なら振り子の下に時計を置いてもいい。ただ、下に時計を置く場合は振り子自体を磁石に反応させるわけだけど、その場合は磁石の運動と地磁気が変な相互作用をする怖さはある。エネルギーを与えるためには少なくとも振り子は磁性体で作らなくてはいけないから、完全に影響を排除するのは難しい(磁石が上にある場合は支点との距離が短い分で移動距離(∝速度)が小さくなるから地磁気との相互作用は少なくなるはず)。

　フーコーの振り子は決まった速度で垂直軸周りに回転するから、それを時計の長周期成分として使うことは考えられる。とはいえ、回転速度はsin(lat)で決まるから、自由に使えるわけではない。1周回ったら12時間、みたいな綺麗な表示は難しい(緯度30度線上だとできる)。

　日本だと屋久島の南西にある口之島がちょうど北緯30度に土地がある。

　北緯30度線モニュメント – 十島村観光・定住情報サイト

　戦後、北緯30度以南が米統治下になり、口之島もアメリカが統治していたので、日本復帰後に30度線のモニュメントを置いたらしい。

　フーコーの振り子を極点に設置すると約23時間56分で1周するけど、時計として(短針代わりに)使おうとすると24時間で1周してほしい。これを緯度に換算すると85.7度くらいになる。このくらいの微妙な緯度にはちょうど良さそうな基地はなさそう。

　Beast of Reincarnationをプレイ中。

　こういうゲーム(銃メインじゃないやつ)は慣れていないので操作がちょっと違和感。まあ、慣れるしかない。

　慣れている人からすれば問題ないんだろうけど、こういうゲームに不慣れでいきなり触ると操作方法が全くわからなくて詰む。攻撃ボタンを押す回数には意味があるとか、防御ボタンを押すタイミングには意味があるとか、そういう基礎知識が皆無でいきなりフィールドに放り出されると、ボコられ続けるし、わからないままに敵の攻撃3連撃を受けて死に戻りする。

　難易度NORMALだと全く進めないけど、とはいえSTORYだと簡単すぎる。というか、STORYの場合はボタンをガチャガチャ押すだけで進めてしまうので、成長が得られない。STORYとNORMALの間にTRAININGみたいな難易度が欲しい。

　例えばスト6のトレモみたいな感じで、タイムラインが表示されて、回避やパリィのボタンを押していた期間と敵の攻撃判定のタイミングがわかる、みたいな機能があれば、超初心者が始めるのは便利な気がする。このゲームの世界観なら世界観に沿ってトレモを作ったり、あるいは、武器選択で刃引きした剣を持ったらクゥと模擬戦ができる(時系列のメーターが表示される)みたいな感じでトレモ的な機能がほしかった。

　プレイヤーの操作中、ずっと抜刀して歩いているのがあまり好みじゃない。あと、フィールドでもモフモフと触れ合えるようなギミックが欲しかったな。欲望を垂れ流すならどこかで20式を拾いたかった。

　作品としては、いろいろな作品のフレーバーが感じられる。でも極端に寄りすぎることもなく、元の作品の尖った部分は削ぎ落として、バランスはかなり良い。

　ゲームシステムに不満がないわけではないけど(主に細かい快適性の部分)、ゲームとしては良かった。

　ネタバレというような内容でも無いと思うので気にせずに書くけど、途中で太陽、月、地球がどの順番で生まれたか、というような謎解きがある。多分こうだろ、というような順番で適当に並べたらうまく行ったのでそれが正解だったんだろうけど、しかし恒星進化(含惑星)の順番としてそれは正しいんか?という疑問。そもそも天体がどの時点で「生まれた」とするかにもよるけど。

　物理的に質量がある程度集まった時点で考えるなら、中心に濃集した水素が太陽(の種)として生まれ、残りカスのディスクが濃集して惑星(の種)が生まれ、その後軌道が安定化する前に惑星衝突で衛星が生まれ、という順番なら、太陽→地球→月という順番になる。

　一方で、ディスクの残りカスが存在していた時点(惑星が形成された時点)ではディスク中心では恒星活動はいまだ始まっていないはず(強い放射が始まるとガスが吹き飛ばされるから惑星が作れない)。そう考えれば、地球→太陽→月という順番になる。

　ある程度安定した状態、つまり太陽であれば核融合反応による放射が表面から発生し、地球や月であれば重力エネルギーの発散が終わり、という段階を指すのであれば、ジャイアントインパクト後のドロドロした地球よりも先に月のほうが冷えるはずだから、太陽→月→地球という順番になる(ジャイアントインパクト以前の地球を現在の地球と別と区別した場合)。

　このあたり(恒星進化論)はだいぶ曖昧に覚えているから、あちこち間違ってそうな気もするけど。/* 宇宙論的な本は結構売ってるけど、恒星進化論みたいな本ってあんまり無い気がする */

　恒星進化論 / 杉恵ゆりか - YouTube

　3本のNVMeの健康状態、CrystalDiskInfoで48%、86%、92%。最初の2本はRAID1でCドライブに、3本目は単独で最近はゲームのインストールドライブに使用している。RAID1の片方がやたら削れてる。たぶんコイツは書き込みキャッシュを使わず高頻度で書き込んで、システムがクラッシュしたらこっちをプライマリにしてスキャン、みたいなことなんだと思う。

　過去のエントリを見ると、去年の6月時点で62％、一昨年10月時点で70%未満、だそう。16ヶ月で14%だから、当時の見立て1%/月相当で経過している。

　元々ページファイルがCドライブに入っていたが、今回これを単独のNVMeに移動した。ページファイルは本来の用途としてはある程度頻繁な書き込みが発生するから、RAIDに置くのは適切ではないはず。ということで、移動した次第。もっとも、このドライブが故障するとページファイルの置き場所が壊れるから、危険ではある。ブートドライブの寿命を削ってRAIDの再構成の危険との天秤(Windowsは起動時にページファイルを置いているドライブが見当たらない場合はCドライブにページファイルを作り直すらしいので、ページファイルを置いているドライブが壊れても、Cドライブ自体が壊れるほどの悪影響はないはず)。

　そもそも、このPCはRAMが比較的安い時代に組んだもので、動画編集とかをやらない個人が使うにしては結構大きめの容量を積んでいる。RAMの容量はあまり厳しくないので、たぶんページファイルはあまり使っていないはず。じゃあRAIDに置いていても良いんじゃないの?という気はするけど、とはいえただでさえ容量に余裕のないCドライブにほとんど使わない巨大なページファイルがあるのも邪魔なので、移動した次第。

　半年とか1年とか様子を見て、プライマリのストレージがどれくらい削れるか見てみよう。

　RAIDはMBのチップセットの機能だけど、AI曰くこのチップセットはRAIDの拡張に対応しているらしいから、OSの再インストールとかをせずとも拡張できるはず。とはいえ、2TBとしても2本買うと10万円だからなぁ。PCを組んだときに買ったやつは1TBで1.2万円だったのに、今では1TBも3万円弱まで高くなってる。ストレージの値上がりもすごいや。半導体がムーアの法則で安くなろうとしても、それ以上に需要が旺盛で札束を積む会社がいくつもあるとどんどん値上がりしていく。

　先日の緊急地震速報の際、ISDB-Tのサンプリング忘れてました。たぶんAC1で出てたと思うんだけど。そこまで手が回らなかったというか、頭が回らなかったというか。スマホの緊急地震速報が出なかったからそもそも緊急地震速報が出ていたことを知らなかった、という言い訳。

　GPSの測位演算、30秒くらいのデータを解析して、GGA/ZDAをGoogle Earthに突っ込むと、ほぼ正確な位置に平べったい回転楕円体が突き刺さる。15mくらい高めに出ているかな、という感じはあるけど、とはいえ回転楕円体の長軸が上下方向だし、誤差の範囲という気もする。ジオイドの符号を逆にすると完全に空中に浮くから、おそらくジオイドの補正は正しい。電離層・対流圏は未補正でサニャック効果だけ適用しているけど、アンテナを置いた建物にきれいに突き刺さるから、かなり高い確度で測位できている。ループフィルタが超広帯域だから、精度はさほど良くないけど。それでも短軸は端から端までで35m程度だが。

　累計のサンプル数をサンプリングレートで割った、受信機クロックベースの時刻と、測位演算で求めたGPS時刻から、1次を引いて、つまりクロックエーラ成分だけを取り出してグラフ化すると、3.1e-7くらいの傾斜になる。フリーランしているTCXOが0.3ppmというのは十分に妥当な気がする(Airspy R2のTCXOはある程度特性の良いものが乗っているはず)。

　対して、衛星のドプラからユーザの4次元速度を推定して、クロックの速度を見ると240m/s程度に見える。光速で割れば無次元になって、これが実際のクロックエラーに相当するはずだが、240/299e6でだいたい0.803e-6くらいになる。推定値が2倍以上ずれるのはちょっと腑に落ちない。

　ドプラは搬送波のズレを見るから、LOの誤差がそのまま乗る。時刻の微分なら純粋に受信機のクロックエラー(ADCのサンプリングレート誤差)だけが見えるはず。そもそもR820T2/R860のLOってどれくらいの確度なんだろう? 0.8-0.3=0.5ppm程度とすると、L1で750Hz程度、UHFなら250Hz程度になる。ちょっと大きい気もするけど、元々がワンセグ受信用(あるいはせいぜい地上波テレビ用)であることを考えると、その程度の誤差はしょうがない気もしないでもない。

　R820T2のレジスタマップを見てみると、PLLに関連しそうなレジスタは24bit分の割り当てがある。PLLの精度が24bitとすれば10進で7.2桁の精度しかないから、Lバンドでは100Hz程度の分解能しかない。先の推定に比べるとまだ7倍程度の差があるけど。

　SDR#でWAVに保存すると、指定した周波数から若干(L1の場合1582Hz)ずれるけど、これってR860のLOを加味した中心周波数を表示しているんだろうか? 1.6kHzは先の100Hzに比べて10倍以上大きいけど、これは24bitが綺麗に使われている前提だから、例えば20bitしか有効に使われていないなら、1575.42M/2^20=1502Hz程度で、実際のズレとはわりと近い値になる。

　Airspyt R2に適当な周波数を周波数を設定してairspy_r820t_readでレジスタを読んでみると、4箇所くらいが書き換わっているらしい。1個がPLLの整数分周、2個がPLLの分数分周、もう1個がミキサ前の分周らしい。全体として26,7bitくらいで設定できるっぽい。ただ、rtl-sdr blogが公開しているレジスタマップとは合わない箇所がある。librtlsdrのコードを追えば良いんだろうけど、さすがにそこまでは面倒で。。。

　もしもR860のPLL分解能が足りない場合、GPSのドプラやISDB-TのCPを見て受信機のクロックエラーを補正するというのは意味がない可能性が出てきた。それが目的で始めたんだけど…… GPSやISDB-Tとクロックを比較する場合、GPSならGPS時刻得て、ISDB-Tならフレーム等価でシンボル窓のオフセットを求めて、それを微分してクロックエラーを見るしか無いのかな? あるいは、R860のPLLのループが分かれば、そこで発生する差をオフセットして直接CPを見るということもできるかもしれないけど。

　もしSDR#が内部的にクロックを補正しているのであれば、SDR#でISDB-TのCPをCWで受信して、位置を調整するというのは、意味がある。線幅が数百Hz程度あるから1ppm程度までしか追い込めないけど。R2が1ppm未満の誤差なら、意味がないということになる。通常の(例えばR820T/RTL2832Uの)ドングルだと指定した周波数ジャストのWAVが出てくるから、多分内部クロックの補正はしていなくて、SDR#でスペクトルを調整するのもあまり意味は無いかもしれない。あるいは、R2はR860のクロックが10MHzでRTLは28.8MHzだから、これがPLL分解能に影響して、RTLベースでは綺麗なクロックが設定できるという可能性もあるけど、中途半端な周波数を設定しても1Hzの誤差もなく生成されるから、fc推定の処理を省いているだけだと思う。librtlsdrはR820TとE4000分岐しているから、SDR#もRTLの先に何がいるかはわかっているはずで、それならPLLの誤差を推定しても良さそうな気もするが。

　櫛形フィルタのFIR型とIIR型の比較。適当に乱数を突っ込んでフーリエ変換。

　FIR型の櫛形フィルタは馴染みのある形というか、そういう雰囲気。IIR型は対称的な形になる。

　FIRは安定なので係数は自由に設定できる。IIRは|k|<1じゃないと安定しない。

　CICフィルタはIIR型を積分器として、FIRを微分器として使って、係数は1あるいは-1で固定されている。なので、状況によってはIIRでも|k|に1を与えても安定な場合もある(CICは2進数の整数演算でごまかしてる感じもあるけど)。

　高周波成分をカットしたいならFIR型でHCF的に、低周波成分を通したいならIIR型でLPF的に、みたいな使い方になるのかな。

　ちなみに、FIR0.5+とIIR0.5をカスケードすると

　みたいな感じで、FIRとIIRの非線形特性が打ち消し合って、直線な特性になる(片対数グラフで直線とか議論してもアレだけど)。

　NCO(キャリア/コード)のフィードバックループにIIR Combフィルタ(k=1弱)を入れても、精度(雲の大きさ)にはあまり影響はなさそうな気がする。少なくとも、Google Earthでぱっと見てわかるような差は無い。それよりはフィードバックゲインを下げるほうが圧倒的に効く。ゲインが小さすぎると収束できず衛星をロストするけど。

　本格的にやるなら、キャリアやコードの位相をカルマンフィルタみたいなもので推定してやるのがいいんだろうけど。

　現状、観測量は50Hzで出しているから、10サンプルを平均して測位演算すれば、それだけでも雲はかなり小さくなる(たぶん10サンプル平均なら3倍くらいは改善するはず)。下手なループフィルタを入れるより、ほとんどフィルタを通さずノイズの多い観測値を高レートで吐き出して、後ろで(オープンループで)フィルタに通したほうが楽。クローズドループの中にフィルタが入らなければ安定性の面でも有利だし、どこでフィルタを通そうが結局違いは無いはず。実用的な受信機なら、軌道モデルに忠実なループフィルタを作ればスプーフィング耐性が上がる、とかはあるにしろ。

　GPSのリアルタイム測位を走らせていると、PCがかなりうるさくなる。普段UPSの負荷はディスプレイ等も含めて250W弱だけど、測位中は350Wくらいまで増えるから、GPSの受信だけで100Wくらい食ってることになる。実際には、チャンネルスキャンをとめどなく回しているから、それの負荷が大きいんだろうけど。

　思いつきで作った画像

　2500x2500なのでブログではリサイズされて本来の意図通りに表示されない可能性もあるけど。

　QRコードのドットの中に、さらにQRコードを埋め込んでいる形の画像。用途としては、画像認識(姿勢推定)みたいな場合に、引きで撮影すれば外側のQRコードが見えて、寄りで撮影すれば内側のQRコードが見えて、という感じで、マーカーへの距離に対するロバスト性を確保することを目的としている。

　通常のQRコードの場合、21x21pxだから、大きなコードと小さいコードの大きさの差がちょっと大きすぎる気もする。

　DataMatrixの場合、10x10pxから作れる(QRコードも小さいコードは仕様化されているけど、普及しているんだろうか?)。

　コードのフォーマットとして、外側はID単体、内側はID+座標、というフォーマットを考えて、外側が10x10にクワイエットゾーンを足して12x12pxとした場合、内側には座標として3桁の数字が必要になる。外側が10x10だと数字は6桁まで、内側が12x12だと数字は10桁まで含めることができるから、例えばIDを6桁、それに座標を足して9桁、というようなフォーマットは作れる。

　内側も10x10にすると、6桁の中でやりくりする必要があって、例えばIDを0から5000未満の範囲で、座標は5000倍して上位桁に挿入し、読み取った数字が5000未満なら大きい方のマーカー、5000以上なら内側のマーカーだから、5000で割ったあまりがドットの位置、というように読むこともできる。

　そういうフォーマットで作ると、こんな感じ

　ただ、10倍のダイナミックレンジはちょっとレンジが狭い気もする。16x16とかのほうが便利かも?

　こういうコードの場合、隙間を開けずに連続して大量に貼るような使い方をするだろうから、大量に生成できるもう少し大きいDataMatrixのほうが良いかも。

　元々は3段階くらいでスケールできるようにしたかったんだけど、コントラストを稼ごうとすると2段くらいが限界っぽい感じ。これでも結構厳しい。大きさ的なダイナミックレンジを広げても輝度方向のダイナミックレンジが狭くなって画像認識精度が悪くなれば意味ないし。

　しかしまあ、こういう画像認識用のコードって見かけない気がする。普通のコードでも、認識できる範囲で引いた状態であれば複数のコードが視野に入るから統計的に処理できる、少数のコードに寄った場合は高空間分解能で撮影できる、というような理由もありそう。そもそも論として、そこまで極端に距離の差が大きい環境で画像認識を使う需要もないだろうし。ローバー系の研究室なら床や天井にマーカーを貼ってマーカーとローバーの距離は一定で使うとか、ドローンみたいに極端に動き回るやつはそもそも画像解析が難しいから精度を求めるならIRマーカーを追尾するとか。

小ネタ

　世界初の「原子核時計」、ウィーンと北京の研究チームが開発 | ロイター

　それぞれ独立に。

　あと5年10年くらいはかかるのかなと思っていたら。どの程度の安定性が出ているのかわからないけど。

　Nuclear clocks tick for the first time

　オーストリアチームは時計を作りたくて作ったわけじゃなくて、暗黒物質の探索のために作ったらしい?

https://www.amazon.co.jp/dp/B0HJ4WMTT6

https://www.amazon.co.jp/dp/B09RWPCYZW

　解説本としては文章が荒削りな感が否めない気がする。測定の歴史とかで急に値が出てきて、現在からすればその値を使うのはわかるけど、その当時はまだその値は出てなくね?とか。

　第4部では定数の不変性とかの話が出てくるので、このあたりは読んでいても面白い。クエーサーとかオクロ炉の話も出てくる。ただ、それ以前の歴史の説明では日本人研究者の功績みたいなところもちょこまか書いてあるけど、オクロについては一切触れられていないのがアレ。アメリカの核研究者が否定した核分裂炉の自然発生を予言したのは日本人やぞ。

　前回のGPSの搬送波ドプラが飛ぶ挙動、多分SNRが悪くてキャリアを微分したときに時々大きなノイズが出る、みたいな感じだと思う。極端なLPFを入れていたから、大きなノイズが入るとステップ状の変動に見える。

　安物のSDR受信機を使っているからしょうがないとはいえ、SNRが低いのはどうしようもない。とはいえ、専用のGNSS受信機を使ったところで、信号強度が低い場所ではSNRは極端に悪化していても問題なく使用できるはずだから、多少SNRが悪くても搬送波を追尾することは可能なはず。企業努力でカリカリにチューニングしたフィルタとかを使ってるんだろうけど。

　とりあえずBPSKを復調して航法メッセージを取り出して、衛星位置を計算するところまでは動くようになった。受信機時空間座標の高精度な(100m程度の確度の)推定値を与えて空間と時間の距離をグラフにすれば、ほぼ正確に直線に乗る(含Δtsv)。

　ちょっと前までISDB-Tで遊んでたから、その感覚でGPSを触るとSNRが低すぎて大変。めちゃくちゃアナログ的。ISDB-Tは十分なアンテナで高SNRに受信すれば復調するだけならほとんどデジタル処理でいいから楽。

　測位演算の計算、IS-QZSS-L1Sの式から補正項と重みを除いて使おうかと思っていたんだけど、この計算って受信機クロックエラー項が無いんだな。通常は衛星と受信機の距離(Ri)にクロックエラーが追加されるはず。

　そもそもこの計算式、POSを直接求めているのが不思議なのよな。普通はPOS_jでj=0に適当な初期値を入れて、POS_j=POS_{j-1}+補正量でjを適当な回数(例えば5回程度)回して、補正量が収束すればそこでPOS_jを採用して終了、みたいな処理になるはずなんだけど。

　あと、サニャック効果の補正も入っていない。電離層はたぶんDGPSで消す想定なんだろうけど。

　あるいは、単独測位である程度の正しい位置を得たあとに、L1SのMT50他補正値を使うということなんだろうか? それにしたってサニャック効果の補正も必要だろうし、(G^T G)^-1 G^T dPRで取れる結果も補正量だからPOS=にはならないはずなのだが。

　とりあえず、単独測位ができそうな感覚は得られているのだが、今回の目的は受信機のクロックエラーの推定だから、できれば移動中に取得した(既知のドプラ成分を含む)サンプルが欲しい。どうやって取るか。歩くような速度でも見えるのかな?

　RTL2832Uはサンプルのドロップがあるからクロックエラー成分はドプラを見る必要があるけど、Airspy R2なら時間微分でもいいのかな? まずは単独測位でトラッキングできるようにして、時間微分して様子を見て、か。

小ネタ

　とっさに操縦桿を握った乗客、惨事を免れたのはテレビ番組のおかげ　イスラエル行き旅客機 - 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>に対応すれば色々楽になる。

小ネタ

「富良野・美瑛ノロッコ号」ラストラン 28年の歴史に幕 | NHKニュース | 北海道、鉄道、観光

　近所を報道のヘリが3機くらい飛んでて何事かと思ったら、これを撮りに来てたのか。

　この間の十勝岳みたいに報道ヘリが素通りしていくことはたまにあるけど、このあたりにある取材対象を報道ヘリが撮りに来る、なんて事態はほぼ記憶に無い。かなり珍しい。

　数百基の光通信衛星で大容量通信を実現へ、ＮＥＣが整備計画…日本独自の衛星網で経済安保強化（読売新聞オンライン） - Yahoo!ニュース

「日本は光ファイバの人口カバー率が99%だが、山間部など4割は未整備で、災害時や有事に備えて衛星通信が重要」(要約)みたいな話、たぶんNECが言ってるわけじゃなくてメディアが考えたストーリなんだろうけど、こういう考え方で衛星コンステを構築するとろくな結果にならないと思う。日本の国土の4割なんて地球の表面積に比べれば0.03%でしかない。そんな針で突いたような面積のために(しかも有事の時だけに)数百機規模の衛星コンステを作ったって全く割に合わないわけで。もっと採算性の良い用途を探さないと。もちろんNECはそのあたりも考えて構想しているんだろうけど。

　しかし、自分でローンチビークルまで持ってるSpaceXに対抗できるサービスを作れるかは結構怪しい気がする。だったらグローバルな衛星通信でなく、リージョナルな衛星通信システム(例えば準天頂通信衛星)を作ったほうが良くね?という感があるが、それはそれで日本以外で稼ぐのが難しくなるからやっぱり難しいんだろうな。オーストラリア、インドネシア、パプアニューギニア、あたりはサービスエリアに入るとはいえ。あとは、LEOだとスマホと直接通信が見込めるけど、GEOだと大変だろうし。一応、GEOとモバイル端末の直接通信が通る見込みは20年くらい前に得たんだろうけど、あれももうロストテクノロジーだろうしなぁ。

　それに、災害時のバックアップとして、といったって、地震ならともかく、台風みたいな気象災害を想定すると、光通信って使い物にならないと思うのだが。そもそも光だと衛星1機に10個の開口をつけたって、500機で5000ユーザーしか収容できないし、全地球で同時に5000ユーザーでは使い物にならないだろうし。ユーザー側の回線は電波で、バックホールを光で、ということなのかもしれないけど。サービスリンクはどうやって下ろすのかという問題が残るし。衛星間だけ光で結んで、とかになるのかな。

　関東圏のメディアが「原発は大都市で消費する電力の生産を地方に押し付けている！けしからん！」みたいなことを言っているのを目にすると、なんだかなぁ、って感じ。原発に限らず、「持続的な電力」ってたいてい地方任せだろ。太陽光発電にしろ、風力発電にしろ。山を切り開いて太陽光発電パネルを敷き詰めて、それが地方の負担にならないとでも? メガソーラーだって色々事故起こしてるだろ。山間部なら光害問題もあるし。風力発電だって同様。ブレードの落下事故も起きてるし、騒音問題や景観問題、鳥類への被害も多発している。

　そもそも、電力に限らず、大都市と地方って大なり小なりそういう構造だろ。大都市が消費する大量の食料は、日本の食料自給率が低いことを加味しても、かなりの部分は地方からかき集めた食材が使われている。低賃金で食料を生産して、ろくな教育のない地方で一子相伝のように続けられている農業が、大都市からの押しつけでなくて一体何だと言うんだ? 大都市を形成するビル群はどうやって作っている? 地方からかき集めた材料を固めているだけだろう。

　原発に反対する理由が「地方への押し付け」なら、電力以外のものもすべて都市部で生産すべきと主張しなきゃおかしい。食料はどこで生産する? 人間の飲水や食料を生産するための水はどこで取水する? 川から取水するのは上流部の地方に依存していることに変わりはない。大都市に降った雨を貯水して使う? 水槽やビルを立てるためのコンクリートは? 地下を掘削して開発する? コンクリートの使用を減らして木造建築を増やす? その木はどこで育てる?

　そんなことは全く非現実的だろう。それなら現実と折り合いをつけて、大都市は地方が生産する資源に依存して、その代わりに大都市の活動で稼いだ莫大な収入のいくらかを、補助金なり助成金なり名前は何でもいいが、地方に還元するほうが建設的だろ。これは必ずしも税金を経由する必要はなくて、例えば第一次産業(および採掘のような第二次産業の一部)の価格を引き上げて、直接的な収入を増やすといったことでもできる。地方に住む人の収入が増えれば地方の税収が増えるから、地方自治体への補助金を減らすこともできる。でも結局は大都市で稼いだ金を地方に配分する、という形が変わるわけではない。

「地方では原発に反対していても声を上げられない。地域の分断を招いている」と言っている人たちが、大都市と地方を分断しようとしているように見える。大都市では大都市でしかできないことをやる、地方では地方でしかできないことをやる、そうやって持ちつ持たれつ発展していくのが、国としてのあるべき姿だろ。

　誰かがそれぞれの役割を果たすのが多様性のある社会であって、誰もが同じことをやるのは多様性とは言わない。大都市には大都市にしかできない仕事があるし、地方には地方にしかできない仕事がある。それに対して大都市が優遇されているとか地方差別だとかの声を上げて、無理に統一しようとするのは間違っていると思う。大都市と地方に格差(例えば賃金格差)があるなら、それの対策は「大都市の仕事を地方に移す」とかではなく、「地方が行っている仕事の給料を増やす」というような方向であるべき。

　例えば「クリエイティブな仕事」と一口に言っても、大人数が集まって侃侃諤諤のブレインストーミングを行わないとできない仕事だってあるだろうし、一人が自分の好きな環境で静かにする仕事だってある。前者を田舎でやろうとすれば移動時間や交通費だって馬鹿にならないし、後者を田舎でやりたいという人を大都市に閉じ込めたってろくな仕事にならない。

　まあ、なんだかんだ言っても、当ブログの読者なら御存知の通り、僕は田舎アンチの過激派なので、ね。都会モンが田舎を憐れんでるようなスタンスを見ると「はぁ！？」とか思うわけだ。別に当人は憐れんでるとかそんなこと思ってないんだろうけど。とはいえ、「地方の人は声を上げることもできない、我々が代弁しなくては」とかそういう感じの変な正義感はありそう。

　炭酸飲料に入れる氷、一旦水なりお湯なりにくぐらせて洗った氷を使うとnucleation siteが減って良いらしいという気づき。もうちょっと早くに知りたかった…… せめて夏の間に。

　ウイスキーとかに入れる丸い氷も、軽く洗って表面粗さを改善して使えば炭酸飲料に入れても良さそう。ウチは酒を飲む家じゃないので丸い氷を作る機材もないし、普通の角氷しか無いけど。氷の中に気泡が入っていると融解が進んだときに露出した気泡がnucleation siteになるから、透明な氷を洗って使うのが一番いいんだろうな。

/* 英語圏のYouTubeばっかり見てると語彙に日本語が無くて困る */

　ようこそ、氷マニアの世界へ。｜シャープ公式 note

「テレビが映らないんだけど」案件。この間のとは別のやつ。見に行ったら確かに電源が入らないので、別のあまり使っていないところからスライドして突き出したやつと交換。テレビが映るようになったことを確認して、その現場は終了。

　回収したテレビをウキウキで動作確認したら、映るでやんの。なんでぇ。。。せっかくバラして良いテレビが手に入ったと思ったのに。とはいえ、この際なので、蓋を開けて中身を確認。ちゃんと「高電圧があるから分解するなよ」のラベルが貼ってあるので、良い子は真似しないよーに。2010年製のテレビで、まだアナログチューナーが乗っていた時代のやつ。

　電源用の基板(低コスト化のために片面、絶縁のためにスッカスカ)が1枚と、メインの基板の合わせて2枚が入っていた(小さいやつも含めるともう少しある)。小さいスピーカーもファストン端子で接続してあったりして、保守性は良さそう(保守というよりは組み立て性メインなのかもしれないけど)。

　左上の黒いヒートシンクが映像処理用のロジックで、その左上にある小さいコネクタがLCDの映像出力。パネルはFHDだと思うけど、配線がめっちゃ少ない。シリアル通信偉大なり。中央右寄りの黒いICはHDMIのスイッチだと思う。背面に1個と側面に1個の合わせて2個のHDMI入力がある。配線はまっすぐ引いてあって、等長配線みたいなウネウネが無い。HDMI程度のクロックならスキューなんか気にしなくてもよい、みたいないさぎのよさ。

　右下にある2つ(写真はシールドを外した状態)がRF/IF入力のダウンコンバータ。写真では分かりづらいけど1段上げた場所に基板があって、ダウンコンバータは金属シールドに入ったモジュールとしてポン付けされている。大きい方がVHF/UHFのRF入力、小さい方がBS/110CSのIF入力。なーんか、安い中国製のチューナーに入っていた古いダウンコンバータと全く同じような構成で拍子抜けだ。この頃はまだVHFからUHFまでの広い範囲(90-770MHz)をカバーしなきゃいけないからRF周りは大変そうだな(地デジ化で周波数が整理されたあとは470-710MHzの範囲)。

　ただ、以前開けたダウンコンバータはPLL ICが見えたけど、今回はそれらしいICは見当たらない。もしかしたら水晶の裏あたりに乗っているのかもしれないが。水晶の横のピンにはシルクでSCLやSDAと書いてあるから、I2Cで周波数を指定できるのも前に分解したやつと同様。

　BS/CSのIF入力は、周波数が高いからか、かなりコンパクト。コイルみたいないかにもアナログフィルタみたいな部品が一切無い。どっかにSAWフィルタ位は入ってるんだろうけど。

　このテレビはちゃんと蓋を閉めて、正常に動いていることを確認して、突き出しの起点に設置。一件落着。

　Airspy R2をDLL経由で叩いて、ISDB-Tを受信するソフトを試作中。とりあえずISDB-Tのフレームに同期して、等価してからコンスタレーションを表示するところまで動くようになった。

　物理18ch

　このアンテナで受信できるチャンネルだと、このチャンネルが一番コンスタレーションがまとまっているかな。QAM64のカドも隣とかなり綺麗に分離できているから、内符号だけでほぼエラーフリーまで行けそう。

　ゲインを1段上げて、わずかに飽和した状態

　左中段のヒストグラムの両端に小さなツノが出て、ここがAirspy R2のADCで見える端。かなり狭い。

　少しでも飽和すると、コンスタレーションが急激に広がる。低い方で同じくらい広げようとすると4段くらい落とす必要がある。利得が低い場合は(量子化ノイズが問題にならない範囲では)振幅が低いだけで信号は保存されるけど、サチった場合は細かい信号が消えるからOFDMとしてはマズイんだろう。あるいは、正弦波がクリッピングされて高調波が出るから、キャリア間の直交性が悪くなる(ICIが悪化する)と考えることもできる。

　物理48,49,50ch

　弱いけど、フレームにロックできる信号が入る。

　A-PABのマップによると、可視範囲にこの周波数で出している中継局があるっぽい。ただ、送受信ともにビームが少しズレているからだいぶ弱い。ワンセグくらいは受信できそうではあるが。

　この場所は3chが並んでいるので、スペクトルで見るとガードバンドを挟んで左右端にも上下のチャンネルが見えている。この状態ではOFDMのガードインターバルの自己相関は3個のピークが出る。上の図では見づらいけど、中央のメインのピークの右側に2つのピークがある。GI自己相関の時刻精度はあまり良くないけど、長期的に位置関係を比較すれば、複数のchのクロックのバイアスが見えるかも? 比較精度としては数us程度だから2時間で9桁とか。受信機のスカートも含めると意味のある観測ができるとは思えないな。

　C#のDictionary、ContainsKey(TKey)と同じようにContainsKeyHash(uint)が欲しい感が若干。Keyの生成コストは高いけどKeyのハッシュ値はO(1)で取れる、みたいな状況で。まあ、そういう事態なんてほとんど無いから用意されてないんだろうけど。

　非unsafeなC#でDLLからポインタ経由でバッファを受け取ろうとするとMarshal.Copyで引っ張ってくるけど、こいつは基本的な型の配列にしかコピーできないのが地味に不便。非unsafe環境でnintからSpan<T>やMemory<T>にコピーできる機能があればだいぶ便利だろうに。unsafe環境ならポインタからSpan<T>を作れるから、基本的にはそれでいいんだろうけど。

　しかし、Marshal.Copyならポインタ/データ長を直接指定して(バッファオーバーランのリスクを犯して)使えるのに、Spanではそれが許されないのが謎。昔は許していたけど最近は許さなくなった、でも昔のやつは互換性維持に消すに消せない、みたいなことなのかな。

小ネタ

　Ghostwire: Tokyoを賑やかにしてVALORANTっぽいルックにした感じ?

　新ブランド「CONTOURJET」で立体物への直接印刷ソリューションを強化（2026年9月16日） | ニュース | エプソン

　多関節ロボットもインクジェットも作っている面白い会社の、面白そうなソリューション。

　エプソンのロボットは元々は時計の量産用に作ったものだそうで、製品を作る機械すら作るという極端な垂直統合は、いかにも日本の古い会社(いい意味で)という感じの。シチズンだって自分で工作機械まで作って(売って)いるからな。

　しかし、エプソンが人工水晶を作って半導体デバイスまでやっているのはわからんでもないけど(例えばXilinxはファブレスとして最初期の企業だけど、当初はセイコーに生産を委託)、インクジェットってどこから出てきたんだろう? 企業情報によると1968年には最初のデジタルプリンタを販売していたらしい。少し遡るとストップウォッチの記録(印字)のための機械も作っているらしいから、その流れなんだろうか? それにしても、数字を何桁か印刷するところから発展しすぎだろ。

　インクジェットプリンタの話だと、1990年代前半までのプリンタはとても写真に耐えられるような画質ではなかったが、エプソンが1996年に発売したものはかなり品質が良くて、それ以降の画質の向上がデジタルカメラの需要を牽引した、ということらしい。撮影しても印刷する方法がなければここまでデジカメが普及することはなかっただろう、と。

　東京オリンピックから続く挑戦、「より速く、美しく」｜大塚商会

　計算機の出力を印刷できるようになったのもこのあたりの時代かららしい。物理的な出力だともう少し早い時期からパンチカードや、印刷と同時期には磁気テープみたいな手法もあるし、一時的な出力でいいならダイヤルで表示するとかもできるけど、人間可読性の高いストレージ用だとプリンタがないと厳しそう。特殊な訓練を受けた人なら紙テープのビット列でも読めるんだろうけど、誰でも読めるという点では印刷はつよい。

　マウスコンピューター“異色の新ゲーミングPC”は初めての1台にちょうどいい。ノートPC向けCPUをあえて使ったデスクトップPC、性能と静音性両立の欲張り仕様 - AUTOMATON

　ゲーミングデスクトップを安くするというよりは、NUC PCを高性能化したようなコンセプトかな。せっかくモバイルCPUを使うならもうひと回りコンパクトな筐体にすればいいのに、と思わないでもないけど。あとは、うまいこと下駄履かせてデスクトップ用のファンを使えるようになっていれば面白そうだけどな。でもまあ、最初の1台向けなら拡張性とか考えてもな…… とすると筐体ももうちょっとコンパクトな方がよくねって気もするが。

　ちょっと前のWindowsって、一つのストレージでレイテンシが悪くなると別のストレージにも波及していたような気がするけど、いつの間にか改善している?

　うちのデスクトップPC、コールドデータを入れているのはRAID5のHDDで、書き込みは20MB/s程度しか出ず、数GBを超えてRAMでキャッシュできない量になるとHDDへのレイテンシが1秒くらいになる。その状態だとCドライブも引きずられて、PC全体のレスポンスも悪くなっていた。

　最近はHDDのレイテンシが1000msあたりでもCドライブ(NVMe RAID1)の平均応答は5ms前後で、PC操作の体感もかなり快適。あるいはチップセットの方でなにか更新が入ったのかもしれないけど、少なくとも自分はチップセット周りの更新は入れていない。でもチップセットが管理するストレージアクセスなんてWindowsでどうにかるものなのかなぁ……

　ビタビアルゴリズムってつまるところ巡回セールスマン問題的な最適化問題になるわけだけど(一筆書きで各都市を1回ずつ回るわけではなくて、一つの都市に何度も訪れたり、あるいは全く行かない都市もあって、n回の顧客訪問(nビットの探索)でいかに稼ぐか、みたいな最適化になるが)、最適化問題なら量子コンピュータで計算できんじゃね?と思ってググったところ、Quantum Viterbi Algorithm(QVA)というのが提案されているらしい。さもありなん。

　ただまあ、地デジ放送みたいな用途で使っている畳み込み符号は現行のCPUやASICで計算するのに苦労はないから、わざわざ量子計算する旨味はなさそうだけど。符号化率をめちゃくちゃ落として拘束長や出力を増やして誤り訂正能力を強めたような情報を復号したいならあるいは? でもそういう使い方って思いつかないな。劣悪な回線でも拘束長を増やすとかよりはビットレートを落としたり回線設計で頑張ってる気がする。あるいは最近の速度が必要な用途ならもっと効率の良い符号を使うとか。

　QVAは英語の論文がいくつかくらいで、概要もちゃんと読んでないけど、情報理論的な使い方ではなさそう。そもそもビタビアルゴリズムは「畳み込み符号の復調にも使える」というものであって、他にも色々な用途があるから、その方面を量子計算したいということなんだろう。

　フーリエ変換は、とりあえず10080pts固定で9x8x7x5x4に因数分解して処理するコードをベタ書き。かなり長くなったけど、とりあえず正しく動いているはず。

　Airspy R2でサンプリングした10MspsのISDB-T IQファイルを読み込んで、FFTで周波数スペクトルを取って、各種処理を行って、ビタビ復号からRS誤り訂正を経てTSファイルに保存して、ffplayに突っ込むと、とりあえずワンセグが見れる。以前NHKがスクランブルを解除して放送していたときに取ったIQファイルを突っ込むと、フルセグ相当の画質で再生できるから、ワンセグ/フルセグ含めて正しく復調できているはず。

　これで、IQファイルからTSファイルまで、フルスクラッチで書いたことになる(以前フルセグのデコードを行ったときはFFTとRS誤り訂正は外部ライブラリに依存していた)。

　ビタビ復号アルゴリズムは一旦実装してしまうとめちゃくちゃシンプルな感じ。ただし計算コストはめちゃくちゃ高い。リード・ソロモン符号は符号ベクトルにシンボル単位で行列演算を行うから、1バイトあたり計算何回、というオーダーだけど、ビタビ復号は1bitずつ何十個のパスを計算するから、少なくとも2-4桁は違うはず。

　いろいろ試していて気がついたことは、いくつかのシステムで、破損したTSパケットが含まれると全く動作しないものが多い、という点。デコーダの挙動としては、RS誤り訂正でエラーが残ったパケットに対してはヘッダの9bit目(同期直後)をセットしてエラーパケットであることを通知しているのだが、これが含まれると全く再生できなくなるシステムがある。

　書き出し時にエラーフラグがセットされたパケットは出さないような分岐を入れてやると、それまで再生できなかったアプリでも再生できるようになる。TSPの仕様でエラーフラグが明記されているんだから、TSPデコーダもこれをチェックすべきはずなのだが、実際にはフラグを見ず、壊れたパケットが入ると延々と伝播する(回復できない)ソフトが意外と多い。

　ffmpeg(ffplay)とVLCは204バイトパケットにも対応しているらしい。少なくとも、ffplayに204バイトTSPファイルを突っ込んでも、再生中にエラーログは出ない。ただ、あくまでも188バイトから余った部分を読み飛ばしているだけで、誤り訂正や誤り検出は行わないようだ。

　とりあえずフルセグが復調できたのは確認できたので、ワンセグに鞍替え。rtl_tcpでサクッとサンプリングして、1024ptsFFTで処理できるし、ビットレートも低いから、めちゃくちゃ楽にデコードできる(複雑な周波数インターリーブも無い)。

　ワンセグのデコードはCPU使用率5%程度なので、PC全体からすれば大したコストではないけど、12C20Tからすると結構ギリギリ。一番重いビタビ復号はマルチコアで分散しているので、おそらく問題はないはずだが。

　今回はTCPでIQ信号を受け取って、FFTからRSまで自前でコードを書いて、TSPをTCPでffplay等に渡すので、ISDB-Tデコーダはエンドツーエンドでフルスクラッチになっている。計算に使うバッファはあらかじめ確保したものを使うか、あるいはArrayPoolで使い回すから、動作中に大きなGCが走らない。メモリ使用量は70MB程度。ちょっと無駄に確保しているところがあるから、もう少し小さくなるはず。カリカリまで最適化すればもっと小さくなるんだろうけど。そもそもワンセグって20年前のガラケーで受信するための規格だから、かなり軽い。最適化していないデバッグビルドで余裕でデコードできる。

　頑張ればフルセグもソフトでリアルタイムにデコードできるはずなんだけど(確か前回ある程度は目処が得られるところまでやったような気がする)、フルセグはデコードしたところで意味がないから、あまり乗り気ではない。アマチュア無線用に? うーん。。。先にデコーダを書いて、それでデコードできる信号をfl2kで出せるようにエンコーダも書いて、みたいな遊びはできるか。

　ワンセグから復調したHE-AAC/H264の映像、ffplayで再生すれば問題なく再生できるのだが、VLCで再生すると映像は見える一方で音声が全く出てこない。

　ctrl-jのコーデック情報ではストリームがH264の1本しか表示されない。ffmpeg -i out.ts -c copy out2.tsみたいな感じで、コンテナの入れ替えすらせずffmpegを通してやると、正しく認識できる。ただ、-c copyを指定しても、パケット単位で中身を比較すると、同じ内容のパケットはかなり少ない。ペイロード(184バイト)が完全に(ビット単位で)一致するパケットは0.5%程度しかないし、それにしたってPIDは一致しない。-c copyで再エンコードさせずにコピーしても、例えばPIDを振り直したり、パケット区切り位置が移動したりはするらしい。

　VLCに関しては、たぶんVLCが解析するサイズが小さくてストリームを検出しきれず、かつ最初に検出したストリームを拾い続けるからあとからストリームが入ってきても検出できない、みたいな感じなんだと思う。最初の方にインターリーブの都合で破損したパケットが入るが、それでデコーダが破損してその後延々回復できない、みたいな問題も似たようなところだと思う。

　VLCで再生中にストリームの再検出を行う機能があればいいんだが、見当たらない。Google AI曰く「あるよ」とのことなんだけど、その項目が見当たらない。バージョンの問題なのか、ハルシネーションなのか。AIが提示したCLIオプションをググっても全くヒットしないから、後者だと思う。

　ffplayでtcpからストリームを受信すると、デフォルトでは再生が始まるまでものすごい時間がかかる。かなり巨大なバッファが埋まるのを待ってからフォーマットの解析を行っているんだと思う。probesizeで20k位を指定すると半々くらいの確率で音声だけの場合と、音声・映像の両方が出る場合がある。30kくらいだとまだ映像が出ないことがあって、40kだと100%正しくデコードできる。ワンセグは416kbpsだから、40kBだと0.77秒、30kBだと0.58秒、くらい。1Hzや2Hzでフォーマット情報を出しているわけではなさそう。

　ffplayで映像が検出されない場合、しばらく待っても検出されないから、リアルタイムでパケットを解析してストリームが追加されたらそれもデコードする、みたいな機能は入ってないっぽい。最初に認識したストリームだけをデコードするのはffplayもVLCも同じかな。

　ffplayは正しく検出できない場合、音声だけが出る。VLCは正しく検出できない場合、映像だけが出る。この違いは何なんだろう?

　ワンセグをデコードしてffplayで画面の片隅にNHKあたりを置いておくと、何か大きな出来事があったときにffplayをクリックしてmでミュートを解除するだけですぐ見れるから、報道で最新のニュースを知りたいみたいな場合は便利そう。IP経由でNHKを見ると50秒くらいの遅延があるけど、ワンセグならrtl_tcpからffplayまでエンドツーエンドでも2,3秒程度しかない。まあ、テレビ経由で情報を入手するのに3秒も1分も大差ないだろ、という気はするけど。

　どちらかといえば常時つけっぱなしにできる方が便利かな。この程度の機能ならPC用のチューナーをつけるとか、あるいはウチはDIGAが置いてあってDiXiMのライセンスも買ってあるから、フルセグをリアルタイムでPCで見るみたいなことは可能だけど、機能が豊富だと必ずしも使いやすいわけではないので、常時表示しておくなら単機能のワンセグだけという割り切りは意外と便利かも。

　気まぐれでGoogle PixelのLinuxターミナルをPixel 6aにインストール(開発者向けオプションのやつ)。apt searchでいくつか検索。build-essentialは12.12、python3は3.13.5-1、default-jdkは2:1.21-76、nodejsは20.19.2、あたり。AndroidにLinuxターミナルを追加したはいいけどその後保守されてない、って感じのバージョン感。開発環境として使おうとするとだいぶ厳しそうだな。FFmpegは7:7.1.5-0が入っていて、リリース日で言えば3ヶ月前だけど、とはいえ7.1のリリースは'24年9月だからなぁ(現在の最新は9.x.x系)。

　あと、gr-osmosdrが0.2.6-4で最新のリリース(2024年)とairspyが1.0.10でこれも最新版(2021年)が入ってるっぽい。rtl_tcpでUSBからTCPに変換して、ユーザーアプリからTCPで接続して、みたいなことができれば面白そうだが、とはいえ開発環境が実質的にC++しかないのはちょっと面倒。C#が走れば色々楽なんだけどなー。airspyに関しては、rtl_tcp的なツールがないから、ライブラリを自分で叩かないとだめなのかな。fl2kもあるけど、0.1.1で、8年前のリリース(最新は去年の0.2.1)。

　試しにrtl-sdr 2.0.2-2+b1を入れて、blog v3を接続してからrtl_testを叩いてみたけど、No supported devices found.でダメだった。最近のスマホはセキュリティが厳しいからUSBデバイスを使うのは大変そうだ。

　build-essentialを入れて、C++の適当なコードを/mnt/shared/Downloads/hoge/a.cppに書いて、同じ場所にa.outを作って実行すると、少なくともhello world程度は正しく動作する。ただ、Ubuntuで動くTCPクライアントを実装しても動作しない。printfは出るからバイナリは正しく動作しているはずなんだけど。ネットワークを超えようとすると厳しいかな? なにかパーミッションとか必要なのかもしれないけど。開発環境でTCPが使えてもなぁ……という感もあるので、当面放置。

　Google Pixel、6aと9aを並べていると、いくつかのアプリのプッシュ通知で、明らかに9aが遅い。6aはWiFi運用、9aはSIMカード入りで、9aは低消費電力化のためにスリープ時はWiFiではなくモバイル回線でプッシュ通知を受けている、みたいなことなんだろうか?

　Complex<T> 構造体 (System.Numerics) | Microsoft Learn

　.NET11(C#15)から使えるようになるらしい。現状のソースだとTにIFloatingPointIeee754<T>条件が指定されているし、shortとかintやInt128が使えるようになるわけではなさそう(SDRer的には閉じていなくてもいいから幅の狭い整数系の複素数が使えると自分で書かずに済んで楽ができるのだが)。今までのSystem.Numerics.Complexはdouble型(128bit幅複素数)固定だったものが、float, Half(fp16), BFloat16(bf16)にも対応するようになった、という感じなのかな。今まで64bit幅複素数(単精度)を使おうとするとNuGetでMathNet.Numericsを入れる必要があった。

　Halfって構造体で定義してあるし演算重そうと思って触ったことないけど、実はそんなことないんだろうか? それともComplex<Half>で特殊な対応が入ったりするんだろうか? あるいは、新しいCPUならハードウェアで計算できますよ、ということなんだろうか。少なくとも、Intel Core系ではfp16演算はサポートされていないはずなのだが。計算はXeonのAVX-512やあるいはNPUが必要。あるいは、fp16/fp32変換はサポートされているから、言語レベルでサポートを入れれば、fp16演算の前後で変換を行ってfp32で計算する、みたいなことはできる(fp16ネイティブ演算とfp32変換計算で同じ結果になるのかはわからんが)。

　fp16/bp16とか色々と特殊な型が増えてくると、CPUの中に小さいFPGAを入れて、ちょっとした特殊な演算はハードウェアでできれば便利じゃねって気がするんだけど、でもFPGAだと速度も電力も専用計算機には足りないし、使い所が無いんだろうな。変な型の演算をやりたくても、一旦普遍的な型に戻して通常のALUで計算させたりとかすれば大抵は事足りるわけだし。/* なんかこんな話ちょっと前にも組み込みマイコンで書いた気がする */

　モノブリスクターボファンエンジンの空想の続き

　ブリスクの断面のイメージ。左から右に向かって流れる。青がファン、緑がコンプレッサー、赤がタービン。ブリスクのFCTの並びで6種類、コンプレッサーのインテークで2種類、合わせて12種類のバリエーションが有る(増やそうと思えばもっと増やせるけど)。Aはファンの排気をコンプレッサーに入れる(2段圧縮)、Bはファンとコンプレッサーのインテークが独立(1段圧縮)。コンプレッサーに入る気流は180度曲げる必要があるから、ファンで軽く圧縮した気流を入れたほうが良さそうな気もする。

　軸受をどこに置くかで高温部の配置も変えたほうが良さそう。小径ベアリングでシャフトを支えるならタービンが外側(4,6番)のほうがいいし、大径ベアリングでブリスクを囲うならタービンが内側(1,3番)のほうがいい。中間に置けば(2,5番)中庸な特性になる(例えばシャフトと外周を両方ともインターフェースに使いたい場合)。

　気流が交差すれば当然ダクトも交差させなきゃいけないから、図中で交差せずに流せるほうが楽なはず。これを強い拘束条件に設定すれば、1A, 5B, 6Aが選択肢になる。高温部を好きに選べるから、材料の特性で選ぶこともできる(耐熱性はあまりないが熱伝導性がいいなら両側から冷却できる5B、とか)。

　上の図の場合、タービン排気は後ろに出すから、排気の残エネルギーを比較的効率よく推力に変換できる(前回空想時点では圧縮機/燃焼室が前後逆だったから、タービン排気をダクトで後ろに向ける配置だった)。あと、コンプレッサーの吸気が180度曲がるから、適当なスリットを入れておけば簡易的なパーティクルセパレータとしても使える。もっとも、最大でも30分程度しか回さない使い捨てのエンジンにそこまでの性能を求めるかはまた別の話(600km/h程度で飛ばしたとして30分も回せば300km先まで飛べる)。

　図は単純なターボファンエンジンだが、実用的に使う場合はスターターやジェネレータもあると良い。電動モーターで起動する場合は可逆に使えるからスターターとジェネレータを共有できる。特性の良い電池を併用するなら、巡航中に発電した電力を終盤にモーター経由で戻して、ブースタとして使うこともできる。圧縮に余裕が出るからより多くの燃料を燃やせる。ただ、バッテリ重量とのトレードオフになるから、必要最小限の電源だけ用意しておいて(起動は外部電源で行って)、ブースタとしては使わないほうがパフォーマンスは良さそう。とはいえ、可変ステータみたいな凝ったものを作れないから、電力の流入・流出で負荷特性を調整できるジェネレータ・ブースタはうまく動けば利点はありそう。

　シンプルに考えればモーターを別に用意してシャフトからカップリングすればいいが、場合によってはブリスクの外周に磁石を並べて、その外側にコイルを配置して、ブリスク自身をローターのフレームとして使うこともできる。

　ただ、できるだけシンプルに(低コストで)作ろうとした場合は、スターター・ジェネレータは搭載せず、起動は外部からの圧縮空気で、飛行中の電源はLIBで、みたいなことも考えられる。どのコンフィグが有利かは量産性や部品コスト等色々と複雑なので今回は気にしないことにする。そもそもモノブリスクターボファンエンジンという空想が実際に可能なのかどうかもわからないし。