2021年2月14日の記事に加筆再掲します。
Ｌａｇ の意味
CQ誌2月号より「FT8最新事情」という連載が始まっている。
その記事に「帯域内の全解読データ」ウインドウの上に表示してある「 Ｌａｇ 」（タイムラグ）の解説があったので、漸く意味が分かった。
上の画像でいうと右端の「 Lag＝－0.44／6 」という部分。
記事によると、
解読終了から送信までの時間。
マイナスは利用可能な余裕時間。
プラスは送信時刻からの遅延時間。
／○は最後のピリオドの解読数。 とのこと。
上の場合なら、６データを解読して送信時刻までに0.44秒の余裕があるという意味なんだとか。納得。
しばらく「Lag」表示を見ていると、だいたい-0.4秒前後の余裕が出ていた。
遅延もたまにはあって、「+0.09/35」を見た。
Ａｖｇ の意味
「Lag」の左隣の「 Avg 」は、理解していた通りだった。
解読したデータの「DT（時刻の差）」の平均値だ。
（ 以下、今回の加筆部分です ）
「 Decode 」の設定を見直しましたので、記録しておきます。
①「 FT8 threads 」
使用するPCのCPUに合わせます。
私のCPUは「 AMD Ryzen 5 PRO 4650G 」
2020年8月発売の6コア12スレッドですので、「12」に合わせます。
以下は、「 FT8 decoding 」の中の項目です。
②「 decoding cycles 」
デコードを何回行うかという設定ですが、Lag値がプラスにならないように選択します。Lag値は「＋0.4」ぐらいまでOKとしている記事もありますね。
高スペックのCPUなら迷うことなく「３」を選ぶのですが、私の場合は「２」を選択しています。
③「 QSO RX freq sensibility 」
電波環境が良好な場合、「高」にするとデコード率が上がるそうです。
ただ、ノイズが多い場合などは偽デコードが増えるらしいので、「Medium」で使っています。
④「 decoder sensibility 」
デコード数に影響しますので、高スペックのCPUなら「use subpass」ですが、私のCPUは３年以上前のものなので「use low thresholds（低いしきい値を使用する）」を選択しています。
「minimum」が、最もCPUパワーを必要としませんが、効果は薄いとされています。
⑤「 early start of decoder 」
デコードを早めに開始してくれるので、Lag値が下がります。
ある程度のCPUパワーがある場合、「on」の方がよいとされています。
⑥「 wideBand DX Call search 」
これにチェックを入れると、「DX Call」ボックスにお目当ての局を設定している場合にその局を優先的に探す効果を発揮してくれるのだとか。
私は「DX Call」ボックスをほぼ使わないので要らない機能ですが、CPUへの負荷はほとんど無いということなので、「on」にしています。
やっぱり、FT8もCPUパワーなのかな。
JTDXは、CPUのスレッドでワイドグラフの範囲を分割担当してデコードしているそうなので、スレッド数が多い方が効果的なんだとか。
私はAMD派なので、次は 12コア24スレッド の Ryzen 9 か！
でもまだまだ高すぎる！
パソコンも無線も金喰い虫だぁ。
