欧州のDMGって大きなイベントがあるとドローン映像を撮ってるけど、これってDMGの社員がやってるんだろうか? それとも外部の会社に発注してるんだろうか?
欧州の映像だからか、25fpsでちょっとカクカクな感じが残念。せっかくドローンで取るなら50pとか60pで見たほうが綺麗だと思うのだが。
京セラの自販機
工場とかで必要な小さな消耗品の管理を行うためのソリューションらしい。
日本だとミスミの自動販売機みたいなものがあるけど、京セラの自販機はあくまでも在庫管理や商品の提供を目的としているものであって、商品の補充や発注は顧客側(工場側)が行うのかな? あるいはそのあたりもなにかソリューションがあるのかもしれないけど。
ロシア政府、“ロシア版『コール オブ デューティ』”の開発に「数百億円規模」の援助表明。「『CoD』はロシアを敵にしてばかりだ」として自前で作る - AUTOMATON
プロパガンダ用に欧米で低価格でリリースして、陣営入れ替えModが作られて、セキュリティの欠陥で国家の尊厳に重大な損害を与えた、みたいな理由で開発会社に制裁金を課して、援助資金を回収、みたいな可能性。
どんな内容のゲームを作るにしろ、「そっちが作るならこっちも作るよ」の口実になるだけな気がするけどな。でもCoDやBFみたいな巨大なフランチャイズがロシア政府や正規軍を敵にする作品を作れるとも思えないし、かといって完全新作で作るにもリスクがでかいし。政府がガッツリ資金提供するロシア版CoDは作られども、欧米側からそれに対抗できる作品が出るビジョンは見えん。ウクライナ政府が、という可能性もあるけど、それはそれでまたロシアが反発するだろうしなぁ。
某レースゲーで建設できるらしい大型パラボラアンテナ、景観は野辺山っぽいけど、副鏡支持構造はあんまり日本の大型アンテナっぽくはないな。前作メキシコマップに置かれていたLMTモチーフの望遠鏡のアセットをそのまま使ったんだろうか?
実物のLMTの副鏡支持構造はシンプルな棒状のフレームを斜めにクロスさせている。対してゲーム中のLMTはシンプルな棒状のフレームを垂直・水平にクロスさせている。大きさはだいぶ違うけど、三菱電機が作ったアタカマコンパクトアレイ(7m)は副鏡支持構造がシンプルな棒状を水平垂直に近い角度でクロスさせているから、FH5のLMTとは相似な感じ。
結果として、次作FH6の巨大パラボラアンテナも、三菱電機のACA7mに近い形になっている。
とはいえ、FH6の巨大アンテナはおそらく富士山とアルペンルートの中間付近に所在する野辺山がモチーフだろうし、いくらメーカーが同じとはいえ、ACA風ではなく45m風にしておいてくれると嬉しかったな。
そういえば某VTuberが野辺山と関わってるな…… 「野辺山45mが出てくるらしいよ」って勧誘しよう(やめなさい
45mはたぶん某アニメでも出てるだろうし、下手なモデルを使うと日本国内ではウケが悪そうだが。まあ、おそらく顧客層が違うから問題ないか。
https://www.hrr.mlit.go.jp/yukimirai-toyama/ouboronnbunn/30_tateyamayuuryo.pdf
立山黒部アルペンルートの除雪作業に関して。H10年(1998年)以降はGPSも併用。それまでは、降雪前に路肩へ立てたポールを目印に作業していた。GPSを使う場合は除雪領域のセンターをGPS付きのブルドーザーでパイロットルートを作成し、それを掘り下げる作業要領。
1998年のGPSはRTKを使っているかどうか悩ましいところだな。
https://www.giho.mitsubishielectric.co.jp/giho/pdf/2007/0701005.pdf
三菱電機の高精度GPS測位サービス(PAS)を納入、2006年3月開通時の除雪に使用された。山間部なので補正データは衛星携帯電話経由で配布。
ということは、その前の数年は通常のGPSを使っていたんだろうか?
https://jsurvey.jp/pcrg/kyougikai.files/m9.pdf
https://jsurvey.jp/pcrg/kyougikai.files/j23.pdf
アルペンルート除雪に使った三菱電機のGPS受信機の説明。ネットワーク型RTK-GPSだそう。水平方向数cm、垂直方向10cm程度の精度。通常のRTK-GPSに比べて固定点を数kmおきに設置する必要がない、とアピールしているから、それまでは固定点を使ったRTK-GPSを使っていたのかな? そりゃまあ、S/A解除前のGPSで道路の除雪作業は無理か……
準天頂衛星みたいに高仰角の衛星が増えて20mの壁の間でもRTKが使えるようになると、CADデータを入れたICT建機で綺麗に壁を削れるようになったりするんだろうか?
会社の略称でCompanyの意味で後ろにCOとついてるところ、WebサイトのURLがhogeco.co.jpとかでなんか冗長な感じ。hoge.co.jpじゃだめなんか?
co.jpならたいして変な場所にも飛ばんやろ、と思ってhoge.co.jpにアクセスしてみたらちゃんとタイムアウトするから、そのドメインは空いているはず。そっちを使えばいいのに。あるいはリダイレクトさせるとかでもいいけど。
ユーザーアカウントの作成とかでパスワードを入力する画面、ランダムに配置したキーボードとか、タップするたびに配置が変わるキーボードとか、そういうのがあると嬉しい気がする。並んだキーをタップするとか、同じキーをタップするだけでランダムな文字列を作れる。入力した文字列を別途覚えておく不便さはあるけど、自分でランダムな文字列を作る場合は、ランダムなキーをタップして、それを覚えて、みたいな手間がかかるから、片側だけでも省略できるのは便利そう。ブラウザのパスワード生成機能を使えば両方とも省略できるから、それに対応していない場所でパスワードを考えるのが面倒、という話。
ボルトを上から入れるか下から入れるか、という話の解説記事で、「ボルトを下から挿入した場合、下部に構造物があれば脱落することを防げます」とか書いてあって(完全には脱落せず、少なくとも多少のシアは耐えられる、みたいな表現)、いやいや、下に構造物がある場所でどうやって下からボルトを入れるんだよ、というツッコミ。
ナットが下にあると重力で緩むから、みたいなことも書いてあるけど、なら重いボルトが下にあったほうが重力が効きそうな気がするが。上からボルトを挿入していれば完全にナットが脱落してもわずかなせん断力には耐えられるから、ナットの緩み(張力ゼロ)を許容するなら上から入れるべきじゃねって気がする。そもそも軸力ゼロを許容できるならボルト・ナットよりもっといい方法があるだろ、という話だけど。
下からボルトを入れて、ボルト・ナット・部材に合いマークを書いておけば、ナットとボルトがズレていたときに一発で分る、というのに関しては、上から見た場合にしか適用されないから、例えばインフラ設備みたいに下から確認することがある場所ではむしろ上から入れるべき理由になりそう。
こういう記事を書いてる人って、自分の記事が矛盾してるって気が付かないんだろうか? 気が付かないんだろうなぁ(身に覚え)。
ボルトを下から入れなければならない理由って、ネットの記事で見る範囲だと腑に落ちる説明はあんまり無い気がする。実際に正しいことが書かれているのかもしれないけど、記事を見ただけではそれが判断できない(実際に試験してみないと判断できない)みたいな説明も含めて。
ちゃんと根拠になりそうな理由でいうと、ワッシャ等を入れるときに、ボルトを上から入れるとワッシャ等を脱落させる恐れがあるけど、ボルトを下から入れておけば、ボルトが脱落しない限りはワッシャ等も脱落しない、くらいかな。
建築物で高力ボルトを使う場合は重い工具を使いやすくするためにボルトを下から入れたほうがいいよ、ただし工具が干渉する場合は上から入れてね、とか、FAだと下からボルトを入れたら脱落したときにワークを破損させたり、食品ラインだと異物混入は対応コストが大きいからボルトの下からの挿入は絶対にNG(ナットも使用せず構造部材にボルトだけで締結)、とか、結局、TPOに合わせて選んでね、みたいな話になりそう。まあ、そりゃそうよな。あらゆるシチュエーションに完璧に答えられる銀の弾丸、なんてあるわけないし。
某ロケットのアレ、1号機のときに第1/2段間分離で、衝撃が円錐で収束して第2段エンジンに過大な衝撃が、みたいな現象があったけど、このあいだのやつも円錐の構造破壊らしいけど、なんか現象が似てるような気がしないでもない。まあ、ちゃんと事前に解析してあるだろうから、正常であれば問題ないんだろうけども……
Google Pixelのカメラ、設定で音量ボタンに割り当てる機能を設定できるんだな。デフォルトはシャッター。他にズーム(音量↓でワイド、音量↑でズーム)や音量(音量ボタンのデフォルト機能?)、OFF(音量操作も無効?)、が設定できる(もしかしたら音量は録音音量、OFFは出力音量?)。
音量ボタンでズームを切り替えられるのは一見便利そうだけど、じゃあどうやってシャッターを切るんだ、という問題。せめてファンクションキーが1個あれば、音量ボタンと組み合わせて色々使えて便利だろうけどな。物理キーが増えると故障場所(壊れやすいメカ、水が入りやすい開口部)が増えるから作りたくないんだろうけど。でもAppleはiPhoneにアクションボタンを載せてるからな。やはりあると便利なんだろうし、多少のコストは気にせず実装できるAppleと、できるだけ価格競争力の欲しいAndroidの差もあるだろうし。
RasPi PicoのMicroPhytonってもっと使いやすそうなものだと思ってたけど、意外と使い勝手悪そう。
公式のインタプリタはUSB CDCとして認識されて、対話モードで動作する。なので、ターミナルで手書きする範囲においては、人間の認識能力やタイプ速度を超える動作はできない。あくまでもただのCDCなので、PC側でCDCにコマンドを送ったりするプログラムを書けば、オンボードフラッシュに入らないような巨大なスクリプトも処理できるけど、まあ、そんな事するやつはおらんやろ……
BOOTSELを押しながら起動してMSCにmain.pyを入れればそれが走るらしいんだけど、なぜかウチのPicoは走らない。なんか、ウチのPico、調子悪くね??
あと、MicroPythonはドキュメントが少ない気がする。C SDKは巨大なHTMLにメソッドの一覧と説明が書いてあるけど、Python版は見当たらない。
結局BOOTSELでMSCとして認識させてスクリプトをコピーしなきゃいけないなら、BOOTSELでMSCとして認識させてuf2をコピーするのも手間としては変わらないし、スクリプトだとインタプリタで走らせてみないと結果がわからないけど、C/C++なら少なくともコンパイラが知る限りのエラーや警告は表示してくれる安心感がある。Pythonも多少の文法エラーくらいならIDEが警告は出してくれるだろうけど。
電子工作をやったことがない人に対して、MicroPhytonインタプリタを焼いたRasPiPicoを配布して、USBで接続してターミナルから対話型でGPIOのインスタンスを確保してLEDをチカチカさせて、みたいなことは楽にできるだろうけど、その後ってどうするんだろうか。最初から専用のIEDを使うのかな。
RP2040が2個乗ったボードってないんだろうか。STM32 Nucleoみたいに、1個はSWDブリッジ、もう1個がターゲット。コスト的にちょっと厳しそうだけど、買ってすぐUSBで接続してフル機能のデバッグができるのは便利そうな気がするが。
イーサネットフレーム、ヘッダにデータ長が書かれていないのが結構謎い気がする。乗っているプロトコル(IPv4とか)を知っているなら内側のプロトコルを見てイーサフレームの全長を把握できるけど、そういう仕組ではないはずだし。
ja.wikipediaの書き方を見ると、フレームチェックシーケンス(FCS)を見れば末端を把握できるから、可変長で長さが不明でもここで終了させればいいとわかる、みたいなことが書いてある。活線挿抜を考えると、自分がネットワークを最初に見たときに通信中だった場合に、ヘッダを見ていなくても末端を知る必要があるとか、あるいはパケット(イーサフレーム)が衝突してビット列の同期が取れなくなったときに末端を探す必要があるから、みたいなことなんだろうか。
とはいえ、FCSってただの4バイトデータだし、ここに入っているのはCRC32だから、これを見てパケットの末尾を知ることは不可能なはず。例えばヘッダを見逃した場合やメッセージが衝突した場合、あるいはノイズでビットが化けた場合に、CRC32が一致することで末尾を判断することはできない。
とすると、イーサネットフレームの末尾を判断するのは、イーサネットフレーム自体ではなく、その下のプロトコルで判断しなきゃいけない、ということになるはず。
100BASE-TXならTRを受信したらそこで終了、みたいなわかりやすい基準があるけど、10BASE-Tにはそういう基準は無いはず。強いて言えばマンチェスタ符号として正しくないシンボルが出る、くらい。まあ、じゃあそれで判断すればいいだろ、と言われればそこまでなんだけど。
wikipediaの記事だとFCSの後のEOFで、10BASEはキャリア消失で終了を検知する、みたいな事が書いてある。キャリア消失で終了を判定して、それまでに受信したビット列をFCSのCRCで確認して、OKなら上に投げて、NGなら握りつぶして、みたいな感じなのかな。
正しくないマンチェスタ符号を検出して通信を終了、だと、通信途中でLANケーブルが抜かれたときに困るから、やはりキャリア消失で検出するのが安心なのかな? 少なくともPHY層では。MIIで上げる信号はマンチェスタ符号で切るとしても。
とすると、FCSの「ペイロード長がわからなくてもFCSでフレームの末尾がわかる」という説明がニュアンス的に正しくない、ということなんだろうか。
イーサネットってSPIみたいに送受信でコヒーレントである必要はないわけだから、TXとRXで変調方式を分けるみたいな使い方って無いんだろうか。
例えばイーサネット接続のセキュリティカメラで、普段は動きが少ないけど場合によっては10Mbpsを大きく超えるから100BASE-TXで送るが、コマンドはほとんど無いから125Mbaudを常に出すのは電気の無駄なので10BASE-Tで接続する、みたいな用途。
オートネゴシエーションで特定の通信方式だけ有効な情報を出して、自分がそれとは違う方式で出す場合、自分は10BASE-Tで送って相手はそれ以外の方式(100BASE-TX)で送らせる、みたいなことはできるかもしれないけど、自分が100BASE-TXを出した場合、相手も100BASE-TXで送ってくるはず。自分は100で出すが相手は10で出してもらう、みたいなことはできないはず。
適当なEtherTypeを定義して、最初に10BASE-Tで接続して、そのパケットで32bit32個(128byte)とかのフラグテーブルを投げて、そのマトリクスから双方が対応できる最も高速な転送速度を決定して、リンクアップしたあとも定期的に投げ合って、高レートで送りたい時は100BASE-TXや1000BASE-Tに切り替えて、必要なくなったらまたビットレートを下げて、みたいなことはできそうだけどな。
イーサネットフレームをPHYで読むのはWoLみたいに可能なわけだし、それと同じような感じで。MACで転送されると困る(ハブを超えて別の機器に影響が出る)から、それを防ぐためにFCS(CRC32)に固定値をxorしてMAC層から見ると常に壊れたパケットを飛ばす、みたいな対応は必要だけど。
今のところ、電線を使うイーサネットの規格は20ちょっとあるらしいから、32bitテーブルでカバーできるはず。これ以上の高速化は電線ではやらないだろうから、車載とかFAとか特定用途を除けば増えないはずだし、そういう部分では特定のプロトコルしか使わないだろうからオートネゴシエーション的な機能では無視できるはずだし。FCSで壊すなら専用のEtherTypeを割り当てる必要はないけど、専用のEtherTypeが割り当てられていればデコーダが簡単になる利点がある。
受信側は自動判別するとして、相手に送信してもらう方式だけ指定するなら、32bitとか64bitのビットフィールドを投げるだけでもいいけど、どうせパケットを切り詰めたってイーサフレームの最小長があるからパケットはあまり短くならないのよな。ロジックが楽になる利点はあるけど(PHYでキャッシュするメモリも少なくて済むし)。
これくらいの仕様は過去に提案されていても良さそうな気がするけど、そういう規格が存在しないということは、需要がなかったんだろうな。まあ、昔はIoTみたいに非対称かつ省電力化が重要な用途もあまりなかっただろうしな。かといって今の時代に100BASE-TXの数百mW程度を削減したいみたいな理由で規格を新しく作って普及させられるとも思えないし。
そもそも建前は置いておいて何をやるためにそういう機能が欲しいのかというと、変調するのは楽だけど復調するのは大変、100BASE-TXは足の早いマイコンならソフト実装で出せそうだけど、受信するのは10BASE-Tのほうが楽だよね、ちょっと多めの測定データを流すときに100BASE-TXで出したり、各種設定を10BASE-Tで受信できたら便利だよね、みたいな方向性。
外付けMAC/Phyでなく、パルストランスだけ外付けで使えたら面白そうじゃね、と。まあ、実際にやろうとすると変調でリソースの大半を食われたりして実用にはならないだろうけど。そもそも125MBdの信号をプログラムが走るデバイスから真面目に出そうとしたら少なくとも250MHzで動くロジックが必要だしな。スクランブルも考えればさらにその数倍のクロックが必要になるし。
プログラムが走らないプログラマブルなデバイスを想定すると、例えばShrike-liteに乗っているForgeFPGAはGPIO2本をパラでドライブすると、min120MHzが出せるそうだ。ここまで早いGPIOが使えるなら、100BASE-TXの波形は出せてもいい気がする。FPGAならLFSRだって組めるだろうし…… でもまあ、わざわざ4B5B/MLT-3変調のためだけにForgeFPGAを乗せるかというと。。。いや、そのためのグルーロジックだろ、という話ではあるんだけど。でも25Mbps程度でいいならW5500でいいし、少し上のチップ(例えばW6300、QSPIモード)なら90Mbps程度のスループットが出るそうだから、わざわざ汎用ロジックを載せて100BASE-TXに対応するくらいなら、専用のブリッジを積んだほうが楽だろうな。さすがにForgeFPGAで100BASE-TXの受信は難しいだろうし(3レベルアナログ信号のためにアナログ段を置かなきゃいけないとか、いろいろ)。
ブレッドボードにジャンパワイヤで接続したW5500とFT232Hがいい加減じゃまになってきたので、ユニ基板に乗せてみた。
ユニ基板使うの何年ぶりだ…… 計画性と躊躇のなさが明らか。プロに見られたらバチボコに殴られるけど、趣味の遊びだから許してッ!!
とりあえず、DHCPでアドレスを取ることはできたので、たぶん動いているはず。
オシロとかロジアナでプロービングしようとすると困るけど、必要になったときに考える。
ストリナのFT232H基板はVer.2だと3.3V出力があるけど、手持ちはVer.1のVBUS出力オンリーなヤツなので、3.3VのLDOを載せている。あとは、FT232とW5500の出力が衝突すると嫌なので、100Ωを挟んでいる。せっかくなので、INTにLEDを配置している。とはいえ、W5500のINTを出しっぱなしにすることも無いけどな。あとはCSにもLEDをつけていれば、通信時に見えるので見た目が面白くはあるけど、面倒なので省略。
FT232Hの固定穴がインチじゃなくてミリなのが絶妙な使いづらさ。最初はユニ基板にミリで穴を開けるジグを作ろうかと思ったけど、でもどうせ11mmのスペーサーが必要なので、基板側のネジ穴と合わせるブラケットを作ってみた。
大昔に買ったCat.5eケーブル
マーキングにELECOM Laneedと書いてあるのでエレコム製なんだろう。
ツイストの様子がよく見える透明被覆のケーブルちょっと欲しいけど、探してもいまいち見当たらない。
RasPiPico2で100BASE-TX送信。ADCでアナログ波形(AF)をサンプリングして、それをWFM変調して、そのIFデータをUDPでPCに転送する、というような処理をやっているらしい。スクランブルを正しく実装しようとすると計算コストが高すぎるはずだから、おそらくアイドル信号は出していないはず(コード未確認)。
GitHub - kingyoPiyo/Pico-10BASE-T: 10BASE-T from Raspberry Pi Pico
RasPiPicoで10BASE-T送信。受信は将来的に対応予定とのことだが。
久しぶりにSTM32を使おうと思って、手始めにSTM32CubeMXをダウンロードしようと思ってゲストでダウンロードを試したのだが、一向にダウンロードができない。
1つ目は、Gmailのエイリアスがだめだったっぽい。延々「メールアドレスはまだ認証されていません」みたいなエラーが出続ける。エイリアスなしのメールアドレスを入れてみるとそのエラーはでなくなった。が、今度は401エラーが出続けるようになった。なんでだよ。
観念してSTのアカウントを作成。入力項目多すぎじゃねー?
RP2040+VSCode(+拡張機能)みたいに比較的容易に開発環境を構築できる現在、STM32はあまり魅力的ではないかも。と思いつつ、機能面で言えばやはりSTM32のほうが強い気がする。必要に応じて様々なチップから選択できるという利点もあるし(RPは現状C-M0+とC-M33の2種類しかない)。
気軽に電子工作を始めたいならRP、将来性を考えるならSTM32、とか? ただ、STM32は茨の道だぞぉ。あと、Arduinoプラットフォームで対応しているせいで玉石混交な情報がな。Arduino界隈は多くの初心者が自分のアウトプット用に色々な記事を書いているので、記事の質を判断できないうちにそういう記事を読むとちょっと大変なことになる。
小さめのヤツを使いたかったので、STBee mini
今回はUSB DFUファームを消して、SWDで書き込み(ST-Link v2は昔のNucleoのカケラ)。
SPIペリフェラルでW5500を接続して、動作テスト。とりあえずDHCPでIPアドレスを取得。たぶん動いてる。
今回はSPI2を使ったので、クロックは18MHz。コアクロックが72MHzだから、32クロックごとに2バイトをハンドリングする必要がある。キッチリ実装すれば足りそうな気もするけど、C++だとクロックに隙間が空いていて、処理が間に合わない。DMAなら隙間なく転送できる。DMAはDMAでいろいろ設定が必要だから2,3バイト程度の転送だと割に合わないけど。
コードはC++で書いているので、色々と面倒。やはりC#は便利。特に、PCで走るC#コードを書いてUdpClientとかでロジックをテストして、それで動いたコードをほとんどコピペしてFT232H/MPSSEでW5500を叩いて、みたいなことをやっていると。
Feature request: Programmable logic - STMicroelectronics Community
STM32にグルーロジック用の小さいロジックセルがあったら便利だよねー、みたいな、白熱()した議論。
RP2040に乗っているPIOって、実際に触ったことは無いしドキュメントもちゃんと読んでないけど、かなり「自由度の低いソフトウェア的な」機能な気がする(そもそも10命令に満たないアセンブリで書く時点で自由度が低いソフトウェア的なのは当たり前とはいえ)。FIFOで受け取ったビットストリームをSPIやUART、I2Cみたいなプロトコルで吐き出すことはできるけど、じゃあそれにm系列のPRBSをXORできますか?というと、おそらく不可能。現実的にPRBSが必要な状況なんて無いだろ、といえばそれまでだけど、あくまでもRPのPIOの柔軟性が低いということを言いたいのであって。
極端な話、STM32と小規模なFPGAを貼り合わせて、STM32のIOをFPGAに取り込んだうえで自由にルーティングしたり簡単なビット演算を行って、FPGAのIOとして外に出す、みたいな感じの機能があって、FPGAを未初期化で使えばただのSTM32として、STM32から適当なビットストリームを吐いてFPGAをコンフィグすれば(マイコンに比べれば)複雑なロジックを処理できて、みたいな機能が欲しいわけだが。それこそShrikeみたいな感じになるんだろうけども。
昔はWiznet W5200とSTM32F103CBを貼り合わせてパッケージングした製品とかも売ってたみたいだし、同じように小さいFPGA(e.g. ForgeFPGA)を貼り合わせてパッケージングした製品とかあっても良さそうな気がするけど、でもそんなもん作ってもコストが合わないから、どうしても必要なら各自PCBに載せろ、って話なんだろうなぁ。
フォーラムの中でも書いてあるけど、そういう製品を作ったところでちょうどいい塩梅の製品にはならない(機能が過小or過大になる)だろうし。
Wiresharkでデータ長0のDiscardパケットを受け取ると長さ0のUDPパケットとして表示されるの、期待した動作とは違うけど、これってどういう挙動なんだろうか。Discardってべつに1バイト以上無いとだめ、みたいな理由はないはずだし、0バイトのパケットでもDiscardとして表示されていいはずなんだけど。
https://www.ietf.org/rfc/rfc863.txt
DISCARDプロトコルのRFC。めっちゃ短い。
「捨てるよ」としか書かれていないから、0バイトのパケットがDISCARDとして認識されないのはWireshark側のバグ的なものだと思うのだが。
