2025年11月12日水曜日

小ネタ



 米軍のミサイル防衛とかの、特に地上ドメインの話。

 巨大なレドームの中身、1970年代にフォードが建設した巨大なパラボラアンテナ(より正確にはカセグレンアンテナ)。毎日2回の定期メンテナンスはかなり悲惨な気がするけど、まあ、半世紀も前の機械ならな。。。

 '70年代のテクノロジーでこの大きさって、どれくらいの帯域を考えてたんだろうか。かろうじてXバンドに届くかどうか、くらい? フィードホーンは中央に四角錐形が1本と、その周囲に円錐形が8本。8本は中心からかなり距離があるから指向性はだいぶ悪そうだが。

 カセグレンアンテナは1960年に論文が出て、三菱電機が数年後に設置したものが最初期の実用例のはず。そこから10年で米空軍に使われているってことは、結構早く実用化・普及したのかな。

 それにしても、西側諸国が大なり小なり依存するミサイル防衛システムの機材が50年落ちか…… この施設だって他にも設備はあるし、別の施設もあるだろうから、半世紀前のシステムがSPOFになっているわけではないとはいえ。



 なぜ『Ghost of Yōtei』のアクションに飽きるのかといえば、それは本作が「映画的に素晴らしいゲーム」だからではないか IGN.jp

前作『Ghost of Tsushima』はプレイヤーがいかに武士の誉れを守っていたとしても、毒殺・暗殺でもなんでもするロクデナシのように扱われていた。結局のところ、リニアなストーリーにおいてプレイヤーに選択の余地はないのである。

『Ghost of Yōtei』はアクションゲームの部分も映画的である。本作は二刀や槍などの武器がいろいろとあるのだが、どれを使うか選べるのではなく、敵に応じて相性のいいものを選ぶといったものになる。選択肢があるのではなく、選ばされるのだ。

 デスストとかもな。どちらもソニーの独占タイトルだけど、なにか関係あるんだろうか。グループ内にソニー・ピクチャーズがあるから映画的なゲームが喜ばれるとか、本体性能的に綺麗な絵や特徴的なゲームシステムを作りやすくて、その方向に縛られるとか。

 Xboxでも売ろうとするとPCでも売りたいよねみたいな話になるだろうし、最初からマルチプラットフォームで売るならマシンスペックの最小構成はある程度引き下げざるを得ないし、そうすると綺麗な絵とか高性能なハードウェア(NVMe前提とか)に依存しないゲームシステムとかが必要になって、プレステ専用ゲームとは違った方向性になる、というのは有り得そうではある。

 まあ、ハードにかかわらずクソゲーなり、クソゲーのなりそこねなり、不満点のあるゲームなんてのは掃いて捨てるほどあるからな。その中から適当に2個選んで共通点を探すってのは簡単な事だ。



 Glyphica Typing Survivalのビーム、うまく成長させて最終面に入ると全自動で迎撃されるから一切入力しなくていい。他のモードでもタレットをうまく成長させればかなりヌルゲーになる。ゲームとしてはちょっとつまらん。

 各メイン武器で最高難易度まで全部クリアしたけど、特に実績解除はないんだな。未実装のモードが1個あるからかな? 普段あんまりテキストを入力しないというのもあるけど、普段は肩が凝ったりとか全然無いのに、このゲームをやるとかなり肩が凝る。


 久しぶりに寿司打をやったら60位台まで行けた。その次は300位台だったのでまぐれ当たりっぽいけど。寿司打は文字列を認識するのに時間がかかるからそこがボトルネックになるんだよな。あとは単純に誤字が多いというのもあるし。



 先日ちょっと長めの停電があって、UPSの稼働時間が15分を切ったのでPC周り全体をシャットダウン。その後しばらくして復旧したので、PCを起動。1時間程度停電していたかな。最近は瞬断はまれにあったけど、数分を超えるような停電はかなり久しぶりな気がする。

/* このブログも長く続けていて居住地とかももう隠してもしょうがないけど、停電情報って電力会社によっては番地単位でアーカイブ・公開されるので、不用意にSNS等で書くと(特に発生時刻)、局所的な停電だった場合は1発でもかなり狭い範囲に特定できてしまうのよな。事前の推定値(都道府県単位)がある場合は特に容易に探せる可能性がある */


***


 RDS(Radio Data System)を含むFMステレオっぽいIQファイルを作ってSDR#に突っ込む遊び。

 RFスペクトルの左上付近に色々と表示される。

 (((と)))の記号はステレオであることを示す(例えばRadioパネルのStereoチェックを外してモノラルとしてデコードすればこの記号は消える)。

 ステレオの中に入っている"ABC123  "のはProgramme service nameと呼ばれるもので、これは放送局の名前やコールサインを表示することを目的としている。8文字を表示可能。動的な変更は想定しておらず、基本的には固定の文字列を表示するのが目的。

 その右側の1234(16進)はProgramme Identification codeというもので、放送局を識別するために使用される。国コードや国内で一意な放送局コードが含まれ、自動再選局を行う際に使用する(国コードは一意ではなく、放送範囲が重ならない範囲で再使用される)。一部の放送局では地域ごとに違うCM等を放送する際に、一部のビットを変更して、異なる放送を行っている放送局・中継所に再選局しないようにしている。

 一番右側の文字列(小文字のa-z)はRadioTexitで、最大64文字または32文字を表示できる。本来は大文字を含む一部の文字セットだけを使用できるが、SDR#ではASCIIの印字可能文字の大半を使用できる。任意のテキストを表示することができるが、運転中に注視すると危険なのでカーラジオでは表示しない場合も多いらしい。そのせいでProgramme service nameを動的に書き換えるような放送局が出てくるらしい。



 RDSの変調は結構面倒くさい。副搬送波周波数は57kHz(3xパイロット)、シンボルレートは2.375ksyps(副搬送波周波数/24)、ボーレートは1.1875kBd(シンボルレート/2)、フレーム構造は1ブロックがデータ16bit+CRC10bitで、ビットレートは約731bps、ブロックレートは約45.7blocks/sec、1フレームは4ブロックでフレームレートは約11.4frames/sec、となる。情報の最小単位は1フレームで、局番号1ブロック、ヘッダ1ブロック、データ2ブロックなので、1フレームあたり2ブロック(32bit)のデータを送れるから、1フレームあたり4文字、1秒あたり45.7文字程度の情報を伝送できる。

 誤り訂正はCRCで行い、1ブロック(16bit)単位で処理する。CRCにはブロック番号を識別するためのビット列がビット加算される。仕様上は最大5bitまでのバースト誤りを訂正できる。

 ビット列のエンコードは、CRCを付加したビット列を、NRZI符号化し、さらにそれをマンチェスタ符号化するという手順を踏んでいる。これは受信した信号から比較的容易にクロックリカバリを行ったり、ビット反転対策を簡略化するためのエンコード方式だと思う(今回は変調しか行っていないので、復調が容易かどうかは未確認)。


 日本でデータ放送のFEC周りをやっていた人が、RDSは転送レート低いし誤り率も高いから使い物にならん、みたいなことを言っていたけど、まあ、わからんでもない気がする。

 そもそもRDSは元々はページャ用として1970年代中頃にフランスで開発されたシステムを流用したものだから、その当時の超小型受信機で復調できる程度にシンプルである必要があって、非常に長いインターリービングとかは不可能だったわけだから、しょうがないといえばしょうがない部分もあるんだろうけど。/* DARCは1990年代中頃に開発 */

 あとは、3xパイロットの場所は別の用途(独ARI)で使っていたから、スペクトル的に分離したいということでマンチェスタ符号を使ってずらしていたのかもしれない。ARIとRDSは直交変調してはあるけど、当時の技術水準で直交復調できるかどうかは怪しいし、スペクトル的にも分離してそうな気がする。


 RDSで文字データを転送する場合、1フレームで2バイトもしくは4バイトを転送できる。一応、近代的な仕様ではUTF-8を使うことになっているはずだが、少なくともSDR#ではASCII文字範囲しか使えない。古い仕様ではASCII文字範囲の一部のキャラクターしか使うことができないが、SDR#ではその範囲外の文字も使用できる。

 SDR#でRadio Text(RT)を受信した場合、文字列は順不同でいいので、任意の表示位置の文字列を送ることができる。例えば歌詞や字幕を放送する場合、2つ後ろのブロックに空白(4x 20h)を送っておけば、古い文字と新しい文字の間に空白があるので読みやすくなるが、もちろん転送レートは半分に低下する。



 周波数変調せずに保存した場合

 L+RはDSB-SCで復調すればそれなりに聞こえる。エンファシスが効いているのでキンキンした音になる気がするけど。±19kHzにパイロット信号、±38kHzにL-R、±57kHzにRDSがある。RDSのサイドローブがかなり高いのでL-Rにも結構入りそう。

 285kspsだからRDSの副搬送波は5サンプル/サイクルで、時間分解能が悪い。それで繰り返しスペクトルが強く出ているんだと思う。サンプリングレートを上げれば改善するはずだけど、計算コストの問題が出てくる。



 fl2k_file.exeはバイナリファイルから8bit1chのデータ列として読み出してFL2000に出力するけど、int8_tとして扱っている。一方で、WAVファイルは8bitの場合uint8_tとして扱わなければならないので、fl2k_fileは1ch8bitのWAVを読ませることができない。せめて符号のフラグをコマンドラインオプションで指定できればよかったんだけど。



https://www.denso-ten.com/jp/technicalreview/jp_pdf/17/17-1J.pdf

 あとで見つけた資料。ちゃんとNZRIとかBPSKとか色々書いてあった。。。

 欧州の状況。ドイツではアウトバーンが整備されていて、短時間で受信状況が大きく変化する。スイスは山間を縫う道路によって受信状況が変わる。ノルウェーではフィヨルド地形のために受信状況が変わる。周波数の自動変更が重要になる。

 この当時のデンソーの受信機では誤り訂正は使っていないとのこと。5bitまでのバーストエラーしか処理できないから、実環境で発生するエラーには対応できないし、無理に誤りを訂正しようとするとよけい間違った情報を得る場合がある。クラシックを聞きたいドライバーにロックを聞かせたりすると危険だから、誤ったデータは捨てたほうがマシ、みたいなことらしい。



 試しにJ-Stageでポケベルを探してみたら、いわゆる文系的な論文がほとんどでちょっと驚く。それ自体をハード的に研究・改良する話は全く押し流されて、すでに過去の物として研究の対象になっているんだな。あとは医療とか緊急対応みたいな分野の例とか。

 そもそもポケベルは携帯電話よりも前のデバイスだから、j-stageに残るほど最近の話ではないということなのかもしれないけど。


https://www.jstage.jst.go.jp/article/nihonkindaibungaku/107/0/107_109/_pdf/-char/ja

「電話と文学」という本の書評。文学作品の中で電話機がどのような状況を表現しているのか、みたいな話。

 この書評の最後に著者が少し書いている、ケータイ小説の話が面白い。1行が短くて改行の多いケータイ小説は携帯電話のディスプレイに由来するものだろうが、会話口調を主体としているのは携帯電話の電話機という機能の名残ではないか、という指摘。


***


 試しにΠ型アッテネータ&整合器について調べてみた。

 減衰量が十分に大きい場合、R1=ZS、R3=ZLとして、R2を適当な値に選べば、インピーダンス変換を行いつつ数十dBの減衰量を持つアッテネータとしても使える。E12系で75Ωと50Ωを変換する場合、75Ωと51Ωでそれぞれを終端してやって、その間をR2=10kΩ程度で弱く結合してやれば、双方から見れば適切に終端されて反射が起こらないし、R2を経由して弱い信号が通過するから、アッテネータとしても作用する。R2が小さい場合は合成抵抗の成分として無視できなくなるので、終端抵抗を大きめに設定してインピーダンスを合わせる必要がある。


 R1=ZS, R3=ZLの状態でR2を変えた場合の、双方から見たインピーダンスと減衰比

 基本的には合成抵抗の計算を行えば済むんだけど、並列に組まれた抵抗が多いので逆数だらけになる。Excelとか関数電卓で計算するのは、不可能ではないにしても、とても面倒(このグラフも正しいのかは怪しい)。

 75Ω側はR2=10kΩを超えたあたりで、50Ω側はR2=2kΩを超えたあたりで収束する。それより低い抵抗値だとインピーダンスが下がる。

 減衰比は双方向で対称ではなく、75Ω信号源/50Ω負荷の場合と、50Ω信号源/75Ω負荷の場合では減衰比が異なる。普通はインピーダンスの違うシステムを双方向で信号を出して使うことはないだろうから、問題ないはず。双方向で使う場合でも、減衰比40dBに対して差が3.5dB程度だから、大きな問題にはならないはず。

 R2=2.4kΩで75Ω信号源50Ω負荷に39.8dBあたりがちょうど良さそうかな。あとは8.2kΩで50.3dB、24kΩで59.6dB、68kΩで68.6dB、とか。750Ωで30.2dBはインピーダンス(特に75Ω側)が若干ずれる。75Ωと50Ωを直結するよりはマシ、程度ではあるけど。


 R1, R3を適当に調整した場合(上の図と軸の取り方が違う点に注意)

 E12(というか秋月で売ってる全部入りのラインナップ)だと調整の選択肢がほとんど無い。


 ちなみに、R1, R3には合成抵抗(2本直列or並列)も含めて、全種類の抵抗からグラフにすると、こんな感じ

 R2は合成抵抗にはしていないが、単に横方向の間隔が狭くなるだけなので、グラフとしては大して違いはない。

 下のグラフにはR1, R3も表示している。R2が100Ω未満の場合はR3が発散するので省略している。



 L型アッテネータ&整合器の場合、全部入りを単体で使う場合はRa=47ΩとRb=75ΩでZ1=77.0ΩとZ2=46.5Ωを作って8.1dBと4.6dBを得るような組み合わせしかない(Zを多少広めに設定するともう少しある)。

 RaとRbに合成抵抗を使えば自由度は増えるけど、とはいえL型の場合は2個の抵抗で2箇所のインピーダンスを制御するから、減衰比の自由度が無い。減衰比を自由に設定したいなら抵抗を3個使って変数を増やすしかない。



 Π型整合器/ATTを試作

 SMAコネクタに、51Ω、75Ω、2x1.2kΩの合わせて炭素皮膜抵抗4本と、0.1uFのセラコンで、整合とATT、DCブロック。ちょっとかさばる。

 Z=Rだから入力の大部分を1本の抵抗で消費するので、今回使った1/4Wの抵抗の場合、ディレーティングを考えると100mW程度が耐入力ということになる。正弦波なら2.2V RMS、矩形波なら2.2Vppあたりが上限。


 fl2k(50Msps)で1-15MHzの正弦波をスイープしてFFTのMax-Holdで測定

 ↑75Ω終端で直結

 ↑Π型で整合/-40dBと50Ω終端

 ↑75Ω直結とΠの差。設計通り-40dBの差がある。

 インピーダンスが正しく変換できているかはわからないけど、まあ、多分大丈夫だろう。とりあえず、見える範囲では振幅が暴れることもないし、変な共振もないはず。元々はアッテネータが欲しかっただけなので、インピーダンスマッチングは二の次というか、おまけみたいなところもあるし。


 そもそもR820Tの耐入力って+10dBmまでだから、VGA(Video Graphics Array)信号ならギリ直接突っ込めるんじゃね?という気がしないでもない。あまりにも余裕がないから念の為にATTを通しておきたい、というのはあるけど。それにしても-40dBは減衰させすぎな気もする。弱い信号をVGA(Variable Gain Amplifier)で頑張って利得を稼ぐ感じか。

 R820TのVGAは50dBくらいまで稼げるから、もし40dBのATTを通してVGAを40dBにしてサチらなければ、VGA信号を(AC結合程度で)直結できることになる。あるいは、L型でインピーダンスを合わせて数dB落とすとかも考えられるし。そのあたりは実際に試してみないとわからないな。


 だいぶ寒くなってきて、もうしばらくしたら積雪が始まるはずなので、それまでに外に出していたアンテナを1本回収しなければ。そうすればrtl-sdr blog v3ドングルが1本フリーになるので、fl2kと接続して遊んだりできる。

 SDRドングルに余裕がないので、R820T系受信機もう1個くらい買っておきたいんだけどなー。v4を買うか、R2を買うか、miniを買うか、といったところが悩みどころ。待ってたらそのうちAirspy系の新製品が出てR2やminiが値下がりしないかな、みたいな願望を抱きつつ。



 抵抗器の誤差の分布ってどういう形になっているんだろうか、という疑問。普通に考えると正規分布だけど、抵抗器の誤差の積極的な使用(ラインナップにない値を誤差の範囲から拾ってくる)を考えると、一様分布でもいいはず。しかし、ググってもいまいちよくわからない。


 ズバリという記事ではないけど、面白い話

 誤差5%の抵抗の作り方:Signal Integrity - EDN Japan

 1980年代頃の話。±10%の抵抗から±1%の個体を探そうとしたら、1個も見つからなかった、という内容。推測だが、比較的山裾の広い抵抗器を作って(というか当時の製造技術ではその範囲の誤差しか作れず)、実測で±5%に入るものは5%品として売り、±5%を超えて±10%に入るものは10%品として売っているのではないか、と。この話が本当なら、例えば±5%品の中には±1%の個体は入ってなくて、±1%品の中には±0.5%の個体は入っていなくて、みたいなこともあるんだろうか(精度が高いやつは炭素皮膜でなく金属皮膜だろうとかの話は置いておいて)。

 そうやってラインナップを作る場合、E12系列や24系列、96系列の違いは何なんだろう? 例えばE96の51.1Ω±0.5%はE12の正規分布の個体から選ぶことはできないわけだし、前述のような使い方を想定するならなおさら正規分布は困りそうな気がする。


 工学部の学生です。レポートの課題で、抵抗の誤差を示すカラーコードがたとえば±5... - Yahoo!知恵袋

 ここの回答でも似たような話が書いてある。昔は製造品質が良くなかった(分布が広かった)から中央を抜き出して高精度品として売っていたが、最近は品質が安定してきたから、グレードに合わせて製造する(中抜しない)し、そもそも5%品でも実測2%程度に収まる、という話。


 とりあえず抵抗器の誤差は正規分布に収まると考えていいのかな。で、最近は誤差が狭くなっている、と。

 じゃあ中途半端な抵抗器が必要な場合、5%品から探そうとしても、最近のラインナップだと中間の値が得られないみたいなこともあるんだろうか。とはいえ、昔の抵抗器だって中抜されているんだから、5%品から1%品を探すみたいなことはできないわけだが。ということは何かね、E系列が中途半端に並んでいるのは、誤差の範囲から必要な(系列のラインナップにない)数値の抵抗器を選べるように、というよくある説明自体が今も昔も誤りということかね?

 あるいは、±5%の正規分布の抵抗器は、±5%ギリギリの個体はかなり少ないことを期待しているけど、昔の中抜品の場合、±5%ギリギリの個体はかなり多かったんだろうか?

 結局、5%の抵抗器を想定するならしっかり5%品で動作する設計を行え、精度が求められるなら1%や0.5%の製品を指定しろ、という話に落ち着くのか。



 Excelの散布図の近似曲線って、完全に水平な線を書くと非表示になるんだな。何だこの制限。。。内部の計算が発散してるとかなんだろうけど、基準値を書きたいときとかに水平の近似曲線って便利な気がするんだけどなぁ。近似曲線の元になった列の線を細くして点線にするみたいな感じでもいいけど、色々調整するところが増えると忘れる可能性が増えるので、近似曲線のほうが使いやすい。のだが。。。

 近似曲線を書くときに微妙な傾斜を与えておけば表示されるけど、水平に近づけていくと先端から描画が消えていく。一部だけ消えるということは、フィッティングが発散しているのとはまた別の現象なのかな?


2025年11月5日水曜日

小ネタ





 Pocket Mill|小スペース用CNCミル|垂直ミル‐Haas CNC機械

 40テーパー、単相電源で使用できて、ベースモデルは25kUSDから、必要に応じてオプションでATCや5軸も対応。

 ベースモデルでSYIL X5と比べれば確かにPocket Millのほうが安いけど、とはいえ向こうはATC標準搭載だからなぁ。色々オプションを積むと40-50kUSDくらいは行きそうだし。とはいえ、ベースモデルを25kUSDで買ってガレージに置いて、物足りなくなったら後からオプションを追加して、それでも足りないなら、Pocket Millを中古で売って大型の機械(VFとか)に買い替えた場合でも、ツールホルダを含めた工具や操作感が共有できるのは、小さいショップから始めて拡張していけるという点では面白そうではある。Haasの小型な機械は30テーパー(CompactMillは20テーパー)の製品もあるから、低価格化をアピールするなら30テーパーとかで作ってもいいはずなのに、そうしなかったということは大型機への移行も考えてそうだな。

 DesktopMillが10kUSDだからPocketMillと性能差の割に値段差がほとんどないけど、DesktopMillの方は教育機関みたいなところでいくつも並べるような使い方を想定しているだろうしな。




 猫背のエンジニア。

 蜘蛛型のロボットを投げて、敵を発見したらネットランチャーで拘束する、ってのは面白いけど、しかしなぜ6本足なのだ…… 蜘蛛というからには8本足でないと。構造が複雑になれば故障率も上がるけど、とはいえ6本足→8本足なら冗長系が増える分で利益が大きそうだが。消費電力とかコストはともかくとして。

 エンジニアだし正面から撃ち合ったら打たれ弱い感じかな。そのわりにサポートとしても中途半端な気がする。あまりガジェットを有能にすると偵察と競合するんだろうけど。『ナショナル・トレジャー』のハッカーみたいな雰囲気だけど、彼ほど有能でもなさそうな感じ。DFの世界観じゃハッキングして使えるアセットもあんまりなさそうだしなぁ。偵察衛星とかSAMとか色々ありそうだけど、ゲームバランス的にねぇ。



 大口径光学アンテナ合成開口実証(OSCAR-J)プロジェクト|JAXA|研究開発部門

 JAXA、MELCO、NAOJで分担して、副鏡および主鏡2枚(全6枚中)の1/1スケールを作成し、検証。

 これ、合成開口かぁ? 強いて言えば開口合成、一般的には普通の分割鏡望遠鏡では?

 これから高性能かつ大規模な地球観測(Opt/SAR)コンステレーションが構築されるであろうことを考えると、この手の観測衛星の必要性は提案当時から比べるとかなり小さくなっているけど、とはいえ他の目的に転用できるのが強みよなぁ。外に向ければ大口径の天体観測衛星として使えるし、地球以外の惑星(コンステが構築されていない場所)で使うことも考えられるし。とはいえ天体観測衛星で使うのはともかくとして、地球以外の惑星で何に使うんだよ、という話ではあるけど。

 姿勢の自由度を増やしておいて、例によって2,3機を日本付近の静止軌道に入れておいて、平時は最低1機を地上観測用に、予備機は外に向けて天文観測に使って、地上で大きなイベントがあれば全部地上に振り向けて、宇宙で大きなイベントがあれば可能な限りそちらに振り向けて、みたいな運用をやっても面白そうよな。回線設計をうまくやれば、常時高速通信で接続して、地上の状況だけでなく、天文現象もリアルタイムの動画を降ろして、珍しい天文現象が起きたらYouTubeで配信したりも考えられる。重力波望遠鏡で見つけた超新星爆発の映像をリアルタイムにYouTubeで配信する、とか。あくまでも地球観測衛星がベースだから精密な天体観測に使えるものではないだろうけど、とはいえひまわりで金星の気象を長期的に把握したりとかもしてるしな。十分に低コスト&気軽に使える光学系が宇宙にあれば天文屋も使うだろうし。NAOJが噛んでるのも、共有するにしろ新造するにしろ、宇宙用の分割鏡望遠鏡が作れるか検討したいってことだろうし。

 作るならDS2000ベースだろうけど、DS2000って外宇宙を見れるほど振り回せるんだろうか。QZSでヨーイングはやってるけど、それにしたって地心指向であることに違いはないし、地心以外に向ける運用はDS2000ではやってなさそう。気象衛星だと放熱面の太陽角の問題とかもあるだろうけど、静止光学衛星の場合は分解能を稼ぐために短めの波長を使うはずだから、冷却はさほど問題ではなさそうな気もする。鏡の精度が得られなくて結局長めの波長になる可能性もあるけど、いちおうJWSTで使っている長波長側ではなく世界初となる可視光を目指しているわけだし。問題があるとすれば通信周りだろうけど、緊急用のテレコマはオムニだろうし、ある程度のボディポインティングは前提だし、通常はミッション用の超広帯域回線を使う前提なら、最初から外側を向けるように設計しておけば問題はなさそうな気もするな。イラストだと大型のパラボラアンテナを積んでるけど、これだとボディポインティングも難しそう。できればオーストラリアとかの晴天率の高い場所に光地上局を置いてもらって光で直結できれば嬉しい。光開口ならあまりかさばらないから地球側と反地球面に置いて内側も外側も向けるようにとか、あるいはうまくやればジンバリングで1個の開口でも成立するだろうし。



 新作TPS『ARC Raiders』は、“『Escape from Tarkov』が難しい”と感じるプレイヤーも遊べる脱出シューターだった。ヒリつきは残して課題を解決 - AUTOMATON

 個人装備はソ連みがあるな。

 ゲームシステムは面白そうだけど、西側の現代的な装備が好きなので、世紀末っぽかったり未来っぽかったりファンタジーっぽかったりソ連っぽかったりするゲームはあまり触手が伸びないな。


 数日毎に1回30分くらい遊んで楽しいゲーム(FPS/TPS)ってないものかなー。対人ゲーで最初にガッツリ自習しないと始めることすらできないみたいなゲームは気軽に遊べないし、プレイスキルが重要なゲームは週1くらいで軽く遊ぶことはできないし。

 対人ゲーでプレイヤースキルがあまり重視されないのって、大量のプレイヤー数でマッチングを頑張るくらいしか対応できない気がする。プレイヤー数が十分にいれば、少なくともゲーム始めたての初心者とランクをカンストした最上位層を同じマッチに入れてリスキルされ続ける、みたいなことは避けられるはず。

 とすると、初心者はプレイヤー数が多いゲーム、つまり発売直後のメジャータイトルを買うのが一番楽しそうな気もする。ローンチ直後ならプレイヤー数が多いことを期待できるし、それらのプレイヤーがある程度フラットな状態を期待できるし、必要であればSNSで情報も集めやすいし。結局リアルマネーでPay to Winってことになりそう。懸念点があるとすると、大抵はフルプライスのゲームを定価で買わなきゃいけないという点だけど、そこはもうPay to Winとして諦めるしかないかな。




 バトロワPvPでステルス特化って珍しい気がするな。

 面白そうだけど、従前の理由で……




 タイピングゲーム。短い単語が周囲から押し寄せてくるので、片っ端から入力して撃破していく感じの。寿司打と違ってランダムリード速度のオーバーヘッドがないから、常にキーボードを叩いている状態にできて、結構楽しい。

 雑魚敵は短い単語だからそれほど大変ではないけど、ちょっと違和感がある単語がちらほら。それと、ボス敵は著作権切れの古い文章を使っているやつがいるので、現代文の入力にしか慣れていないと大変。

 変な入力を強要されるのはバグっぽい気もするな。ローカライズの人が大量の単語のデータセットを作るときにちょっとミスった、みたいな。バグった方に慣れると後でバグフィックスされたときに大変そうだけど、とはいえ、違和感の少ない状態に直してほしさが強い。

 あとは、ゲームシステム(自機の種類やアップグレード)が分かりづらいかな、という感じ。



 Appleの商品ページ、Windows(非慣性スクロール環境)から見るとスクロールがガッタガタでめちゃくちゃダサいWebサイトなのが残念な気がする。「ウチの製品で見ればヌルヌル綺麗に表示できるよ!」とアピールしたところで、御社の製品を購入済みのユーザーにそれをアピールしても顧客の獲得にはあまりつながらないのでは? むしろ御社の製品を使っていないWindowsユーザーに対して強くアピールできるWebサイトを作るべきなのでは? WindowsからAppleのWebサイトを見ると「Appleってこんなダサいデザインしかできない会社なんだ」的に見える気がする。


***


 ある日の1090ログ

 航空大の機体。Mode-3/A,C,Sが出ている。旭川空港で1200でタッチアンドゴーを行って、帰るときにスコークを変更。かなり強い信号を受信している。単に距離が近いからという理由だろうけど。

 パルスはコヒーレントだけど、傾斜が変。

 Mode-Sの応答。ログの都合上短く分割されているけど。灰色のドットが位相。

 最初は上昇傾向、すぐに下降傾向に移って、最後はほぼ水平。謎い。PAの昇温でXtalの温度特性が見えている、という感じでもない。電源周りの特性とか?


***


 fl2kからGPS L1, L2, L5を出したときの配置の例。L1, L2, L5の振幅の差があまり大きくないものをいくつかピックアップ。結構多くの選択肢があるので適当に選んだ数個。

 ↑12.75Msps

 ↑21.086956Msps (ゾーンが違うけど20.370367Mspsでも同様の特性)

 ↑35.35714Msps

 ↑51.764703Msps

 ↑89.090907Msps (89.000000Mspsや89.166663Mspsでもほぼ同様)

 ↑96.25Msps


 96Mspsや89Mspsはだいぶ特性が良い。89MHzはL4とL3がゾーン境界に近いけど、まあ、民間人でそんなバンドを使うやつもおらんやろ…… ただ、96Mspsとか89Mspsはデータレートがかなり高いので、データの生成も高コストだし、FL2000に通すのもUSBコントローラーの帯域幅的に結構大変そう。

 52MspsはL2, L5の特性はいいけど、L1がゾーン境界に近いのでちょっと厳しそう。他のサンプリングレートもL1は厳しい。低サンプルレートだと21Mspsがゾーン境界からの距離はちょうどいいかな? 急な傾斜のそばだから補償フィルタを通そうとすると大変そうだけど。

 今回は拘束条件としてL1, L2, L5の高さ(Sinc関数の利得)が近いことを設定したけど、利得に関してはキャリアの振幅で調整すればある程度自由に設定できるから、これはおそらくあまりいい条件設定ではない。周波数の低いL5はSincのヌル点近くの傾斜が急な場所に配置されるし、周波数の高いL1はSincのピークの近く(ゾーン境界近く)に配置されてしまう。ピークから適当な距離(周波数で5MHzとか、正規化周波数で0.2とか)ずらした場所を拘束条件として探すほうが良さそうな気がする。


 ということで、試しにL1,L2,L5のゾーンを拘束して探索

 ↑19.375Msps (2.91dB@L1,2,5)

 ↑34.838701Msps (2.89dB)

 ↑70.666660MHz (3.53dB)

 ↑79.999992Msps (2.79dB)

 ↑85.714280Msps (1.36dB)

 ↑86.0Msps (2.56dB)

 ↑100Msps (2.94dB)


 35Msps以下はL5とL2の間にピークが入るので、SAWフィルタでエイリアスを切れない。エイリアスの除去を考えると少なくとも70Msps程度(L2-L5の1.5倍程度)が必要。この場合、L1とL2で2.8dBくらいの差があるので、この差を減らそうとすると85.7Mspsに設定する必要がある。サンプリングレートにキリの良さを求めるなら86Mspsとか100Mspsとか。fl2kの入力は10MHzだから、100Mspsなら外部クロックと高いコヒーレンシー(ジッタ特性)が期待できる可能性もある。100MspsならL1, L2, L5, L6がすべてちょうど良さそうな位置にある(フィルタの特性次第)。


 京セラのSAWだと1ポート入力で2ポート(L1,L2/L5)出力とか3ポート(L1,L2/L5,L6)出力の製品はあるけど、複数ポート入力1ポート出力の製品はなさそう。個別のアンテナを使ったらマルチバンドの意味がなくなるから複数入力ポートは不要ってことなんだろうけど。しかし、マルチバンドGNSS受信機って帯域ごとに入力ポートが独立してるのかな? それならfl2kから2,3chで信号を出して軽くDC付近(大きな振幅)を消してから、まとめずにバンドごとに突っ込めば良さそう。外付けのフィルタに依存してアンダーサンプリングとかやってると困りそうだけど。


***


 FMラジオ用のfl2kの適当な計算。

 IFのサンプルレートを285ksps(15x19kHz)に設定すると、250倍で71.25Mspsが作れる。71.25MspsはFL2000で出せるからちょうどいい周波数を出せる。76MHzから99MHzの範囲はゾーン3に入る。

 44.1kspsから285kspsに変換する場合、44.1ksps*950=41.895Msps/147=285kspsでかなり高い場所を経由する必要がある。かなり高い、とは言っても、DACのサンプリングレートの半分程度ではあるけど。

 48kspsからであれば48ksps*95=4.56Msps/16=285kspsで、かなり低い比で変換できる。

 FMステレオ放送を変調する場合、パイロット信号はNCOで作ればいいし、サンプルレートもそれほど高くない範囲に選べば計算量はあまり多くないから、大抵はNCOで問題ないはず。だた、RDSみたいなデジタルデータを扱いたい場合、少なくともパイロット信号の整数倍を選んでおくと、計算が楽になるはず。285kspsなら285ksps/57kHz=5で、データキャリアの1周期を5サンプルで表現できる。ちょっと分解能悪いけど、どうせBPSKだし、デジタル変調だし、なんとかなるはず……


***


 CICと補償フィルタの例(N6, R10、入力正規化周波数0.06でカットオフする補償係数)

 補償フィルタを通しても高周波側が上がってくる特性が謎だったんだけど、FIRの次数が少ないとこうなるらしい。特に32タップの場合は全体的に高くなっていて全く補償特性がないし、64タップの場合もDC付近が少し持ち上がっている。

 拡大するとこんな感じ

 1024タップでも細かく見ればやはり高周波側は持ち上がっていて、2048タップでも程度の問題。CICフィルタはなまじ整数演算で計算誤差がほとんどないから、厳密に見るとこういう細かい誤差が綺麗に見えてくる。

 128タップが顕著だけど、綺麗な曲線ではなく、多少うねうねした形になっている。これはFIRのリプルが窓関数(Blackman)を抜けて出ているもの。



 入力端の正規化周波数を0-0.5の範囲で周波数スイープした複素信号をCICに入れて振幅をグラフ化

 青が期待した値、橙がその結果。ぴったり重なって、その差は0.001dBより小さい。

 振幅の期待値は(sin(pi*f*R)/sin(pi*f))^Nで計算できる。CICの応答はSincのN乗という説明がよくあるけど、分子にRが入っているし、分母にsinが入っているので、ちょっと違う形になる。



 FMステレオ用のFIRの特性

 48kspsを入れてFIR、↑CIC(N6、R95)、↓CIC(N5、R16)をシリーズに通して285kspsを得るような形。FIRは512タップ、プリエンファシスはとりあえず50usを設定している。バンドパス特性はほとんど直線な感じ。CICやエンファシスが重なって偶然そうなったんだろうけど。/* 直線と言っても片対数だけど */


***


 SDR#のWFMのエンファシス特性。乱数+FFTで1kHzから5kHzの雑音を作って、それをFMステレオ変調しIQファイルへ書き出して、SDR#で復調。右下のAudio Spectrumが問題の部分。

 ↑0.1us(エンファシスOFF模擬)

 ↑50us(米国のFM放送)

 ↑75us(日本のFM放送)

 デエンファシスは高周波を下げるので、プリエンファシスがない場合(今回は0.1usで模擬)は明らかに右肩下がりのスペクトル。50usと75usはほぼ平坦だが、どちらかといえば50usのほうが水平に近い。とはいえ、ほぼ違いはない。


 エンファシス特性、10usから100usまで

 エンファシスOFFと50usは高周波では12dBとか変わるので音源によっては比べなくてもわかると思う。しかし、50usと75usでは3dB程度しか変わらないから、片方だけ聞いて正しいエンファシスか、不正なエンファシスかを判断するのはかなり難しいと思う。4kHzを超えればどちらも3dB差程度でほぼ一定だから、大抵の場合は単に音量の違い程度にしか聞こえないはず。


 本来は特性を期待できる受信機(例えば日本メーカーが開発した広帯域受信機のWFMとか)にfl2kの出力を突っ込んで、実機でも比較してみるべきなんだろうけど、ハードウェアも色々準備しなきゃいけないし、録音方法も考えなきゃいけないし、録音したもののスペクトルを見る方法も考えなきゃいけないし、ちょっと手間が大きいので、また気が向いたらやる方向で。。。


***


 SoundEngine Free(v5.23)のヴィジュアルのFFT、連続して見ていると正常に表示できなくなるときがある気がする。一時停止してまた再開すれば正しそうなスペクトルが見える。

 あと、ヴィジュアルのFFTは、FFTの分解能(Hz/bin)と表示の分解能(Hz/pixel)が違うが、そこのレート変換に変な特性があって、線スペクトルを表示すると振幅が正しく表示されないっぽい。振幅が正しくない程度ならまだいい方で、場合によっては完全にスペクトルが消えることもある。テスト信号みたいに線スペクトルが入っている音声信号を見たいときは気をつけないとまずそう。


 ↑すべての線スペクトルがある程度等しい強度で表示されている状態

 ↑フロアが暴れている状態。低周波側が顕著だが高周波側のスペクトルの隙間もかなり浮いている。

 ↑横幅を減らして表示した状態。例えば18kHz付近のピークがほぼ完全に消滅しているし、付近のピークもかなり減衰して表示されている。


 線スペクトルの高さが正しく表示されない問題は、表示領域を広くすればある程度緩和できる。おそらく適当な幅のbinを加算平均とかしていて、線スペクトルが消えるんだと思う。表示範囲を広くすると平均化に使用するサンプルが減るから、線スペクトルが相対的に浮いてくる。うちの環境だと4KモニタとサブのFHDの合わせて5760ピクセルの領域で表示すると、ほとんどすべてのスペクトルが同じ高さに見える。3840ピクセル程度だとまだガタガタする。

 高周波側が顕著で、正規化周波数で0.2あたりまではかなり安全。ただ、これはFFTの周波数分解能の問題だと思う。低周波側は、長期的には線スペクトルであってもFFT窓内ではブロードなスペクトルになって、複数binで平均化したときにノイズフロアに引っ張られなくなる、みたいなことだと思う。

 信号処理(フィルタ処理とか)のテストのために波形をWAVで吐き出してSoundEngine Freeで表示して確認する、みたいな方法は結構危険かもしれない。


 フロアが暴れるのは横幅を広くしたときに顕著で、幅が狭いときはほとんど出ない。高さはおそらく無関係。線スペクトルが消えないように横を広くするとフロアが暴れるし、フロアが暴れないように横を狭くすると線スペクトルが消えるし。難しい。


2025年10月29日水曜日

小ネタ








 地上-衛星間光通信における大気ゆらぎの影響を克服する次世代誤り訂正符号の伝送に世界で初めて成功|2025年|NICT-情報通信研究機構

 5G NR LDPCとDVB-S2の組み合わせでフェージングの誤りを訂正。組み合わせるってことは、どちらか片方だけじゃ駄目なんだろうな。S2だってBCHとLDPCの連接符号を使っているわけだし、G5 NR LDPCを使う理由って何なんだろうか。DVBのインターリーブと5Gの誤り訂正、とか?



 最近の車のヘッドライトって歩行者を重点的に照らして反対車線の車には強い光を照らさないようなビームパターンになっているけど、比較的狭い場所とか起伏の激しい場所で使う車だと、ブロードなビームパターンが欲しい場合って無いんだろうか。汎用の車両とヘッドライトAssyを交換してブロードなやつをつけるオプションがあっても良さそうだけど、そういうのをつけると公道を走れないとか理由があるのかな?



 人間用のヘッドライトを1本欲しいなーと思って物色してるんだけどいまいち良いのが見当たらない。

 今まで使っていたPetzlのタクティカがわりあい良かったのでそういう系統のが欲しいけど、Petzlの現行製品はタクティカ(80g級)に比べて100g級と一回り重くなっているし、外観もゴツくなっている。

 BlackDiamondのアストロ300は80g級で値段も比較的手頃だけど、白色灯しかないので、いざというときに赤色が欲しくなると困りそうな気がする。これに赤色をつけるとコズモ350という名前になって、値段が2倍になる。

 GENTOSはデザインが好きじゃないからなぁ…… あとはPetzlとかBlackDiamondは人間の生死に近い場所で使うブランドだから、低価格帯の製品でもそれなりに品質も高かろう、という期待感があるけど(自分はそんな環境で使うわけではないとはいえ)、GENTOSはあくまでも安価なLEDライトのブランドというイメージ。とはいえ、GENTOSってまともに使ったことはない気がするな。一応日本メーカーだからそこまでひどい品質でもないだろうけど。/* amazonの履歴によるとGENTOS製品は10年くらい前に何個か買ってるらしいけど印象にない */

 Petzlのヘッドライトは取扱説明書に変調周波数が明記してあるのが面白い。この周期で動く機械は動いていても動きが見えなくなるから使うときは注意しろよ、という注意書き。PetzlやBlackDiamondは取扱説明書が日本代理店からPDFでダウンロードできて、動作温度範囲がちゃんと明記してあるのが嬉しい。冬の北海道だと場合によっては温度範囲キワで使うことも考えられる。Petzlは欧州(仏)らしく-20℃(-4℉)から+40℃(+104℉)まで、BlackDiamondはアメリカの会社らしく-17℃(0℉)から+43℃(+110℉)まで。Petzlのほうがわずかに寒いところまで耐えて、BlackDiamondのほうが僅かに高い温度まで耐えるが、あくまでも丸めの範囲でしかない。

 Energizerのヤツが70g級で白色と赤色が独立したボタンで使いやすそう。デザインもわりかし好み。ただ、あくまでもコンシューマー向けのメーカーな気がするし、信頼性はそこそこかな。普段使いで問題になるようなものじゃないだろうけど。Amazonの商品画像には緑色もあるらしいけど、商品パッケージとかには記載がないのが謎い。外観を見る感じ補助灯がLED2個分ありそうだからR/Gを積んでいそうな気もするが…… /* 購入履歴によるとEnergizerのライトも買ったことあるらしいんだけど、記憶が。。。 */

 PetzlのARIA 1 RGBは白色の他にRGB LEDが乗っていて、3色を照射できるらしい。ただ、OFF状態からRedを起動するモードは無くて、WhiteをつけてからRedに切り替える、みたいな操作しかできないはず。常識的に考えて、以前のモードにかかわらず赤で起動する、という機能が無いわけないだろ?と思うんだけど、説明書に明記してないのがなぁ。他の機種でも同様。古い機種の説明書(PDF)にはswitching on & choosing colorという項目でoff or whiteから長押しでredを起動するというモードがあるけど、新しい機種にはwhiteから2秒長押しでredに切り替える、みたいな説明しかないから、OFFからredを起動は難しそう。あるいは、「white」というのはwhite onとwhite offの両方を含んでいる、という意味なのかもしれないけど。

 BlackDiamondのコズモ350も、取扱説明書の図を見る限り、OFF状態から確実にredで起動するコマンドはなさそうな気がする。

 昔使ってた安物のヘッドランプが1ボタンなのに白/赤の操作性がすごく良くて使いやすかったんだが、なんで安物のヘッドランプでできる操作がブランド物のヘッドライトでできないのか謎い。安物のやつはハードウェアの品質は値段なりだったけど。

 Google曰く、うちの周り(田舎の距離感)にもスポーツ用品店は結構数があるらしい。とはいえ、このあたりはスキー場に来る観光客の相手がメインの店だろうから、PetzlとかBlackDiamondとかを一通り在庫している店が一体どれくらいあるだろうか…… 昼間(orナイター)のスキー客相手なら光り物は不要だし、自分で計画して山に入るようなガチのキャンパーなら装備を現地で買うなんて馬鹿なことはやらないだろうし。

 YouTubeのレビューとか探せば操作中の動画くらいあるだろ、と思って探しても全然出てこねーし、検索ワードに全く無関係な"YouTuber"が馬鹿騒ぎしてるような動画は大量に「おすすめ」されて出てくるし。YouTubeの"アルゴリズム"ってほんと馬鹿だよなー。せっかく大量の動画コンテンツがあるはずなのに検索システムがクソなせいで死蔵してる。箱開封ASMR風モタモタ雑音Shortsとか誰が見るんだよ。なんでそんな動画しか検索結果に出てこないんだよ。YouTubeは暇つぶしのコンテンツを探すにはいいんだろうけど、特定の情報を探すには向かない感じだなー。YouTubeに限らず、最近のインターネットはそういう傾向なのかもしれないけど。商品名でググって出てくるレビューサイトでも表面的なことは書いてあっても、突っ込んだレビューをやってるところはあまり多くない。結局田舎住みは自分で買って試すしかないのか。。。


 Nitecore UT27 MCTは白色2灯で色温度を3段階から選ぶことができて、赤色も搭載。重さも74gとかなり軽量。操作性はちょっと独特だけど、少なくともOFFから赤色を起動できることは明記されている。ただ、比較的高価格帯(9千円弱)なのがネック。

 HA11は単3電池1本で38gとかなり軽量で値段も3.2千円と、輝度が低め&ランタイムが短い以外は良さそう。赤色もOFFから起動可能。バンドのNITECOREのロゴがうるさい以外は選択肢として良さそうだが……

 Nitecoreはオンラインの取扱説明書のURLがわかりやすくていいな。一つのディレクトリに製品名が小文字でファイル名になっているから、気になる製品があったらとりあえず取説を開いて操作方法を見る、とかができる。試しに10年以上前に買った製品の名前を入れたらちゃんと説明書が見れた。テキストのコピーができないのが不便ではある。メーカー純正の充電池をamazonで探そうとか思ったときに手入力しなきゃいけない。あと、雪山とかは想定していないのか、温度範囲が書かれていない。

https://flashlight.nitecore.com/Uploads/FLASHLIGHTS/download/ha11.pdf


***


 とある日の1090MHz

 左側のグループは6種類の応答が出ている。右側は4種類。左と右ではドップラが若干違うので、おそらく別の機体。どちらの時間帯もFr24に機影無し。Mode-S応答無し。

 左のグループは6個とも同じドップラ特性だから同一のトランスポンダっぽいけど、なかなか謎い。Mode-1,2,3/A,Cの4種類じゃないとすると、Mode-1,2,3/A,B,C,Dとか? そんなアホな……

 

***


 C#からfl2kのDLLを叩いて波形を出せるようになった。構造体の授受とか配列のピン留めあたりでミスってたっぽい。

 1280KiB/chのバッファを10Mspsで出力するので、ブロックを7.63Hzで出力、ここに1000サイクルや1100サイクルの正弦波を入れているので、7.63kHzとか8.39kHzの波形が出ている。8bitに対して±64ppの波形なので1/2フルスイング、VGAの信号レベルが0.7Vppで、終端抵抗をつけていないので1.4Vpp、その半分なので0.7V、といったあたりで、実測値もそのあたり。

 2chオシロなのでRedとGreenしか見てないけど、おそらくBlueも出せるはず。ということで、3chパラレルの数十Mspsの高速DACとして使える目処は得られた。

 手元の環境だと40Mspsあたりまでしか出ない(運が良いと75Mspsあたりまで行けるときもある)。デスクトップPCのフロントパネルの3.0端子なので、なにかボトルネックがあるのかも。underflow_cntに1が入るから何らかのアンダーフローが発生しているんだろうけど、start_txのbuf_numを増やしても改善しないので、別の場所っぽい。



 FL2000のI2C読み書きコマンド


 オシロはバグで後続パケットがあるとストップコンディションの場所が正しく表示されない。ロジアナだいぶ久しぶりに使った気がする。3月にソフトウェアアップデートが出てた。といっても後続モデルが出ているのでバグフィックス程度だけど。

 プログラム上はレジスタアドレス0x12を指定しているが、実際には0x10からの4バイトが読み書きされている。下位2bitはFL2000の中で無視しているっぽい。


 ターゲットデバイスはArduino Nano Everyで作ってみた。細かい制御をやろうとすると大変そうだけど、手軽に数バイトを読み書きできるダミーのI2C RAMっぽく作る程度なら結構楽に作れる。


 しかしまあ、FL2000のI2C、どういう使い方を想定しているんだろうか。このシーケンスだと24LCxxxの読み書きには使えないはずだが。EDIDとかを想定すると24LCとは別のプロトコルでいいんだろうか? それともFL2000には別のI2Cモードも乗ってるんだろうか。



 fl2kで設定できるサンプリングレート

 青色(左軸)が設定できるサンプリングレート、橙色(右軸)が設定できる間隔。

 数値的には7.777777Mspsから555Mspsまでを設定できる。実質的にはUSB 3.0(内部バス含め)の帯域幅で制限されて、150Mspsあたりが上限らしい。

 間隔は狭いところでは1Hzステップで設定できる場所もあるし、場所によっては数MHzくらい空くこともある。


 サンプリングレートの自由度があまり高くないので、用途によってはある程度妥協する必要もがある。例えば44.1kspsの整数倍を作ろうとすると、407倍で約17.95Msps(サンプリングレートエラー16Hz)、429倍で18.92Msps(17Hz)、481倍で21.21Msps(19Hz)、1069倍で47.14Msps(-45Hz)、1221倍で53.85Msps(49Hz)、1443倍で63.64Msps(58Hz)、といった選択肢が考えられる。大雑把に1ppm程度のクロックエラーが有る。日本のFMラジオの帯域を想定すると75-100MHzあたりになるので、53.85Mspsならzone3とzone4で全域をカバーできて(zone3/4の折り返し部分は抜ける)、63.64Mspsならzone3で両端を除いた範囲をカバーできる、という感じか。端はカバーできずとも奇数ゾーンだけである程度の範囲をカバーできる1443倍が便利かな? いずれも1280x1024との整数比にはならないから、そのあたりは気にせず。



 試しにウイークリービルドの最新版(osmo-fl2k-64bit-20251026)を使ってみたら、fl2k_test.exeを起動すると"libusb: error [winusbx_set_interface_altsetting] SetCurrentAlternateSetting failed: [31] システムに接続されたデバイスが機能していません。"と"Failed to switch interface 0 to altsetting 1, trying to use interface 1"というエラーメッセージが表示されるけど、とはいえ信号はちゃんと出ているっぽい。

 付属のDLLを使った場合も同じエラーメッセージが出力されるけど、信号の出力自体は行われている。

 DLLは3個付属していて、本体がlibosmo-fl2k.dllで、他にlibusb-1.0.dllとlibwinpthread-1.dllがついている。libwinpthreadのプロパティではバージョンは1.0.0.0固定だがファイルサイズが若干違うのでバイナリは別っぽい。libusbはプロパティで表示されるバージョンも違うし、容量も違う。ただ、libwinpthreadとlibusbは最新版に付属しているものを使って、libosmo-fl2k.dllだけ切り替えた場合、最新版ではエラーメッセージが出るが古いバージョンではエラーメッセージが出ないから、libosmo-fl2k.dll側の問題だと思う。とりあえず、[31]エラーの場合、見かけ以上は波形やI2Cのやり取りには問題なさそう。エラーメッセージが出るのが気持ち悪いなら古いバージョンを使えばいい。



 さて、ということでC#からDLLを叩いて複数ch(少なくとも2ch)の波形を出したりI2Cで読み書きしたりが動くようになった。安定して動かそうとするとサンプリングレートを高く設定できないのがネック。このあたりはPCとの相性問題なので定量的な評価は難しそう。せいぜいPCIe拡張カードを使えばUSBチップは比較的自由に設定できるかな、程度か。それにしたってPCIeバスコントローラーの機嫌もあるだろうしなぁ。


 fl2kで3chをコヒーレントに数十Mspsで出せるとして、何に使えるかな。

 法的な面を考えなきゃいけないから、実際に電波を放射するような用途には使いづらい。なので、例えば3素子のビームフォーミングみたいな使い方はできない。超音波あたりなら出せないことはないとしても。

 外付け回路が面倒になる点を許容できるのであれば、GPSのL1, L2, L5を出してマルチバンドGNSSシミュレータとかは作れそうだ。高調波を使うのであればアップコンバージョンも不要だけど、低周波がかなり強く出るからせめて何らかのフィルタ程度は必要になる。先に数十dBのATTを挟んだうえでSAWとかを入れる感じかな? 3バンドを適切に配置できるサンプリングレートがあるかは未確認だけど、1個2000円未満のUSB DACでマルチバンドGNSSのシミュレータが作れたら面白そうだ。ぐぐったら18年頃(fl2kが出た当初)にちらほら記事があるけど、継続的に使っている人はいなさそう。その場合もL1だけで、マルチバンドのシミュレータとして使っている例はなさそう。マルチバンドにしろシングルバンドにしろ、わざわざGNSS信号を生成するような人はちゃんとしたデバイスを使うだろうしな。

 ゾーン2とかゾーン3でNTSCやFMを出せばアナログテレビ信号を放送できるけど、今の時代にアナログテレビを復調する機材は入手性が悪そうだ(AirSpy R2で自作するとかも可能ではあるだろうけど)。レトロ家電とかで古いテレビを稼働状態で展示したい人とかは、自由にアナログテレビ信号を出せるfl2kはいいかもしれないけど、そんな人が日本にいったい何人いるか……

 もうちょっと高い場所を使うなら地デジ放送(ISDB-T)とかも出せるだろうけど、このあたりまで来るとMPEG-2 TSの構造のほうが難しくなりそう。受信だけならRTL2836系でワンセグ放送は受信できるから、fl2kで出してrtlで受信して、最低限の映像信号だけ飛ばすならわりあい簡単にできそう。市販のテレビで受信できる一番シンプルなMPEG-2 TSってどれくらいのものが必要なんだろうか。さすがにH.264の映像信号にヌルパケットを入れて固定ビットレートで送る、程度で見れることはないだろうから、色々と必要なはずなんだけど。確か"ウルグアイの大学生"がフルスペックのISDB-Tの送受信をやっていたはずだが。

 外付け回路で頑張るならIQ信号を出すということも考えられるか。3chのDACが一つのダイに乗っているということは、アナログ特性はかなり近いはずだから、3ch目はバイアス基準のDCを出しておくということもできる。例えば50MspsでIQを出せば100MHz幅近い信号を出して、外付けのアップコンバータで高周波へ移動できるから、帯域幅が非常に広い変調信号を出力できる。アップコンバータを用意するのが手間だけど。



 試しにFMステレオ信号を作ってみようと思って、いろいろググりながら、とりあえずゼロIFでIQファイルに書き出してSDR#に入れてみたんだけど、うまくステレオとして認識できない。モノラルだけの信号でも、NFMで復調すれば一応聞こえるけど、WFMだと音量がかなり低くなる。

 たぶん主搬送波とパイロットの信号レベルとかいろいろ合わせないと駄目だろうし、一部予想外の挙動をしている部分もあるので、しっかり本腰入れて作業しないとダメぽ。ということで、今回はfl2kがI2C周り含め3chDACとして動くことが確認できたということで良しとして、実際に使う辺りはまた気が向いたら、ということで。



 といいつつ、なんかモヤモヤするのでWikipediaを物色

 FM broadcasting - Wikipedia #Stereo_FM

 それっぽい計算式が書いてあったのでC#でベタ書き。ちゃんとSDR#でFMステレオとして再生できるゼロIF IQファイルが作れた。やっぱWikipediaしか勝たんのよな。


 処理の流れとしてはL/R channelをFIRでBPF(含エンファシス・CIC補償)に通したうえで、CIC(N5)で13倍し、NCOでステレオFMへ変調、Re/ImをCIC(N5)で111倍してキャリアを掛けて、IQファイルとして出力。低周波部ではなんだかんだ処理しても、結局は最終段のCICと複素積が一番重い。

 CICは積分が入るから無限インパルス応答となって、厳密に言えばウインドウを区切って並列に処理することはできないから、ここの高速化は諦めるしかない。複素積は適当な領域に区切って並列で処理できるから、ここはマルチスレッド化できる。とはいえ、CICが重いことに違いはないので、CICは実軸と虚軸を並列に処理、最後にLoとかける処理は1ブロックずつ並列処理で、結局CICで律速されて、3ブロック同時処理、くらい。で、リリースビルドでは4分30秒くらいのWAVをIQファイルに変換するのに1分10秒くらいかかる。デバッグビルドでも早ければ3分30秒くらいだけど、遅いと4分20秒くらいかかって、確実に等倍速で走ることを期待するのはちょっと難しそう。ちなみに、4分30秒のWAVを約63.64Mspsの2ch8bitで吐き出すと33GB近くになる。SDR#だと最初の30秒程度しか読めない(SDR#は4GiB制限があるので)。



 floatで保存すればさすがにスプリアスがゴリゴリに出るけど、u8で保存すれば分解能未満になるので、綺麗なFMステレオのスペクトルになる。

 今回は特に理由もなくIQ信号で出しているけど、fl2kで出すなら実軸だけでもいい。虚軸を省いてもCICの計算は両軸が必要だけど、複素積の計算量が半分になるので、計算量が4分の1くらい省略できる。結局CICが一番重い。



 IQファイルをC#でlibosmo-fl2k.dll経由でFL2000に与えてみた

 FL2000から出したRed信号を同軸ケーブルでオシロまで引っ張って、75Ωの炭素皮膜抵抗で終端しつつ1MΩで受けてる。前に75ΩのBNCの終端抵抗を買った気がするんだけど、どこにしまったっけなぁ…… たぶんRCA-BNCケーブルにつけっぱなしのはずなんだけど、そのケーブルも見当たらないし。

 オシロのMeasure、矩形波的な信号を突っ込むとFreqが正しく計測できないらしい。トリガのf=16.3666MHzのほうが正しい値に近い。約63.64Mspsでf16.3MHzを出してゾーン3で80MHzのFM信号を得ている。

 試しに広帯域受信機を近づけたら、さすがに離れるとノイズだらけになるけど、同軸線にアンテナをピッタリ添わせたら受信できた。同軸線といってもさすがに真横に這わせたら漏洩する。/* スケルチ全閉にしてもノイズを受信する。この部屋の電波環境どうなってんだ */



 試しにCICで高周波段(積分器)を1段ごとにバッファに書き出して、それぞれをスレッドで処理するようなやつを作ってみた。

 4分30秒のファイルをデバッグビルドで処理して5分50秒、リリースビルドで2分50秒、くらい。元々の実装では1分10秒だったのが2分50秒になったわけだから、かなり遅くなった。積分器N個+微分器1個のN+1スレッドで動作するし、実軸/虚軸を同時に処理すれば、例えばN3なら6+2スレッドが走ることになる。ただ、実軸/虚軸を直列にしても、並列にしても、処理時間は全く同じだった(デバッグビルドだと誤差程度には早くなる)。つまり計算リソースではなくメモリ帯域幅等で制限されていると考えられる。ウチのPCだとシングルスレッドでCPUのキャッシュで頑張ったほうが良さそう。

 そういう事を言い始めると最初から最後までバッファを介さずに全部一気に処理したらだいぶ早くなるんじゃ?という気もするんだけど、さすがに面倒すぎるなぁ。。。

/* そういえば、このときは最終段Loをシングルスレッドで回していたから、ここを変えればもう少し早くなるかも */


***


 What is this and what do these changing letters and numbers mean? I appreciate any info as I'm new to SDR, thank you. : r/RTLSDR

 SDR#のWFMでスペクトル画面の左上に表示される文字列の意味。曰くRDS(Radio Data System)で放送されているコールサインや曲名みたいなテキスト情報をデコードして表示しているとのこと。ランダムな文字列が表示されるから信号レベルとかのステータスかと思ったら、ちゃんとしたテキスト情報なのかな? じゃあRDSって誤り訂正やら誤り検出やら積んでないのかよ、という話だけど。Wikipedia曰くエラー訂正機能があるとのことだから、RDSデータのない信号を突っ込んだ場合はノイズ的なものを受信して非表示になるはずなんだけどな。誤り訂正はおろか誤り検出自体通さずに表示しているのかな?



https://www.jstage.jst.go.jp/article/iteac/2016/0/2016_31C-4/_pdf

 2016年。FMラジオ同期放送用のデジタルFM変調器の話。

 OCXO校正用に「GPS/QZS/地デジCP信号校正」とのこと。地デジCPって、日本だと最上端の1本しか無いから、校正の精度としてはさほど高くなさそうな気がする。SPを使ったほうが精度が出るはずだけど、CPでいいってことはその程度の精度でいいってことか。

 そもそも地デジ信号ってGPSに従属してるわけだから結局GPSを受信するのと大差ないのでは?という気もするが。GPSが止まってもCPで高精度なクロックを供給できるよ、みたいなことなんだろうけど、広域でGPSが止まってるならCPの精度だって悪くなってるだろうし。FMラジオ用のOCXOに比べれば地デジのクロックはさらに精度が高いことを期待しているのかもしれないけど。地デジがRbを使っているならOCXOよりは安定性が高いかな?


2025年10月22日水曜日

小ネタ


 三菱電機グループの技術を紹介する「三菱電機技報」全バックナンバーを公開 | 三菱電機

 オンラインで公開していなかった1959年以前についても公開を始めたよ、とのこと。’50年代はともかく、それより前は現代の文に慣れてる身からするとかなり読みづらいけど。

 興味はあるけど、いかんせん量が多いのでなぁ……



 なんか頭痛いなーと思って熱を測ったら37.1℃あって、慌てて加湿器をつけて寝たら、翌朝には36.8℃くらいまで下がってた。その後.8と.9を行ったり来たり、といった感じ。体感ですごい楽だから熱下がったのかなーと思って測ったら37.1℃だったりとか。人体謎い。

 信頼できない湿度計によると、部屋の湿度は45%くらいだった。一晩加湿器をつけて4Lくらいぶちまけて58%くらい。部屋にいるとわからないけど、一旦部屋を出て数分して戻ってくると、部屋に入ったら明らかに蒸し暑い感じがする。単純に加湿器(加熱型)で熱が供給されているのもあるだろうけど。

 部屋の外に設置したGPSアンテナの同軸線を引き込むために窓を数mm開けているので、加湿してもここから空気が交換されるっぽい(室温と外気温の温度差で循環しそう)。とりあえずマスキングテープを窓枠に貼って密閉。これで加湿器をつけると湿度は上がるようになったけど、部屋があちぃ。。。なんだよ10月も後半に29℃って……

 なお、今回更新分の内容が薄いのは体調不良ではなく、ダッコフが原因です。


 ダッコフはドロップが渋いのでなかなか難しいね。例えばDELTA FORCEのオペではデイリーとかウィークリーで装備チケットが貰えたからそれを使い潰して大して稼がなくてもだいぶ遊べたけど、ダッコフでは全部自分で装備を整えなきゃいけないのでデスペナがキツイ。

 最初の数日はわりと遊んだけど、気軽に行ける範囲が結構狭くてすぐ飽きちゃった。




  オンライン対戦のデスマッチ型タイピングゲーム。現在デモ版がフリー公開中。

 対戦型とはいえFPSみたいなゲームに比べれば比較的個人戦に近いのでだいぶ遊びやすい。とはいえ、勝率は悪いので大抵のゲームは普通に撃ち殺されるけど。……タイピングゲームで撃ち殺されるとは一体。。。

 最大100人が同時に入れるのかな? 200人に加えて机やタイプライター等の小物が100セット配置してあって、グラ要求がかなり大きい。

 自分の場合、誤入力が比較的多いので1ミスが命取り(文字通り)になるこのゲームは結構大変。あと、単に英語能力が低いのもボトルネック。次に入力する単語を読み上げるみたいな機能があればタイピング練習だけじゃなくて英語学習的に良さそうな気がする。

 日本語モードも欲しくはあるけど、実装難易度は段違いだろうな。日本語は英語と違って入力の揺れがあるから、それらを許容しようとすると結構手を入れなきゃいけなさそう。


 プレイ時間1時間ちょっとでレベル100を超えて、いくらでもやれそうだけどこれ以上は何かしらに支障をきたしそうなので一区切り。気がついたらレベル200超えてるけど多分なにかのバグ。



 そういえばIdiosが案件してたQTTA、プライムデーで箱買いしていたのが届いたので、とりあえず醤油を試食。記憶の中のQTTAってもっと重いイメージだけど、リニューアルした分が効いてるのか、記憶違いなのか、思ったより食べやすかった。ただ、主食にするには少ないし、間食にするには多いし、微妙なところ。まあ、大抵のカップラーメンはそれくらいの感じだけど。ボリュームが欲しいならパックご飯とか温めればいいしな。そのあたりは個人が好みで調整といったところで。

 最近あまりカップ麺を食べてなかったので結構久しぶりな気がする。昔は別ブランドの6種類入り12個入りとかを箱買いして毎日それを1個ずつ食べるみたいな生活を結構長期間やっていたせいで、その頃に食べていたカップ麺は食傷気味。そういう意味では、QTTAは当時ほとんど食べなかったので、気軽に食べられそうだが。


 カップ麺を食べながら、日常生活の中で時計の時刻精度が10秒くらいで要求される状況もなかなか無いよなー、などと考えたり。待ち合わせでも例えば1,2分くらいのズレは許容できそうな気がする。

 カップ麺を作る場合、3分として10秒で5%くらいだから、湯を入れる場所と食べる場所が物理的に離れている場合、双方の時計が10秒以下程度で同期している必要がある。クォーツ時計は月差10秒前後だから、その誤差が出る時計の場合は数週間程度の頻度で時計を合わせておく必要がある。電波時計やNTPで時刻同期した時計の場合は最大でも数秒程度の誤差に収まるはずだから、カップ麺を食べるときでも安心。



 たまーに流れてくる「ウン十年無借金で経営してきた(経営状況に問題のない優良な)町工場が後継者不在で廃業するしかない」みたいなニュース、人材育成のコストをケチったから無借金だっただけでは?って気がするな。「誰か後を継いでくれる人がいないか」とか言っても、その「誰か」って、最初から自分と同じスキルを持っていることを期待しているんでしょ? 長期間無借金経営ってことはその間に大規模な設備投資も行っていないだろうし、何十年も前に作られたマニュアルもなければ保守できる人も居ない機械が並んだ工場を売りつけられて「明日からよろしく」とか言われたってどうにもならないでしょ。最悪鉄くず程度の価値しかない工場なのでは?



 最近PCのオーディオ系が調子悪いんだよなー。有線イヤホンが時々ゴッソリ抜ける。おそらく充電器に入れてあるEcho Buds 2がPCと接続して出力先がそっちに吸われてるんだと思うんだが。実際、ケース内のBudsをグリグリ押すと正常に戻るし。しばらく放置しても戻ることもある。ファームウェアのバグっぽい挙動なのか、あるいは電気的な問題なのか。BGMとか動画とかの音声が頻繁に途切れるのは結構ストレスが溜まる。



 SDカードにUbuntuを焼いてみたけど、うちのノートPCは内蔵のSDカードリーダーからのブートには非対応っぽい。残念。USB接続のSDカードリーダー経由でも駄目っぽい。同じUSB MSC扱いだと思うけど、USBメモリからは起動できてSDカード(USBリーダー)からは起動できないのちょっと謎い気もする。


 このノートPC、前に使っていたものに比べてほとんど半分くらいまで軽くなっているので取り回しがかなり楽。画面も広くなってFHDになったし。この軽さに慣れたら次に買うノートPCが重くて使えないんじゃないかってレベルで軽い。

 ただ、トラックパッドのスクロールに変なクセが有るのと、CapsLock(Ctrlに割当)を押すとトラックパッドが一瞬反応しなくなるのと、あと動作が全体的に遅い。一応何世代か前のi5が入っているけど、Visual StudioでのビルドとかをメインのPCと比べると圧倒的に時間がかかる。


***


 Windowsでのfl2k、ウイークリービルドのosmo-fl2k-64bit-20220706.zipは動作する(少なくともfl2k_test.exeでsps/2が出る)けど、おそらくその次のosmo-fl2k-64bit-20231112.zip以降は動作しない。


 libosmo-fl2k.dllの戻り値が結構クセがあって大変。列挙型ではSUCCESS = 0で定義してあるけど、例えばfl2k_set_sample_rateの戻り値はintで、正常時には4が帰る。これはfl2kチップのレジスタに値を書き込むfl2k_write_regの戻り値が帰っていて、この関数はlibusb_control_transferの戻り値を返している。ここで4バイトの配列を与えているから、正常時には4が帰り、例えばタイムアウトエラーが発生した場合にはLIBUSB_ERROR_TIMEOUTが帰るが、これはFL2K_ERROR_TIMEOUTで同じ値(-7)が定義してあるから、それが見える(実際にどういうエラーメッセージが出るのかは未確認だけど)。

 大雑把には、負数の場合はエラー、ゼロ以上であれば概ね正常、みたいな判断になる。厳密にやるなら例えばfl2k_set_sample_rateの戻り値は4以外をエラーとする、みたいな扱いでもいいけど、実装が変わったときに対応できない懸念がある。


 とりあえずopen/closeとサンプルレートのset/getは動いているような気配がある(getはFL2000から読んでいるわけではないけど、少なくともDLLレベルまでは正常にアクセスできているはず)。ただ、start_tx/stop_txを入れると、コールバックは呼ばれるが、適当な乱数を入れた配列を与えても出力されないし、その後のcloseはハングアップする。

 参照しているコードは最新のコミットだから20220706版のビルドと違う可能性もありそうだけど、古いバージョンのタグをZipで落としてヘッダを見ても内容はほとんど変わらないから、少なくともAPIを叩くレベルでは区別せず使えるはず(さらに古いバージョンだとI2C機能がなかったりする)。


 試しにi2c_readを適当な引数で叩いてみると、指定したアドレスのI2Cコマンドが出る。ターゲットデバイスをつないでいないから最初のアドレスでNAKを読んでFL2K_ERROR_NOT_FOUNDが帰るけど。とにかく、物理的にFL2000を開いてI2Cコマンドが出ることはオシロで確認できたから、少なくともfl2k_openは正しく動いているし、それで得られたデバイスハンドラも最低限取り扱うことはできているはず。

 i2c_readを呼んだあとにcloseしても正しく閉じれるから、FL2000に対する操作でcloseがハングアップするわけではなさそう。ただ、i2c_readを呼ぶ前には定期的にDDCをポーリング(後述)しているけど、i2c_readを呼ぶとDDCポーリングが止まる。fl2kとしてRF信号を出す場合はDDCは必要ないはずだから事実上は問題ないだろうけど。DDCはFL2000が勝手にポーリングしてるものだと思ってたけど、fl2k側から止められるならなんで出してるんだろう?


 さて、Windowsでfl2k_testが動いて、DLLを叩いて一部の機能は触れるようになったが、DLL経由では肝心の波形信号が出せない、といったところで今週は時間切れ。どうしたものか。fl2k_tcp.exeとかいういかにもなヤツも付属してるから、それを叩いてもいいんだけどな。rtl_tcp.exeの場合は吐き出されるバイナリ列を受け取るだけだから簡単だけど、fl2k_tcpはデータを待ち合わせしなきゃいけないからちょっと面倒そうだ。



 USB 3.0 - VGAアダプタの部品面

 裏面には部品は乗ってないので省略。

 中央にあるのがFL2000-1L0-DX。右端にUSB 3.0のケーブルがはんだ付けしてあって、D, TX, RXの3ペア6本と電源の8本。左端にはDsub15のコネクタが実装されている(上下の補強端子はハンダ無し)。

 左下のチップはフラッシュメモリっぽいけど型番でググっても出てこない。似た型番は出てくるのだが。

 右上のSTO-23は1.2VのLDO。その隣の5ピンも3.3VのLDOで、シリーズで使っているのかな? DACの基準にも使っているっぽいから、PSRR重視でLを挟んでシリーズにしているんだと思う。

 右下に10MHzの水晶。

 その他トランジスタやダイオードやインダクタがいろいろ、コンデンサが大量、抵抗もいくつか。


 I2Cのプロービング用にpin5(GNDのはず)を引き出したらなんか信号が浮いてる。もしかしていくつかのリターン線が結線されてない……?? 



 FL2000のDDC

 I2Cのクロックは15.23kHz。NTSCのHsyncに近い周波数だけど、少し(3%程度)違う。そもそも走査線数からして違うからNTSCとVGAのHsyncの周波数が同じである(or近い)必然性もないし。

 0x50~A(W)が8個ずつ、260ms程度の頻度で出ている。オシロのデコーダのバグで左端にも0x50~Aが出ているけど、実際には無い(前の組のDDCは適切にストップしている)。

 

 先頭

 スタートコンディションの前に1発負パルスが出ている。


 末尾

 NAK直後にストップコンディション。



 fl2kからHsync/Vsyncを出せれば数十kHzとか数十Hzのパルス信号を出せて、RF信号に同期したパルス(トリガ信号)を出せて便利そうだな、と思ってたんだけど、Osmo-fl2kのWikiによるとHsyncとVsyncの両方を無効にしないと連続信号が出せないらしい。ままならないな。


 とりあえず、当面はDLL経由で波形を出せるところが目標か。しかし、構造体とかの取扱もさほど変なところは思いつかないし、怪しいところも無いからなぁ。libosmo-fl2k.dllを消すとfl2k_testも動かなくなるから、少なくともDLLの問題はなくて、叩く方法の問題であることは間違いないはずだが。ダミーのDLLを作ってどういう操作がされているかを見るとか? メンドクセ…… そもそもDLLを正しく叩けているかが問題なのに、どうやってDLLに偽装するんだという話だし。


2025年10月15日水曜日

小ネタ



 めちゃくちゃ真面目に遊んでて良きかな。

 歌詞に出てくる色々なキーワード、「コレ」っていう写真だけスライドショーにしたバージョンも欲しいな。そのうち誰か作りそうではあるけど。

 リアクション&解説動画とかあっても面白そう。CNESとかJPLあたりにホロヲタいないかな。欧米の宇宙機関ならプロジェクト進行とか日本と似てるから色々面白い話ができそう。真面目に全部説明してたら5時間くらいかかりそうだけど。




 DMGのスピンドル。ひずみゲージを内蔵して3軸の力覚センサみたいな計測値が得られる。今のところは手動で記録開始/停止を行って、後で解析するみたいな使い方かな? おそらく適当なテストピースをカットして発生する負荷を計測して切削条件を最適化する、みたいな使い方を考えているんだろう。

 機械自身がセンサで状況把握できるようになるなら、従来のCAMでツールパスを作ってポストプロセスで座標変換して、みたいな感じじゃなくて、CADから「このボリュームを除去して」みたいな指示だけ出して、機械が自分で持っている工具情報(刃の位置や許容負荷範囲)からそれに合わせたツールパスをある程度決めて、切削速度(切り込み量)とかはトルク等を見ながら自動で調整して、みたいな機能があっても良さそうだけどな。ワークピースの形状は機内のカメラなり、DMGならニコンのスキャナなり、機械自身で把握できるわけだし、機内の障害物も知っているから、工具をどういう向きで突っ込むとクラッシュするとかの情報は一通り持っているわけで、CADデータ(STLとか)で最終的に欲しい形だけ教えておいて、あとは先に除去したい範囲とかを教えておけば、機械が勝手に削ってくれる、みたいなのが理想的な工作機械だろうけど。付加造形はわりとそういう感じになってきているし、切削加工もあまりピーキーな製品でないなら勝手に削ってくれる方が良さそうだが。あるいは、最終的な形に1mmくらい膨らませた形(荒削りの範囲)までは機械が自動的にゴリゴリ削っていって、最後の仕上げのツールパスは人間が細かくプログラミングして削る、みたいな感じとか。

 まあ、そのあたりは、とりあえずセンサだけ先に売っておいて、あとからライセンスで追加する、みたいなことを考えているんだろうけど。



 Introducing the S-70UAS™ U-Hawk™ - YouTube

 UH-60を無人化してコックピット部分を観音開きになるようにして長い貨物を積み込めるように。MLRSのコンテナ1個を運んだり、UAVを上空から吐き出したり、いろいろ運べるし、無人だから(機材のコストを無視すれば)撃墜されるような任務に投入しやすくなる。

 各国の軍で採用されているUH-60を改造するのであれば、保守部品の調達や整備の教育コストも圧縮できるし、色々便利そうだろうなぁ。シミュレータ用の機材をそのままリモートコントロールステーションに流用すればUH-60のパイロットがU-Hawkを遠隔操縦できるようにもなるだろうし。

 米海兵隊はMLRSフォームファクタのランチャーを前線付近で移動させて生存性を高めながら使おうとしてるし、運用コストの低いヘリで必要なところに運ぶシステムが有ると便利そうよね。スリングで吊るのでなく機内に格納できるから運用性も高そうだし。

 前線で物資輸送とかUAVランチャーに使うならある程度のステルス性もほしそうだけど、外観を見る感じそのあたりはあまり考えてなさそう。ステルス型のUH-60系は15年くらい前にちょろっと漏れたことがあるから開発自体はやってるだろうし、前線で飛んでたってことは一通り評価も済んでるはずだけど。むしろ一通り情報は持ってるから必要になったときに改造すればいい、みたいな判断なのかもしれないけど。あるいは逆に高コスト過ぎてUH-60のステルス化は諦めたのか。ヘリのステルス化は一定の繰り返し周期が発生するローターからの反射が大変そうだが。

 たぶん無人の輸送ヘリを最初から設計して作ればもっと効率の良い機体を作れるんだろうけど、運用コストを考えると既存機の改造がベストなんだろう。「新規設計じゃないですよ。飛行実績のある機体のバリエーションですよ」といえば色々な手間を省けるし。MLRSコンテナ流用の無人ランチャーといい、既存システム流用の機材が増える昨今。



 20年でCPUコアの巨人にのし上がった「Cortex-M」:EE Times Japan 20周年特別寄稿(1/3 ページ) - EE Times Japan

 自分は仕事として(直接的に金銭的な報酬を受け取って)組み込み開発に関わったことはないけど、ちょうどこの移行期あたりにマイコンで遊んでいた(&若干の試作の下請け的な事をやっていた)気がするな。PICのアセンブリで電子工作を始めて、Arduinoで試作してPICに移植したりして、mbedを一時期触って、その後はSTM32(Cortex-M3)に移行してある程度複雑なものも作ったりして(PICを最後に使っていたのが2011年頃、STM32を使い始めたのが’12年頃、のはず)。試作みたいなやつはPIC, Arduino, STM32, mbed、あたりを一通り使っていた気もする。PICとかSTM32や周辺のセンサを使うときはどうしても英語のデータシートを拾うしかなかった。STMは日本語訳も用意してくれてたり、PICはそこそこシンプルなのでそもそもあまりデータシートを読み込まなくてもある程度は使えたけど(それでハマることも多かったけど)。

 H8Tinyも本当に触りだけ(Lチカ程度は)使ったことがあるけど、開発環境の構築とかが結構面倒で結局全く使わなかった気がする。でも電子工作を本格的に始める切っ掛けはH8系に特殊な開発環境を付属させたキットだったかな。

 海外のマイコン(PICやAVR)が普及して以降は、学生の間にマイコンとかを触り始めたようなエンジニアは英語のデータシートを読むしかないから、その人達が仕事として組み込み機器を作るようになると英語があまり敬遠されなくなった、という効果もありそうな気がする。そういう人たちが就職したタイミングでCortex-Mが出てきた、みたいな。

 ルネサスも一時期電子工作向けにマイコンを普及させようとしていた気がするし、比較的新しいArduinoにも乗ってるけど、でも日本語データシートのメリットを活かせるほど日本で普及したかというとな。そもそもArduinoは巧妙に隠蔽(抽象化)されているから、これでマイコンに触ったからと言ってデータシートを積極的に読むかというとそうはならん気もするし。チップを普及させたいならSTMのNucleoみたいにそれっぽいボードを用意する程度でも十分な気がする。まあ、ルネサスはそれをやって失敗したわけだけど。


 QualcommがArduino買収でエッジAI強化へ:新ボードも発表 - EE Times Japan

Qualcommは「Arduinoは独立したブランドやツール、ミッションを維持しながら、複数の半導体サプライヤーの幅広いマイクロコントローラーとマイクロプロセッサを引き続きサポートする」と述べている。

 じゃあ何のために買収したんだよ、という話だしなぁ。そのうちRasPiと競合の層しか出さず結局売れず、みたいな感じになりそうな気もするが。Intel Edisonとかみたいに。

 Nvidia Jetsonは10年経った今でも製品の発売が続いてるけど、これは計算能力がちょっと高めの用途で使いたいみたいな部分で人気があるのかな。UNO QもQualcommのある程度計算能力の高いチップを積むんだろうけど。とはいえ例えばハイエンドのSnapdragonを積んでAndroidが走ります、とか言われたって、そんなもん何に使うんだよ、って話だし。



 気象衛星ひまわり9号の観測障害 8号での観測に切り替え 気象庁 | NHKニュース | 気象、台風

「今回は衛星のカメラと衛星本体との間の通信に何らかの不具合が起きたとみられていますが、詳しい原因はまだ分かっておらず」

 前回は熱管理の問題だったけど、それとはまた別の原因なのかな?


 ひまわりっていまいち衛星の詳細がわからないんだよなー。AHIは外国製だから日本語資料も少ないし、そもそもここ10年とか20年の衛星はほとんど情報が出てこないってのもあるけど。

 DS2000の資料でAHIの接続にSpWを使っているみたいな感じのことは書いてあるけど。データレートは平均60Mbpsくらいだから、SpWでちょうど良さそうな程度。ほとんど固定レートだから汎用バスを使う利点はあまりないだろうけど、だからといって専用のインターフェースを作るよりはな。

 しかしまあ、ミッション機器と通信ができないと言っても原因として考えられる範囲は端から端まで幅広いからなぁ。


 ひまわりとGOESって少なくともセンサ(AHI/ABI)のメーカーは同じだし、観測帯域もいくつかは共通だったり、多少の互換性はあるわけだけど、例えばひまわりが予備も含めて全損した場合って、軌道上予備のGOESを借りてくる、みたいなことは可能なんだろうか? アメリカは国土が広いというのもあるので、観測衛星は東西のペアでかつそれぞれにバックアップがいるので、軌道上には予備が2機ある。事務仕事(スロットの管理とか)さえクリアできれば西側の1機をもう少し西に寄せてもらうとかはできそうだが……

 ひまわりは日本だけで使っているシステムじゃないし、影響力も非常に大きいから、理想的には軌道上に3機以上を置いて、同時に2機は観測してステレオ視や高頻度観測を実施して、片方が止まっても観測は中断を挟まずに継続して、トラブルが長期化しそうであれば予備機を立ち上げて、みたいに運用するほうがいいんだろうけどな。ひまわり11号以降で純国産化するなら「いよいよやばくなったら最悪GOESを借りて解析に突っ込む」的な運用も難しくなるし、オーストラリアあたりにも呼びかけて軌道上に常時3機おいておくような運用にできないものか。

 日本の気象(weather)衛星はひまわりだけだけど、気候(climate)観測を目的としたものとか、あるいは海外のLEO気象衛星も含めれば断続的とはいえ日本周辺を観測できる衛星は色々と飛んでいるし、静止気象衛星が使えなくなったとしても、直ちに気象予報が許容できないほどに劣化するというわけではないんだろうけれども。少なくとも、いくつかの周回衛星は気象庁のモデルに組み込まれているはずだし。だから9号機の設計寿命を超えて10号機の打上げを遅らせようみたいな話も出てくるんだろうし。


 GOES-17 - Wikipedia #Malfunctions

 GOES搭載ABIでも熱管理のトラブルがあったらしい。推定される原因はループヒートパイプの流れがFODで阻害されたのではないか、とか。ただ、これは純粋に放熱量が減るものだから、ひまわり9号みたいに単発で発生するものとは種類が違うけど。



 YouTube、スマホのYTMで音楽聴きながらデスク外で作業して、机に戻ってきてからPCのYouTubeでBGVを再生しようとすると「別の場所でアカウントが使用されています」的なエラーが出てきて再読込しないと駄目なの結構不便。最近のYouTubeは再生位置が残るとはいえ、時々滅茶苦茶な場所に飛ばされることもあるし。何が面倒って再生画面を再読込しなきゃいけないのが面倒。なんで再開できないんだよ。

 アカウントを複数人で共有してるわけじゃないんだから、「別の場所で再生してる? うっせぇ!そっちを止めろ!!」的な運用でいいはずなんだけどな。



https://www.jstage.jst.go.jp/article/jie1922/37/5/37_5_280/_pdf

「ガスタービンに関する最近の諸問題」(1958年)

 この表題で講演を引き受けたが、問題点が特に思いつかない、とのこと。強いて言えば使用実績が少ないところかな?とか。この頃の実用ガスタービンの例が色々と書いてある。発電用とか、コンプレッサー用とか。

ガスタービンはそれらの要素を作動流体の通路であるダクトと動力伝達を行う軸とで、色々に組み合わせ、結合したものであり、それらの組み合わせ方で色々のサイクルもできまた同一サイクルでも部分負荷性能、回転数特性などきわめて広範囲にかわった性能を持つことを作ることができる。その変化の範囲の広いことは非常なもので、真空管、抵抗、コンデンサ、コイルの組み合わせで全く異なった特性を持った回路を作ることのできる弱電回路とよく対比される。この点はガスタービンの一大特色で、他の原動機がたとえばピストン式内燃機関、蒸気タービンといえばそれぞれかなりはっきりと性能が決まってしまうのと全く異なるところである。

 弱電回路は同じ部品をシリーズやパラレルに使って色々組めるのでさすがにそこまで自由度が高い熱サイクルは実用的な意味は無いとしても、まあ、そういうふうに作れないこともないか。 

 ガスタービンを航空機に使う場合、出力あたりの重さが軽いことと、高高度では空気温度が下がるから圧縮比を高くできる(断熱圧縮でより大きな圧縮比(=温度差)を設定できる)ことから地上用よりも効率が高くなる。

「このように弾道兵器の原動機やごく小型の軽飛行機などを除けば、ほとんどの航空原動機界は内燃タービンの仲間で占めてしまったといってよい。しかし航空用以外にはこのように圧倒的に使用されるというような分野はない」

 その他の用途についてもいくつか。冷却水が不要なので砂漠等での発電で使っているとか。

 圧縮機やタービンの効率はほとんど限界に達していて、あとはタービン入口温度をいかに高くできるかにかかっている。



 ターボプロップとかターボファンとか、エンジンの前にプロペラ(ファン)がついているトラクター式が多くて、プッシャー式ってあんまり見かけない気がする。特にターボファンの場合、コアの中央に低圧シャフトを貫通させなきゃいけないから、構造的にデメリットが大きそうな気がするのだが。

 ターボファンの場合、周囲にカウリングがあるから、トラクター式では流れ(特にファンの後ろ)を時間をかけて整流しやすい、という利点があるのかな? 流れをきれいにすればその分効率化や低騒音化が可能になる。

 ターボプロップの場合は、コアの中を貫通させているわけではなくて、平行軸にオフセットして、その間で減速させたりするから、コアを貫通するような構造上のデメリットは少なそう。

 そういう諸々のバランスを考えると、トラクター式のほうがいいよね、みたいな結論になるんだろうか。


 古い資料(80年代中頃)だと中型機の後方(与圧区域より後ろ、ペラ等が飛散しても与圧区画を貫通しない)にプロペラを配置したプッシャー型ターボプロップ機のイラストがあるけど、普及していないところを見るとトータルで大した利点はなかったんだろうな。飛行機の大型化・高速化でターボプロップ機では厳しいというのもあるだろうし(実際には思ったより小型機のレンジが広がらなかった、という感じか)、他にも、より効率を求めるのであれば胴体の後ろに小径のプロペラをつけるより、主翼の上とかに大径のプロペラを付けたほうが燃費がいいだろうし。


 特殊な例として、P&W PT6がある。普通は前から吸い込んだ空気を後ろに流しながら圧縮・燃焼・膨張を行って高圧タービン(圧縮機用)や低圧タービン(出力用)を駆動するわけだけど、PT6は後方で空気を吸い込んで前に向かってサイクルを進めて、前方から後ろ向きに排気を出す。この場合、低圧タービンが一番前につくから、最短距離の出力シャフトで伝達できるし、コアを貫通させたり長いシャフトで引き出す必要がない。気流を大きく曲げるからFOD対策にも良さそう(質量の大きな粒子は曲がりきれずにトラップできる)。遠心式圧縮機とかタービンの周りに燃焼器がついているとか、大型化するのは厳しそうなデザインだけど、小型機で使うなら問題ないだろうし、売れてるってことはやはりメリットが大きいんだろうな。


 船舶の電動化と同じように航空機でもガスタービンで発電してモーターでプロペラを回そうみたいなシステムもあるし、絶賛開発中だろうから成立する見込みはあるんだろうけど、途中でエネルギー変換を重ねるから効率が悪そうな気はする。小型機で大径ペラをギヤで減速して高効率で回そうとすると機構部の質量が増えるけど、電気を経由すれば比較的簡単に回転数を制御(減速)できるみたいな利点はあるのかな。


 航空機だと運動エネルギーが大きいし軽量化の要求が大きいけど、船舶は逆に運動エネルギー(位置エネルギー含め)が大したことなくて、軽量化の要求も小さいわけだから、ガスタービンより原子力のほうが合いそうな領域ではありそう。それこそ小型モジュール炉で発電してモーターで駆動して、とか。アクティブに動く場所が少ないSMRなら故障の可能性も低いから予備電源もかなり小さくていいだろうし。ただ、船舶の場合は遠洋で沈没したりする可能性を考えると、大きな水圧で圧壊しないような構造(適当な差圧を超えると海水を引き込むとか)が必要になるから、陸上用と設計の共通化ができなくて、単価が厳しそうではある。


***


 L1Cの相関のテスト

 相関値は非正規化なので、高さはあまり意味はない(CPとCDは相対的に比較できるはず)。

 C/Aに比べて狭いスペクトルのCP/CDが得られている。

 L1CはL1 C/Bと同じように1.023MHzの正弦波を重ね合わせてあるけど、CPは1.023MHzと6.138MHzが適当な割合(1MHzが多い)で乗っている。ただ、今回は1.92Mspsだから、単に1.023MHz100%で近似している。送信出力が同じならCPのほうが相関値が低くなるはずだけど、実際にはCPの方が高い。送信出力の違いかな?

 とりあえず、C/Aと同じドップラと思える場所にピークが出ているから、QZSS L1Cの拡散符号は正しく生成できているはず。

 拡散符号の生成はソフトウェアで実装すると結構シンプルだけど、これをハードウェアで実装しようとするとかなり面倒くさい気がする。送信側もどうやって変調しているのか気になるな。C/Aみたいにシフトレジスタで作れる符号列じゃないから、ハードウェアでやろうとしたらROMに持っておくくらいしか考えられない。あるいは初期化に100秒以上かけていいなら比較的シンプルに作れそうな気もするけど。


 ドップラスキャンで出るスペクトル幅が狭いからスキャンは大変そうだ。どうやって取得するのがいいんだろうか。先にC/Aで受信機の位置・時刻・速度を決めておくとか? なんか本末転倒な気もするけど。



 L1Cのスペクトル。縦軸は任意の値。横軸は周波数(MHz)。左右対称なので片側だけ。1.023McpsをNCOでサンプリングレート変換(25Msps)してFFTに通した形。L1C/Aも同じ形のはず。


 自己相関のピーク。縦軸は任意の値。横軸はミリ秒。


 同様に、L1C BOC(1,1)のスペクトルと自己相関。L1CもL1C/Bもスペクトルや自己相関の形は大して変わらないはず。自己相関は周期が違うけど、チップレートは同じだから、メインローブのエンベロープは似ているはず。

 BOC(1,1)はメインローブの±0.5us(±150m)の場所にサイドローブがあるから、綺麗な形のメインローブを期待したアルゴリズムを組んでいると、正常に処理できない。

 あと、DLLのEarly/Lateを±0.5chipsに設定していると、相関値のちょうど切れ込みの部分を見ることになるから、特性が悪くなりそう。それに、Sカーブの形も多分想定と違った形になる。BOC(1,1)をDLLでロックしたい場合、±0.25chipsとかの場所を見ないとダメそう。

 スキャンしてロックするときも、FFTで探して見つけたピークから±1chips程度の範囲を0.1chips間隔くらいで全部相関値を取って、一番高いピークを探す(サイドローブを棄却する)ような処理も必要になるはず。

 簡易的にL1C/Bを受信するならC/Aコードのチップレートを2倍にすれば良いけど、正常に受信したいならかなり大変そうだ。L1CもQZSSから受信したいなら同様。



 実際の信号から、FFTで見つけたピーク値の±6chips位の範囲を、適当な間隔で位相をずらしながら相関

 なんか変な形。3個連なった高いピークが2つのサイドローブとメインローブだろうけど、サイドローブの高さが結構違う。あと、サイドローブの前にもう一つ山がある。


 試しにPRN 4(GPS 3-1)でドップラスキャン

 L1C/AもL1Cpも同様にピークが出る(縦軸は任意の値)。

 ただ、PRN 4はBOC(1,1)は無いけど、時間軸のデータを見ても、妥当性(納得感)のある結果が得られていない。


 デバッグ用に簡単なコードを書いてみたら、全く動かね。。。CDMAの復調ってこんなに大変だったっけェ??


***


 C#のRichTextBox、Textを書き換えても字面が似ていればスクロール位置は概ね維持されるんだな。ちょっとずれる時があるけど。元々TextBoxで作っていて、TextBoxはTextを書き換えると一番上までスクロールされるので、それを防ぐのに色々ググってたんだけどやり方が分からず、RichTextBoxならそれっぽい挙動が作れるらしいのでRichTextBoxに変えたら、そもそも何もやらなくてもスクロールを維持できるじゃん、という発見。これだけで丸一日無駄にしたような気がする。。。

 ただ、RichTextBoxでも字面が大きく変わるとスクロールが少しずれることがある。それが嫌な場合は、

static Point GetScrollPos(RichTextBox richTextBox)
{
    const int EM_GETSCROLLPOS = 0x4DD;
    SendMessage(richTextBox.Handle, EM_GETSCROLLPOS, 0, out var b);
    return b;

    [DllImport("user32.dll", CharSet = CharSet.Auto)]
    static extern long SendMessage(nint hwnd, int msg, int wp, out Point lp);
}

static void SetScrollPos(RichTextBox richTextBox, Point b)
{
    const int EM_SETSCROLLPOS = 0x4DE;
    SendMessage(richTextBox.Handle, EM_SETSCROLLPOS, 0, ref b);

    [DllImport("user32.dll", CharSet = CharSet.Auto)]
    static extern long SendMessage(nint hwnd, int msg, int wp, ref Point lp);
}

 みたいなメソッドを用意して、GetScrollPosで取ったスクロール位置を、Textを書き換えたあとでSetScrollPosに投げれば、スクロール位置をかなり忠実に維持してくれる。ただし描画範囲の前の部分でテキストが書き換えられた場合は、もちろん表示内容自体がズレる。

 TextBoxの場合、SendMessageでEM_GETSCROLLPOSを呼んでも正しい結果が得られない。EM_SETSCROLLPOSも期待したとおりに動かない(反応がない)。おそらくRichTextBoxでしか対応していないと思う。ただ、TextBoxに対してもEM_GETRECTみたいな呼び出しは動いているみたいだから、TextBox自体がSendMessage系コマンドに非対応、というわけではないらしい。いまいちよくわからない。


 SendMessageみたいに色々な型のポインタを渡すような場合は、DllImportでメソッド内に定義するやつのほうが便利そう。LibraryImportだとメソッド内に定義することができないから同じ名前が大量に出てきて面倒なことになりそう。LibraryImportはunsafe前提だから、むしろポインタで宣言してゴリ押しするという手も……



 C#のパターンマッチングのvalue is >= 10 and <= 20みたいな範囲指定の構文、もう少しわかりやすい構文無いものかなー。良い書き方は全く思いつかないけど。value is 10..20とかvalue is not 12.34..56.78みたいな感じとか? そういう書き方がC#的に実装できるかどうかは別として。<や<=は境界値を明示できるのが良さそう。Rangeみたいな書き方は境界値がうまく表現できない。


 宇宙船演算子 - Wikipedia

「.NET FrameworkではCompareToメソッド[9]が同じ働きをする」

 .NETのCompareToって結果はあくまでも「負数」「ゼロ」「正数」としか規定していないから、宇宙船演算子みたいに例えばswitchでcase -1: break; case 0: break; case 1: break;みたいに分岐できなくて、「同じ働き」とは言えない気がする。最近のC#のswitchだとパターンマッチングで負数、ゼロ、正数にマッチできるから似たような使い方ができないわけじゃないけど。

 基本的には-1,0,1を返すことが多いだろうけど、とはいえ例えばintの比較ならreturn value1 - value2;を返してもいいわけだし(キワでバグるけど)、文字列の比較ならC言語のstring.hのstrcmpみたいな結果をそのまま返したっていいわけで、このあたりはライブラリとか実行環境に依存しているから、呼び出す側はあくまでも符号だけ(&ゼロかどうかも)を見るしかない。

 実際のところ、機械語レベルまで行けば-1,0,1を比較するのと負数、ゼロ、正数を比較するのでは、後者のほうが楽そうな気もする。厳密に-1,0,1で分岐するには1を足してゼロなら-1、1を引いてゼロなら1、どちらでもなければゼロ、みたいなロジックのはずだけど、負ゼ正で分岐するならゼロに対する比較を行って、ゼロフラグが立っていればゼロ、マイナスフラグが立っていれば負数、そうでなければ正数、みたいに分岐できるはず。CPU依存なので実際どういう処理になるのかはわからないけど。



 プログラムで変数を非表示(触るとコンパイルエラー)にするような機能が欲しくなるときがたまにある。例えばint i = 123; Console.WriteLine(i); delete i; Console.WriteLine(i); double i = 123.456;みたいな感じで、適当な構文で変数名を削除すると、その後に読んだり、新しく作ったりするとコンパイルエラーになる(IDE上でもIntelliSenseで見えなくなる)。ちょっと長いメソッド内の最初の方でしか使わない変数が後ろの方で見えるのがウザいときに使ったりとか。そういう場合はメソッドを切り分けろよということで必要ないんだろうけど。


***


 2018年頃に俄に話題になっていたような気がする、USB-VGAアダプタを使った送信機、そういえばそんなのあったなぁ、と思ってamazonで探したらドングルが売ってたので、試しに購入してみた。

 使っているチップがFL2000という型番なので、これを使ったトランスミッタはfl2kと呼ばれるテクニック。

 Windowsからはうまく動かなかった。zadigでドライバを入れ替えるとエラーメッセージが変わるけど、正常動作ではない。

 試しにUSBメモリにUbuntuを焼いて、ライブUSBで起動して、ソースコードからビルドしてみると、実行時にUSB周りのエラーが出た。それと一緒にusbfs_memory_mbを書き換えろみたいなメッセージも出たので、それに従って設定を変えたら、ちゃんと動くようになった(メッセージではechoで書き換えろと表示されていたけど、sudo echoではうまく書けなくて、sudo viで書き換えた)。本当に動いているのかはわからないけど、少なくともfl2k_testで50MHzの正弦波が出て、Ctrl-Cで止めれば止まる。


 100Mspsで50MHzを出して、イメージが-30dBあたり、というような感じ。

 バイアスが0.7Vあたりなのがちょっと謎い。VGAってもう少し低いはずなんだけど(1MΩで受けてるから2倍になったと考えれば、正常かも)。



 ということで、Windowsで動かすには工夫が必要そう(or現状動かない)、Ubuntuで動かすなら割と簡単、という結果が得られた。USB 3.0接続で10Msps~150Mspsくらいで出力できるDACとして使えそう。

 しかし、Ubuntuかぁ…… Windows側もzadigの設定とかいじる余地はあるから、もしかしたら動くのかもしれないけど。


 今回買ったドングルはamazon.co.jpでレビューも多くて、結構数売れてそう。順当に在庫があるなら当面は入手できるかな? はんだ付けは綺麗だけど、底面パッドがスカスカだったり、Dsub mini15の補強端子がはんだ付けされていなかったり、値段なりではある。


 今回は手持ちのUSB 2.0のメモリにUbuntuを入れてたけど、結構使いやすかったし、SDカードに入れて持っておくのも良さそう。ノートPCはUSB 3.0対応だけど、USB端子は2個しかなくて余裕がないから、これは開けておきたい。充電対応のType-Cもあるけど、これは電源として使っているから、USBメモリを差すのには不適。バレルジャック経由でも給電できるけど、ACアダプタ使うのメンドクセ……

 そういえば、夏頃に中古のノートPCを買ったけど、一通り動作確認してから……とか考えてる間に失念して書いてなかった気がするな。こういうことやろうとするとソフト的に多少壊れても問題ないパソコンが有ると便利。その目的で買ったNUCはSDR用のアダプタに使っちゃってるしな。。。あと、キーボードとかディスプレイとか色々考えずに気軽に使えるノートPCはやっぱり気軽に使える。キーボードやトラックバッドのクセが今まで使っていたものと異なるので使いづらくはあるけど、とはいえ北海道じゃ現物を確認して買うってのも難しい御時世だからねぇ。運試しと思って買うしかない。


 ライブUSBって保存領域を設定しない場合は設定やデータが保存されないらしいけど、これって逆に言えば電源ブチ切りとかあるいは起動中にストレージを抜いても問題ない、みたいな使い方ができたりするんだろうか? そういうふうにググってもいまいち情報が出てこない。スピーカーからブチブチ音がする、とかそういう記事ばっかり。ライブCDとかライブDVDなら書き込みができないから明らかに問題ないけど、リムーバブルディスクだとどうなるんだろうか。


 UbuntuってSDカードにインストール(ライブUSB的な動作でなく)はできるんだろうか。その状態でSDカードの優先度を上げておいて、カードが入っていればUbuntuが起動、それがなければWindowsが起動、みたいな。

 WindowsとUbuntuのデュアルブートに関する記事で、Windowsが入っているドライブを物理的に外してからUbuntuをインストールしたあとでWindowsも接続してBIOSで選択する、みたいな解説もあるから、SDカードの有無で起動OSの選択はできそうな気がする(BIOSからSDカードが見える必要があるけど)。デスクトップPCのHDDならSATAコネクタを抜くだけで切断できるけど、NVMeは着脱がちょっと面倒。ノートPCだと底面パネルを開く手間も増える。

 NVMeをカートリッジみたいに気軽に交換できるラップトップとか無いものかな。FrameworkのStorage Expansion Cardが「高速だからOSの起動にも良いよ」(意訳)みたいなことを書いてあるから、これを使って追加のOSをインストールするとか、あるいはカードを交換していろいろなOS環境を交換したりとかもできるんだろうか。Framework Desktopも正面にスロットが2個あるからこれにOSを入れておけばOSを交換できそうだけど、Desktopの拡張スロットは交換が難しそうだ。

 あるいはそもそもSDカードとかUSBメモリなら、ISOを焼くときに保存領域を設定しておけばインストール作業不要でそのままOSとして使えるのかな?