bookmark_border[340] FT8設定状況の確認

CQ誌9月号には、8月号に続き別冊付録として「FT8マニュアル」がついており、8月号が「入門」編であったのに対し今回は「活用」編です。

早速、当局のFT8設定状況を確認しました。まず基本的な見直しポイントとして挙げられている次の7点です。

①PCの時計合わせ

「iネット時計」をインストールしており、運用の都度、そのアプリを立ち上げて時計を合わせています。精度は±0.2秒ですが、記事によると「JTDXの場合、0.18秒以上遅れるとデコーダーの感度が約6~8dB低下するといわれている」とのことですので、何か別の方法を考えた方が良いかも知れません。

②PC処理能力の向上

先日書いたように、当局では何世代も前のプロセッサを使っており、これも「処理能力によってデコードに大きな差が出る」とのことです。特にJTDXはデコード時の負荷が重いそうですので、記事にはプロセッサの状態やCPUクロック周波数を常に100%にすることが推奨されています。当局ではこの設定にしていますが、常にファンが動いた状態で、少しでも排熱がうまくいかなくなるとスロットリングによりクロック周波数が急激に落ちるおそれがありますので、バランスが重要かと思います。

③綺麗な電波の発射

第1はALCレベルメータでの確認が重要ですね。またFT-991AMでは送出信号のオーディオモニタができるためそれで確認したり、相手局から送られるSNRレポートを参考にしたりしています。ちなみに、以前使っていたFT-450DMでは送出信号のモニタができなかったため(自分がモニタ方法を気付かなかっただけかも知れませんが)、不安はありました。

④スプリット設定

「Rig 」設定をしています。スプリット設定をしないと2,800Hz以上のDFでは送信できないこと、初めて知りました。

⑤受信帯域フィルタの拡張

リグ上ではフィルタの幅を最大に設定しています。JTDXやWSJT-Xではワイドグラフの表示範囲しかデコードしないとのことで、設定を確認したところ「Bins/Pixel 2」になっていたため「Bins/Pixel 3」に変更しました。

⑥受信能力改善

受信を妨げるほどのノイズは受けていないように思いますので、特に何もしていません。アンテナやカウンターポイズの調整により、結果的に受信ノイズを低減しているのかも知れません。

⑦ソフトウェア最新化

使っているJTDXは「v.2.2.156」ですが、JTDXのサイトを見たらこれが最新の様ですのでOKです。

別冊記事の内容は盛りだくさんで情報も多く載っていますので、JTDX中心に書かれていることもあり、これから落ち着いて一つ一つ学んでいきたいと思います。

ちなみに、以前「同一局が同じタイミングで複数の信号を出している」のを怪現象として不思議に思っていましたが、これは記事にある「DX petition mode」か「MSHV」と思われます。 勉強になります。

bookmark_border[325] 15m不思議な現象

結局、12mは当面諦めて17m、15mなどを中心に運用していきたいと思います。そこで、15m FT8でインドネシア局がCQを出していましたので呼んでみました。

その局は他のJA局に応答したので、当局は次の呼び出しに備えてTXボタンを押して待っていたら・・・

何とJA局に「73」を送出するのと同じタイミングで、当局に「-13」のレポートが送られてきました。当局(のJTDX)は「-26」を返していますが、ぎりぎりで相手局の信号がデコードできたということでしょうか。

WSJT-XやJTDXに、複数局へ同時に信号を送る機能があるのかどうかはわかりませんが、不思議な体験をしました。

bookmark_border[277] 6m活況

これは昨日午後の6m FT8の様子です。欧州方面が開けていたようです。あいにく天気が悪かったのでアンテナはベランダ内のHFV5で、全く逆方向のため残念ながら欧州局は受信できませんでした。

まるで40mの様相を呈しており、それも特定局に集中したパイルではありません。皆さん欧州DX狙いで当局は大人しくしていた方が良さそうな状況だったため、すぐに2mにQSYしました。

更に驚くべきことに、この時55局のデコードに成功していました。当局のデコード環境では最高記録です。FT8は一信号あたり50Hzの幅があり、それが3KHzの帯域に収まる訳ですから、理論上は最大60局分しか収容できません。55局というとそのうちのいくつかはDFが重なっているでしょうが、90%を超える密度です。

JTDXを「156」にアップデートしてからデコード性能が上がったような気がしていましたが、まさかここまでとは思いませんでした。

bookmark_border[251] JTDXアップデート

JTDX(v2.2)を「156」にアップデートしました。パネル表示も操作上も特に変わったところは無いようですが、CQ誌記事によると様々なバグ修正がなされているとのことです。

なお、アップデートによるものかどうかわかりませんが、デコード性能が上がったような気がします。

これは6mでのQSOとWFの記録です。当局からの呼び出しに対して相手局から応答いただいたのですが、タイミング的に遅かったにもかかわらずちゃんとデコードできています。自局に対する信号待ちの場面では、ある程度信号が抜けていても推定してデコードするのでしょうか。その時の信号レベルは少し低くなってはいますが・・・

今のところこれ以外に気が付いた点はありませんが、使っていくうちに進化が見えてくるのかも知れませんね。

bookmark_border[238] FT8 送信時のTX1の扱い

FT8 QSO時の送信シーケンスの在り方、その中でも「TX1を送信すべきかスキップすべきか」を考えてみました。

① パイルアップ時など
パイルアップやバンドが混んでいるようなとき、コンディションが安定していないときなどは、なるべく送信時間を短くするためTX1をスキップするようにした方が良いと思っています。また、確証はなくあくまで感覚的なものですが、TX1をスキップしてTX2から始めた方が相手局に拾っていただける確率が高くなるような気がします。

②RRR使用のCQ局への応答
RRRを使うCQ局に応答する場合は、TX1をスキップした方がQSOが早く終了します。TX1が無くなることに加え、当局からRR73を送出するため二重に短くなるためです。

例えば標準どおりTX1を送出した場合は、

・CQ  JA1●●● PM95
・JA1●●● JK1BSH PM95
・JK1BSH JA1●●● -10
・JA1●●● JK1BSH R-05
・JK1BSH JA1●●● RRR
・JA1●●● JK1BSH 73
・JK1BSH JA1●●● 73

一方、TX1をスキップした場合は、
・CQ  JA1●●● PM95
・JA1●●● JK1BSH -05
・JK1BSH JA1●●● R-10
・JA1●●● JK1BSH RR73
・JK1BSH JA1●●● 73

となり時間が短くできます。またTX1を送出した場合は、RRR局からの最後の73が受信できないと当局から73を再送しロスになってしまいます。

なお、TX1スキップの場合に留意すべき点としては、送信設定した時点での相手局の信号をもとにSNRレポートをしますので、送信設定とQSO開始のタイミングが時間的に離れている場合は、実態に合っていないレポートをすることもありますので、送信設定はなるべく小まめに行う必要があると思います。