95％の宇宙 解明されていない“謎”を読み解く宇宙入門 (SB新書) | 野村 泰紀 | 宇宙学・天文学 | Kindleストア | Amazon
このタイトルを見たときに、話題として比較的狭い領域(質量で換算できるモノ)の話しか書いてないのかな、と思ったのだけど、かなり広い範囲が出てきた(商品説明に目次が書いてある)。超弦理論やマルチバース、ブラックホールの最近の話はあまり細かくは書かれていないけど。
NFCカードのスキミング対策でシールドする小袋、全体がアルミ蒸着シートで作られているけど、原理的には外周部のアンテナが入っている場所だけシールドしておけばいいはず。場合によって、目視自体を防ぎたいのか、逆に何が入っているのか明らかな方がいいのかは分かれるだろうけど、シールド袋としては目視できないタイプが圧倒的に多そう。
クレカだとNFCを使わずに番号を手入力したいという場合は袋から出さずに使えると便利だろうし、あるいはマイナンバーカードみたいな身分証明書はシールドしたうえで、自分が急に意識を失ったりしたときに救急隊員が財布を見てマイナカードを一目で発見できるような状態にしておきたい、みたいなことも考えられる。
どうしても一部が透明なシールド袋が必要なら、市販の透明なカード袋の上から、アンテナ部だけ覆うようにアルミテープを貼ったりとかで自作することもできるか。どの程度確実にシールドができるかは未知数だけど、そんな事言い始めたら通販で売ってるシールド袋だってな。外部からネルギーを突っ込まないと動かないNFCカードの特性上、ある程度減衰させれば動作しなくなるはずだけど、とはいえ多少減衰した程度なら問題なく使えるように作ってあるだろうしなぁ。
最近のYouTube、PCサイトのデザインがなんか変。具体的には一番上からスクロールすると途中でコンテンツの読み込みが挟まってサムネがズレるみたいな挙動がある。地味に不便。それと、視聴済みの動画のサムネの下にシークバー(再生済みの割合の長さの棒)が表示される動画と表示されない動画が混在していて使いづらい。未視聴だと思って開いてみたら動画の途中から再生が始まる、とか。シークバーが表示される動画はマウスオーバーでもURLオプションで時間指定がされているけど、シークバーが表示されていない動画はURLオプションも無し。
あと、Androidアプリ版のYouTubeも、Premiumのレジューム機能が変な挙動をしている。PIPが非表示だが画面の中に配置されているので、画面の四隅をタップすると勝手に動画が再生されることがあるとか。最近のYouTubeは細かいところがどんどん不便になっていってる気がする。
ただ、最近のYouTubeは英語の文字起こしとそれの翻訳の精度はかなり高くなってる。文脈で固有名詞を理解するみたいなことはできていないけど、英語を聞き流しながら日本語を読んでも、文脈や意味、表示されるタイミングはかなり綺麗。このあたりはAIで最適化されてるんだろうな。逆に、サービスの使いやすさみたいな、人間が調整しなきゃいけないようなところはどんどん悪化している。
最近インターネットがちょっと不調なことがある。平日の夜とか、休日の昼間とか、下りが5Mbps未満程度しか出ない。そのタイミングでも上りは130Mbpsとか出るから、回線の物理的な問題とかではないはずなんだけど。
***
興味本位でF-35Bのホバー時の操縦方法を探してみるなど。YouTubeで軽く探した程度だと、オフィシャルに近い情報(メーカー製シミュレータの動画とか)はあまり見当たらないけど。デモンストレーターの映像って古いやつは結構あるけど、最近の映像ってほとんど無い気がする。セキュリティ厳しくなったんかな?
HOOK/STOVLボタンを押すとSTOVLモードを切り替えて、通常飛行形態でSTOVLモードに入ると60kt前後の低速飛行に移る。この状態ではスロットルで前進速度を、操縦桿で上下(押し込みで下降、引きで上昇)、操縦桿左右でローリング(左右方向の速度)、ラダーで進行方向、という感じで、通常飛行形態と同じ操作系になる。低速時にスロットルの減速ボタンを押すとホバリングする。ホバリング中も、操縦桿前後で上下、スロットルで前後位置、という操縦方法になる。
ヘリコプターは操縦桿の前後が位置の前後、スロットル(コレクティブレバー)の上下が位置の上下だから、これが左右逆になっている。プロポのモード1とモード2の違いみたいだ。
STOVL時には仮想HUDの左下に飛行機のアイコンが出て、機体の上の数字がエンジン出力(%)、機体の下の2つの数字がスラストベクター(度)。スラストベクターは前進時なら90未満、減速時(or後進時)は90より大きい数字(最大103度)になる。
適当な数字でざっくり雰囲気を考えてみると、平時の短距離着陸や垂直着陸の際は(必要かどうかはさておき)、例えば6度のスロープでFPMを滑走路端に置いて進入して、300kt未満でギヤダウン、適当な距離&速度に達したらHOOK/STOVLボタンを押して短距離着陸モードに入り、自動的に60ktくらいまで減速(ベクトルは維持)、そのまま6度のパスで進入を続けて、適当な距離に達したらスロットルの減速ボタンを押すことで、FPMの場所は維持しつつ目標地点上空で静止(高度は減速ボタン押下時の付近を維持)、スロットルの前後と操縦桿の左右で位置を調整、操縦桿の前後で高度を調整、みたいな感じなんだろうか。
空母に短距離着艦する場合(英国のSRVL運用)は手前の端(通常アレスティングワイヤがあるような位置)にFPMを置いてそのまま60kt程度で突っ込んで、垂直着陸する場合は艦の横(海の上)にFPMを置いて適当な高さで減速・停止、スティック左右とスロットル前後で位置を調整してからスティック前後で降下、とか。
スロットルが前後位置に対応しているとすると、例えば最スローでホバーに入ると目標地点がどんどん後ろにズレていくみたいな問題があるはずなんだけど、どうやって対応しているんだろうか? 例えば減速ボタンを長押し中はスロットルの制御が外れて、その状態でスロットルを中央に移動すれば前後指示コマンドがエンゲージ、とかなんだろうか。
F-35Bの垂直着陸は自動で行う…フライトシミュレーターも公開 | レスポンス（Response.jp）
通常時の操縦棹（サイドスティック）は「前に押すと下降、後方に引くと上昇」だが、これがSTOVLモード時になると「前に押すと前進、後方に引くと後進」に変わる。
パイロットがシミュレーターで説明してる操作法と違うぞ……
メディア向けのシミュレーター体験会とかで触る機会はたまにあるはずだけど、いまいちSTOVLをやったみたいな話は見かけない気がする(海外メディア含めても)。大抵は対空戦、ひねくれた人なら対地戦をやってそれで終わり、みたいな感じなんだろうな。
自衛隊内部向けの情報収集とかでもなければ、一般のメディアが商売する相手は一般市民で、市民が気にするのは空港周辺の飛行経路とか騒音なんだから、真っ先に離着陸のシミュレーションを触らせてもらって、「こういう飛び方をするとどれくらい時間がかかるから、騒音の継続時間はどれくらい」みたいな情報を集めるべきだと思うんだけど。「タッチパネルで敵を選択して発射スイッチを押せば撃墜できる」みたいな話を書いたってねぇ。いくらFBWで素人が普通に操縦できるほど簡単とはいえ、素人が離着陸にかかった時間をそのまま採用するわけにも行かないしな。
eVTOLもマニュアルで操作できるやつは、垂直離着陸と水平飛行の遷移があるから、その2つの制御則をシームレスに(本能的に)操作できるモードがあるはずなんだけど、メーカー間で操作方法を統一しようみたいな動きはあるんだろうか? そもそもマニュアル操作はプライマリではないし、マニュアルで操作するにしてもセンサで状況を監視しているから危険な操作には入ることはないから、多少の誤操作は許容してメーカー独自の操作方法になっているんだろうか。
飛行機の操作方法とヘリコプターの操作方法、それぞれのプライマリの形態に合わせて操作しやすくなっている気がするけど、F-35Bはあくまでも飛行機がプライマリであって、ホバリングは過渡的(着陸時のみ)な使用だから、操作のしやすさ(ホバーモードでの複雑な飛行)は犠牲にしたうえで、本能的に操作しやすい感じになっているのかな。
eVTOLみたいなものは、巡航はオートパイロットがプライマリで、ユーザーが操作するのは離着陸時がほとんどだろうから、ヘリコプターの操作系になりそう。
別件だけど、最近の戦闘機ってスティックシェイカーみたいな機能ってあるんかしら? フライトシミュ用のジョイスティック(最近の戦闘機モチーフ)で振動機能をアピールしてるやつがあるけど。
コンピューター制御の最近の戦闘機って、そもそも失速自体発生し得ないから、失速に近づいていることをパイロットに通知するスティックシェイカーも無さそうな気がするけど。
失速に入らないなら速度を下げるとどうなるかというと、位置エネルギーを速度エネルギーに変換するんだろうけど、それが進むと結局墜落することになるわけで。あと、最近の戦闘機は背面で飛んでても目を閉じれば水平飛行と同じ感覚になるから、しっかり外を監視していないとヤバそう。だからこそわざわざオートスロットル(必要に応じてパイロットの操作をオーバーライドできるアクチュエータ)を積んでまでF-16にAuto-GCASを追加したりとかしてるんだろうけど。
ヒコーキやドローンを調べていて、久しぶりにラジコン飛行機に触りたい欲が出てきた。まあ、わざわざ違法だと知ったうえでやりたいかと言われれば、そんなこともなく、合法化の手順を踏もうとも思わず。
自分みたいな方向性の人間(要するに自作の回路とかペイロードを色々積みたい要求)からすると、小型化はかなり難易度が高いのよな。適当にデカくていいなら、例えばウイングスパン2mとかその程度で作っていいなら、わりといろいろ遊びがいがあるんだけど。
***
小さいネオジム磁石を21個並べるプレートを作ってみた(最中状に2枚、重ねる前の写真)。
磁石が小さすぎて単体だとほとんど磁力がない。そもそもamazonで100個入りとかで買ったやつだから磁石としてもあまり優秀なものじゃないだろうし。そういう磁石をたくさん並べても、使った数に見合うような効果は無さそうな感じ。strong sideとweak sideで磁力が違うのは明らかに体感できるけど。
あとは、外周部は磁束が漏れているはずだから、3x3程度だとそもそも効果が薄い、という可能性もある。それに、立方体の磁石とかを使うならともかく、薄い円筒形の磁石だとこの並べ方をしてもきれいに整わない気もするし。
***
モードSのデコードのやつ。
モードSの誤り訂正にはCRC-24(1FFF409h)が使用される。ただしCRCには機体IDやインテロゲータIDがXORされている(場合がある)ので、普通にCRC計算を行ってもゼロにはならない(事がある)。
SSRモードSインテロゲーションにはインテロゲータのIDが含まれているし、インテロゲータは航空機IDを知っているから、これらを含めてCRCを計算することで、正しい結果が得られる。対して、別の航空機からの応答(ICAOコードが異なる)や別のインテロゲータに対する応答(インテロゲータIDが異なる)の場合はCRCエラーになるから、誤った応答を採用することが無い。パケットの中にそれぞれのIDを含める場合、追加で24bit(ICAOコード)+4bit(インテロゲータID)が必要になるが、24bitパリティにこれらをビット加算することで、シンプルな誤り訂正の中で自動的に排除できる。
ただ、SSRとして使う分には便利な機能だが、バイスタティック的に使うことが難しい。インテロゲーションが既知なら対象の航空機やインテロゲータIDもわかるけど、レスポンスだけ受信する場合は誤り検出を諦めるとか、いくつかの妥協が必要になる。
とりあえず、試しにブルートフォースでモードSを復調。10MspsのIQファイルから1Mbpsのマンチェスタ符号を手当たり次第に復号して、プリアンブルとCRCが正しいビット列を吐き出す処理。パラパラとパケットが得られて、DownlinkFormatによるとモードS All-Call応答とのこと。2.7秒程度の間隔でAll-Call応答が出ているっぽい。TCAS用かな?
全サンプルからビットを復元してCRCでチェックするので、キャリアスケルチでトリガする必要がなく、かなり弱い信号でも復号できる。ただ、CRCみたいな誤り検出・訂正コードはビット位置ズレがあっても(例えば1bitズレていても)、CRCで誤りが検出できないことがある。
プリアンブルのSNRでフィルタする方法(例えば各パルスの差が3dB以上なら破棄とか)も考えられるけど、プリアンブルのSNRとデータのSNRは同じなので、プリアンブルのSNRでフィルタリングすると、データビットのSNRも一定未満は破棄することになる。なるべく低い信号まで探したい場合は、この方法は使いづらい。そもそもSNRの低い(誤りの確率が高い)データなど使うな、という話になるのかもしれないけど。ただ、キャリアスケルチの場合はノイズフロア付近を取らないように高めのトリガレベルを設定する必要があるけど、プリアンブルのレベルは相対的に低い閾値でトリガできる。
CRCは正しくゼロクリアにならないが、プリアンブルの形が正しく、データビットの波高も正しく、SNRも良いパケット、つまり見た目上はモードS応答として正しい波形もダンプしてみると、CRCは固定値を取り、ダウンリンクフォーマットは4や11が出てくる。航空機とインテロゲータのペアが固定ならCRCは同じ値が出力されるはずで、DF4はモードC応答(モード3/AはDF5)、DF11はComm-B応答だから、メッセージの形としては正しそうな気がする。
同時にブロードキャストされているモードS(CRCがゼロクリアになり、非ゼロのICAOコードが含まれているもの)のICAOコードのCRCを求めてみると、先に出た非ゼロ固定値が得られた。
DF4はM-C応答をM-Sで変調しているような感じで、ATC SSRインテロゲータからの質問ならインテロゲータIDが含まれているはずだが、それが無いのが謎い。ATC SSRではなく、ACAS/TCASみたいな機能によるんだろうか? ACAS/TCAS用の質問にはIIコードは無いはずだから、CRCにICAOだけ載せてIIコードが無いのは説明できる気がする。でもその場合は他者が出したACAS/TCAS質問の応答を誤認する可能性がありそうだが。距離が近いモードSトランスポンダに対してはモードSとは別の(ACAS/TCAS側の)プロトコルで識別するとかするんだろうか?
モードSのCRC(24bit幅)に24bitのデータを入れた場合、入力と出力は1対1で対応する(複数のデータが一つのパリティに重複しない)。なので、データに誤りが無いと仮定すれば、パリティから適当な逆変換(テーブルを引くとか)で24bitIDに戻すことができる。もちろん、伝搬中にビット誤りが発生すれば、それを検出することはできず、誤ったIDを復元することになる(IIコードが乗っている場合もICAOコードは復元できない)。同じIDが複数検出されればそれを正しいコードとして使うとか、ビット列を厳密に判断する(少しでも弱かったり強かったりするビットが含まれていれば破棄する)とか、色々とロジックは組めそうだが。
トランスポンダの規定としては、モードSの応答はいずれのビットペアでも2dB以内に収めるように、とのことだから。4dB位を見ておけばいいかな。ENRIの資料では3dBで閾値を設定していたはずだけど、受信側は1dBしか余裕がない。もっとも、送信側は大電力を出さなきゃいけないので電気的に厳しいが、受信側はそこまで厳しくない、ということで、2dB+1dBで設定しているのかもしれないけど。
モード3/A/CやモードSの応答の形をググると綺麗な矩形波列の図が出てくるけど、Airspy R2で見た感じは、もっとヌメッとした感じの振幅が得られる。おそらく帯域幅を制限しているので正規分布的なエンベロープになっているんだろうけど。
もう少しサンプルレートの高い受信機か…… HackRFとか? 帯域幅が倍で値段は2倍弱。7GHzまで対応しているけど、2.4GHzとか5.8GHzみたいなISMバンドとか、そのあたりで使われている周波数拡散プロトコル(DSSSやFHSS等)を見るには20Mspsだと厳しいのよなぁ。当面はR2の1.7GHz/10Mspsまでで遊ぼう。
同じような感じでSIFの受信も行おうとした場合、これらの信号はパルス間隔1.45usで規定しているので、10MspsのAirspy R2とは若干相性が悪い。確かENRIのロガーは20Mspsだった気がするけど、帯域幅の話(18MHzくらいのはず)だけでなく、モード3/A/Cのタイミングが整数に入るように、というような選び方をしていたのかもしれない。
モードC応答で有効なGillhamコードから得られた高度と、モードS DF4で得られた高度を見てみると、ほぼ同じ値(丸め誤差程度の差)が得られている。同様に、モード3/A応答で得た有効なコードと、モードS DF5で得たコードを比較すると、同じ値が得られている。
DF5のコードはいくつかのビットが追加されているけど、スコークコードについてはSIFと同じ物理配置で並んでいる。Xビットすらもそのまま残っている。ということは、モードSを決めるに当たってXビットも残しておく必要がある、と判断された、ということなんだろうか。やはり大口顧客が使ってるのかな? ほとんど使い捨てみたいなドローンにわざわざモードSトランスポンダなんて乗せるかな……とは思いつつ、でもQF-16位の規模になれば乗せるか。
一部の説明だと中央のXビットは常にクリアで、セットされている場合は無効な信号として扱う(無視する?)、というような事が書かれている。この場合、空域にターゲットドローンが存在していても、民間用を始めとしたセカンダリレーダーでは把握できない(スクリーンに表示されない)ということになる。そもそもターゲットドローンを民間航空機がいる空域で飛ばすな、という話なので、普通は問題ないんだろうけど。
自衛隊で海岸近くでターゲットドローンを飛ばしている部隊もあるから、そういうときに1030/1090MHzをサンプリングすれば面白そうだけど、さすがに怪しまれそう。べつにでかいアンテナを立てるとかするわけでもなく、ダッシュボードに置いたモノポールをノートPCでサンプリングする程度で取れるだろうから、外から見て怪しい感じには見えないだろうけども。
