PR

FT8でQSOパーティ(2022年)は難しそう

正月二日からQSOパーティが開催されるけど、現時点のWSJT-X(2.5.x)ではFT8で運用するのは大変なことがわかった。きっかけはこちらのツィート。

どうやら、最近のWSJT-XではRRR送出の挙動が変っているらしい。

WSJT-X 2.5.3使用禁止
RRR送出の挙動以前の話として、WSJT-X 2.5.3は「/P」付きの局から呼ばれるとWSJT-X自体がクラッシュするという致命傷がある。再起動するにも余計なプロセスが残っているので、まずはそれを殺さなきゃいけない。
詳細はこちら ⇒ https://wsjtx.groups.io/g/main/topic/87729548
そういうわけで、WSJT-X 2.5.3は使ってはいけない。2.5.1は大丈夫。2.5.2は未確認(ユーザグループの投稿によれば大丈夫らしい)。

2.5.4ではクラッシュに関しては解決している。

以下は2.5.1での挙動に基づいた話。

CQ側

今回の問題はCQを出す側で発生する。前回(2021年のQSOパーティ)まではこちらの記事に書いた方法で比較的スムーズにシーケンスを流すことができた。

キーになるところをさらっておくと、(RR73ではなく)RRRを送出し、その次はTx 5でオペレータネームと73を送出するという流れ。

しかし、WSJT-X 2.5.1ではRRRを送出した場合、相手から73が来たらTx6に強制的に移動させられて、それと同時にEnable Txがオフになる。Tx 5にチェックを入れていてもダメ。とにかくTx6への移動が強制されて、送信も終了。したがって、オペレータネームを送出できない。

この挙動を踏まえて、QSOパーティでなんとかやるには、こうするしかなさそう。

  1. Tx 4は「RRR」に設定(「Tx 4」ボタンをダブルクリックするとRR73とRRRがトグルする)
  2. 呼出しを受けてシグナルレポートを送出したらTx 4に移動(これはオートシーケンスで自動)
  3. Tx 5にオペレータネームと73をセット(マクロを活用 ⇒ 「OP 名前 73」 空白含めて13文字以下)
  4. 相手からの73を受信したらすぐに「Tx 5」ボタンをクリックし、さらに、「Enable Tx」ボタンも押す(逆順だとTx 6のCQが送出されるので注意)
  5. このあと、もし相手から再度オペレータネーム付きの73が来たら、こちらも念のためTx 5を再送

これで多分大丈夫だとは思うけど、まぁなんとも忙しない。注意力と素早い操作が必要。「QSOパーティ」というよりもコンテスト並みの集中力が必要かも…。20局達成したらかなり疲れそう。

なお、呼出側がいきなりシグナルレポートを送ってきてくれたら、普通の流れでTx 5を送出してくれるので楽。そう考えると、QSOパーティでは最初の呼出しはGL付きではなくて、いきなりシグナルレポートを送った方が親切かもしれない。

この手順、いきなり本番だとかなりまごつくと思うので、今のうちに練習しておいた方がいいかも。あるいは、前回(2021年)使ってバージョンに戻すとか…。

WSJT-X 2.5.1でのRR73とRRRの挙動の違いを整理。

  • RR73: 送出したらTx 6に移動し、Enable Txがオフになる
  • RRR: 相手からの73を受信したらTx 6に移動し、Enable Txがオフになる(相手からの73を受信するまではRRRを再送する)

どちらにしても、Tx 5を送出することはない。例外は、シーケンスの最初で相手がシグナルレポートを送ってきた場合(GL付きではなくて)。このときは、CQ側もTx 5を送出する。

希望は「RRR送出後にTx 5にチェックが入っていたらTx 5を送信する。入っていなかったらそのまま終了。73が来ない場合はTx 4を再送」という仕様。Tx 5を送信するか否かのスイッチを付けてくれてもいいけど。「Tx 5で自由テキストを送る権利を与えよ!」叫びたい。QSOパーティ以外でもフリーメッセージを送りたいこともあるし。ここに書いてもしょうがないだろうけど。

RR73だとTx 5にチェックしても無視される。

【追記】 実際にQSOパーティで運用してみるともう少し違う挙動があることがわかった。

それは、相手が非標準の73を送ってきた場合。RRR送出後に例えば「OP name 73」のような形式を受信するとTx 5を送出してからEnable Txがオフになる(シーケンスはTx 6に移る)。オートシーケンスできれいに流れてくれる。QSOパーティとしてはとても楽。

ただし、標準の73、つまり、「HisCall MyCall 73」、または、「HisCall MyCall RR73」だと最初に書いたように、それを受信した時点でEnable Txはオフ(Tx 5は送出されない)。また、73として認識しない形式、例えば、「OP name TU73」や「OP name HNY73」などが来ると、こちらはRRRを再送する。

RRR送出後に受信したメッセージによるその次の動作をまとめるとこう。

  • 標準73(「HisCall MyCall 73」、「HisCall MyCall RR73」)
    ⇒ Enable Txがオフ(Tx 5は送信されない)
  • 非標準73(「OP name 73」のように「73」がある)
    ⇒ Tx 5送信後にEnable Txがオフ
    ⇒ 手動でEnable Txをオンにすると、別の局に呼ばれたらそれに応答、呼ばれなければCQ送信(Tx 6)
  • それ以外(「OP name HNY73」のように「73」の前に空白がない場合は73として認識しない)
    ⇒ RRRを再送

ということで、73は「OP name 73」のようなWSJT-Xが認識できる非標準の73形式で送るのがベストだと思う。標準形式や、73の前に空白なしで別の文字を付けるのは手動対応が必要になるので避けるのが良いと思う(RRを除く)。

呼出側

CQ局を呼び出す方は前回と同じ方法で大丈夫。呼び出す方は必ずTx 5を送出する。

なお、上に書いたように、相手のことを考えると最初からシグナルレポートを送った方がいいかも。 その必要はなさそう。普通にGL付きで大丈夫。

JTDXの場合

JH8JNFさんの記事を参照。

コメント

  1. JE1SGH 1RO より:

    よく解らないですが,そもそも通常の交信で最低限名前くらいは交換するから,NYPの要件が名前交換になっているんじゃないかと思います.
    FT8/FT4では苦労しないと名前交換できないんですから,必要条件から外すべきだと思います.