過去の記事の書き直しです。
FT8で、スプリット運用をして離れたDFで呼んでも全く応答がないのに、そばのDFで呼ぶとすぐ応答があることがたまにあります。
一因として相手がワイドグラフの表示範囲を狭めている可能性があります。
ご存知のようにWSJT-XとJTDXは、ワイドグラフに表示されている範囲でしかデコードしません。 ワイドグラフの表示範囲が500~2200Hzであれば、その範囲内の局のみがデコードされ、例えば2500Hzの局があってもデコードされません。
局によっては、意図的にワイドグラフを狭くしている場合があります。遠くのDFに呼びかけても全く反応がない場合は、近くのDF、特に低いDFに呼びかけてみると、反応があるかもしれません。意図的ではなくて「何も知らないまま」帯域を狭めている人もいるとは思いますが。
お使いのリグによっては、受信帯域が狭く、その上限が2400前後になる場合があります。意図的ではなく2400以上のコールをデコードできない場合もあると思います。
また、私はワイドグラフを意図的に狭くしてもあまりメリットはないと思います。私は常にワイドグラフに0~3000Hzを表示し、必要に応じてPBTなどのフィルターでダイナミックレンジやSNRの向上を検討しています。
このケースは最初は0-3000までをRIGのフィルターでも絞らずに受信していて、次にRIGのPBTフィルターで帯域を800-2500に絞り、次に帯域を1300-3000に変化させたものです。
JTDXのワイドグラフは0-3000のまま維持しており、RIGのフィルターの外でも「強い信号」の局はデコードされます。
RIGのフィルターで帯域を絞り、「強い信号」を追い出すことによって帯域内の「弱い信号」のデコード率を向上させることができます。
逆に上限を広げた場合はどうでしょうか? ほとんどの運用局が3000以下で運用しています。したがって3000以上に広げても3000以上はスカスカの状態だと思います。しかし混雑していた場合には、あえて3000より上に出てくる局もいます。試しに3200くらいで運用したことがありますが、時々コールされました。
CPUに対する負担を考えてみると、表示させている範囲でデコード作業を行いますので、無駄に広げてもCPUに掛かる負担が増えるばかりで良いことはありません。例えば3500とか4000まで広げても運用局のいない周波数のデコード作業を行いますので無駄になってしまいます。
JTDXの場合は使用スレッド数でワイドグラフの表示範囲を分割し、それぞれのスレッドが分割された範囲のデコードを担当するので、誰もいない部分のデコードに割かれるCPUスレッドが無駄になってしまいます。
最近のコメント