“宇宙からの信号”解読ゲーム『Signal Station』発表。レトロ機材を駆使して波形分析、政府や陰謀論者も狙う秘密のシグナル - AUTOMATON
時代設定が1984年だそうで、野辺山45mとほぼ同時期くらいの感じかな。新しい望遠鏡をSETI的に使うのは難しいだろうから、実際には古い施設を使っている可能性もあるけど。そうするとパークスくらいの時代かもしれない。プレイヤーが信号をトラッキングし続ける必要があるならパークス前、自動追尾してくれるならパークス後、位の時代か。実際に遊んでみればいろいろわかるんだろうけど、テザーだけではどうにも。
あの…… パナソニックさん…… その……
興味本位でGoogle AIにモバイルバッテリーの発火確率(自然故障由来)を宝くじ換算してもらったところ、1000万円が当選する確率くらいだそうだ。うーん、よくわからないや。でもまあわりあいありえそうなふんいきではあるかな。
某書のあとがきに書いてあった、量子コンピュータが普及した時代の量子ネイティブの人間は感覚的に量子論を理解できるはずだ、みたいな話、僕としてはそこまで楽観できるとは思えないんだよなぁ。現代の古典コンピュータネイティブの高校生や大学生で、スパコンやスマホの動作原理を適切に理解している人がどれくらいいるのか。理系の大学生でスパコンを使っているような人でも、全員がその仕組みまで理解しているというわけではないはず。もちろん古典コンピュータの動作原理を詳細に理解している大学生というのはいるだろうけど、そんなこと言ったら量子論をある程度正しく理解している大学生だって今の時代(非量子コンピュータネイティブ世代)でもいるはずだし。
古典コンピュータで使われている信号は量子を統計的に見たものだから自由度が高い(ビットの表現が自由)、あるいはそれを扱う方法(半導体、真空管、機械式、etc)が大量にあるのに対して、量子コンピュータはQubitの自由度がかなり低い(少なくとも大量の量子を統計的に扱うようなことはしない)みたいな違いがあって、量子コンピュータのほうがより理論的だから理解がしやすい、みたいな可能性はあるけど。
Gmail、署名&暗号化されたわりと重要なメールをフィッシングメール扱いして迷惑メールフォルダに突っ込むの、アホ。おまえが署名必須化で引っ掻き回したあげく署名を信用しないって、なんのために署名必須化させたんだよ。かと思えば迷惑メールを重要なメール扱いすることもあるし。
去年の12月に急に話題になったような気がする、「Gmailが来年の1月から外部メールを受信できなくなる」騒動、「1月から受信できない」というのを「1月に入ってからは受信できない」と解釈していたのだけど、1月に入ってもまだ外部メールの受信が続いているし、じゃあ「1月中に受信できなくなる」or「1月末に受信できなくなる」という意味かと思っても、2月に入っても受信が続いているし、一体何だったんだ、という感じ。
ビッグテックと呼ばれる企業(e.g. GAFAM)の中でもGoogleは頭一つ飛び抜けて広い範囲に迷惑をかけている(混乱を振りまいている)気がする。まるでバベルの塔にキレた神の如き。これがインターネットの神か……
Webサイトの広告、基本的に目を引く(要するにウザい)広告が多いけど、最近は「数秒の広告を視聴すると24時間表示されなくなります」系の広告が結構普及している気がする。で、この広告の何がウザいかって、多くて1週間に2,3回しかアクセスしないサイトに設置されている場合に、毎回必ず見なきゃいけないという点。
Webサイトの3秒ルールとか言われていたのは大昔の話だけど、5秒って。。。しかも読み物系とか報道機関みたいに一つの記事をある程度時間をかけて読むようなコンテンツなら5秒のロスも許容できるかもしれないけど、ちょっと気になってググって、しかもテキストを2,3秒流し見するだけで確認が終わるようなコンテンツに対して、5秒の待ち時間はさすがに無理。Ctrl-Wで閉じて別の検索結果を見るほうが早い。広告は見られないし、Webサイトのコンテンツも見られないし、読者は手間が増えるし、誰も得をしていない。
特にそれがIT系の解説サイトだったりするとな。おまえなんのために高いカネ払ってレスポンスのいいサーバー使ってんだよ、クソみたいな広告出すくらいならページの表示に4秒くらいかかるような遅いサーバーでもいいから安いやつ使って広告減らせよ、という気になる。
自分は基本的に検索結果から気になるサイトを2,3個新しいタブで開いてから、そのタブを確認する、みたいな見方だから、バックグラウンドで読み込んでくれる分には読み込みに5秒とかかかってもあまり気にならない。一方で必ずタブを5秒以上表示しないとメインコンテンツが見れない、みたいな広告はかなり苦しい。
最近はサイト内リンクの枠を全部含めても面積比で広告のほうが多いWebサイトとかも目につくからなぁ。それに比例してコンテンツの内容も質素になっている気がするし。やはり資本主義は悪……ッ!!!
厚さのあるガラスの両面にQRコードを印字して姿勢を高精度に求める、みたいなブツの空想。
ガラスの両面に吸収スペクトルの違うQRコードを印字する。裏表で同じ位置にQRコードが貼り付けてある。このコードをカメラで読み取ると、2つのQRコードが重なった状態で認識される。ただし吸収スペクトルに差があるから、例えばRedとBlueで読み取ることで手前側と奥側を識別できる。
QRコードを認識する際にドットの位置を精度よく認識することで、QRコードの姿勢を解析する。この方法の場合、上下左右の位置と奥行き軸の回転の3自由度は高い精度が得られるが、奥行方向の位置や上下左右軸の回転感度は低い。提案手法の場合、奥行方向にQRコードが重なっているから、ドットの位置関係を利用することで上下左右軸の回転に高い感度を持つ。同様にして奥行方向の位置にも比較的高い感度を持つ。
QRコードの中身にはQRコード自身の物理量を入れておくことができる(例えばマーキング対象の物体に対する位置・姿勢を行列やベクトルの形で保存する)。他にも、マーキング対象の物体自身に関する情報(商品名や部品名、部品のロットやシリアル番号等)も保存できる。
透明な媒体を画像認識するので、1回の撮影で非接触かつ高い精度で相対姿勢を把握することができる。という利点はあるが、具体的な用途として何があるかというと…… 大抵の場合は複数のコードや複数のカメラで解決できるからなぁ。
***
RJ45の安い圧着工具を買ってみた。工具とテスタだけかと思ったら圧着端子とブーツも100組くらい入っていた。これでお値段3000円台前半。こわい。
工具はオープンのスプリングが入っていて、閉じた状態で固定するラッチもないし、テスタもめちゃくちゃ安物っぽい雰囲気だけど。コネクタもどれくらい信用していいのかわからないけど、とはいえ今の時代LANケーブルの圧着端子なんてだいたい中国製の安物だろうしなぁ…… 練習のために組むなら問題なし。
Cat5eはAmazonベーシックの50ft(15.2m)で1000円というめちゃくちゃ硬いやつを切って使用。単価66円/m程度なので激安の箱売り(30円台前半/m～)に比べて安いわけではないけど、普通の箱売り(80円/m前後)に比べれば安いし、そもそも1軒家にLANケーブルを引き回したいわけではないので、箱買いする必要もないし。
ということで、適当に結線して遊んでみたり。
ツイストレートは青、緑、橙、茶の順かな。青が2.9TPI、茶が1.5TPI、くらい。
下においてある5本は、左から、4ペアストレート、2ペアストレート、2ペアクロス、4ペアクロス(2クロス2ストレート)、4ペアクロス(2クロス2クロス)、という感じ。普通の4ペアクロスは2クロ2スト(橙緑がクロス、青茶がストレート)で結線されている。
568Bで結線する場合、コネクタを上に向けて爪側から見た場合(下段の5本の上側コネクタの状態)に、右端(1番ピン)から橙、その次が緑。ただし歴史的な事情?で中央の2ピンを飛ばすから、10BASE-Tや100BASE-Tのように2ペアだけ使う場合は1,2,3,6ピンを使う(下段の左から2本目)。1000BASE-Tのために4ペアが必要な場合は、飛ばした中央2ピンに青と残りに茶。
被覆がストライプになっている線が正極で奇数番、ソリッドな線が負極で偶数番。緑が飛ぶので青は逆になるけど、基本的には右側にソリッドを入れる。
コネクタを上に向けてコンタクト側から見て左が1番ピンだけど、コンタクト側から見ると金属で線が見づらくなるから、爪側から見たほうが見やすい気がする。あと、ちゃんと奥まで刺さっているかを見るには爪側から見たほうが確実。線を押し込んだと思ったら1本入ってなくてコネクタの中で折れ曲がっていた、みたいなこともある。この場合、2分の1の確率で100BASE-Tで接続できてしまうので、気が付かずに使っていると速度が出ないということになりかねない。
568Aは橙緑がクロスする(青茶は基本的にクロスしない)。
568のピンアサイン、橙緑青というのは覚えなきゃいけないけど、ストライプ/ソリッドの順番は奇偶で決まっているし、わりとわかりやすい気がする。10回くらい圧着すればだいぶ慣れてくる。橙緑青茶は色相で見ると順番に並んでいるから、それで覚えるという手も…… ちょっと厳しいか。
緑が飛んでるのは、電話用のモジュラージャックみたいに中央を使っていたやつに配慮して、ということだと思うんだけど、帯域幅を広くして使おうとするとクロストークとか大変そうだなー。今更順番に並んだコネクタを作ろうという話にもならないだろうしな。
2ペアのストレートケーブルをテスタで見てみたら、正しく親子機両方で1,2,3,6が結線されていると表示される。一方で、2ペアのクロスケーブルをテスタで見ると、2-6,3-1,6-2が表示され、1-3の結線が検出されない。
普通のクロスケーブル(4ペア結線、橙緑だけクロス)では、1-3,2-6,3-1,4-4,5-5,6-2,7-7,8-8と、正しく表示される。
橙緑と青茶をそれぞれクロスさせたケーブル(一般的ではない4ペアクロスケーブル)を作ってみると2-6,3-1,4-8,5-7,6-2,7-5,8-4として表示される(1-3の結線が検出されない)。
2ペアおよび4ペアのストレートと4ペアの一般的なクロスの3種類は正しく見えるかな。安物のテスタなので、一般的ではないケーブルは適切に処理できないっぽい。あくまでも正しく結線されているかどうかを確認するためのもの。まあ、普通はそういう製品で十分だしな。
上の写真に写っている5個のケーブルは、スイッチから4ペアストレートで引いてきて、Cat5e中継コネクタ経由でノートPCに接続して、オートネゴシエーションで認識させれば、正常に動作する。2ペアしかないものは100BASE-Tとして正常に動作するし、4ペアのものは1000BASE-Tとして正常に動作する。少なくとも、簡易的なスピードテストで見る限り、2ペアは100Mbpsギリギリまで出るし、4ペアのものも100Mbpsを超える速度は出る。といっても、回線があまり早くないので、せいぜい150Mbpsとかその程度だから、実は大量に不良パケットが発生していても、気付けないわけだが。
*
ケーブルテスタの中身
左側が親機、右側が子機。
子機はRJ11とRJ45のコネクタに、LEDが9個、ダイオードが3個、というシンプルな構成。
親機はRJ11とRJ45にLEDが10個、ダイオードが5個、抵抗が2個、スイッチが1個、COBが1個、という構成。面積広めのパターンがポツポツ膨らんでいるのが謎い。ベーキングせずにリフロー炉に入れて剥がれてきてるとか?
***
STM32F1/W5500でNTPクライアント。割り込みをタイマで受けて送信時刻と受信時刻を高精度に(マイクロ秒程度で)計測。試しにCloudflare、AWS、Googleの3サーバー(IPアドレス固定)に対して10分程度の間隔(5-15分のランダム)で計測。
マイコンが起動した時刻を原点として、θはNTPに対するマイコンの遅れ時間を、δは通信遅延を計測。いずれの軸も単位は秒、ただしθ-1次の右軸はミリ秒。
θはマイコン起動時のNTP時刻に相当する量がオフセットされている。傾斜はマイコンのクロックエラー成分が見えているもの。傾きは12.8ppmで、通常の水晶のクロックエラーに矛盾はない。正の値から減少しているので、水晶が早い方向。
θ - 1次はマイコン(水晶)の時刻ズレやクロックエラー成分を大雑把に除去したもので、クロックの変動を示している。ただしそれぞれ数msずつオフセットしている(平均値はオフセット無し)。基本的には温度特性だと思うけど、温度は未計測なので詳細は不明。やはりこういうものを測るときは温度計も必須だな。体感(&タイミング)的には温度が上がると減少幅が減るので、おそらくATカットの0℃付近から40℃付近までのカーブを見ているんだと思う。冬の北海道なので、もっと暖かい環境なら誤差はもう少し小さくなるはず。
δは通信遅延成分。NTPサーバー内の遅延は除去済みだが、最近のNTPサーバーはほとんど遅延なしに応答を送ってくるので、基本的には送受信の間隔。遅延は国内サーバーと想定されるCloudflare/AWSは安定、おそらく海外サーバーのGoogleは若干不安定。
θ - 1次を見ると、CloudflareやGoogleはノイズが見えるのに対して、AWSはノイズが少ない。
平均値を見ると、AWSとGoogleはほぼ重なっているが、Cloudflareは明らかにバイアスがある(前にPCで複数のNTPサーバーを比較した際も、Cloudflareはバイアスがあった)。
下の方にはAWSから見たCloudflareとGoogleの差を表示している。Cloudflareは2-3ミリ秒程度のバイアスがある。Googleは±1ms程度、大抵の時間は±0.5ms程度に収まっている。一方で、振幅を見ると、Coudflareは比較的狭い範囲で、Googleは若干広がって出ている。これはサーバーまでの経路の問題だと思う。AWSとかNICTみたいに国内にある信頼性が高いであろうサーバーを参照する場合、NTPの精度は頑張れば0.1ms程度までは期待できるかな。確度はまた別の話(AWSはスミアリングもあるし)。
今回は高頻度にNTPサーバーに取りに行きたかったので、日系法人サーバーには触らなかったけど、気兼ねなく高頻度に叩けるNTPサーバーとしては、Cloudflareは明らかにバイアスがあり、Googleは海外サーバーであることを考えると、AWSが一番いいかもしれない。
AWSはクラウドサービス大手として安定したシステムを構築したい、という前提があって、それのタイムスタンプを流用したNTPの性能も良い、と考えることもできそう。そう考えるとMicrosoftもAzureを提供しているので、それと比較しても面白そう。ただMicrosoftやAppleはあくまでも自社のOS向けのNTPサーバー起源だと思うので、時刻精度をどこまで追求しているかは怪しい気もする。
NICTみたいに精度が高いであろうサーバーと比較したりするべきなんだろうけど、いちおう頻繁に叩くなよと明示されているからなぁ。1日480回以内だから10分間隔(1日150回程度)なら怒られることはないだろうけど。
あとは、GPSモジュールのPPSで時刻決めしたさもある。タイマの外部入力ピンに1PPSを接続して、1秒の曖昧さは無視する、みたいなことをやるのが一番手軽ではあるけど、PPSを出せるGPSモジュールか。。。
タイマを時刻基準にするとマイコンのリセットで原点が動く欠点がある。本来はRTCみたいにコアリセットには影響を受けない時刻系を使いたいんだけど、STM32F1のRTCは結構使いづらそうな感じ。でもF1のRTCは32bitカウンタとプリスケーラが入っているだけなので、読み書きに注意すれば、NTPみたいに元期からの経過秒数を扱うシステムとは相性がいい(ただし32kHz分解能)。F4とかだとカレンダ機能が載っているから、NTPと比較するなら年月日時分秒を変換する処理が必要になる。
一番手っ取り早いのは、適当なマイコンで1MHzと1PPSのクロックを出して、適当なタイミングで次の1PPSの時刻をUART等で出して、時刻の基準はそれで決めて、NTPみたいにソフトウェアを書き換えたい(コアリセットをかけたい)用途のマイコンとは切り離して、みたいな感じかな。なんか冗長な感じではあるけど。
10MHz+1PPSを出すようなクロックは色々な市販品があるから(e.g. GPS受信機)、それに組み合わせるタイムコードの標準とかも探せばあるんだろう。そういうのに従うのが楽だろうけど、STBeeMiniで10MHzは作れないのでな。。。STM32F1のPLLは大部分が2^Nで指定するので、12MHzのクロックを積まれると使いづらい。8MHzを積んでいてくれたらありがたかったなぁ。
IRIGタイムコードは基本的に高周波(10MHzとか)とは無関係なはずだから、1MHz+IRIGみたいな組み合わせをやってもいいんだろうけど。
*
DNSやNTPはanycastで実装されているものが多いので、例えば1.1.1.1や8.8.8.8で別の地域にあるNTPサーバーを調べることはできないし、別の国のISPが提供しているその地域向けのDNSサーバーに問い合わせても、time.google.comやtime.cloudflare.comは同じIPアドレスを返すから、そのNTPサーバー(IPアドレス)に問い合わせを行っても、やはりインターネット地理的に近いサーバーからの応答が帰ってしまう。
time.aws.comはNTPサーバーごとにIPアドレスが別れているらしくて、おそらく別の国にあるであろうDNSサーバーに問い合わせを行うと、ユニークなIPアドレスが得られる(実際にNTP問い合わせを行って遅延を確認したわけではないけど)。
GoogleやCloudflareはとにかくサービスを提供できればいい、そのためには1箇所のデータセンターが死んでもIPアドレスを変えずに別のデータセンターに到達できるanycastが良い、みたいなことなのかもしれない。IPアドレスの割当や管理の手間も省けるだろうし。
対してAWSはそもそもAWS内で高精度な時刻が欲しい、という要求が先にあって、そのあとでNTPを公開したから、NTPに関しても問い合わせ先がIPアドレスに紐づけされていて、場合によっては勝手に別のデータセンターを参照してしまう(精度・確度が変動する可能性がある)anycastを避けた、みたいな理由があるのかな。
海外のDNSサーバーも、例えばその地域で有力なISPのDNSのIPアドレスを調べても、nslookupでタイムアウトするということもある。自分たちがカバーしていない地域(or自分たちと契約していない回線)からのアクセスは捨てるみたいな処理があるのかも。
ということで、大手IT企業が提供するNTPサービスで、他の地域のサーバーに取りに行くのは結構大変そう、という雰囲気。
そもそもNTPは直近のサーバーを使うべきだという話なんだけども。
***
Flightradar24から「おまえんとこのフィード止まってるけど?」とのメール。ここ数年は安定して稼働していたので、かなり久しぶりだ。
古いRasPiで走らせていたやつで、microSDから工夫なしに常時起動なのでそろそろ寿命かな、ということで、別のmicroSDにOSを焼いて初期設定をいろいろやったのだが、どうにもうまく行かない。うーん、困った。結構前にも同様の事象があって、そのときはOSの入れ替え等で直ったんだが。
なんか動作が遅い気がする(例えばログインIDを入力してからPassword:の文字が表示されるまでにかなり時間がかかる)ので、RasPi本体側もなにか不具合があるのかな、と当たりをつけつつ、どうしたものかと思いながら在庫を漁ったら、大昔に買ったRasPiがあったので、それにOSを入れ直し。10年以上前に買ったやつだと思うが、あの頃って何故か色々大量に買い込んでたのよな…… あの頃のバイタリティ(&金銭感覚)がかなり謎い。最近はマトモ(流通ルート含め)な電子部品は1個も買ってない気がする。
別のRasPiにインストールした方はだいぶ軽い気がするけど、でも通常版RasPiOSとRasPiOS Lightの違いな気もする。とはいえ、前のRasPiはapt upgradeを何回やっても完了しなかったのが一発で終わったり、だいぶ安定に動いている気がする。GUI側と競合してただけでは?とか考えるとやっぱりOSの違いなだけのような気もするけど。
しかし、OSの更新やらフィードの設定やらがすんなり終わっても、やはりステータスを見るとオフラインのまま。
topで見るとfr24feedがS(Sleep)になっている。でもtopの説明だとSはイベント待機とかの状態らしいし、よくみるとまれにCPU使用率が0.0より大きくなるから、たぶん動いているはず。ではなぜfr24に上がらないのか……
そもそも、大昔のRasPiでたかだか0.5％未満のCPU使用率でADS-Bがデコードできるとも思えない。fr24feedってdump1090のデコード結果を投げるようなものだと思うけど、topを見る限りdump1090が走っていない気がする。
どうせaptで取れるやろ、と思って試してみるも、入らなかった。だからfr24feedも正常に動作していないのかな?
ADS-B受信をdump1090-faに変更 | My Blog
を参考にソースからビルド。ただしこのブログのコマンド列は順番が逆で、先に2個目のapt install(引数が少ない方)を打ってからget cloneで取って、ビルドとインストールを行う(少なくとも先にgitをインストールしておかないとgit cloneはできない)。
systemctlでdump1090-faを開始して念の為にreboot。topを見るとdump1090-faのCPU使用率が50％超、PCからデバイス名.local:8080を開くとPiAwareの画面が表示されるので、少なくともサーバーは動いている。デコーダが動いているかどうかは不明。相変わらずオフラインのままだし。
topでCPU使用率のusとsyの和がほぼ100でidがほぼ0なので、処理に余裕がない。処理に余裕がなくてfr24feedが正常に動作していないのかも。
漁っていたときに見つけていた、一つ新しい版のRasPiに変えてみた(元々走っていたのと先に交換したのがRasPi1B+、新しいやつはRasPi2B)。
先に上述の手順でdump1090-faを入れてから、Share your ADS-B data - Real-time flight tracker | Flightradar24 のコマンドでfr24feedをインストール。初期設定はメールアドレスとシェアリングキーを設定。先に入れたdump1090が認識されるので、それでフィードが始まる。はず。これによってtopが88.4 idと、かなりの余裕が見える。単純にクロックが2倍になっただけでなく、コアの効率も良くなったんだろう。
Fr24のMy accountだとすぐにOnlineになったけど、Statisticsで見るとOfflineのまま。どうしたものか。
その後数時間ほど放置してから確認すると、STATUSはOfflineのままだけど、10nm程度だけどいくつかレポートが上がっていたので、最低限デコードしてレポートは動いているはず。いくつかの方向にはレポートが全く出ていないとか、レンジが狭すぎる気もするけど、そもそも普段は定期便が数時間に1本通る程度しかトラフィックのない場所だから、その機体が家から10nm程度の場所を通過した、位の意味だと思う。長時間受信していればもう少し分散するはず。
その後、航空機が通過しているときに再読込したらSTATUSもOnlineに戻っていた。fr24feedはUDPでパケットを投げているのかな? おそらく投げるデータがないときは何も投げていないんだと思う。ハートビートも無いだろうから、サーバー側からすると受信機側で航空機が見えない時間帯はOffline扱いになるんだと思う。世界中に大量のクライアントが置いてあるから、いちいちクライアントと全部コネクション作ってたら大変ってことなんだろう。
さらに数日放置してみると、ちらほらとレポートが上がっているので、たぶん動作しているはず。相変わらず時々Feeder outage notificationのメールが届くのが謎。最近は全く届いていなかったんだけどな。メールを探してみると前に届いたのは2022年11月なので、5年以上安定して動作していたのか。すごい。その間に停電で1回止めているから、数十分止まっている程度なら通知は出ないんだな。
最近になって急に届くようになったのが謎いけど、航空便の運用の変更で深夜帯にレポートが出なくなって、それでFr24側でタイムアウト判定された、みたいなことなのかな? そう考えると、最初のオフライン通知も実は誤報で、RasPi自体は正常に動作していた可能性もあるのか。まあ、今更気にしてもしょうがないし、更新のいい機会だったと考えよう。。。そんなこと言ったら10年以上使い続けているワンセグチューナーも更新しろよ、って話になるんだけど。気が向いたら安い受信機を1本注文しようと考えつつ、でもRTL-SDR blog v3ドングルも手持ちにあるので、イザとなればそれを使う方向で。どうせ必要になるまで買わないんだろうなー。
ということで、おそらくfr24のフィーダは復旧。
とりあえず、RasPi1B+で最近のdump1090を走らせるのは無理、RasPi2Bなら結構余裕、自分で古いRasPiでセットアップするならdump1090はgitからビルドする必要がある、fr24feedの初期設定はdump1090をインストールしてから、といったあたりが、今回得られた知見。
そもそもRasPi3B+以降を使っていればFr24公式のイメージが使えるはずだから、イメージを焼いてシェアリングキーを設定するだけで使えるようになるんだろうけどな。でもRasPi4の値段高いよ。。。Fr24のGoldプラン約1年分(アンテナや電源等の周辺機器を含めれば約2年分)と考えれば、長期的に使えば元は取れる値段ではあるのだけども。
topで表示すると、dump1090-faもfr24feedもS(Sleep)のまま、dumpは46%CPU程度、fr24は0.3CPU%程度の表示。基本的にイベントドリブンなのでtopでサンプリングするとSleepで固定らしい。idは88%程度の表示。topのタスクは1コア相当、Cpu(s)は全コアのトータルらしく、RasPi2Bのクアッドコア換算では1つのコアを45%使うと残りは88.75%になる、ということで、数値としては正しそう。dump1090-faは2倍程度重くなってもまだ耐えられるし、別のスレッドの処理は別のコアに割り振られるから、Webサーバーが走っていても問題なし、ということだと思う。
試しにSkyAware(8080ポートのやつ)を見ていたら、自前のMark Xデコーダよりはるかに遠くから受信が始まっていた。Mark Xは誤り検出が無いから閾値を厳しめに設定していて、Mode-Sは誤り検出があるからアグレッシブにデコードできる、という違いなんだろう。無線みたいにダイナミックレンジが広い伝送媒体の場合、FECまでいかずとも、誤り検出があるだけでも伝送レートが格段に上がるな。
Mark Xも適当なフィルタ(一定時間で一定個数受信しないと表示しないとか)で閾値を下げればもう少し遠くまで見えるんだろうけど。でもATCレーダの回転周期が数秒、ACASのインテロゲーションが1Hz程度であることを考えると、閾値は30秒で20個とかだろうから、最初に出てくるまでにかなり遅延がありそうだ。
ADS-Bでは、頻度は低いけど、たまにほぼ200km先から受信していることもある。飛行高度2万ftとして電波の見通し距離は300kmくらいになるから、水平線まで障害物がなければ200kmくらいは届くのかもしれないけど、それにしてもチャチなアンテナ1本でアンプもなしにそんなに見えるものなのか。
あまり関係ないだろうけど、RasPiがWiFi APのハブ経由でGbEハブに接続されていたので、以前使っていたGbEハブを追加してそれ経由で接続。8ポートのハブ1個じゃ足りない。。。2個のハブを重ねて置いたので、10cmに満たない短いパッチケーブルを作成。実用のケーブル作成には使わないから……と思ってたけど、工具があれば使うんだよな。
Amazonベーシックのケーブルはさすがに被覆が硬すぎるので、もう少し柔らかいケーブルを買っておいたほうがいいかも(今回は超短距離なので外皮を剥がして使用)。長距離を引くわけじゃなくて、ハブ-機器間のせいぜい2mとかのケーブルを作るだけなら、10mくらいのケーブルをストックしておけば良さそう。
***
fl2kを使おうとしてC#でDllImport経由で叩いているんだけど、fl2k_closeを呼ぶとExecutionEngineExceptionが出る。
C#が悪いんかと思ってcygwinのdlsym経由で呼んでみても、やはりfl2k_closeでSegmentation faultが出る。
fl2kからはバッファに突っ込んだ波形が出てくるから、fl2k自体の操作はできているはず。あくまでもfl2k_closeだけが正常に動作しない。デバイスが閉じられないだけであって、使えないことはないけど、ちょっと気持ち悪い。
試しにWindows11/MinGW環境でビルド。pacmanでいろいろ入れて、buildの中でcmake ..やってninjaを実行。ただしgetopt周りがうまく動かない。今回はDLLが欲しいだけであって、実行ファイルは必要ないので、CMakeLists.txtの中のBuild utilityをすべてコメントアウト。
libosmo-fl2k.dllが作成されるので、試しにdumpbinに突っ込んでみると、一通りの関数が見える。libsomo-fl2k.cに適当な関数を作って再度ninjaとdumpbinを叩くと、追加した関数が追加されるので、正しくビルドできているはず。
試しにcygwinでもビルド。何を入れたか覚えてないけど、git, cmake, gcc, g++, libusb1.0-devel、あたりかな。cygwinだとCMakeLists.txtやソースコードの変更もなく、ただcmake ..とmakeだけでビルドできた。足りないライブラリがあればcmakeでエラーが出るからそれを入れる。出てくるdllがcygosmo-fl2k-0.dllという名前だから、cygwin用の最適化なり設定なりが入っている可能性もあるけど、少なくともdumpbinからは見えるから、大丈夫なはず。
気まぐれに、というか、どっちもlibusbやろ、という短絡的な理由でairspyone_hostの開発環境にならってMinGWを最初に試してみたけど、最初からcygwinで試せば簡単だったな。
cygwinのgccでlibosmo-fl2k.dll.aを指定して、exeと同じ場所にdllを置いてやれば、osmo-fl2k.hをインクルードして呼び出せるので、dlopenでパスを指定してdlsymでポインタを取ってキャストして、みたいな手間はない。ただ、今回の場合はosmo-fl2k.dll側をゴリゴリ書き換えたいので、dllをexe直下に置くのはちょっと面倒。
Google AI曰く、-Wl,-rpathで探索ディレクトリを追加できるよ、とのことだけど、色々試してみても全く効果がない。Copilotに聞いてみたところ、-Wl,-rpathはELF用のオプションだからEXEには意味がないよ、とのこと。なるほどね。別件で使ったときも含めて、Google AIはハルシネーションが多い印象。
今回の場合はPATHに一時的にDLLの置き場を追加するのが一番楽そう。/* あとから考えるとちょっとやり方ミスってただけっぽい気もするけど、今更掘り返すのも面倒だし、、、 */
試しにfl2kから3chの正弦波を出すサンプルをC++で書いてcygwin/g++でビルドして走らせてみたら、なぜかfl2k_close含めて問題なく動作。あれれー？ ただしlibusb error [31]が出る(正弦波は問題なく出るが)。
ノートPCでビルドしていたので、試しにデスクトップPCに持ってきたら、DLLが見当たらないというエラー。なんでぇ。。。デスクトップ側のcygwinでビルドし直しても、相変わらずDLLが見当たらないまま。なぜだ。。。
これらのDLLをC#から読み込んでみると、Cygwinでビルドした方もMinGWでビルドした方もDllNotFoundException 0x8007007Eが出て関数が呼べない。
難しいねぇ。。。
