何日か前に届いた、ほぼ確実に迷惑メールであろう、プロバイダからの案内のメール、送信者がプロバイダの一般的なメール(実際のログイン通知とか)と同じなのは当然として、Gmailで見ると送信元や署名元も実際のメールと同じで、かつGmailが重要と判断したマークを付けている。ただし、通常のメールは送信先メールアドレスが自分のメールアドレスだが、このメールは正しくないアドレスになっている。それと、ログインして設定しろとURLが貼ってあるが、このURLはプロバイダのドメインではない(プロバイダから送られてくるメールはもちろんプロバイダのドメインのURLが貼られている)。
送信元と署名元が実際のプロバイダと同じに見えるものが付属しているのも変だけど、それでころっと騙されるGoogleもGoogleよな。
別の迷惑メール、普段迷惑メールなんて送信者名だけ見て関係のない会社(普段から迷惑メールで使われている社名)なら件名すら見ずに読み捨てるんだけど、たまたま目に止まった内容が面白かった。本文のフッターには社名や会社のWebサイトへのリンクが書いてあるんだけど、Example Companyという会社でURLはexample.comだそう。ちょっと面白い。
迷惑メール用のサンプルデータをほとんど書き換えずにそのまま流用したのかな? メール本文の中に別のドメインのURLが書いてあるから、これが本体なんだろうけど。しかし、example companyとか書いてあるのも気にせず送るようなヤツが迷惑メール出してるのかぁ。そりゃまあ、一流企業の英語バリバリシゴデキ人間が業務or副業で出してるだけとも思わないけどさ。
「DXセミナーの案内がFAXで送られてきてガッカリ」みたいな話、むしろそれって正しいやり方なんじゃね?って気がするけどな。デジタルツールを使い込んでいる所にDXソリューションを売り込んだって意味ないだろうし、電話やFAXを現役で大規模に使っている組織こそDXするべきだろうし。適当なデータセットに乗ってるFAXの電話番号に一括して送信しているだけだろうし、大量の電話番号からその組織が十分にデジタルツールを使いこなしていて売り込む必要が無いと除外するのも面倒だろうし。
主に人生の諸先輩方へ向けて作られているスマートフォン、UIが独特で使い方を聞かれても答えられないとか色々不満点はあるんだけど、タップ操作が感圧式になっているのはすごい羨ましい。
PCのマウス操作みたいにクリック操作が明示的なHIDに慣れていると、普通のタッチ操作(含一般的なノートPCのトラックパッド)で「いや俺触ってねえんだけど!?」は結構フラストレーションになる。Mac系のトラックパッドはクリックが感圧なので、その誤入力が無い。スマホにもそういう機能が欲しい。
一時期のiPhoneも感圧式のタッチパネルだったはずだけど、すぐに廃止された気がする。やはりタクタイルスイッチで計測できるトラックパッドと違って、スマホのタッチパネルで機械的なアナログ値を安定して取るのは難しいんだろうな。逆に言えば、意地でもその機能を削らない日本の端末メーカーの気力というか(今はレノボ傘下だから親企業は中国だけど)。キャリアやユーザーからの圧力もあるんだろうけど。
文章を読みながら手持ち無沙汰でキートップを撫でながら思ったけど、FキーやJキーあたりに画像素子を埋め込んで、指紋認証やポインタ操作デバイスとして使うことってできないんだろうか。
面積が小さいからポインタとしての操作範囲(ダイナミックレンジ)は狭いけど、ちょっとした文章の入力中に、数文字分離れた場所にカーソルを移動したい、というときに、右手を大きく動かして矢印キーを使うよりも、JキーやFキーを撫でてマウスカーソルを少し動かすくらいの操作ができたら便利そうだが。
とはいえ、マウスカーソルの移動はできても、クリック操作をどこに割り当てるんだ問題が出てくるのだが。スペースバーの手前にボタンを追加する、あたりかなぁ。
単にカーソルを動かしたい場合はViみたいな操作系は便利そう。今度はEscが遠いけど。
ターボファンエンジンの発電能力増強のために高圧軸だけでなく低圧軸にも発電機を取り付ける、というやつ、実際のところどれくらい効果があるんだろう? 低圧軸は高圧軸で余ったエネルギーでブン回してるだけだから、高圧軸で発電しても、高/低圧軸の両方で発電しても、トータルで取り出せるエネルギーに差はない気がするんだけど。
高圧軸の発電機が大きくなるとイナーシャも大きくなるから起動が大変……みたいな話は、そもそもその発電機に電力を突っ込んで回すんだから大して問題ないだろ、という気がするし。
構造的に、高圧軸に大容量の発電機を取り付けるのが難しいから、比較的小型の発電機を2箇所に設置する、みたいな理由はありそうだけど。あとは、熱い場所に高効率な発電機を置くのは大変だから、メインは低圧軸で、でも起動用の電動機が必要だからついでに高圧部でも発電して、みたいなこともあるんだろうか。
昆虫に過給器をつけたらどうなるんだろ、という空想。昆虫を巨大化させた設定がある創作物で、でも昆虫って巨大化すると呼吸できなくなりますよねー?みたいなツッコミに対して、サイバーパンク的な方向からのソリューション。エネルギーは外付けのLIBで、BLDCでブン回す方向で考えている。電池が切れたら(orリモートで停止させたりすれば)活動を止められるという利点もあるディストピア風味の味付け。
気まぐれに読んでた中性子イメージングの資料で「核分裂で生じる高速中性子は使いづらいから水で冷やして使う」みたいなことが書いてあった。確かに水で減速する核分裂炉って、我々が日常的に「熱いものを水につけて冷やす」と全く同じ物理現象で高速中性子を冷やしてるんだよな。火で温めた石を水につけてお湯を作るのと同じ(マクロスケールでは核子が運動量を直接交換しているわけではないけど)。石がめちゃくちゃミクロになるし、トータルのエネルギーは非常に大きいので、日常のスケールとは全く違ってイメージが湧かないけど。でも水は沸くんだよね(ただし沸騰水炉に限る)。
中性子イメージングの場合は水だけでなく液体水素を通して冷やしたりもするらしい。あまり冷やしすぎると波長が伸びて分解能が下がるんだろうけど、液体水素ならそこまで極端に冷えるわけでもなく、かといって早すぎもせず、値段も安いし、わりといい冷却剤なんだろうな。核分裂で生じた高速中性子や常温程度に近い熱中性子に対して、液体水素で冷やしたものは冷中性子というんだそうだ。熱中性子を通す場合、液体水素は厚さ3cm程度でいいらしい。極めて少量でも十分に冷却できるから、トリチウム化する量も少ないんだとか。たしかにあまり長く液体水素を通しているとそっちに吸収されてしまうのか。
http://www.spring8.or.jp/pdf/ja/SP8_news/no99_20/no99.pdf
2020年。Spring-8でトリウム229の励起に必要なエネルギーを計測したい、みたいな話。
トリウムの原子核は他の原子に比べて低いエネルギーで励起でき、原子核は電子雲よりも遥かに小さいし、電子雲がシールドの役目をしているので外部からの影響を受けづらいため、原子核を時計に使えば現在の原子時計よりもさらに精度の高いものが作れるはずだ、ということで、励起エネルギーの低いトリウム229で実験を行っているらしい。
トリウム229のトラップとかの話。
冷却用のレーザとかで、結構大規模な装置が必要そうな感じだ。もっとも、応用の話で「「原子核時計」というテーブルトップサイズの装置による宇宙進化の解明という、新しい研究分野を創成する可能性も秘めている」と書いてあるから、実用化の暁には十分に小型化できると考えているんだろうけど。
***
改めてRaspberry Pi Picoを触っている(比喩表現)。
なぜか、Ras Pi PicoのRUN端子に触れる(物理)とリセットされる不思議な現象が起きている。内蔵プルアップ抵抗って100kΩ未満だろうし、そんなに簡単に動くものでもないと思うんだけど。それに、4.7kΩを追加で付けても、やはり指で触れると反応する。
前に、BOOTSELを押してWDTを蹴ってUSB MSCで認識させるというやつ、あれ実は正常に動作していなかったらしい、という気がしてきた。
定期的にキャッシュをオールクリアしたり、あるいはQSPI FlashからUIDを読むようなコードを書いてBOOTSELを押しても、正しく動作を続ける。そもそもQSPI Flashはデバイスが1個しか接続されていない場合はCSをGNDに落としてピンを1本省略するみたいな使い方ができるらしい? 軽くググっただけだとそういう使い方は見当たらなかったけど、SPIだとそういう動作ができるデバイスもあるし、QSPIでできても良さそう。ということで、そもそもRP2040のBOOTSEL(QSPI Flash nCS)を動作中にGNDに落としても、SSIの読み出しには影響はないようだ。
BOOTSELでリセットしたい場合、自分でBOOTSELを読んでリセットするしかないらしい。その場合、BOOTSELをGPIOに変更する必要があるから、そのコードをRAMに置いたうえで、割り込みも停止して、とか、いろいろ手間がかかる。RP2040をリセットするのも、例えばCortex-M0+コアをリセットしても他のコアやペリフェラルは動作を続けるから、WDTを開始して待つ、みたいな方がいいらしい。QSPIがCSを使わないならGPIOに固定しても、キャッシュミスを含めて正常に動作するだろうけど、GPIOを読むときにBOOTSELの押下有無にかかわらずLOWでしか読めないし。
RP2040のXIPはプログラム側からXIPに書き込みを行うとキャッシュライン(2040なら8byte単位)を無効化して次の読み出し時に強制的にFlashから取らせる機能があるらしいんだけど、軽く試した感じではうまく機能させられなかった(キャッシュラインを削除してBOOTSELをオシロで覗いても、VDDに張り付いていてQSPIで読みに行っている気配がない)。SDKラッパーのxip_cache_invalidate_rangeを使っても同様。
結局、RasPiPicoを手軽に使いたいなら、2枚買ってJTAGアダプタとして使うのが一番確実っぽいなー。
Ras Pi Picoはドキュメント(SDKが用意している関数やその機能)がHTML1ページで説明してあったりして情報を探すのが便利ではあるけど、いまいち釈然としない部分も多い。
あと、当たり前だけど、STM32とはペリフェラル周りが全く違うので、自分がやりたいことをどうやったらできるのかを調べる必要もあるし。ある程度気合を入れて一気にいろいろ試していけば感覚も掴めるんだろうけど、そこまでのモチベも無いのでな…… STM32ならこの機能とこの機能を使えば楽に作れるんだけどなー、とか、いろいろ。
***
PCでデータが通るところ、ぐぐると必ずオーディオ系のブログが出てくる。オーディオの人たち、どこにでもいるな。懇切丁寧に解説しているけど、でもその説明って……
もちろん、データが通らない場所(e.g.純粋なパワーライン)も彼らの領分。
*
https://www.net.itc.nagoya-u.ac.jp/member/shimada/infoNW2025B/slide/lecture20250617slide_rev1.pdf
イーサネットの特に物理に近い周りの話いろいろ。
https://www.fujitsu.com/downloads/JP/archive/imgjp/jmag/vol55-6/paper07.pdf
2004年。1チップで10GbE12ポート240Gbpsのスイッチングハブ。25mの銅線をドライブできるIOを内蔵。
*
DHCP、Wikipediaを見ながらざっくり実装してみた程度なのであまり詳しくは調べていないけど、最低限の機能だけならそれほど難しいものではない。300バイトくらいのUDPパケット(互換性目的で200バイトくらいゼロ埋め)を2往復+αで処理できる。NTPの数倍の手間、といった程度。10倍まではいかないかな。
DHCPはMACアドレスと紐づけて処理される。ユニキャストで送ると送信したイーサネットフレームのMACアドレスに返答が帰るので、パケットでMACアドレスを偽装して実際には別のMACアドレスから送る場合は、ブロードキャストで送る必要がある。逆に言えば、実際にはネットワークに接続されていないデバイス(ネットワーク内に存在しないMACアドレス)に対してDHCPでIPアドレスを割り当てることもできる。
攻撃らしい攻撃も思いつかないけど、攻撃者となる一つのデバイス(単一のMACアドレス)からDHCPサーバーにリクエストを投げれば、DHCPリソースを枯渇させるのは簡単にできそう。すでに接続されている端末に割り当てられたIPアドレスを横取りすることはできないけど、追加で接続される端末へIPアドレスが割り当てられるのを防ぐことはできそう。それで具体的になにか強烈に悪用できるかというと微妙だけど、迷惑ではある。
DHCPサーバー側では、イーサフレームの送信者MACアドレスとDHCP DiscoverのMACアドレスが一致しないパケットは捨てる、みたいな方法で避けれるけど、少なくともうちのルーター内蔵のDHCPサーバーはそういう機能はないらしい。イーサフレームのMACアドレスまで偽装すればサーバから見れば偽造かどうか判断できないけど、そこまでされたらもうどうしようもないし。
C#とかでMACアドレスを偽装してDHCPクライアントを作って遊ぶ程度なら、Discoverを送って、Offerを受け取って、Requestを投げて、Ackを受け取って、という手順でIPアドレスが得られる。W5500とかでDHCPクライアントを作る場合は、OfferとRequestの間に、割り当てられたIPアドレスに対してUDP SENDを挟むほうが良い。ARPが投げられるから、IPアドレスが存在していた場合はSEND_OKになるし、存在していない場合はTIMEOUTになる(不必要なパケットを投げるのでポート9とかあまり害がなさそうな場所に投げる)。
DHCPでIPアドレスが割り当てられれば、パケットの中で指定するオプションでルータのIPアドレスやDNSサーバのIPアドレスも取れるから、DNSで名前解決したり、ルータを超えて外にパケットを投げたりもできる。ルータ超えもとりあえず問題はなさそう。少なくとも、適当なNTPサーバーにパケットを投げれば正しく返答が得られる。
ということで、W5500からNTPサーバー(Cloudflare)にリクエスト
ロジアナは送信割り込みと受信割り込みの時間を計測、オシロは10BASE-Tの適当な箇所(とりあえずプリアンブルの最初の立ち下がり)を計測。送信割り込みは送信開始前、受信割り込みは受信完了後だから、ロジアナの方は少し時間が長く計測される。
NTPサーバーにCloudflareを選んだのは、違法コンテンツで荒稼ぎしているCDNなら頻繁に打っても迷惑かからんやろ、という理由。あとは、たぶんGoogleは日本国外のアジアサーバー、Cloudflareは日本国内のJPサーバーのはずだから、応答が早いというのもある(応答が遅いとオシロで見るのが面倒くさい)。応答速度で言えばNICTの小金井サーバーを指定すればCloudflareと同じ程度には早いはずだけど、カツカツの予算で運営しているであろう国立機関のサーバーをアホな遊びで負荷かけるのも忍びない(神戸サーバーは物理的に遠いのでレイテンシが若干増える)。awsはGoogleに比べれば応答は早いし、NICT神戸より若干早いので、おそらく国内サーバーだと思う。
他のサーバーも含めて割り込み間隔を計測。何回か試すと、最初に比べて数ms程度短くなる。たぶん途中の経路が少しずつ最適化されて、その経路がキャッシュされるんだと思う。NTPで時刻精度が欲しいなら結構高頻度に(少なくとも途中で最適化された経路のキャッシュが消えない程度の頻度で)打たないとだめかも。でもそれをやるとルータのテーブルを占有することになるので、あまり良くなさそう(NTPサーバーへの負荷も大きいし)。数時間毎にバースト状に1秒間隔で5発くらい打ってRTTが一番短いものを採用する、あたりが落としどころかな。
SEND_OKとRECVの間隔は、Cloudflareは28ms程度、AWSは30ms程度、Googleは55ms程度、かな。一旦経路が収束すれば、何回か送ってみてもほぼ安定した間隔が得られる。
ちなみに、PC(C#)からソフト処理でCloudflareにNTPを打ってみると、RTTは172ms程度と計測される。実際は30ms程度で帰るはずだから、PC内部で150ms近い遅延が発生していることになる(ちょっと大きすぎるので、もう少し工夫すれば圧縮できそうな気もする)。
そういえば、北海道にNTPサーバーってないのか?と思って、試しにさくらインターネットの公開NTPサーバーを叩いてみた。結果、23msで応答が帰った。Cloudflareを抜いてトップ。とはいえ、おそらく関東圏であろうCloudflareと比べて圧倒的に早いというわけでもない。もしかしたらONUあたりがボトルネックになっていて全体的に一定の遅延がかかっているだけかもしれないけど。
北大にもNTPサーバーはあるらしくて、DNSで問い合わせれば正しそうなIPアドレスが得られるけど、試しにNTPパケットを投げても応答がないので、おそらく校外からは使えないんだと思う。
NordVPNのIPアドレス検索に突っ込んでみると、AWSは大阪として表示されるけど、Cloudflareは結果なし、Googleはジョージア州、さくらは結果なし、になる。
ジョージア州までは大圏航路で1.1万km、往復2.2万kmとして伝搬時間は最速でも73ms程度必要だから、普通に考えれば55msで帰るのは不可能。ニュートリノ通信とかで地球を貫通したとしても往復1.9万kmちょっとあるから、63ms程度かかる。ニュートリノ通信、あんまり早くないんだな。HFTで10ms早ければ大儲けできるだろうけど。/* 実際にニュートリノ通信が実用化されたとすれば、途中でルータを挟まずに直結できる分で差はもっと大きいだろうけど(※変復調のレイテンシは無視するものとする) */
***
オシロでサンプリングした100BASE-TXを復元する遊び
↑オシロで取った波形(1Gsa/s)を1symbol(8samples)で折り返してグラフ化
↓1symbol分の平均値
サンプリングした波形は主にオーバーシュートに起因するノイズが多いので、平均化するだけでアイがかなり広がる。
平均値の微分値の絶対値の平均値
1-8はラグのサンプル数、max/minはラグごとの最大値と最小値の比。ラグを大きくすれば微分値も大きくなるけど、最大/最小の比が下がってしまう。比はラグ1が一番大きいけど、とはいえ3割程度しか変わらないが。
平均化したサンプルと、それの微分値の絶対値の平均値(ラグ1)
ビットの位相と微分値の位相には関連性が認められる。
微分値の適当な位置(最下点or最上点)を基準にして、そこからNポイント後をサンプリングに使う、みたいな感じにすれば、アイが開いているところのサンプルを取ることができる。
ただ、今回のデータの場合は、微分の位相とビットの位相は微妙な位置関係になっている。サンプリングレートが数倍高ければ(数Gsa/sでサンプリングできれば)もっと綺麗な関係になるはず。もっと上のクラスのオシロが必要になるし、計算量もかなり増えるけど。
あと、サンプルデータをざっと見た感じ、クロックエラーは十分に低そうな感じ。少なくとも、10kpts程度であれば十分にコヒーレント。短いパケットがどこにいるかがわかっていれば、クロックリカバリ無しで固定位相でサンプリングしても問題なさそう(今回の場合はW5500からUDPを投げて、SEND_OKでトリガしたので、その位置付近にパケットがあることはわかっている)。
ということで、ビット位相は固定で、MLT-3の復調
青と橙がMLT-3(NRZI)から復調したビット(青がビット0、橙がビット1)。PRBS(11bit)との相関値も緑で示している。
100BASE-Xはアイドル時に正弦波状の信号が出しっぱなしになるので、31.25MHzの線スペクトルをばらまかないようにPRBSで拡散を行っている。接続初期はPRBS位相が不明なのでビット列は0と1がランダムに出ている。
この乱数ビット列に対してPRBSを相関させる。一定の長さ(2047bit)のビット列が溜まると相関値が+1に安定して、2047bit周期で-2047のピークが出る(PRBSのアイドル信号は負論理なので相関値も負になる)。
ピークを見つけたらそこをPRBSの基準として、ビット和を取る。以降はアイドル信号のビット1が出続ける。
7000付近で短いUDPパケットを1個投げていて、相関値が暴れることで非アイドルであることがわかる(ビット0も出てくる)。
ここのビットパターンを見ると頭にJKや末尾にTRがあるので、少なくとも100BASE-Xとしてそれなりに正しく復調できているはず。
100BASE-TXでは10BASE-Tと違って常にデータが流れっぱなしになるのは、クロック同期だけでなく、PRBSの同期を維持する目的もありそう。そもそもPRBSを使わなければデータがない時は4B5Bビット列自体止めておけば線スペクトルは出ないのでは?という気もするが。それはそれでやはりクロックや4B5Bの同期が面倒なんだろうけども。
拡散を解除した4B5Bから、過去10bit分のビットストリームを持っておいて、JKを見つけたら以降TRが出てくるまでをダンプすると、555555555555D550EBF6XXXXXX0008DC010203080045000020000A400080117633C0A80189C0A801B600440009000C76F3010203040000000000000000000000000000XXXXXXXXというようなバイト列が得られる。最初の55..D5はイーサネットフレームのプリアンブル(頭にJKが入るので、10BASEに比べて1バイト少ない)、50EBF6XXXXXXが送信先MACアドレス(PC宛で出したのでASUSのコードから始まる)、その次が送信元MACアドレス(WizNetの適当な番号を設定)、以降IPv4ヘッダやUDPヘッダ、ペイロード、パディング、CRC、と続く。CRCを計算すると正しく0x2144DF1Cが得られる。
ということで、100BASE-TXも無事に復調を確認できた。
わりと簡単に復調できた10BASE-Tに比べて、100BASE-TXは復調がかなり面倒くさい。当然だけど、ビットレートが上がると復調の難易度も上がる。もっとサンプリングレートの高いADCとか、それこそLSIみたいにリアルタイムでアナログ的な処理ができるのであれば、もっと特性よく受けられるんだろうけど。
100BASE-TXは3値(+1V、0V、-1V)を使用して、NRZIでデータを送る。0を出すときは位相を維持、1を出すときは90度進める。アイドル時は1を出し続けるが、NRZI/MLT-3で125Mbaud/4=31.25MHzの3レベル正弦波が出続けるから、複数の100BASE-Tを引き回したりすると31.25MHzの強烈な線スペクトルが出る。これを抑圧するために11bitのm系列で拡散する。
m系列の位相を決めるためには2047bitのアイドルが必要だから、少なくとも35マイクロ秒程度のアイドルが時々入る必要がある(まあ、イーサネットで帯域使用率を完全に100%フルで使うこともあるまいが)。
なんか、ベースバンドと言いつつ、結局無線通信と似たようなことをやってるなぁ。10BASEはマンチェスタ符号だからどちらかといえば有線通信寄りだけど(ADS-Bとか、無線通信でもマンチェスタ符号の使用例はあるわけだが)、100BASE-Xはスペクトラム拡散とかしてて、普通に無線通信のベースバンド信号って感じだ。……だからベースバンド信号なのか。納得。
10BASE-Tも100BASE-TXもツイストペア1本で送るから、適当なキャリアでFSK変調とかすればそのまま無線で飛ばせそう。もっとも、帯域幅がかなり広いから周波数使用効率は悪いし、変復調も面倒だろうけど。それに、有線用の規格だから誤り訂正とかは全く無いので、無線で飛ばそうとすると品質が厳しいだろうけど。だからわざわざWiFiを作ってるわけだし。
100BASE-TXって平衡接続のプラスとマイナスを間違えるとどうなるんだろう? Google AI曰くリンクアップしないor極めて不安定になるとのことだけど、でもMLT-3って電圧レベルの変化が1、維持が0なわけだから、それがプラスに変わろうがマイナスに変わろうが関係なくね?
10BASE-Tはマンチェスタ符号が逆転するので、ビット論理が逆になるから基本的に逆接続は駄目だろうけど。
こういうのは実際に間違ったピンアサインのケーブルを作って試してみるのが確実なんだろうけどなー。気が向いたらEthernetのケーブルを作る工具類を買おう……とは思いつつ、頻繁に使うわけじゃないから圧着工具は安物でいいだろうけど、いかんせんCat.5eケーブルがな。。。100mとか買っても使わないわけで、1割使うかもわからないのに気軽に買える値段でもないし、かといってPCとかある程度信頼したい機器の接続に自作ケーブルを使う可能性があることを考えると極端に安いヤツを買うのも嫌なわけで。適当な長さのCat.5eAssyを買って切って使うのが現実的かな。切って使うことを考えてないであろうケーブルって切って使えるのかわからないけど。
100BASE-TXって途切れずに(連続位相で)アイドル信号を出しっぱなしにするから、1対1が前提のはずなんだけど、最近のリピーターハブって100BASEや1000BASEに対応しているらしい。どういう原理なんだろう?
他のデバイスから送られてきたパケットを一旦クロック復元して適当にバッファしてから再送する、みたいなことをやってるんだろうか? バカハブって実はスイッチングハブと同程度には複雑なことをやってる?? だとするとスイッチングハブと同じくらい複雑で、圧倒的に数が出ない分で、値段が高いってのは理解できる気もする(実際はどうかわからないけど)。
というか、一旦復調して再クロッキングして配布するくらいなら、スイッチングハブのMACアドレスルーティングを省略して、入ってきたパケットを全部ブロードキャストとして解釈して出せばいいんじゃね、って気もするな。とするとスイッチングハブの小改造でリピーターハブとして使えそうな気もするが。
でも最近のスイッチングハブなんてCPUやFPGAでなく、LSI/ASICで組んでるだろうし、それを改造しようとするとやっぱり製造コストが高くなるんだろうな。スイッチングハブのデバッグ用機能でMACアドレスルーティングをせずにブロードキャストする、みたいな実装がされているヤツがあれば、安くリピーターハブとして使えるんだろうけど、そういうふうに使えると知られている製品が有名でないってことは、無いんだろうな。
スイッチングハブってMACアドレステーブルが空のときはブロードキャストするわけだから、強制的にテーブルをクリアするような(メモリで辞書引きしても結果を返さないような)機能があればいいんだろうけど。
同じMACアドレスが複数のポートに接続されていたらそれぞれのポートにパケットを出す、みたいな機能を持ったスイッチングハブがあれば、監視したいデバイスのMACアドレスをPCから出して横流ししてもらう、みたいなこともできるだろうけど(MACアドレスをどうやって偽装するかはさておき)、実際のスイッチングハブは、MACアドレスは最初に登録されたポートを使って、一定時間(数分とか)で削除して、必要になったらブロードキャスト/学習で登録し直して、同じMACアドレスが複数存在する場合はテーブルから削除されたタイミングで新しく応答したほうが使われる、みたいな挙動らしい。
10BASE-Tの10MHz(max20Mtoggle/sec)って、マイコンからすればSPI/UART/USB FSと同程度のGPIO速度なわけだし、変調方式だって極めて単純だし、10BASE-T Phyを内蔵したマイコンだってもっとあっても良さそうな気がするけど、Ethernet Phyを内蔵したマイコンってかなり少ない気がする。前回書いたSTM32はMACまでを内蔵していて、外付けしたPhyとはRMIIで接続する方式。
別件で調べ物をしていたらルネサスのSHでPHY内蔵(パルストランスだけ外部に用意)というものが出てきた。BGAパッケージなので結構大規模なマイコン。
平衡を扱わなきゃいけない(コンパレータで受けなきゃいけない)のが面倒、長距離を引き回して入ってくるノイズに耐えるのが大変、そもそも10BASEの需要が無い、みたいな理由なんだろうか。そりゃUSB FSと10BASEどっちを使いたいかというとUSBのほうが需要はありそうだけど、かといって10BASEもちょっとしたセンサやコントローラのネットワーク化とかでは便利そうな気がするけどな。USBは短距離のP2Pでしか使えないけど、10BASEなら比較的自由なトポロジで配置できるし。
そういう機器を作りたいなら適当なPhyをSPIとかで外付けすればいいでしょ、みたいなことなのかもしれないけど。
これからの時代だと、車載用の10BASE-T1Sや100BASE-T1を内蔵したマイコンは出てきそうだけど、マルチレベルを出さなきゃいけないからマイコン直結は面倒そうだ。結局RMII接続かな。ワンチップで(外付けPhy等無しに)10BASE-T1Sを接続できるマイコンは末端付近で便利そうだけどな。まあ、それが発売されたところで、家庭やオフィスの10BASE-T対応ネットワークに接続できるわけではないけども。
Wikipediaのボーレートの説明を見ると、10BASE-Tは10Mbaudと書いてあるし、RS-232でもbpsとbaudは同じ値、みたいに書いてあって、ちょっと違和感。
個人的には、ボーレートは1秒間で信号が変化する最大の回数、ビットレートはそれによって送ることができる実効データレート、の認識なので、例えば10BASE-Tはマンチェスタ符号化だから20Mbaudだし、9600baudのRS-232はスタートビットとエンドビットを除いて実効ビットレートは7680bps(Start1,Data8,Parity1,Stop2なら6400bps)、というイメージなんだけど。
0 件のコメント:
コメントを投稿