2024年3月13日水曜日

小ネタ







 NHK福岡のラジオ第2がスウェーデンで聴こえた件


 AMD、次世代ローエンドFPGA「Spartan Ultrascale+」を発表 | TECH+(テックプラス)

 すでにXilinx(というかAMD)にとって唯一のGlue Logic向けチップという感じになっており

 他のやつが性能高すぎてグルーロジックに使いたいなら一番下のモデルしか選択肢がないってところだろうけど、それにしたって凄まじいスペックよね。PCIe Gen4x8とか、LPDDR5 4266Mb/sとか、何と何をつなげるんだって感じ。一言でグルーロジックと言っても、組み込み分野とデータセンター分野ではスケールが相当違いそうだ。

/* 某R社の組み込みグルーロジック向けのFPGAどうなってるんだ。デザインツールやデザイン例は公開されているけど、チップ自体はまだ売ってないんか? */


 ドローンアートの空想。農薬散布用のドローンで雪原に融雪剤を撒く。巨大な水墨画みたいな絵を書ける。気の利いたドローンなら育成状況に応じて薬剤の散布量を調整する機能があるから、その機能を使えば濃淡を調整できるから、絵をかける。普通の融雪剤なら水墨画風になるけど、色のついた粉末を使えばフルカラーで書ける。べつにドローンである必要はないけど、雪面に綺麗に(足跡とかの痕跡を残さずに)絵を書こうとするとドローンが一番楽なはず。

 大面積に大量に迅速に簡単に散布できるデモとして面白そうではある。複数機を同時に飛ばしたりとか、いろいろアピールできる点は多そう。話題性としても強いから広報的にも強いだろうし。どっかのメーカーでやらないかな。DJIとか。


 FIRをアセンブリで実装しようと思って、アセンブリの勉強とかいろいろ。

 宣言だけC++のテンプレートでやって、実装をアセンブリにやろうと思ってたけど、テンプレート引数で整数の値を変えると名前も変わるからめんどくせーんだよな。まあ、それがテンプレートだからしょうがないんだけど。

 とりあえず配列を2個受け取って、片方をFIRに通してもう一方に結果を書き込むような処理をインラインアセンブリで書いてみた。8%くらい早くなった。効果が見える程度には早くなるけど、わざわざアセンブリで書くほど効果があるかというと微妙なところ。むしろ一切最適化していないCコードがアセンブラより1割弱遅いくらいで展開できるんだな。

 FIRは一番サンプリングレート低い場所で使うから、多少最適化したところであんまり効果もないし。とはいえ20%くらいの負荷があるから結構大きいけど。ADCから128分の1くらいまで落としてそれでもなお20%の負荷は結構でかい。


 今週ちょっとドタバタしてて作業時間削られたとはいえ、それにしても得たものが少ない。単位時間あたりの作業量が年々低下している気がする。6,7年前はもっと色々ぽんぽん作ってた気がするのに。


2024年3月6日水曜日

小ネタ










 空力の専門家…… いや、まあ、そうなんだけど。レッドブル・エアレースの関係者ってF1にアサインされたのかな。それともレッドブルはエアレースは主催であって技術者はいなかったのかな。

 システムとか画角とかもうちょっと調整したら良さそうだが。試作段階だと画角が水平寄りで遠くまで見えてて速度感があってよかった。本番のは画角が低くて視界が狭いからあんまり速度感が無い。もしかしたら気象の関係で実際に遅いだけかもしれないけど。



 最近の戦闘機(F-22やF-35)は複座型が無いから広報的には厳しいよねぇ。アメリカ空軍や海軍の広報でYouTuberや著名人をF-16とかF/A-18に載せたりはしてるけど、最近の戦闘機は下から眺めるしかできないからなぁ。今後単座戦闘機が主流になると、民間人が戦闘機に乗れるのは今のうちかな?


 Razerのマウスのエンコーダ、試しにamazonでそれっぽいエンコーダを買って交換してみた。商品写真が左右反転されているのに気が付かずに買ったせいでちょっと手間取ったけど、問題なく交換完了。無事ホイールでスクロールできるようになった。クリスプ感があまりなくて、なんとなくヌメった感じ。あと、ちょっと重い。もうちょっと軽いほうが好みだな。

 自作キーボードはジャンルとしてある程度確立されている感があるし、キーの操作感やキートップのデザインとかはいろいろ選択肢があるけど、マウスってどうなんだろうか。性能を気にしないのであれば例えばBambu Labのキットを買うとかできるけども。あるいは安物のゲーミングマウスをドナーにしてとかもできるけど、それにしたってガワを作るだけだしな。スイッチとかエンコーダとかを好みのものに変えるみたいな製品はあまりなさそう。

 ちなみに、今回買ったエンコーダ、マレーシアの倉庫から送られてきたけど、前に別の出品者から買った別の部品と同じ発送元だった(住所や電話番号が同じ)。住所でググったらクアラルンプール国際空港が出てきた。まさか航空便で送って20日弱かかるわけもあるまいし、船便だと思うんだけど。空港の近くに物流倉庫みたいなのがあるのかな?

 そういえば、DELLの液晶は拡散シートに変なシミがあるし、昔買ったIntel CPUは不良品だったし、思えばPC関連で不良品買いがちだなぁ…… 日頃の行いが悪いから。。。


***


 ダイレクトサンプリングのスペクトル

 ADCはフリーランさせている。6bitなら4.72Msps、8bitなら3.863Msps。6bitは+12dBで8bitに合わせてある。やはり分解能が低いと特性も悪くなる。あと、ノイズらしいスペクトルも色々出てくる。1440kHzとか1602kHzは6bitでは見えなくて、8bitが必要になる。

 1.78MHzと1.88MHzあたりにも鋭いピークがあるのが謎い。後者はアマチュア無線の1.9MHz帯に近いけど、1.88MHz付近は使えない。わざわざバンドプランから除外してるってことはなにか別の用途で使っていて、それが見えているのかな。1.88MHzでググったらいろいろ出てくるけど、いまいち何に使ってるのか見えてこない。

 SNRは入力レベルが低いのが問題だから、もう一段増幅してやればいいんだけど。ただ、前回作ったときに3段では発振してしまったような記憶がある。ということで今回は2段(DC付近で4096倍)にしている。ADC分解能が高ければその分SNRも稼げるけど、今度はADCのサンプリングレートが問題になる。デュアルADCなら単純にサンプリングレートが2倍になるけど、Nucleo-G474REのピンアサインだとデュアルADCは結構難しい。

 アナログ周りが結構面倒で、もういっそコンパレータで2値化してフルデジタルで処理してもいいんじゃね、とか思ったり。ADCのサンプリングレートでも処理速度が足りないんだから、さらに高いサンプリングレートを処理できるわけないんだけど。

 今回は2段のRF増幅段で4倍から4096倍(12-72dB)まで11段階に対数で直線状に設定できるようにするために、1段あたりPGAを2個使っていた。ただ、4096倍でもゲインが少し不足しているから、多段階の設定はあまり旨味がない。これを例えば増幅3段で8192倍から262144倍(78-108dB)まで6段階に対数で直線状に、みたいなコンフィグをして、増幅率のレンジを狭くするかわりにOPAMPの使用量を減らすこともできる。ただ、1万倍あたりまでいくとサチりそうな気がする。さらに高い増幅率だと確実にサチる。途中の増幅率を下げて例えば2048倍から65536倍の範囲とか、512倍から16384倍とか、適当に選べばいいんだけど。この構成の利点はOPAMPの組み合わせが多少自由になるので、デュアルADCがやりやすくなる。デュアルADC12bitはシングルADC6bitよりもサンプリングレートが高いから、エイリアスがより遠くなるし、データ自体の分解能も高くなる。ただしデータレートが高くなるとCICのNを大きくできなくなるし、情報量が増えるからRも小さくしなきゃならない。


 CICの計算、R16, N4で入力がint8_t[n]とint8_t[n][2](ローカル)、出力がint32_t[n/R][2]で、実数と複素数のミキサを兼ねた処理を、4096ポイント8ブロックの処理に対して行ったら、3.41ms(@Cortex-M4,170MHz)くらいだった(R,Nを含めて積分器・微分器はベッタベタのベタ書き)。このCICに100%の計算リソースを与えた場合、9.6Mspsくらいを処理できる計算。ただしこの計測はADC(DMA転送)を止めた状態で行っているので、実際にはアービトレーションでもう少し遅くなる。

 32bit幅の複素数を4段の積分器に通す場合、Cortex-M4が持つ汎用レジスタに必要な情報がおさまるから、ロード・ストアをかなり少なくできる。ただ、途中の値を配列で持つといちいちストアが入るから、計算速度が2倍くらい遅くなる。コードを書くのが非常に面倒くさいけど、全部ベタの変数で持つ必要がある(N4の複素数で16個必要だから、地味に面倒)。

 おおよそ17.7クロック/サンプルで処理している。積分だけ考えるなら、1サンプルあたりロード3回(実数のサンプルと複素数のローカル)、積2回(ミキサ)、加算8回(2N)、という感じなので、単純計算で13サイクル必要。追加でサンプルやローカルのポインタの管理もあるし、ループカウンタや微分器の処理も(16分の1とはいえ)必要だし。ということで、ほとんど無駄なくCIC処理が動いている感じ。

 ちなみに、途中で使うレジスタを64bitにすると、処理時間は17.5msくらいになる。5倍くらい遅くなる。レジスタに乗り切らないからロード/ストアが必要になるし、加算も2回必要になる。91クロック/サンプルくらい。32bitコアで64bitのCICは32bitに比べて数倍遅いけど、とはいえ例えば32bitでまず5分の1に落としてやれば32bitと同等の処理速度になるから、ダイナミックレンジを広く稼げる64bitを使ってもいい。


 ADC(8bit), local(7bit, table), CIC(R8, N4), local(7bit, NCO) CIC(R16, N4), FIR(R2)でデシメーションして複素数をDACに出力

 DSB復調なのでキャリアのビートが出ている。22Hzくらいズレているのかな。567kHzを受信して22Hzのズレってことは40ppmくらいのクロックエラーか。まあそんなもんだろう。

 DACは約15.1kspsで駆動しているので、7.55kHzあたりで折り返してエイリアスが出ている。FIRで6kHzくらいのLPFを通しているので、3kHz幅くらいのノッチがある。外付けのLPFを作るのも面倒だし、FIRの後ろにもう1回CICを追加してインターポレーションするほうがいいかな。計算リソースと要相談。現在でも96%くらい使っているから、あんまり余裕はない。1chだけでいいならFDMA使えばいいんだけど、2ch出そうとするとちょっと面倒。今はデバッグ用にI/Qを出しているだけであって、最終的には1chだけ出すようになるはずだから、そうなればFDMAでインターポレーションすればいいはず。

 FIRはCICを補償するような特性なので、いちおうRF入力に対してフラットな周波数特性になっている(DACのSincは未補償だけど、DACのサンプリングレートはもっと高くする予定だから、フラットな領域を使えるはず)。


 周波数特性の設計はこんな感じ


 1個目のサイドローブが-50dBくらい。2段目のCICのNを増やせばもう少し下がるので、計算リソースと相談といったところ。実際どのくらいが必要なのかもわからないしな。50dBも落ちてれば十分な気もする。ただ、RF増幅段の特性で数百kHz離れると20dBくらい差があるから、周波数が高い方を聞いてると下の方が-30dBくらいになるから、周波数によっては妨害が入るかもな、という感じか。1個目のサイドローブの中に27kHzが入っていて、これが-75dBくらいだから、3ch離れた場所で放送があると搬送波が3kHzの可聴帯に入ってくる。

 一応FIR(±20%LPF)でCICを補償しているけど、N4くらいならほとんどフラットな感じ。


 計算リソースが結構ギリギリ。現状サンプリングレートは約3.86Mspsで、できればもう少し高くしたいけど、厳しそう。FIRがもう少し最適化できそうだけど、一番サンプリングレートが低い場所だから大して効かなそうだし。


 夕方にデバッグしてて、北海道でもまだまだ明るい時間帯(1720とか)なのに急に東京からと思われるピークが出てきたりして、電波伝搬っておもしれーなー、と。電離層の変化は紫外線とかの強さの問題なわけで、可視光では昼間でも紫外線で見ると入射角が低くなればその分減衰も強くなるから、単に夜だからとか昼だからみたいな感じじゃないんだろうな。昼間は旭川の数kWとか札幌の100kWとかしか受信できないのに、ある時刻を過ぎると北海道の他の弱い局や本州の方らいし周波数に由来する線スペクトルが大量に出てくるから、処理ミスってノイズが大量に入ったのかと思う。

2024年2月28日水曜日

小ネタ




 前方オーバーヘッドパネルの左上。見づらいけど、右側の赤いスイッチカバーと下段の黒の2個のカバーにシアワイヤがついている。赤がフラップの代替制御、黒がスポイラー格納。


 017 | Boeing 737. overhead panel. | liveview86 | Flickr

 中段左寄りの赤いスイッチ2個(バッテリ切り離し)にもシアワイヤがついている。

 赤いスイッチカバーは見える範囲で4個、すべてシアワイヤ付き。黒いスイッチカバーは見える範囲で7個、シアワイヤ付きなのはその内2個。シアワイヤがついていないカバーにもシアワイヤ用の穴が空いているけど、1個(一番左上のやつ)だけ穴が見えない。穴のあるカバーもパーティングラインとか穴の位置で微妙に違いがある。いろんなサプライヤが供給してるんだろうな。穴がないやつが混ざってると在庫管理が面倒そう。


***


 Google検索、バグなのか仕様変更なのか、"filetype:pdf"の効きが弱くなっているのがすっげー不便。ちょっと特殊なキーワードとかはPDFで探せばたいてい見つかる場合が多かった気がするけど、filetypeの強制がなくなって通常のHTMLも検索対象になった結果、似たような語感で全く無関係のページが大量に出てくる。


 製品紹介 Products|セイフティSBU|株式会社ダイセル

 火工品を扱っているメーカーの製品情報。いろいろと面白そうなデバイスが。

 パイロスイッチなんてあるんだな。火工品でピストンを動かしてバスバーを切断し、切り抜いた導体で次のバスバーを接続させる。大電流を扱えるし、一瞬(200us未満)で回路を切り替えられる。遮断だけまたは導通だけの製品もある。


 ren | Microsoft Learn

注意 このコマンドは rmdir コマンドと同じです。

 ……そんなわけないやろ??? 英語版だと「This command is the same as the rename command.」という表記。(rmdirはディレクトリ削除コマンド)


 8.126MHzあたりのオシレータって普通に売ってるものだと思ってたけど、全然売ってないんだな。DigiKeyでも1種類しか取り扱いがない。ルネサスのPLLオシレータだそう。もうちょっと普及してるものだと思ってた。PLLオシレータがアリならSiTimeのMEMSとかも選択肢に入ってくるだろうから、これらを含めていいならもう少し多いけど。


 STM32、使うの久しぶりすぎて開発環境整えるのもだいぶ苦労してる。CubeMXでコード生成してmakefileでビルドしてるけど、今どきのSTM32開発環境って何を使うべきなんだろうか。CubeMXで選べるライブラリが長らく保守されてないっぽいし、別の方法を使うべきっぽい気がするけど。それともF4とかG4とかのあたりは保守する気がないだけで、新しいマイコン使えってことなんだろうか?


 makeでビルドするとものすごい時間がかかる。クリーンビルドで10分以上かかる。遅いと1ファイルのコンパイル(ソース→オブジェクト)に数十秒とか数分とかかかる。試しに-ftime-reportをつけてみたら、G++の自己申告だとwallで1秒未満しかかかっていない。で、-ftime-reportを出力してから次のg++の呼び出しがかかるまでに相当長い時間がかかっている。ということは、g++の問題じゃなくて、makeの問題ってことか。


 WSLでホットリロード効かない or コンパイル遅すぎ問題 #webpack - Qiita

 WSL(WSL2)でビルドが遅くて重くてホットリロードが効かないとき #React - Qiita

 このあたりが原因っぽいなー。しかし、前にやったときは遅いとか全然感じなかったんだけど。ここ1年あたりでファイル処理周り変わったのか?


 どうしたものかなーと思いつつ、試しにcygwinをインストール。12分とかかかってたクリーンビルドが20秒ですって。めっちゃ早いじゃん。-j19で並列化すれば8.5秒程度で終わる。もちろん通常のビルドならさらに早い(3秒弱)。

 WSLを使っていたのってMicrosoft製のツールでmake使いたいだけだったしな。STM32の開発ならどうせCubeMXとかarm-none-eabi-gccとか外部ツールが必要だし、今更cygwinが増えたところで。

 Make for Windowsという方法もあるんだろうけど、もう20年近く更新されてないっぽいし、さすがに。

 あと、最近のVSCodeのIntelliSense用にWindows用GCCバイナリが必要だから、WSLから呼ぶLinux用バイナリと両方用意するのが面倒。cygwinならWindows用GCCバイナリを使うから、VSCodeと共有できる。


 STM32G4のADCで3.4Mspsでサンプリングして、フーリエ変換。

  HSI↑ ↓HSE

 64倍のPGA(GBW13MHz.typ)を2段で4096倍に増幅しているから、右肩下がりのスペクトル。

 HSIとHSEでスペクトルがちょっと変わる。HSEのほうがノイズが多い。HSIは周波数精度がだいぶ悪い(1900ppmくらい早い)。HSEは周波数精度がそこそこ高い(11ppmくらい遅い)。個体差とか温度特性とか色々あるだろうけど。

 外付け水晶は24MHzだから、数百kHzオーダーのノイズは問題ない程度だろうと思っていたんだけど、予想よりだいぶ影響がある。イメージ雑音なのかな?

 イメージ雑音を除去したいのであれば、例えばADCを駆動するTIMからDMAを蹴ってARRを書き換えてやればサンプリングレートをスイープ(リニアor離散)できるから、イメージのスペクトルを拡散できそう。ただ、目的のスペクトルは第1ゾーンに入っているとはいえ、LOもTIMに同期して動かさなきゃいけないのが面倒ではあるけど。1stLOはテーブルだろうし、ARRの周期とテーブルの長さを合わせればいいんだけど、色々面倒なことになりそう。

 ただ、ゾーン2以上のイメージを除去できるなら、逆に使えば任意のゾーンのスペクトル以外を拡散することもできるはずなんだよな。例えばゾーン2に同期してLOを振動させてやればゾーン1やゾーン3以上を除去できるから、ソフト的にアンダーサンプリング用のフィルタが作れる。しかし、計算量がなぁ。。。

 アンダーサンプリングなソフトウェア無線で、受信可能な帯域幅よりADCのサンプリングレートが低い場合に、ADCのサンプリングクロックを振動させてソフト的にイメージを除去する、みたいなソリューションってあるんだろうか? 素直に実装するならBPF通過帯域幅よりサンプリングレートを高くするべきだし、普通はそうするんだろうけど。

 1stLOが周期性として、その周期で位相が戻るような拡散パターンが必要になるのかな。パターンを作るのが大変そうだ。

 試しにアンテナを外してサンプリングしたら、HSEでもノイズがきれいに消えた。ってことは、基板内で入ったノイズじゃないのか…… 基板から放射されたノイズが2mくらい飛んでアンテナから入ったってこと? であるならダイカストのケースに入れれば十分シールドできそう。/* もしかしたらアンテナではなく、PGAの途中にオシロのプローブを当てていたのが原因かも */


 ADCの生データをオンチップでダウンコンバートしてCICに通してみた(間欠処理)

 567kHz(NHK R1、札幌、100kW)にピークが出てる。その隣の594KHzは東京のNHK R1(300kW)、その次は旭川のNHK R1(3kW)の621kHz。大阪のNHK R1(100kW)の666kHzのピークもある。まあ、周波数を見てるだけなので、本当にそこから送信された電波かどうかはわからないけど。

 とりあえずミキサとCIC(R16, N4)合わせてサンプリング時間の2倍程度の計算時間。全部forでループさせてるとはいえ、だいぶ遅い。これを最適化して3倍程度まで早くしなきゃいけない…… アセンブリ…… ウッ。。。


 前回DSP型AMラジオを作ったの、去年だと思ってたけど、一昨年だったか…… 前回は復調周りはある程度受信できるところまで作って、あとは液晶とかつないでスペクトルの表示とか作り始めて、結局中途半端なところで飽きてしまったので、今回はもう少し真面目に受信周りを作り込みたいな……


 STM32G474RE、アナログ回路いろいろ入ってて面白いのに、Nucleo G474REはピンアサインが厳しいのがつらい。G474REでアナログ電源周りちょっと気をつけたりして、特にアナログ回路の自由度高めのピンアサインのボードとかあると面白そうだが。さすがにQFP変換基板で使うのは面倒だし、とはいえ自分で基板を作るというのも……

 STBee F4miniみたいな感じでSTBee G4mini(STM32G474RE)とかあると便利なんだけど。最近ストリナはセンサ類も含めてあんまり新製品出してないしなぁ。


***


https://www.jstage.jst.go.jp/article/itej/69/3/69_185/_pdf

 NHKの中波ラジオの送信機の話。1本の空中線で2ch(R1とR2)を給電するための整合回路の例とかも。


https://www.jstage.jst.go.jp/article/itej1978/33/3/33_3_162/_pdf/-char/ja

 1978年。周波数拡散の方式の例とか。DS, FH, TH, TFH, pulse FM, FH/DS, TH/DS。

 TH(時間ホッピング)は装置が簡単に構成できる利点があるが、CW妨害に弱い。妨害対策ではなく多元接続が目的。FHと組み合わせてTFHとして使用される。

 pulse FMは情報通信で使う場合はチャープ方向(上り・下り)で情報を変調する。干渉やマルチパスフェージングに強い。情報通信に使われることは多くなく、レーダーで使うことが多い。

 FHやTHとDSを組み合わせたFH/DSやTH/DS方式。収容能力が高い。


 北海道の中波放送(AMラジオ)の周波数一覧

 横軸に周波数を、各線グラフで放送局を示し、データラベルには出力、所在地、コールサイン、周波数(一番下の行)を表示している。100kW以上のNHK(R1, R2)および在京3局は北海道外についても記載した。

 北海道の民放局(HBC, STV)はFMへの移行は表明しておらず、当面はこの周波数で放送が続けられるはず。この図中では在京3局がFMへ移行しAMを停止したいらしく、またNHKラジオ第2は2年後(2025年度末)に放送終了の予定らしい。アナログモードがどんどん減っていくなぁ……

 そのうちFMラジオも終了するんじゃね? とか思いつつ、まあ、これだけ大々的にFMへの移行を宣言してるんだから、「FMアナログ放送を終了します」とは少なくともあと15年は言えないだろうけど。想定としてはFM放送はISDB-Tsbでデジタル化したかったんだろうけどな。しかしワンセグでも430kHz、mmの3セグなら1.23MHzの帯域幅だから、FM放送の2倍に広がってしまう。電波仕様の効率化の面から見てもISDB-Tsbは厳しそう(ガードバンドが要らないから同一中継局からは6MHzあたり13ch詰め込んだり、SFNで中継したりで、トータルでは効率化できるだろうけども)。

 そういえば十勝NDBも廃止されたらしいしな。ググると2020年頃に受信報告があるけど、最新のエンルートチャートには乗ってない。北海道は十勝が最後の1個だったはず。近くに航空大学校の分校があるから、ナビゲーション機器の練習用にNDBが残ってたのかもしれないけど、とはいえ今の時代新しく練習するようなものでもないだろうし。他のエリアのチャートを合わせても、ナビゲーションの周波数の一覧にはNDBっぽいものは見当たらないから、国内のNDBは全部廃止されたのかな?


https://www.nhk.or.jp/bunken/book/regular/nenkan/pdf14/14_672_675.pdf

 NHKの主要な中継局の周波数、出力、コールサインの一覧。なあ、FMラジオの周波数、MHzとkHz間違えてんぞ。。。


2024年2月21日水曜日

小ネタ



 太陽ってすげーんだな。


***


 事故を防ぐにはどうすればよかったか。再発防止策をともに考察する【杉江弘×堀江貴文】 - YouTube

「シミュレータで確認したが、滑走路上に飛行機が存在すれば間違いなく分かる」という旨の発言、どういう状況設定をやったのか何も話してないからあれだけど、「USエアウェイズ1549便の事故をシミュレーションすると確実に飛行場に帰れるから、川に不時着した機長の判断は間違っている」みたいな雰囲気を感じるな。例えば着陸のシミュレーションを1千回やって、事前に何も説明せず700回目あたりで滑走路に飛行機を配置する、みたいな状況を想定した上で、それでも「確実にわかる」なのか、「滑走路上に飛行機がいるから探してみてね」を1回やるのかで結果は全く別になるはず。言わずもがな、前者のほうが実際の状況を反映している。まさか何百回もシミュレータをリセットして回すなんてことはやってないだろうから、件の発言は後者に近いはず。

 HUDに対して批判的なのも、いかにも老人って感じがする。「昔はそんなもの無かった(だから不要だ)」系の発言は時代が変わることを理解していない考え方のように感じる。そんなこと言ったら昔は航空管制だってなかったんだから、「昔に無かったものは今も必要ない」を適用するなら、飛行機は好き勝手自由に飛んでいいって話になる。そんなことをやって事故が多発したから色々な規則や機器が開発されてきたわけで。HUDだって今はPFDを表示するだけで邪魔だとか言われているにしても、あと15年とか30年くらい経てばFLIRを載せて、たとえ濃霧の中でも前方の飛行機やら障害物を見えるようなシステムが標準搭載になって、そういうシステムが無い航空機は大規模空港へのアクセスを禁止する、みたいな時代になるはずだし。

 飛行機だっていきなりライト兄弟がB737やA330を作ったわけじゃなくて、色々と進化して今の形になったんだから、これから色々な変化が出てくるのは間違いない。それなのにHUDみたいな新しい技術を「邪魔」と切り捨てるのは、30年くらい経って「そういえばHUDは全然普及しなかったね」みたいになるならともかく、今すぐには納得できないな。

 ベテランのパイロットは嫌がるだろうけど、飛行機の安全性は「素人が何も説明されずに操縦席に座っても安全に運行できる」くらいになるのが理想形であって、パイロットはあくまでもシステムが故障したときのバックアップのために乗務する、程度になるべきだと思う。ただ、一気に一足飛びでそこまで行くのは不可能だから、段階的にシステムを拡充して行って、その間にHUDとかAIとかのシステムが色々と増えていくはず。


***


 僕は、潜水艦の狭さというのは、無意味な狭さではなく、意味のある狭さだと思っている(いつも通り素人考えだけど)。例えば天井の高さで考えると、火災が発生した際に有毒なガスから身を守って初期消火や操艦作業を行うために、天井に酸素マスク用の配管が通っていて、あちこちにクイックディスコネクトカプラが配置されている。また、消火作業や浸水で床や壁が水浸しになっても漏電・感電しないように、コンセントが天井に配置されていたりする。他にも傾斜した時等に手足で突っ張れるようにしたり、角度をつけて潜航・浮上したときに天井にぶら下がって遊んだり、潜水艦の中では何かと天井に手を伸ばす機会が多い。そのような状況を考えたときに、「原子力潜水艦だから艦内容積に余裕がある」というような短絡的な考え方で無闇矢鱈と高い天井を用意すると、通常の運用やダメージコントロールといったあらゆる面で支障が出てくる。そのような視点で某ドラマを見ると、あのドラマはリアリティというのは非常に低いと考えざるを得ない。他にも人間や武器の挙動とか様々な面でいろいろと不自然な箇所が多い。

 あのドラマはあくまでも国家間の戦略的な意思決定を見せるのが主目的であって、潜水艦の戦闘というのはその意思決定を強いるための舞台装置でしかない、というように見える。であるなら、潜水艦内や戦闘のシーンはあくまでもオマケであって、それに対してリアルであるとかリアルじゃないとかを論じること自体に意味がない。

 とかなんとか能書きを垂れつつ。

 次シーズンははたしてどうなるかな? 舞台装置的な部分が改善するか、現状維持か、悪化するか。たいてい、映画とかドラマは回を重ねるごとに悪化していくのが多いような気がするが……

 日本の潜水艦とアメリカの潜水艦は内装がだいぶ違っていて、設計思想もだいぶ違う。例えば米軍の潜水艦は消火作業では初期消火にCO2、中盤以降はホースで水を撒くけど、自衛隊の潜水艦は一貫してCO2消化器を使って、それで対応できなかった場合は区画を閉鎖してハロンを使うという感じで、自衛隊の潜水艦は水を使う前提になっていないから、電気機器の配置もそれに則った配置になっているらしい。とはいえ、SSNに関しては米国製だからデザインはYouTubeを参考にして大きく間違ってるってこともあるまい。SSNは結構伝統的な内装な気がする。暗くて狭苦しい艦内。SSBNは比較的広々として明るい艦内だけど、ドラマに出てくるのはSSNだから、暗くて狭い設計思想が受け継がれる方が自然な気がする。むしろ日本の通常動力型潜水艦のほうが米軍のSSNより広めな印象だし明るい印象。乗員の体格差とかの違いなのかもしれないけど。


***


https://www.jstage.jst.go.jp/article/kasai/6/1/6_5/_pdf

 1956年。木造モルタルの建物での漏洩火災の原因に関して。ラス網を通じて地絡したときに、比較的低い電流値(5A程度)でも発火に至るメカニズムを発見した。それ以前には10A以上の比較的高い電流でしか発火しないと思われていた。

 ラス網は積極的に接地していなくてもある程度低い接地抵抗であり、数A程度流れることがある。網が赤熱すると木材が炭化するが、この炭は導電性を有しない。また、網が溶解すると接触不良になり、それ以上の炭化は進まない。ただしこの溶解した場所でアーク放電が起こると炭が加熱されてグラファイトへ変化し、導電性を持つようになる。漏電経路が網から導電性を持った炭へ変わると、この炭が高温に発熱し、さらに周囲の木材をグラファイト化させて発熱部が広がり、特徴的な空洞を形成しながらやがて発火へと至る。


 ラス網を接地すれば一見何の変哲もない木造モルタルの建物をシールドルームとして使えるんか?と思ってちょろっと調べてみたけど、積極的にどうのこうのしなくてもシールド効果はありそうだな。まあ、屋内に置いたラジオとかテレビの感度が極めて悪くて窓の外に出したら急に受信するようになるから、ただのモルタルでもある程度はシールドしてるんだろうという気はしてたけど。実際のところどの程度シールドになっているかはわからんけども。あとは窓があれば突き抜けるし。


 しかし、文体がなんとなく『星を継ぐもの』を連想させる感じがする。文章って時代ごとに相当な特徴を持っているんだろうな(星を継ぐものはさらに四半世紀くらい後だけど)。SFの翻訳って論文の文体を意識してたりするんだろうか? それとも当時はこういう文体が一般的だったんだろうか。


***


https://www.jstage.jst.go.jp/article/digraj/3/2/3_191/_pdf

 半導体技術の発展とテレビゲームや電卓との関係性とか、その頃の話が色々と。アタリを創業した人物の人となりとか。

 ピンボールみたいに機械的なインタラクションで動いていたゲームから、電子的に信号処理を行うPONGが生まれ、IC化やLSI化を経て、家のテレビ(受像機)に接続して遊ぶテレビゲームが生まれた。機械的な動作のゲームの場合は製造や調整に多くのノウハウが必要だが、デジタル半導体を使用するビデオゲームは簡単にコピーすることができ、多数の後発メーカーが出てきた。ただしLSIはゲーム内容を変えるためには半導体の設計自体を変更する必要があり、大量の在庫を抱えたアタリや後発メーカーに次のゲームを開発する体力は残っていなかった。

 また、LSIの特性は電卓のような用途でも問題化していて、新製品を開発するには新しい半導体を開発しなければならず、半導体の開発コストや半導体メーカーが不得手とする多品種少量生産によって厳しい状況だった。そのような中で、マイコンを使用することでハード(半導体)とソフト(機能)を分離し、半導体メーカーは1種類の半導体を大量生産し、半導体ユーザー(電卓メーカー)はプログラムを変更することで多様なラインナップを用意することができるようになった。

 しかし電卓のような用途の場合、製品が普及するとあとは価格競争になる。マイコン化で多少安くなったとはいえ、必要以上に普及するための原動力とはなり得なかった。対して産業用制御機器の分野ではプログラマブルな特性が要求され、さらに電卓とは比較にならない価格帯であり、マイコンが普及した。また、プログラムを変えることで機能が変わるマイコンの使用によって、テレビゲームの分野でも、カセットを交換することで多様な遊び方ができる製品を作ることができるようになった。

 PONGのようなゲームが出現する前にも、研究機関や大学が所有していたコンピューターを使ったゲーム(表示装置を使ったビデオゲーム。テレビ(受像機)を使ったテレビゲームと、テレビ以外の表示機を使うビデオゲームを区別する文脈がある)は色々と開発されていたようだ。ただ、これらの研究機関や大学で開発されたゲームは、技術者の間でプログラムが共有されることはあっても、それ以外の人間が触れる機会はほとんど無く、後のテレビゲームとの技術的な接点はほとんど無かった。同時期に日本国内にもコンピューターは存在していたが、誰もそれで遊ぼうとは考えず、また当時の考え方からすれば研究機材を遊びに使うなどとんでもないことだ、と。


https://www.jstage.jst.go.jp/article/itej1997/57/11/57_11_1476/_pdf

 ソニーの技術者へのインタビュー。日本でのテレビ本放送での、テレビの開発とかの話。

 NHKのテレビ試験放送が始まる知らせを受けて個人の趣味として静電偏向型のテレビを自作した。1950年12月18日に試験放送が開始され、受信に成功。会社に持ち込んだところ、上司は気に入ってくれたが、他社がテレビの量産を始めても、ソニーはテレビ開発はほとんど行わなかった。

「(前略)毎週テスト放送が繰り返されて、その後クイズのようなものが出題されるというようになりました。例えば、偏向歪みを測定するパターンを放送して、何番目が正しい円形であるかを答えなさいという類のものでした」おそらく日本で最初のクイズ番組なんだろうな。もっとも、技術的な問題であって、受信機(それを調整する技術者)を試すような問題。

 その後、ソニーでトランジスタテレビを作るという話が出たので、テレビを自作した経験を活かしてトランジスタ化。RFは真空管で、IF以降はトランジスタでテレビを構成し、8インチのポータブルテレビを開発し、その後は5インチのポータブルテレビも作った。

 ソニーの社風として、とにかく小型化するという方針。他の誰にも作れないほど小さく作れば、自社のオリジナリティになる。


 Sony TV8-301 - Wikipedia

 en.wikipediaは何でも知ってるな。

 鉛蓄電池を内蔵しているので、持ち運んで使用できたんだそうだ。高価で壊れやすくすぐに生産終了したそうだけど。オリジナリティを出して高付加価値化した結果値段が高くて売れなくなるやつ。。。




https://www.jstage.jst.go.jp/article/bplus/9/3/9_180/_pdf

 著者は1944年生まれで、大学1年の時にテレビを自作したそう。ただし「チューナーとブラウン管は新品、それ以外は中古品で」というような書き方。回路図から部品を集めて、みたいな感じではなくて、ある程度モジュール化されていたのかな?

 1963年頃として、カラー放送は始まってるけど普及率はさほど高くなく、テレビの一部はトランジスタ化されているけど、オールトランジスタ化はもう少しあとのはず。テレビがモジュール化されるのはトランジスタ化と同時期(トランジスタを扱える技術者が少ないから、モジュール化して基板を交換できるようにすることで修理を容易化)のはずだが。


https://www.jstage.jst.go.jp/article/cjaros/9/4/9_15/_pdf

 ヒビノの創業者、1950年(当時17歳)に米軍払下げのオシロスコープを流用してテレビ受像機を自作、とのこと。

 オシロスコープを流用できるんであれば、15.75kHzの発振器と、コンセントから50Hzを持ってきて、鋸波にしてXYに突っ込んでやればいいから、わりあい作りやすい部類ではあるのかな? 映像管はオシロが制御してくれるから、電磁偏向ブラウン管みたいに大電力を線形増幅する必要もないし。あとはVHFの周波数変換がちょっと難しいという感じかな。民間市場でVHFを扱う機器はそれほど普及してはいないはず。とはいえ、技術的には達成可能な見込みがあったからこそこの周波数を選んでいるわけで、極端に難しいということもないはずだし。


https://www.jstage.jst.go.jp/article/oubutsu1932/21/6/21_6_196/_pdf/-char/ja

 1952年。1950年の3月に戦後初のテレビの電波発射が行われ、11月からは一般向けの試験放送を開始した。現在(’52年春から夏頃?)は受像者は500人くらい。今のところは自作が大部分だが、ラジオメーカーが量産の準備を進めているから、秋ごろには日本製の受像機が市場に出回るはず。自作する場合は4-6万円、完成品は10-20万円くらい、だそう。レートは10倍から15倍くらいのはずだから、部品だけ買うなら65万円くらい、完成品なら200万円くらい、といったところか。個人輸入や米軍を通じて日本に持ち込まれたテレビを改造して使っている例も多少はあるだろうし、あるいは自作したテレビの所在が全て把握されているわけではないだろうし、ある程度の差はあるだろうけども、それでも最初の数年で数百台規模のテレビが自作されているのか。

 フレームレートとか帯域幅の考え方に関してもいくつか書いてある。テレビ放送は商用周波数とフレームレートを合わせる(フレームレートを商用周波数の半分に設定し、飛び越し走査する)のが妥当だが、そうした場合は関東で50c/s、関西で60c/sとなり、フレームレートが違う場合はプログラムの交換に非常に手間がかかるため、国内では統一したい。フリッカーを考えて60c/sを選んだ。試験放送時点では電源にフレームを同期する方式を用いたが、日本は電源の周波数が不安定でであるから、非同期方式を使用することにする。

 帯域幅については、基本的にはアメリカの6MHzを導入したわけだが、7MHz派の言い分は、6MHzはアメリカが戦前に決定したものであり、それを鵜呑みにする必要はないであろう、帯域幅が広ければ画質が良くなる、といったもの。6MHz派の方は、1MHz広げても画質の差はわずかであり、アメリカで研究中のカラーテレビ方式を将来的にそのまま導入できる余地を残したい、みたいな感じ。その他色々。

 カラー方式の説明も色々。この時点でNHKとコロンビアがカラーテレビの研究を行って、CBS式(カラー円盤方式)で実験している。すでに白黒テレビが普及しているアメリカではNTSC方式が有望である。CBS式は白黒放送と互換性がない。RCA方式の場合は白黒と互換性があるのかな? NTSCはRCA方式を発展させたもの。

 日本の放送方式を決定した段階では、アメリカではカラー放送の方式は決定していなかったんだな。おそらくアメリカは白黒と互換性を維持したカラー方式を採用するはずだから、アメリカ方式と同じ放送方式を選んでおけば将来的に日本でも互換性を維持してカラー化が可能だろう、みたいな消極的な選び方っぽいな。


 テレビの自作ってどんなもんなんだろ、と思ってちょろっとググってみたけど、うーん、という感じ。そりゃやってる人はやってるけど、ラジオの自作ほどポピュラーでもないし。

 20年くらい前に秋月で売ってるモジュールを組み合わせて液晶テレビを作るみたいな遊び方が流行っていたらしいけど、RF(VHF/UHF)をCVBSに変換するモジュールと、CVBSをRGBに分解するモジュールと、RGBを表示する液晶を組み合わせて、みたいな感じだから、ほとんど「自作PC」に近い雰囲気。

 テレビ自作のインセンティブは高価なテレビを買わずに自分で作るみたいな方向性だろうから、放送開始直後とかそのあたりの時代ならともかく、ここ半世紀くらいは市販品を買えば済むだろうし。

 半世紀以上前の話が多いだろうからググってもほとんど概要がつかめず。学術的な内容というより個人の趣味みたいな分野だからあまり記録にも残らないだろうし。


https://www.jstage.jst.go.jp/article/mscom/76/0/76_139/_pdf

 戦前から戦後にかけてのラジオの自作に関する考察。

 ラジオ放送が開始された直後は自作ラジオ(鉱石ラジオ)が非常に多く普及していて、聴取者が自らラジオの修理を行うような状況だった。ただし数年でラジオ屋が組んだラジオが普及し始め、自作ラジオの割合は減っていった。戦前には専ら技術研鑽のような目的と化して、多くの人が自作する対象ではなくなった(誰にでもできるような内容であってはならない、という風潮)。一方で戦後にはラジオキットが大量に流通し、誰でも簡単に作り、ラジオを聞くことができるという状況になった(戦前と戦後で自作ラジオに対するスタンスが全く異なる)。一方で、1970年頃になるとオーディオが急激に勢力を伸ばし、自作ラジオは衰退していった。音楽を聞こうという目的に対してラジオはトークが挟まり、また放送特有のノイズから逃れることができず、音楽の忠実な再現という方向がラジオでは不可能であり、それ(音質の追求)をなし得るのがステレオ(オーディオ)の分野だった。音質の追求に対して、遠くの人との通信を楽しみたい人はラジオではなくアマチュア無線へシフトした。FM放送が始まったときにはそれを受信するラジオを自作する人もいたが、自作ラジオの衰退を阻止するほどの勢力ではなかった。テレビの自作に関しては一切触れられていない。

 ラジオの場合は伝搬時のノイズがあるから音質の追求が難しくて、それを嫌った人がオーディオ分野にシフトして、結局今のオカルトみたいなジャンルが出来上がったんだろうなぁ。あの界隈謎すぎるよ。。。


https://opac.ll.chiba-u.jp/da/curator/109605/S13482084-69-P307.pdf

 教材としてAMラジオの代わりに使えるFMラジオの提案。トランジスタ1石で超再生検波。めっちゃシンプル。


 No.4 私設研究所の設立 | JA2JA 神戸幸生氏 | アマチュア無線人生いろいろ | 週刊BEACON | 個人のお客様 | アイコム株式会社

 当時、テレビ受像機生産に乗り出すメーカーや、テレビ受信アンテナを手がけるメーカーが増加した。戦後、ラジオ放送開始にともない、電気店や電気に興味を持つ人々がラジオ受信機を作って販売したのと同じ現象が起こった。テレビの組み立てキットを発売するメーカーも現れた。神戸さんも自作のテレビ受像機を何台か作った。

 さすがにメーカーに特集されるようなOMにはテレビ自作に関わった人がちらほらいそうな感じ。


***


 思わずamazonで車載用のワンセグチューナーを衝動買いしてしまった。簡単に動作確認して、ちゃんと動いているので、早速分解。

 RF入力はSMA、電源とかCVBSとかその他諸々は1個のコネクタからハーネスが出ている。説明書によると電源範囲は9-35Vあたりとかなり幅広い。ただ、説明書に一切記述のない謎のminiB端子をUSB電源に接続したら起動した。USBコネクタの根本にダンピング抵抗みたいなのついているけど、その先はスルーホールだし、裏面にはパターンは無い。多層基板の中に入ってるんだろうか? PCに接続しても認識しないし、少なくとも機能的には何にも使ってないんだろうけど。まさかUSBワンセグチューナーとして使えるような機能なんてないだろうし。

 左上のチップがチューナーで、ググったらルネサスのチップが出てきた(ドキュメント類は無し)。すでにEOLだけど、ワンチップでRF(470-806MHz)からワンセグのトランスポートストリームに変換できるやつらしい。モードは1から3まで、帯域幅は6から8MHzまで、変調もQPSKと16QAMに対応していて、チャンネルスキャンとか、ワンセグの受信に必要な機能は一通り対応しているようだ。

 一番大きいチップは素性が不明だけど、トランスポートストリームをNTSC/PALに変換するのを担当しているはず。中央のSOPは64MbのSPI Flash。一番下のSOPはDCDCかな? チューナーの水晶は24.576MHzで、これは24x1024kHzに相当する。メインのチップは27MHz。220uFはたぶん電源のLC LPFだと思う。耐圧35Vに対して動作範囲が最大35Vだから、ディレーティングが全くない。たいていは12V、高くても24V系でしか使わないだろうから、普通は超えることはないだろうとしてもよ。


 CVBSはこんな感じ。最初見たときはめっちゃガタガタで、安物のコンデンサで結合しやがってーと思ってたら、プローブのGNDが浮いてただけという。。。CVBS用のアナログ回路を内蔵した半導体ならsag補償回路くらいは入ってるか。


 基板裏のシルクにUTXD1/URXD1みたいなあからさまな端子があったので、オシロで覗いてみた。

 何も操作しなくても時々115.2kbaudでなにか文字列が出てくる。コンソールで受信すればデバッグ情報みたいなのがちらほら出てくる事があるけど、役に立つ情報かというと微妙なところ。


 8.127MHzの水晶が入ってたら面白そうだなーとか思って試しに1個衝動買いしたけど、そんなことはなかった。チューナーチップにはPLLが入っていてISDB-Tに周波数ロックできるけど、とはいえおそらく水晶にはフィードバックせず、内部のPLLで使っているだけのような気がする。いったいどうやって評価するか。GPSのPPSでオシロをトリガして水晶を温めたり冷やしたりするとか?


***


 430MHz帯で嫌がられない程度に弱い出力でISDB-Tを出して狭帯域デジタルATVみたいな遊びってできないもんかな(6MHzのNTSC方式ATVに比べて狭帯域という意味)。専有帯域幅は0.5MHz未満だから広帯域の画像とか実験用のバンドに収まる。ISDB-Tはホワイトノイズ状の連続波だから十分に弱い出力であれば他への妨害はあまり気にならない程度だろうし。

 フルセグTVだとCATVの周波数変換パススルー用に300MHzあたりまで受信できるから、430MHz帯ISDB-Tも受信できそう。もっとも、フルセグTVがワンセグの受信に対応しているかの問題があるけど。携帯受信機は当初はISDB-TmmみたいにVHF-High帯を想定していたりしてたけど、もちろんアマチュア430MHz帯は避けてるし、普及しなかったからVHF対応のワンセグ受信機もそう多くないだろうし。まあ、5.6GHzとかのデジタルATVも周波数変換が必要だし、同じように受信側に周波数変換を挟めば済む話だし、35-300MHzくらいの移動だから、C帯あたりから移動するよりはやりやすいはず。


 マイコンとかからNTSCのベースバンドを出そうとすると14.318Mspsが必要だけど、ワンセグのIFなら4.063Mspsあたりで良いのか。受信するなら1024ptsのFFTが欲しいけど、送信するなら512ptsでアナログ波形に変換してインターポレーション+周波数移動すればいいわけだし、ワンセグのTSPからIFを出すならSTM32F4あたりで十分行けそう。さすがにH.264の圧縮とかもやろうとすると厳しそうだけど、ちょっと早めのマイコンならワンチップで例えばUSBカメラからワンセグIFまで出せそうな可能性があるわけか。/* そういえばシマフジがトランスポートストリームからのワンセグ変調器を作っている(いた?)けど、RISC(1200MIPS)+FPGA(75kLE)で相当大規模なものらしい */


 rtl_tcpの複数起動、起動時間が長くなるとタイミングがズレるんじゃないか、みたいな疑惑が出て狐につままれたような感じ。そんなまさか、パトリオットミサイルじゃないんだから……


 春の陽気で大いに雪解けが進む昨日、3Dプリンタを置きっぱなしの部屋が17℃くらいまで温まったのでちょろっと部品を試作。数カ月ぶりに使った。

 試しにM12x0.5のスレッドを0.12mmピッチで印刷してみたけど、さすがに入らず。タップで軽くさらったらスルスル入った。

 また寒くなってきたので次の稼働は当面先の予定。


 ISDB-Tのデコードはとりあえず自分の中で一区切りつけたので、なにか違うことやりたいなー。久しぶりにSTM32とか触ってみるか。

2024年2月14日水曜日

小ネタ








 日本のAM放送がFM放送への移行へ向けて試験的に停波されたりされ始めているけど、アメリカって、AM放送を行っていないとFM放送のライセンスが付与されないんだな。いったいどんな理由で……

 欠片程度とはいえ欧米の近代技術史をかじっている僕からすると、どうせ高音質で混信せず地域密着型の番組を放送できるFMラジオを脅威に感じた既存のAMラジオ放送会社がロビー活動した結果なんだろ、とか思ったり。まあ、そんな簡単な話じゃないんだろうけど。


 沈黙の艦隊、全く期待してなかったというのもあるけど、期待よりは良かった。戦術がアレとかCGが安っぽいとか文句を言おうとすればいくらでも言えるけど、極端に酷いというほどでもないし。そもそも、マニア向けの娯楽作品というより大衆向けに政治的なメッセージを込めたような作品だろうから、正確な描写とかはあんまり気にしてないだろうし。プロデューサーが「CGにもこだわった」的な発言をしていたから、その点に関しては「いうほどか?」という感じではあるけど。まあ、『THE LAST SHIP』とか『ハンターキラー』とか、娯楽作品なのに(だからこそ?)戦術がめちゃくちゃだったり、CGクオリティが低い作品もあるから、それらと比べれば相対的にはわりと高評価。

 純粋な娯楽作品として、戦術やCGクオリティが比較的高い映画は、例えば『バトルシップ』が挙げられるけど、戦術やCGが良いからと言って商業的に成功するかどうかはまた別の話だからな。


『イン・ザ・ネイビー』(原題:Down Periscope)

 コメディ映画寄りだけど、面白かった。バカバカしい内容でも受け入れられるならオススメ。ちゃんと潜水艦らしいストーリーだし。やっぱりこういう内容のほうが「こまけぇこたぁいいんだよ!!」の感じで頭を空にして見れるから楽でいいな。

 落ちこぼれの乗組員がWWII中に建造された潜水艦に乗って、原子力潜水艦や駆逐艦等が守る米海軍基地へ模擬攻撃を仕掛けるようなストーリー。撮影は’95年だけど、タイコンデロガ級巡洋艦や就役間もないアーレイ・バーク級駆逐艦もちらっと映ったりしていて、あまり大昔の印象は無い。まあ、大部分はWWIIの潜水艦の中のシーンだから、現代的とは言えないけど。

 なんちゅーか、はいふりっぽいな、とか思ったり。


 マウスのスクロールホイールのチャタが酷くてまともにスクロールできない。下に行きたいのに上に行くとか。傾向としては上に回せば上に行こうとするし、下に回せば下に行こうとするけど、ほとんど動かない。ブラウン運動を思わせる動き。

 amazonでそれっぽいエンコーダをポチってみたけど、配達予定が3週間後くらい。それまでは別のマウスでホイール操作する感じかな。届いてもちゃんと合うかわからないけども。

 改めてamazonのレビューを読んでみると、このマウスはスクロールホイールが半年程度で壊れるのがデフォらしい。部品を交換してもすぐ壊れそうだな。どーしたものか。

2024年2月7日水曜日

小ネタ








 高強度レーザ(軌道離脱)以外にも情報処理系(LiDAR)も扱う会社。ではあるけど、情報通信に言及してないのがなんとも。それは親会社(スカパーJSAT)の仕事だから、みたいなことなのかな。レーザー系はひとまとめに1社でやればいいのに。


 有川浩を読んで育った世代としては、潜水艦映画の主演兼プロデューサーが、潜水艦の通常のオペレーションを指して「潜水艦が沈む」とか表現しているのを見ると、ちょっとピキッちゃうな(ドントシンク、考えるな

 日本の俳優が「原子力潜水艦は機密の塊。情報は一切出てこない」とか言ってる横で、アメリカのYouTuberが「原子力潜水艦のピザウマウマ」とか言ってるのを見ると、お国柄というか、文化の違いというか、なんというか。

 米海軍の原潜(SSN)って市民向けのイベントで艦内に入れたりするからな(例えば USS Albany SSN-753 Los Angeles-class submarine at Fleet Week - Port Everglades 2019 - YouTube とか)。もっとも、電子機器等は持ち込み禁止なので基本的に内部の撮影はできないし、停泊中だけども。とはいえ、撮影許可を得て停泊中に動画を撮影している例もある(例えば Inside a Nuclear SUBMARINE! | USS Indiana Tour - YouTube とか)。訓練航海とかに便乗してカメラを持ち込んでるYouTuberも何人もいるし(例えば Inside a Nuclear Attack Submarine - YouTube とか)。戦略原潜(SSBN)だとセキュリティが厳しいからそう簡単には入れないけど、メディアの取材が入ったりの例がないわけではないし(たとえば Rare access inside US ballistic missile submarine | ABCNL - YouTube とか)。映画の撮影で本物の原子力潜水艦(SSGN)を使った例もあるし(Act of Valor)。日本で信じられているほど原子力潜水艦は機密の塊というわけじゃない。


 Find M12 Lenses (S-Mount Lenses) and Optics for Cameras

 M12xP0.5とCマウント専門のオンラインショップ? レンズマウントも何種類か扱っている。ドキュメントとかもしっかりしている。ショップも日本語化されてるし(機械翻訳っぽく若干変な訳があるけど)。

 大学とか企業でちょっとしたCマウントレンズが欲しいくらいの用途なら、ミスミで買っても大差ないかな。アメリカから送ってくるから送料もそこそこかかるし。M12xP0.5のマウントとかちょっと特殊なやつがドキュメント併記で売ってるから、中国直送の怪しい部品を買うより博打度は少ないけど、とはいえ数ドルの部品に数十ドルの送料を考えると、中国から5個数百円とかの部品を何種類か買ってそのうち1種類でも使えることを願ったほうが安いような気がしないでもない。


 玄関のドアの閉まりが悪いのでドアクローザーを調整。メーカー名を見てみたら、リョービだって。リョービってこんなのも作ってるんだな。というか、リョービはダイカスト製品の会社らしい。ドアクローザーみたいな小物から、自動車部品とか、大きなものだとオフセット印刷機とかも作っているらしい。電動工具も昔はダイカストのケースに入ってたから、そういう由来なのかな。昨今は樹脂部品になってきたから、ダイカストメーカーとしては扱いづらいか。どっちも射出成形ではあるけど、技術的には全く別物だろうし。さすがに印刷機みたいな大きさになるとフレームをダイカストでってわけにもいかないだろうから、別の由来な気もするけど。

 うちの家についているドアクローザーは古い製品なので、ネジ1個で2種類の速度(全体的な速度とドア枠に収める速度)を調整するタイプ。全体の速度はネジの締込み量で、枠に収める速度はネジの位相で調整する。QAM変調みたいだ。


 エアダスターのシュリーレン撮影、悔しくて夜しか眠れないのでチャレンジ

 ショックダイアモンドらしいの撮れた。それにしても鏡の汚いこと。

 圧縮空気を適切なノズルから吹けば超音速流が得られる、みたいなのはどこかで読んだ気がするけど、とはいえちゃんとしたラバールノズルとか必要なんでしょ?と思ってたのだが、まさかエアダスターの細ノズルでいいなんてな。こんな真っ直ぐな管だと抵抗だいぶ大きそうなのに。直管に超音速流を流すと出口まで流速が制限されるから高い圧力が維持されて出口から不足膨張のまま吹き出してくるって感じなのかな? いや、媒質中を縦波が伝搬するのは音速に制限されるけど、媒質自体が動くんだから音速のリミットはないよな……

 この時、ナイフエッジを使ってない。なんで撮れたんだろう。絞り羽あたりがナイフエッジみたいに効いたのかな? 光軸の調整が難しい。上下左右の移動の微調整とヨー・ピッチの微調整、4軸のプラットフォームが必要。やっすい三脚だと微調整できないから面倒くさい。

 光軸に手を入れると体温で発生したモヤみたいなものが見えるから、シュリーレン撮影としては機能しているはず。


 畳み込み符号のビタビ復号、もうちょっと早くならんかな、と思って、試しにC#のコードをC++に移植してみた。C#ってどれくらい遅いんだろうか、と思って。

 541824バイトの乱数(1,QPSK,2/3、12,64QAM,3/4で1フレーム相当、ただし全データに対して2/3相当のパンクチャド、204バイト単位の末尾に0x47を設定)に対して復調処理。

 復号処理に、通常のC#コードで1.10秒、unsafe/一部SIMD化で0.840秒、C++(g++ -O3)で0.921秒、くらい。確かにC#はC++に比べて遅くはあるが、乱雑な配列アクセスを多用している割にはそこまで遅くない。unsafe/SIMD化は期待したほど早くはならないけど、何も考えずにC++で書いたよりは早い。C#って意外と早いんだな。もっと遅いもんだと思ってた。forとかforeachで最適化されない配列アクセスも、結構早い。ちゃんと最適化されてる。

 元々のC#コードは今の2倍以上遅くて、処理速度に一番効くのがDebug/Releaseビルドの切り替えという。Debugモードってめちゃくちゃ遅い。Releaseモードだとステートメントの再配置とかスタックに読み出さずにレジスタ内で計算するとかいろいろ最適化して早くなるんだと思う。もちろんデバッグには不便だから開発中はDebugモードを使うほうが楽だけど。

 通常のコードでもSIMD併用やチューニング(unsafe不使用)で0.9秒を切るくらいまで短くなってきたから、何も考えずに書いたC++より早い。unsafeもチューニングすればもう少し早くなりそうだけど、ポインタでゴリ押ししたりコードが複雑になったほどの効果はないかな。

 C#、ほんの僅かな差(処理内容に影響のないステートメントの前後の入れ替えとか)でも5%とか影響あったり、チューニングが難しい。あるいは、明らかに計算量が多いアルゴリズムのほうが1割近く早かったりもするし。ildasm.exeだと何やってるかわからないし、かといってILSpyだとソースコード読んでるのと大して変わらないし。こういうのってどこを見ればいいんだろうか。x64のパイプラインとか勉強しなきゃいけないんかしら?

 無関係の別のメソッドを書き換えたら実行速度で2割位遅くなったりとか、何が何やら。一時期は0.6秒台が見えていたのに、不要なコード削除したりしたら0.75秒切るのも難しくなってきた。

 配列のインデックスの計算で&(≒mod)を使用するとき、例えばarray[i&mask]=hoge;みたいなことをやるときに、var j=i&mask;array[j]=hoge;みたいなことをやると、明らかに遅くなる。CILってアドレッシング時にbitOrを取るための専用命令みたいなのがあったりするんだろうか? 添字の計算は相当最適化してあるらしくて、下手に変数で中間値を管理するよりベタ書きしたほうが早い。


 うちにある単4のNi-MH、充電器でエラー(赤点滅)になるやつがかなり多くて、もう10本近く死んでる。大半はamazon basicsのブランド。何本かパナのやつも混ざってるけど。amazon basicsのNi-MH、eneloopと同じ製造元みたいな噂だけど、やっぱり品質には差があるのかな? それとも最近パナの単4をあんまり使っていなかったせいでamazon basicsのやつが集中して死んでいるだけなのか。

 最近は単3電池を使う機器はほとんど使っていなくて、もっぱら単4電池ばっかり使っているのだが、これがどんどん死んでいく。

 そういえば10年くらい前に買ったパナの単3は負極側が変形(凹む)して死亡する電池が多かった気がする。メーカーによらずコンシューマー向け製品の品質なんてこんなものか……


 20ADC30VとかのスイッチをCMOSレベルの入力に接続するの、どうやるのがいいんだろうか。12VDCくらいの電源に100Ω3Wくらいの抵抗負荷を接続して分圧して計測、あたりがシンプルなやり方だろうけど、いかんせんCMOS入力を考えると消費電力がな。電源の容量も大きいのが必要になるし。

 操作頻度があまり高くない&使用範囲が常温の範囲なのであれば、電源側にシリーズに定電流ダイオード、スイッチの前後に電解コンデンサ、スイッチの後ろにパラレルに抵抗を入れて、操作時にキャパシタ間でエネルギー移動させてスパークさせて、みたいな感じとか? あとは分圧したり、必要に応じてシュミットトリガインバータとかフォトカプラを挟んで。


 ちょっと変な光学系センサ、1ヶ月ほど前に注文していたやつが届いたので軽く遊んでる。電気的な特性は期待通りだけど、光学的な特性、特に2個のセンサのアライメントがかなり厳しい。光学部品を固定しているネジを緩めれば荒い調整はできるけど、細かい調整は不可能に近い。ガラエポ基板に乗っているから、調整したとしても押せば歪むし。80x22x12mmくらいのアルミ部品を作ってやればキッチリアライメント出せるはずだけど、とはいえ1万円くらいの部品に対して金属削り出し部品の外注かぁ…… 時々やってくるCNC欲しい欲。精度だったり強度だったりで3Dプリンタでは少し足りない部分で、せめてTormach 440あたりがあれば色々作れるんだろうな。いや、どう考えても外注したほうが安いんだけどね。。。


 ざっくりFusionでデザイン。Fusion使うのも久しぶりだな……

 上面以外はフラットだし、上面以外は寸法精度ほとんど必要ないから、3軸機でもワンチャッキングで加工できそう。試しにDMMに投げてみたらPA12MJFで5千円くらいだそうだ。うーん…… タップとかは自分で加工しなきゃいけないことを考えると……

 DMMの3Dプリントサービスが始まってしばらく経つけど、切削の似たようなサービス見当たらないよな。プロトラブズは撤退したし、ミスミは法人しか使えないし。アディティブと違って切削は形状の条件が厳しいから自動処理が難しくて、システムとして成立させるにはある程度の規模が必要だから、その規模を受注できない会社(プロトラブズとか)は撤退するし、日本で規模を受注できる企業(ミスミとか)は法人相手だけで十分稼げてるし。


 そういえばPenta Machine(旧PocketNC社)の新しい機械の話全然出てこないけどどうなってるんだ?と思って見てみたら、新製品のページ追加されてた。いつ追加されたんだろう? 2024年発送開始だそう。

 Solo Info — Penta Machine Co.

 推奨のワークサイズは6インチキューブ(ワークエリアはもう少し広い)の5軸マシンで、ATC搭載、220V1.5kW(110V昇圧でも対応可能)、定価80kUSDのところ今なら75kUSD、だそうだ。

 Haas Mini MillにTRT100+コントローラを載せたら82kUSDくらいになるし、TRT100のワークサイズがΦ3”x3”くらいだから、5軸加工だけ考えるならSoloはいい選択肢なのかな? Mini Millよりだいぶコンパクトだろうし。

2024年1月31日水曜日

小ネタ


 単位の変形の話とか。


 同じチャンネルの動画。思わず笑ってしまったので貼っておく。







 適度な距離感で同じ業種の人が2人いると話が弾んで良いな。1人を呼んで話を聞くと中途半端な(比較的浅めの雰囲気の)範囲しか聞けないような感じがして物足りなかったり、同じ会社から2人呼ぶと一人が話してもう一人は相槌打って、みたいな状況になりがち。あまり距離感が近すぎない同じ業種の2人だと、取材を意識して深いところまでは潜らずとも、仲間内で話してくれるから面白い。この動画の場合は人選が良かったというのもあるんだろうけど。片方が積極的に話を回して、もう片方がそれにいい感じに反応して、話が難しくなりすぎたら聞き役が質問して。ただ、競合他社の人を集めなきゃいけなくなるから、こういう構成ができる分野は狭そう。

 別のチャンネルのコンテンツで、普通の取材では話さないようなディープな話も、みたいなコンセプトでも、専門家一人に対して聞き役一人であんまり深くないような雰囲気がしてしまっているものもあるし。深掘りする話ってのは掘るのがなかなか難しい。「餅は餅屋」で、同業種の人に掘ってもらうのが一番良いんだろうな。

 あとは、NHKの『ザ・バックヤード』も似た感じで、聞き役が全くの部外者だから、あまり深掘りできていない感があってもったいない。

 実は「専門家が楽しそうに話している」みたいな内容って、NHKの『100カメ』が一番近そうな気がする。一応NHKのカメラ(大量のスマホとかGoPro)は意識しつつ、とはいえ普段の仕事場だから仕事の話がメインだし、楽しそうな職場であれば楽しそうな場面がいっぱいあるし。


 紅茶のいれ方を米科学者がアドバイス、英国人の憤慨に米大使館が対応 - CNN.co.jp

 英国人がこよなく愛する紅茶のいれ方を巡り、英米間で250年前のボストン茶会事件以来となる外交論争が勃発している。

 紅茶がどうのこうのと若造がなにか騒いでおるぞ(コーヒーを飲みながら え? 本物の英国人は紅茶もコーヒーも飲まない? 酔っ払いが何を言うか。コーヒーでも飲んで目を覚ませ!

 味として感じない程度の塩味で苦味が遮断されるそうだ。スイカに塩をかけて食う我々日本人的感覚からすると塩をかけると余計味を感じそうな気がするけど。


 「完璧な紅茶」作るには塩を入れるべき、米科学者がアドバイス 英米「紅茶論争」に発展 - BBCニュース

 教授の説明によると、塩には、紅茶の苦みを感じさせる受容体をブロックする働きがある。

 なるほど。

 ほかにも、紅茶の温度をより熱く保つためには、背の低いどっしりとしたマグカップを使うこと、マグカップとミルクを事前に温めておくこと、ミルクは紅茶を注いだ後に入れることなども挙げている。

 ほう……? 


 例の話題のやつ、リンク貼っておきますね

 https://www.jstage.jst.go.jp/article/faruawpsj/51/6/51_566/_pdf

 http://satcom.jp/93/spacejapancommentaryj.pdf



 ターミナル・リストの続編。前作よりは少しマイルドになったかな? どちらかといえばという話だけど。

 誤字脱字の量から感じられる不景気よ(小並感 前作は誤字そんなになかったような気がするけど。出版前に誰も中身チェックしてないんだろうなぁ。言論・表現・出版の自由バンザイ。


 100カメでHTV-Xスペシャルとかやらないかなー。HTV-X/H3の製造工程から、射場作業、レイトアクセス、打ち上げオペレーション、フェアリングが割れる映像や点のようにしか見えないISSがどんどん大きくなる様子、ドッキング中の作業や、ハッチを開ける映像を内側から。最後に生鮮食品の食事シーンで終了。さすがに規模がデカすぎて大変そう。2時間とか3時間のスペシャルで…… 普段の100カメも膨大な映像をギュッと詰め込んでいるから時々スペシャル版やってほしいなー。


 SDR#ってIPv6には対応してないんだな。なんでだよ……

 SDR#、4GiB越えのWAVにも対応していないし、dataチャンクの長さが0なのも対応していないし、いろいろ不便。ファイル開放もしてくれないし、簡単にハングアップするし、GUIはあちこちとっちらかって使いづらいし。


 C#のDns.GetHostAddressesでローカルのPCの名前からIPアドレスを取るのに、3秒程度かかっていて、ちょっと遅い。試しにDNSサーバーをデフォルト設定からGoogle Public DNSに変えたら0.4秒くらいまで縮まった。まだちょっと遅いけど、我慢できるレベル。ローカルのデバイス名を名前解決しようとすると存在しないドメインの問い合わせになるから、近所のDNSサーバーに無くて順繰りに色んな場所へ問い合わせなきゃいけないから遅くなるのかな? マトモなDNSサーバーならまだいいけど、存在しない名前を渡されたら広告サイトのIPアドレスを返すみたいなサーバーにあたると面倒なことになりそう。

 ローカルのPC名からの名前解決、DNSサーバーまで問い合わせずにローカルで完結させるような機能ってないんだろうか。それっぽい設定は大昔の記事で出てくるけど、Wikipediaで斜め読みした感じXPあたりから少しずつ削られて7あたりで廃止されたらしい?

 GetHostAddressesはローカルの名前解決専用みたいな話らしいけど、とはいえGetHostAddresses("google.com")とかやるとちゃんと取れるから、インターネット上のDNSサーバーを使っているはず。

 dll叩けばローカルの名前解決専用のAPIがあるらしいけど、さすがにそこまでするのもなぁ……


 C#のInterlocked.Exchangeってコストどの程度なんだろうか。

 メンバ変数を取ってクリアする、みたいな処理、var a = _hoge; _hoge = 0; みたいなやつを var a = Interlocked.Exchange(ref Hoge, 0); みたいに1行で収まるから書くのが楽。しかもスレッドセーフにもなる。オトク! 知らないで見ると何をやってる処理なのか分かりづらいのがネック。あとCLI準拠じゃないぞと脅してるのが気になる。ググってもいまいちどういう意味なのかよくわからない。マルチプラットフォームを想定すると実装依存だから注意してね、みたいな感じなのかな。


 ffplayでMPEG-2 TSのリアルタイム再生、うまく動かないんだけどなんでだろう? TCP、パイプ、名前付きパイプを試してみたけど、どれも配信側が終了するまで再生が始まらない。

 TCPはTcpListener/TcpClientで、パイプはProcess.StandardInput.BaseStreamで、名前付きパイプはNamedPipeServerStreamで作って、それぞれ書き込んだけど、書き込んでいる側のプログラムが止まるまでffplayの画面が表示されない。

 書き込んでいるtsファイルに対してffplayを起動すると、起動時にファイルの中身がカラだからエラーで落ちる(5秒位待ってからffplayを立ち上げると再生される)。

 Processで起動したffplay以外にも、ターミナルから手動で起動したffplayでも同じような挙動。


 ffmpegでUSBカメラをMPEG TSに変化してTCPサーバーを立てて、ffplayで再生するコマンド

 ffmpeg -f dshow -video_size 320x240 -i video="USB Camera" -f mpegts tcp://[::1]:1234?listen

 ffplay tcp://[::1]:1234

 エンコードが間に合わないんでQVGAを設定している(適当な大きさでいい)。ffplayを起動すると10秒近く経ってから再生が始まる。

 ワンセグのMPEG-2 TSも、しばらく(数十秒)読ませると再生が始まるから、バッファに溜まるのを待っている感じの挙動なのかな。ffmpegのUSBカメラだと早めに再生されるのはビットレートの違いかな。ffplayの-helpを探してもそれっぽいオプションが見当たらない。ffmpegのオプション多すぎて全部読むの厳しそう。。。

 試しに最初に32MBくらいヌルパケット送り込んでみたけど、変化は無かった(エラーメッセージ増えたかなくらい)。ヌルパケットを破棄してるってことはネットワークレベルのバッファじゃなくて、映像信号レベルのバッファか。

 ffplayで-fflags nobufferを追加すると、ffmpegからUSBカメラの映像を受け取るときはだいぶ低レイテンシで再生できる。ただ、ワンセグはやはりソース側が閉じるまで再生が始まらない。

 切断はどうやって判断してるんだろ?と思って、試しに送信側でバッファして1秒毎くらいに転送させてみたけど、相変わらず終了するまで再生が始まらない。送り側が終了したらほとんど直ちに再生が始まるのが謎い。

 USBカメラはあまり遅延なく再生できるってことは、間にffmpeg挟んでトランスコードしてffplayに突っ込めばいいんか?と思って、そういう感じでやってみたけど、今度はffmpegが身動きできなくなってる。


 試しにVLC media playerをインストール。最初はストア版を入れてみたんだけど、なにかおかしい。ということでアンインストールの後に通常のx64インストーラーでインストール。VLC、インストーラー版もWindowsストア版も名前はVLCだけど、中身は全くの別物なんだな。

 ストア版だとtcp://[::1]:1234みたいなストリームには非対応だけど、インストール版なら問題なく動く。C#からProcess.Start(@"C:\Program Files\VideoLAN\VLC\vlc.exe", "tcp://[::1]:1234");みたいに起動してやれば、C#のTcpListener/TcpClientで送ったストリームを再生してくれる。ただしパケットのタイミングによって正常に再生できる場合とできない場合があって、後者の場合は映像は再生できるけど音声は出ない、みたいな感じになる。

 ffmpegはとにかく持てるだけ大量のパケットを受信してから解析して再生することで、できるだけ正しく再生しようとするし、VLCは可能な限り少ないパケットを解析することでレスポンスを良くするが、高い頻度で間違えたまま突っ走る、みたいな感じなんだろうな。そんな両極端じゃなくて、もうちょっといい塩梅のヤツは無いものか。

 VLCの名前の由来、Video LAN Clientなのに、ストア版はLAN経由のVideo Clientとしては使えないんだな。何という名前負け。。。TCPでMPEGTSを直接突っ込むみたいな使い方じゃなくて、もっと普通のLAN共有なら動くんだろうけど。


 あきらめムードでググってたら、それっぽい話題が出てきた

 ffmpegのオプション -analyzeduration と -probesize - 脳内メモ++

 -probesize 32は試していたけど、効果は無し、という判断だったのだけど、改めて試してみたらちゃんと効果があった。ただし適切な値を設定してやる必要がある。これはバイト数を指定するが、最小の32の場合、おそらく必要なデータが溜まらないので延々に待ち続けて、別の症状が出ていたんだと思う。

 デフォルトは5MBだが、ワンセグ放送の480kb/sでは約1.4分程度の長さだから、再生が始まるのにこれくらいの時間がかかる。probesizeに48k程度(1秒弱)を与えてやれば、コマンドから1秒程度の待ちで映像が表示される。プロービング量が足りない場合は音声だけ(+スペクトルの映像)が再生されたりする。VLCの場合は映像だけはよくあるけど、音声だけというパターンは遭遇していない。ffmpegの挙動とまた違うのかも。

 probesizeを188に設定すると、音声が再生される(音声か映像かは確率的かもしれないけど、何回か試した中では音声しか出てきていない)。一方でprobesizeを187に設定すると再生が始まらない。1パケットに満たない長さの場合はうまく認識でくなくなるようだ。一方で189を設定すれば(188と同様に)再生されるから、必ずしもパケットサイズの整数倍である必要はない。ワンセグをffplayで見る場合は48kがちょうど良さそう。

 analyzedurationは時間で指定できるから、ビットレートによらず設定できるこっちのほうが便利そうだけど、とはいえどれくらいのデータを解析したらどれくらいの時間になるかと言うのは解析してみないとわからないはず。ためしに500000(0.5秒)を指定しても期待した動きにはならなかったから、probesizeで指定したほうが良さそうな感じ。映像データは固定ビットレートではないからprobesizeも確実というわけではないけど。

 VLCも内部はffmpegを使っているらしくて、起動オプションでprobesizeも設定できるらしいが、今のところはうまく動いていない。どこか別のオプションが先にリミットに達したりしてるのかも。VLCはヘルプを日本語で出せるからどのオプションがどういう効果なのかはわかりやすいかな。結局ffmpegのオプションを調べなきゃいけないけど。。。


 RazerのNAGA PRO、ホイールのチャタがいい加減頭に来たのでググったら、エンコーダを掃除したら治るよ、みたいな話が出てきたので、そんなばかな、と思いつつためしに分解。メーカー修理? こんなガバガバな製品作るようなメーカーがまともなサポートなんてあるわけ……

 分解はすごく簡単というほどでもないけど、難しいというほどでもなく、面倒なだけ。基板がいっぱい入ってる。メインボードの下にはmicroBコネクタだけ乗った基板が1枚入っている。使い方によっては頻繁に抜き差しするから、摩耗したり破損した場合はメーカーに送ればコネクタだけ交換してくれそう。一番下に入ってるから作業コスト高そうだけど。

 ホイールの側面にRGB LEDがついた基板と、本体側面にポゴピンを受ける基板、上面にデフォルトで感度設定が割り当てられたボタンが付いた基板。側面パネル(3個)にもそれぞれスイッチやRGB LEDが大量に乗った基板が入ってるから、トータルで製品に8枚くらいのPCBが入っている。そりゃまあこの値段にもなるか……という感じはする。納得はしないけど。

 右クリックと左クリックはRAZERのロゴが入ったマイクロスイッチ。中クリックはTTCのマイクロスイッチ。ホイール左右はタクトスイッチ。エンコーダはKailhものが空中配線されている。

 エンコーダは汚れている雰囲気はなかったけど、何回かグリグリやって組み立てたら、チャタリング解決した。なんでだよ。

 組み立ててしばらく使っていてから気がついたけど、ホイールのクリック感が時々強くなる時がある。このホイール、クリック感が非常に弱くてエンコーダの中途半端な相で止まることがあって、不意にスクロールしたりすることがあるんだけど、もしかしたら不良個体を引いただけなのかもしれない。本来はもっと歯切れのいいクリック感があるのかも。

 Kailhでググるとマウス用のエンコーダの話が大量に出てくるから、一応ちゃんとしたメーカーではあるんだろう。ただ、ちょっとした埃で正しく動作しなくなるとか、品質面ではちょっと微妙な気がする。不良個体だから影響を受けやすかったという可能性はあるにしろ、それなら不良個体を出荷した品質管理という話になるし。

 やっぱりマウスを買うときは店頭で現物を触ってから買う方が良い。手に馴染むとかの話だけじゃなくて、不良個体を買っても判断ができない。明確に使用できないとかならともかく、ちょっと動作がおかしい程度だと「品質悪いけど、こんなものか」で済ませてしまう可能性がある。可動部の数で言えばキーボードよりマウスのほうがシンプルだけど、複雑度で言えばマウスのほうが高い。キーボードだと他のキーと打ち比べたりできるけど、マウスは各機能の直交性が高いので判断が難しい。

 ホイールのチャタが治って安心してたんだけど、数日でまた軽微なチャタが出始めた。んなーーー。それっぽいエンコーダ買って交換しようかな。。。

 PC側ソフト、最近は比較的安定していたんだけど、最近また調子悪くなってきた。サイドパネルのボタンが反応しなくなる症状。パネルの着脱とかマウス側の電源OFF/ONでは復旧せず、PC側ソフトの再起動で復旧する。数時間ごとにこういう挙動が出るから、いちいち再起動させるのが面倒。Razer君さぁ、マジなんなん?? 低品質なハードウェア、低品質なソフトウェア、高いのは値段だけ。


 液晶を内蔵したトラックパッドってないんだろうか。マウスとしても使えるし、ジェスチャ操作だったり、画面端からフリックしてショートカットキーを表示したり。ASUSのノートPCとかでいくつか例があるけど、デスクトップPC用で同様のデバイスってないのかな。

 5インチくらいのタッチ液晶に適当なPC側のソフトを組み合わせるだけで作れそうな気がする。液晶にアプリを常時表示させておいて、HID入力をキャプチャして上書きしてやればいい。探せばそんな感じのアプリありそう。ちょうどいい大きさのタッチ対応液晶のラインナップがほとんど無いのが難しいところ。