VIDEO
ロッキード・マーティンの無人潜水プラットフォームのコンセプト。友軍の潜水艦の底に張り付いて、潜水艦の運動エネルギーで充電できるとか面白い機能も有りつつ、自立で戦闘できるランチャーみたいな使い方もできる。実際に撃つ場合は一旦浮上して衛星リンクで許可を得たりもできるらしい。魚雷や偵察・攻撃用のドローンを投射できることを考えると、結構でかいビークルっぽいな。もしかしたらSDVと同じような規模・運用方法を考えているんだろうか? 原潜の背中に積んで運んで、目標海域の近くで吐き出して、とか。
しかしまあ、敵艦の想定が結構あれよな。中露だとしたら日本はすでに陥落しているような状況に見えなくもない。さすがに仮想敵として海上自衛隊を想定している、というのはひねくれ過ぎだと思うが。
VIDEO
Q. なぜカッパーケーブル(銅線)が大量にあるの? デジタルの光通信でよくない?
A. デジタルは1箇所切れたら全部終わり。アナログなら1,2本切れても他が使える
うーん、過渡期。。。じゃあファイバーも冗長化しろよ、という話だと思うんだけど、冗長化したり自動で繋ぎ変えたりみたいなシステムってないんだろうか? データ通信ならリンクアグリゲーションのプロトコルとかありそうだけどな。タイミングクリティカルなシステムで使うにはまだ足りないってことなんだろうか。
色々な機材を持ち込んで現場に引いてある電線を使いまわしたりするから、リプレイスのコストが高すぎ、そのコストを許容できるメリットはない、みたいなことなんだろうか。わざわざファイバーを追加するくらいならSDIでいいや、とか。
リアル港湾作業シム『Docked』3月6日配信へ。クレーン操縦から物流管理、港拡張まで全部やる“港まるごと”ワンオペ体験 - AUTOMATON
デモをちょろっと遊んでみた。ちょっとコンテナが軽そうな感じがあるけど、ゲームとしては面白かった。
ただ、「この場面で使う道具はこれじゃないだろ」というような場面(例えば狭い場所でリーチスタッカーを切り替えして奥のコンテナを取り出すとか)もあって、ちょっとストレスが溜まるかな。ゲーム性を考えるとあらゆる場面でストラドルキャリアを使って取り出すというわけにも行かないんだろうけど。あとは、荷崩れしたコンテナ船からコンテナを下ろすのにガントリークレーンを使えるんかな?という疑問。ガントリークレーンの自由度って3軸しかなさそうだけど、傾いたコンテナとか取り出せるんだろうか(ゲーム内では6軸の自由度がある)。
全部英語UI/字幕だけど、ステップバイステップでウェイポイントや操作を指示されるので、そんなに難しくはない。色々な操作があるのでキーを覚えるのは大変だけど、F1で操作方法を表示しておけるし。
https://www.tepco.co.jp/niigata_hq/data/publication/pdf/2025/2026020601p.pdf
6号機制御棒駆動機構電動機制御盤の警報発生に関する調査結果について
かなり細かく説明しているな(書いてあることをそれなりに理解するにはある程度の電機周りの基礎知識が必要とはいえ)。
Gmail の Gmailify と POP の今後の変更について - Gmail ヘルプ
スケジュールが追加された? 2026年第1四半期までに新規ユーザーのサポート(新しい追加?)を終了、既存ユーザーは’26年後半に廃止、だそう。
別に何の話というわけでもないけど、組織のトップのおじさんが気安く「万死に値する」とか言ってハラキリの文化を後生大事に抱えていて、最後の最後に一番保守的っぽい印象を残しているのがもはや皮肉だし、そこまで大口叩いておいて辞職するわけでもなく結局身内には甘いところも含めて「そういうとこやぞ」って感じがするし。
Google Earthが起動しなくてぐぐったら、Google AIが復旧手順をいくつか提示してきたんだけど、一番最初のやつが「Google Earth Proを起動し、メニューの[ヘルプ] > [修復ツールを起動]をクリック」で、これだからAIはダメなんだよ、みたいな感じの。
/* 結局Google Earthが起動しない原因は非常にアホらしい理由(人間の問題)で、特にあれこれすることもなく解決、というか、そもそも発症すらしていなかったというのが正しい結論 */
PC Web版のYouTubeの登録チャンネルの新着動画一覧がタイル表示に強制されて動画の説明も見れなくなるの、マジでクソ以外の何物でもない。Googleとかいう頭のいい人ばっかり集まってる会社がこんなに馬鹿なことをわりと頻繁にやるのか理解できない。頭のいい人が多くても平均化すると凡庸になるらしい。
Amazon musicでも思ったけど、最近のこういう感じのサービスって「登録チャンネルの動画は絶対に見る」とか「このアーティストの楽曲は絶対に買う」みたいな提供の仕方に特化している気がする。動画のタイトルや説明文を読んで見たい動画を探すとか、曲を試しに聞いてから買うかどうかを決める、みたいな、興味のエンベロープを広げるような使い方ができない。登録していないチャンネルの動画を探そうとしても、YouTubeの検索機能は本当に使い物にならないしな。そういう機能はX(旧ツイッター)の口コミに任せる、みたいな方針なのかもしれないけど。
SDRのサーバーとして使っているNUC(アンテナ引き込み近くでサンプリングしてTCPで解析PCに流し込む)、勝手に再起動する事象が発生。最近はそうならないようにWindows Updateを1週間停止して、1週間毎に手動でUpdateの確認と必要に応じて再起動の操作を行っていた(メインPCを週1で再起動しているので、それと同時にNUCも必要に応じて再起動)。
起動後にコントロールパネルを開いてみると、ちゃんとWindows Updateが止まっている。なにかね、Windows Updateって止めていても勝手に再起動するのかい?? なんのための停止機能だよ。。。
***
IRIGタイムコードの仕様書を眺めているけど、わりと簡単そう。JJYタイムコードとかなり似ている。
色々な変調やフレームが定義されているから、用途によって選べる。逆に言えば、方言が多い。デファクトスタンダードはいくつかあるらしいけど。例えばパルス幅変調は時刻精度が高いがDCバイアスがあるから長距離伝送に不向き、振幅変調はDCバイアスが無いから同軸線で比較的長距離を引き回せる代わりに時刻精度が悪い、マンチェスタ符号はDCバイアスがないから長距離を引き回せるし、時刻精度も高い、みたいな感じ。
パルス幅変調が一番基本的な方法かな。3種類のパルス幅を使用するのはJJYと同様。
振幅変調はパルスのHighを100%、Lowを33%とするASK。搬送波はいくつかの値が定義されている。ASKなので搬送波を追尾できるのはJJYと同様(JJYは変調が深いので大抵はOOKだけど)。もしかしたらLowは33%ではなくて30%かもしれないが。厳密に準拠する必要があるのでなければ、送信側は3対1くらいの比率、受信側は余裕を見て2対1位を受けられるように、程度でいいと思う。
マンチェスタ符号は一般的なマンチェスタ符号とはちょっと違う(IRIGは3値をエンコードする必要があるので)。イメージとしてはASKをBPSKにして2値化した感じ。1bitを表現するのに複数のマンチェスタ符号シンボルを使用する。あんまりマンチェスタ符号っぽくない。
ASKの時刻精度が悪いのはアナログ値を使うから、立ち上がりのタイミングを精密に決められないのが原因。2値化して(というかアナログを経由せずに)出すマンチェスタ符号なら立ち上がりを精密に決めることができる。ただ、振幅情報が失われれば当然時刻情報も失われるので、周波数変調の代わりに位相変調を使う、というような感じ。
マンチェスタ符号はDCオフセットのない2値信号なので、光ファイバとの相性もいいらしい。
ビットとマンチェスタ符号には0.5シンボルのオフセットがあって、マンチェスタ符号の遷移(中央)が秒と同期するようになっている。次のビットの値があらかじめわかるので、マンチェスタ符号からパルス幅変調や振幅変調への変換は容易になっている。PWMやASKからマンチェスタ符号への変換は0.5シンボル以上の遅れが発生するので、正確なタイムコードを出したい場合は符号再生とフレーム生成が必要になる。ノイズの多い環境や遠距離まで飛ばしたい場合はマンチェスタ符号を光ファイバに載せて、IRIG TCレシーバの近くで電気信号(既存の機器と互換性の高い形式)に変えてから入れる、みたいなこともできる。
1bitを多数のマンチェスタシンボルで伝送するので、同じシンボルが連続する。マンチェスタの同期がかなり大変そうな気がする。
IRIGタイムコードには誤り検出機能は無い。十分に誤りが少ない伝送路を使うか、あるいは複数のフレームの連続性(例えば秒のインクリメント)を確認する。あるいは、BCDの時分秒と、17bitのseconds of dayから計算することもできる。
IRIGタイムコード、フォーマットとしてはだいぶシンプルだからエンコーダは簡単に作れそうだけど、そうやって作ったエンコーダをどうやって動作確認するかという問題がな。せめてマトモなエンコーダがあれば、先にそれに対応したデコーダを作って、その後でエンコーダを作る、みたいなこともできるんだけど。
ASKは可聴帯だし、マンチェスタも概ね可聴帯だろうから、探せばPCやスマホでオーディオIOベースのフリーのIRIGエンコーダ/デコーダとかもありそうではあるけど。
YouTubeあたりで探せばIRIGタイムコードの音声素材なんていくらでもあるやろ、と思って探しても、全く出てこない。大部分はSMPTEタイムコード機材のVlog動画ばっかり。YouTuber、タイムコードジェネレーター買いすぎでわ。
あとはオーディオ機器でiRigという製品シリーズがあるらしくて、字面から分かる通りスマートフォン向けの機器だけど、検索ワードを変えると(例えば"IRIG B122"みたいにtimecodeを検索ワードから外すと)これの検索結果が大量に出てくる。
動画に限らないけど、インターネットが民主化して大量の人間が入り込んだ結果、ごく少数の人しか知らないディープな知識、いわゆる集合知と呼ばれるものが押し流されて、多数の人間が飛びつく話題ばかりしか出てこない、という現象。特にSNSはその傾向が強いんだろうけど。まあ、ニューラルネットワークだってそういう挙動だし、知性っぽいよな、とは思いつつ、条件反射的な反応を知性と呼んでいいのかはまた別の問題だけど、そんな事を言い始めるとな。。。
試しにIRIGタイムコードの形のWAVを作成(P,0,1,P,0,1の並び)
下がASK、左上がPWM、右上がマンチェスタ。振幅変調と言いつつキャリアとビットレートが近いので素直に振幅復調しようとすると結構大変そう。どうせ受信側でもローカルを作るんだから同期検波すればいいだろ、というような考え方なのかもしれないが。
マイコンから出すことを考えると、PWMはわりと簡単そうだし、マンチェスタ符号も出せないことはないはず。ASKはアナログ波形を出さなきゃいけないので大変そうだ。DAC+ボルテージフォロアで出すとするなら、最低でもSTM32F303K8みたいなデバイスが必要になる。電圧の分解能が悪くてもいいならメモリバスにR-2Rをぶら下げてDACとして使うとか、GPIOにDMA転送できるならそれでもいいけど、どちらにしろある程度のリソースが必要になる。いずれにしろ、IRIG TCを出すだけなら、必要があれば出せないことはないかな、といった感じ。クロックを出したりまで考えると大変そうだけど。
B127とB227
IRIG TCのサンプルデータの生成、うまいこと自動化したら全パターン一気に吐けないかな、と思って、そういえばIRIG TCってどれくらいの種類があるんだろうかと数えてみたら、トータルで300あるらしい? 搬送波は最大1MHzまであるので、それをWAVで書き出そうとすると50Msps程度は必要だし、全部50Mspsで出すと莫大な量になるから搬送波が低いやつは低spsで書き出したいし。とか考えるとかなり複雑なコードになりそうだ。
50Mspsだとしても例えばfl2kで出せば実空間に出せるわけで、タイミング確度を求めずにとりあえず動作確認用の波形が欲しいみたいな場合はできそう。fl2kなら3chを出せるから、IRIGのフォーマットを3種類出すこともできるし、1PPS、10MHz、IRIG-B122、みたいな信号を出すこともできるし。fl2kは汎用の水晶を積んでいるからクロック精度は悪いけど、10MHzだから適当な外部クロックを突っ込んでやればそれで済むはずだし。
同じくIRIGのタイムコードとして、UARTを使うIRIG J-1x/J-2xというものがあるらしい。1は1秒/フレームで1秒桁まで、2は0.1秒/フレームで0.1秒桁までを表現。xでボーレートを指定(2の300から9の38400baudまで)。1xは300baud以上、2xは2400baud以上。7bitOddのストップ1。2xは<SOH>DDD:HH:MM:SS.S<CR><LF>のフォーマット(1xは.Sが無い)。概ね1年毎に1周する。
タイミングはSOHのスタートビットの立ち下がりエッジで規定。フレーム間はアイドル(H固定)だから、一定期間H後の立ち下がりエッジでトリガできる。STM32のUARTだとタイムアウト機能があったはずだから、これでタイマのICを有効化してエッジでカウンタをキャプチャ、みたいな感じで受信できるはず。送る場合はハードフロー制御で出すのを止めて、負論理のPPSで送信を許可した瞬間にスタートビットが始まる、みたいな感じで処理できるはず。
UARTではないIRIGはアルファベットでフレームレートを規定するが、すでにHまで使っているので、UARTを使うJまではあと1個しか拡張できない。まあ、今更IRIGタイムコードを拡張したいという需要もないだろうけど。
あと、IRIG Jは搬送波がないので、周波数を出すことができない。IRIG x00xも搬送波はないけど、1bit分解能の時刻で、例えばIRIG Bなら10msを決めることができる。搬送波を出す場合、例えばIRIG Bx1xなら1kHzの搬送波で1msを決めれる(最大1MHzまで)。
1PPSとか10PPSの入力側が、一定時間アイドル後の最初のエッジで同期みたいなロジックであれば、IRIG JをPPSの代わりに使うこともできる。普通はそういう機能は無いはずなので、そういうふうに使うことはできない。UARTを1ch受けれる小さいマイコンと2入力NORゲートが1個あればIRIG J-1xやIRIG J-2xを1PPSに変換することもできる。ただ、パルス幅が極めて狭くなるので、十分に広いパルス幅(100msとか)が必要な場合はORゲートを追加してマイコンから追加パルスを出すみたいな事が必要になる。立ち下がりエッジのジッタは大きくなるけど、基本的には立ち上がりだけで決めるだろうから問題はないはず。
IRIG [A-H]は受信がちょっと面倒なのがなー。IRIG x00xならPWMキャプチャができるマイコンならわりあい容易に受信できそうだけど、x1xxやx2xxはちょっと大変そうだ。無理してデコーダを作るくらいなら、1MHzや10MHzのref clockとIRIG Jの2本で投げたほうが楽ってこともありそう。
***
SuperK OD-DAQ - GPS subsystem
スーパーカミオカンデの時刻決定周り。GPSでUTC(USNO)を決めてファイバで引っ張って分配。
https://tech.nao.ac.jp/tech-sympo/2020/proceedings/tecsym20_Hirano_Ken.pdf
VERAの時計回りの機材枯渇に対応するために作り直したよ、みたいな話。たぶんDAQ(ADC)周りとは独立した、アンテナ駆動周りの時計の話だと思う。なかなか複雑な構成。巨大で高額かつ信頼性が要求される機械の部品だから、電子工作レベルのマイコンでアダプタを作って、みたいな話じゃ済まないんだろうけど。
時刻決定の話を探してたら、博論でFPGAベースのNTPサーバーを試作した話が出てきて、それが某組織で使用されている、みたいなことが書いてあった。そうか、あれって大学院生が作ったシステムだったんか……
***
STM32F1/W5500のNTPクライアント、動かしてると別の遊びができないからそろそろ止めるかー、と思いつつグラフを眺めていたら、なんか急にCloudflareのオフセットが減ったんだけど……
CloudflareとGoogleのAWSからの差は前回の画像と符号が逆になっているので注意。
Google-AWSはほぼ0msを行ったり来たりしているので、おそらくGoogleとAWSの時刻確度は高い。
Cloudflare-AWSは最初は-2ms強だったものが-3ms弱までずれていって、X軸70万付近を境に急に-1ms付近まで引き戻されている。もしかして、CloudflareのNTPクロックってフリーランしてるんか? そんな事ある??
W5500のNTP時刻比較、しばらく安定して動いていたんだけど、急にエラーを吐き続けるようになってしまった。おそらく稀に発生するネットワークの遅延とタイムアウト処理のタイミングが変な感じに噛み合ってエラーから復帰できずに次のクエリも失敗する、という感じらしい。ネットワーク遅延の発生回数はかなり少ないから、エラー発生率はかなり高いことになる。でも時間あたりの発生率は低いのでデバッグが大変。せっかくの機会なのでここで終了。
***
STM32F303K8でタイムコードジェネレータを作る遊び。どういう種類の信号を出すかで迷いつつ、まずはどういう信号が作れるかを確認しているターン。
STM32F303K8でも、クロックの調整を行わないのであれば(誤差のあるクロックに追従してタイムスタンピングするだけなら)10MHzから1PPSまで、あるいは各種IRIGタイムコードも含めて出せそうな気配。
クロックの微調整が必要なら、STM32G431KBがあると良さそう。調整と言っても数ナノ秒単位でクロックを進めるか遅らせるかの調整だから、ジッターはそれなりに含むけど。
STM32G431KBT6はDigiKeyで1個4.91USD、2.5k個買うと単価は2.72USDくらい。これをマルツで買うと1個1100円、2400個で470円。うーん。ちなみにSTM32F303K8T6はマルツで1200円、秋月で780円。秋月、いったいいつから在庫抱えてるんだ…… これだけ回転悪ければ、そりゃ不人気商品はどんどん取り扱い終了していくか。。。
市販の機材で精密な時刻を作る用途(特にアンサンブルで時刻を決める場合)って、おそらく原子時計は各々フリーランさせて、出力される10MHzを位相変調するような感じで調整しているはずなんだけど、どうやって信号処理しているんだろうか。
デジタルでゴリ押すならADCで正弦波をキャプチャ、FIRで複素信号化、複素積で移相、実部をDACで出力、みたいな感じでできるだろうけど、10MHzを変調しようとすると数百Mspsくらいは欲しいだろうし、大昔からこういうデバイスが存在している以上は、デジタル信号処理ではないはずなのだが。
とはいえアナログ位相変調でやるのも大変そうだし。VCOで位相を固定した(&任意に移相できる)10MHzを作ってそれを出力するのが手っ取り早いだろうけど、そうするとVCOのノイズがそのまま出てくることになる。あるいは、この手の10MHzクロックに要求されているのは高い精度の周波数だけであって、短周期成分はあまり問題ないのかもしれないけど。
*
とまあいろいろ考えつつ、試しにタイムコードジェネレータのピンアサインも考える
HSEからコアを60MHzで駆動。10MHz、1MHz、1PPSを出力。IRIG系は、アナログ系が1ch、デジタル系は何種類か。
今のところ、IRIG-B003、IRIG-B1x3、IRIG-Jxx、を出力している。
アナログ系は例えばIRIG-B122互換信号を出せるし、搬送波は1kHz、10kHz、100kHzに対応している。DACを1Mspsで走らせているので、1MHzキャリアは使用不可、100kHzは10サンプル/周期なのでノイズちょっと多め。
デジタル系はPWMのB003とUARTのJxxにだけ対応。マンチェスタ符号は未実装だけど、多分出せる。Jは現状12,15,25,27に対応。GPIOから出していて、かつ高速化のためにベタ書き(Excelでコード生成)している関係で、ROM的にはUARTを出すのが一番キツイ。アセンブリで書けばもう少し小さくなると思うけど、さすがにそこまでするつもりはない。ROM容量64kBに対してすでに57kB使っている。
GPIOの余裕があまり無いので、信号形式を操作するようなインターフェースを追加する余地が無い。ADCが2本程度使えるから、ロータリースイッチを2個程度つけることはできるけど、そんなもの付けたところで何に使えるんだ、という話だしな。せいぜいフレームフォーマット(A-H)と搬送波周波数を切り替える程度にしか使えない。
そんなに制限されたUIを作るくらいなら、別のマイコンをもう1個置いてUARTで接続、あたりのほうが使いやすそう。クロック用のマイコンはNiMHでバッテリバックアップ、UIは停電時には電源断、みたいな感じで割り切ったりできるし。
実用的なタイムコードジェネレータが必要な場合は、もう一回り大きな、例えば100pinくらいのパッケージを採用して、豊富なIOで使いやすいユーザーインターフェースを用意しつつ、停電時はADCで電源や電池を監視してモードを切り替え、というような設計になるんだろう。今の時代に単機能なIRIGタイムコードジェネレータの新規設計があるかどうかはさておき。
アナログ系
1PPSでトリガしてB003とB123をキャプチャ。
1PPSでトリガしてB003とB133をキャプチャ。デジタルとアナログのタイミングはかなり一致している。
デジタル系
200kHzでサンプリング。当然10MHzと1MHzは折り返しているので意味はない。
一番上のUSER_LEDが、処理中はHighになる。デューティー比が十分に低いので、計算リソース的にはまだまだ余裕がある。
200MHzでサンプリング
1PPS、IRIG-B003、IRIG J-25のエッジは十分に高い精度で一致している。対して10MHz、1MHz、1PPSの位相はあまり一致していない。10MHz/1MHzはあくまでも歩度を得るために使う、という程度になるかな。
ハードウェア的にはUART TX/RXやTIM15のch1とch2のリソースが残っているから、GPSからNMEAを受け取ったり、GPSの1PPSと自身の1PPSを比較して、精密な時刻を受け取ることもできる。
ただ、自身の歩度や時刻をある程度精密に決めたとしても、それをフィードバックする方法がない。タイマのクロックを1パルス止めたり入れたりとかすれば調整はできるけど、60MHzから10MHzを作っているから、1パルスの分解能がかなり悪いし、調整の際は出力されるクロックが12MHzや1.2MHz、あるいは8.57MHzや0.857MHzになる。
一応、高ZでよければDACが1ch残っているから、外付けのVCOやバリキャップを制御して、クロックの挿入・除去無しに、比較的綺麗に歩度を調整することもできる。ただ、その場合はアナログ回路の追加やらPID等の制御ループやらいろいろ考えなくちゃならない。現状、振幅変調も含めてすべてデジタル的に処理しているし、外付けクロックはMEMS発振器を使っているので、基本的にアナログ系のループは一切ない(STM32F3内蔵オペアンプでボルテージフォロアを作ってはいるが)。水晶を外付けするとアナログ回路を追加しなきゃいけないデメリットが大きそう。単に面倒ともいう。
SiTimeのSiT3807みたいにVCXOなMEMS発振器みたいなものも売っているから、アナログ回路が面倒ならそれを使うという手もある。曰く0.1-3.2V範囲(3.3V品の場合)で入力インピーダンスが100kΩ、リニアリティが0.1%typとのことだから、マイコンのDACで制御するのがかなり楽そう。それでも多少のフィードバックループは必要なわけだけど、それはどうしようもない。
最近C#ばっかり使っていたから、久しぶりにC++に触ると結構違和感ある。これがコンパイル時定数になるとかホントか!?、とか。さすが組み込みでガッツリ使われている言語だけあってそのあたりのサポートが手厚い。
