羽田の新ルートの南風運用進入が自宅上空5000ftだったのを機会にFR24をよく見るようになりました。 Basicアカウントだと広告が邪魔で困っていましたが フィーダーになれば無料でビジネスアカウントを貰えることを知り受信を決意しました。

ラズパイで運用するのが多数派のようですが 余っていたサブノート(E200HA)にLinux mintを入れてNASを運用していたのでそれを活用することにしました。

よくわからないままにdump1090-mutabilityをビルドし、 fr24feedのdebian版を公式からダウンロードしてインストールしたところ チューナーの認識を除けば動作しているようだったので購入手配へ。 なお、もう動いているので触りませんが、より新しいdump1090-faを入れるのが正解だったらしいです。

まずamazonでR820T2と明記されているものを2000円で購入しました。

4/11注文4/14発送5/7到着。

早速装着してdump1090を--interactiveで起動するもいっこうに受信する様子がありません。 /var/log/dump1090.logを確認すると1090MHz受信不可のFC0012。 マレーシア発送でずいぶん待たされた上に非対応品とは。

期待せずに返品交渉したら返金処理されました。

楽天で同等品をまた2000円で購入。国内発送メール便で届いてちゃんとR820T2でした。

5/7注文5/9発送5/12到着。

ちなみに購入店はファンライフさんです。

対応チューナーを装着して/var/log/dump1090.logを確認するとR820Tと表示。

• ソフトからはTとT2は識別不能
• T2とプリントされた模造品が出回っている

まず付属のアンテナをノートPCの上に適当に置いてテスト。

壁越しの位置で無理だろうと思ったらあっさり受信してびっくり。 自宅マンションが高台の4Fだからかもしれません。 ただし最大距離50nmくらいでほぼ近所数マイルを通る機体しか見えず淋しいです。

fr24にログインするとちゃんとビジネスアカウントに切り替わっています。 まずは目的達成。

付属アンテナを外が見える窓ガラスの上のほうにセロテープで貼り付けてみると コンタクト数が数倍になり最大距離も150nmくらいに改善しました。

Polar plotを見ると窓が東南東向きなので東だけ受信できています。

まあ方角は改善不能ですが、距離は工夫次第で改善できそうです。

dump1090のモニタリングが他で言われているIPアドレス:8080では出ません。 /run/dump1090-mutabilityにはjsonが出来ているのでデータは取れているはずです。 lighttpdは動いているようなので色々試したらIPアドレス/dump1090/で出ることがわかりました。 航跡を確認すると途切れており今一つ安定していません。 受信距離はともかくコンタクト数を増やしたいところです。

/runにすごい勢いで書き込んでいるはずでeMMCが心配になりました。 ラズパイ運用でも対策している人が多いようです。
が、dfコマンドを実行すると/runはすでにtmpfsになっており問題なし。 /etc/fstabではそうなっていないのでdump1090が起動時に何かやっているんでしょうか？ 起動スクリプトを追いかけてみたが発見できず。まあいいことにします。

アンテナケーブルがカーテンに干渉するのでMCXの2m延長ケーブルを追加しました。

ケーブル長が延びたこととコネクタの損失か最大距離が20nm程度下がってしまいました。 なお試しにアンテナをベランダに出してみましたが改善はありませんでした。 設置高さがガラス直貼りより低くなったことが原因と思われます。 あまり考えなしに窓ガラスの高い位置にアンテナを貼り付けていましたが、 高さはけっこう大事だったようです。

なお、感度の確認方法はdump1090で安定し受信できている機体を選択しRSSIを見ながらアンテナを動かしました。

外の高い位置に設置すると改善が期待されますが、 台とエアコンダクトを通す工作が面倒そうなので室内設置の範囲で楽しむことにしました。

dump1090でdistanceが表示されていないことに気が付きました。
/usr/share/dump1090-mutability/html/config.js
のSiteLatとSiteLonが初期設定のままだったので自局位置に修正したところ 地図が出なくなり焦りましたが、 設定を見直したら恥ずかしいことに緯度と経度を間違って入力していました。 修正すると正常に出力されて同心円も出てきました。

ただこれ、config.jsのコメントにはdump1090で設定済みの場合には無視されると書いてあるんですが、実際には有効です。よくわかりません。

付属アンテナは基台のマグネットを鉄板に付けないと感度が低下するらしいので お菓子の缶の蓋をくっつけてみました。

効果は正直よくわかりませんでした。 これだとアースが取れていないのでしょうか。
まあ悪くなってはなさそうなので、紅茶缶を窓に貼り付け、上に乗せてみました。

家族には笑われていますが、非難されてはいないのでよしとします。

fr24で見ているとエンブラエルの航跡がいつもガタつくのが気になっていましたが、 ADS-Bの自己申告ではなくMLATによる位置推定だかららしいですね。 と、/run/dump1090-mutabilityを見ると自分のデータにMLATが出ていないことに気が付きました。 fr24feed.logを確認すると
Receiver not compatible with MLAT, timestamps in wrong format!
とあります。調べてみるとなんか時計の精度を上げるとできそうな気もしますが、 面倒そうだし自局単体ではあまり面白くないので保留としました。

MCXケーブルで延長すると損失が大きいのでUSB側での延長に変更しました。 ノイズ源であるPC本体からチューナーを離す意味もあるようです。

RSSIがさらに3dBほど改善しました。最大距離はほぼ変わらずです。 成田の離着陸機がかなり空港に近い3000ftくらいの低高度で見えるようになりました。 また完全に建物の死角である南西方向の機体もたまに受信するように。

ついでにケーブルの取り回しを下に凸としてみました。 冬場は結露の激しい窓なんですがこれで水滴がチューナーに流れ込むことはないはずです。

安物チューナーの水晶発振器の質は悪く、 最初から微妙にずれておりかつ発熱でどんどんずれていくらしいです。 それを補正するためのパラメータがdump1090のPPMです。

補正値を調べるためにWindowsPCにSDR#をインストールしました。 特にわかりづらいこともなく、ネットに出ている手順通りなので詳細は割愛します。
Linuxに付けたままrtl_tcpでポート1234に接続してもよいようですが、 ちょっと反応が良くなかったのでWindowsPCにチューナーを直接装着しました。

ここで困ったのが基準とする「適当な既知の周波数」というやつ。 どうもこの世界では皆さん無線の知識は当然のようにあるようでどこを参照するかの具体例がないです。 一般人でも知っているFM局に合わせてみるも周波数変調なのでピークがはっきりしません。

ピアノ線の先端がちょっと怖かったのでビーズを瞬間接着剤で追加。 特に感度に変化はありませんでした。

受信環境がサブノートPCなのでそのまま外でも運用可能です。やってみましょう。

うちの近所で最も見晴らしがいいのはここ荒川の幸魂大橋です。 欄干にアンテナを立てて受信中の図。
dump1090の表示がこれ。全方位23機捉えています。これだけ見えると面白いですね。 コロナ禍でこれですから通常時はもっとたくさん見えるんでしょうね。

成田の着陸は1500ftまで、羽田の着陸は800ftまで見えてます。
ただ意外と同じ位置ではRSSIは自宅より悪いです。 遠くもせいぜい150nmくらいまで。 チューナーをPCに直差しなのでノイズを拾っているのか、熱環境が違って周波数がずれているのか。
ちょっと気になったのがこれ。ひょっとすると高圧線直下はダメ？

これまで使っていたdump1090-mutabilityはちょっと旧いようです。 動いているのでまあいいんですが、より新しいdump1090-faに入れ替えてみました。

gitで取ってきてbuildすればそれでいいのかと思えば、ちょっと引っかかったのでメモを残しておきます。

git clone https://github.com/flightaware/dump1090.git dump1090-fa
cd dump1090-fa
dpkg-buildpackage -b

cd ..
sudo apt remove dump1090-mutability
sudo apt install ./dump1090-fa_3.8.1_amd64.deb

念のためにシステムを再起動し、http://IPアドレス/dump1090-fa/で表示が出ることを確認できました。 ちょっと高機能なようですね。

気になったのがRSSIの値がmutabilityと全然違います。が、見える範囲は変わっていないので 単に表示の問題のようです。どっちが正しいかはよくわからず。

なお、config.jsは書き換えなくてもちゃんと正しい位置が参照されました。

コロナ禍でテレワーク中にふと息抜きでdump1090を起動したら、 見慣れないシンボルが銚子沖に。 これはひょっとしてと思って詳細を見るとビンゴでした。

世界最大の輸送機、An-225ムリヤですね。一度は実機を見てみたい機体です。
まあFR24ならいつでも表示できるわけなんですが、自分で直接捉えるとまた格別ということで。

材料に余りが出たので1/2λと5/8λの単純なアンテナを追加して、 受信しながらとっかえひっかえしてみました。
左から、付属アンテナ、アルミストロー＋追加エレメント、1/2λ、5/8λです。

長さは 波長275mm×係数×銅線の短縮率0.96 としました。

どうやら作成したコーリニアアンテナはこれまでで最良の性能があるようです。 他から交換すると有意に受信状況が改善しますし、 FR24のStatisticsでも改善傾向が見られます。
他にも初めて新潟沖日本海の機体を捉えたり、成田の北からの着陸も1800ftくらいまで見えたり、 改善は明らかです。150nm以遠も以前とそう変わらないようです。

ここまで試したアンテナを性能順で並べると、

コーリニア > アルミストロー＋追加エレメント > アルミストローのみ > 1/2λ > 5/8λ >> 付属アンテナ

となります。アルミストローで改善したのはストローの効果ではなく単に長さが1090MHzにマッチしただけ ではないかと疑っていたのですが、ストローに何らかのメリットがあるみたいで怪しさ満点です。

コーリニアは長く重くなってしまったので付属アンテナの小さなマグネット基台では固定が十分でなく、 気が付いたら倒れていたりで長期運用には向かない感じです。 そのうちアルミストロー＋追加エレメントに戻すことになりそうです。

以前SDR#を使ったppmに与える値の調べ方を紹介しましたが、 Linuxだけで調べる方法が分かったのでそちらも紹介します。
わざわざWindowsPCにSDR#をインストールしないで済みますし、 普段と同じ熱環境で調整できるのでより良いと思います。

dump1090を停止してから、以下コマンドを実行します。

rtl_test -p

絵が出てこないので見た目は面白くないですが、SDR#よりずっと楽なのでお勧めです。

ただ、謎なのはどこにも参照周波数を入力してません。 出てくる値はSDR#と同じ値に落ち着くので正しいようですが、何見てるんだろ。

RFゲインとは、内蔵アンプによる信号増幅のパラメータのようです。 dump1090ではデフォルトで--gain -10が入っており、 その場合はチューナーで設定可能な最大値に自動設定されるようです。
なお、dump1090-faには--enable-agcという似たような設定がありますが、 これはソフト内蔵のデジタル処理で、別物です。 設定してみましたが、効果はよくわかりませんでした。

さて、この設定値、必ずしも高ければ良いというものではないようです。 確かに試しにFMを受信したときなどちょっと下げたほうが音質が良かったりしました。
ネットには一定時間おきにゲインの値を変えながら受信し カウント数を比較するスクリプトなんかも存在します。 私もちょっと試してみましたが、ばらつきが大きくてよくわかりませんでした。 見えてる機体が十分に多くないとそちらの増減の影響のほうが大きいのでしょう。

当初はいまいちかと思ったコーリニアアンテナですが実力は高く、 徐々にフライト数が回復している今、dump1090でしばしば200nmオーバーの機体を見かけます。
ぜひ使い続けたいところですが、 大きく重くなってしまったので 両面テープで窓ガラスに貼り付けていた紅茶缶が しばらくすると剥がれて落下してしまいました。

原因はカーテンとのクリアランスを確保しようと、 当初使用していた100g缶から200g缶に変更したことでした。 100g缶に戻した現在安定しています。
本当は塩ビのパイプでレドームを作成するべきなんでしょうが、 あるもので落ち着いたのでこれで良しとします。

なお、たまたまそのへんにあったこの紅茶缶、 マグネット設置には理想的な形状をしています。

普通の缶は蓋のエッジがパイピング加工されていて、そこが両面テープでの固定に邪魔になります。 この缶はフラットなのでぴったり接着が可能です。 また、上面が緩いドーム形状になっており、マグネットアンテナを簡単に垂直に調整することができます。
ちなみに本体も装着してあるのはちゃんと理由があって、 当初画像のように蓋だけだと接着面上縁に力が集中してしまいます。 本体が下で支えることにより、接着面に垂直に力がかかるので剥がれにくくなっています。

それにしてもまさか紅茶メーカーもこんな理由で絶賛されるとは思っていなかったことでしょうね。

先日モバイル運用のテストで幸魂大橋で受信した際、 自宅よりも遠距離が芳しくないので不思議に思っていましたが、原因が判明しました。
自宅の方が高度が高かったです。

写真ではそんなに高く見えませんが幸魂大橋はかなり高い橋で、 欄干から下を見るとかなり下に水面が見えて、ちょっと怖いくらいなので 標高も高いと思い込んでいましたが、そうでもなかったみたいです。
私の趣味は自転車で、過去のGPSの走行ログがあるので確認してみました。 すると、当日受信した位置の標高は26mでした。 走行中にはスマホはウエストポーチに入れているのでだいたいアンテナを置いた欄干と同じ高さです。 ちなみに地理院地図で見るとこのあたりの水面の標高は1mくらいです。
同じログの自宅位置の標高を見るとなんと38m。地面の標高は37m。 自宅は4Fなので階高を3mとすると床まで9m。アンテナは床から2m。
37+9+2 = 48mがアンテナ標高です。
地球は丸いので、遠距離受信で邪魔なのは地面です。 遠距離で重要なのはアンテナの高度だった、というオチでした。

先日コーリニアアンテナの記事で、被覆の有無は関係ないみたいと書きましたが、 ちょっと気になったのでもう一度検証してみました。
できるだけ多くの機体が見える時間帯を選んで数時間様子を見てみると、 やはりちょっと裸銅線と比較してよろしくないようです。
具体的には200nm以遠をさっぱり受信しないのと、 FR24のStatisticsの１時間コンタクト数が前後の裸銅線の時間帯と比較して有意に少なかったです。

となるとやはりビニル被覆線は短縮率が違うのではないかと思われます。 なんとか検索で見つけ出した例として、 Ham Jounal No.21でIV線の短縮率を実測した数字として0.89が紹介されています。 つまり裸銅線と同じ寸法で作ったのでは長過ぎたようです。

裸銅線の短縮率を0.96とすると、裸銅線のエレメント長に0.89/0.96 = 0.927を掛ければ正解のはず。

上から179mm - 20mmループ - 191mm - 20mmループ - 173mm

ループはよくわからないので同じとします。 というかもともときっかり20mmで作れているとは思えないので。
これで曲げなおすとこんな感じです。

するとどうでしょう、太平洋上の245.9nmがあっさり見えて限界突破、反射波で新潟沖日本海の機影も捉えました。

ちょっと補足しておくと、dump1090で表示される高度は気圧計からの数字みたいで、 GPS高度はjsonファイルのデータを見たところ40625ftでした。
同じ性能でこっちの方が黒くて目立たないし、少しでも短いので取り回しも楽です。

ADS-Bの信号にはCRCが含まれているのでビット誤りがあった場合にある程度訂正できるようです。 dump1090-faの場合はデフォルトで--fixが指定されており、 1ビットのエラーは訂正されるようです。
調べ物をしている際、2ビットの誤りも訂正する指定を発見しました。 --fix --fixと2回繰り返すとそうなるみたいです。 ちなみにLinuxでこういうオプション指定方法は初めて見ました。
一応指定してみましたが、効果はさっぱりわかりませんでした。 うちのサブノートの場合CPU負荷は上がらなかったのでそのままにしてあります。

なお、一部のforkでは--aggressiveという同様の指定があるようですが、 dump1090-faでは無効化されていて、 指定するとかわりに--fix --fixが適用されます。
--aggressive指定は重いわりに意味がなかったようで、 海外フォーラムでは指定したい初心者に対して 「意味ないからやめとけ」みたいな会話がよく見られます。

コーリニアアンテナは受信性能は良好ですが、モバイル運用に難があります。 かといって、アルミストローも脆弱なので向いていません。 というわけで、アルミパイプ（φ7mm t1mm）を加工してみました。 見た目で少し削ればM3ナットが入ると思ったのですが、かなり削る必要があって苦労しました。
長さはストローと同じ135mmの他、1/2λ短縮率0.96として132mm、 短縮率0.93で128mmの3パータン試してみましたが、132mmが最良でした。 なお、追加エレメントはあった方が良いようです。

これで群馬県北部の機影を捉えました。 太平洋上200nmオーバーは無理でした。
困ったことにストロー135mmの方が僅かに性能が良いようですが、 モバイル運用だとそこそこの性能があればいいのでこれでいいことにします。

今週に入ってから気温がぐっと上がり、冷房を入れないと過ごしづらい状況になってきました。 チューナーを設置しているリビングは日中人が居ないのでそこそこ高温になっています。 気になったのでrtl_testコマンドで補正値を再測定してみました。
すると5月は+32ppmだったのが+38ppmとけっこうずれてます。 設定を変更して再起動してみると若干受信状況が改善した気がします。 これはちょっと熱対策を考えた方がいいようです。

<補足> rtl_testの値をちょっと読み違えていたようで、 再計測するとドングル付近の気温29℃で+34ppmでした。 あまり収束アルゴリズムのできが良くないようで、 ppmが落ち着いた時のsample rateがちゃんと2048000Hzであること要確認です。 たぶん5月は25℃くらいだったのではないかと思いますが、 仮に+5℃で2ppmなのであまり気にしなくてもいいのかもしれません。

FR24のフィーダーとなって30日が経過しました。 過去30日間の受信状況によってランキングが出てきます。
うちから見える範囲は東側の90度くらいしかないので論外かと思っていましたが、 実はうちにはけっこう有利な条件でスコアが算出されていて、 本日の国内ランキングは285位となかなかのものです。

細かい係数は無視すると、常時フィードしている場合だいたい
最大受信距離×2 + 平均受信距離
これの過去30日間の平均値がスコアになります。 見ての通り、コンタクト数は関係ないのでうちでも勝負になるわけです。 というか、コンタクト数を加味すると空港に近い人の圧勝になってしまいますね。 そこそこ標高の高いうちは最大受信距離が延びるのでかなり有利です。 今のスコアはアンテナを改良する前の日の値が多く含まれているので、これからまだまだ順位は上がりそうです。

ちょっとトップランカーの値を見ましたが、 トップ100に入るには最大200nm平均100nmくらいは必要みたいで、うちではちょっと厳しそうです。 コーリニアアンテナに変えたのが5月末なので、6月末くらいのスコアからが実力になりそうです。 しかしこれでアンテナ改良の検証やモバイル運用が心理的にやりづらくなりましたね。

どうも熱環境が安定していない気がするのでヒートシンクを追加してみました。
ヨドバシで15mm角高さ6mmひとつ51円を2個購入。
とりあえず殻割りしてみるとこんな感じ。


受信状態で触ってみると、チップ側も裏側もかなり熱いです。 チップ側からの放熱はヒートシンクとの接触面積が確保できないので、 有利そうな裏側からの放熱としてみました。

受信状況が改善されているかはよくわかりませんが、 ヒートシンクを触るとかなり熱いのでとりあえず放熱はしているようです。 補正値は今までより小さい+30ppmになりました。室温の影響を受けにくくはなっていると思います。 ちなみに両面テープは熱伝導性をうたっていない普通の薄手のものです。

なお、放熱対策をしたら受信感度が上がったという報告がたくさんあるのですが、 たぶんそれは直接の原因ではないと思います。 R820Tの動作上限温度は85℃だそうで、さすがにそこより上にはなっていないような。 正しく補正すれば感度は確保できるはずです。 放熱したことによりもともとずれていたのが許容される範囲に近づいたのではないかなと思います。
私の場合は日によって補正値が変わるのを多少なりとも抑えることが目的です。 他には電解コンデンサの故障対策という点では意味があるかなとは思います。

追加したヒートシンクはそれなりに放熱しているようで、 受信中に指で触ると2秒くらいが限界です。 となると、表側からも放熱してみたくなりました。
ただ、チップのサイズは4～6mm角くらいと小さく、 両面テープを介した伝熱はちょっと無理があるように思います。

鉄ボルトを追加して定常運用してみると、触れないくらい熱くなっています。 チューナーの設置場所がガラス窓とカーテンの間の狭い空間で、 空気の動きが全くないので雰囲気との温度差がなくなっているようです。
試しに狭い空間に向けてサーキュレータを弱にして風を入れると、 ボルトもヒートシンクもほんのり暖かい程度に下がります。
重要な事実としては、受信感度はほぼ変わりません。 なのでこれを最終形態として構わないと思われます。 色々調べてみると発熱による熱雑音で感度低下が起きるはずなんですが、 うちではその現象は確認できません。 まあ、せっかくなのでもう一工夫してみることにします。

その昔CPUのオーバークロックが流行したときに色々やりましたが、 大事なのは出た熱をさっさと外に捨てることでした。 今回の場合もファンによる強制空冷が正解ですが、 可動部分を増やすのは好みではないのでパッシブにいきます。

私は外で焼き肉をするのが好きで、特に備長炭が好みです。 ただ、備長炭は起こすのが大変で、うちわでやってたら腕が疲れてしまいます。 そんなとき友人に教わったのが煙突の利用です。 ミルク缶の底を抜いて円筒状に加工し、 下に少量の着火剤を入れて炭を詰めて着火するだけ。 あとは完全放置で真っ赤に起きます。 対流効果で熱くなった空気が上から抜け、下から酸素を含んだ空気が吸気されるというわけです。 製品としてはキャプテンスタッグの「火起こし名人」というものがあります。

今回はトイレットペーパーの芯を利用してみました。 これを縦にして中にチューナーを入れれば、規模は違えど同じことが起きるはずです。

ただ、やってみたものの効果がさっぱりわかりませんね。 とりあえずボルトは相変わらず触れないくらい熱いままです。 いいアイデアだと思ったんですが。 横方向への拡散ができなくなったデメリットが対流のメリットを消してしまったのかもしれませんね。 受信感度は変わらないようなのでこれでいいことにします。

<補足>
室温26℃の日に触ってみたら、ぎりぎり触り続けられるくらいの熱さでした。 ひょっとして煙突長くしたらいけるかな。 本当は非接触の温度計（amazonで1500円程度）が欲しいんですが、コロナ禍で品薄のようです。

鉄ボルトでの放熱は調子がいいようなので、伝熱性や放熱性の良い アルミボルトならさらにいいだろうと思われます。 ただ、アルミボルトはあまり一般的でなく、通販なら入手できるのですが 送料が高いのでホームセンターに物色に行きました。

発見したのがアルミリベット。在庫で一番大きかった5x12mmを購入しました。 あと、スプリングも安かったので購入。 先日パイプアンテナに使ったアルミパイプがちょうど内径5mmでぴったりはまるので 十字に切り込みを入れて表面積を増やしました。

ケースにセットするとこんな感じです。

するとどうでしょう、明らかに受信感度が良くなっています。 今まで受信することのなかった秩父や大月の機影を捉えるようになりました。 窓とは完全に反対側の離れた位置なので、僅かな反射波を捉えたようです。
うちでは熱雑音の影響はこれまで観察されませんでしたが、 単にまだまだ放熱が追い付いていなかったということのようです。
最大受信距離は伸びていませんが、もともと物理限界に近いのでそんなものでしょう。

リベットの役割はチップの熱を速やかにケース外に伝えることですから、 より伝熱性が高く放熱性はやや低い銅製のリベットだともっと良さそうです。 CPUのヒートシンクもその組み合わせが最良とされていますね。

dump1090のTracksを見ていると、たまに長野県の機体を捕捉していることに気が付きました。 窓の完全に裏側になるのですが、30000ftあたりからだと絶妙に目の前の建物で反射するようです。
ちょっとずるいんですが、FR24でそのあたりを通過する便を探しておいて、 dump1090で待ち構えて捉えた記念撮影が以下です。

行政区分では川上村になるようです。実は埼玉と長野はお隣さんなのでした。 距離的には大したことないですがここだけピンポイントで受信可能で、すぐに機影は消えました。

熱対策に関してはあまり受信に効果を感じなかったので単なる工作レポートとなっていましたが、 最後に実施したチップからの放熱で結論がひっくり返りました。
私はケース外へ排熱すればそれでいいと考えていました。 チップへ直接ヒートシンクを接触させても、 迅速に放熱しない限りすぐに飽和してしまってあまり意味がないと考えたからです。
ところが実際にはアルミリベットは受信感度改善に有意な効果を発揮しました。 どこで読み外したのでしょうか。

先日長野県の機影を捉えましたが、他にも拾える可能性がないかなと地図を見ていたら、 福島県も可能性があることがわかりました。 群馬県北部の奥利根湖のあたりは見かけるんですが、そこから少し北は福島県です。
と、IBEXのCRJがちょうど群馬を北上中だったので待ち構えてみたところ、拾えました。

行政区分では桧枝岐村になるようですね。

長野と福島の機影を捉えたところで、あと残りの県はどこがあるでしょうか。
自宅は埼玉で、窓から東が見えているので東京と千葉、あと茨城南部は問題なし。 横須賀がぎりぎり直視できるので神奈川も問題なし。 群馬は反射波で奥利根あたりや前橋周辺がスポット的にあちこち見えています。 熱対策で大月が見えるようになったので山梨もなんとか。 長野と福島は先日捉えました。 最終的に意外なところで栃木が残りました。
栃木県はうちから全域が100nm圏内にすっぽり入るんですが、 運の悪いことに直視は無理で反射波もほとんど期待できない方角に位置します。 たぶんアンテナをベランダの柵まで出せば直視できるんですが、 あくまで常設状態にこだわってトライしてみようと思います。
dump1090のTracksを見ていると、たまーに航跡が栃木で記録されているようではあります。 群馬の太田や舘林はそこそこに見えているのですが、 すぐ近くの足利や佐野あたりは運が良ければギリギリ拾えているようです。
FR24のプレイバックで確認すると、アンカレッジから香港へ行く便や 茨城空港と西日本を結ぶ便がいい感じに通るようです。 と、たまたま開いた瞬間に運よく佐野市上空の福岡から茨城に向かうスカイマークの機影をゲット。

これで今のアンテナ位置で見える可能性のある全県制覇です。

追記
新潟県忘れてました。なぜか新潟沖だけピンポイントで見えるんですよね。

３段コーリニアアンテナの導入から１ヶ月が経過したので フィーダーランキングがかなり上がってきました。 今日現在でスコアは10003、日本国内ランキングは195位です。 あとは小改良程度なのでだいたいこのあたりで定着するかと思います。
以前スコアの算出方式について軽く触れましたが、少し誤認があったので訂正します。 常時フィードしている場合、だいたい以下式の30日積算でランキングが決まります。

最大受信距離×2 + 平均受信距離

で、「平均受信距離」の意味を取り違えていました。 私はこれを受信できた信号の平均距離だと解釈していたのですが、 どうやら８方位の最大受信距離の平均値が正解のようです。
例えば以下は昨日のStatisticsのPolar Plotなんですが、

北から時計回りに数値を書くと
(75+192+202+127+82+7+7+50)/8 = 93
これが平均受信距離の正しい算出式らしいです。 南西と西が7nmというのはずいぶんと低いですが、 ある程度安定的にフィード出来ていないとカウントされないようです。
世界ランキングのトップを見ると最大と平均の差がほとんどありません。 つまり全方位遠距離受信できているというわけですね。
ただ、日本ランキングのトップランカーは必ずしもそうではありません。 山が多い地勢なのと、航路の偏りでそもそも全方位の遠距離に機影が無いということなのでしょう。
それにしても東しか見えなくても勝負になると思っていたのですが、思い切り不利だったようです。

いつものようにdump1090を起動して眺めていたら、250nm近い位置がTracksで出てきました。 遠ざかる方向の場合、機影が動かなくなった位置の距離を読めばいいのですが、 近づいてくる場合はdump1090のログに距離は残らないので ログに最初に出てきた緯度経度から自分で算出する必要があります。 あたりまえですが、信号に受信位置からの距離情報は含まれませんので。
カシオの計算サイトで求めてみると、なんか見た目と微妙に違う気がしたので dump1090の距離計算式を確認しました。
dump1090-faの場合、距離はtrack.cで計算されています。 てっきり地球を回転楕円体として計算しているのではないかと思ったのですが、 実際には真球として計算されていました。 コメントによると「そんな誤差が問題になる状況で使ってない」とのことです。なるほど。 まあ誤差は高々0.5%程度ということで少しでも計算量が少ないほうがいいという判断なのでしょう。
残念ながら違っているというのは気のせいで、最長受信距離更新とはなりませんでした。

緯度経度から計算サイトで距離を算出するのが手間だなと思ったので、 便名を指定すると自局から最初に機影が見えた位置までの距離を dump1090-faの計算式で表示するスクリプトを作っていました。 その動作確認中に、明らかに250nmを超えていそうなTrackを発見しました。

作成したスクリプトで確認すると、251.5nm。新記録達成です。 ちなみにGPS高度は38075ftで、やや低いです。梅雨前線の影響で回折が起きやすい条件なのでしょうか。

せっかく作ったので一応公開することにします。 というか、忘れそうなのでメモ代わりです。

自宅の緯度経度はハードコードしてあって、dump1090のjsonファイルから抜き出した 緯度経度と、球面三角法というもので距離を算出しています。 地球の半径には6371kmという数字が使われていますが、 これは表面積が本物のと等しくなる値だそうです。
jsonファイルをタイムスタンプ順に並べて、grepコマンドで便名を含むものを抽出します。 このときJAL11を見ようとしてJAL118がヒットしたので除外する処理を追加。 後は緯度経度が含まれないレコードもあるのでlonを含む行のみを抽出したら先頭行が最初に見えた位置ということになります。
必要な行が抜き出せたのでtrコマンドで各レコードを行に分解し、latを含む行が経度です。 ただ、mlatがマッチしてしまうので先に除外してます。 lonはそのまま緯度でOKです。 後はdegreeをradianに変換。
球面三角法には緯度の差の絶対値が必要になるんですが、bcコマンドにはabs関数がありません。 ちょっと考えましたが、二乗してルートを取りました。 同様に、acosが無いのでatanで出せるように三角関数の公式で変換。 出てきた中心角に地球の半径をかければ距離が出ます。
最初はFortranでプログラム書いたんですが、あまりにシンプルなので 計算もbashのシェルスクリプトでやるように書き換えました。 いまどきの人はpythonとかで書くんでしょうが、 定年間近の古参プログラマはそういう感じでやりますね。

#!/bin/sh
# my site
LAT0=35.8
LON0=139.6
PI=`echo '4.0*a(1.0)' | bc -l`
R=`echo '6371.0/1.852' | bc -l`
FLN=$1
JSON=`ls -rt /run/dump1090-fa/history*.json | xargs grep -h $FLN 2>/dev/null | grep -v "$FLN[0-9]" | grep '\"lon\"' | head -1`
echo $JSON
LAT1=`echo $JSON | sed 's/^\[{\(.*\)}]$/\1/' | tr ',' '\n' | grep -v mlat | grep lat | sed 's/^.*://' | tr -d '"'`
LON1=`echo $JSON | sed 's/^\[{\(.*\)}]$/\1/' | tr ',' '\n' | grep lon | sed 's/^.*://' | tr -d '"'`
LAT0=`echo $LAT0/180.0*$PI | bc -l`
LON0=`echo $LON0/180.0*$PI | bc -l`
LAT1=`echo $LAT1/180.0*$PI | bc -l`
LON1=`echo $LON1/180.0*$PI | bc -l`
DLON=`echo "sqrt(($LON1-$LON0)^2)" | bc -l`
T=`echo "s($LAT0)*s($LAT1)+c($LAT0)*c($LAT1)*c($DLON)" | bc -l`
T=`echo "sqrt(1-$T^2)/$T" | bc -l`
DIST=`echo "$R*a($T)" | bc -l`
printf "%.1f\n" $DIST

以前国内ランキング200位を達成したのですが、 その後じわじわと上昇していてここのところ170位台をキープしています。
似たような順位の受信局と比べると、 最大受信距離は長いですが平均受信距離で負けてます。 今日のうちの平均受信距離は94nm。まわりはだいたい130nmくらいです。 やっぱり見える範囲が狭いのを最大距離で逆転している感じですね。 熱対策を完了したのが6月の末頃でしたから、距離はもう上がらないと思います。

あと可能性があるとすれば、受信時間でしょうか。 完全に常時起動にすると、Uptimeは24×30=720になります。 うちの場合はテストでたまに止めるので、今日の時点で714です。 スコアの計算式を見ればわかりますが、1時間止めるとスコアは12下がります。720-714=6時間だと72。 仮に常時起動だった場合は今日のデータだと148位に相当します。 ただ、いっぺん止めるとその影響が30日間出続けるのでなかなか難しいですね。

先達の皆さんの記録を拝見すると、ある程度落ち着いたところで フィードを中止されている例が多いようです。
気持ちはよくわかります。 私もそうなんですが、つまらないです、これ。
導入して最初のうちは色々と改善点が見えるし、 対策した効果もすぐにわかるので励みになります。 が、落ち着いてしまえばやることがほとんどありません。

最大の欠点は、フィーダーの多い都市部の場合とにかく全然自分のデータが採用されません。 FR24では選択した機体が今どのフィーダーのデータを参照しているかわかるのですが、 私は今まで自分のデータが使われたのを見たことが一度もありません。
まあ、フィーダーとなっている最大のモチベーションは 邪魔なバナー広告を消したいからなので問題はないんですが、 もうちょっとなんとかならんかなあと正直思います。

ずいぶんと更新してませんでしたが、完全に定常運用に入ったので書くことがありませんでした。

2020/7/13に公開した距離計算スクリプトですが、 当時はjsonをさっぱり理解していなかったので暗号みたいになってます。 スマートリモコンのAPIで遊んでいるうちにjqの使い方がだいぶわかったので 今ならもっとすっきり書けるはず。

lsの-tでタイムスタンプ順にソートしてgrepやheadで 該当する便名を抜き出すというのは確実でいい方法なんですが、 行末に","が残るのでsedで削除。 すると緯度経度はjqで一撃です。なんと楽な。

JSON=$(ls -rt /run/dump1090-fa/history*.json | \
  xargs grep -wh $FLN 2>/dev/null | grep -v "$FLN[0-9]" | \
  grep -w lon | head -1 | sed -e "s/,\$//")
LAT1=$(echo $JSON | jq .lat)
LON1=$(echo $JSON | jq .lon)

FLN=$(printf "%-8s" $FLN)

JSONALL=$(cat /run/dump1090-fa/{aircraft,history*}.json)
JSON=$(echo "$JSONALL" | jq ".aircraft[] | select(.flight == \"$FLN\") | select(.lon != null)")

JSON=$(echo "$JSON" | jq -s 'sort_by(.messages) | .[0]')

JSON=$(echo "$JSON" | jq -s 'sort_by(.messages) | reverse | .[0]')

JSON=$(echo "$JSON" | jq -s 'sort_by(.messages) | .[-1]')

JSON=$(echo "$JSON" | jq -s 'min_by(.messages)')