東京住みの人は地元で科学技術系のイベントが多くて羨ましい。
カンガルーのロゴ入りの模型(一番目立つところにロゴを配置するとYouTubeの埋め込みでは再生ボタンで見えないというよくあるやつ)。
そのうちキーウィロゴの模型とかも作るんかな? /* NZ空軍はキーウィのロゴを使っているし、海軍が使用するヘリ(空軍が整備を担当)にもキーウィが書いてあるけど、海軍はキーウィのロゴは大々的には使っていないっぽいな */
日本の動物(特に固有種)でシルエットだけで用意に判別できる動物ってあんまり思いつかない。
OlightってLED自体も自社で製造してるんか…… LEDはわりあい作りやすいチップではあるのかな? 極端な微細化も不要だし、配線を何層も重ねる必要もないし。中国ならパワエレ用のSiC製造ラインを中古で買ってLEDに振り分けてとかすれば安く一通り揃えられそうだし。一旦半導体に手を出せば、そのうち制御用のロジックチップとかDCDC用のパワエレも自社内で作れそうだし、コンスタントに売れるなら原料だけ買って製品を出荷するみたいな感じで利益率は改善できそう。
従来のArkfeldはホワイトでダブルクリックするとストロボ、トリプルクリックするとターボだけど、ArkProではダブルクリックでターボ、トリプルクリックでストロボ、らしくて、いかにも互換性に興味のないOlightっぽいなぁ。トリプルクリックでターボは不便だけど、かといってストロボが必要なシチュエーションでトリプルクリックもやばいだろうに。Olight製品は某チャンネルで酷評されていたりするのを見ると、実際のシチュエーションでの使いやすさとかは一切興味がなくて、ただ所有欲を満たすだけの製品を量産している印象。まあ、タクティカルな使い方をしたいユーザーなんて無視できる程度の人数しかいないだろうしなぁ。
【#毎日早瀬とサシ飲み】13日目 早瀬走×栞葉るり part.41 - YouTube
栞葉、なんでそんなに極限環境に行きたいんだよ? JCG案件はやってたし、JAMSTECからも案件来ないかな。
10年以上前にしんかい6500と母船を光ファイバーで接続して水深5000mから中継をやってたし、やろうと思えば深海から生配信もできるんだけど、でも1回だけしかやらなかったってことは相当金or手間がかかるんだろうな。
最近は水中ドローン用の光通信(自由空間? 海中無線)の研究も行われているけど、とはいえ映像を送れるような上り速度(&コメントを表示できる程度の下り速度)を出せるようなものとなると、かなり高頻度に中継しないと厳しそう。数十台のROVで中継するくらいなら有線のほうがまだやすそう。
ROVだと光ファイバー接続は当たり前だろうし、有人型でも光ファイバーの取り回しはそこまで面倒ではないという可能性はないかな? むしろ10年前では生配信に使えるアップリンクを特に洋上で確保するのが面倒だった、とか。最近だとStarlinkを使えば洋上でも高速通信が可能だし、あとはROVと同じようにファイバーを引き回せば、深海からの配信とかもそれほど大変ではなさそうな気がするが。
しかし、調査の様子を生配信となると、そこで発見した事の優先権が得られない問題がある(ネット経由で見ていた人が先に論文を書いてしまう可能性が排除できない)のがネックではありそう。純粋な調査というより、広報に振った活動になるから、運用コストを誰が支払うんだ、少ない広報予算を圧迫するほどのものなのか、みたいな。
しんかい6500のWebサイトで25周年特集みたいなページがあったから覗いてみたら2015年だって。6Kの活動レポートも2019年夏までは頻繁に報告されているけど、それ以降は1件もない。6Kってここ5年は一切活動していない…??
防衛省 自衛隊独自の階級名変更を検討へ | NHKニュース | 安全保障、防衛省・自衛隊
階級名の変更について、自衛隊の幹部の1人は「(前略)そもそも今の階級名を英訳するとアメリカなどと同じなので対外的に困ることはない。(後略)」と話しました。
別の幹部は「(前略)議論するならば階級名より退官後の処遇などを優先してほしい」と話しました。
そらそう。
呼び方を変えて本人たちの士気を高めるぞーっつって処遇から目をそらすならそれは単にやりがい搾取でしかない。やりがいのない仕事に給料だけで人を呼び込んでもろくなことにならないので、そのあたりは上手くバランスを取る必要はあるにしても。
言い方は悪いけど、自衛隊って税金を突っ込むうえで無駄が少ない組織だと思うんだよな。他の組織と違って個人の行動がかなり規制されていて、遠出(外泊等)やまして海外旅行に気軽に行ける職種じゃないから、給料を上げればある程度は地元の飲食店に還元される。多くの自衛隊を抱えるのは地方だから、税収の地方への分散になる(少なくとも国民平均割で使って人口密集地に集まることは避けられる)。他の省庁と違って特定の分野(企業、例えば土木関係)に予算が集中するわけでもない(装備品なら重工系や電機系、大規模設備なら土木関係、細々した外部委託なら周辺の中小企業等、ある程度広い業種に分散できる)。
職員(隊員)の給与に振り分けても、民間人ほど「海外旅行で贅沢する」みたいな用途で使われる率が高くないことを期待できるから、給与の大部分は国内で消費される(隊員によっては個人で海外のトレーニングに大金を突っ込むみたいな人はいるにしても)。あるいは、自衛隊が保有する装備にしても、「防衛装備品ですので」の一言を添えれば国産品を買うハードルが下がる(純粋な価格競争で海外製品が流入することを一定程度抑止できる)。高額な装備を国産化すれば国内産業に還元できる(あるいは逆にE-767みたいな使い方もできる)。ただ、日本が武器を作るなんてけしからん、みたいなことを言い始めると、海外から言い値で装備を買って多額の外貨が流出することなるから、自衛隊へ金を突っ込むなら国内で消費する産業構造(飲食業から重工業まで)を整えなきゃいけない。それらをうまく回すことができれば、国内に数兆円の市場規模が用意できる。金の使い方を国が自由に決められるトヨタ3個分の組織はでかいぜぇ。
あとは全然関係ないけど、自衛隊は便利屋じゃないみたいな話。それはそうなんだけど、とはいえ、早ければ呼集をかけて1日で数千人とか、ゆっくり準備して1週間で数百人とかをあまり無理せずに集められる組織ってそうそうないはずなんだよな。昨今の熊対策にしても、じゃあ警察とか消防とかで大規模に人や装備を急に集められるかというと、おそらく無理だろうし、民間に委託するのも、おそらく無理だろう。災害時なんかは特に顕著で、怪我の応急処置もできるし、土を掘り返すこともできるし、建物を立てることもできるし、食事も提供できるし、それらに必要な輸送能力も持ってるし、というような組織は、他には類を見ない特徴がある。せっかく高い金を払って維持してるんだから、必要かつ使えるときには使わなきゃもったいない。
防災は防災専門の組織を作るべきだ、といっても、彼ら自身で人材から作業能力から全部独自に揃えたとして、武器は持たないにしても、結局は自衛隊とほとんど同じ能力を持つことになるし、似たような能力を持った組織を2つ並行して維持するためには莫大なコストがかかる。それなら自衛隊側で待遇改善とかで人を集めたほうが低コストで目的を達成できるはず。例えば災害時のための航空輸送や海上輸送のために輸送機や揚陸艦を買おう、とか言い始めたら、一つで数百億円とか数千億円のアセットを数十から数百、それに付随する人員や固定資産も用意しなきゃいけなくなる。最小限の組織で運用して、いざというときは自衛隊に委託する、みたいな運用であれば、じゃあ自衛隊でいいじゃん、という話になる。
自衛隊は災害派遣等は最低限にして国防に専念すべきだ、というのは、何十年前の時代に戻りそうな感じがする。国民から見えない場所で武器を使う訓練だけだと、何十万人の武器を持ったよくわからない集団、になる気がする。いろいろな災害派遣等を通して、他にも色々と人前に出るような仕事を割り当てられるようになって、ようやく最近になって国民に広く受け入れられる存在になってきたのに、上がってきた評価をまた下げてもいいんか?って。右側の人は便利使いするなと言うし、左側の人は自衛隊を人前に出すなと言うし、双方の言い分をまとめると同じ方向を向いているのはあまり良い状況とは言えない気がする。ポジティブフィードバックを放置しておくとろくなことにならない。
https://www.jstage.jst.go.jp/article/jrsj/43/3/43_43_330/_pdf/-char/ja
2023年。「衛星通信と可視光通信を複合した水中ロボットの長距離遠隔制御の実現」ファーストオーサーはソフトバンク所属らしい。
仰々しいタイトルの割に内容はうーんって感じ。30baudのOOKをWebカメラで受信して実環境で2m程度の実績。
画素(エリアセンサ)で受信すれば送受信のアライメント要求が低い、送信源が複数あっても空間的に離れていれば分離できる、みたいな利点が書いてある。とはいえ、30baudOOKじゃなぁ…… ソフトバンクみたいに金が有り余ってる会社ならもう少しマトモなコンフィグで実験すればいいじゃん、という気がする。倉庫に放置されてる機材を探すだけでももう少し良い機材があるだろうよ。イベントベースドカメラならSNRも応答速度も高いよね、とか。
そもそも、水中ロボットの遠隔制御みたいにロバスト性が重要なら、音響通信で頑張ったほうがいい気がするな。浅海域や氷海域ではマルチパス特性が悪いと言ったって、じゃあOFDMとか、方向は色々ありそう。少なくともコマンドは極端に高い伝送レートは要求されないだろうから、音響で良さそうな気がする。一つの空間に複数機を同時に動かしたいとかだと困りそうではあるけど。光通信は高速化が期待できるよね、という方向を考えているのかもしれないけど、それにしたってビークル側から映像を送らせるとかを想定するのであればWebカメラベースでは基礎実験とも言えない全く別のシステムを考えなきゃいけないだろうし。
https://www.jstage.jst.go.jp/article/jinnavi/170/0/170_KJ00005654549/_pdf
2009年。円偏波SARTとAIS-SART。
従来のSARTは水平偏波のみが認められていたが、日本からの提案で円偏波SARTを含めるように改正した。距離で1.4倍の改善効果が得られる。
別のグループが提案したAIS-SARTも同時に採択された。提案から日が浅く拙速な印象。従来SARTはトランスポンダだがAIS-SARTはトランスミッタ。日本の沿岸で考えればAIS搭載船よりレーダ搭載船のほうが多いのは明らかであって、従来SARTとAIS-SARTを併用するならいいが、コスト的には片方しか積まないはずであり、AIS-SARTを搭載しても発見される確率は下がるのではないか。
AIS-SARTの提案グループが提案時点(2005年)で考えていたかはともかくとして、最近だとAISを衛星で受信するシステムもあるし、そうなると遠洋でも衛星で受信できるAIS-SARTのほうが、付近にレーダが無いと検出できない従来型SARTより優秀という可能性もある。他の同様のシステム、例えばE-PIRBとどう棲み分けをするんだという問題はあるにしても。
元々はE-PIRBで救難信号を受信して大雑把な位置を決定したうえで、現場に向かった船舶やヘリコプターのレーダーでSARTを見つけて迅速に救助する、という運用だったはずだから、AIS-SARTならGPSでピンポイントに位置を速報できるからE-PIRBと従来SARTの2つをAIS-SARTで置き換えできますよ、ということなのかもしれないけど。その後E-PIRBにもGPSが乗ったから、結局はE-PRIB+SARTをAIS-SARTに置き換えるのではなく、新型E-PIRBに発展した感じだけど。現在使われているE-PIRBにはAISも乗っているらしいから、そういう意味ではAIS-SARTがE-PIRBに乗ったとも考えられるか。
YouTubeで再生が終わったあとに表示される動画のパネル、昔は結構大量に表示された中から適当に1個選んでたけど、最近は3個しか表示されないし、オススメの精度が悪いから、再生終了後に次の動画を気軽に探すのが難しくなった。Googleは時々頭の悪いことをやる。
わりと大手のネットメディアの記事で専門家っぽい人が書いた記事が、転載したグラフ(図)一つに感想を少し書いた記事だったりすると、なんだかなぁ、って感じがする。専門家ならせめてもう少し深い分析や解説を書いてほしいし、素人ならXあたりでやっていてほしいし。
試しに著者プロフィールを見てみたらかなり大手のインテリジェンス系の研究機関に所属しているらしくて、そういう人がこういう薄っぺらい記事を書いてるのかぁ。。。「弊社のレポートを買えばもっと細かい分析が読めるよ」ということなのかもしれないけど、記事の書き方的にはそういうわけでもなさそう。
バイクの動画で、薄曇りの日入りを背負うような状況で、ヘッドランプがユーディの光みたいな効果を発揮して完全に背景に溶け込んでいて、すげー視認性が悪い状況があった。薄曇り日入りを背負うような状況って実世界でもそれなりに多そうだけど、事故原因になったりしないんだろうか? 事故るような距離まで接近すれば路面が背景になるから問題ないとか? 背の低いスポーツカーとかから見るとちょっと厳しそうだが。あるいはカメラのダイナミックレンジの問題で見えないだけで、肉眼で見ればちゃんと見えるのかもしれないけど。
対艦ミサイルでユーディの光みたいなものってあるんだろうか? 航空機に比べれば小型な弾体をステルス化して低高度からシークラッタにまぎれて突っ込んでいく対艦ミサイルは、相対的にレーダ監視よりも目視での監視で見つかる可能性が高くなるから、弾頭の先端部にLEDなり適当な光源をつけておけばだいぶ視認性が悪くなりそう。あるいは、エアフレームの左右にもLEDを並べて、横から見たときに(艦隊の僚艦から)発見されづらくするみたいなこともできそう。
かつての対潜哨戒機と同じように、現在の対潜哨戒機でもユーディの光は便利そうな気もしないでもない。ペリスコープとかで見た程度では容易に発見されづらいように。最近は光源も小さくなってるし、適当なビームサイズに絞った光源を複数の方向に向けて設置しておいて、背景光と同じ明るさに見えるように制御する、くらいは簡単にできそうだが。
先日結構まとまった雪が降って、屋根の上に5cmくらい積もったかな。屋根の上に乗せているGPSアンテナも同じくらい雪に埋まっているはずだけど、相関強度を見る限り信号の減衰はほとんど無い。測位精度(分散)も図でみた感じは以前とほぼ違いがない。単独測位程度ならアンテナの上に多少雪が積もった程度は全く問題ないようだ。これで真冬の積雪が50cmとかまで来るとどうなるかわからないけど、とはいえその前に回収しなきゃいけないので、その状態でのデータは取れない。
車の上にGPSアンテナを乗せるなら適宜雪を落とすなり、走ればたいていは落ちるだろうし、ポール等で立てて固定点で取るにしてもそこまで雪が積もることもないだろうし、日本海側とかの極端に積雪が多くて何mも埋まるとか、あるいは過冷却で樹氷みたいに凍りつくような場所を除けば、安価なGPSアンテナ(=単周波・単独測位用)は積雪の影響は無いのかも。それに積雪や樹氷が問題になるような場所なら多少の熱源で解決できるような問題じゃないだろうし。だからヒーター内蔵GPSアンテナってのは探しても見当たらないんだろうな。
ただ、翌日になって気温が上がってくると、明らかに相関強度や捕捉衛星数が下がった。やはり水分を含むとだめっぽい。もしヒーターで溶かすにしても、水分が長期間残留しないようにかなり強烈に熱を加えないとダメそうな気がする。どうせRF系のバイアスでどうにかなるようなエネルギーじゃないから、別で電源を通してヒーターをつけるくらいなら、各自勝手にやればいいだろ、ということなのかな。
Glyphica Typing Survival、どうせ20分くらいでゲームオーバーになるやろ、と思いつつ難易度を下げて始めたら、60分を過ぎたあたりで負ける気配がなくなって、さすがに100分超えて飽きてきたので終了。最高難易度だと毎回20分あたりで敵が増えるところで終わるけど、難易度を下げると終りが見えない。
たまに使いたくなるデータ単位のキビバイト、略称KiBの気持ち悪さと言ったらクロード・リットルなみ。なんでおまえ大文字なんだよ…… 試しにCopilotにKiBの由来になった架空の人物の設定を考えさせたらスラスラ出力してきた。こういう作業は得意なんだな。
LEO適合型イベントベースドカメラと言う空想。
低軌道衛星に搭載したエリアイメージセンサを使用して地上を撮影し、画素内でアロングトラック方向に輝度情報を受け渡ししながら、輝度変化の情報を抽出する。TDI-CCD的なイメージ。
あんまり使い道が思いつかないのよな。分解能50mとして1000pxで50kmくらい、軌道速度8km/sとして6秒程度しか撮影できないから、その中で十分なイベントレートのある事象しか検出できない。さすがに厳しそう。
もう1桁、30秒とか60秒とかの窓が得られれば、例えば懐中電灯のSOSモードを軌道上から検知して、山中や海上での遭難者を宇宙から光学で探す、みたいなことも考えられるんだけど、数秒オーダーだと厳しい。それに、それ以外の用途があまり思いつかないので、衛星を打ち上げるコストを正当化できない。航空機の衝突防止灯を検出するにしても、衝突防止灯を点灯している友好的な航空機であればADS-Bも出してるだろうし、トランスポンダを適切に運用していない非友好的な航空機は衝突防止灯も適切に運用していない可能性があるし。
***
先日受信した1090MHz
Fr24でそれらしい機体は24bitアドレスが出ていて、ぐぐってみるとF-15とのこと。Frで表示されているのは1機だけだが、ガーブルの感じからして少なくとも2機はいそうな気がする。
うちで受信した中にMode-Sっぽい応答が見当たらないのが不思議。Fr24でアドレスが見えるってことは出しているはずなんだけど。
不思議な応答が出てる。かなり強いし、低spsだと綺麗な無変調信号(ガウス関数)に見える。タイムドメインで中央に変なピークが出ているけど。
*
トランスポンダに関連する資料を読んでいたら、艦載のモード1,2,3/A,C,4トランスポンダというものがあるらしい。ぐぐってみると周辺機器(コントロールパネル)の修理に関する公募が海自から出ていたので、米軍艦だけでなく海自艦にもそれに類する装置(ATCトランスポンダ)は搭載されているっぽい。艦載のトランスポンダはモードCではブラケット応答(コード0000)を返すんだそうだ。しかし、民間でのトランスポンダの使い方を考えると、結構面倒な気もするな。
民間ではトランスポンダは空港のレーダや空中衝突防止のために使われているから、船舶から応答が帰ると、航空機か船舶かを識別する必要が出てくる。船舶からはブラケットCが帰るといっても、例えばうちの周り(北海道の内陸部、海は可視範囲外)でもブラケットCらしい応答を受信できることがあるから(可能性としてはコード00または0000のモード1,2,3/Aである可能性も除外はできないが)、通常の航空機が何らかのエラー(トランスポンダや気圧計の不具合等)でモードCを返すこともあり得るはず。あるいは、気圧高度計が初期化中の場合もブラケットが出るはず。
ブラケットCを除外した場合、故障した応答を返す航空機はATCレーダ等に表示されなくなる。対地速度で区別しようにも、例えば気球に搭載されたトランスポンダみたいに対地速度が遅い空中物体も存在するから、これも難しい気がする。船舶からはモードCでGillham codeとしてあり得ないビット列を返すように規定しておけば、海上目標か航空目標かで区別するのは容易だったのにな。航空機トランスポンダは結構場当たり的に実装されている。
TCASから見ると、船舶搭載トランスポンダは高度不明の目標だから、それらは同高度に存在するとして対応する必要がある。TCASの仕様としてブラケットC(高度情報のないモードC応答)はRAは出さないけど、それでもTAは出るはずだから、艦艇搭載トランスポンダの近くを飛ぶと民間航空機にTAが出そうな気がする。
この資料にはトランスポンダのいくつかの種類についての説明も書いてあった。
IFF Mark Xが現在のトランスポンダのベースになったもので、モード1とモード3では単一パルスの応答を、モード2では2つのパルスを返すだけの機能。ただしIDENTとEmergencyも返せる。IDENTは現在のSPIとして、Emergencyはどうやって返してたんだろう? というかそもそも単一パルスを返すってことは現在のモード1,3とは全く互換性のないものなのかな?
IFF Mark X (SIF)ではコードを返す機能を追加した。これは元々のMark Xではセキュリティが低いため(容易に偽装できる)。モード1は32個の、モード2は4096個の、モード3は64個のコードを返せる(モード1は1桁目が0-7の範囲を、2桁目は0-3の範囲を設定できる)。IFF Mark X (A)ではモード3のコードが4096個に増加し、モードCが追加された。
IFF Mark XIIはMark X(SIFおよびA)と互換性があり、モード4が追加された。
Xパルスに関する説明も書いてあった。曰く「X-pulse replies are transmitted only from pilotless aircraft and are not present for mode C.」だそうで、無人航空機のモード3/AでのみXパルスが送信される、とのこと。「CにはXパルスは無い」と書いてあるだけだから、モードBやDで送信される可能性もあるけど、まあ、無いだろう。
ただしレーダースクリーンでXパルスを表示するためには、制御パネルでXパルスを表示するためのスイッチをONにしたうえで、さらに制御パネルに対象の3/Aコードを設定しなければいけないらしい。つまり特定の3/AコードにXパルスが含まれているかどうかを確認する、というような感じ。ちょっと手間を増やしてある。
7600や7700の説明によると、モード3/A専用であって、モード1や2で76や77を受信しても影響は無いらしい(そもそもモード1では76や77は出せないわけだが)。7600は軍民両用の無線故障、7700は民間用の緊急事態、みたいな説明。軍用機の場合は「7700と4Xを組み合わせて使用する」みたいなことが書かれているけど、4Xの説明は一切書かれていない。モード4のXパルス、みたいなことなんだろうか? M3/AのXパルスは緊急事態を報告するためのものではないから、M4のXは目的を変えて使われているのか、根本的に違うものなのか(そもそもM3とM4ではフレーム構造自体が違うわけだが)。
76や77を受信した際に、近距離(5マイル以内)の場合は除外するスイッチもあるらしい。プリフライトチェックで出したものを一々通知しないように、とのこと。手動で76や77を出す場合はトランスポンダが正常に動作していればそれ以上の確認は不要だろうから、それ以上のロジックがあって、それを飛行前にチェックする手順があるのかな。例えば戦闘機だと射出座席を使用した際に自動的に77が出るみたいな機能があるはずだけど、実際に射出しなくても、テスト用にトリガすることもできるんだろうか? しかし、プリフライトチェックで77を出す手順が存在していた場合、陸地に近い場所で空母を運用していた場合や、あるいは陸上の航空基地で77を出した場合は近くの空港からそれを検出してしまうから、そういうチェックはできなさそうな気がする。あくまでも遠洋に出ていて、LOS内に他のインテロゲータが存在していない場合だけ試す、みたいな感じなんだろうか?
モード4については、具体的な話はほとんどないけど、軽く説明されている。曰く、インテロゲータは4つのパルスとSLSパルス、それに続く最大32個のパルスで質問を行い、トランスポンダは3つのパルスを返す、とのこと。Mark XIIは従来のトランスポンダに質問し応答をデコードできるけど、モード4は従来のM1,2,3/A,Cとは全く互換性がなさそう。
古い資料なのでモード5の説明は一切無し。
モード4チャレンジに成功した目標は以降友好的として使われて、モード4チャレンジは行われなくなるらしい("no need"とだけ書かれている)。一方で、モード4で友好的と判断できない目標に対しては、兵器発射前にモード4チャレンジを行う必要があるらしい。この場合、FCSで自動的に判断して再チャレンジや、モード4友好的な目標に対する射撃インヒビットを追加するのか、あるいはレーダー担当官等がマニュアルで操作するのかは不明。/* このドキュメントが作成されたのが2000年頃なので、その当時の話 */
モード4の質問には一連のコードが含まれていて、トランスポンダはそのコードが正しいことを確認して応答するかどうかを判断する。コードには有効な期間(開始と終了)があるから、古いコードで質問しても応答は得られない。インテロゲータには現在のコードと次のコードを設定して、手動で次のコードを使用することもできるが、期間前に次のコードで質問することは明確に禁止されている。もし次のコードを使用した場合、適切に報告を行う必要があって、NSAまで報告が上がるらしい。敵が再利用するのを防ぐために短期間で更新してるんだから、近い将来に使うコードが流出した場合はそりゃNSAがどうにかするだろうさ。
モード4のコードは「正式な名前は無く、単に"code of the day"と呼ばれることもある」みたいに書いてあるから、1日毎に更新されるのかな。あるいは単に1ヶ月とかに比較して短いからdayと言っているだけなのか。
もし1日毎に更新されるのであれば、例えば23時台に離陸する航空機は翌日の23時台までの最大24時間程度しか有効な応答を返せないことになる。たとえ居住性の高い航空機を空中給油で長時間滞空させることができたとしても、モード4トランスポンダで作戦時間が制限される可能性がある。例えばRQ-4の場合、36時間の飛行が可能だそうだから、コード更新が24時間毎の場合、12時以降に離陸すると途中でコードの有効期限が切れることになる(ここで使う時刻はコード更新時刻を基準にしたものだから、例えば米東海岸とかグリニッジとか適当な地点で設定されるので、機体の離陸や運用地域のタイムゾーンとは無関係)。E-4は最大で72時間程度飛べるらしいから、モード4の有効期限を過ぎる可能性もあるけど、まあ、E-4クラスの機材なら空中でモード4のコードを受け取るくらいはできるだろうし……
で、モード4は3つのパルスを返すということだから、上の画像みたいな波形はモード4とは違いそうな気もする。とはいえ、このログは狭い時間ウインドウでしか記録していないから、パルス間隔が長い場合は正しく記録できない。
そもそもこんなに長いパルスを使うかな?という疑問もある。逆に、ジャミング等が行われている環境で使うことを想定すると、ある程度強い(相関性の高い)電波を使っている可能性もありそうだけど。
モード5ってモードSとADS-Bの暗号化バージョンとのことで、ADS-Bベースなら質問いらないんか?と思ってぐぐってみたら、あんまり情報出てこないけど、テスト用の機器でモード5の質問周期が明記してあるから、少なくとも質問に対してリプライを返す機能はあるっぽいな。
質問レートとしてモード5レベル1の225Hzとモード5レベル2の4Hzの2つが書いてある。225HzはモードS的なモードで、4HzはADS-B的なモードかな? ADS-Bの場合インテロゲーションは不要だけど、ADS-B In的な機材をテストするための信号かな?
*
試しに、航空機の適当な高度・速度を仮定して、固定目標に対するTCAS TAが出る確率を計算してみた(計算が正しいかどうかはわからん)
いい感じのグラフ化の方法が思いつかなかったので、とりあえずTAが発生した数を比率で表してみた。縦軸が確率、水平面はキロメートル単位であることに注意。TAの発生は確率ではなく純粋に条件分岐だが、便宜上確率として処理している。/* 速度や高度毎にTAが発生する輪郭線を書けば2次元で表現できるだろうけど、輪郭線を作る方法が思いつかなかった */
原点(左寄り奥)に航空機が存在し、右側に向かって進んでいる状態。速度は150ktから650ktの範囲を、高度は500ftから3万ftまでを計算している。500ft以下の場合はTAが発生しないので、計算には含めていない。保護領域は高度でリミットしていない(艦載トランスポンダから帰るのはブラケットCなので)。速度は日本からジェット気流に乗って東向きに飛ぶ場合を考慮して650ktまで計算している。
見づらいが、高度が低い場合は地上目標とのスラントレンジが保護領域内に入るので、地上固定目標が後方(500m程度まで)に存在する場合でもTAが発生する。高度が上がると地上目標が保護領域内に入ることは無いから、自身より後方の物体からTAが発生することはない。
前方や側方は速度によって大きく異なるが、650ktの場合、前方は最大15km(8nm)先まで、側方は最大7km(4nm)程度までTAが発生する可能性がある。
着陸進入のような状況を考えると、例えば4000-5000ft、200-300ktくらいに設定すると、側方は3km程度までTAが発生する。つまり滑走路の延長線の左右3kmの範囲にMCトランスポンダが有効な艦艇が存在していた場合、航空機上でTAが発生する可能性がありそう。
***
FM変調のやつ、71.25Mspsを0.1秒/ブロックくらいで処理していて、32bitや64bitの複素信号を扱うので、データ量が多い。ということで、メモリがボトルネックになっているのでは、という仮説のもと、処理ブロックをものすごく小さくしてみた。これでReleaseビルドで測ってみると、1倍速前後位の速度。大容量のバッファを確保した場合、2倍速程度が出るから、かなり遅くなった(一部パラメータを変えているので同条件の比較ではない)。大きなブロックで処理する場合、大容量のバッファを確保するとはいえ、ほとんどの部分はシーケンシャルアクセスだから、あまりメモリは問題ないのかも。
このPCはDDR4 3200MT/s デュアルチャンネルだから、51.2GB/sくらい流せる。1倍速なら1秒で0.5GB程度のデータ量だから、メモリ速度はあまり問題なさそう。
CPUの使用率とかストレージのバス利用率はタスクマネージャーに出るのに、RAMのバス利用率を簡単に確認できないの、ちょっと不便だよなー。普通は必要ないんだろうけど。
結論として、CPUの計算速度がボトルネックらしい。とはいえ、最終段でのメモリの読み書きを減らすと明らかに早くなるので、全く無関係というわけではないんだろうけども。あとは、ブロックサイズを適切に小さくするのも、やはり効果があるらしい。
ブロックサイズを1桁ずつ切り替えて、入力サンプル数48よりは480、4800よりは480のほうが処理が早い。480サンプルは10msecに相当するので、出力サンプル数は0.7215Mpts、32bit複素数なので6MB弱、最終LOも同数なので12MB、CPUのL2にはギリ、L3にはおそらく十分に入る、くらいの大きさ。やはりCPUの外に押し出されると遅くて、極端に小さいとオーバーヘッドが大きい、というような感じになるんだろうか。
そもそも、Intelの最近のやつだと、L1とL2はコア単位、L3は全コア共有、表示される容量はL1/L2共に全コアの合計、のはずだから、例えばL2が12MBで物理コアが12個の場合、1MB/コアだから、キャッシュ内に収めようとするとその程度(かつ他の処理で食われる分)に収める必要があるから、結構小さい処理単位じゃないと厳しそう。
*
CICは微分器や積分器があって演算結果を戻すような構造になっているから、無限インパルス応答だと思ってたんだけど、実際には有限インパルス応答と考えていいらしい。
CICインターポレーションに適当なステップ応答を突っ込んでみると、出力側から見て(N-1)(R-1)サンプルで静定する(0オリジンで(N-1)(R-1)番にR^(N-1)が出てくる)から、入力側から見ればN-1ポイントを入れてやれば良いようだ。N≧Rの場合はN-1ポイントを突っ込むと1ポイント分余計に計算してしまうけど、ブロックサイズが十分に大きければ無視できるし、そもそもほとんどの場合CICはN<Rで使うだろうから、問題ないはず。今回の場合も、N=5, R=125みたいな条件。
CICデシメーションの場合は入力側から見てN*(R-1)ポイントで静定するので、ブロックごとに分割して(CICをリセットして)処理する場合は先に前のブロックの最後のN*(R-1)ポイントを突っ込んでおけばいい。
CICをブロックごとにリセットして、リセットしただけの場合と、前のブロックのラストNポイントを読ませた場合で比較
N=5, R=20のCICインターポレーションを使用。入力の青と、出力の橙(リセットだけ)、緑(リセット後にNポイントを入れて静定)。緑はちゃんと連続しているように見える。
そんな感じで、最終段のCICと複素積をマルチスレッド化すると、デバッグリリースだと12スレッドで1.25倍速、リリースビルドだと5スレッドで3.22倍速、くらい。シングルスレッドだと2倍速くらいだから劇的に高速化というわけではないけど、少しは早くなる。
タスクマネージャーで見るとストレージへの書き込みが800MB/s程度で安定してほぼ100%に張り付いているから、もしかしたらストレージがボトルネックになっている可能性もある。
試しに出力フォーマットを2xF32から2xU8に変えて帯域幅を4分の1にしたら、リリースビルドで9スレッド7.91倍速くらいまで出た。ストレージもだいぶ余裕がある。さすがにそろそろCPUがネックかなと思いつつ、タスクマネージャーで見る限りはCPUもまだまだ余裕がある。並列化しているのは最後のCICと複素積だけだから、その前がネックなのかも。
ただ、全体的にマルチスレッド化(周波数変調部はシングルスレッド処理)しても、大して早くならない。SSDへの書き込み速度がネックになっている感じ。試しにファイルへの書き出しをコメントアウトしてみると、11倍速くらいまで出る。その場合、CPU使用率は90％あたりで安定するから、マルチスレッド化はある程度効いてる。
各処理の同時に走っている数
FIRがBPF、CIC補償とプリエンファシス、CIC1で48ksps→570kspsへレート変換、freqModで周波数変調、CIC2で71.25Mspsへレート変換(含複素積)、という感じ。
最終段のCICが14スレッドくらい並列で走っている。FIRと初段CICも最大で3,4スレッド出ているから、一応並列処理が効いている。
周波数変調は前のブロックと位相連続性が必要だから、並列処理はできない。
ブロックサイズは10msに設定しているけど、100msに変えると12倍速くらい出るから、若干なりとも早くなる。シングルスレッドでの処理とマルチスレッドでの処理では最適なブロックサイズは異なるらしい。
スレッドのハンドリングはもう少し効率化できるだろうけど、全体的なパフォーマンスとしてはこのあたりで頭打ちかな。CICを最適化するとか、あるいはNを減らすとかすれば多少は早くなるだろうけど。
CPUをほぼ100%使って10倍速程度ということは、実速度(例えばWAVをリアルタイムにFMステレオ変調してfl2kへ吐く)の場合ならCPU使用率は10％程度で済む。シングルスレッドで走らせるには厳しいけど、最終段CICだけマルチスレッド化する程度でも十分に処理できそう。シングルスレッドでも運が良ければ1-2倍速は出るけど、あまり余裕がないので、CICのマルチスレッド化は効果がありそうな気がする。
大量のデータを適当にスロットリングしつつパイプライン処理して、各ステージはシングルスレッド専用もあれば複数スレッド同時処理できるものもあって、結果は順番通りに吐き出して、みたいな処理、C#だとRxでやればいいじゃん、みたいな話なんだろうけど、とはいえRxってイマイチ概要が見えてこないんだよなー。
今回は最終段CICだけマルチスレッド化する予定だったので、適当なクラスを作って、allocで取った領域に書き込んで投げてしばらく待ったら結果が出てきて、その領域は読んだあとにfreeで捨てて、みたいな感じで、あらかじめ確保したメモリを使うように処理していた。これをパイプライン処理全体に使おうとすると、大量のメモリコピーが発生する。でも結局Observerパターンを実装してもそのあたりは自前で書かなきゃいけないんだよな。データ処理はデータ処理に専念して、作業領域の管理は呼び出し側で頑張るほうが楽そう。
0 件のコメント:
コメントを投稿