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で、みたいなことも考えられる。どのコンフィグが有利かは量産性や部品コスト等色々と複雑なので今回は気にしないことにする。そもそもモノブリスクターボファンエンジンという空想が実際に可能なのかどうかもわからないし。
