前回書き忘れていた話題
By Cmichel67 - Own work, CC BY-SA 4.0, Link
この人(Adam Steltzner)、もとはミュージシャン。高校の数学(geometry)は不合格で、大学ではジャズを学んでいた人。ある日見上げた夜空で、以前に見た星座が全く違う場所に見えることを不思議に思って天文学の勉強を初め、現在はNASA JPLで火星探査機パーサビアランス(Perseverance)の責任者を努めている人。
前回、ISASの人が『天体観測』のMVを作った動画を貼ったのに、Steltznerを思い出せなかったのが悔しい。。。
MSRミッションやMMX等でこの人達が集まることもあるだろうし、その時はコラボしてミュージックビデオ作って欲しいなぁ。「もう夜空を見上げるだけの時代じゃないぞ! 俺達の手の中には実物があるんだ!!」
/* Wikipediaの画像埋め込み、なんでソースのタグが特殊文字になってるんだろう。。。 */
***
戦艦ニュージャージー(博物館として保存)のキュレーターが、なぜ映画『バトルシップ』を見ないのか。
***
https://www.sjac.or.jp/common/pdf/toukei/50nennoayumi/4_5_nihonnokoukuki7-8.pdf
2002年頃の資料?
さらに最近では、エアバス社A340、330、320向けのLCDモジュール(6.25"x6.25")を横河電機が供給を始め、今年からA380向けのLCDモジュール(6"x8")の供給を始める。 (83p)
93pにはカシオ計算機が横河へTFT液晶を供給しているとのことだが、ここはA380の文脈で、6x6インチと書いている(従来のA340向けの製品なのかもしれないけど)。6x6とか6.25x6.25とかいろいろ数字が出てくる。。。
このPDF、かなりの箇所で小文字のエルが数字のイチに誤植されている。あとは'間'が'問'になっていたり。この頃はまだ手書きの原稿が残っていた時代なのだろうか? それにしたってDisp1ayやCrysta1みたいな、文脈として明らかにおかしい部分もあるし、人間のミスというよりはシステムの問題のような気もする。でもOCRで処理したにしては誤認識が少ない。
***
横河のカタログ、A320, 330, 340向けの6x6LCD、Active areaが158.75 x 158.75mmだから、表示エリアはちょうど6.25"ってことか。解像度は756x756px。なんで756pxなんだろう? かなり中途半端な値だと思うんだけど。
ドットサイズは0.21mm/pixくらいだけど、インペリアルだと120.96dots/inchになる。CRTの規格として60lines/inchを満たす解像度の表示機を使え、というような要求があって、それを満たすように設定した、というような感じだろうか? 航空機用のCRTは一般的なテレビと違って水平走査ではなく、ベクトル形式の入力インターフェースだそうだから、テレビの液晶化のように基準となる解像度(走査線n本)が存在せず、最低60LPIを識別できるように、みたいな要求が設定されていた可能性はある。
A350XWBでは13x8"と書いてある。アクティブエリアは331.6 x 207.2mmなので、インチでは13.055x8.157"くらいの中途半端な大きさ。ただし対角は15.4"で解像度が1440x900px(WXGA+)だから、民生品と同じ規格(16対9ではなく16対10だが。テレビ用ではなくPC用でよく使われる規格)。
A380に関しては何も書いてない。
A380のディスプレイ、もしかして10.4"のXGAを縦置きしたのかな? これだと6.24x8.32"で、それほど外れた数字にはならない。A330等の6.25"スクウェアを、ほぼ同じサイズの民生品から10.4"XGAを選んで縦置きして6枚から8枚(+サイド2枚)へ増やして、A350XWBでは横に並んだ2面分を15.4"WXGA+に置き換えた上で横方向に広げて6枚を使用、みたいなシナリオは有り得そうだな。
YOKOGAWAグループの航空機用計器事業を取得｜プレスリリース｜OKI
OKIの製品情報を探しても出てこない。今年度初め付けだからまだ用意してないのかな?
http://www.iadf.or.jp/document/pdf/21-4.pdf
B777では8x8"のディスプレイを使っているそう。これが正しいのであればエアバスよりもかなり早い段階で比較的大型のディスプレイを採用している。
B787ではアビオニクスの統合を進めることで、操縦系と航法系を1台の画面に表示できるようになったことから、ディスプレイも12x9.1"(対角15.1")へと大型化・統合化されている。
F-35がそうであるように、全く別のシステム(飛行制御・航法・通信・状況認識・火器管制・その他)を1枚の画面に統合して表示するシステムもあるけど、描画用のコンピュータが壊れると一切の表示が消えてしまうから、民間機の場合はそれぞれ独立したシステムが長らく使われていたんだろう。最近になってシステムの信頼性が向上してきたことで、787やXWBでは異なる設計思想を採用できるようになってきた。電子機器への依存度が高くなると、今度は「定期的にシステムを再起動してください」みたいなトラブルが入り込む余地も増えるけど、まぁ、その手のトラブルはパトリオットミサイルのように湾岸戦争の頃にもあったわけで、ソフトウェアが複雑化してくると避けられない。787では電装系だけでも2000lb(1トン弱)の重量削減を見込んでいたようだから、重大事故には発展しない程度の多少のリスクは承知した上で採用したのだろう(システム全体で見ると結構危ないところだったけど)。
Don’t Throw Away Those CRTs | Business Aviation News: Aviation International News
同事業所は1965年に日本初のカラーテレビ工場として稼働を始めたが、(中略)。その後は航空機の操縦室用のモニターに使うブラウン管などをつくっていたが、21年3月末に製造を終了することから閉鎖を決めたという。
飛行機用のCRT、ついこの間まで製造が続いてたんだな。
***
解像度のテストチャート
これは 1951 USAF resolution test chart と呼ばれるタイプ。文字通り、アメリカ空軍が規格化したテストチャート(MIL-STD-150A、廃止済み)。当時のアメリカ空軍は(というか世界的にそうだけど)、空中偵察ににフィルムカメラを使用していた。今みたいにマウスで操作して拡大したりできないから、興味深い場所はルーペで確認していた。その際に使う光学機器の解像度が悪いと小さな目標を見落としてしまうので、顕微鏡の解像度を測定する必要があった。
本来はガラス板にリソグラフィで作るものだが、今回はプリンタで印刷。Wikipediaの外部リンクにあるPDFを100%で印刷したもの。今回はA4サイズだからグループ-4までをカバーしているけど、本来は2" or 50mm程度の大きさで、グループ-2以下の範囲をカバーしているようだ。
右下の一番大きな図(グループ-4/エレメント1)の3本線の端から端が40mmになっていれば、正常な寸法で印刷されていることがわかる。グループの数字が1増えるごとに1辺あたり2分の1に小さくなっていき、グループ内では6個のエレメントがある。エレメントの並びはちょっとクセがあって、慣れないと大変。
上の写真(クリックで拡大)だとG1E3までは線を分離して見ることができるので、分解能は2.52LP/mmということになる(この値はブログに貼り付けた写真の分解能であって、プリンタの分解能や撮影した元の写真ではもう少し高い分解能を持っている)。
線の間隔は計算で求められるので、必要であればどこまででも小さいテストチャートを作ることはできる。実用性はともかくとしても、光学顕微鏡では見ることすら難しいような小さいチャートも作れる。例えばグループ16では線の幅が10nm未満になるから、今の半導体プロセスではこのあたりまでは作れる。/* 最近のこのブログ、海里の意味で"nm"を使うことも多かったが、ノーティカルマイルかナノメートルかは文脈で判断してくれ */
***
せっかくなので、FFTを使用したローパスフィルタ的なヤツの実験
入力画像は実部のみなので、先に処理する方向は負の周波数は必要ないはずだから、半分は捨ててもいいはず。しかし、そういうふうな処理はせず、正の周波数と負の周波数を分けて処理するのが主流らしい。2回目のFFTは入力が複素数(1回目の位相情報)だから、正と負の周波数はミラーにはならない。
上の例だと、高周波側をガッツリ削っていて、縦と横で通過帯域幅が違う(横解像度に比べて縦解像度が4倍)。
縦方向の線(横解像度)はG-3 E6あたりが限界。G-2 E1は潰れている。横方向の線(縦解像度)はG-1 E6あたりが限界かな。G0 E1は潰れている。ちょうどグループ2段分(エレメント12段分)違うので、解像度は4倍の差があり、設定通りの特性が出ている。
バンドパスフィルタみたいなヤツ
スペクトル画像では分かりづらいけど、原点(直流成分)に128を設定しているので、グレーを中心に、白黒のエッジ部分が強調されて見えている。
平面空間でリンギングが大きいのは周波数空間で急峻に切っているからであって、周波数でガウシアン特性にすれば平面でもガウシアンになり、バンドパスの場合はリンギングが抑制される
周波数はMagnitudeを対数で画像化しているのであんまりフィルタ掛かってないような見た目だけど、平面空間に戻してみると、ちゃんとエッジを引き立てていることがわかる。ある程度の周波数特性は残っているので、G-1 E4あたりが明るく見えている。
画像処理といえども、基本的には1次元のFIRと似たような感じ。ただし、音声やセンサの波形と違うのは、基本的に画像はインパルス信号をとらえる必要がある、という点。用途にもよるんだろうけど、エッジや輝点みたいなインパルス信号を拾おうとすると、FIRみたいな信号処理だと厳しい気がする。
周波数空間で急峻な(矩形の)フィルタを使う場合は、上下左右で分解能が異なっても、「そういう画像」として認識できるので、あまり問題にはならない。一方、ガウスフィルタを使って上下と左右の分解能が違う画像を作った場合、強烈な吐き気を催す場合がある。おそらく視覚情報から得た運動量(分解能が低い軸に対して高速移動している)と体内の慣性センサから得た運動量が一致しないからだと思う。今回はそのような図は貼らないが、もしも自分でそういう画像を作ろうと思った場合は、すぐに画像を閉じれる状態で見ることを推奨。個人差があるだろうからケロッとしてる人もいるだろうけど。
***
リモートデスクトップのファイルコピー、映像の転送とファイルの転送を同期で行っているのかな? 大量のファイルをコピーしようとすると画面の更新が止まる。ダイアログは向こうのPCに出るのでキャンセルもできない。リモートデスクトップを遮断すればコピーもキャンセルされるので、再び接続すれば操作も再開できるが。
すっかり忘れていたけど、部屋の片隅から2TBの外付けHDDが出てきた。前にストレージ容量がやばくて慌てて買ったやつ。PCに入れるデータが一気に2TB増えてしまった。まぁ、特に重要なデータが入っているわけではないので、データ移行に使う外付けストレージが2TB分増えてラッキー、という程度(今回はEthernet経由ではなく外付けHDD/SSD経由で移動した)。
試しに開発環境はHyper-Vで構築してみているんだけど、リモートデスクトップで入った実機の中で仮想マシンを走らせる入れ子構造なので、自分が今操作しているウインドウがどこのウインドウなのかをかなり強く意識しておかないと、容易に操作を誤る。
仮想マシン、RAMDISKに乗せておいたら爆速な環境が作れないかな? 今回はSSDにイメージを置いているけど、RAMDISK経由で起動できるならイメージはHDDに置いても速度的なデメリットが無い。ソフト(設定)によっては仮想マシンを使わないときもRAMを圧迫されるデメリットはあるけれども。ただ、仮想マシン側でストレージアクセスをRAMにキャッシュするような動作になっていれば、RAMDISKを使うメリットは皆無なので、事前に確認しておく必要はある。もし仮想HDD全体をRAMにコピーしてキャッシュされるなら、HDDに置いても問題ないことになる。まぁ、流石にそこまでのキャッシュはしてくれないと思うのだが。
5.25インチベイにUSBポートとか引き出したいんだけど、いまいち良い製品が見当たらない。いっそのことPCIe x1のUSB拡張ボードを載せてPCを前後逆に置こうか、とか思うレベル。あるいはUSB 3.xが2本入ってる19ピンコネクタからType-Aのパネルマウントのケーブルを買って、フロントパネルは3Dプリンタで作る、みたいな手もある。手間はかかるけど、自分の好きなように配置できるのが魅力。
マザボに生えてるUSBコネクタ、Type-A 3.xの19ピンとType-CのKey-Aが絶妙に互換性無さげで悲しい。Type-AがType-Cにフル互換性がないのはしょうがないとしても、Type-CはType-Aをカバーしているべきではないのだろうか。Type-C(Key-A)にはD-/D+が1ペアしかないので、2レーンのType-C 1本を1レーンのType-A 2本に分岐できないはず。そういう変換コネクタは市販品があるけど、どういうふうに解決しているんだろう? レビューを見ると片方しか認識しないと書いてあるものが多いから、そういうことなんだろう。Key-AにD-/D+がもう1ペアあれば、Type-C+Type-A(2.0)として使うか、2xType-A(3.x)として使うか、みたいな選択肢が作れたのに。変換コネクタの中にUSB 2.0のハブが入っていればいいのかもしれないけど、そもそもUSB 3.xってそんなに柔軟な規格なのかな?
最近のマザボ、WS2812とかいう誰が作ったのかもよくわからないような規格にも対応しているんだから、DS18B20とかにも対応しておいてほしい。HDDとかM.2とかチップセットとか適当な場所に温度センサをペタペタ貼り付けて温度に応じてファンを制御してほしい。
ゲーミングPCだと「ピカピカ光れ! 冷却? ファン全開でブン回せ!!」みたいな思想だから、制御みたいな面で見るといまいちだよなー。
DS18B20は3pinモードならFT232でUSBに接続できるから、適当なアプリを書けばアプリケーションからPC内部の温度を認識することはできるけど、それをメーカーが作ったファン制御ソフトに渡す方法がない。適当なマイコンで1Wireの制御とファンのPWM制御を担当させるという手はあるけども。
***
小ネタ中の小ネタ
パソコンサポートのチラシが入ってた。「地域密着型」を売りにしている店だそうだ。書いてある住所はウチから直線距離で200kmくらい(途中に山脈があるので車移動だと350km前後)。本州だと下手したら3県くらい横断できる距離。トータルサポートを提供しているらしいんだけど、「ちょっとパソコン調子悪いんだけど見てくれない？」とか言われてもすぐ対応できるんだろうか? 農畜産業向けの監視システム(たぶんWebカメラくらいのものだろうけど)の導入とかもやってるらしいんだけど、この手の代物となると「今すぐ直せ」とかも言われるだろうに、どうしてるんだろうか。まさかロビンソンR44とか導入しているわけでもあるまいし……
とある分野の話題を読んでいて、面白そうな人を見かけたのでとりあえず英語版Wikipediaで検索。1ページもヒットしねぇ。。。 改めてぐぐってみると、どうやらスペルミスらしい(FがEになっていた)。元の文章の著者紹介を見てみると、博士課程の人が書いているらしい。大学生が書く文章なら多少の誤字は許容せねば…… /* 掲載誌は査読付きのものだが */
ラストネームだけカタカナで書いてあって、フルネームは英語のみの記載なので、ファーストネームでのスペルミスは発見が大変そうだ。共著で教授の名前も書いてあるけど、大学の先生だからといって自分が関わってる分野の端から端まで全員のフルネームを覚えているわけじゃないだろうし(英語版Wikipediaでも3段落くらいの業績の人なので、有名な偉人というわけでもないし)。
LOX系のロケットやってる人たち、だれかパソコンのオーバークロックやってくれないかなぁ。小型の電動ターボポンプでLN2を熱交換器に圧送するようなやつ。わりと面白そうだと思うんだけど。ターボポンプや熱交換器の設計・解析の練習にも使えるし、多少オーバークロックしても安定して動くマシンが作れれば今後の設計でもCFDとかが気休め程度にでも早くなるだろうし。
CPUの上に容器を載せてLN2を注ぐような、一般的なオーバークロック用のハードウェアだと窒素の気泡の影響で熱交換効率悪そうだなー、って気がするんだけど、仕事で極低温液体とか熱交換器を扱っている人たちがガチで冷却を設計したらどうなるのか気になる。OCは周辺回路も含めた特性だから、CPUだけ冷却したところで大してスコアでなさそうだけども。
IHS引っ剥がしてダイむき出しにしてLN2を滴下するみたいなシステムも作れるかな? 相当な応答性が要求されるので大変そうだけど。0.8MPaくらいで加圧しておけばある程度の運動エネルギーで押し付けられるから気化した分で押し返されることもないだろうし。
ライムライトってどういう原理なんぞや?と思って調べていたら、光格子時計の話が出てきた。原子蒸気を得るために0.1Wの紫外線レーザを当てたら4000K相当の白色スペクトルが出てきたんだけど、たかだか0.1Wのレーザでそんなに加熱されるかね?みたいな文脈で、ライムライトの発光原理に似てるんじゃね?と。この原理を解明できれば原子蒸気の安定供給に資するので重要である、とも。
1820年代に発明されたライムライトが、2020年代の光格子時計の研究にもつながっていて、しかも未解明なんだな。
0 件のコメント:
コメントを投稿