セイコーの時刻同期技術により“GNSSの死角”を解消衛星測位に依存しない次世代位置情報基盤「Chrono Locate™」を建設分野で実証 | セイコーソリューションズ株式会社のプレスリリース
https://www.taisei.co.jp/about_us/wn/assets_cms/pdf/10967.pdf
浚渫工事で実証しているのが面白いな。重力に縛り付けられた人類は水運から逃れることはできないのだ……
https://www.nict.go.jp/publication/shuppan/kihou-journal/houkoku65-2_HTML/2019S-06-01(05-01).pdf
Chrono LocateのベースになったのがNICTのWi-Wi(wireless two-way interferometry)という時刻同期技術。まあ、名前からして時刻ベースだろうよ。
最低4箇所の基地局が必要、みたいなことが書いてあるけど、Wi-Wi(時刻交換プロトコル)ベースなら1箇所の基地局との双方向通信と、追加で2箇所の基地局(主局と精密に時刻同期)からの受信だけでも位置決めできるはず。基地局間の時刻決定が面倒という場合でも、3基地局相手に双方向通信を行えば済む話で、4局目が必要な理由がわからない。
Wi-WiのアクロニムがWIreless two-Way Interferometryの意味(tWo-wayではなく)だとすると、実際のところ1wayとか4wayとかで時刻決定していても、それはWi-Wiになる、という可能性はあるか。1基線の1wayで時刻を決めることはできないけど、4基線の1wayなら4次元時空間を拘束できる(GPSと同じ原理)。
つまり最低4基地局が必要なChrono Locateは、Wi-Wiベースと言いつつ、実はオリジナルのWi-Wiの2wayではなく、1wayの独自プロトコルを使用している、という可能性。
ユーザー端末が増えると、2wayでは基地局の負荷が増えるから、ある程度のデバイス数を見込んだ測位用途では1way(放送型)のほうが使いやすい、ということもありそう。あるいは、長距離を飛ばそうとすると無線機器としての取り扱いが面倒になるから、ユーザー機器は受信だけで使えるように(無線機器として登録するのは基地局側だけでいい)、とか。
https://www.riken.jp/press/2026/20260403_1/index.html
Spring-8の観測データ(27GB/s)をFPGAで前処理し、データセンターで可逆圧縮処理。非圧縮では19PB/weekのデータ量が、2.2TB/weekまで減る。また、伝送帯域の使用効率が改善するので、観測後数日かけて解析していたものを、観測中に(15分程度で)解析できるので、実験中に結果を見ながら調整できるようになった。
シネマカメラのレビューのYouTuberの発言。「買い替えようと検討しているなら、買い替える必要はない」(意訳)、至言だな。
買い替えを検討しているということは、すでにそれに相当するものを持っている。買い替える明確な必要性があるなら買い換えればいいが、買い替えるための理由を探しているなら買い替える必要はない。
「機材を買い替えるより、まずは創造性を豊かにしよう」とも。
Google君さぁ、gmailに届いた、今までも何回もメールを送ってきている相手からの、署名&暗号化がされている、ちゃんとしたメールを迷惑メール扱いするのやめてくんない? あと、プロバイダからの割と重要なメールも迷惑メールフォルダに入ってたし。
別の例では、昔一瞬だけ遊んだホヨバのゲームで登録していたアドレスに届いた、ホヨバの署名がついてTLS暗号化もされているし、たぶん正しいメールだと思うんだけど、これがGoogle的には個人情報を不正入手するための危険なフィッシングメールである、という判定らしい。で、フィッシングメールであることを解除する(通常の受信フォルダに移動する)ためには、メール全文をGoogleに送って審査してもらう必要があるんだそうだ。面倒くさい世の中になったものだなぁ(Googleに送った時点で(審査されていなくても)自分の受信した分は通常のフォルダに移動するけど)。
インターネットを使い始めた最初から契約しているプロバイダ、色々なところからメアドが流出して、最近は1日100通くらいの迷惑メールが来ていたけど、プロバイダ側でフィルタリング(送信者アドレス偽装検知)が追加されてからは1日1,2通程度まで減った。まだ来るってことはいい感じに設定すればフィルタを突破できるんだろうから、いたちごっこだろうけど、当面は静かになりそう。
YouTubeのサイドバーの登録チャンネルの枠で「もっと見る」をクリックすると、格納されていた一覧が展開されるという従来の挙動が変更されて、別のページに遷移して、しかも登録チャンネルの一部しか表示されない(ページ一番下までスクロールすると次のブロックを読み込む)、という改悪。一部しか表示されないとCtrl-Fで文字列検索できないからめちゃくちゃ不便。
実際には移行先のページでもう一度サイドバーを開けば全件が表示されているので、そこを開き直せばページ内検索ができるけど、遷移先のページが出てくるまでにタイムラグがかなりあるから、操作性はだいぶ悪い。
冗談目に言ってた「毎週のようにYouTubeが改悪される」という話、だいぶ現実味を帯びてきている。
***
ある1日に受信したSIFの、7777応答だけを表示したもの
13時間の間に200回以上の7777応答を受信し、ほとんどすべての機体から受信している。ただ、7777応答を返す機体でも、すべてのタイミングで7777を返しているわけではなくて、受信開始付近または受信終了付近に固まっている。
一番上のドットが7777応答。一番下の方の斜めに分布しているドットはモードC応答で、高度変化を示している(モードCに割り当てられたコードは高度でソートし、その上に残りをコードでソートして表示している)。
これを見ると、7777応答は離着陸時の高度が低いときにのみ出ていて、高度が高いときにはあまり出していないことがわかる。
7777応答はトランスポンダの定常的な誤動作で出しているものだと思っていたけど、実際にはそうではなく、別のメカニズムがありそうだ。それが高度に起因するのか、あるいはインテロゲータの信号強度が強すぎると誤動作するのか、いろいろ考えることはできるが。しかし、特定の機体だけ誤動作するならともかく、旭川空港に離着陸するほぼすべての機体で同様に7777が出るというのは、ちょっと不思議な気がする。
7777が見えるのは受信側の問題である可能性もあるけど、メカニズムが想像できないんだよな。特に振幅や位相の連続性を満足するような条件を含めると、受信側原因説はかなり旗色が悪い。とはいえ、多くの機体に搭載されているトランスポンダのほぼ全てで同様に変な挙動をする、というのも、考えづらいわけで。
*
Airspy R2で受信してSIF/モードSをデコードするやつを試作中…… GUIが面倒なので、とりあえずコンソールでデコーダだけ作ってる。一応TCPサーバーもつけているので、外部アプリからSIF/56bit/112bitを取り出して表示したりとかは可能。
ウチには現在、RasPiで走らせているdump1090(Mode-S ADS-B専用、RTL2832ベース)と、自作のSIF専用受信機(RTLベース)と、今回作ったSIF/M-S受信機(Airspy R2ベース)の3種類の受信機が走っている。RasPi側は多少利得が高いだろうアンテナをつけていて、かつCRCで誤り検出を行っているので、かなり遠くまで見える(高度によっては札幌まで見える)。SIF専用のやつはなぜか北側に極端に利得が高くて、旭川空港を離着陸する機体もかなり低い場所まで見える。R2に接続しているアンテナはあまり感度が高くなく、受信側の閾値も未調整なので、あまり遠くまでは見えないが、西や南はSIF専用よりR2のほうが遠くまで見える。
デコーダもまだ調整中なので常時受信はしていないけど、雰囲気的にスケルチ通過後のIQファイルは2-5GB/dayくらいかなー、といった程度。SIF専用のやつは200MB/dayくらいなので、1桁多い。サンプリングレートで2.8倍、8bitIQ→16bitIQで2倍、合わせて5.6倍、ゲートの感度を少し敏感に設定して(絶対値指定→相対値指定)、トータルで10倍～、という感じらしい。
WAVは圧縮効率が悪いので、単純に圧縮すると25％程度しか圧縮できない。おそらくdataチャンクを1回微分すればもう少し稼げると思うんだけど、デコーダを考えるのが面倒。自己展開方式にラップすれば良いんだろうけど、それを作るのもまた面倒。
SIFを受信したIQファイルの、信号強度の各パーセンタイル値。ブロックサイズは128Kサンプルで、5サンプルの移動平均(インコヒーレント)を取っている。
ブロックサイズがある程度大きければ、95％程度までは入力信号の影響は受けない(空域の過密度による)。ブロックサイズが小さければ、その分メッセージ長の比率が長くなるから、低いパーセンタイル値にも影響が出てくる。
キャリアスケルチを自動で設定したいなら、90%あたりを参照して、+9dBあたりでトリガすれば、ある程度の振幅のある信号ならトリガできる。もう少し低い信号まで見つけたいなら、95％+6dBとか。あまり敏感にしすぎるとノイズフロアでトリガしてしまう難しさがあるけど。
意図的に高いパーセンタイルを設定して、例えば98%とかにすれば、多くのパケットが出ているときは相対的に受信する数を絞る(比較的弱いパケットを破棄する)、みたいな使い方もできるかもしれないけど、とはいえあまり信頼性はなさそう。特に前ブロックのパーセンタイルを次のブロックの閾値に使う、みたいな場合。今回のブロックの振幅を別ブロックにコピーして、先に閾値を決めてからスケルチの処理を行う、みたいな流れなら、ある程度安定して動くかもしれないが。
縦軸にドップラ(kHz、正負の曖昧さがある)、横軸に信号強度(非正規化)のグラフ
0kHz付近にパラパラと散らばっているものがある。これは通常のモード1/2/3/A/B/C/D/S応答の形。正しくデコードできないもの(総当りのデコードでSNRが足りないもの)はキャリアスケルチで通ってenergyでプロットしている。ほとんどはSNRが足りないだけで、信号としては1/2/3/A/B/C/D/Sに対応している(全部確認したわけじゃないけど)。
モードS112bitを見てみると、こんな感じ
横軸がマイクロ秒、青が信号強度(dB)、橙が位相。大雑把に40usで1回転しているので、逆数で25kHz程度のドップラで、上の図と整合的。位相のノイズが大きいのは、マンチェスタ符号の谷の部分。
ドップラが4MHzほどある信号
信号強度は十分に高く(モードSのピークと同じ程度)、2つの山がある。このとき、同時に取得していたRTL2832ベースの受信機では、この信号は見えなかった(ドップラ4MHzはRTLの帯域の外なので、見えなくても当然だが)。ただ、昔これに似た形を見たことがあるので、1090の近くでもこの形を使うことはあるはず。
受信地点から可視の範囲に十分な空港設備を持っている施設はないので、航空機が発している信号のはず。
例えば函館空港のVOR/DMEは70Xで、これに対して測距する場合、航空機が1094MHzの質問を発する。
Wikipediaによると、DMEの質問は2つのパルスペアを使用して、Xチャンネルは12us間隔のパルスを使用するらしい。上の図の2つのコブはちょうど12us程度の差に見える。適当にググって出てきた画像によると、パルス幅はピークの-6dBで3.5usらしいが、上の図のコブもそれくらいの幅に見える。
このときに25kHz程度のドップラを含むモード3/A/C応答(コードor高度)に一致する機体は、Fr24で見ると函館から200km程度の場所を飛んでいる。このときの高度(FL310)から水平線までの距離を計算すると、函館は十分に可視範囲内だから、函館VOR/DMEを使っていると考えても矛盾はない。
ということで、この謎の信号は、DMEのものと考えて間違いなさそうな気がする。DMEってどういう信号なんだろうか、とは気になっていたけど、はからずもサンプリングしてしまった……
あと、だいぶ前に見かけた変な形の波形も、DMEであることが判明した。ただ、そのときはRTLでサンプリングしたので、1090MHzからせいぜい±2MHz程度の範囲のはず。その周波数で質問を行うトランスポンダは、少なくとも北海道の周辺には存在していないはず。A/A TACANみたいなもので使っていた可能性は排除できないけど、とはいえ可能性としてはそう多くないはず。そもそも1030MHzや1090MHz付近は避けて運用しているはずだし。
DMEの質問も、パルス幅(±1.7usで-6dB)と間隔から、自動で検出はできそう。チャンネルも角速度やパルス間隔から判定できるだろうし。ただ、DME質問を出しながらこの辺りを飛ぶ航空機はあまり多くないはずだから、わざわざ検出してもなぁ……という気はしないでもない。A/A TACANにしたって、全チャンネルのごく一部しか受信できないし。
*
dump1090の30002ポートからは、信号がないときは1分間隔で*0000;というメッセージが出てくるけど、これって何を意図したメッセージなんだろう? モードSの56bitや112bitでは14文字や28文字の16進数が出てくる。4文字ということは13-16bitのデータを吐くフォーマットなわけだけど、何用なんだろうか。
今回作ったデコーダは、モードSの56bitや112bitなら14文字や24文字のテキストを出して、SIFの14bit(3bit*4 + X + SPI)は4文字で吐こうとしていた。dump1090の16bitメッセージと衝突する。*0000;は自分のフォーマットに照らすとフレーミングパルスに相当するので、これが衝突するのはちょっと困る(クライアントを作ったときに、dump1090をソースにしてハートビードを受信したときに、フレーミングパルスを受信していると誤認する)。
SIFはF1/F2も含めて16bit化して、フレーミングパルスは*8002;が出て、*0000;なら無効メッセージ(ハートビート)として扱う、という手もあるが。
あと、DMEもどうするかなー。そもそもTCPで吐くかどうかも含めて考えなきゃ。
*
TACAN/DME/VOR/ILSの周波数割当
たぶんこんな感じだと思う。
縦横が違うだけで同じ図。
チャンネルは1から126まで、チャンネルごとにWXYZのサブチャンネルがある。基本はXYだけ、場合によってWZも追加(MLSとか特殊用途用の割当?)。WとX、YとZは同じ周波数を使用。
TACAN/DMEの機上(インテロゲータ)周波数は全チャンネルでリニア。応答はXとYで別の周波数(±63MHzオフセット)を使用する。オフセットの符号は63と64を境に反転する。
周波数の代わりにチャンネル番号を使う場合、質問はサブチャンネル(XY)にかかわらず同じ周波数だから、質問周波数を指定したい場合はチャンネル番号だけでいい(例えばチャンネル1で1025MHz)。逆に、応答はサブモードによって周波数が変わるから、応答周波数を指定したい場合はサブチャンネルを含めて指定する(例えばチャンネル1Xで962MHz)。
VOR/ILSは17-59と70-120はリニア(60-69は抜けて、そこを飛ばして連続)。XとYは50kHz差、XとX、YとYは100kHz差(つまり50kHz間隔でリニア)。17-56は奇数チャンネルがVOR、偶数チャンネルがILS。
実際にはこれらのチャンネルがすべて使われるわけではなく、例えば1030MHz(チャンネル6)や1090MHz(チャンネル66および3Y)付近はATCRBSで使っているので割り当てず、またGPS L5(1176.45MHz)付近も避けることがあるらしい。L5は89Xと90Xの間だが、帯域幅が広いから、綺麗に抜くなら上下15chくらいを飛ばすことになるはず。
アメリカで使われているUAT ADS-Bは978MHzで、これはチャンネル17Xに相当する。ビットレートがそこそこ高いから、おそらく帯域幅もDMEから拡大していて、周辺は避けて割り当てるような運用になっているはず(未確認)。
Airspy R2で1090±4MHzを受信するとすると、62から70まで、1Yから7Yまで、125Yと126Y、あたりが受信できる。Xの応答は範囲外だから、Xを受信したら質問と確定できる。Yは質問と応答の周波数が重なっているが、質問と応答はパルス間隔が異なっているから、識別可能(Xは質問と応答が周波数で分離されているから、質問と応答は同じパルス間隔を使用)。A/A TACANはパルスペアではなくシングルパルスで応答するらしいので、応答を受信するのは難しそう(単パルスのエンベロープでDMEかノイズかを判断しなきゃいけない)。
DMEは250MHzを超える幅(比帯域幅23％)があるから、これを全部監視しようとするとかなり大変。これくらいになると適当なアナログフロントエンドで増幅とBPFだけ通して、ダイレクトサンプリングで取り込むような形になるのかな。DME/TACANやUAT/1090ESをすべて監視するようなモニタシステムは作れるだろうけど、まあ、そういう需要はあまりないだろうなぁ。
DME/TACANの全chを監視して嬉しいこともそう無いだろうし、UAT/1090ESを受信したいなら適当な狭帯域受信機(帯域幅数MHz)を2個並べれば済むだけだし。研究機関の電波環境測定みたいな用途なら全体を一気に受信できる機材があれば便利かもしれないけど、そういう場合でも市販の受信機でIQデータを取っておいてあと解析で処理すれば済むだろうし。
そもそも978/1030/1090MHz以外はDME/TACANでしか使わないから、電波環境のモニタリングとかも不要だろうし。
*
ついでにTACANについても軽く調べてみて、測角/測距を両立する原理はなんとなく理解った気がする。
TACAN局は2700パルスペア/秒でパルス列を放送している。このパルス列は、原則としてランダムなタイミングで発信される。
このパルス列は、15Hzと135Hzの2つの正弦波で振幅変調されている(一つの大きな正弦波が1秒あたり15回転し、その中に小さな正弦波が9個入っている)。この振幅は水平面で回転しているから、どこかで位相の基準を与えなければならない。このために、ランダムな間隔で出ているパルスは、1秒に15回、決められた間隔(X:12us、Y:30us)・個数(X:12個、Y:13個)の連続したパルス列を出力する。また、135Hzの正弦波にも同様の基準パルスを出力する(X:24us6個、Y15us13個、ただし15Hzと同じタイミングの場合は15Hz側が優先)。
TACANで方位を決める場合、まずこの連続したパルスを探してタイミングを決める。その後、パルス列を振幅変調して位相を復調し、TACANから見た自身の方位を決める。
測距する場合、機上TACANは質問信号を送信する。これを受信した地上TACANは、応答信号を発する。応答パルスを1回返した地上TACANは、次のランダムなパルスを一つ飛ばす。これによって2700パルスペア/秒を維持する。
機上TACANは150パルスペア/秒以下(ただし135Hz付近は避ける)のランダムなタイミングで質問を送る。地上TACANからはランダムな2700パルスペア/秒の応答が帰るが、この内のいくつかは自身が送信してから一定時間後に届いている。この一定時間後に届く応答を見つけることで距離を確定する。一旦距離が決まれば、以降は2パルスペア/秒程度で測距値を更新し続ける(DMEインテロゲータは最大30パルスペア/秒まで、通常は25Hz)。
TACAN/DMEトランスポンダは2700パルスペア/秒を応答できるから、インテロゲータが25パルスペア/秒で質問した場合は108機まで同時に応答できる。150パルスペア/秒も相手にするなら、例えば5機で750パルスペアを使うから、残りの約2000パルス分を配分して80機程度がキャパシティになる。これがDMEの容量。TACANの場合は測距の頻度が低いから、例えば15機のサーチ(2250パルスペア/秒)と225機のトラッキング(450パルスペア/秒)を提供できる。
TACAN/DMEは2700パルスペア/秒程度で設計されているので、これを超える質問が送られた場合は、受信機の感度を下げて、原則として遠くの機体から順に無視するようになる。
TACANが、質問がなくても常に2700パルスペア/秒の応答信号をランダムに出力するのは、測角に必要なため。
A/A TACANは通常のTACANとほぼ同じものだが、XチャンネルもYチャンネルの周波数を使うという違いがある。また、A/A TACANでは2機間で測距する場合、それぞれチャンネルで63の差を設定する。例えば編隊長機は16X、それ以外の編隊機は79X、というような具合。この場合、通常のTACANとは異なり、16Xは1040MHzで送信し1103MHz(16Yの周波数)で受信し、79Xは1103MHzで送信し1040MHz(79Yの周波数)で受信する。自分の送信周波数と相手の受信周波数、相手の送信周波数と自分の受信周波数が同じなので、1組の送受信機で信号をやり取りできる(Xペアの応答周波数を使う場合、飛行機1機辺り2組の送受信機が必要になる)。
TACANは252チャンネルあるが、A/A TACANでは1組辺り2つのチャンネルを使うので、実効で126チャンネル(X63+Y63)から選ぶ。
編隊機は相手が単一(隊長機)だから、その機に対する距離を測定することができる。対して、隊長機は相手が複数いる場合、いずれの機に対して測距するかはわからない。特定の編隊機だけ先にA/AをONにして、それにロックしてから他の機もA/AをONにすれば、最初にロックした機体を追尾するが、他の機が同じ距離になった場合に別の機を追尾する可能性は排除できない。
TACANは最大1000km程度まで届くから、この範囲内で他の機体がA/A TACANを使用していた場合、誤った距離を測定する可能性がある。A/A TACANを使用する場合は相手との距離を推定しておき、誤った相手にロックした場合は手動で再起動する必要がある。地上TACANでも同様だが、原則としては同じチャンネルが近所に設置されることはないはずだから、あまり問題ないはず(移動型のTACANを設置して十分に確認せずに起動した場合などはこの限りではない)。
A/A TACANでは原則として測距のみを提供する。相手から質問信号(パルスペア)を受信すると、それに応じて応答信号(単一パルス)を返す。測距のアルゴリズムは通常のTACANと同様。サーチして、トラッキング。自分の質問に対する応答と、相手の質問は同じ周波数を使う。A/A TACANでは質問が2パルス、応答が1パルスだから、質問と応答を誤認することはない。
地上TACANとA/A TACANは、Xチャンネルは応答周波数が異なり、Yチャンネルは質問パルスの形式が異なるため、地上TACANとA/A TACANが混在した環境でも、誤ってロックすることはない(地上TACANとA/A TACANで同じ番号のXチャンネルを使っていた場合、両者は別の周波数で応答する)。
測距onlyの場合は質問に対して応答を返すだけなので、消費電力はかなり少なくて済む(まあ、尖頭電力はかなりでかいとはいえ、パルス幅はたかだか数マイクロ秒なので、フルスペックのTACANでも綺麗にパルスを出せば大した消費電力ではないはずなのだが)。
大型の航空機だとA/A TACANでも測角ができるものもある(一部の空中給油機など)。測角を提供する場合、消費電力の問題だけでなく、適切なビームパターンを持ったアンテナ(回転型あるいは電子的に回転できるもの)も必要になるから、アンテナ自体がかなり大きくなる(測距だけなら小さいアンテナ1個で済む)。どちらかといえば物理寸法のほうが問題になりそう。
A/A TACANに使用する周波数(チャンネル)は任意に設定していいはずだが、とはいえIFFに使用する1030MHz(6や69Y)や1090MHz(66)、その周辺のチャンネル(上下5本程度)は避けたほうが賢明。もっとも、IFFとTACANはパルス波形が違うから、同じ周波数を使っていたとしてもそれで味方として判定されなくなる(敵機判定される)とか、TACANが使えなくなる、というわけではないはずだが。
1GHz付近の周波数はたぶん第二次大戦中のIFFに端を発して航空機が占有しているんだろうけど、それにしても962MHzから1213MHzまでを占有しているって、ものすごい既得権益というか。しかも周波数間隔1MHzとかだし。現代の過密な電波環境からするとアホみたいに無駄な使い方をしている感がある。/* 帯域幅だけでいえば、テレビだって日本だと470-710MHzまでの広大な範囲を占有しているけど */
VORも108-118MHzまでの10MHz幅を使っているけど、TACAN/DMEに比べればまだ大人しい方。今の時代にVHFの10MHzを開けたって大したことに使えるとも思えないしな……
*
https://commons.wikimedia.org/wiki/File:DC9_ATC_Transponder.JPG
JALの博物館に展示されていたDC-9のトランスポンダの写真。
しれっと「ABCD」とか書いてやがる……
https://www.oncealoft.com/product-page/generic-transponder-1
DC9のトランスポンダと同じ製品かな? 特に説明は書かれていない。
「黒色の汎用トランスポンダ」だそう。動作保証無しで125ドル。
ABCDでコードを返せるトランスポンダ、実は結構普及していたんだろうか?
ABCDノブの下にはALT RPTG(altitude reporting)のスイッチがあるから、おそらくモードCで高度も返せるんだろうけど、ノブでモードCを選んだ場合はどうなるんだろうか。
***
アルゴリズムの動作例で、ピボットの選択、長さ8で左から4個目、長さ6で左から4個目をピボットとして選んでいるけど、これってどういう基準で選んでいるんだろう? 長さ8で左から4なら長さ6で左から3、長さ6で左から4なら長さ8で左から5、を選ぶべきだと思うんだけど。アルゴリズム的にピボットを選んでるわけではなく、天下り的に(説明しやすいように)位置を選んでいる?
int[]のパーセンタイル値の取得、Google AI曰く「その程度のサンプル数ならソートして取ったほうが楽だよ」とのことだけど、実際のところかなり重いので、クイックセレクトを実装してみた。結果、トータルの処理速度が2倍程度早くなった。ついでに、初回のピボットに、前回のパーセンタイル値をヒントとして渡してやると、さらに1割くらい早くなる。
書いたコードをGoogle AIに見せると、「テメーのコード非効率だぞ」つってif増やしまくった改善コードを見せてくる。いくら投機的実行を信用しているからとはいえ、明らかに不要なifまで増やすのは無駄だと思うんだけど。。。雑用AIなんて所詮この程度よな。
今回作ったやつはTCPサーバー機能も実装して、dump1090の30002ポートと似たフォーマット(少なくともADS-Bに関しては互換)だから、今回作ったやつ用のクライアントを作れば、dump1090からもデータを受けることができる。非ブロードキャストメッセージ(CRCがゼロにならない)とかSIF(概ねモード3/AもしくはモードC)に関してはdump1090からは取れないけど。高度やコードはADS-B系メッセージからも取れるはずだから、それに対応しておけばAirspy R2の受信機を走らせていないときでも、RasPiで常時受信しているものを流用できる。
ということで、次はクライアントの作成かな。これは現行のSIF専用受信機と同じような雰囲気でいいはず。現行のやつはTCPでrtl_tcpに接続してデコードしてコードや高度を表示しているけど、GUIはほぼそのまま使える。モードSだと気圧高度の分解能が改善しているとかの違いはあるけど、そのあたりは適当に丸めて100ft単位で扱うとか。
せっかくモードSを使うんだからもっと色々表示したいけど、そんな事を考え始めたら決まるものも決まらないのでな。。。
