小ネタ

　浜岡原発審査で過小評価疑い “データのねつ造 極めて重大” | NHKニュース | 静岡県、原発、原子力規制委員会

　そもそもなんで規制する根拠となる資料を規制される側に作成させているんだよ、という運用の問題な気がするけどなぁ。誰が好き好んで自分の首を絞める作業を馬鹿正直に行うんだよ。そういう問題が起きないようにするために、独立性を高めることを目的に作ったのが規制委員会だろ。せめて規制するための資料くらい自分で作れよ。まあ、規制するための数値を規制庁が用意しても、それに耐えられるという根拠を改ざんされたら意味ないじゃねーか、という話ではあるけど。

　経産省 浜岡原発の契約変更問題 中部電力に追加報告求める | NHKニュース | 原発、経済産業省

　別の問題も出てくると、体質の問題な感じもしてくるけど。あるいは長期間運転を止めているせいで緊張感が失われているみたいなこともあるのかもしれないけど。

　IT開発者向けの質疑応答（QA）サイト「Stack Overflow」で投稿数が激減、ユーザー戦慄 - やじうまの杜 - 窓の杜

　なんとなく個人的に感じている「昔のOSSって謎の活力があったよね」くらいの時期と相関していそうな気もするけど、でも2023年辺りまでは結構アクティブだからあんまり関係ないか。

　Shrike-lite: 開発ツール・ボード 秋月電子通商-電子部品・ネット通販

　ForgeFPGAとRP2040を載せたボード。

　オープンソースでGitHubに色々資料あるから参照してね、という方針。逆に言えば、まとまった資料が存在しない。LiteではないやつはRP2350が乗っているらしい。

　FPGAとRPは、RP側から転送するためのSPI接続等がある程度で、基本的には全部ピンに引き出して必要に応じて外部で接続する形かな。まあ、そのほうが使いやすいしな。

https://strawberry-linux.com/pub/ft232hx-v2-an001.pdf

　ストリナさん、手ハンダのクオリティがｹﾞﾌﾝｹﾞﾌﾝ

　自分は基本的に共晶ハンダしか使ったことがないので、無鉛ハンダだときれいにつかないとかあるのかもしれないけど。

　半導体ウエハの見た目をしたウエハース(お菓子)って作れないものかな。8インチとか12インチとかちょっと大きめの円盤状の形で、表面に多少の模様をレーザー等で焼き込んだりして。必要に応じてカット(ダイシング)して提供してもいいし、丸いまま売ってもいいし。あるいはダイシングしたものをクリームで重ねてチップレットにしてもいいし。模様もレーザーで後から焼くだけじゃなくて、光ディスクみたいに焼いてもいいし。さすがにウエハース程度の引張強度だとあまり細かい模様は無理かもしれないけど。

　千歳あたりのお菓子屋さんで道産食材を使ったウエハースでそういうやつを作ってラピダスの話題に便乗して売ったら面白そうだけどな。

　ウエハースのレシピってググってもほとんど出てこない。IPコラボで買った大量のウエハースを消費するためのアレンジレシピとかばっかり出てくる。均質な内部構造を考えると材料や加工法がそれほど複雑とも思えないが、どうなんだろうか。

　熱で溶かした砂糖をチョクラルスキー法で引き抜いたらどうなるんだろう? 巨大な単結晶の砂糖とか作れるんだろうか? さすがに8インチとか12インチとかの砂糖の結晶を作っても取り回しが大変そうだけど、ミニマルファブで使うような0.5インチだと細めの金太郎飴くらいの径。産総研のミニマルファブの展示でお土産として半導体風の模様の金太郎飴とか配布しても面白そう。あるいは単色の砂糖の棒を0.25mmくらい(実際のウェハー厚程度)にうまく切断して、レーザーで半導体みたいな模様を焼き込むとか。同じ程度の厚さというよりは、同じ程度の曲げ強度で切断するべきかもしれないけど。

　理研が富嶽そうめんとか売ってるし、産総研も負けずに半導体ウエハースとかを売ろうぜ。研究者カードを入れてさ。

　メーカーによるグラニュー糖の加熱特性の違い｜農畜産業振興機構

　いくつかのサンプルで融点を比較した結果とか。

　メーカーの違うグラニュー糖でカラメルソースを作るとかなり違うものが出来上がるらしい。微量な成分の差で大きな影響があるとかだいぶ半導体に近そうな感じがしてくるな。

　Google Pixelのカメラ、電源ボタン二度押しでカメラを起動して音量ボタンで静止画を撮影する機能、動画を撮影したいときに困ってたんだけど、音量ボタン長押しだと長押し中は録画されるんだな。長押し中に録画ボタンを左に移動して鍵アイコンに重ねるとボタンを離しても録画を継続して、録画ボタンをタップor音量ボタンで録画終了。タッチ操作ができない状況(厚手のタッチ非対応手袋を使っているとか)を考えると、物理ボタンだけでオルタネートに録画を開始できると便利なんだけど、ちょっと足りない。

　YouTube、デザインが変わってまた使いづらくなったな。

　YouTubeとかGoogleの機能やデザインの変更って「不便になった」と感じることは多いけど、「便利になった」と感じることってほとんど無い気がする。まあ、不便になったら目立つし、便利になっても無意識に使うだけだし、みたいなこともあるんだろうけど。

　それにしても、普通にスクロールやクリックができないUIって単純に不便だし、もっと言えばクソだろ。なんでそんなものがデプロイされるんだろう? Google系の会社、時々本当に変なことをやる。

　amazonみたいな大企業が作る防犯カメラみたいな製品にひどく反発しているレビュー系の仕事もやっている某有名企業、消費者のプライバシーを侵害して稼いでいるからみたいなのが理由らしいけど、彼らってどういう製品なら納得するんだろう。

　小さい会社が開発した製品ならいいの? そういう会社が開発したコネクティングデバイスが信頼できるとでも? セキュリティしかり、製品寿命しかり。あるいは小さな会社の製品がある程度普及したら簡単に買収されるリスクも有る。西側企業が買収するならともかく、家電企業が中国企業に買収されたりみたいなことも起きている昨今、下手に市場価値の低い会社が作る製品はそういう点でもリスクがあると思うが。AnkerやTP-LinkやiRobotの例もあるし。アメリカのビッグテックが消費者のプライバシーを侵害するのは許さないけど中国政府がアメリカ国民のプライバシーを侵害するのは問題ない、とでも思ってるの?

***

　ジャイロスコープのプリセッション、力学的に正しいかは別にして、感覚的に理解しやすいのは、人工衛星の軌道で考えてみることだと思う。

　人工衛星が円軌道を回っているときに、軌道面に対して垂直に力を加えると、垂直な方向の運動エネルギーが増える。元々持っていた運動エネルギーとベクトルが合成されるので、斜めの速度になる。あとはそのベクトルを面内に持つ軌道面を回転する。これだけ。

　これを十分に弱い力かつ長い周期で考えたときに、この人工衛星が例えば適当な間隔(10mとか)で大量に並んでいても、同じ動きをする。それらを紐でゆるくつなげても同じ動きをする。同様に、棒で比較的固くつなげても同じ動きをする。剛体(自転車の車輪とか)で考えた場合は、1周期未満の短い時間で力が加えられる前の箇所にもプリセッションが伝播する点が大きく異なる。

　大雑把にはそういう感じに見ておけばいい気がする。ただ、この方法でイメージするためには、人工衛星の軌道をある程度正しく認識しておく必要はあるので、例えば小学生にこのイメージを説明すれば全員が理解できるというようなものではないけれども。

　もう少し身近なもので近似したいなら、重りを付けた紐を振り回してもいい。ただし地球の重力は無視するものとする。

　質点に与えた力は時間積分して垂直方向の速度になるが、その力を受けた結果は元々持っていた運動エネルギー(接線速度)との合成だから、接線速度に対して垂直速度が小さければ角度の変化は小さくなる。接線速度が大きければベクトルの角度は小さくなるし、接線速度が小さければ角度は大きくなる。ジャイロ剛性はこれでおおよそイメージできる。もちろん、接線速度がゼロなら垂直に与えられた速度がそのまま出てくるから、歳差運動は発生しなくなる。どれほど小さくても接線速度がゼロでないなら、歳差運動が発生する。

***

　LAN内機器での時間同期の標準規格「PTPv1」こと「IEEE 1588-2002」【ネット新技術】 - INTERNET Watch

　累積誤差を排除した2代目PTP「IEEE 1588-2008」、LAN内機器での時間同期の精度を向上【ネット新技術】 - INTERNET Watch

　PTPv2の成功を受けて登場した「IEEE 1588-2019」は、広範な利用のためのオプションを追加した「PTPv2.1」【ネット新技術】 - INTERNET Watch

　PTPってちゃんと調べたことなかったけど、わりと簡単っぽい感じだな。UDPのパケットを投げるので、基本はNTPとほぼ同じ。

　NTPはクライアントから始めて1往復のやり取りを行う。パケットの中に送受信時刻を含めるが、送信時刻は送信する予定の時刻を入れてあるに過ぎないから、キューに積まれたりすると実際の時刻とずれることがある。

　PTPはサーバーから定期的に2つのパケットをブロードキャストする。2つ目のパケットには1つ目のパケットを送信した実際の時刻が記録される。クライアントは1つ目のパケットを受信した時刻を記録しておき、2つ目のパケットで時刻を決める。ただしこの1つ目の時刻には伝搬遅延分の遅れがある。

　正確な時間が必要になると、クライアントはサーバーに向けてパケットを送信する。クライアントはこれの送信時刻(含1way遅延)を記録しておく。サーバー側はそれを受信した時刻を記録し、これをクライアントへ返信する。クライアントが送った時刻とサーバーが受信した時刻を比較すると2way相当の伝搬遅延が得られるから、これを差っ引けば、サーバーとクライアントで時刻同期ができる。

　これがPTPv1の仕組み。

　PTPではパケットのどの部分を時刻の基準に使うかも定められているので、これと時刻を結合するために、PTP対応のハードウェアが必要になる。時刻の基準はあくまでもMAC層のパケットの頭が基準になるので、PTPに依存したものではないから、他にも汎用的に使える時刻基準ではあるから、汎用的に使える時刻基準としてPHYで対応して、それを流用してPTPにも使う、みたいなことは可能だろうけど。

　ただ、PTPv1ではブロードキャストのパケットにはPTPサーバーを選択するための情報(精度や確度など)を含めている関係で、パケットが大きくなり、これで輻輳が発生することで信頼性が低下する問題があった。そのため、PTPv2ではブロードキャストパケットを小さくすることで高頻度に放送できるようにした。これがv1とv2の互換性がない所以。

　v2.1ではCERNで得られた知見に基づいて精度改善を行ったり、曖昧さを除去する改定が行われた(その他色々なオプションの追加も)。例えばスイッチやルーターを通過する際に増える遅延(特に遅延に方向性がある場合)に対する改善など。PTPv2.1を使うためには対応したスイッチ/ルーターを使う必要がある。

　以上がPTPの簡単な仕組みだけど、この理解が正しいのかは不明。PTPの仕様はIEEEが決定・販売を行っているので、非会員が正規に買おうとすると250USD程度の値段になる。

　結局、規格が普及するかどうかは無料公開か有料公開かに関係なく、需要があるタイミングでタイムリーに規格を提案できるかどうかなんだろうな。よほど高価なプロプライエタリとかならともかくとして、200ドル程度でドキュメントが買えるならな。趣味で遊ぼうとかすると困るけども。

　PTPの要点はハードウェアでパケットの時刻決定ができる点と、パケットの送信時刻を別のパケットで送る点なので、やろうと思えばNTPの拡張でも対応できたような気がする。物理層の時刻決定は追加で必要として、残りはNTPのパケットだけでどうにでもできそう。ブロードキャストとか追加領域とか、一通り必要な機能はNTPにもあるし、124番ポートは特に使われていないようだから、これを追加でNTPに割り当ててもいいだろうし。

　例えばクライアントは124番を開いて、サーバーは124番に対してブロードキャストを行って、それを受信したクライアントは123番宛に追加でパケットを送って、従来のNTPは123番でそのまま使って、みたいな感じとか。

　PTP、わざわざ新しい規格を作るほどかなぁ、という気はする。下手に拡張するより作り直したほうがわかりやすいだろ、ってことかもしれないけど。

　PTPは100万分の1秒の精度がある、とかいったって、NTPだってパケットのフォーマット自体は数百ピコ秒程度の時間分解能があるわけだから、確度を改善すればいくらでも改善できるだろうし。

　ただ、上記の記事はあくまでもNTPに一番近い形態を解説しているだけであって、実際のPTPはもっと色々な設定が可能なので、柔軟に使おうとするとやはりNTPの発展では難しくて、PTPが必要だったんだろうな。

　PTPはイーサネットフレームのヘッダ開始点を基準に時刻を決めるので、自然にイーサネット内でしか使用できない。まあ、べつにルーターやWiFiを超えさせてもPTPパケットとしては問題ないはずだが、その間の遅延を確定(高精度に推定)できないので、PTPとしての精度は得られない。なので、パブリックPTPサーバーみたいなものも基本的には存在しない。

　将来的に広域通信網全体にPTP対応機器(ユーザーが見えないところはTCで、末端付近はBCで、とか)が配置されたらどうなるかはわからないけど。GNSSみたいにジャミング・スプーフィングのしやすい時刻でなく、有線で高い精度の時刻を配布できるPTPが普及すれば欲しい用途はあるだろうし。

　しかし、PTPは高頻度でパケットをブロードキャストしなきゃいけないから、広域に使うのは難しそうな気がする。BCとP2Pで通信するならNTPみたいにクライアントドリブンで使えるのかもしれないけど。/* PTPとP2Pの紛らわしさよ。。。 */

　PTPとしては、高い時刻確度が必要な場合はGNSS等で、そうでなく、あくまでもLANの中(例えばファクトリーオートメーションやテレビスタジオ)で機器間の同期を取りたい場合は絶対的なUTCとの同期は必要ないから、そういう場合はNTPで外部と同期すればいいらしい。

　もう少し厳密に言うと、PTPはUTC系ではなくTAI系+Leap情報を採用しているらしい。ので、GPS系とは相性が良さそうだし、閏秒を透過的に拡散する最近の公開NTPサーバーと組み合わせると問題が起きそう。特にホールドオーバー用に高精度なクロックをローカルにおいている場合。まあ、それくらい考えてるシステムならNTPサーバーの実装(LIを正しく返すかどうか)くらいは確認して使うだろうけど。あるいは、GNSSとかを使わない系ならむしろ閏秒は拡散してくれる方がありがたいって場合もあるのかもしれないけど。

　White Rabbit Project - Wikipedia

　CERNのPTP実装。白兎は『不思議の国のアリス』から。

　最長10kmの銅or光ケーブルを使ってナノ秒未満の精度が得られるらしい。

　1000BASE-Tなら125Msy/s、10GBASE-Tなら0.8Gsy/s程度だから、その逆数で8ns、1.25ns、クロックの真ん中でサンプリングするならその半分程度、PTPv2以降は数十～100Hz程度で同期信号を打つから平均化して数倍程度、と考えると、数ナノ秒からサブナノ秒くらいは行けそうではあるが、それにしても。

　確度で見ればGPSコモンビューと同程度で、線を引き回さなきゃいけない分導入コストが高いし距離とコストが比例するけど、外部からの攻撃が難しいとか外部システムに依存しないみたいな利点はありそう。あとは、Gbpsオーダーのデータを流すのにも使える。基本的にGPSはデータリンクには使えないからな。

　有線(ファイバーとか)に対してスプーフィングを仕掛ける難易度ってどれくらいあるんだろうか。十分に情報的なセキュリティを確保したネットワークに対しては、少なくともケーブルに物理的にアクセスする必要があるから、周囲の物理的なセキュリティ確保である程度は対策できるか。GPSならある程度離れた場所からでも受信アンテナに向けてうまい感じに電波を突っ込むだけでも偽装(あるいは妨害)できる可能性がある。物理的に接触する必要があるケーブルなら、建物の耐タンパー性で少なくとも偽装・妨害を試みた段階(物理的にネットワークへ触れる少し前)で検出できる。GPSだって信号自体の認証とかビームフォーミングでどうにかしようという話もあるけど、ビームフォーミングするとまたそれで時刻確度が悪化するとかもありそうだしな。ネットワークも完全に独立したシステムを作るのも難しいだろうし、電子的に外部から入ってどうにかしたりみたいなことも考えられない訳では無いにしても。

　電力保安用IPネットワークにおける高精度時刻同期方式の適用検討－PTP同期の精度評価とIP機器の同期機能割当て－ 報告書 詳細情報　| 電力中央研究所

　ガチの研究所が自分たちの必要な精度(1us)を得られるかどうかを色々な条件で比較した結果。ネットワーク系の会社が技術ブログで概要を説明しているのとは異なって、かなり細かいところまで説明している。

　商用電源なんて50/60Hzだから対してタイミング確度あんまりいらんやろ、とか思ってたけど、60Hzを1度単位でサンプリングしようとすると45us程度になるし、マージンを考えると5us程度は必要になるのか。

　そういえばSTM32 Nucle-144でEthernetポートが乗ってるやつあるけど、あれどういうふうに使えるんだろ、と思って軽く検索。STM32自体はRMIIでインターフェースして、PHYはMicrochipのLAN8742Aが乗っているらしい。

　PHYのデータシートを見た感じ、割り込みに設定できるのはWoLとかA/Nとか、いかにもPHYが触りそうな部分だけで、イーサネットフレームの送信とか受信に関連しそうなものは見当たらない。

　そもそもPHYって電線から出てくる電圧レベルをデジタルデータに変換するまでが担当で、フレームを処理したりはもう一つ上の層(MAC?)でやるのかな。その割にWoLはPHYで検出できるから、少なくともWoLが入っているフレームを検出できる程度の機能はあるんだろうけど。

　STM32H7のEthernetはPTPにも対応しているらしい。PTPだけでかなりのページ数を割いて説明している。例によってパケットの内容とかの説明はないけど。

　PTPはMAC層で処理するから、EthernetのクロックとMIIのクロックの差とかもジッターに出てきそうだ。PHYでPTPを処理できれば一番いいんだろうけど、WoLみたいにシンプルなフレームと違って、もう少し上のレベルで動いているから、PHYで処理するのは難しそう。結局MACで処理するのが楽なんだろうな。それにしても、プリアンブルの末端(ヘッダの頭)で割り込みピンを駆動するくらいの機能はPHYにあっても良さそうな気もするけど。

　アメリカのエンティティリストに乗っている某社のドキュメントにPTPの詳しい説明が書いてある。パケットの内容とかも書いてあるので、とりあえず試しに投げてWiresharkで見たり程度はできそう。

　そもそもPTPの内容って有料販売だから気軽に無料公開しちゃだめだと思うんだけどな。グローバルに普及した一般公開されていない(有料販売されている)仕様書の類、このあたりの企業から無料で公開されがち。そういう信頼の置けない商売をやっているから西側から嫌われるんじゃないのか。まあ、ググれば他にもいくつかの企業(機微な製品を扱っているアメリカ企業を含む)が公開している情報にもパケット構造が断片的に書いてあったりするから、そこまで厳しく秘密にしているものでもないんだろうけど(それこそ現物があればWiresharkとかで見ればわかるわけだし)。

　PTPは仕様が無料公開されてないので自分で作ろうとすると大変そうな気がする。WiresharkはPTPv2に対応しているらしいので、適当なパケットを投げてみて試すという手はあるけど。あるいは、CERNのWhite Rabbitが「完全にオープンソース」だそうだから、それを追うという手もあるか。うさぎの巣穴へ真っ逆さま。

***

　W5500でポート9にUDPを投げて、オシロをSEND_OKの割り込みでトリガ

　↑PCに4バイト投げたとき

　↓ルーターに128バイト投げたとき

　10MbpsHD、黄色(ch1)がW5500から見たTX+、紫(ch2)がW5500から見たRX+。UDPを出す前にARPでアドレス解決をしているっぽい?

　ルーターからはなぜかエコーバック的なものが帰っている。ただ、W5500はこれを受信してもパケットが届いたとは認識していない(Socket.Int.RECVが立たず、Socket.RxReceivedSizeもゼロのまま)。PCから投げても応答を受信できないから、なんか変なパケットになっているんだと思う。波形を解析すればイーサフレームからパケットの内容を復元できるだろうけど、流石に面倒。。。

　SEND_OKのトリガは、実際には送信が終わる前に出ているらしい。メッセージが衝突したりした場合はどうなるんだろうか。トリガとプリアンブルのタイミングはかなり精密で、数回見た程度だと100ナノ秒未満のジッタ程度に見える。

　PCから同一のUDPパケットを4回送信してRecvで割り込み

　当然だが、パケットを受け取ったあとにRecv割り込みがかかる。2usくらいジッターがあるかな、という感じがする。やはりというか、送信よりも受信のほうが精度が出ない。そもそもW5500の割り込みってタイミングスペックあるのか知らないけど。

　パケットを長くするとフレーム末から割り込みまでの時間も伸びる。おそらくCRCの計算が10Mbpsより遅いんだろう(あるいは受信が終わってから計算しているのか)。受信した長さはRX Bufferを読めばわかるから、Recv割り込みからフレーム先頭の位置までの時間は計算である程度推定できるはずなんだけど、どの程度確実に決められるかは不明。

　W5500の送信割り込みジッタが0.1us、受信割り込みジッタが3usと仮定すると、多少余裕を見てトータルで5us程度になる(受信パケット長から十分な精度でパルス位置を推定できる場合)。NTPは送信時刻を決めるのが難しいけど、PTPのFollow_Upで投げるなら、W5500でPTPサーバ/クライアントを作れば、10us未満程度の同期精度が得られるはず(確度はまた別の問題)。PTPの理想的な状況と比べると4桁くらい悪いけど、ソフト実装のNTPに比べれば2,3桁くらい改善できるはず。そう考えるとNTPとPTPで6-8桁くらい違うのもすごいけど。

　ちなみに、W5500を100BASE-Tに設定すると常にビット列(100BASEのアイドル信号)が出続ける

　だいぶ波形がなまっている。オシロは200MHzだけど、プローブは100MHzなので、125Msy/sを見るのは厳しそう。でも頑張ってクロック同期すればデコードできないことは無さそうかな?

　100BASE-Tのバストリガに対応していないオシロで100BASE-T信号を見るとこれが常に流れるので、イーサネットフレームを狙ってキャプチャするのは難しい(W5500ならSEND_OK/RECVで割り込みをかけてこれをトリガすれば少なくともその付近にフレームがあるはずだが)。

　こういう遊びをしているとアナログ6+デジタル16くらいのオシロが欲しくなる。TekのMOS5みたいに、アナログ1ch or デジタル8chを8系統好きに組めるMSO5は便利そうだなぁ。なお値段。

　横河のやつだと12bit8ch+1bit32chみたいなモデルもある(MSO5換算12ch)。ベース価格で比べればTekの半分くらいの値段だし。まあ、それでも高級な軽自動車が新車で買えるくらいの値段になるらしいけど。横河の一部の機器にはIEEE 1588 PTPサーバー機能が乗っているらしい(クライアントは結構多い機種で対応)。カタログによると「誤差1us以下の高精度なクロック同期を実現」だそうだ。横河の計器は同一機器を接続してch数を倍増する機能があるけど、PTPで同期すれば異なる機種間でも時刻同期ができるらしい。トリガ信号を接続すればサンプリング時刻は同期できるけど、PTPなら非同期的な信号も含めて、柔軟に時刻同期できるだろうしな。

　Sigだとアナログ8ch+デジタル16chで100万円台から300万円弱まで(帯域幅による)。RIGOLもほぼ同じ価格帯かな。SigやRIGOLはいくら最近は良くなってきたとはいえ所詮は中国の安物計器メーカーから始まっているし、ブランド物には使いやすさとかの点ではまだまだ勝てなさそうな気がする。まあ、LeCroyあたりでSigのリバッジを売ってるのを見ると、ブランド品だって安物はクソみたいな品質なんだろうけど。

　LeCのカタログ、「アナログ8チャンネルとデジタル16チャンネルは常に利用可能です。他社の機器のように、デジタルチャンネルを利用する際に、アナログチャンネルを犠牲にすることはありません。テレダイン・レクロイなら、常に全チャンネルが利用できます」とか書いてあってすごい(横河のオシロでもアナログchをデジタルとして使うみたいな製品もあるし)。

*

　10BASE-Tの波形データをExcelに取り込んでみた

　縦軸は任意の単位(8bitADC直読み)、横軸はマイクロ秒。700kptsが2chなのでかなり重い。

　Excelで横幅が広い散布図を書くと補助目盛線の位置がずれる不具合、普通に迷惑なので早く直してほしいなぁ。。。

　.NET FWのChartでグラフ化

　.NET Framework久しぶりに触った。昔のC#って不自由だったんだなぁ。全然好きに書けない。それでもLangVersionで13.0とか指定すればかなり自由にはなるけど。

　2個目の送信を適当にマンチェスタ復号して手動デコード

　クリアビットと思われるエッジは青色の、セットビットと思われるエッジは赤色の点を打っている。また、それらを8個合わせて16進の値も合わせて表示した。復調にはクロックリカバリが必要かなと思っていたけど、クロックリカバリなしでもおおむね問題ない感じで復調できた。クリアビットが明らかに上に寄っているけど、プリアンブルの一番最初のエッジから50%後ろをサンプリングポイントとして採用しているだけなので、その分のズレだと思う(セット/クリア判定はサンプリングポイントから適当に±数サンプルずらした2箇所の高さを比較)。パケット長が60usで1シンボルが0.05usだからタイミングはそこまで厳しくないらしい。

　マンチェスタ符号のクロックリカバリってどうやればいいんだろう? エッジの位置を探すにしても、エッジが鈍っていたらどこを採用すればいいんだろうか。AC結合するにしても、ビットパターンによってはDCオフセットがあると思うんだけど。

　ビットの意味についてはWikipediaを見ながら復調してみたけど、とりあえず妥当な結果が得られていると考えられる。送信先ポートが0で送信元が9だけど、これは単にW5500の設定をミスっているだけ。16進の列もオンラインのCRC32計算機に突っ込んでみたら正しい結果が得られたから、少なくとも明確なビットエラーは無いはず。

　10BASE-Tは安いオシロでも十分に見えるシンボルレートだし、マンチェスタ符号だから見たとおりに復調できるし、楽でいいな。

　FCSの末尾は中途半端な電圧が出ているけど、これは単にマンチェスタ符号の振幅レベルが見えてるっぽい。実データの振幅が高いのはおそらくLANケーブルを伝搬したことで発生したオーバーシュートだろう。FCSの末尾ではマンチェスタ符号として不正なDCを出すことで明確に末端を示しているんだと思う。

　本来はARP(推定)や謎のエコーバックも復調したかったんだけど、思った以上に面倒なので省略。ただ解析するだけなら大した手間でもないんだけど、図示しようとするととても面倒。ChartなんでFW以外で使えないんだよ。。。

*

　ためしにW5500を操作するGUIを試作

　いろいろ設定できる場所とか見れるものが多いので、1画面に全部並べるとFHDでは収まりきらない。

　手動でパケットを投げたり読んだりもできるけど、とりあえずDNSだけ作ってみた。結構大変だった。主に普通のリソース管理で。SPIバスは1本しかないし、ソケットは同時に8本しか開けないから、それらをうまいこと管理する必要がある。

　結局、FT232H/W5500を使っていても、うまい感じに隠蔽すればC#のTcpClientやUdpClientと同じように使えるし、それこそSend/Receiveを作れば全く同じように使えるから、C#側でTcp/Udpを使うコードを書いてそのまま流用したりもできる。

　W5500のCommon Register 0x0017 Socket Interrupt Register、各ソケットから割り込み要求があるとそのビットがセットされるレジスタだけど、データシート上は書き込み可能(R/W)になっているのが謎い。0や0xFFを書いても何の効果もないし、もちろんセットビットに相当するソケットの割り込み要求がクリアされる、なんて機能も無い。

***

　そういえば、SpaceWireって情報がないときでもクロックが出続けているはずだけど、これでクロックを配布しようみたいな使い方ってないんだろうか? 全部の機器はルータで接続されているわけだし、ルータもクロックリカバリして他のポートにクロックを配布できるだろうし、すべての機器がコヒーレントに動いていれば、クロックを積分すれば時刻が得られるから、機器間の時刻同期も楽になるだろうし。

　ビットレートを切り替える際とかは困るだろうけど、宇宙用コンポーネントなんてルーティングも全部冗長化してるんだから、片方ずつ切り替えて常にコヒーレント(片系統が死んだら非コヒーレントで時刻決め)みたいな運用もできるだろうし。

　そこまでして精密にクロック(積分して時刻)を配布したい需要があるかどうかはともかく。SpaceWireだって時刻配布プロトコルはあるわけだから、大抵の需要はそれで十分だろうしな。