2025年12月31日水曜日

小ネタ





 三菱電機のワイヤーレーザー金属3Dプリンタ


 三菱電機って切削機は作ってたっけ? たぶん作ってないと思うんだけど。工作機械メーカーが作る3Dプリンタは後加工も含めて一貫して処理できるようなシステムを考えていて、特に松浦なんかは金型用の比較的小規模なマシンとはいえ、積層と切削を交互にできるから工具を突っ込めないような場所も高い面精度で造形できたりするわけだけど、三菱電機はそのあたりがちょっと不利そう。

 まあ、DMGの機械も1台で切削も付加もできるようなやつもあるけど、その分機械1台を占有する時間が長くなるから、例えばスピンドルの稼働率は悪くなるわけだし。切削と付加は機械を分けて、段取りの手間は自動化で頑張って、全体で最適化して低コスト化して、みたいな方向もありだろうしな。



 マキノのレーザー加工機


 水の層流の全反射を使って光ファイバーみたいにレーザーを細いビームで送るので、加工部がテーパー状にならないし、切り屑の除去や冷却にも効果的。ヒュームが出ないのも良さそう。

 Nd:YAGの基本波1umは水の透過性が悪いので、第2高調波の緑を使っているのが特徴的な気がする。レーザー加工機で緑ってあまり見かけないような。赤外をよく吸収するワークなら赤外だし、銅みたいに長波長の反射率が高い材料は青色を使うし。




 スマホで撮ったデータをFramework expansion cardに転送すればそのままPCに挿せるから便利だよ、とか。そんなの普通のUSBメモリだって同じだろうよ、というような気はするけどな。


 とはいえ、Frameworkの拡張カードって色々使えて便利だよな。Type-C to HDMIアダプタとか、SDカードリーダーとか、ネットワークアダプタとか、一通り揃ってるし。

 Framework拡張カード用のUSBハブとかあっても面白そう。好きにインターフェースできるし、そこから拡張カードを外してスマホやPCに直結してアダプタとして使うこともできるし。結局Frameworkの拡張カードって単なるUSBアダプタなわけだし、USBハブに挿して非Frameworkマシンでも使えるようなやつがあっても良さそうだが。



 H3打ち上げ失敗 機体と人工衛星 大気圏に突入した可能性 | NHKニュース

 どこに落ちたんだろう。トランスポンダってNECだよね? 回収して再利用しようぜ。/* 昔のNECの衛星搭載機器は打上げに失敗したロケットから回収して通電したら動作したというネタ */


 なんか思ってたより大事っぽい感じで大変そうだなー。

 仮にフェアリングだとすると、W用のヤツを……とも思いつつ、フェアリングってロケットの中ではオーダーメイド(カスタマイズ)が多いはずだけど、発注してすぐ作ってくれるものなんだろうか。専業メーカーならなるはやで作業してくれるんかな?



 From Manufacturing to Testing: 2025 Year-End Recap - YouTube

 デジタルコックピット周りの説明で左側のPFDの後ろにおいてある白い板状のやつ、Starlink miniのアンテナに見えなくもない気がするけど、どうなんだろ。最初からアビオ系に組み込むにしたってそんな場所に置くかなぁという気もするし。



 個人向け金属製品製造サービス、図面不要で1点からのオーダーに対応:メカ設計ニュース - MONOist



 前回「名前とかどうでもいいだろ」とか言ったけど、DIY系YouTuberがcircuit boardのことを「基盤」と書いてるのを見ると「おまえその上に倉庫でも建てる気か!?」とか思うし、やっぱり名前は大事だなって。



 プレイヤーになりすましたAIを見分けるゲーム、素数テストとかそういう数学系のテストって通じるんだろうか? それとも素数やフィボナッチ数みたいな有名な数列はうまいこと対応するんだろうか? ちょっと性能の良い生成AI程度なら簡単な数列は正しく返せるだろうしなぁ。セキュアな情報、少なくともゲーム内で交わしていない鍵、例えばプレイヤーの誕生日とかを含めた非対称鍵みたいなものを用意して…… なんか普通のセキュリティと同じような感じだ。

 SFで素数テストをやるのはわりと定番のネタだけど、少なくとも現代技術レベルの地球のAIでも正しく回答できるとなると、知性の判定は難しそうだよなぁ。知性とは何か、知性をどうやって判断するか、だけでSFのネタになるし、現実の世界の話になっているし。



 Steam:ISS Simulator

 Ver1.3.0版公開。ライティングの調整、操作モードの追加、現在地(モジュール名)の表示、負荷軽減、バグ修正、パフォーマンス改善、だそう。

 試しに遊んでみたけど、前より重くなってる気がする。RTX3060でFHDだとLow設定じゃないと満足に動作しない。

 操作モードは「プロモード」が追加。視点操作のヨーイングがローリングに変わる。えーっと、ヨーはどこにやったの??? 宇宙ステーションって基本的に上下方向が厳密に定められているから、上下方向は固定のほうが「現実的」な気がする。サイエンスフィクション的な宇宙観でいうとプロモードのほうが近いかもしれないけど、あくまでもフィクション。

 謎な制御則や物理法則が現実と異なる点も相変わらず。

 特に評価するような内容は無いかな。


***


 24日に飛んでいた機体

 かすかに聞こえた音の感じからして双発以上のターボプロップっぽい気がする。

 Fr24機影なし、M-S無し。4種類のコードを送信(同一機と考えて振幅やドップラに矛盾なし)。M-Cに矛盾しない応答が一つ、M-1に矛盾しない応答が一つ。

 M-1らしい応答は明らかに数が少ない。質問自体が少ないんだろう(4倍や整数比から明らかにズレているのは謎い)。もう一つも応答数が少ないやつがあるから、これがM-2かな? 残りの応答が多いやつは民間空港のレーダからも質問されているM-3/A,Cだと思う。


*


 旭川空港が除雪か何かで閉鎖していたらしく、2機が1時間近く上空待機していた

 通常は右端(これは離陸機だけど)みたいにすぐに受信範囲からいなくなるけど、上空待機中はオーバルパターンで飛んでいるので連続的または間欠的に長時間受信できる。


***


 マブチ130をガルバノスキャナ的に使うやつ


 上画像が中立位置、0.3A程度まで不感帯、0.1V1A(0.1W)くらいを突っ込むと下画像くらいまで振れる。

 スプリングでセンターリターンするので、適当な電流で角度を指示できる。はず。大電力というほどではないにしても、そこそこ大きめの電流を制御しなきゃいけないけど。

 ヒス特性やLPF特性がかなり強そう。広帯域で使おうとするとパラメータ同定をしっかりやって適切なフィルタを通さないと厳しいかも。

 中央の不感帯が嫌な場合は片側だけ使えばいい。レンジが狭くなるけど、それほど広いレンジが必要ということもないだろうし。片側に振るだけなら両極性が不要だからHブリッジは不要でドライバ段も楽になるし。ただし双方向に電力を突っ込める場合、適当なフィルタを使えば逆方向に引っ張ることができる利点がある。


***


https://www.jstage.jst.go.jp/article/itej1978/41/2/41_2_130/_pdf

 1986年。テレビ放送にFAXを乗せる提案。

 FAX専用の副音声チャンネルを追加して両立性を図る。150秒(2.5分)を1フレームとして、1日を576分割し、1フレームでA4用紙1枚分を伝送できる。Y信号とC信号を映像ラインに同期して交互に(CはCBとCRを2倍速で1行で)送る。NTSCとある程度の互換性があるので、CRTに表示して確認したり、あるいはFAXとして印刷して保存したり、色々な使い方が想定できる。今のところ、既存の受像機とは両立性が悪い(副音声放送時にノイズを与える)が、対策方法はわかっているので今後のテレビで対応が進めば実用化が期待できる。

 郵政省と、現在のTBS系の会社で開発していたらしい。NHKではないけどテレビ放送の分野だからか、制御信号のデジタルデータの誤り訂正には短縮化差集合巡回符号を使っているらしい。

 例えば天気予報の番組で同時にFAXで天気図を放送してハードコピーを配布するみたいな用途で使えれば便利そうな気がするな。あるいは料理番組でレシピを放送するとか。でもこういう方式が普及したという話は聞かないので、普及しなかったんだろうな。考え方はISDB-Tのデータ放送に引き継がれてはいるけど。



 前にISDB-Tを復調していたときは「なんか動いてるからいいや」で放置していた差集合巡回符号の誤り訂正の実装、改めて調べ直したり、AIに聞いてみたり。放送用途メインで色々な場所で使われている割に、詳しい解説がほとんど出てこない。ただ、AIに聞いてみると、数学的な噛み砕いた解説とかを出してくれるので、参考にはなる。理解できるわけではないけど。

 誤り訂正のパリティチェック位置は(x^n+1)/G(x)で得られる。のだが、なんか釈然としない途中経過が必要になる。並びを上下反転させないとうまく動かない。変調するとき(冗長ビットを作るとき)と復調するとき(誤りを探すとき)で、ビットオーダーを逆にしないと動かない。

 行き当たりばったりのコードで確認しているから、整理すればもっと綺麗になるのかもしれないけど。


***


 気まぐれに安いW5500モジュールを購入。試しに適当なレジスタを読んでみると、ちゃんとデータシートと矛盾しない結果が得られるので、少なくとも読むのは正しく動いているはず。無害そうな場所に書き込んでみると、それも反映されるので、書き込みも正しく動いているはず。ただ、一部の書き込み可能なレジスタは、書き込んでも反映されない場所がある。


 試しにCommon RegisterのHardware AddressとIP Addressを適当に設定して、Socket n RegisterのモードをUDPに、ポートを適当に設定して、開いて、PC側から適当なパケットを送ってみたら、RX Received Sizeが増えて、Socket n RX Bufferをダンプするとそれらしい値が入っていた(32Kメモリは起動時はゴミデータが入っているっぽい)。

 RX Bufferに入っているデータは8バイトのヘッダと受信したデータで、ヘッダの内訳はIPv4アドレスとポート番号、データサイズで、ヘッダや受信したデータ含め送った内容(PC側のIPアドレスやその時のポート番号)とも一致する。


 Socket n RegisterのDestination IP AddressやPortは書き込んでも反映されない。TCPモードに設定してOpen, Connectを叩くと、設定したアドレスやポートに接続されて、Socket n Registerを読むと設定したアドレスやポート、それにハードウェアアドレスも表示されるから、おそらくDestination系は書き込みレジスタと読み出しレジスタが別れていて、TCPで接続しないと読み出せないんだと思う。一旦アドレス等が読めた場合は、切断してもそのまま読める。

 TCPで接続した場合、TX Bufferに書き込んだデータがそのまま送信される。DISCで切断してもFIN_WAITから進まない。これはC#で書いたサーバー側処理の関係のような気もするけど。


 UDPで送る場合も、TCPと同じように、TX Bufferに送りたいデータを書いて、TX Write Pointerを更新して、Destination IP Address / Portを設定して、SENDコマンドを叩く。RXみたいに、パケットの中にIPアドレスやポートを指定する必要はないようだ。UDPを受信する場合は誰が送ってくるかわからないけど、送信する場合は特定の相手を指定して(or 指定しないことを指定して)送信するわけだから、あくまでも宛先はUDP/TCPにかかわらずDestinationで指定するようだ。


 データシートはあくまでも電気的特性やレジスタマップが書いてあるだけだから、実際にTCPやUDPを投げるときにはどういうふうに操作する必要があるか、みたいなことはあまり書かれていない。とはいえ、そう変なものでもなく、多少の電子工作知識があれば既存のライブラリ無しでもどうにでもなりそう。まあ、既存のライブラリを使うのが常道だろうけども。


*


 W5500でUDP(SENDコマンド)を送ったときの、CSとTX+の波形。PHYの設定で10BASEに固定している。

 CSが立ち上がるより6.9us程度前からすでにプリアンブルが出ている(多分問題ないだろうけど、念の為にプリアンブルよりあとのパケット部分は隠している)。

 その際のSPIの波形

 数usというのは特に意味はなさそう。単にコマンドレジスタへSENDが書き込まれたら直ちに処理を開始して、内部遅延分が見えている、という感じっぽい。W5500はCSを使わないコマンド体系もあるから、CSでバスを解放するとかには関係なく、単にコマンドが書かれたら直ちに実行するんだろう。

 何回かパケットを送っても、CS立ち上がりタイミングとEthernet波形が出るタイミングはかなり安定していて、1us未満程度のジッタしかない。SPIはソフトSPIを書いているし、CSも同様にソフトで処理しているから、Arduino側のジッタの影響もあると思う(16MHzクロックだと1マイクロ秒の間に16命令しか走らない)。

 おそらく受信割り込みもハードウェアのステートマシンで処理してるだろうから、かなりタイミング精度は高いはず。うまいこと制御できれば、NTP程度なら十分な精度は出るかもしれないな。


 10BASE-TとかのBASEって、ベースバンド信号の意味なんだな。マンチェスタ符号化しているだけで、だいぶシンプルな変調方式だ。目で見てデコードしようとは思わないけど、適当なスクリプトさえ書けば100Mspsとかで取った波形からパケットを復調するのは容易にできそうだ。


*


 W5500を始めとしてW5x00系のEthernetチップは色々な使用例があって、例えばArduinoの標準ライブラリにも入っているし、ググればそれを使うための情報も多いんだろうけど、今回は試しに最低限の情報(主にデータシート)を参照して叩いている。これといってネットワーク化したいアイテムがあるわけでもないので、気分転換に叩いて遊んでいるという感じ。

 最近はPCで走るプログラムばっかり書いてて、PCの外で動くプログラムを書くのもかなり久しぶりだ。といっても、Arduino Nano EveryでUART-SPI変換をやって、結局C#でW5500を叩いているんだけど。テスト用のパケットとかもC#で作ってるしな。


 W5200にSTM32F1を重ねてパッケージングしたW7200という製品もあったらしい。DigiKeyには無いし、Mouserではディスコンで販売終了している。ストリナにはまだ在庫があるけど、評価ボードの在庫は無し。WIZnetのWebサイトでもW7200の情報は皆無で、ぐぐると忘れられたようにPDFのデータシートが出てくるだけ。そもそもW5200の製品情報自体が消えている。

 ぐぐってもあまり情報が出てこないので、だいぶニッチな製品だったんだろうな。もうちょっと時代が後だとSTM32F1にArduinoをポーティングして使う遊びが流行ってたから、ワンチップでArduinoが走って、パルストランスだけでEthernetに直結できるミニボードは面白がられたかもしれないけど。


0 件のコメント:

コメントを投稿