WSJT-X 2.5.4がリリースされていたのでインストールしてみた。2.5.3では「/P」付きの局から呼ばれるとWSJT-X自体がクラッシュするという致命的な問題があったが、多分、それが直っているはず。リリースノートにこうある。
Release: WSJT-X 2.5.4
January 3, 2022
----------------------
This is a bug fix release. It has the following changes since
release 2.5.3:
WSJTX:
- Repair a defect that caused occasional crashes when in QSO with
stations using nonstandard callsigns.

では、問題だった「/P」付きのコールサイン。
まずは、呼ばれた場合。2.5.3だとこのパターンでクラッシュしていた。

問題なさそう。リトライを繰り返しているのは、こちらが弱かったから。国内なので5Wで運用していたのだけど、厳しかったみたいで呼んでくれた相手局は他の局とQSOを始めてしまった。そこで、送信電力を上げて応答し続けてなんとか返答をもらえた。
続いて、逆パターンの「/P」付きコールサインの局を呼んだ場合。

こちらも良さそう。だけど、実はこの前に、上手く行かなかったこともあった。

相手から「73」をもらってもこちらは「R-07」を繰り返す。しょうがないので、手動で「73」を送出。先ほどとの違いは、相手からの応答。先程のは「RR73」をもらっていたのだけど、こちらは相手から来たのは「73」。相手から「RR73」か「RRR」をもらわないとシーケンスが進まないのかな?相手から「RR73」や「RRR」ではなく、いきなり「73」のパターンはあまり経験していないので以前の版ではどうだったか不明。こちらから「Rレポート」送出後に相手から「73」が返ってきたら終了でいいと思うんだけどなぁ。
【追記】 この動作、挙動がおかしいんじゃなくて、仕様変更だそうだ。なんだかなぁ…。
WSJT-X 2.5.xでのRRRやRR73での挙動(Tx 5関連)についてはこちらの記事にまとめてある。
コメント