先週は風邪でへばっておりました
***
FH4(UK)だと、走ろうと思えばわりとどこでも走れる自由度があったけど(FH5は未プレイ)、日本マップはその自由度が低そうな感じがするのが若干の懸念点。FH4もそれなりに起伏はあるけど、日本の場合はとにかく崖が多いからな。降りるのはともかくとしても、登るのは大変そうだ。まあ、ドライビングゲームだしちゃんと調整してあるだろうけど。
「クルマですから」と言い訳して空飛ぶクルマを何機か用意しておいて、普通の車では行けないような場所には空から行けるようなシステムがあれば面白そうだけど、さすがにForzaで空は飛べないだろうなぁ。イースターエッグでトヨタの資金が入ったJoby、大穴狙いでHondaJet。eVTOLはどこでも離着陸できるから便利そう。HondaJetはさすがに厳しそうだな。FH6のマップエリア的には空港は少なくとも5箇所程度は配置できるだろうけど、それにしても。過去作だと飛行機とのレースみたいなミッションもあったし、今作は新幹線とのレースもあるらしいから、可能性としてはHondaJetとのレースも排除はできないか? ガンダムが出てくるなら、HondaJetくらい不思議でも何でもないか。
FH6とACSは地域的にかなり重なってるはずだし、比較とかあっても面白そうだなー。/* YouTubeのUbiの本チャンネル、ACSの動画全部消えてる? */
PCストレージ大手Western Digital、「今年のHDD供給枠はほぼ完売」。HDDにもAI特需の波 - AUTOMATON
「AI時代のローカルシステムなんて安物(ネットワーク機能と映像デコーダだけ乗ってるスマホorタブレット)で十分だよね? 計算に使えるリソースは全部買い占めちゃうけど問題ないよね」みたいな感じ。ゲームみたいにメモリやら色々必要な場面も、サーバーサイドでレンダリングまでやるようなプラットフォームがそれなりに進化してきたからなぁ。手元に高い計算リソースを置くような使い方は近い内に駆逐されそうな勢い。
一昔前は@homeみたいな分散コンピューティング(一昔前ならSETI、最近話題になったものだとFolding)があったけど、このままコンシューマー向けノードの高コスト化が進むと10年程度で無くなりそうだな。
そういう時代になると、ビットコインみたいな非商業的(非プロプライエタリシステム)のブロックチェーンってどうなるんだろうか。マイニング用の機材がどんどん高コスト化して計算アセットが減少していくと、計算量で信用を確保するようなシステムはつらそうだが。そのうち計算ノードが減って多数決が弱くなって、どこか予算力のある組織が安くなったオンライン計算リソースでゴリ押しして掠め取って、バレないうちに現金化して、みたいなこともできたりしないかな。
ロボットと「Xbox」のコントローラー 冬季五輪の写真の舞台裏を探る - CNN.co.jp
"主要なイベントでは、撮影から処理されるまで30秒以内ということも珍しくない"
"ロボットカメラは会場内やミラノの拠点から操作され、ゲーム機「Xbox」のコントローラーで制御されることが多い"
https://www.jrhokkaido.co.jp/CM/Info/press/pdf/20260224_lavender_engine.pdf
JR北海道で'25年11月に発生した、車両から発煙した事故の報告。
エンジン燃料系のコントローラのハンダにクラックが発生し、振動で異常な制御値が出力され、過大な燃料が供給され、エンジンが過回転に至った。
コントローラー基板の写真もある。こう言っちゃなんだけど、電子工作で作るような基板とほとんど同じだな。SMDは一切無し、金属皮膜抵抗だらけ、背の高い部品はポッティングしてあるのが高信頼向けっぽい感じではあるけど。部品が乗ってない場所に2.54mmグリッドのランドを大量に配置しているあたりとか、いかにも。
しかし、光学顕微鏡にデジカメを載せたやつを「電子顕微鏡」かぁ。
他の車両については振動を与えて異常値が出ないことを確認した。コントローラー自体が故障したことで保護が働かなくなっていたので、監視用の機材を追加で搭載する。
ただ、この手の安全装置は、それ自身が故障していることを検出するのが難しいのが問題な気がする。「気づいたときにはもう遅い」みたいな。フェイルセーフデバイスが安全側に故障しているならまだマシで、危険側に故障していることを、事故が起きてから知った、という事例は多い(明らかにバイアスがあるので当然とはいえ)。
JR北海道の状況を考えると、ただでさえ採算性の悪い北海道の旅客輸送で、安全装置を追加したこと等によるコストの増加に対して、経営陣(&国)からのコスト削減圧力を受けて、機材の点検・整備の手が抜かれて、結局また別のトラブル(or事故)を起こす、というような流れになるような気もする。
安全性の向上に一番有力な手段は大規模な予算の投入なんだろう。それで設備の維持や更新を行ったり、コスト意識による圧力(「早く作業を終わらせなければ」という考え方等)を減らして確実に作業を行う。ただ、JR北海道の収益性でそういうことは不可能だろうけれども。
不景気の何がだめって、人の命が安くなるのが一番だめな気がする。好景気でも各種コストが高騰して相対的に低コスト化圧力が強化されたら意味ないので、バランスの問題なんだろうけど。
新幹線の分離の途中経過。
不規則に開閉動作を繰り返す事象、素人考えだと配線が浮いてノイズが入ったとかを考えるけど、でも「1年以内に調査を終えることが困難であると見込まれる状況」ってことは、そんな簡単な話じゃないんだろうな。
制御線の単純な接触不良みたいなトラブル、例えば金沢シーサイドラインの事故やボルチモアの貨物船事故みたいな場合だと、1線で1信号を伝送するような従来の方式(アンサーバックのない方式)が弱点になっている感じもする。これがデジタルデータバス(誤り検出や双方向通信)で通信していた場合は、故障検出のロジックが多層的に構成できて便利そう。1553的に冗長化してもトータルで見れば配線本数は減らせるかもしれないし、冗長系やルータで頑張れば断線しても短時間(遅延なく～百ms未満程度?)で復帰できるし。ただ、デジタルデータバスの場合は決定論的な通信が期待できないみたいな欠点もあるし、実際に万博の自動運転バスでそういう不具合があったわけで(本来は適切なFDIRを設計するべきだろって話なんだけど)。このあたりはSDVでどんどん規格を更新していくだろうし、10年20年後には大規模な公共交通機関にも取り入れられるんだろうけど(その時代にその手の輸送の新規設計作業が残っていれば)。
ハンダのクラックの非破壊検査って、ぐぐるとX線検査みたいなのばっかり出てくるんだけど、原理的にかなり難しそうな気がするのだが、もう少し別のソリューションって無いんだろうか? 例えば超音波みたいなインピーダンス変化を見る手法であれば、割れた面を確実に計測できそうだが。とはいえ固体中で波長が数十um程度の波だから、滅茶苦茶な高周波数が必要になるだろうし、液体につけて波を入れなきゃいけないから、その液体から基板をどうやって保護するか、みたいな問題もありそう。最終的に、X線CTスキャンが一番手軽、って話になるんだろうか。
どの手法にしろ、明らかな起点がある場合や、亀裂が進展するよりも短い周期で検査する以外には、実際にクラックが発生してからじゃないと検出できないから、結局は適切なFDIRで処理したうえで、BITSで故障箇所を検出する、みたいな感じになるんだろうか。航空宇宙分野だと冗長化で頑張る(札束で殴る)みたいな方向性も可能だけど、地上輸送系でそれは難しそうだな。新幹線くらいまでのスケールだと、適切に緊急停止できる余裕だけ確保しておく、くらいが落とし所か。
オフィスとかで、イーサネットケーブルをJJコネクタで中継するとスループットが低下するのでNG、みたいな話、実際のところどれくらいの影響があるんだろう? ツイストがほどけたりクロストークやリターンロスが悪化するから、ともっともらしい説明が出てくるけど、でも通ってるのってデジタルデータですよ? 普通は信号が多少劣化したところで問題なく復調できるだろうし、それでも復調できないレベルまで信号が劣化しているなら「スループットが低下する」(ちょっと遅くなる)レベルじゃなくてもっと大きな影響(大量のパケットをロストするとか)が出てくると思うのだが(1000BASEはだいぶアナログっぽいけども)。
「コネクタが抜ける可能性が排除できないから」みたいな理由ならわからないでもないけど、第一義的にスループットの低下を挙げるのはちょっと信用ならないというか。あるいは「延長コネクタが燃えた」とかに関しては、そりゃPoEと組み合わせるやつが悪いだろ、という話だろうし、「後からPoEに流用するかもしれないから」というなら、それを理由にして禁止にしろ、という話だし。
Apple Siliconみたいなダイをスタックするような半導体を最大限突き詰めた方向性のスマホ(モバイルデバイス)ってどこまで行けるんだろうか、という空想。ストレージもフラッシュメモリで半導体化されて久しいし、表示デバイスもマイクロLEDみたいに半導体で作りやすそうなものもあるし。カメラ(光学デバイス)だって半導体プロセスでメタマテリアルとか開口マスクを作るような感じで作れるだろうし。マイクやら多少のセンサは現状でもMEMSで半導体化されているし、スピーカーもイヤホンみたいな小電力のものはすでにMEMS化が提案されているし。アンテナみたいに高誘電体とか物理寸法が問題になるようなものは工夫が必要そうだけど。
ディスプレイで発電するみたいなデバイスの提案もあるけど、現状の課題は電力が厳しそう。バッテリーだけ接着剤で貼り合わせて、必要に応じてアンテナも貼り付けて、それ以外は全部ワンチップ(チップレット)に収まったスマホ、みたいなものって作れないんだろうか。カスタマイズ性が最悪なのでよほど製造プロセスを最適化(高柔軟化)させないと厳しいだろうけど。
設計支援からチップレットまで垂直統合したラピダスみたいなファブで「ワンチップスマホ」を製造できたら面白そうだけどな。細かいネジ等が大量に必要な組み立てコストがゼロだし、機械的な結合がほとんどないから故障リスクも低い。半導体が全部抱え込むことになるけど。
ぐぐってみると、半導体固体電池というものが研究中らしい(2019年の東芝の特許など)。英語表記だとSemiconductor Solid Batteryで、略称はSSBになるのかな。
LIBに比べて容量は低いが、単純なキャパシタよりは3桁以上大容量で、半導体プロセスで作れるので、ロジックのバックアップ電源(チップに電源を内蔵できる)等の用途が想定される、みたいな話。
化学反応で貯蔵するのではなくて、電荷をそのまま貯める。電池というよりキャパシタに近い。現状スパッタリングで作っているけど、塗膜でも作れるらしい。効率や容量が改善すれば、エネルギー変換無しで純粋に電荷を貯めれるので面白そう。半導体全固体電池でも、フラッシュメモリと同じように寿命があるのかもしれないけど。
化学電池は化学反応である程度安定な電圧が出る利点があるけど、キャパシタとかSSBは充電率と電圧が比例するので、後段で安定化させなきゃいけない手間がな。LIBもDCDCやPOLは必要にしても、電圧が安定していればDCDCの動作幅が狭くていいので、特定の比率の変換に特化して高効率な設計ができる。逆に、SSBは電池内部でのエネルギー変換(ロスや反応による発熱)が無い分で大電流充電ができるとか、充電率と電圧がリニアだから適当な電圧まで定電流で突っ込めばいいとか、過熱保護が必要ないとか、フューエルゲージが必要ないとか、エネルギー管理全体で見れば削れる機能もあるんだろうけど。
ディスプレイやRF、あるいはスピーカーみたいに大エネルギーを扱う機能はちょっと懸念が残るけど、チップレット単体でスマートフォンを作るのは、原理的にはできそうな感じだな。発電だって光電変換とか熱電変換は半導体でいけるし。
消費電力が少ないディスプレイと言うと、一番究極なのは反射式の液晶だろう。輝度をまるごと外部に依存する。ただ、完全固体化スマホを空想するうえで、表示デバイスが液晶というのはいただけない。E Inkも同様。有機ELもちょっとなー。最終的に、完全固体化を目標とすると、マイクロLEDしか残らなさそうだ。
わずかなエネルギーを突っ込むだけで反射率をスイッチングできる半導体素子みたいなものって作れないんだろうか。光の反射が電子によるなら、電子的に反射特性を変えられる素子があっても良さそうだけどな。自由電子が大量に入っていれば高反射率、自由電子を吸い出せば低反射率、みたいな画素。
Electroreflectance - Wikipedia
https://www.jstage.jst.go.jp/article/electrochemistry/67/11/67_1078/_pdf
材料系の分野だと、電位を変調してロックインアンプで計測して反射率の変化を計測する、みたいな手法はあるっぽいな(下のPDFでは金を測定する例)。反射率で変調度が浅いから実用的なディスプレイとしては使いづらそうだが。全体が金メッキで文字盤も何も無い腕時計が、よく見ると薄く時刻が表示されている、みたいな時計は、作れなくはないか。いかにも成金趣味っぽいし、今の時代に売れるとも思えないけど。
飛行機の飛行制御の資料。「B747は飛行中に4発のエンジンが停止しても、また、エンジンの1つが落下しても、いん石などの衝突などで外翼がとんだり落雷などで垂直尾翼が半分とれても、更には水平尾翼やエレベータの一部がなくなっても操縦可能であることが大きな特徴である」とか書いてあってすごい。エンジンが4個ついているから、油圧の冗長系がかなり多い。とはいえ、それでも全系統全損とか起こしてるわけだが(全系統の作動油を喪失することもあるし、エンジン4発全部止まることもあるし)。
PCのメインモニタの液晶画面の謎のゴミ
表からこすっても取れないし、表示内容を変えても消えないし。ピクセルのグリッドがあるから表示内容の問題か?とか思っていたら、なんか動いてやんの。これ、液晶パネルの奥、バックライトの手前の隙間に入り込んだ小さな虫らしい。これが「バグ」か……
液晶パネルってちゃんと密閉されてるものだと思いこんでたけど、結構隙間あるんだな。バックライトを拡散させるために空間が必要、ということなんだろうか。空間があるところを密閉すると不都合だから、適当にベンチレーションを開けておいて、場合によってはそこに虫が入り込む、みたいなこともあり得るわけか。
***
タイムコードジェネレータのやつ。
いろいろ書き換えて、アナログ1系統、デジタル4系統から、比較的自由に信号を出せるようになった。デジタル系からアナログ信号(e.g. 振幅変調正弦波)を出せないのは当然としても、そういう部分を除けば、概ね好きに出せる。とはいえ、現状IRIGのマンチェスタは未実装だし、対応しているのはIRIG-A,B,H,JとJJY(40/60kHz)、それから1,10,100PPSと1,10,100kHzの正弦波、といったあたりだけども。JJYは振幅変調で出せるので、近くに(ほとんど容量結合させるような距離に)電波時計をおいておけば、それに時刻を反映させられる。
計算リソース的には今の3倍くらいは出せそう。重いのはアナログ(1MB/sの波形をコピーしなきゃいけない)なので、デジタル側は空きピンを全部割り当ててもまだ余裕な気がする。
アナログは、STM32F303K8を使う以上、ボルテージフォロアが1chしかないので、アナログは1系統しか出せない。HiZで良いならDACはもう1本使えるし、全chがHiZでいいならトータルで3ch使えるけど、とはいえメモリ容量(全12+4KiB)の制限があるから、現状ではアナログは1chしか出せない。
バッファは現状1ms(1kHz) x2で確保しているけど、これを例えば2kHzにすればメモリ使用量は半分になるから、3chのADCでも余裕はある。ただ、計算がだいぶ面倒になるので、やりたくない。
ということで、当面はアナログ1ch+デジタル4-8ch程度で固定の予定。ちゃんとしたIRIGタイムコードジェネレータとして市販するなら振幅変調は4chくらい無いと話にならないんだろうけど、そんな予定も無く。G474REなら4xLowZ+2xHighZの6chまでアナログ系を出せるはずだが、さすがにQFP64を自分で扱うのは面倒(Nucleoはピンアサインが悪くてアナログ系の制限が強い)。
***
STM32L010F4で遊んでる。TSOP20で32MHz、Flash16K、RAM2K、という感じのスペック。CubeMX(HAL)で使おうとするといかんせんRAMの少なさがどうしようもない。QFP32(e.g.STM32F303K8)より一回り小さいので、32ピンまではいらないような簡単な用途には便利だし、SOP8みたいに極端な小パッケージ(電源2本とSWD2本以外にGPIOが4本しか使えない)に比べれば使いやすくはあるのだが。
L101F4のUSART2のCTSを使って、外部トリガに同期してRS232メッセージを出力
紫がTIM2_CH1のPWM信号、黄がUSART2_TX信号。124.70nsで標準偏差120psくらい(1Gspsなのでオシロ側のジッタも大きい)。もっと盛大にジッタ出るかと思ったけど、かなり安定しているな。両方とも同じクロックで動いているからかな。コアが32MHzで動いているので、4クロックで125nsになる。0.24%程度の差があるけど、これはHSIの精度(3.0V常温動作時1%)の範囲内なので、クロックの誤差が見えているものだと思う。右上のトリガレートも1.0027kHzで、1kHzに対して0.27%高い。値としては若干違うけど、精度としては良さそう(オシロ内蔵のクロックも精度あまり良くない)。
USARTを適当な信号に同期して出力できることがわかったので、これを利用してIRIG Jシグナルジェネレータを作成。
機能としては、1PPS、10PPS、IRIG J-xyを出力するだけのシンプルなもの。これは前回の多機能なものは機能が多すぎて動作確認が面倒という反省によるもの。現状、クロックの出力は無し。必要ならMCOで1MHzや8MHzは出せる。手持ち部品の関係で10MHzは出力不可(逓倍器や分周器が基本的に2^nしか設定できないので、10MHzを出したいなら10MHzや20MHzのCMOS出力発振器を外付けする必要があるが、手持ちに無い)。
IRIG Jはとりあえず12,13,14,25,26,27,28,29に対応。2年ほど前に買って積んでいたサムホイールスイッチを1桁で使って、0-9までを選んで、0と1は無出力、2-4はIRIG J-1y、5-9はIRIG J-2yに割り当てている。
ただ、今回はTIMでUARTのCTSをトリガしていて、出力モードの切替はUARTやTIMの設定をまとめて変えなきゃいけないので、過渡特性をきれいにしようとするとかなり面倒。
F3で作っていたときは1MHzのサンプリングクロックでDACとGPIO(BSRR)にまとめてバッファを転送していた(IRIG JもソフトUARTで生成した)から、時刻は決定論的に決めることができていた。今回は10Hzのタイマで時刻を管理したうえで、UARTのバッファを書き換えたりする必要があるので、かなり面倒。
ピンアサイン
基本的にすべてのペリフェラルはユーザーコードから直接レジスタを叩いて初期設定やらいろいろやっている(CubeMXで初期化するとハンドルがデカくてRAMに余裕がない)。なのでペリフェラルに割り当てたGPIOは宣言だけしている(CubeMXで宣言しておけばそれ用の初期化コードは書いてくれるし、GPIOの初期化はスタック領域だけで完結する)。
PA0はHSEに予約、PA9はMCOに予約、PB9はBOOT0に割り当てられているので予約。
IRIG Jの出力にUSART2_TXを使用していて、このピンアサインだとLPUART1は使えない。ピンを整理すればもしかしたら使えるかも。自由に使えるUARTが無いので、時刻は起動時に1日0時0分0秒0からカウントを開始する以外に設定ができない(反映をIRIG Jで確認するなら、UART2_RXでIRIG Jと同じボーレートで設定することはできるはず)。
最初はL010F4の20pinはちょっと大きいかな、L021D4(14pin)あたりがあると良さそうだな、と思っていたけど、20ピンでも結構ちょうどいい感じだな。
STM32F1の汎用タイマはCNT==CCRxの場合にしかSR.CCxIFがセットされないはずなんだけど、STM32L0の汎用タイマはCNT==CCRxの場合だけでなく、ARR<CCRxの場合は常にSR.CCxIFがセットされるらしい。
TIMよりも長い周期のPWMを出したい場合に、DMAでCCRに転送して、ピンの論理を固定したい場合に、ARR<CCRの値(例えば0xFFFF)を入れる事があるが、その場合にSRが期待した結果を返さなくなる。
