2017年12月29日金曜日

Mk41

 Mk41 strike-lengthを紹介するPDFを簡単に訳してみました。
 よみづらいけどごめんね!


Missiles
SM-2
Blk II
VLA
ASROC
種類 対空 対潜
最大重量(kg) 707.6 635
最大長(m) 4.76 5.08
最大直径(mm) 355.6 355.6
トマホーク
AUR
シースパロー
VL/RIM-7
種類 対地/対水上 対空
最大重量(kg) 1814.4 244.9
最大長(m) 6.27 3.86
最大直径(mm) 584.2 203.2
システムサイズ - 61Cell 発射機
長さ 8.71m
6.32m
高さ 7.70m
発射機 RM&A - 8Module 発射機
平均故障間隔 1936時間(80日)
平均修理時間 3.2時間
平均保守時間 30分/1日
intrinsic availability 0.978
ストライクダウン
平均失敗サイクル
200
必要な電力(61Cell VLS 発射機)
440Vac 60Hz 3phase 200kW
115Vac 60Hz 1phase
(lighting)
8kW
115Vac 60Hz 3phase
(backup power for 440Vac)
10kW
115Vac 60Hz 1phase
(発射制御装置)
5kW
115Vac 400Hz 3phase 45kW
必要な船舶からのサービス
低圧空気 1.5MPa  
淡水 210リットル  
海水    
  Deluge 1.2kL/毎分 at 0.73MPa
  散水 4.0kL/毎分 at 0.5MPa
  排水 5.2kL/毎分  
冷却 40kW  
加熱 20kW  
環境条件
発射機内の条件 13℃/95%RH
から
30℃/55%RH
システム重量
空の発射機 117t
空のMk13キャニスターとアダプター 178t
61発のSM-2 Blk II 217t
48発のSM-2 Blk IIと
13発のトマホーク
230t
空のMk22キャニスターとアダプター 195t
VL/RIM-7 210t
キャニスター重量
Mk13
  空 675.9kg
  SM-2 Blk 2(ミサイルのみ) 1383kg
  PHS&T (空キャニスター) 1211kg
  SM-2 Blk 2とアダプタ 1800kg
Mk14
  空 912kg
  トマホークAUR 2726kg
  PHS&T (空キャニスター) 1424kg
  トマホークAUR(sill assembly) 2781kg
Mk15
  空 757kg
  VLA 1497kg
  PHS&T (空キャニスター) 1293kg
  VLAとアダプタ 1769kg
  VLA(max, growth)とPHS&T 2032kg
Mk22
  空 966kg
  VL/RIM-7 1216kg
  PHS&T 1501kg
  VL/RIM-7とアダプタ 1497kg
発射制御システムの寸法と重量
ステータスパネル
  長さ 29.12cm
  幅 45.72cm
  高さ 60.96cm
Remote launche enable panel
  長さ 20.32cm
  幅 25.4cm
  高さ 33.02cm
発射制御装置
  長さ 86.36cm
  幅 111.76cm
  高さ 203.2cm
ストライクダウンの重量
strongback, horizontal transfer assembly 95.7kg
vertical strongback 21.3kg
Cell guide assembly 23.1kg
Steady rest assembly 24.5kg
Pivot fixture 167.4kg
Beam weld steady rest 74.4kg
Beam weldment locator receiver 136.6kg
Lift adapter, truck assembly 128.8kg
Chock 60.3kg
Other assemblies 110.2kg
Total 842.3kg
安全性
restrained firing
拘束されたミサイルの完全なモーター燃焼で
生き残ることができるランチャー
warhead deluge
弾頭の爆発を防ぐために提供される洪水
(1.21kL/min at 0.7MPaゲージ)
* トンはlong ton(英国トン)を使用
* PHS&T:Packaging Handling Storage and Transportation


 このPDFでは、タイコンデロガ級を基準としているようです。タイコンデロガ級は、前後に8モジュール(64セル)のMk41を搭載しており、全体で122セルがあります。前後共にストライクダウンクレーンがあり、これが3セル分を占めているのはアーレイ・バーク級フライトII以前と同様です。

 Missilesの重量は、ミサイル単体の重量かな?wikipediaによると、RIM-66の重量は707kgだそうで、PDFの値と一致しています。


 RM&AはReliability, Maintainability and Availabilityの頭文字で、"信頼性、保守性および可用性"みたいな意味だそうです。8-Module Launcherとのことなので、61発分のランチャ全体の話だと思います。平均して80日に1回は前後どちらかの発射機の修理が必要になる、みたいな意味かと。また、この際は3.2時間の修理が必要になるということでしょうか。
 intrinsic availabilityってどういう意味だろう?単位が書いてないので何かの比率だろうけど、何の。
 ストライクダウン平均失敗サイクルというのは、ストライクダウンクレーンで失敗する確率でしょうか。200回に1回失敗する。でもちょっと位置合わせに失敗したくらいならやり直せばいいだけで、カウントはしないでしょうから、何らかの致命的な失敗のカウント?200回に1回、ミサイルを破損させるような失敗をする、とか。でもこの値ってどれくらい信用して良いんだろうか。ストライクダウンって統計取れるほど使ってるのかなぁ。


 電力はいまいちよくわかりません。


 圧縮空気が1.5MPa必要だそうです。Low-pressureと書いてありますが、日本で言うと法規制される高圧です。何に使うのか不明。空気だから排煙に使うのかなーと思うけど、でもそれなら流量も併記されてるはずです。
 水は何に使うのか不明。淡水は流量が書いてないので、そんなに大量に使うものではなさそうです。
 海水は流量が書いてあるので、それなりに大量に必要になるんでしょう。
 
 冷却は高温地域、加熱は寒冷地での温度制御だと思います。おそらくVLS発射時に冷却が必要な場合は、水が使われるはずです。


 環境条件は、これもよくわかりません。
 発射機内がこの範囲に収まる必要がある、ということかな?セルではなく、発射機全体っぽいです。主に船舶のエアコンで制御する数値でしょうか。


 重量はいろいろ書いてありますが、大きく分けてシステム重量とキャニスター重量があります。他にサブシステムの仕様にもかかれていますが。
 こまかく計算していくと、だいぶ計算が合いません。ま、あんまり細かく考えないように。。
 キャニスターは、SM-2がMk13、トマホークがMk14、VL ASROCがMk15、VL/RIM-7がMk22、となっているようです。中身(ミサイル)に合わせてそれぞれ作っているのでしょう。
 strike-lengthとtactical-lengthではセルの長さが違いますが、tactical-lengthでもMk13キャニスターの重量は変わりません。wikipediaのイラストではtactical-lengthにはSM-2は入らないような感じですが、実際には搭載できるようです(追記:SM-3と取り違えてました。あと最後にもうちょっと書き加えています)。キャニスターの長さは共通で、より大きいVLSに搭載する場合は、キャニスターの下にゲタを履かせているのでしょう。とはいえ、排煙の経路だったりが必要なので、単純な高さ合わせだけでは足りないと思いますが。


 安全性の項目は2種類書いてあります。

 一つ目は、何らかの理由でミサイルが発射されずに、ランチャー内でモーター(固体燃料ロケット)が燃え尽きても、危険にはならないことが求められています。
 ミサイルに限らず、固体燃料は燃焼温度がとても高く、運動エネルギーも大きいです(熱エネルギー/運動エネルギーが高いほど、高性能)。例えばH-IIAに使われるSRB-Aの燃焼温度は3000℃を超えるそうです。ミサイルのモーターは、ブースター等であれば燃焼時間は数秒ですが、SM-2のメインモーターのような、デュアルスラスト型では燃焼時間は40秒ほどあるようです。
 「3000℃のガスを40秒浴びても抜けない防火壁」というのを考えてみると、かなり大変な要求だと思います。そもそも3000℃というのが想像の埒外ですね。

 もう一つは、弾頭の爆発を防ぐための仕組みだそうです。原文では"prevent warhead explosion"とあるので、耐爆ではなく、防爆を指しています。
 おそらく、キャニスター内でモーターが燃焼して弾頭が加熱されて自然発火/起爆することを防ぐための機能でしょう。大量の水をキャニスターに流し込んで加熱を防ぐ、ということだと思います。
 1.2kL毎分、0.7MPaというのは、"船舶からのサービス"の海水のDelugeを使うのでしょう。Deluge、洪水や氾濫という意味だそうですが、キャニスター内を洪水にしてしまう、という用途でしょう。
「上は洪水、下は大火事ってなーんだ」
「Mk41に装填されたMk13でモーターが異常燃焼してる状態!」
 上っていうか、キャニスター全体が洪水ですけどね。
 当然ですが、SM-2のブースター/メインモーター、VLAやトマホークのブースターが燃えても、水をかけても消化は不可能です。発泡系の消火剤でも同様です。これは固体燃料の中に酸化剤が含まれているからです。逆に、トマホークのジェット燃料が漏れて燃えている場合は、ある程度の消化が期待できます。

***

 ということで、簡単にMk41のことを書いてあるPDFを読んでみました。A4紙で1枚分程度ですし、4分の1はイラスト(解像度低くて数値読めない!)なので、情報量はあまり多くないですが。

 昔、ディスカバリーチャンネルだったかでアーレイ・バーク級の建造を手伝う、みたいな番組があったはずなんですが、再放送してないっぽいです。見たいんだけどなぁ。Mk41の設置作業とかやってた気がします。
 ナショジオのライリーは修理中!もそうですが、向こうの番組は「手伝いに行く」というテイが多いですよね。日本でもこういうのやらないかなぁ。


追記:2017/12/30
 イージス艦辞典47pに各キャニスターのイラストがありますが、ここにはSM-2MRとSM-2ERの2種類が書かれています。SM-2MRはtactical-length(図中ではlengthではなくmodule、以下同様)の長さで、SM-2ERはstrike-lengthです。
 おそらく、strikeのPDFに書いてあるMk13キャニスターはSM-2MR専用のものだと思います。
 wikipediaの図は左から3番目がSM-3とSM-2ER、右から3番目がSM-2MRで、SM-2MRサイズはMk13、SM-2ERサイズはMk21だそうです。PDF翻訳しなくてもwikipediaに書いてあったよorz この図、見覚えあるから読んでるはずなんだけどなぁ。。。

2017年12月28日木曜日

Iron palette

 いつも起きるの遅いから、乱数の試行回数を増やして寝たら、今日に限っていつもより早く起きてしまい、プログラムが終了していない。ということで、amazonでハイエナ・ロードを見て終了待ち。いやぁ、切ない映画だ。
 primeに登録してから、最近見た映画はprimeばっかりだなぁ。最近聞く音楽もprimeばっかりだし、嗜好がamazonに制御される。

***

 さて、本題のIron palette。前回、最後にちらっと書いた、「正弦波2個じゃなくて、正弦波1個と直線で良いんじゃね?」をやってみました。



 いい感じです。
 FLIRのスペクトルとよく似ているので、FLIRも正弦波+直線で作っているのかもしれません。

 正弦波2個を作るには、パラメータが4+4で8個必要でした。正弦波1個だと、パラメータは4+2で6個で済みます。3割ほど、パラメータで使うROM領域が少なくて済みます。96byteが72byteになったところで、誤差の範囲ですけど。チープな組み込みなら24byteも大きいですが、なら三角関数とか使うな、という話で。

***

 C# src

public class Iron_palette
{
    protected const float R_f = 1.5879f;
    protected const float G_f = 4.2124f;
    protected const float B_f = 2.2251f;

    protected const float R_p = 3.161f;
    protected const float G_p = 0.8156f;
    protected const float B_p = 3.1285f;

    protected const float R_g = 0.4042f;
    protected const float G_g = 1.0976f;
    protected const float B_g = 1.9342f;

    protected const float R_o = 0.0027f;
    protected const float G_o = -1.5174f;
    protected const float B_o = 1.9635f;

    protected const float R_a = 1.9869f;
    protected const float G_a = -0.1639f;
    protected const float B_a = 2.2419f;

    protected const float R_b = -3.9506f;
    protected const float G_b = -0.17f;
    protected const float B_b = 0.1099f;

    public static Color to_color(double value)
    {
        if (value < 0 || value > 1)
        {
            throw (new ArgumentOutOfRangeException());
        }

        return (Color.FromArgb(
            (int)(
                (Math.Sin(value * R_f + R_p) * R_g + R_o) *
                (value * R_a + R_b) *
                255),
            (int)(
                (Math.Sin(value * G_f + G_p) * G_g + G_o) *
                (value * G_a + G_b) *
                255),
            (int)(
                (Math.Sin(value * B_f + B_p) * B_g + B_o) *
                (value * B_a + B_b) *
                255)));
    }
}

2017年12月24日日曜日

Iron palettes

 FLIRの画像でよく使われる、青紫っぽい熱画像のスケール。

 熱画像だと、温かいところが赤、冷たいところが青、中間が緑、というのがよくあるが、これは輝度と値が比例しないので、慣れないと理解しづらいという問題がある。また、印刷する際にカラーで印刷しないと情報が失われてしまうので、紙ベースで処理してコストを気にするようなところでは、モノクロで印刷しても情報が失われないIron paletteのほうが良い。輝度と値が比例するので、慣れていなくてもぱっと見て理解できる、という利点もある。


 javascript - Thermal imaging palette - Stack Overflow
 適当な大きさのパレットで持って、中間は補完しろ、みたいなことが書いてある。

***

 色をグラフ化すると、なんとなく波形っぽいので、とりあえず正弦波で近似してみた。


 1色あたり、8個のパラメータが必要になる。C#で乱数を作って、FLIRの画像から取り出したスケールとの差を最小になるパラメータを書き出した。500万セットくらい乱数を作っているが、5分位で処理できる。アルゴリズム上の問題で500万セットくらいしか処理できないが、アルゴリズムを修正すれば寝てる間に500倍くらいの乱数セットを処理できそう。
 ただ、今は1色ごとをFLIRの値と比較しているが、本来であれば輝度へ変換した上で、輝度のリニアリティを優先するべき。このあたりは追々。


 値から色に変換するには、値を0-1で正規化して、(sin(値*周期1+位相1)*ゲイン1+オフセット1)*(sin(値*周期2+位相2)*ゲイン2*オフセット2)で計算できる。

 上記のパラメータではこんな感じ。


 かなり綺麗に表現できてる気がする。
 三角関数が6個必要なので、組み込みだと計算負荷が高め。ま、組み込みでこういうスケールが必要な事態は少ないだろうし、問題ないはず。PCとかで処理するなら、三角関数で好きなだけ分解能を増やせる。

 緑の片方はゲインが0に近いので、正弦波5個で計算できるかも。


 最初はパラメータを手動で設定していたけど、乱数で設定したら簡単にそれっぽい値にできた。それなりに時間はかかるけど、放置しておけば終わるので楽。
 もうちょっと色々試してみる予定。


追記:2017/12/25
 アルゴリズムを変えて生成してみた。



 微妙に直線性が悪い気がするのと、グレーがなんとなくガタガタしてる気がする。
 とりあえず0で輝度が10%、1で輝度が85%になるような値になっている。0が完全な黒ではなく、1も完全な白ではない。背景が真っ黒のページにグラフを表示しても境界がわかりやすいし、真っ白な紙に印刷しても同様。
 なんとなく1側が青白くて、輝度が低い気がする。

 とりあえず以下のソースコードは別言語への移植も含めて自由に使っていいです。完全無保証無サポートですけど。あとFLIR Systemsとかに怒られても知らないけど(あ、怒られたら怒られたって教えてくれると助かります)。

 C# src
public class Iron_palette
{
    protected const double R_f1 = 0.5107;
    protected const double R_f2 = 0.6085;
    protected const double G_f1 = 2.9332;
    protected const double G_f2 = 0.0599;
    protected const double B_f1 = 4.6611;
    protected const double B_f2 = 0.646;

    protected const double R_p1 = 1.0094;
    protected const double R_p2 = 2.8977;
    protected const double G_p1 = 1.193;
    protected const double G_p2 = 0.8202;
    protected const double B_p1 = 1.5839;
    protected const double B_p2 = 1.0357;

    protected const double R_g1 = 3.8616;
    protected const double R_g2 = 2.3461;
    protected const double G_g1 = 4.2843;
    protected const double G_g2 = 0.2103;
    protected const double B_g1 = 2.7105;
    protected const double B_g2 = 1.6943;

    protected const double R_o1 = -3.2597;
    protected const double R_o2 = 2.1916;
    protected const double G_o1 = -4.9513;
    protected const double G_o2 = -0.2657;
    protected const double B_o1 = 2.8918;
    protected const double B_o2 = -1.4018;

    public static Color to_color(double value)
    {
        if (value < 0 || value > 1)
        {
            throw (new ArgumentOutOfRangeException());
        }

        return (Color.FromArgb(
            (int)(
                (Math.Sin(value * R_f1 + R_p1) * R_g1 + R_o1) *
                (Math.Sin(value * R_f2 + R_p2) * R_g2 + R_o2) *
                255),
            (int)(
                (Math.Sin(value * G_f1 + G_p1) * G_g1 + G_o1) *
                (Math.Sin(value * G_f2 + G_p2) * G_g2 + G_o2) *
                255),
            (int)(
                (Math.Sin(value * B_f1 + B_p1) * B_g1 + B_o1) *
                (Math.Sin(value * B_f2 + B_p2) * B_g2 + B_o2) *
                255)));
    }
}

 それぞれの三角関数の値。左上の、ガタガタしてるのはFLIRの画像から拾ってきた輝度。


 ざっと眺める感じ、1個の直線+1個の三角関数、で近似できそうな気がしてきた。Rs2はほとんど直線っぽいし、Gs2もほとんど直線。Bs2は微妙に曲線だけど、これくらいなら直線で近似できるんじゃないかなぁ。
 あとで片方直線、片方三角関数、でパラメータを探ってみよう。
 何かのシミュレーション結果をIron palettesで動画化する場合、4k動画なら1枚で約50M回のsin計算が必要になる。60fpsで1分の動画なら180G回のsin計算が必要になる。これが半分になれば結構大きい気がする。

しきさい&つばめ



 2017/12/24 12:30:00 JST

JS Orbit

 43065/82AがGCOM-C、43066/82BがSLATS、それ以外の3個がH-2A DEBです。
 とりあえず衛星名はこれで確定じゃないかなーって気がします。

 82CがH-2Aの2段目、82Dがつばめ搭載アダプタだと思います。82Eもデブリですが、以前に公開されたJAXAのシーケンス動画ではGCOM-Cの付近にはデブリはありません。このあたりはGCOM-Cの動画だと何か書いてあるかもしれません。


 とりあえずはしばらく待ちの体制です。次のネタはSLATSの高度が下がってからになるかな。

2017年12月23日土曜日

しきさい&つばめ


 結構前にTLEが更新されていたみたいです。

 JS Orbit

 今回の打ち上げでは、"しきさい"と"つばめ"の他に、ロケットボディと"しきさい"を載せる円筒形のアダプタがあります。
 43065/82Aか43066/82Eのどちらかが"しきさい"だと思います。
 他に43066/82Bと43067/82C、43068/82Dがあります。おそらくDが"つばめ搭載アダプタ"、B/Cのどちらかが"つばめ"、もう一方がロケットボディ、だと思います。

 軌道投入される物体は衛星2個、ロケットボディ、アダプタの4個のはずですが、実際には5個の物体が登録されています。
 A/Eはかなり近いので、"しきさい"に関係する部品なのかもしれません。あるいは5個の内のどれかが偽データか。


 最近はTLEのグラフ化をやっていませんが、つばめはダイナミックに高度が変わるはずなので、ある程度データが溜まったらグラフ化もやってみようと思っています。近いうちにSS-520でTRICOMも打ち上げられますから、そちらも合わせて。

CIWS

 CIWS ファランクスの制御方式とか。

 ファランクスは戦闘機に搭載されていた、M61バルカン ガトリング砲をベースとして作られたシステム。バルカンの下に弾倉、上部に火器管制レーダー、更にその上に捜索用のレーダーが搭載されている。
 レーダーはどちらもKuバンド(12-18GHz / 25-16mm)帯を使用している。捜索レーダーは5.6km、追尾レーダーは4.3kmの探知距離と言われている。
 使用する弾薬は20x102mm弾を使用する。これは戦闘機に使用される一般的な種類。薬莢長こそ対物ライフルや重機関銃の12.7x99mm弾と近い大きさだが、弾丸の長さは倍程度の違いがあり、直径が大きいことから、装薬量も大幅に増やせる。
 ファランクスの銃口初速は1.1km/s程度、有効射程は1.5km程度。弾丸が最大射程まで到達するには1.7秒くらいか?

 ファランクスの制御は、クローズドループフィードバックで行われている。撃った弾丸をレーダーで追尾し、目標との差を計測し、それを補正した上で次の弾丸を発射する。
 この場合、弾丸の追尾の方法によって、制御分解能が変わる(レーダーの角分解能を無視する場合)。
 弾丸の未来予測を行わない場合、目標と同じ距離にある弾丸と目標の差と、その弾丸を発射した際の照準を使用し、次の射撃の諸元を得る。この場合、最大射程で撃つと、最初のフィードバックは1.5秒後くらいになる。ファランクスは毎秒75発以上を発射するから、最初の110発程度は無駄打ちになってしまう。
 弾丸の未来予測を行う場合、弾丸の未来位置はある程度物理法則に忠実だから、目標と同じ距離に達した際の位置を計算することができる。ある程度の距離を飛んだ時点で、例えば最遠500mとした場合、7割程度の性能改善が見込める。
 クローズドループではある程度の時定数が必要だから、無闇矢鱈と連射速度を上げればいい、というものでもない(VADSのように適当にバラけさせて撃つなら、高連射速度は意味があるかもしれないが、当のVADSもかなり発射レートを下げてるから、あんまり意味ないのかも)。

 ファランクスで200m/s程度の目標を迎撃する場合、射撃機会は7.5secほどになる。弾倉は20sec程度の容量だから、2-3回程度の迎撃で弾倉がカラになる(早い時点で迎撃を終了する、あるいはある程度接近してから迎撃を開始するなら、5-10回程度)。複数のファランクスを並べれば、飽和攻撃で撃ち漏らした目標を迎撃するのにはいいかもしれない。しかし、一時期はアーレイ・バーク級でもCIWSを減らしたこと、最近では飽和攻撃を食らう危険が減っていること、を考えると、あまりCIWSを増やしたところで、導入・維持コストがかかるばっかりになってしまう。


 前回のエントリでもちらっと書いたが、「最強の装備」を考える場合、ただ単に火器を増やせばいい、という話ではない。VLSを増やしたところで、レーダーやイルミネーターの性能が変わらなければ、飽和攻撃を食らった際の能力は変化しない。長射程のミサイルを追加したところで、それを観測する手段がなければ、宝の持ち腐れになる。
 また、あまりに過剰な装備の搭載は、初期コスト・運用コストの増大という結果を招く。コストを考えないなら、いくらでも自由に装備を追加すればいいが、そんなことをするなら「研究開発にコストを回せ(未来装備の実用化)」という話になってしまう。
 他にも、あまりに大きな火力を持つと、政治的な問題を引き起こす可能性もある。
 「最強の装備」を考えるときは、コストや政治的な面、用途や使用頻度、と言った点を踏まえ、また、本当にその重量を艦に搭載できるか、と言った点も考えてみると、面白いはず。もっとも、「そんなのは俺の勝手だ!」と、好きなように盛るのも、それは個人の自由なのだが。

スタンダードミサイル

 他人の妄想に突っ込むのは野暮だと思うけど。

 スタンダードミサイルにはいくつかの種類があります。
 代表的なところでは、SM-1, SM-2, SM-3, SM-6です。それぞれサブモデルが存在し、場合によっては魔改造を受けて艦対空ミサイルから空対地ミサイル(性格には空対レーダーミサイル)にされた、というモデルもあります。が、今回は扱いません。

 SM-1はRIM-66 SM-1MRと、RIM-67 SM-1ERの2種類があります。同様に、SM-2はRIM-66 SM-2MRとRIM-67 SM-2ERの2種類があります。SM-3はRIM-161 SM-3、SM-6はRIM-174 SM ERAMの、それぞれ1種類ずつです。
 型番から分かる通り、SM-2はSM-1のサブモデルという扱いです。
 ではSM-1とSM-2は相互運用が可能かというと、そんなことはなく、SM-2は撃てるがSM-1は撃てない、というプラットフォームがあります。


 とりあえず先にMRとERの違いを説明しておきます。
 MRはMedium Rangeの略、ERはExtended Rangeの略で、それぞれ中距離、長距離の意味です(たいてい、ミサイルの最初か最後についてるERは長距離型の意味が多いです。SM-6ERAMのERも長距離の意味です)。
 基本的にMRもERも同じ弾体を使用しており、ERにはブースターが追加されている、という点が異なります。

Standard Missile

Standard Missile-2 on launcher, National Museum of Nuclear Science & History  

 この2枚の写真は、上がSM-2MR、下がSM-2ERです。ERのほうはMRの倍くらいの長さがあります。ERの後ろの青い部分がブースターで、これが付いていれば長距離型(ER)、なければ中距離型(MR)です。


 さて、SM-1とSM-2の違いについて。
 SM-1は全期間に渡り、セミアクティブレーダー誘導です。一方、SM-2は慣性/指令誘導による中間誘導と、セミアクティブレーダーによる終末誘導の組み合わせになります。
 全期間でセミアクティブによるロックオンが必要なSM-1では、ミサイルの発射前からロックオンしておく必要があります。そのため、発射する前からミサイルを目標へ指向しておく必要があります。これは、旧来の旋回式発射機では特に問題にはなりません。
 一方、SM-2は慣性誘導による中間誘導が追加されたため、「とりあえずこの方向へ飛んでいけ(ロックオンは後でやる)」という指示を与えるだけで発射することができます。この方式では、発射時にはロックオンする必要がない、というのが直接的な利点ですが、同時にミサイルを目標に指向しなくてもいいという利点があります。中間誘導の採用には同時に飛行できるミサイル数が増えるという利点もありますが、一番大きな利点は、この好きな方向に撃っておける、という点にあります。

 旋回式発射機は、発射前に目標に指向できるという利点がありますが、逆に目標に指向するまでの時間がかかるという欠点も生み出します。また、発射機は前甲板に1基、後甲板に1基、合わせて2基程度しかありません。万が一敵の攻撃(艦砲やミサイルの破片等)が発射機に命中した場合、その発射機が使用できなくなる危険があります。それでなくても、機械的なトラブルで攻撃力が半減、あるいは全滅といった事態になる危険性があります。
 これらの欠点を解決できるのが、Mk 41を始めとした垂直発射システム(VLS: Vertical Launch System)です。VLSであれば、ミサイル1発ごとに発射機1個が割り当てられている、と考えることができます。そのため、発射機1個が使えなくなっても、戦力の損失は100分の1程度に抑えることができます。また発射の指向が不要なので、準備ができ次第、次々と発射できます。他に、甲板上の発射機が無くなることによるステルス性の向上、セル(発射機)がカバーに覆われることにより被弾時の被害を抑えられる、といった利点もあります。
 もちろん、VLSにも欠点がないわけではありません。一番大きな欠点は、発射時はミサイルが上を向いており、発射時にはロックオンできない、という点です。この欠点は「発射前にロックオンが必要」というミサイルにのみ発生することであり、どの方向にでも撃てる(後からロックオンできる)慣性誘導を使用すれば、この欠点は存在しません。

 ということで、SM-2の中間誘導はVLSから発射するために作られた能力、とも言うことができます。もちろん、イルミネータの専有期間を減らして同時に発射できる弾数を増やす、飛翔経路を最適化して射程を延長する、といった利点もあるのですが。


 ここまで読んでくれば、「VLSからSM-1, SM-2, SM-3を撃てるようにしよう!」という「僕の考えた最強の戦闘艦」は実現不可能なことがわかると思います。もちろん、SM-1に中間誘導能力を追加すれば可能ですが、そんなことをするよりもSM-1を捨ててSM-2に絞ったほうが楽です(SM-1に中間誘導を追加したのがSM-2なのですから)。
 場合によっては、SM-2でも限定的ながら弾道ミサイル防衛が可能ですから、SM-3すらも捨てることもできます。まぁ、この場合はSM-6に一本化したほうがいいのですが。

 以上、SM-1とSM-2の違いとかの話でした。


 なお、上では書いていませんが、VLSの欠点は他にもあり、一旦真上に飛び出てから向きを変えるため、あまりに近い目標に対しては発射できない、という欠点があります。
 このため、RAM(Rolling Airframe Missile)は旋回式発射機を使用しています。一方で、同じ個艦防空に供されるESSMはVLSから発射されます。初期のRAMは最短射程0.8km、最大射程が9km程度だそうです。VLS方式に由来する最短射程は5km-10kmくらいかな、と思います。
 RAMは旋回式発射機に特有の、指向時間という問題がありますが、基本的にRAMは最後の砦であり、RAMの前にESSMやSM-2による迎撃を試みています。例えばSM-2で迎撃できずにESSMが必要になった場合は、RAMを使うことに備えて旋回を開始する、といった運用にすれば、ESSMの結果を待つ間に旋回を行えるはずです。
 高速な対艦ミサイルが低高度で接近してきた、という場合は旋回が間に合わない可能性もありますが、その場合はVLSから発射しても姿勢変更が間に合わない距離のはずです。

***

 最強の戦闘艦を作るにはどんな装備があればいいか、というネタは面白いのですが、最近は複数の戦闘システムを組み合わせて能力を拡張する、という方向に発展しています。例えばSM-6では水平線以遠まで発射できますが、当然水平線の向こうはイージスのレーダーでも見えません。この場合、目標を探すにはE-2等からのデータリンクを使用します。そのため、SM-6の射程を活かすにはE-2のような観測手段が必要であり、E-2を運用するには陸上の飛行場か、洋上の航空母艦が必要になります。そうなると、戦艦○○にVLSを追加する、という話では済まなくなります。

「僕が考えた最強の戦闘艦」という妄想を行う場合、どういう制約を課すか、といった事も決める必要があります。例えば、「仮想装備も使える」という、いわば「現代兵器縛り」を外した場合、光速で攻撃できるレーザー(光学)兵器が最強の装備になってしまいます。攻撃されたことがわかるのは攻撃を食らってからですし、予防的な回避行動も意味ないのですから、光学兵器が最強なのは当然でしょう(ま、銀を蒸着するとかいろいろ対応はできますが)。
 逆に、「現在実用化された装備のみしか使えない」となった場合は、タイコンデロガ級やアーレイ・バーク級といった、現存する戦闘艦の中で一番強いのはどれか、という話になってしまいます。
「僕が考えた(ry」なので、このあたりはてきとーに縛ったり、緩めたり、自由にすればいいのですけども。。
 とはいえ、やはり「最強の戦闘艦」では、現在でも戦闘艦単艦では能力が不足している以上、単艦では「最強」とはいえなくなってしまいます。そうすると、最強の組み合わせは何になるか(空母にE-2を載せてタイコンデロガにSM-6とトマホークを満載、とか)みたいな話になってしまいます。
 面倒くさい。。。(by コンゴウ)

***

 なお、ここに書いたことはwikipediaからてきとーに拾ってきて自分なりに咀嚼した情報なので、間違ってたらごめんなさい。(おまじない)

2017年12月17日日曜日

あなたが落としたのは

 金の斧ですか? 銀の斧ですか?
 それとも、このハイカーボンスチールを鍛造した斧ですか?

 正直者のあなたにはこのハイカーボンスチール鍛造の斧を差し上げましょう。あなたが落とした方の斧ですか? 見つけられませんでした。。。
 このようなものは受け取れない? ご安心を、親戚筋の鍛冶屋が時々送ってくるのです。ウチは石油ストーブにしたばかりで…

 ***

 という電波を受信した。

 どうも、お久しぶりです。生存報告まで(というほど開いてないけど)。

 最近は見てないけど、ナショジオの工業系番組で工具とか紹介するときは、ほとんど高炭素鋼だよね。高炭素鋼を讃えよ! あ、いや、叩けよッ! 鉄は熱いうちに!

2017年12月12日火曜日

HIP

 ここ何日か、他のことにかまけてジンバルが全く進んでいません。はやく再開しないとソースコードの読み方忘れちゃう。。




 青が人工衛星、赤が恒星です。
 恒星もマウスオーバーで名前が表示されますが、星の名前のデータベースを探してくるのが面倒だったので、とりあえずヒッパルコスカタログのIdを表示しています。

 天球の方位は、0時が北、3時が東、という感じです。実際、TLEでは東の静止軌道がスカスカになっています。
 一方、北を0時、東を9時で表示するプラネタリウムソフトと、この図の星の配置が一致します。ということは、恒星位置は東西が逆に処理されている可能性が高いということです。


 今のところ、右画面でHIPを表示すれば連動して左画面でも表示されてしまいます。しかし、この挙動はかなり使いづらいです。例えば、右画面は衛星だけ、左画面は恒星だけ、といった表示ができれば使いやすい気がします。
 とはいえ、そうするとContextMenuItemの使い回しができないという問題が出てきます。もしかしたらDeepCopyとか使えばなんとかなるかな?
 開発PCはディスプレイが広いので、2画面だけじゃなく、他にも色々表示させたくなります。例えばADS-Bを表示する予定がありますが、天球にADS-Bを表示するのと、PPIに表示するのと、他に恒星や衛星、コンフィグ画面等で、6画面くらい欲しくなります。
 4k液晶なら18枚くらいは余裕で表示できますが、ノートPCだと2画面が限界です。
 FormにMFDを1個だけ配置して、必要なだけWindowを表示する、という方法もありますが、そうすると上記のそれぞれでモードを切り替える、というのが面倒になります。
 このあたりはうまいやり方を探す必要がありそうです。

 あと、表示の座標もちゃんと確定しておく必要がありますね。
 戦闘機のディスプレイなら北が0時、東が3時が自然だと思いますが、今回は高仰角がメインの用途なので、上から見下ろした表示は向かないかもしれません。
 他にも、ジンバルが向いている方向が6時になるような表示とか、そういうのも欲しくなります。
 とはいえ、あんまり複雑にすると作るのが大変だし、という問題なども有って、後回しになっています。後回しにすると、修正作業が大変になって、結局途中で辞めるという結果になりそうな気も。
 行き当たりばったりはダメですね。

2017年12月10日日曜日

メモ:SketchUpで面が切断される




 SketchUpを使っていると、上の画像のように、物が切断されて表示されてしまうことがある(時空が乱れた感じ)。
 根本的な解決方法は見つけていないが、とりあえず、ツールバーのカメラ→視野を選択し、視野角を狭くすれば多少改善する。
 ただしこの方法では遠近感が変化してしまうので、イメージ図を作ったりといった場合は、適切な視野角に戻すこと。


 根本的な原因は、3Dグラフィックでは、"最短撮影距離"と"最遠撮影距離"というものがある(名前は間違えてるかも)。最短撮影距離はカメラのレンズにもあるが、それとは全く別の問題。
 コンピューターグラフィックスでは、あまりに遠い物体は「遠すぎて見えないはずだ」という仮定に基づいて、描画処理を省略する。見えないものの色や影を計算したところでリソースの無駄だからね。
 同時に、あまりに近すぎる物体も、画面に表示しきれないし、ポリゴンの粗さが目立ったり、いろいろな理由により、描画を省略する。

 SketchUpの場合、最短撮影距離が長すぎるので、視点で物体に近づくと、物体の描画が省略されてしまう。視野角を変更すると、同じ範囲を描画するのでも、カメラの位置が変わり、視野角を狭くすれば、カメラを遠くに配置する必要があるから、最短撮影距離を相対的に縮めることができる。

 あまりにも視野角を小さくすると、パースペクティブが無くなり、平行投影に近づいていく。とりあえず、18度とか15度くらいがいいかな、という感じ。
 裏技?として、視野角を170とかにすれば、魚眼レンズで撮影したような感じになる。もちろん、時空の乱れはより悪化するが。

イージス艦のCICのスケール

USSTiconderoga(CG-47)CIC

 タイコンデロガ級イージス巡洋艦1番艦 CG-47"タイコンデロガ"のCICの写真。
 1984年3月1日、あるいは1984年3月13日17字29分撮影(前者はファイルの説明に書いてあった日付、後者はディスプレイに表示されている日時)。


 左から2番めのディスプレイ、AAW(対空戦闘)の状況表示だが、レンジは256NM(海里:ノーティカルマイル/Nautical Mile)と書いてある。
 レバノンで作戦行動中の写真だそうだ。
 ということで、ほい、レバノン周辺の衛星写真。


 黄色い円は、半径256海里の円。おおよそ、ディスプレイに表示された海岸線と一致している。
 ということで、RANGE SCALE 256NMというのは、「半径256NMの円に内接する正方形の範囲」(正方形:ディスプレイのアス比に依存?)という感じらしい。対角で512海里、辺方向で約360NMの範囲を表示している?


 表示されたアイコンは海軍戦術情報システム(NTDS: Naval Tactical Data System)に準拠しているが、wikipediaのアイコンとは違い、単色で表示されている。
 味方は円、的は辺が斜めな正方形、敵味方不明は辺が水平・垂直な正方形、中立は辺が水平・垂直な多角形、で表示される。
 海軍のシステムなので、洋上目標(船舶)が基準。船なら円形、航空目標なら円の上半分だけ、水中目標なら円の下半分だけ。ミサイルなら噴射炎っぽい記号が増えたり、ヘリコプターならローターっぽい記号が増えたり。魚雷は円形に水平線が追加される。魚雷は水中目標ではなく、水面目標の扱いになってる。地上目標はクロスで表され、仲間はずれ感がすごい。
 上の写真では、マップに水上目標や空中目標がいくつか書いてある。地上目標のアイコンもある。いくつかの空中目標は破線で表現されてるけど、どういう意味なんだろうか。
 ASWディスプレイでは、対潜戦なので水上だと思うんだけど、水上にも地上目標のアイコンが有る。あと円形の味方や正方形のアンノウン以外に、斜め四角の敵アイコンもいくつかある。

 ASWディスプレイはスケール64海里で、海岸線の形からして、左上はキプロス島の半島の付け根南側で、右下の線はレバノン南西部(中西部?)の海岸線と思われる。画面の中央部大部分は洋上で、画面の中心は34d8'N、34d24'Eあたりかな。
 左上の海岸線上から伸びる線は長さが25海里くらいかな?25海里/1分なら約2800km/h(1500kt)、25海里/5分なら約550km/h(300kt)、25海里/10分なら約280km/h(150kt)くらい。
 同じ画面の洋上目標は、最大で3分の1くらいの長さなので、それぞれ500kt、100kt、50ktくらいか。船舶と考えると、アーレイ・バーク級で最大30ktくらい、フリーダム球でも最大50ktくらいなので、80年台前半ということを考えると、もっと遅くても良さそう。となると、30分後として30km/h(16kt)とか、長いやつは90km/h(50kt)とか? でもたかが100km/hでこの長さだと、イージス艦のコンセプトだった、対艦ミサイルの迎撃とかをやろうとすると、線の長さはこの10倍くらいになってしまう。

 必要に応じて速度スケールは変更できるのかもしれないけど、それにしては速度の説明が書いてあるようには見えないし、そもそも頻繁に変更しては状況認識に問題がありそうだから、ちょっと考えづらい気がする。

 うーむ、謎は深まるばかり。。。

2段ベッド


 2x4材で下にテーブルの入ったベッドを作ろうと、いろいろ考えています。こういうのって正式名称はなんていうんだろう? 上下で寝るわけじゃないから2段ベッドじゃないし、空間的には3段分あるし。

 今使っているベッドも、形状は同じ感じですが、下側の空間がうまく活用できていません。ということで、まるっと作り変えてしまえ、と思い始めました。
 ということで、少し大きめの机にして、死蔵してる24インチを1枚出してきて、全体で3面ディスプレイにできないかな、と考えています。GTX950とGT520の計2枚差しだけど、3画面ってできるのかな? できたとしても、GeForceって1GPUでマルチディスプレイを組むと変なエラッタが出たはずだけど。
 探せばもう1枚くらいGT520出てくるはずなので、どうせWebブラウザやメディアプレイヤーくらいしか使わないから、PCI Ex x1でも問題ないと思ってますが。グラボ3枚差しかぁ。すげーな。内2枚はGT520だけど。


 SketchUp上で見ると、はしごがかなり邪魔っぽいですが、実際の位置関係で柱の横に座ってみると、あんまり気にならない感じです。顔から柱まで40cmくらいあるので、多少圧迫感があるかな、という程度。どうしても気になるなら、2ディスプレイにして余裕のある配置にしてもいいですし。

 寝る部分は、一応せん断応力を減らすような組み方にしています。すのこ状のフレームも上下に重なった形状にして、圧縮応力になるようにしています。が、youtubeの動画とか見てみると、みんなビスのせん断方向で作ってるんだよなぁ。意外とビスって高強度なのかもしれません。でも心配なので、やっぱり圧縮で作りたい感じです。
 四隅で圧縮ですが、すのこは2x4と2x6をそれぞれ2本ずつ縦で支えてるので、耐えれるはずです。本来は破壊試験とかして勘所を掴んだほうがいいんでしょうけど。
 一方で、はしご部分はビスのせん断だけで支えています。寝るところが落ちるとPCとか損失が大きいですが、はしごが壊れても自分が落ちるだけだし、はしごに乗ってるときはある程度即応でバランスを取れるだろう、という期待もあります。重心を考えると確実に自由落下で背骨から落ちるんですけどね。
 あとスノコは静荷重ですが、はしごは動荷重なので、はしごのほうが強度的には厳しいです。また外側に引っ張られる方向の荷重があるので、ちゃんと作るなら、踏み台が柱の向こう側になるように作るべきかな、という気もします。まぁ、それは壊れたときに考える、ということで。古いハシゴとか釘2本で止まってたりしますしね。多分そこまで気にすることじゃないんでしょう。


 SketchUpなので、日照のシミュレーションができます。今の案では、10月から4月あたりまで、モニタ上に日照があります。カーテン閉めるなりすれば多少は改善するでしょうし、イザとなれば黒い模造紙でも窓際においておけば、入射エネルギーは熱に変換しつつ、十分遮光できそうな気がしてるのと、それでもダメならアルミ蒸着シートを使えばいいだけなので、この部分はあまり気にしていません。
 それよりも、現状の窓際に机を配置していて、寒気が入ってくる、というほうが厳しいです。左右が板で囲まれ、窓際はサッシの隙間があって、直接足に気流が来る配置なので、かなり寒いです。


 ということで、目標は寒い時期に間に合うように作ることですが、どうなるかなぁ。
 材料はホーマックで買えますし、垂木でエアガンのターゲットを色々作ったときに買った卓上丸ノコがあるので、材料の切断も気軽にできます。
 ということで、ベッドを分解して搬出し、新しい材料を搬入して組み立てて、を1日でやりきる覚悟ができれば、いつでもできるはずですが、その気になるまでが大変だなぁ。
 一応、PCやHDDレコーダーも移動する予定ですが、これは現状の配置のままでもベッドを入れ替えるのはできるはずなので、そのあたりはあんまり心配していません。心配事があるといえば、3ディスプレイ化とかするとコンセントが圧倒的に足りない、というくらいでしょうか。ただでさえ古い家でテーブルタップ大量に使ってるのに。。。
 そういえば、小学生の頃は切り売りの電線と埋め込みのコンセントを買ってきて配線したりしてたので(どんな小学生だw)、ベッドにコンセントを大量に生やしてもいいんだな。机の天板はコンパネを使う予定ですが、奥の隅はディスプレイを斜めに置くので、デッドスペースになります。その部分に穴を開けて、コンセントを設置するとか。まぁ、法的な云々は置いておいて。。。


 上の図ではPCだけですが、他にもHDDレコーダやXbox 360を置かなければいけませんし、近いうちにXbox Oneも買う予定なので、そのスペースも作る必要があります。しかし机の上はかなり厳しい感じで、かと言ってスノコの下の空間を使おうにも、そこも厳しそうな気がしています。じゃぁ足元かというと、あんまり足に近いところに置くと蹴飛ばしそうで怖いです。
 あとせっかくなので、寝ながらにして手が届くような棚もほしいなぁとか、色々要求が増えています。

***

 まだ先の話ですが、中華CNCを買おうかと思っています。amazonで3万円くらいで売ってる、CNC2417とかですね。しかし、今はどこにも置くスペースが無いのと、買っても使うかなぁ、という心配が有って、かなり消極的です。
 でも、ベッドの下の空間を有効に使えるようになれば、空いたスペース(今PCを置いてる位置)にCNCを置けるくらいの空間は確保できるはずなので、そうなったら買いたいなぁって。

F-16風(続きのつづき)


 とりあえずジンバルのコントローラを作っています。
 いちおうTLE(人工衛星)とHIP(恒星)のボタンがありますが、HIPは未実装です。

 MENUを押せばメニューページになり、天球表示以外にコンフィグ画面があります。コンフィグは今のところシリアルポートの接続/切断だけです。ポートの選択とかは別のタブに作っています。

 TLEをONにすると、直下にあるテキストファイルに入っているすべての衛星が表示されます。今のところ1800個ほどでしょうか。1800個のTLEの 位置計算、方位仰角計算、Graphicsへの書き込み、をやっても、10-25msecくらいしかかかりません。衛星1個あたり10マイクロ秒で計算してる、ということでしょうか。確かに衛星の計算って複雑なだけで計算量は多くないんだけど、いくらなんでも早すぎでしょ。ARMだと、計算だけでも1msecかかるのに。

 天球全体で見てみると、静止軌道がかなり濃い感じです。しかし、東側は太平洋上なので、静止衛星は少ないですね。

 ディスプレイにマウスカーソルを重ねると、一番近い衛星の名前が表示されるようになっています(左側のディスプレイにカーソルを重ねています)。
 今のところ、ディスプレイをクリックすれば、無条件にジンバルがその方向を向きます。本来であれば、マニュアル操作ならジンバル指向、TLEモードなら衛星を選択して継続追尾、HIPモードなら恒星を選択して継続追尾、みたいな感じにするべきでしょう。


 衛星1800個ならテキストファイルでも500KiB未満ですから、SDカードに楽勝で入ります。HIPカタログもテキストデータですが、恒星約12万個分でも容量は50MB程度です。SDカードに余裕ですね。
 TLEの計算自体はマイコンでできることも確認済みなので、スタンドアロン動作は問題ないはずです。恒星位置の計算はマイコンではしたことないですが、あまり計算量は多くないですし、衛星ほど素早く動くわけでもないので、なんとかなるでしょう。


 TLEは、一応、データ長は固定ですが、衛星番号は間欠なので、衛星番号から直接ファイル位置を計算することができません。一番簡単なのは、TLEフォルダに、TLE1個毎に衛星番号をファイル名にしたファイルを1個ずつを作る、という感じになると思います。FAT16なら6万個くらいファイルを作れるらしいので、デブリとかを除けば、十分収納できます。

 HIPは空白埋めの固定長なので、特定のデータを取り出すのはそれほど大変ではないはずです。HIPもやはり間欠データですが、12万セットに対して100セット程度の不足なので、HIP番号を受け取って、目的のデータが来るまでファイルの前方にシーク、という程度でも問題ないはずです。もしそれが許容できないなら、ヌル行を追加したテキストファイルを作ればいいだけですし。


 ということで、なんとなくコントロールソフトも見た目はちゃんとしてきました。でも、かなり面倒です。
 最初は「参照渡しだから1個作れば複数の表示ができるね!」と思ってたんですが、その方法では、片方でズームするともう一方もズームする、という感じで、かなり使いづらいです。一応、表示内容は別々に選べるので、それだけが救いです。
 しょうがないので、ディスプレイごとにインスタンスを作って、別々にズーム・移動ができるようにしましたが、個別に登録しなければいけないし、UIハンドラも個別に作る必要があるので、面倒です。

 あと、MFDからペイントイベントを受け取ったら、現在表示中の画面のレンダーを呼び出して、そのレンダーは表示内容に応じて下位レイヤーのレンダーを呼び出して、という感じになっています。
 下位レイヤーでは、例えば天球レンダーからTLEレンダーを呼び出した場合、衛星位置は天球レンダーの表示位置に応じて衛星位置も表示することになります。しかし、天球を拡大しても、フォントは拡大されずに常に同じ大きさで表示する必要があります。さもなくば、天球を拡大すると、衛星名が画面の外に飛び出してしまいます。これは衛星のアイコンも同じで、ズームしても衛星のシンボルは一定の大きさで表示されたほうが便利です。
 ということで、衛星の位置を表示する際は上位レイヤーの座標変換行列を使い、衛星の名前を表示するときはスケールが違う行列を作り、という動作が必要で、しかも衛星の情報(軌道高度とか)は画面の左上とかに固定されたほうが読みやすいでしょうから、そういう表示は新しく行列を作って、という感じの処理を、都度書く必要があります。
 これがかなり手間なので、もっとスマートな方法を使いたいのですが、なかなかいい方法が思いつきません。

 こういう処理は、例えばUnityの3Dゲームが近いかな、という気がしています。ゲームフィールドは3Dで表示し、キャラの名前等は相対位置で2D表示し、ステータス等は絶対値で表示し、という感じで。
 ということで、ゲーム制作関係の参考書とかを読めばいいのかな、とも思ったりしますが、多分Unityは抽象化しすぎて参考にならないでしょうから、ゲームエンジンを作るような本が必要なのかな。


 そういえば、F-15ってASAT兵器を使えるけど、MFDに衛星を一覧表示したりするんだろうか?イージス艦もやはり対衛星ミッションを行っているから、衛星の表示もできるはずです。
 F-15の場合は、飛行前に地上で目的の軌道を入力して、飛行時はそれ以外の物は表示されないようなインターフェースになってるはずです。ASATの試験はF-15Aで行われましたが、一人乗りで操縦しながら衛星を選択するとかは大変ですし、そもそもF-15Aに気が利いた表示ができるシステムを載せれるとも思えないし。

 イージス艦の場合は、NTDSのアイコンで目標の速度や移動方向がわかるようになっていますが、低速なヘリコプター等も表示することを考えると、同じスケールでマッハ25とかを表示すると、速度スケールが画面外に出てしまい、かえって速度がわからなくなってしまいます。低速な目標から超音速ミサイルまでを表示したりすることを考えると、速度スケールは対数スケールかな、という気もしますが、常識的に考えれば、こういう表示は「何分後の未来位置まで引いた直線」とかでしょうから、やはり対数スケールってことは無いでしょう。
 例えば5分後の未来位置なら、ISSの場合は5分で日本列島縦断するかしないかくらいなので、1画面で日本を端から端まで表示できるイージス艦のディスプレイなら、衛星も十分に表示できそうな気がします。
 特に弾道ミサイルを追尾できるイージス艦では、ミサイルの現在位置、落着予想地点、迎撃までの猶予、といった情報を表示する必要があるので、少なくともBMDの際の意思決定が問題なく行えるくらいの表示はできるはずです(って、何日か前にもこんな話書いたな)。

 イージスのCICで衛星がどのように表示されるかなんて、わざわざ隠すことでもないでしょうが、かと言って、わざわざ表に出すことでもないでしょうから、当分は見れないだろうなぁ。最近だとICBMとか色々で、イージスで宇宙空間見ることも多いだろうし、センシティブな話題だろうからなぁ。

2017年12月8日金曜日

F-16風(続き)


 24インチFHD(本物の3割増しの大きさ)でスイッチを押してみたけど、意外と押しづらかったのでボタンを大型化したのが前回からの見た目の違いかな。前回はclassだったけど、UserControlになってたり、いろいろ変わってるのだが。

 ボタンの表示や操作内容はContextMenuStripで渡すが、C#は参照渡しなので、複数のパネルで同じ内容を表示できる。1箇所でも違う内容を表示したいなら面倒だけど。
 本物のF-16等でも、左右のMFDで全く同じ内容を表示できるので、複数のパネルで操作できるのは実物準拠という感じ。実機の場合は、もし片方が壊れても大丈夫なように、万が一片方が被弾しても大丈夫なように、という事なんであろう。

 ただし、片方のpaintイベントがもう片方に波及しないので、片方でCheckedを変えたりしても、もう片方は反映されない。paintハンドラでもう片方をrefreshすると、無限ループになってしまうので、うまいやり方を考えないと。
 現実的には、ディスプレイの内容は20fpsとか30fpsで書き換えることになるだろうから、タイマで定期的にrefreshすれば無問題、という気がする。

 1280x800のノートPCでは、ディスプレイを2面表示することは可能。
 左右で別の情報を表示するようなインターフェースにしてもいいし、片方を情報表示、片方をコンフィグページ、みたいにしてもいい。

 ジンバルのコントロールパネルを作ってるが、マニュアル操作をどうするかが問題になってる。アナログ入力があればいいんだが、C#で簡単に使えるアナログUIは意外と少ない。Xbox360のコントローラであればXNA経由で使えるが、すでに入手性が悪くなってる。Xbox oneもXNAから扱えるんだろうか?
 一応C#でもジョイスティック等は読み出せるが、製品によってボタンやスティックの割当が違うから、このあたりをうまく吸収してくれるように作る必要がある。


 さっき、一瞬、F-15のディスプレイも調べてみたが、あまり良くわからなかった。
 F-15A/B/C/Dはいかにもなアナログ計器のコックピットだが、F-15Eではグラスコックピット化されている。
 EF(E型フロント席)はMFD3面と、HUD下に6行キャラクタディスプレイがある。ER(E型リア席)はMFD4面と、右側に小さなパネルがあるらしい。ERは兵装士官(WSO: Weapon Systems Officer)が乗るが、戦闘機とは思えないくらい簡素化されてる感じ。操縦桿があるのが飛行機らしい点。もっとも、F-35は電源OFFならのっぺらぼうだが、アレは「そういうもの」という思い込みがあるし。

 F-15の操縦桿には親指で操作する「キャッスルスイッチ」という物がある。滑らないようにする突起が、西洋の城の見張り台(身を隠す突起があるやつ)に似ているから、「キャッスル」スイッチと言うんだそうだ。
 ゲーム用のジョイスティックでは、ここにはPoVスイッチ(あるいはハットスイッチ)と呼ばれるスイッチが付いていて、主に視点操作に使われる。これは基本的に「開放」と「操作」の2値を受け付ける(開放と8方向で9値?)。
 F-15では、これはFLIRの視線方向操作に使うらしい。ということでゲームと同じく視点操作なのだが、ON/OFFで望遠のFLIRを操作するのは大変だろうから、おそらくアナログ入力になっているはず。
 一方で、操縦桿にはハットスイッチみたいなスイッチがもう一つ有って、これはトリムの調整に使われるらしい。これはアナログ入力が必要なほど敏感じゃないはずだから、2値(9値?)で足りるはず。


 ジンバルの操作でも、やはりアナログ入力がほしいのだけど、どうやって作るかなぁ。
 スタンドアロン重視ならマイコンにジョイスティックを追加すればいいんだけど、PS2のコントローラに入ってるようなやつでは気分が出ないし、かと言って工業用のタイプになると値段が2桁上がってしまう。
 F4ならUSBホストもハードウェアでできるけど、USBを実装するのはとても面倒くさい。気がする(USBって使ったこと無いので不明)。
 適当なUSBジョイスティックのXYをC#で読めばいいじゃないか、とも思うけど、せっかくジョイスティックを使うならHOTASっぽくしたい。スロットルデバイスは持ってないから、HOSになっちゃうけど。

 他の方法としては、JHMCS風の「見た方に向く」とか、短SAM風の「覗いた方に向く」とかもあるけど、どちらも作るのは面倒そう。

 当面は、MFDで「アナログモード」みたいな設定を作って、それがtrueのときにMFD上を左クリックしたままドラッグしたりすれば、それが入力になる、みたいな感じかなぁ。
 PC画面なら本物のMFDと違って、画面座標の直接入力が可能だけど、あんまり多用しすぎるとプログラムが大変になる。
 これはF-35でも同様なはず。もっとも、F-35は振動や加速度の条件が厳しい戦闘機のシステムだから、「振動で指が動いてしまった」とかで誤った入力にならないように、フリックやらスワイプやらの操作は無いらしい。ということで、画面をタッチした座標と、単押しか長押しか、くらいの判定しか無いはず。

 暖かくなるまでに動くようになればいいから、とか余裕かましてたけど、大変そうだ。

2017年12月7日木曜日

F-16風の


 F-16のMulti Function Displayっぽい画面をC#で作ってみました。もちろんボタンは操作可能です。


 F-16のMDFを調べてみると、Honeywellの表紙含めて4p分くらいのPDFが出てきました。日付は2006年になっています。

 F-16A/Bではコックピットにはレーダー/HUDレピータのディスプレイが1基と、兵装用の9セグ(12セグ?)LEDx5行のディスプレイが使用されているようです。
 F-16C/D(Block 25)では単色のディスプレイ2枚に置き換わり、多用途化されたようです。さらにBlock 5xではこれが多色化されたようです。
 UAEに輸出されたF-16E/F(Block 6x)では大型のカラータッチ液晶を搭載したようですが、写真を見つけられませんでした。大型タッチ液晶というと、同じロッキード・マーティンのF-35が思い浮かびますが、おそらく同じようなものだと思います。


 先のカタログはカラーMFDのものですが、解像度は480x480pxで4x4インチだそうです。密度的には、24インチFHDの3割増し、18.5インチFHDや13.3インチWXGAくらいです。11年に買ったノートPCが13.3インチWXGAなので、民間の普及品よりちょっと高密度、くらいでしょうか。
 ただしコントラスト比は航空機用だけあり高く、5750対1らしいです(読み間違えてるかも)。また輝度も非常に高く、約790cd/m^2だそうです。参考までに、この間買った4k液晶(HDR非対応)は300cd/m^2でした。
 また、戦闘機では夜間はナイトビジョンゴーグルを使用しますが、新月の星明りだけで敵の戦闘機を見つけれるくらいの高感度なものですから、直接高輝度な画面を見てしまっては簡単にリミッターが働いてしまいます。なので、バックライトにも相当なダイナミックレンジがあると思われます。カタログにも「under all lighting conditions, from night-vision goggles to full sunlight」と書いてあります。簡単に訳せば、「直射日光から暗視装置まで、どのような光環境でも」みたいな感じでしょうか。

 液晶の起動には1分@-20℃と、ちょっと時間がかかります。とはいえ、ウチの液晶でも冬に1日家を開けて室温が10℃を下回ってしまうと、自己発熱でコントラストが正しくなるまではしばらくかかりますから、-20℃で1分というのはかなり優秀かもしれません。ヒーターでも入ってるのかな。

 この液晶は13ポンド(約6kg)のモジュールですが、映像を生成するシステムが他に必要になるようです。映像を生成するモジュールは31ポンド(約14kg)で、メインのシステムにはPowerPCベースのカスタムCPUが使われているようです。クロックは400MHz、メモリは4MB(8MBまで増設可能)、バッテリーバックアップされた64MBのメモリ(オプション)、といった感じで、更にグラフィック用に240MHzのPowerPCが乗っていて、こちらは32MBのRAMと16MBのFlash、16MBのテクスチャメモリと15MBのフレームメモリが乗っているそうです。
 メインの計算モジュールより描画モジュールのほうがメモリが大きいあたり、グラフィックの負荷がいかに高いかが伺えます。
 この描画モジュールはC言語で開発されているようです(C言語で開発可能、の意?)。メインシステムはJOVIALとCだそうです。JOVIALは聞いたことも無かったのですが、F-15やC-130、F-117等、かなりいろいろ使われているようです(wikipediaで、プラットホームに、other legacy systemsと書いてあって笑ってしまった)。

 このシステム、5GB(拡張可能)のストレージを持っており、航空機に搭載したままで書き換えが可能なようです(地上で整備士が書き換える、くらいの意味でしょう)。

 地図の倍率は125万分の1と50万分の1の2段階を選べるようです。125万分で127km四方、50万分で約51km四方、くらいの範囲を表示できます。125万分は巡航で9分、50万分は同4分くらいの距離でしょうか。50万分では1pxあたり100mくらいですから、遷音速なら1秒に3ピクセルくらいの分解能です。
 CASに使うには50万分では荒いし、洋上に出て迎撃するには125万分でも狭いし、みたいなとても使いづらそうな気がしますが、そもそもF-16のコンセプトからすれば、これくらいでも問題ないのでしょう。
 表示モードは北が上、ヘディングが上の両方を選べるようです。

 インターフェースはNTSCといった身近な物がある反面、MIL-STD-1553が5本入力可能だったりと、軍用な面もあります。また、イーサーネット100BaseTでデータ通信ができたり、デバッグ用に10BaseTが付いてたりもするそうです。

 他にも、画像をアップロード/ダウンロードする機能があったり、地形を3Dレンダリングで表示できたり、といった機能もあるそうです。


 興味本位で見つけたペラッペラなパンフレットくらいのPDFですが、真面目に読んでみるといろいろおもしろいですね。

***

 さて、一番最初のC#のヤツですが、コントロールではなく、クラスとして作っています(後から気づきましたが、これはコントロールとして作るべきでした)。
 コンストラクタにはContextMenuStripを与えており、ボタンで操作できる項目はVisualStudioのGUIで編集可能です。
 もちろん項目のボタンを押せばその下の階層に移動できますし、上に戻るタグを付けておけば勝手に階層を遡ってくれます。
 今のところ、ボタンの数(20個)以上の項目が有った際は、それ以上は表示しない、という挙動です。ContextMenuStripは動的に生成可能ですが、動的に作って20個超えても知らないよ、というスタンスです。
 クラスの中でClickハンドラを追加して移動していますが、もちろん外部でClickを登録しておけば、それに応じて処理もできます。
 またMDFの描画イベントを外にも出しているので、必要に応じて外部で描画できます。同時に現在選択しているToolStripMenuItemも参照できるので、外部はそれに応じて描画内容を変更する、という動作にしています。

 もともとは気分転換に作り始めたGUIですが、タッチ液晶で使えば意外と便利そうな気がします。
  もうちょっと色々使いやすいようにして、FSXの情報を表示したり、ジンバルの制御ソフトに組み込んでも面白いかな、と思っています。


追伸
 Arma3でマップに使えるアイコンみたいなやつ、MIL-STD-2525Bという規格らしい。2013年にオープンソースとして開放された模様。

 Test Multipointをクリックするとアイコンが表示される。

2017年12月6日水曜日

星座の境界

 星座(天球を88分割した領域)の境界線データ。

 IAU(国際天文学連合)のページに有る。
 The Constellations | IAU
 Charts and tablesにTXTというリンクがあるが、これに境界線の赤経赤緯の点がリストになっている。

 図にするとこんな感じになった。


まぁだいたいこんなもんかな、という感じなので、大きく外してはいないはず。
 最初は4等星より明るい星を表示してたけど、6時/20度の領域に1個も星がなかったので、4.5等星以上に変更した。この領域ってこんなに星が少ないところなのかな。

 それにしてもこの分割、怪しい古代文明の遺跡にある扉の鍵みたいな感じだ。88個のカケラを集めなければ入れないボス部屋、とか。

 星座の星をつなぐ線のリストとかもほしいけど、どこにあるんだろう。プラネタリウムソフトによって表示が違うので、統一したデータとかはないのかもしれないけど。

2017年12月5日火曜日

じんばる

 ファームウェア・コントロールソフト共にジワジワと進化しています。


 とりあえず天球を上下2分して仰角と俯角の表示をつけています。あと影になってるけど、モーターの速度を表すグラフもあります。
 他にいくつかのパラメータを設定したり、RTCを設定する機能とか。
 TLEの指定はコントロール側にはつけていませんが、ファームウェアでは実装済みで、ターミナルソフトを使えば指定できます。RTCで現在時刻を基準に計算できますが、観測地点はまだべた書きの状態です。TLEと観測地点をコントロール側で指定できるようになれば、最低限使えるようにはなります。

 とりあえず仰角と俯角の図は同じ大きさですが、基本的に俯角で使うことはないので、このあたりはもうちょっと工夫したいところ。
 あと天球図は色々機能を追加したいです。例えば可視の人工衛星を表示したり、スターカタログを表示したり、それらをクリックして目標に指定できるようにしたり。
 ただ今回はスタンドアロンで動くことを主目的としているので、PC側のソフトばっかり強化するのもなぁ、と思っています。ま、結局メイン機材はWebカメラなので、PCは必須になるんですけども。

 前回作った時は、マイコンはステップ位置を受け取ってモーターをその位置に指向するだけの機能でした。それ以外の計算はすべてPCで処理していたので、自然な流れでコントロールソフトが肥大化していきました(プラグインとして実装して、TLEやスターカタログ、ADS-Bをデータソースとして使えるようになりました)。ただ、そのときはSTM32F1の84MHzだったので、あまり凝ったファームウェアは動かないだろう、という予想があったので、PCメインとしました。
 今回はSTM32F4の上でC++で書いているので、ある程度複雑な処理も可能になっています(フルスペックのC++じゃないので、制限も大きいですが。new deleteが使えないとか)。自前で計算できるので、TLEやスターカタログなら(データの読み込みを別にすれば)スタンドアロンで処理できます。一方で、ADS-BはPCのサポートが必要になりますし、満足なUIを作るにはやはりPCで作るのが楽でしょう。

 そういえば、Cortex-M4FのSTM32F4とはいえ、実際はdoubleのソフトウェア演算ですから、実質的にはSTM32F1との違いはクロック周波数だけのはずです。で、衛星位置の計算が1msec未満ですから、F1でも2msecで計算できるはずです。ということは、STM32F1でも十分にスタンドアロンで衛星を追尾できそうですね。


 開発環境は4k液晶ですが、実運用のときはノートPCを使う予定で、画面解像度は1280x800です。なので、制御ソフトもその大きさで足りるように作る必要があります。今の制御ソフトがだいたいそれくらいの大きさなので、コレ以上は大きくできません。
 パラメータ画面とか、目標選択画面とか、タブにわけるにしても、かなり狭い気がします。天球を表示してスターカタログとか衛星をクリックできるようにするには、かなり心もとない解像度ですね。

 例えば初期のイージス艦は、おそらく低解像度なブラウン管の見づらい画面なわけですが、その画面でも最大で200個程度のターゲットが表示される想定のはずで、そういったときに必要な情報を表示できるようなインターフェースというのが作られているはずです。高度や速度の情報を含め、脅威度の推定とかも適切に表示できているはずですが、どうやってるのかなぁ。
 もっとも、その表示がうまくできなくて民間人およそ300人の犠牲が発生してしまった、といえるのかもしれませんが。実際、当該機が上昇しているにも関わらず、それを監視していた乗員は降下していると判断した瞬間がありました。ということは、その時点でのイージス艦では、そのあたりの情報は人間が判断しづらい表示だったということでしょう。


 とりあえず、実際に運用に入るのは暖かい季節になってからですから、しばらく時間があります。その間にいろいろと考えてみようと思います。

メモ:軌道計算のコスト

 STM32F4でTLEの計算、最低限方位仰角を計算するのに1msec未満@168MHz。ここからジンバルの補正とかが必要だけど、そんなに計算コストは高くない。ただしISSの軌道なので、離心率が大きい軌道では収束まで時間がかかるから、もうちょっとかかるはず。
 STM32F4はFPUを内蔵しているが、それは単精度で、軌道計算には全く足りない。例えばTLEは時間を日単位で与えられるから、年末になると精度は80秒程度に悪化する。8km/sec*80sec=640kmの誤差となり、高さ400kmに対して誤差が大きすぎる。
 そこで今回はすべての計算をdoubleで行った。本来は精度が不要な部分をfloatにするといった工夫をすべきだが、今回は動作確認が最優先。それでも1msec以内に計算できるので、しばらくはこのままで。

 ワンチップで軌道計算ができるので、あとはGPSで自分の位置と時間を得て、SDカードからTLEを読み出せば、スタンドアロンで軌道計算を行える。TLEはSDカードに入れるようになるはずなので、数日置きに更新する必要がある。場合によっては、FlashAirでWiFi経由で更新させたり、TCPに対応させたりできるはず。僻地に設置して使うなら、イリジウムのSBDでもTLEの更新には十分。そんなところに置いてどんなミッションができるかという問題はあるが。
 TLEは衛星打ち上げ情報部分を除いてアルファベットは不要だから、テンキーとスペース、ピリオドと正負記号だけで入力ができる。小さな液晶とキーパッドをつけておけば単体で打ち込みもできる。F/A-18のテンキー風インターフェースとかつけても面白いんじゃないかと。さすがにパンチカードは大変そう。

前回、衛星追尾をやったときにはPCのC#アプリで方位仰角を計算してシリアルポートで転送していたが、次回はスタンドアロンで動作できるようになる予定。

 衛星追尾そりゅーしょんをご用意しておりますので、キューブサットの追尾等のご入用の際はご連絡をお待ちしております。(嘘)

2017年12月4日月曜日

中間誘導とVLS

 VLSから発射するには中間誘導が必須である。
 (シリアス口調ここまで)

 中間誘導が使えるミサイル、例えばAIM-9Xは中間誘導が可能で、発射後ロックオン(LOAL:Lock-On After Launch)ができる。AIM-9M等は中間誘導ができず、発射前ロックオン(LOBL:Lock-On Before Launch)のみとなる。
 LOALをするためには「どの方向へ向え」という情報だけで発射する必要があり、その方向へ飛翔するにはなんらかの中間誘導が必要になる。中間誘導ができない場合は、発射前に確実に方向が決まっている必要があり、LOBLのみの運用となる。
 中間誘導の方式はたぶんなんでもいい。AIM-9XならJHMCSの正面方向へ飛翔するだけなので、角度の操作量だけを得ているはず。この場合は慣性誘導でいい。AIM-120は基本的にLOALの運用のはずだが、自分のシーカーでロックオンするのは目標に近づいてからのはずだから、「メインのシーカーがロックオンするのは発射した後」ということでLOBLの一種と考えられる。この際、目標が遠くにいた場合は、目標に接近する間に目標が移動してしまう可能性が高いから、慣性誘導だけでは足りず、途中で目標位置の情報をアップリンクする必要があるはず。だから中間誘導にデータリンクが必要になるはず。

 VLSから発射する場合、ミサイルのシーカーは真上しか見えない。また発射前はフタが閉まっているから、どっちにしろシーカーの目は塞がれていることになる。なので、発射してからシーカーがロックするまで、何らかの方法で中間誘導が必要になる。
 中間誘導を持たないスタンダード1は旋回式ランチャーからしか発射できず、VLSから発射するスタンダード2は中間誘導が追加されている。旋回式ランチャーは撃つ前に目標の方向へミサイルを指向できるから、発射前にロックオンが可能。
 SM-2はVLSから発射するという要求のために中間誘導を追加したが、このためにイルミネーターは終端誘導時のみで済むようになったため、同時に複数のミサイルを飛翔させることができるようになった。
 とはいえ、同時に週末誘導できるのはイルミネーターの数に制限されてしまう。例えば、遠くの航空機と近くの航空機がいて、遠距離目標のほうが優先度が高い、と判断した場合、遠くの目標へミサイルを撃ち、続いて近くの目標へミサイルを撃つことになる。この場合、イルミネーターが1個しか無いと仮定すると、イルミネーターはまず遠距離目標を照射する。最初に撃ったミサイルはこの目標へ誘導されるが、その間に近距離目標に撃ったミサイルも目標へ到達してしまうかもしれない。しかしその時点ではイルミネーターは高優先目標に対して使用中だから、近距離目標への誘導が行えない。イルミネーターが使えるようになったときには、近距離目標へ向かったミサイルは目標の向こう側へ飛んでいってしまった。というようなことが予想されるので、優先順位決定アルゴリズムは、単純に脅威度のみならず、将来的に使えるリソースも考えて撃つ必要がある。上記の場合、遠距離目標に撃ってから近距離目標を撃つと、同じタイミングで目標の終端誘導が必要になってしまうから、ワザと近距離目標に撃つタイミングを遅らせる、とか、そういうような処理が必要になるはず。

 なかなか大変そうだ。武器システムは一日にしてならず。

国際衛星識別符号(International Designator)

 どれくらいの範囲を表せるのか。総当りで吐いてみた(C#)。

StringBuilder sb = new StringBuilder();

for (int i = 1; i <= 26; i++)
{
    sb.AppendLine(
        (char)('A' + i - 1) + "" +
        "," + i);
}

for (int i = 1; i <= 26; i++)
{
    for (int j = 1; j <= 26; j++)
    {
        sb.AppendLine(
            (char)('A' + i - 1) + "" +
            (char)('A' + j - 1) + "" +
            "," + (i * 26 + j));
    }
}

for (int i = 1; i <= 26; i++)
{
    for (int j = 1; j <= 26; j++)
    {
        for (int k = 1; k <= 26; k++)
        {
            sb.AppendLine(
                (char)('A' + i - 1) + "" +
                (char)('A' + j - 1) + "" +
                (char)('A' + k - 1) + "" +
                "," + (i * 26 * 26 + j * 26 + k));
        }
    }
}

 A__が1で、B__が2、C__が3と続き、Z__が26で、AA_が27、AB_が28、BA_が53、ZZ_が702、AAAが703、ZZZが18278まで。
 約1万8千個を扱える。

 中国のASATの試験では、「観測可能なものだけで2,841個以上」(wikipedia)ということなので、かなり余裕ありそう。とはいえ、2桁だと700個ほどしか扱えないから、やはり3桁は必要なんだろうな。
 文字3桁分を整数で書こうとすると5桁必要だから、TLEに押し込むには文字を使うしかなかったんだろうなぁ。26進数恐るべし。
 1958年頃から使われ始めたらしいが、当時の人はどうして700個じゃ足りないと思ったんだろうか。IPv4しかり、大抵は後から桁数が足りなくなるもんだけど。米軍のASATが59年だそうだから、当時からデブリとかは色々考えられてたんだろうか。

 Cでコレを計算する場合、初期値をpiece = 0として、piece *= 26; piece += ch - 'A' + 1;を必要桁数分回せば文字列からintに戻せそう。

2017年12月1日金曜日

空港へ行きたい

 FS MSXでF/A-18を飛ばしながらVOR(コックピットパネルはTACAN)を操作しつつ、「VORってどういう仕組なのかな」と思ったのが運の尽き。調べても出てこない。

 いちおうwikipediaに簡単に書いてあるが、簡単に書きすぎてさっぱりわからない。

 ざっくり解読してみると、主搬送波に可聴信号(モールス符号orその他)がAM変調され、副搬送波がFM変調され、副搬送波に基準位相がFM変調され、副搬送波に可変位相がAM変調されているのかな、という気がする。どこまで合ってるかわからないけど。

 AM/FM変調だけなら、解析するのはそんなに難しくない気がする。ということで、VORを実際に受信してみればいいのだが、あいにくウチの周りで受信できるVORは無い。ということで、空港まで行かなきゃならない。かなり面倒。
 実際に取りにいくなら、SDRでIQを記録する、という感じになるんだろうな。となるとGPSで位置情報を取りつつ、VHF帯を記録することになるのであろう。なんとなく、ゼロ・ダーク・サーティーのCOMINTっぽい雰囲気。こっちはレーダーだから、ELINTになるのかな。


 VORを使うのは航空機だけじゃなく、流星観測にも使われるらしい。曰く、流星が通ったところは電離して電波を反射するので、VHFが上空から返ってくるんだとか(この理解で合ってる?)。VORが受信できるなら、VORのラジアルから、VOR局から流星までの方角がわかるんじゃないか、という気がするけど、35msecくらい持続しなきゃいけないし、AM変調だからかなり厳しそう。
 開口合成受信アンテナを上空に向けておけば、反射波の入射角がわかるから、送信局の位置と送信地点からの方位、受信地点の位置と受信地点からの方位で、流星の位置を特定したり、というのもできそうな気がするけど、流星の反射波ってどれくらいのモノなんだろうか。

***

 あんまり関係ないけど、気が向いたのでIQファイルを生成してみた。データとしては余弦波/正弦波をWAVEファイルに記録するだけなので、思ったより簡単につくれた。変調も、AM/FMでなんとなく出来てる気がする。CWは言わずもがな。
 でも変調できるのと復調できるのは別問題だからなぁ。FMってどうやって復調するんだろうか。

 IQファイルを作る際、最初に間違って256kSPSで作ってしまった。SDR#に食わせるとクラッシュしてしまった。250kSPじゃないとダメ。1.024MSPSとか2.048MSPSとかあるから、256kSPSだと信じて疑わなかったよ。。。

***

 いろいろやりたいことは溜まってるんだが、気力が出ない今日このごろ。

 そういえば、昨日でplalaのモバイル回線の提供が終了したね。同時にWiMAX2の制限が解除されたので、WiMAXに戻した。
 サービス終了ギリギリまで使い続けていたけど、異世界中世魔法ファンタジーに飛ばされるとかはなかったヨ。いや、ネトゲならともかく、回線使ってるだけで飛ばされても、あんまり強いチートもらえなさそうだし、どうでもいいんだけど。
 サービス終了間際の回線は予想以上に快適でした。他の人は早々に使い終わって帯域が空いたからかな?