WSJT-X Improved JP1LRT Editionの新しいPublic Release Candidate、20260901A-REB522-P6 / P6-ALを公開しました。

今回のP6は、これまで公開していた20260824A-REB522-P5 / P5-ALの後継版です。ベースは引き続き2026年5月22日版 WSJT-X Improved 3.1.0で、WSJT-X Improved 3.2.0ベースへ移行した版ではありません。

P5で起きていたこと

Hunting待機中にWanted局を受信すると、JP1LRT Editionはその局を取得し、QSOを開始してレポートを送信します。

P5では、その後相手から応答がないままレポートを3回送信すると、通常のCQ RUN用の無応答処理へ入り、場合によってはそのままCQ送信へ移行してしまうことがありました。

通常のCQ RUNとしては自然な動作ですが、Wanted Pounce / Huntingの思想から見ると、ここは少し違います。Huntingでは「Wanted局を待っている」のであって、相手が応答しなかったからといって勝手に通常CQへ移るべきではありません。

P6でどう変わったか

Wanted Pounce / Huntingから開始したQSOで、レポートを3回送信しても相手から続きの応答が得られなかった場合、P6では次のように動作します。

• 4回目のレポートを送信しない
• CQを自動送信しない
• Auto Txを停止する
• DX Callをクリアする
• Tx6 / CALLING状態へ戻る
• Wanted Pounceを有効なまま維持する
• Hunting待機状態へ戻る
• 蓄積済みのAutoSeq候補を保持する
• 同じWanted局を再び受信した場合も、新しいQSOとして再取得できる

3回目の直後にRR73が来たら？

ここは重要な境界条件です。

3回目のレポート送信直後に、相手からRR73などの有効な応答を受信した場合は、無応答とは判定しません。

その場合は従来どおり、QSO完了処理、最終73、Terminal Holdを経て、正常にHuntingへ復帰します。

つまり、単純に「3回送ったら即中断」ではありません。3回目送信後に届いた有効な終端応答は、きちんとQSO完了側が優先されます。

通常のCQ RUNには影響しません

今回の新しい復帰処理は、Wanted Pounce / Huntingから開始したQSOだけに適用されます。

通常のCQから開始したQSOの動作は従来どおりです。

• CQ: Firstは、通常の無応答上限後にCQへ戻る
• AutoSeq 2の通常CQ RUNは、既存のactive-QSO no-progress処理を使用する
• 「Set Rx frequency to Tx frequency after QSO」が有効なら、CQ復帰時にRX DFをTX DFへ戻す
• 通常CQではAuto Txを継続してCQを再開する

Hunting由来QSOと通常CQ由来QSOを、明確に別のライフサイクルとして扱うようになった、と考えると分かりやすいと思います。

P5までの機能もそのまま維持

P6はWanted Pounceの無応答時復帰を追加したもので、P5までに実装・検証してきた既存機能を削除したものではありません。

• P5 Return to Hunting
• Stop after 73の優先
• Best S&Pの言語依存不具合修正
• AutoSeq 2 / AutoSeq 3
• Terminal Hold
• CQ DX / 地域指定CQの自動取得安全制御
• Manual takeover safety
• LoTW userのtie-break
• 進行中QSOの保護
• Quick Call OFF時の正常動作
• Orange WantedとBlue display-onlyの役割分離

検証内容

Standard版

Standard版では、以下を実行確認しています。

• HuntingからWanted局を取得
• レポートを正確に3回送信
• 4回目のレポートを送信しない
• CQを誤送信しない
• Hunting待機状態へ復帰
• 同一局への再発火とカウンター初期化
• 新しい受信レポート値による送信メッセージ再生成
• 通常AutoSeq 2 CQとの非干渉
• 通常CQ: Firstの無応答復帰
• RX DFのTX DFへの実際の復帰
• 3回目送信直後のRR73受信
• 最終73、Terminal Hold、Hunting復帰

AL版

AL版では、P5-ALとP6-ALの完全source bundleを独立比較し、Standard版で承認された修正内容との一致、AL固有コードとの非競合、クリーンビルド、正式パッケージ検証、隔離起動および正常終了を確認しています。

ただし、これはすべてのモード、設定、境界条件を網羅したことを意味するものではありません。P6 / P6-ALはあくまでPublic Release Candidateです。

ダウンロード

GitHub Releaseを開く

Release: https://github.com/jp1lrt/wsjtx-avelag/releases/tag/20260901A-REB522-P6

各ZIPには対応する.sha256 sidecarも用意しています。

ユーザーガイドもEdition 1.8へ更新

P6 / P6-ALに合わせて、ユーザーガイドもEdition 1.8へ更新しました。

英語、日本語、ドイツ語、スペイン語の4言語版で、P6のWanted-Pounce無応答時復帰、最新のファイル名とSHA-256、Public RCとしての注意事項、既知の制限を反映しています。

現在も残っている既知の制限

P6で以下を修正したわけではありません。引き続き検討・調査中です。

• F/DB6LLのようなプレフィックス形式を含むスラッシュ付きコールサインのRR73処理
• jt9.exeの間欠的SIGSEGV
• 「Highlight also messages with 73 or RR73」設定に関する報告
• --language=es使用時、一部の新しい未翻訳UI文字列が英語ではなく日本語で表示される場合がある問題

最後の項目は表示上の問題で、QSOロジックや送信メッセージには影響しません。

Public RCとしてのお願い

• 新しい別フォルダへ展開してください
• 現在正常に動いている版を上書きしないでください
• Standard版とAL版を同じフォルダへ展開しないでください
• 別の--rig-nameプロファイルを使用してください
• 設定とログをバックアップしてください
• コールサイン、グリッド、無線機、PTT、オーディオ、レポート、ログ設定を確認してください
• 生成された送信メッセージ、DX Call、Auto Tx状態を監視してください
• 無人・無監視運用は行わないでください
• 異常を感じた場合は直ちに送信を停止してください

最後に

JP1LRT Editionは、単に機能を増やすことではなく、実際のFT8/FT4運用で「次に何が起きるか」をできるだけ予測しやすくし、進行中QSOや終端メッセージを壊さず、運用者の意図を尊重することを重視して作っています。

今回のP6も小さな修正に見えるかもしれませんが、Wanted Pounce / Huntingという運用思想を崩さないためには重要な変更でした。

実運用で何か不自然な点や再現可能な挙動を見つけた場合は、Standard / AL、完全なタイトルバー識別子、UTC時刻、Wanted-Pounce / Hunting状態、Quick Call ON/OFF、ALL.TXT該当部分、期待した動作と実際の動作を添えてご連絡いただけると助かります。

73, Yoshi / JP1LRT