特に明確に決めてるわけじゃないんですが、最近は毎週水曜日の昼過ぎに更新することが多いです。前回は火曜日でした。ええ、曜日感覚が壊れてます。水曜日になにか用事があって早く更新したとかではないです。
諸々想像してたのとだいぶ違うな。あれだけのボリュームを2,3時間の映画に詰め込むんだからそりゃ色々変えなきゃ収まらないんだろうけど。あとは映える見た目も作らなきゃいけないし。
世界大会を3年連続で同一都市開催ってすごいな。
Hill Helicopters HX50、エンジンのフル機能テストを12月中旬、初飛行を来年6月下旬、生産開始を27年6月下旬に設定、とのこと。
現状、エンジンのシーリング周りで手間取っているらしい。ラビリンスシールでオイルとか空気とかを分離するけど、要求精度が高くて、いろいろな部品が複雑に入り組んでいるから調整が大変なんだそうだ。
/* YouTube、最近海外のコンテンツも相当の割合が翻訳されて表示されるけど、オリジナルのタイトルとか説明ってどうやったら見れるんだろう? YouTube自体の環境設定で設定した言語以外は表示できないなんて馬鹿なことはないと思うんだけど、Googleのやることだからなぁ。。。 */
MQ-28A Ghost Bat Milestone - YouTube
メインランディングギアの扉の面積がかなり大きいし、比較的後ろの方に配置してあるけど、低速時にベントラルフィンとして使えるみたいなことも考えてたりするんだろうか?
６０年近く動作していなかった人工衛星から強力な電波信号、天文学者を悩ませる(1/2) - CNN.co.jp
「強力な電波信号」とは言っても、いわゆるゾンビ衛星みたいに継続的にテレメとかトランスポンダとかが起動しているわけではなくて、超短パルス信号(30ns、強い部分は3ns)。可能性としては、表面の帯電が放電して電波が出たのではないか、とか。
軌道上の放電が地上から検出できる可能性があるのは面白いけど、とはいえ電波天文用の超高感度な望遠鏡が必要だろうから、衛星運用側から監視に使えるような手法ではなさそう。
次世代半導体の実現に欠かせない日本、Playground Globalが目指す日本半導体業界との協業 | TECH+（テックプラス）
xLight、露光装置の中でEUVを作るのは面倒だから、工場の隣に放射光設備を併設して分配しようぜ、みたいなやつ。すごいな。EUVは反射させるのも大変で、だからこそ装置内(最短距離)で作るのも苦労してるんだけど、外に置くなら桁違いに巨大な装置で強いEUVを作れるから、何回か反射が増えて損失が大きく増えたところで、トータルでは使いやすくなる見込みがあるんだろう。
https://www.kek.jp/wp-content/uploads/2025/05/pr202505231400euv-fel.pdf
5月末のKEKのプレスリリース。加速器でエネルギー効率良くEUVを作るための研究開発が採択されたよ、みたいな話。原理とか課題も少し解説してある。
極端紫外線を出すには800MeV(光速の99.99998%)まで加速する必要がある。現状、エネルギー効率の良い加速器では数十MeV(99.88%)程度で、赤外線までしか出せないので、より高速に加速する技術を研究する必要がある(あくまでもエネルギー効率を稼ぐなら、という話)。
どうせ電子線を使うなら電子線リソグラフィとかで頑張ったほうがいいんじゃないかって気は若干。そこまでして光にこだわりたいってことはやっぱり電子ビームは色々課題があるんだろうけど。光なら鏡で反射できるから、みたいなことなのかな。
インカメラVFXに使うLEDウォール、広色域とか色再現性って必要なんかな? RGBで出力された映像信号をカメラで撮影してRGBに戻すんだから、色再現性とかこだわるだけ無駄な気がするんだけど。どうせキャリブレーション(カメラで撮影して正しい色になるように出力する映像を調整)はやるんだから、パネル側の演色性が多少悪くたって、ねえ。
民間の衛星コンステで光学やSARの画像は得られるようになりつつあるけど、早期警戒衛星みたいなヤツの民主化はいつになるのかな。SRBM以上を速報できるようなシステムがあると時々役に立つと思うんだけど。理想的にはPAC-2程度を見つけたいが。ただ、実際にあったものを「あった」と言うのは良いとしても、無かったものを「無かった」と言うには、かなり精度の良いシステムが必要になる。どれくらいの信頼性が得られるか。
LEOから上層大気を透かして見るようなセンサになるだろうから、大量の衛星が必要になる。収益化が難しい情報だから、民間主導でやるのは難しそうだ。光学衛星に相乗りして、オンボードでフィルタリングして、怪しいイベントがあれば衛星間通信で隣の衛星にも同様なイベントがないかを問い合わせて、みたいなセンサを作れれば、比較的安価に速報を出すことはできそう。関心度の高い地域では直上を通過する際に目標を指向して光学観測、それ以外は地心指向で地球の縁を観測、みたいな運用モードになるのかな。
センサのテストが難しいのが難点。米軍とかだと自国のミサイルのテストに合わせてセンサも試すみたいなことができるけど、民間だと気軽に撃つことができない。まあ、最近は軌道投入用のロケットの打上げも多いし、センサさえ軌道にいくつか置ければ、という感じもする。衛星打ち上げ用ロケットはICBMクラスだから小さい方の試験には使えないけど、とはいえでかいものが見えなきゃ小さいものも見えないし、まずは簡単な方から試していく方針で。
光学衛星の会社だと事前に発射予定が公開されているロケットに関しては上空から撮影したりしてるんだろうか。直上を通るようなパスがあれば高解像度で撮って広報的に使えるし、遠距離からしか見えない軌道でも宇宙空間を背景に見たときに熱源がどういうふうに見えるか試したり。SARでもロケットの打上げに合わせてその周辺を観測して、どういうスペクトルが見えるのか試したりとかはしてるのかな。SARはビームが細いから早期警戒みたいな使い方は難しいのが難点。やはり強烈に光っている相手なら光学のほうが楽そう。
一定期間で暗号化が解除される(平文に戻る)暗号化方式があったら面白そうだなー、みたいな空想。
かつての占星術師が残した記録みたいに、その時点では海の物とも山の物ともつかないようなデータだが、とはいえコストを掛けて取得したデータを、短期的には独占したいが長期的には人類が使えるようにしたい、みたいな用途。
主に企業みたいな営利組織が研究した内容とかを想定しているけど、営利組織が取得した実験データが数百年後に価値を持っているかというとちょっと疑問。まあ、情報保存コストが安くなれば負担できないコストではないだろうし、大量にあればいくつかは価値があるだろ、みたいな楽観的な予測。
学術的な公開かつ長期保存を目指したアーカイブみたいなものはあるけど、短中期的には非公開だが長期的には公開を目指したアーカイブ、みたいなものってあんまり聞かない気がする。最近は情報セキュリティとかがうるさくて不要なデータは速攻で削除するだろうからなぁ。
時限で壊れる暗号ってのが難しいよなぁ。100年後のスパコンで解析できるくらいの暗号化、とか考えても、じゃあ具体的にどういう暗号強度ならそれを満たせるんだ、という。
非対称暗号で秘密鍵を物理的に手の届かない場所、例えば軌道周期が数十年になるような太陽周回軌道に突っ込んで、軌道をうまく調性してやれば直近100年で復号することはできない暗号みたいなものは作れる。ただ、秘密鍵を確実に地球上から破棄したことを保証するのが難しいのと、将来的に宇宙開発が進んで秘密鍵を回収する陣営が出ないとも限らないというのがネック。
サブmオーダー(UWBの数cmとか)みたいな精度が不要な屋内測位って、やっぱりIMESがあると便利そうよなー。Bluetoothみたいに測角する必要がないからシステムがシンプル。既存のハードウェア(高周波回路)を使えるから追加コストはほとんど不要。普及しなかったのが悔やまれる。まあ、精度が不要なら低出力なBluetoothのビーコンを置いておけばいいのかもしれないけど。IMESと同じように適当な位置情報が入ったメッセージを数秒間隔でブロードキャストする感じで。
最近だとPTPみたいな時刻同期方式もあるし、Ethernetケーブル1本でPoEで給電しつつPTPで時刻合わせして、みたいなこともできるから、GPSと同じように、時刻ベースで簡単な測位演算を行って、IMESの元々の想定よりも少ない送信機で高い精度が得られそうな気もする。PoE/PTPを使うならEthernetで常時接続が前提だから、ネットワークから分離されたら送信機能をロックするみたいな機能も作れるから、ハードウェアの管理も楽になるし(オリジナルのIMESはハードウェアは管理が厳格だった)。PTPにもNTPと同じように認証の仕組みもあるだろうから、サーバーが正しくないならRFを出さない、みたいなインターロックも作れるだろうし。
しかし、PoE/PTPだと、施設内にLANケーブルを敷設したり色々とコストがかかるのがネック。工場みたいにノイズの多いところで使おうとすると面倒なことになりそう。そうなると、IMESオリジナルの単独で使うビーコンのほうが楽という話になって、それならBluetoothビーコンでもいいじゃん、ということになるんだろうな。
原理的には、PTPに対応したWiFi親機と子機があれば、WiFiのToFで測位もできそう。測位精度は頑張って10mオーダーだから精密な測位には向かないけど。PTPが普及して全体的に精度が改善すれば1mくらいは出るかな? メッシュWiFiを常に5台程度の親機が見えるような密度で配置すれば、比較的高精度の測位と、ついでに超高帯域幅の通信ができる。両者を併用したい用途が思いつかないけど。
YouTubeのURLパラメータでt=0sをつけると指定が勝手に消えるの、地味に不便な仕様。BGMに使っている動画とかで、次に開いたときに最初から再生したい動画とかで。
t=1s以上にしておけば消えないから、1秒未満だけ特殊な処理が走ってるんだろうけど。
ACSの最近のバージョン、リソース管理に難あり? 起動直後からゲームを遊び始めるとCPU使用率が100%になって処理落ちする。OS側や他のアプリケーションを含めて広い範囲に影響がある。起動直後の画面(時代を選ぶ画面)で数十秒くらい置いてからゲームに入れば問題ない。
あと、終了時にもなんか変な挙動がある。ゲームのシステム画面で終了させるとめちゃくちゃ重くなる。タスクマネージャーからアプリケーションを終了させれば問題ない。
あと、ランチャーが時々(一日に数回)ポップアップしてくるのがウザい。
収集系のサブクエ、探索中に見かけたけどメインストーリー優先で放置していると、マップに表示されないからあとから探すのが大変なやつ、凡例を開くと未回収を一覧で表示できる機能があるのを知らなかった。こんな便利機能があったなんて。
***
陸自のUH-1とAH-1
APS-C、910mm、トリミングなし。
かなり低い高度を飛んでいた。UHはバタバタというローター音に混じってキーンというタービン音も聞こえた。
翌日や翌々日もUH-1は飛んでいた(AHは見かけなかった)。ただ、高度は初日に比べてかなり高かった。
当該時刻のMode-C応答
高い高度から降下している2つは旭川空港に着陸した民間機。低い高度を上下しているのがAH/UHだと思うけど、40分もずっと受信範囲にいるのはちょっと謎。耳に聞こえる範囲だともっと狭い時間しか飛んでいなかった。近く(聞こえない程度に遠く)をうろうろしていたのかも。
デコード不良のデータが大量にあるけど、単に信号レベルが低くて、トリガはされたけどデコードはできない、みたいなMode-A/Cが大部分。あとは単にリプライが重なって不正な応答になっていたり、民間機のMode-S系だったり。
Mode-A応答(非Mode-C応答)は、一つが日高管制区域で使っているスコーク、もう一つが1200だった。
特に低高度を飛行しているときの拡大
上にいるのがUH、下にいるのがAHだと思う。
AHは0320o(FL10)、0330o(FL11)、0730o(FL14)、あたりが出ている。FL11とFL14はハミング距離が1なので、ビット誤りで誤読した可能性がある。FL14は振幅が不安定、波形が汚い、コヒーレンシーが悪い、などの特徴があるので、こちらが誤読、FL11が正しい高度だと思う。FL10もコヒーレントだから、最低高度はFL10まで下がった可能性がある。
UHと思われる、FL20、FL23の波形
信号強度が明らかに違うので、たまたま近い高度を飛行していた別の機体からの応答と考えられる。目撃したのはAH-1が2回、UH-1が2回だけど、2回とも同じ機体であるかどうかはわからないから、この時間帯は最小2機、最大4機が飛行していたと考えられる。
FL20とFL23は角速度が似ているけど、他の機体も似たような角速度だから、おそらく防衛装備用の無線機として精度がキッチリ管理されていて、角速度は受信側が支配的っぽい気がする。機体ごとにトランスポンダに個体差があるとそれを使って機体を識別できるし、機体を識別できれば稼働率とか運用の詳細がわかるから、電子戦や防諜を考えると避けたい(機体のシリアルを読めば同定は可能だけど、文字を読むには高解像度の画像が必要になる。SIGINTで同定できるなら色々楽になる)。トランスポンダに限らず無線機器には同じことが言えるから、自衛隊としても周波数を安定化させるインセンティブはある。角速度に個性がないのはそれで説明できると思う。まあ、サンプル数が少ないから、偶然の可能性も排除できないけど。
瞬時値であるFL10からQNH1012mbar(Fr24で取得した旭川空港のMETAR)を適用し、このあたりの標高を引くと、対地高度は115m程度となる。ただ、もう少し標高が低い場所をFL11で飛んでいた場合は対地高度160m程度となるから、今回のデータを元に、直ちに航空法違反の飛行を行っていたと断定することはできない。
たまに米軍機や自衛隊機が異常な低空飛行をしていたみたいなことが話題になるので、じゃあトランスポンダのログ取っておけばよくね?ということでサンプリングして早9ヶ月ほど? ようやく怪しいデータが取得できたけど、結局これだけじゃ判断できないという当たり前の話。Mode-Cは高度情報しかないから、AGLを得るためには水平面を拘束する必要がある。Mode-Cだけじゃできない。
MLAT受信機を作ってある程度の基線長で4箇所くらいに配置しておけば水平面も固定できるだろうけど、とはいえ運用の手間が大変そうだなぁ。受信機自体は1.09GHzを低い周波数に落として10Mspsくらいでサンプリングして、強い信号が入ってきたらGPSでタイムスタンピングしてSDカードに保存しておいて、後で複数受信機からまとめて回収して解析して、みたいな感じでやるなら、受信機1個あたりの単価はそれほどのものではないだろうけど、とはいえいかんせん数を揃えなきゃいけないのが大変。基線長を稼ごうとすると誰かの敷地に置かせてもらうみたいな交渉も必要になるし。定常運用したいなら個人の遊びの範疇からはみ出しそうだ。
天球カメラと組み合わせれば、少なくとも方位は得られる。原理的には仰角と高度から距離も得られるけど、低高度の目標には精度が出ない。2箇所のカメラでθ-θで水平面を拘束して、Mode-Cで高度を拘束する、あたりが落としどころか。
*
別の日
青地に橙のストライプ、警察のヘリかな。FL50くらい。
日没後20分くらい。このカメラは流し撮りモードは無いので、手ぶれ補正はOFFで撮影している。APS-Cでf910mmで1/15sでも、連写すれば何枚かはブレずに写る。20枚弱撮ってほぼ完全にブレ無し写ったのはこの1枚だけだから運要素も強いけど。運というか、筋肉の問題というか。あとは慣れの問題もあるだろうし。下手に支えようとせず、角運動量に任せて動かせばいいはず。
Fr24だとAW139とMil or Govという説明があって、BaroAltとLatLngはあるけど、ICAOアドレスやGPS Altみたいな項目はない。軌跡の感じからいってもMLATっぽいけど、機種や政府所属というのはどうやって情報を得ているんだろう?
***
車載用みたいなGPSアンテナって、グランドプレーンめちゃくちゃ大事なんだな。延々衛星を見つけられなくて悩んでいたんだけど、屋根の鉄板の上に乗せたらかなりきれいに受信できるようになった。ベランダの手摺みたいな狭い金属に乗せるだけだとあまり効果がない(無いわけではない)。だいぶ時間かかったけど、とりあえず自分で書いたコードの問題じゃないとわかっただけ収穫。
2.4Mspsでサンプリングして、ファイル系時刻(横軸)と、GPS秒数とファイル系時刻の差をプロット。最初のオフセット分とクロックエラー由来の傾斜は除去してある。不連続な場所が衛星をロストした箇所で、1回あたり40us程度のジャンプがある。
1ブロック96サンプルで転送して2.4Mspsで40usなのか、偶然にその程度の量が落ちているのかは不明。サンプリングレートを変えて比較してみればいいんだろうけども。
***
C#の生文字列リテラルでタブ文字を使うの、いちいち\\tを入れて.Replace("\\t","\t")で変換してたんだけど、生文字列リテラルの中にタブ区切りを入れればいいんだな。まあ、そりゃそうか、という気はするけど。Visual Studioは文字列の中身でタブキーを押しても1個以上の空白文字(20h)を挿入するから、生文字列リテラルの中にタブ文字(09h)を入れるのは地味に面倒くさい。別のエディタ(メモ帳とか)でクリップボードにタブをコピーしてくるか、あるいは生文字列リテラルを作るときは一旦\\tを入れておいて、VSの置換で正規表現を使うか。
改行コードを選べないとか、生文字列リテラルは低レベルの部分で使おうとするとちょっと不便。
IEnumerable<int> Func()でyield returnを使うみたいに遅延評価されるメソッドを、戻り値は不要だけど処理はやってほしい、みたいに呼ぶときって、どうやって呼ぶのがいいんだろう? Func.ToArray();はちょっと冗長な感じ。foreach(var a in Func());みたいに呼ぶのも、外側には公開されないとはいえvar aの定義がちょっとあれだし。とはいえ、for (var a = Func().GetEnumerator(); a.MoveNext();) ;みたいにやるのもアホらしいし。やっぱりforeachで読み捨てるか、それが嫌ならそれをラップする拡張メソッドを作るしかないのかな?
0 件のコメント:
コメントを投稿