小ネタ

　HDMIセレクタのインジケーターが謎の点滅を発症してレコーダからの映像が来なくなった。つぎはおまえか!!

　なんのことはない、レコーダ側のHDMI端子が微妙に抜けて接触不良してただけだった。F端子繋ぎ変えたときに抜けたらしい。狭い範囲にF端子が4本、HDMI、100base、USB3.0が並んでるので繋ぎ変えが大変。指が入らない。

　セレクタの取説、インジケーターの説明とかは特に書かれてなかった。なんのための取扱説明書かと小一時間(ry

***

　いよいよ旧レコーダのファンがヤバそう。1回完全に停止して電源落ちた。電源入れ直したら動いたけど。

　壊れたのならしょうがない、ということで蓋を開けてみたら、ファンの回りにヒートシンクがあるわけでもなく、強制空冷というよりはこもった熱を逃してる感じ。蓋を開けたままならファン無しでも良さそう。ということで再び電源ON。ファン回ってても換気してないし、うるさいし、と思ってファンを外してみると、しばらくして勝手にシャットダウンする。ぐぐってみると、ファンが無かったり停止したら落ちるのは仕様らしい。

　ファンは結構不思議な挙動してる。電源をオシロで見てもPWM変調されてるわけではなく、必要な流量に応じて電圧が変化するらしい(電源は綺麗なので、可変レギュレータでも乗ってるのかも)。3ピンのうち2本は電源として、残りの1本が謎い。オシロで見ても特に何か流れてるようには見えない。

  ファンに棒を突っ込んで(くれぐれも真似しないように)強制的に停止させると、やはりしばらくして電源が落ちる。ただ、ファンブレードがピクピク動いてるので、回転が止まったことを検出して一旦給電を止めたり、もう一度電源を投入して回るかどうかを試したり、結構複雑なことをやっているっぽい。電流センスかなにかで死活確認やってるのかな?

　録画データ全部移し終わってればあとのことは気にせず分解して回路追ったりできるんだけど。本体に残ってるデータはほとんど動かしたけど、外付けHDDにまだ結構大量に残ってる。一旦本体を経由しなきゃいけないし、内蔵HDD-外付けHDD間の移動は結構手間がかかる。

***

　JSF++を軽く読み直して、ついでにMISRA-Cの解説とかもちょろっと読んでみたり。

　MISRA-Cの日本語の解説本、対象読者が「C言語1年目くらい」らしいんだけど、一方で「ソフトウェア開発者は1年目でコンパイラを書ける実力が必要」らしくて、ちょっと厳しすぎません?って感じ。日本の自動車業界で自分でコンパイラ書ける人どれくらいいるんだろうか…… シンプルなインタプリタくらいだと頑張れば最低限は……くらいは行けそうだけど、コンパイラってことは機械語吐けってことだよな。たいへんそう(

　まぁ、汎用のコンパイラを使ったらバックドア仕掛けられちゃうもんね。自動車制御とかセキュアな用途だったら自分でコンパイラ作らないと安心できないよね。開発者ひとりひとりが自分専用のコンパイラをハンドアセンブリして作るなんて、日本の自動車のセキュリティは素晴らしいなぁ!!(くれぐれも書いておきますが、これは皮肉ですよ)

「最近の変更のドラフトに文字コードの指定が入ってたけど、日本からの働きかけで削除してもらった」という話が書いてある。日本の自動車開発の現場だとソースコードにコメントとかで日本語書き込んでるからルールに準拠できねぇよ、というような話らしい(変数名にマルチバイト文字を使ってるとか、そんなまさか……)。

　JSF++でも文字セットと文字コードの指定があって、空白とか改行を含めてトータル96文字、実質的にASCIIコードを指定、という感じ。JSF++ではインデントは空白を使えと推奨(should)しているけど、文字セットには水平タブどころか垂直タブまで定義されてる。

　日本もF-35買ったけど、ソフトウェア書き換えるとか書き換えないとかの話どうなってるんだろう? 結局120買ったから書き換えず使うのかな。さすがに戦闘機のソフトウェア書くような人なら日本語コメント禁止縛りでもできそうな気はするけど、某飛行機のソフトウェが「大卒新人が書いてた」とか言われてるのを聞くとあながち……

　JSF++ではルール9で具体的に使える文字を列挙して、ルール10でISO 10646を指定している。ルール9はwillなので、責任者に許可貰えば破ってオッケー! ってことで、UTF-8でソースコード書いて範囲外の文字のコメントを含めることはできる。まぁ、それを言い始めるとルール10(will)を破る許可をもらえばShift_JISとかも使えるわけだが。

　MISRA-Cで作ろうとしてたルールって例外なしのshallでUTF-8を指定して、日本のソースコードがShift_JISまみれだから反対したという可能性が……

***

　すっかり忘れてたけど、MSFS2020のSDKの話題がちらほら出てきてる。曰くSimConnectに対応、だそうだ。マジかー。あのクッソ面倒なAPI…… LMに売り払ったんだから潔く全部作り直せばいいのに。過去のサードパーティー製品考えるとそういうわけにも行かないんだろうけど。FSX用とかP3D用に用意した自作コックピットとか市販の製品使い回せるのは便利だろうしなぁ。LMからソースコード買い戻したんだろうか? それとも残ってた仕様書をもとに書き直したのかな。

　昔のエントリ読み直したら、C#からSimConnectを叩くには.NET FW 2.0にする必要があるらしい。やっと.NET Core 3.xに慣れてきたところなのに……(いや、いまさらCoreかよ)。2020に付属のDLLなら近代的な.NETで書き直されてるのかな?

　MSFSXの発売が2006年。SimConnect関係のエントリが2016年。当時のエントリには「今更こんなAPI叩いて……」とか書いてあるけど、5年も経って伏線回収するなんてなぁ。

　PC買い替えたらMSFS2020買う。いつになるやら。。。

***

　壊れたヘッドライトが「壊れてるから壊していいよ」と持ち込まれた。それなら遠慮なく。とはいえ、電池周りの端子が液漏れで接触不良してただけなので、洗浄したら治ったわけだが。

　とはいえ、せっかく「壊していい」と言われてるんだから、軽く分解。

　最近のマトモなライトって全部LED化されて、電球交換も不要だから発光部を分解できないことも多いんだけど、こいつはキャップのネジを外せば一通り分解できる。

　なんか見たことあるようなLED Assyだなぁ。スター型基板ってどっかで規格化とかしてんのか?

　白色LEDといえばCREEというイメージだけど、CREEは昨年にLED部門を売却してパワエレに注力して、社名も変えたらしい。SiC製造に強みを持ってる会社としては、コモディティ化されたLEDで価格競争に巻き込まれるよりは、自社の強みで付加価値をつけれる分野に行くのは自然なことだろうけども。

　メインの片面PCB。COBが1個と、チップCRが1個ずつ?、チップトランジスタ?が1個、くらいか。あとはタクトスイッチ。前の写真で違和感持った人もいるかもしれないけど、LEDへの配線は正負共に赤色、電池からの配線は正負ともに青色。しかも電池からの配線はパスコンにハンダ付けされて、タクトスイッチのハンダは1箇所ついてないという、いかにも低コスト化最優先みたいな製品。/* 映画に出てくる時限爆弾みたいな色合いだ */

　PCBは接着されてるようで、軽くラジオペンチで引っ張っても動かなかったので、とりあえずここまで。

　もとに戻して、ちゃんと点灯することを確認して、返却。光軸はかなりいびつ。まぁ、光学設計なんてやってないだろうし。

　物欲刺激されてPETZLのヘッドライトとか欲しくなってきたので、とりあえず光り物はここまで。ただでさえ普段遣いしてない光り物がいくつもあるのに、これ以上増やしても……