WSJT-X Improved JP1LRT Edition P6 / P6-AL Public RC公開 — Wanted Pounce無応答時のHunting復帰を改善2026年09月01日 14時33分37秒

WSJT-X IMPROVED JP1LRT EDITION / PUBLIC RELEASE CANDIDATE

WSJT-X Improved JP1LRT Edition P6 / P6-AL Public RC公開

Wanted Pounceで相手から応答が続かなかったときの復帰処理を見直し、CQへ誤って移行せずHunting待機へ戻るよう改善しました。

20260901A-REB522-P6 / P6-AL

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ベースへ移行した版ではありません。

今回のポイント
P6の中心は、Wanted Pounce / Huntingから開始したQSOで、相手局からその後の応答が得られなかった場合の処理改善です。

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として再取得できる
つまり、P6では「Wanted局を3回呼んで応答がなければ、CQへ流れず、元のHunting待機へ戻る」ようになりました。

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の役割分離
Quick Call OFFについて
Best S&Pが対象局、DX Call、DX Grid、送信メッセージを準備しても、自動的には呼び始めません。これは異常ではなく、意図した正常動作です。

検証内容

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固有コードとの非競合、クリーンビルド、正式パッケージ検証、隔離起動および正常終了を確認しています。

独立レビュー最終判定
Standard P6: READY FOR PUBLIC RC PROMOTION
P6-AL: READY FOR PUBLIC RC PROMOTION
Blocking issues: none

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

ダウンロード

GitHub Releaseを開く

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

成果物 ファイル名 SHA-256
Standard GUI WSJT-X_20260901A-REB522-P6_win64.zip d69ef54fb7d10feb3a7bc9620497eda8ec40c700f08f4d5302e8e016a02e992b
AL GUI WSJT-X_20260901A-REB522-P6-AL_win64.zip 658db59666b89ae4884365e5ba55087b234b29aaa0cf7950fee80fcb2ab800e7
Standard source WSJT-X_20260901A-REB522-P6_source_bundle.zip 86e53df77bacaa93fc16bed15aec8e8ae1529231df16873486dacdb619803e2c
AL source WSJT-X_20260901A-REB522-P6-AL_source_bundle.zip 8ecb9f4d6ec4763a2eb03f7d33a1971466263b7435a7efc491e56b8365a1c1f4

各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

ハムフェア2026、今年も2日間楽しんできました!2026年08月31日 09時22分49秒

HAM FAIR 2026 / JP1LRT
ハムフェア2026、今年も2日間楽しんできました!

財布を忘れて《詰んだ》ところから始まり、0次会、6m DXer懇親会、ARDC講演、関東UHFコンテスト表彰式まで。たくさんの皆さんにお会いできた、楽しい2日間でした 📡

初日――国際展示場駅でいきなり《詰んだ》🤣

昨日・一昨日は ハムフェア2026 に参加してきました。

今年も出展者証を持っていなかったので、10時の開場を待つ一般入場組。とはいえ、朝から長蛇の列に並ぶのは苦痛なので(笑)、初日は 10時30分ごろ到着 をターゲットに自宅を出発しました。

会場までいろいろな行き方がありますが、この日は外も比較的涼しかったので、りんかい線の国際展示場駅から歩いて向かうことにしました。

ところが――
国際展示場駅に着いたところで《詰んだ》🤣

なんと……
財布を家に忘れてきました。

普段からあまり現金を持ち歩かない私ですが、さすがにハムフェアでは多少必要だろうと思っていたのに、その財布そのものがない(笑)

スマホケースの中には、非常用に入れてある エマージェンシー・キャッシュ5,000円

そして夜には6m DXerの皆さんとの懇親会。その予算もだいたい5,000円。

……はい、使えません🤣

そんなことを考えているうちに、11時に予定されていた仲間との記念撮影の時間が迫ってきます。

もう歩いている場合ではないのでタクシーへ。運転手さんに「Suica使えますか?」と確認するとOK。普段から モバイルSuica を使っているので、ここは無事突破(笑)

なんとか記念撮影にも間に合いました 📸

そのまま有明ガーデンで“0次会” 🍺

記念撮影のあとは、そのままの流れで有明ガーデンへ。

ハムフェア2026 懇親会 “0次会” スタート 🍺🤣

しゃぶしゃぶの飲み食べ放題で、ビールをジョッキ 7杯 流し込み、牛肉と野菜もしっかりいただいて満腹。

さて問題の支払いですが……仲間に PayPayで送金

財布がなくても、意外とどうにかなるものです(笑)

その後はハムフェア会場内をゆっくり散策。

普段SNSや無線でつながっている方、久しぶりにお会いする方、初めて直接ご挨拶できた方など、本当にたくさんの皆さんとお会いすることができました。

無線で声やコールサインを知っていても、実際に顔を合わせて話せるのは、やっぱりハムフェアならではですね 😊📡

秋葉原で6m DXer懇親会――PY2XB Fredさんも参加 🇧🇷

18時からは秋葉原へ移動し、6m DXerの皆さんとの懇親会

今年はブラジルから PY2XB Fredさん も参加されました 🇧🇷📡

宴会開始前にはFredさんとヨドバシカメラへ行き、Fredさんのスマートフォンケースと、奥様用のモバイルバッテリー選びにもお付き合い。

その後の懇親会では、6m DXの話はもちろん、いろいろと興味深い話を伺うことができ、とても有意義な時間になりました。

もちろん二次会にも参加 🍺🤣

2日目――ARDCの講演と関東UHFコンテスト表彰式

そしてハムフェア2日目。

この日は昼ごろから会場入りしました。

メインステージで行われた

「アマチュア無線で拓く次世代への架け橋
― イノベーション等を支える ARDC のビジョン ―」

のお話は、とても興味深く聞かせていただきました。

アマチュア無線を単に「今ある趣味」として見るのではなく、次の世代や技術、教育、イノベーションへどうつなげていくのか。

こういう話をハムフェアの場で聞けるのは、とても良いですね。

そして14時からは、第43回関東UHFコンテスト表彰式 を《見学》😅

なぜ《見学》かというと……

コンテスト当日の休みを申請するのを忘れてしまい、今年は参加できなかったから🤣

表彰される側には回れませんでしたが(笑)、多くのお知り合いの皆さんが表彰される姿を、拍手でお祝いしてきました 👏

2日目はそのまま帰宅。17時にはもう自宅でのんびりしていました。

やっぱりハムフェアは「人に会える」のが一番楽しい

今年のハムフェアも、2日間を通して、日頃から無線やSNSでつながっている本当に多くの皆さんとお会いすることができました。

直接お話しできた皆さん、ありがとうございました 😊

一方で、

「会場にはいたはずなのに、結局すれ違いで会えなかった!」

という方も本当にたくさんいらっしゃいました。

あれだけ多くの人が集まるイベントなので、こればかりは仕方ありませんね。

今回お会いできなかった皆さんとは、ぜひ来年こそ!

やっぱりハムフェアは、機器を見るだけのイベントではなく、
人と人が直接会えることこそが一番の楽しみなのかもしれません。

今年も楽しい2日間でした。
皆さん、ありがとうございました! 😊📡🍺

FT8の「最後の1 decode」を拾うために――Wide GraphとJTDX Filterを理解して使う2026年08月30日 10時09分56秒

ハムフェア2026のあと、6m DXer仲間で飲んでいた時のことです。話題がFT8の極弱信号のデコードになりました。 そこで僕が話したのが、「目的の局だけを何とかデコードしたい時は、リグのフィルターだけでなく、 WSJT-X / JTDXのWide Graphの表示範囲も狭めてみる」という方法です。

面白かったのは、そこにいた皆さんが「リグの受信フィルターを狭める」という方法は当然のように知っていたのに、 「Wide Graphを狭める」という発想はほとんどなかったことでした。

これは魔法ではありません。しかし、6mのマルチホップEsなどで、見えたり消えたり、-20数dB付近を行き来しながら、 「あと1回だけデコードできればQSOが進む」という場面では、覚えておいて損のないテクニックだと思っています。

Wide Graphは、単なる「表示窓」ではない

まず大前提です。WSJT-XのWide Graphは単なるウォーターフォール表示ではありません。 公式User Guideには、次のように明記されています。

“Decoding occurs only in the displayed frequency range.”

つまり、デコードはWide Graphに表示されている周波数範囲内でのみ行われます。 たとえばWide Graphを100~3300Hzまで表示していれば、その範囲がデコーダの探索対象になります。

JTDX 2.2.159のソースでも、この関係はかなり直接的に確認できます。 デコード時のパラメータ nfa にはWide Graphの開始周波数、 nfb にはWide Graphの上限周波数が設定され、デコーダ側へ渡されています。

ここがポイント Wide Graphの幅を変えることは、見た目を拡大・縮小しているだけではありません。 デコーダが探索する周波数範囲そのものを変えている、ということです。

「CPUを目的局に集中させる」は、感覚的には正しい

たとえば普段100~3300Hz、約3200Hz幅を探索しているところで、 目的局が1500Hz付近にいることが分かっているなら、 その周辺700~1000Hz程度までWide Graphを狭め、不要な範囲を探索対象から外すことができます。

これを「CPUパワーを目的局に集中させる」と表現すると、とても分かりやすいと思います。 ただし技術的により正確に言えば、 「不要な周波数範囲を探索対象から外し、デコーダの探索空間を限定する」ということになります。

もちろん、3200Hzから1000Hzへ狭めたからCPU負荷が単純に約1/3になる、という話ではありません。 FFTや音声前処理など、探索幅とは独立して必要な処理もあります。 それでも、デコーダが調べる候補の存在する範囲を限定できること自体には意味があります。

ただし、S/Nそのものが良くなるわけではない

ここは誤解してはいけません。Wide Graphを狭めても、受信した信号の物理的なS/Nが改善するわけではありません。 -23dBの信号が、それだけで-20dBになるわけではないのです。

FT8の限界領域のデコードでは、候補検出、同期探索、LDPC Decode、AP Decode、複数回のPass、 さらにデコード済み信号をSubtractして残った信号を再探索する処理など、いくつもの段階があります。

したがって、「探索範囲を狭めれば必ず感度が上がる」とは言えません。 一方で、限界付近の信号に対して不要な範囲を探索対象から外した結果、 広い範囲ではデコードしなかった信号が、狭めた時にはデコードするということは実戦上あり得ます。

重要 これは「デコード感度を何dB改善する」という種類のテクニックではありません。 デコーダに与える探索条件を変えることで、限界信号のデコード成功条件が変わることがある、 という理解が適切です。

リグのフィルターを狭めることとは、作用点が違う

「弱い信号ならリグのフィルターを狭める」という方法は、多くの方が使っていると思います。 しかし、リグのフィルターとWide Graphは同じ「帯域を狭める」操作でも、働く場所が違います。

📡 RF / IF / DSPリグの受信フィルター
不要な信号を前段で抑える
🔊 Audio受信音声をPCへ
ソフトへの入力
💻 DecoderWide Graphの範囲
探索する周波数範囲を限定

リグ側の帯域を狭めることで、強い近接信号によるAGC動作や受信系への影響を抑えられる場合があります。 一方、Wide Graphを狭めるのは、ソフトウェア側で「どこを探すか」を限定する操作です。

つまり、極弱局に集中したい時は、次の二段構えになります。

  1. リグ側で不要な受信帯域をできるだけ減らす。
  2. ソフト側でもWide Graphを目的局周辺へ絞り、デコーダの探索範囲を限定する。

実際には、Wide Graphをどこまで狭められるのか

ここで、実際の画面上ではどこまでWide Graphを狭められるのかも確認してみました。 Bins/Pixelを1にした状態で、私が現在使用しているWindows環境では、 WSJT-Xは約682Hz、JTDXは約572Hzまで狭めることができました。

これは固定された「最小デコード帯域」ではありません 682Hz / 572Hzという数字がデコーダの仕様として固定されているわけではありません。 Bins/Pixel=1のときの周波数スケールと、Wide Graphウィンドウを実際にどこまで細くできるかによって決まる表示幅です。 Windowsの表示スケーリング、フォント、使用言語、UIレイアウトなどによって多少変わる可能性があります。

つまり、「目的局の50Hzだけを残す」といった極端な狭帯域化は、 少なくとも通常のWide GraphのUI操作ではできません。 一方で、通常の数kHz幅から700~1000Hz前後へ狭めるだけでも、 探索対象をかなり限定することはできます。

狭ければ狭いほど良い、ではない

では、目的局が1500Hzにいるなら、可能な限りギリギリまでWide Graphを狭めれば最高なのか。 僕はそうは考えません。

FT8デコーダは、強い信号を先にデコードしてSubtractし、その後に近接した弱い信号を拾えることがあります。 目的局のすぐ近くに強い信号があるのに、それを探索範囲外へ追い出してしまうと、 状況によってはその恩恵を失う可能性があります。

そのため僕なら、目的局だけを極端に囲うのではなく、 まずは目的局を中心に±500Hz程度、つまり合計1000Hzくらいを目安に残して試します。

※ ±500Hz(合計約1000Hz)はWSJT-X/JTDX公式の推奨値ではなく、 極弱局へ集中する際の実戦上の目安として僕が考えている値です。 上記の最小幅まで最初から絞り切るのではなく、まずは1000Hz程度を残し、状況を見ながら調整します。

僕ならこう試す

  1. 通常運用では、例えば100~3300Hz程度を表示。
  2. どうしてもデコードしたい極弱DXが現れたら、まずリグの受信フィルターを狭める。
  3. Wide Graphも目的局周辺1000Hz程度へ縮める。
  4. 状況を見ながら、必要ならもう少し狭める。
  5. 近接強信号や呼んでくる他局も考慮し、「狭めすぎ」になっていないか確認する。

では、JTDXの「Filter」ボタンとは何が違うのか

ここまで読んだJTDXユーザーなら、 「それならJTDXのFilter機能と同じでは?」と思うかもしれません。 発想には共通する部分がありますが、完全に同じものではありません。

操作何を狭めるか考え方
リグの受信フィルター 無線機側の受信帯域 ソフトへ入る前の不要信号を減らす
Wide Graph wideband decoderの探索範囲 広帯域探索の「窓」そのものを狭くする
JTDX Filter 現在のRx周波数付近 選択したRx信号周辺だけを狙うnarrow decoding

現在のJTDX 2.2.159のFilterボタンのツールチップでは、帯域幅は次のように説明されています。

  • FT8:170Hz
  • FT8 Hound:580Hz
  • FT4:274Hz
  • JT9:115Hz
  • T10:225Hz

FilterはRx信号のスペクトラムを中心に置かれます。つまりFT8なら、 現在選択しているRx周波数周辺の170Hzという非常に狭い範囲へ対象を限定する機能です。

JTDX Filterの「昔の説明」と「現在の説明」が面白い

ここからが少し興味深いところです。

2018年版のJTDX User ManualではFilterについて、 デコード候補数を減らすことでdecoding attemptsがより少ない候補へ再配分され、 信号をデコードできる確率がわずかに上がるという趣旨の説明がありました。

ところが現在のJTDX 2.2.159のFilterツールチップには、はっきりこう書かれています。

“Filter functionality can not improve signal decoding”

つまり現在の説明では、Filter機能そのものはsignal decodingを改善するものではないとされています。 主目的は、遅いCPUでも送信開始までにデコード処理を終えられるようにし、 送信直前まで処理が続いてメッセージが変わることを避けることです。

さらに現在のツールチップには、Filter帯域外から自分を呼んでいる局は失われるため、 CPU上本当に必要な場合だけ使うようにという注意もあります。

ここは「矛盾」ではなく、世代差として読むのが良さそう JTDXのデコーダは長年にわたり改良されています。古いマニュアルの説明を、現在の2.2.159へそのまま当てはめるべきではないでしょう。 なお現在のAdvanced設定にも、decoding attemptsはlow-SNR信号のdecoding efficiencyに影響し、 wideband側とRx-frequency側の双方に関係する、という説明は残っています。 つまり「decoding attemptsが重要」であることと、 「Filterボタン自体を感度改善機能と説明しない」ことは両立します。

JTDXのAuto RX frequency Filterにも注意

JTDXには AutoSeq → Auto RX frequency Filter があり、 QSO進行中にRx-frequency Filterを自動で使うこともできます。

これは便利な機能ですが、Filterが有効な間は帯域外からの呼び出しを拾えなくなることがあります。 特にCQを出して複数の周波数から呼ばれるRUN運用では、 「今FilterがONなのか」を意識しておく必要があります。

結局、何を覚えておけばいいのか

今回の話を一言でまとめるなら、

欲しい信号がどこにいるか分かっているなら、不要な範囲まで常に全部探させる必要があるとは限らない。

ただし、「狭くすれば必ずデコード感度が上がる」と単純化してはいけません。 リグの受信フィルター、Wide Graph、JTDX Filterは、それぞれ違う場所に作用する別の道具です。

どの道具も、伝搬がなければ信号を作り出すことはできません。 十分強い信号なら、こんな工夫をする必要もありません。

でも6m DXで、目的局がウォーターフォールには確かにいる。 ときどき一度だけデコードする。 あと一つReportが欲しい。あと一つRR73を拾いたい。

そんな「あとほんの少し」の場面なら、 リグのフィルターだけでなく、Wide Graphの幅も思い出してみてください。

最後の1dBならぬ、最後の「1 decode」を拾えるかもしれません。📡

情報は共有した方が、この趣味は面白い

飲み会でこの話をした時、何人かから「それは知らなかった」という反応がありました。

DXの世界では、もしかすると「そんなことを皆に教えなくてもいいのに」と思う方もいるかもしれません。 でも僕は逆です。

アマチュア無線は、誰かが見つけた知識や工夫を共有し、他の人が試し、 そこからまた新しい発見へつながっていく趣味だと思っています。

アンテナも、伝搬も、受信技術も、ソフトウェアも同じです。 自分だけの「秘密の技」にするより、 「こうすると少し良くなるかもしれない。みんなも試してみて」と共有する。

そして誰かが実験して、「こういう条件では効いた」「ここでは逆効果だった」とさらに情報を積み重ねる。 そうやって知識が育っていくことこそ、アマチュア無線らしさの一つではないでしょうか。

参考資料

  1. WSJT-X User Guide, “Wide Graph” — “Decoding occurs only in the displayed frequency range.”
    https://wsjt.sourceforge.io/wsjtx-main_en.html
  2. JTDX 2.2.159 source, mainwindow.cpp — Wide Graphの開始周波数・上限周波数を decoder parameters nfa/nfbへ設定。
    Debian Sources: JTDX mainwindow.cpp
  3. JTDX 2.2.159 source, mainwindow.ui — Filter帯域幅および現在のFilter機能説明。
    Debian Sources: JTDX mainwindow.ui
  4. JTDX 2.2.159 source, Configuration.ui — decoding passes / attemptsとlow-SNR decoding efficiencyの説明。
    Debian Sources: JTDX Configuration.ui
  5. JTDX User Guide, Version 2018-01-08 — 旧Filter説明。
    JTDX User Manual 2018 PDF

※ 本文中の実戦的な運用目安は筆者の考えを含みます。ソフトウェアの動作・仕様については、 上記公式文書またはソースコードの記述と区別して記載しています。

【公開RC】WSJT-X Improved JP1LRT Edition P5を公開しました📡2026年08月28日 23時51分54秒

PUBLIC RELEASE CANDIDATE

【公開RC】WSJT-X Improved JP1LRT Edition P5を公開しました 📡

新しい番号を追うだけではなく、実際のFT8/FT4運用で「こう動いてほしい」を積み上げたJP1LRT Editionの一般公開RCです。

20260824A-REB522-P5 P5-AL Release Candidate
WSJT-X Improvedはすでに3.2.0が公開されています。
では、なぜ今になって3.1.0ベースのJP1LRT Editionを公開するのか?
答えは単純です。
3.2.0にはない、JP1LRT Edition独自の運用支援機能が数多く入っているからです。

新しいバージョン番号だけを追うのではなく、実際のFT8/FT4運用、とりわけCQ RUN、DXハンティング、短時間の6mオープンなどで「こう動いてほしい」と感じてきた機能を積み上げてきました。

今回公開したのは、WSJT-X Improved JP1LRT Edition 20260824A-REB522-P5 / P5-ALです。

主な特徴

🎯AutoSeq 2/AutoSeq 3

複数局から同時に呼ばれたとき、単純なデコード順や距離だけではなく、ユーザーが設定した優先順位で相手局を選びます。

New DXCC、バンドニュー、Wanted局、LoTWユーザーなどを考慮する、JTDX由来の考え方をWSJT-X側へ持ち込んだCQ RUN機能です。

🟧Hunting/Wanted Pounce

Wantedに登録したコールサイン、プリフィックス、グリッドの局を待ち受け、条件が成立すると自動的に対象局を選択します。

P5では、Huntingから開始したQSOが正常に完了すると、CQを自動送信せず、オレンジ色のHunting待機状態へ戻るReturn to Huntingを再検証しました。

「73送信後に停止」がONなら、最終送信を安全に完了してAuto Txを停止し、Huntingにも戻りません。

🛡️Terminal Hold

RR73/73付近で、QSO相手や送信状態が早く解除されすぎることを防ぎます。

最終送信、PTT終了、相手局からのRR73/73、手動で選んだ次の局などを整理し、安全なタイミングで次の動作へ引き継ぎます。

🔄安全な手動引継ぎ

送信中に別の局を選んでも、現在の送信や交信相手を不用意に壊さないよう、即時切替と予約切替を使い分けます。

現在進行中のQSO、最終73、手動で選択した相手局は、自動選局より優先して保護されます。

Best S&Pの言語依存不具合を修正

従来は、翻訳されたハイライトカテゴリ名を内部へ保存し、固定された英語文字列と比較していたため、日本語など英語以外のUIでは「バンドの新コールサイン」や「新DXCC」が正しく判定されない場合がありました。

現在は翻訳表示ではなく、内部の型付きカテゴリ値で判定します。

上流側へもフィードバック済み

この修正は上流側にも報告し、独立した差分として提供しています。表示言語に依存せず、同じ意味のカテゴリを同じ内部値として扱う方向へ改めました。

Standard版とAL版

特徴 QSOロジック
Standard 従来のWSJT-X Improved PLUS系レイアウト 主要なQSOロジック・安全機能はAL版と同等
AL JTDXに近い操作感を持つレイアウト 主要なQSOロジック・安全機能はStandard版と同等

表示・診断機能も充実

  • LoTWユーザー表示
  • Worked/B4情報
  • Wanted表示
  • 拡張されたActivity Window
  • ウォーターフォール表示改善
  • Avg/Lag/Sync
  • 詳細なALL.TXT診断マーカー
  • 8桁/10桁グリッドロケーター入力
  • PSK Reporterへの高精度位置情報送信

なお、8桁/10桁のグリッドロケーターを設定しても、通常のFT8/FT4でオンエア送信されるロケーターは従来どおり4桁に制限されます。

3.2.0が出たのに、なぜ3.1.0ベースなのか

今回のP5は、WSJT-X Improved 3.1.0の2026年5月22日版をベースにしています。3.2.0ベースではありません。

WSJT-X Improved 3.2.0 JP1LRT Edition P5
3.2.0で追加された新機能・改善 CQ RUN、Hunting、相手局管理、安全な終端処理、独自の表示・診断機能

つまり、「3.2.0が出たから、この3.1.0ベース版には意味がない」という関係ではありません。

むしろFT8/FT4の実運用では、3.2.0とは違う方向の機能を楽しんでいただけると思います。

今回はGAではなく、一般公開RCです

⚠️ 最初は既存の正常動作版を残したままお試しください。
  • 別フォルダへ展開
  • 別の --rig-name プロファイルを使用
  • 自動選局を使う場合も、生成される送信メッセージとDX Callを必ず監視
  • 無人・無監視運用は想定していません

公開内容

  • Standard版
  • AL版
  • 各SHA-256確認ファイル
  • Standard/ALの対応ソースバンドル
  • 英語/日本語/ドイツ語/スペイン語のUser Guide 1.7
  • 統合SHA256SUMS
📥 Download — Public Release Candidate

興味のある方は、まずUser Guideを読んだうえでお試しください。

GitHub Release Page を開く

https://github.com/jp1lrt/wsjtx-avelag/releases/tag/20260824A-REB522-P5

不具合報告をいただける場合

次の情報を添えていただけると、原因を追いやすくなります。

  • 使用したバージョン
  • UTC時刻
  • モード
  • 関連する設定
  • 行った操作
  • 期待していた動作
  • 実際に起きた動作
  • 可能であればALL.TXTの該当部分
限定テストに協力してくださった皆さん、ソースレビューと実運用確認に協力してくださった皆さんに、改めて感謝いたします。📡

【WSJT-X Improved 3.2.0 / 260818版 ― 何が変わった?】2026年08月18日 16時20分43秒

先ほどWSJT-X Improved 3.2.0がリリースされたことをお伝えしましたが、今回は3.1.0 260522版から何が変わったのかを、リリースノートをもとに日本語で簡単に解説してみます。

今回の3.2は、一言でいえば、

「6mを含むEME/Q65運用の大幅強化」+「普段FT8/FT4を使っている人にも役立つ細かな改善と修正」

というアップデートです。

EMEをやっていない方には馴染みのない機能も多いと思いますので、そのあたりも含めて少し噛み砕いて紹介します。

なお、これはJoe Taylor K1JTらによるWSJT-X本家そのものではなく、DG2YCB Uwe氏が開発している WSJT-X Improved の新バージョンです。


■ ウォーターフォール上のコールサイン表示がさらに実用的に

3.1で追加された「ウォーターフォール上へのコールサイン表示」が改良されています。

CQを出している局は緑背景で表示。

「73/RR73も表示」のオプションを有効にしている場合は、それらも同様に扱われます。

現在DX Call欄に入っている局、つまり自分が狙っている相手は、Band Activityと同じように赤背景+白文字で表示されます。

さらに大きな変更として、ウォーターフォール上に表示されているコールサインを直接クリックできるようになりました。

ダブルクリックすれば、その局とのQSOを開始できます。

WSJT-Xでは、この機能を使う場合「Hold Tx Freq」がONである必要があります。

つまりウォーターフォール上のコールサイン表示が、単なる「見える表示」から、実際のQSO操作にも使えるインターフェースへ進化しています。

この機能はWSJT-Xだけでなく、QMAP、MAP65にも展開されています。


■ 6m EME向け「liveCQ」プロトコルを拡張

今回の3.2で特に大きなテーマの一つです。

W7GJ Lance氏による6m EME DXpedition H44GJ を念頭に開発された機能で、主にQ65 Pileup運用を強力に支援します。

普通のスポットというと、

「○○局がこの周波数に出ている」

という情報を送るものを想像しますが、今回のliveCQは少し違います。

受信したすべてのQ65メッセージをN6NU氏が用意した専用サーバーへ送り、サーバー側で情報を解析します。

これによってDXpedition局側は、

「今、どの局が自分の信号を実際に受信できているのか」

をActive Stationsウィンドウで、ほぼリアルタイムに確認できます。

EME、特に6m EMEでは伝搬条件が非常に厳しく、

「誰が呼んでいるか」

だけではなく、

「誰のところまでこちらの信号が届いているか」

が分かることには大きな意味があります。

QMAPとMAP65からも新しい

https://livecq.n6nu.org

へスポットできるようになり、さらに複数URLへの同時スポットにも対応しました。


■ QMAP v1.0 ― Click-to-Workを搭載

QMAPも正式にv1.0となりました。

最も分かりやすい新機能が Click-to-Work です。

コールサインのオーバーレイ、デコードされた個々のメッセージ、あるいはBand Map上のコールサインをクリックすると、

・コールサイン
・周波数
・Odd / Evenのタイムスロット
・Q65サブモード

などの情報がWSJT-Xへ渡されます。

そしてダブルクリックすればQSO開始。

つまり、

見つける → 運用条件をセットする → 呼ぶ

という操作がかなり直接的になりました。

WSJT-X側はQ65モードで、VHF featuresを有効にしておく必要があります。

さらに、

・QMAPを複数同時起動可能
・WSJT-Xと同じく--rig-name=NAMEで個別管理可能
・複数のWSJT-XとQMAPを個別にペアリング可能
・Band Mapウィンドウを追加
・Astro DataやBand Mapを開いていた状態を次回起動時に復元
・N6NU SDR bridgeと連携し、最新版では複数sliceにも対応

など、本格的なEME/SDR運用をかなり意識した進化になっています。

QMAPのユーザー設定やデータの保存場所もWindowsでは

AppData/Local/QMAP

へ変更されました。

初回起動時には、旧WSJT/wsjtx/binディレクトリにある既存データが自動的にインポートされます。


■ MAP65 v4.0 ― WSJT-Xとの連携が大きく進化

MAP65もv4.0になりました。

こちらもEMEをやっている方にはかなり大きな変更です。

新しい方式では、

MAP65 = 広帯域受信担当
WSJT-X = 実際のQSO担当

という使い分けが可能になりました。

MAP65はxPol Rxを含む広帯域受信を担当しながら、実際のQSOはWSJT-Xで行えます。

そのため、

・CAT制御
・AutoSeq
・ログブック
・その他WSJT-X側の機能

をそのまま利用できます。

MAP65上でコールサインのオーバーレイやメッセージをクリックして局を選択すると、その情報をWSJT-Xへ渡してQSOできます。

さらに、MAP65とWSJT-Xによる同時受信も可能になりました。

MAP65で広帯域を監視しつつ、WSJT-Xにも適切なナローバンド音声を入力しておけば、両方が同じ信号のデコードを試みることができます。

WSJT-Xのナローバンドデコーダーは非常に高感度なので、EMEでは新しい可能性が広がりそうです。

MAP65にもQMAPと同じClick-to-Workが実装され、

・コールサイン
・グリッド
・Odd / Even
・Txモード

などをクリック操作で設定、またはWSJT-Xへ転送できます。

条件を満たしていればダブルクリックでQSO開始も可能です。

その他にも、

・IQストリーム192kHz帯域幅へ対応
・従来の96kHz / 95.238kHzとの互換性を維持
・Q65のDecode Depthを設定可能
・過去のTR周期の信号を再デコードする実験的機能
・Astro Data / Band Map / Messagesウィンドウの状態を記憶

などが追加されています。

MAP65の設定・データ保存場所も

AppData/Local/MAP65

へ変更されます。


■ ここからは普通のFT8/FT4ユーザーにも関係する変更

EMEをやらない方は、むしろここからが重要かもしれません。


1. wsjtx_log.adiの保存場所とファイル名を指定可能に

WSJT-Xのログファイル

wsjtx_log.adi

の保存場所とファイル名を選択できるようになりました。

例えば、

・NASやネットワークドライブへログを置く
・ユーザーごとに別々のログを使う
・運用環境ごとにログを分ける

といった使い方が可能になります。

Settings → Reporting → Loggingに新しい設定があります。


2. Highlight orange / Highlight blueを拡張

Highlight orange / Highlight blueのプレフィックス指定で、

* = ワイルドカード
! = 除外

が使えるようになりました。

例えば、

;K*;!KH6!KL!KP!

のような指定が可能です。

つまり、Kで始まるプレフィックスを広く対象にしながら、KH6、KL、KPなどを除外するといった設定ができます。

DXを追いかける方にはかなり便利そうです。

ただし書式にはルールがあります。

コールサインやグリッドはカンマ区切りで、各コールサインの後にもカンマが必要。

プレフィックスは前後をセミコロンで囲みます。

ワイルドカード*を使えるのは1文字のプレフィックスの後だけ。

2~3文字のプレフィックスを除外する場合は!で囲みます。


3. PWR / SWRに加えてALCも表示

対応している無線機では、

PWR / SWR / ALC

をWSJT-X上に表示できるようになりました。

Settings → Radio → Rig Dataで

「Display PWR, SWR and ALC」

を選択します。

さらにALCが高い場合、黄色または赤背景で警告表示することもできます。

デジタルモードではALC管理も重要なので、対応リグを使っている方には実用的な改善でしょう。


4. DX Call欄の局とのメッセージだけを表示可能

CQまたはCQ/73チェックボックスを右クリックすると、

現在DX Call欄に入っている局との送受信メッセージだけを表示できます。

混雑しているバンドやDX pileupなどで、

「今、この局とのやり取りだけ見たい」

という時には便利そうです。


5. 送信中のバンドボタン誤操作を防止

送信中に誤ってバンドボタンをクリックしてしまい、周波数を変更してしまう事故を防ぐようになりました。

「Allow Tx frequency changes while transmitting」が有効になっている場合だけ、送信中の変更が許可されます。

派手な機能ではありませんが、実運用ではありがたい安全対策です。


6. コンテストモードのログ処理を改善

コンテストモード中は<state>タグを書き込まないよう変更されました。

このタグがログ処理上の問題を起こしていたためです。

また、

「ARRL Field Dayモードに切り替えますか?」

といった警告も、同一セッション中に何度も表示されず、1回だけ表示されるようになりました。

コンテスト運用者には嬉しい改善だと思います。


7. RRRにも国情報とハイライト表示

RRRを含むメッセージについても、国・エンティティ情報とハイライト色が表示されるようになりました。

交信終盤のメッセージでも相手局の情報を確認しやすくなります。


8. Cloudlog関連の修正

ホテルなどからQSOをアップロードする際に発生していたCloudlog関連の問題が修正されています。


9. WSPR / MSK144 / Q65関連

・WSPRモードでのTCI audioの問題を修正
・「MSK144/Q65: Tx until 73 is received」機能を修復
・MSK144の安定性を改善

といった修正も行われています。


■ 新機能「TX-Inhibit」

これも興味深い新機能です。

同じバンドで、

WSJT-Xによるデジタル運用

SSB/CW運用

を併用するような環境で、PTTが競合する事故を防ぐための機能です。

特に複数の無線機や複数のオペレーターが同時に運用するクラブ局、コンテスト局などで有用でしょう。


■ その他

・Linux用Debianパッケージの互換性改善
・Hamlibを4.7.2へ更新

なども行われています。


■ まとめ

今回のWSJT-X Improved 3.2は、FT8/FT4そのものを全面的に作り替えたというより、

EME/Q65運用環境を大きく進化させたバージョン

と見ると分かりやすいと思います。

特に、

QMAP / MAP65 / WSJT-X / liveCQを連携させ、「誰がこちらを受信できているか」を把握し、見つけた局をクリックして、そのままWSJT-Xで交信する

という方向へかなり進みました。

一方、EMEをやらないFT8/FT4ユーザーにとっても、

・Highlight orange / blueのワイルドカードと除外指定
・ログファイル保存場所の自由化
・ALC表示
・DX Call局だけを表示する機能
・送信中のバンド誤操作防止
・コンテストログ関連の改善
・RRRへの国情報・ハイライト表示
・TX-Inhibit

など、普段の運用に直接関係する改善が多数含まれています。

ですので、

「3.2はEME向けのアップデートだから、自分には関係ない」

というわけではありません。

EME/Q65ユーザーにはかなり大きなアップデート。

FT8/FT4中心のユーザーにとっても、日常運用の使い勝手や安全性を改善する変更が多数入ったバージョン、と考えるのがよさそうです。

【WSJT-X Improved 3.2.0 / 260818版 リリース】2026年08月18日 16時17分58秒

【WSJT-X Improved 3.2.0 / 260818版 リリース】

本日、WSJT-X Improvedの新しい3.2シリーズがリリースされました。

https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v3.2.0/

今回のアップデートは、一言で言えば、

「6mを含むEME/Q65運用の大幅強化」+「普段FT8/FT4を使っている人にも役立つ細かな改善と修正」

です。

リリースノートは英語でかなり専門的なので、「結局何が変わったの?」という方向けに、日本語で少し噛み砕いてまとめてみます。

なお、これはJoe Taylor K1JTらによるWSJT-X本家そのものではなく、DG2YCB Uwe氏が開発している WSJT-X Improved の新バージョンです。


■ ウォーターフォール上のコールサイン表示がさらに実用的に

3.1で追加された「ウォーターフォール上へのコールサイン表示」が改良されています。

CQを出している局は緑背景で表示。

現在DX Call欄に入っている局、つまり自分が狙っている相手は、Band Activityと同じように赤背景+白文字で表示されます。

さらに大きな変更として、ウォーターフォール上に表示されているコールサインを直接クリックできるようになりました。

ダブルクリックすれば、その局とのQSOを開始できます。

WSJT-Xでは、この機能を使う場合「Hold Tx Freq」がONである必要があります。

つまり、ウォーターフォールが単なる「見える表示」から、実際の運用操作にも使えるインターフェースへ進化しています。


■ 6m EME向けの「liveCQ」が大幅強化

今回の3.2で最も大きなテーマの一つです。

W7GJ Lance氏による予定されている6m EME DXpedition H44GJ を念頭に開発された機能で、Q65 Pileup運用を強力に支援します。

通常のスポットというと「○○局がここに出ている」という情報を送るイメージですが、今回のliveCQは少し違います。

各局が受信したすべてのQ65メッセージをN6NU氏が用意した専用サーバーへ送り、そこで情報を集約します。

これによってDXpedition局側は、

「今、自分の信号を実際に受信できている局は誰なのか」

をActive Stations画面で、ほぼリアルタイムに確認できます。

EME、特に6m EMEでは伝搬状況が非常に厳しく、「呼んでいる局」だけでなく「そもそもこちらを受信できている局」が分かることには大きな意味があります。

QMAP、MAP65からも新しいliveCQサーバーへスポットでき、さらに複数のURLへ同時に送信することも可能になりました。


■ QMAP v1.0 ― 「Click-to-Work」搭載

QMAPも正式にv1.0へ進化しました。

一番分かりやすい新機能が Click-to-Work

コールサインのオーバーレイ、デコードされたメッセージ、Band Map上のコールサインなどをクリックすると、

・コールサイン
・周波数
・Odd/Evenの送受信タイミング
・Q65サブモード

といった情報がWSJT-Xへ自動的に渡されます。

そしてダブルクリックすればQSO開始。

つまり「見つける→情報をセットする→呼ぶ」という操作が、かなり直接的になります。

WSJT-X側はQ65モードで、VHF featuresを有効にしておく必要があります。

さらに、

・QMAPを複数同時起動可能
--rig-name=NAMEで個別管理
・複数のWSJT-XとQMAPをそれぞれペアリング可能
・Band Mapウィンドウ追加
・Astro DataやBand Mapを開いていた状態を次回起動時に復元
・N6NU SDR bridgeの最新機能、複数sliceにも対応

など、SDRを使った本格的なEME環境をかなり意識した進化になっています。

設定やデータの保存場所もWindowsでは

AppData/Local/QMAP

へ変更。

旧ディレクトリのデータは初回起動時に自動インポートされます。


■ MAP65 v4.0 ― WSJT-Xとの連携が大きく変わった

MAP65もv4.0になり、こちらもEMEをやっている人にはかなり大きな変更です。

新しい方式では、

MAP65=広帯域受信担当
WSJT-X=実際のQSO担当

という使い分けが可能になりました。

MAP65はxPolを含む広帯域受信を担当し、実際の送受信シーケンス、CAT制御、AutoSeq、ログなどはWSJT-X側で処理できます。

これはかなり合理的な構成です。

MAP65で見つけた局をクリックすると、その情報がWSJT-Xへ渡され、WSJT-X側でそのままQSOできます。

さらにMAP65とWSJT-Xを同時に受信させることも可能。

MAP65の広帯域受信と、WSJT-Xの高感度なナローバンドデコーダーを同時に使って、同じ信号のデコードを試みることができます。

MAP65にもQMAPと同様のClick-to-Workが実装されました。

その他、

・IQストリーム192kHz帯域幅対応
・従来の96kHz / 95.238kHzとの互換性維持
・Q65のDecode Depthを設定可能
・過去のTR周期を再デコードする実験機能
・Astro Data / Band Map / Messagesのウィンドウ状態を記憶

なども追加されています。

MAP65の設定保存場所も

AppData/Local/MAP65

へ変更されます。


■ ここからは普通のFT8/FT4ユーザーにも関係する変更

EMEをやらない人は、むしろここからが重要です。

1. wsjtx_log.adiの保存場所とファイル名を自由に指定可能

これまでは基本的に決められた場所にあったwsjtx_log.adiですが、保存先とファイル名を指定できるようになりました。

例えば、

・NASやネットワークドライブへログを置く
・ユーザーごとに別ログを使う
・運用環境ごとにログを分離する

といった使い方が容易になります。

Settings → Reporting → Loggingから設定できます。


2. Highlight orange / Highlight blueがさらに強力に

プレフィックス指定で、

* ワイルドカード
! 除外指定

が使えるようになりました。

例えば、

;K*;!KH6!KL!KP!

のように指定すれば、Kで始まる対象を広く指定しつつ、KH6、KL、KPなどを除外する、といった設定ができます。

DXingをしている人にはかなり便利な機能です。

なお書式にはルールがあり、

コールサイン・グリッド → カンマ区切り
プレフィックス → セミコロンで囲む
ワイルドカード → 1文字プレフィックスの後のみ使用可能
2~3文字プレフィックスの除外 → !で囲む

という仕様です。


3. PWR / SWRに加えてALCも表示

対応している無線機では、送信中の

PWR / SWR / ALC

をWSJT-X上で確認できるようになりました。

さらにALCが高い場合、黄色や赤背景で警告表示することもできます。

デジタルモードではALCの管理は重要なので、対応リグを使っている人には実用的な改善です。


4. DX Callに入っている局だけを一時的に表示

CQまたはCQ/73チェックボックスを右クリックすると、

DX Call欄に現在入っている局との送受信メッセージだけを表示できます。

混雑しているバンドやDX pileupで、特定局とのやり取りだけを追いたい時に便利そうです。


5. 送信中のバンドボタン誤操作を防止

送信中にうっかりバンドボタンをクリックして、周波数を変えてしまう事故を防ぐようになりました。

「Allow Tx frequency changes while transmitting」を有効にしている場合だけ、送信中の変更が許可されます。

地味ですが、実運用ではありがたい安全対策です。


6. コンテストログ関連の修正

コンテストモードでは<state>タグを書き込まないよう変更されました。

このタグが原因でログ処理上の問題が発生していたためです。

また、

「ARRL Field Dayモードに切り替えますか?」

のような警告も、同じセッション中に何度も出ず、1回だけ表示されるようになりました。

コンテスト運用者には嬉しい改善だと思います。


7. RRRメッセージにも国名・ハイライト表示

これまでのCQ等だけでなく、RRRを含むメッセージについても国・エンティティ情報やハイライト色が表示されるようになりました。


8. Cloudlog関連修正

ホテルなど、通常とは異なる場所・ネットワーク環境からQSOをアップロードする際に発生していたCloudlog関連の問題が修正されています。


9. WSPR / MSK144 / Q65関連の修正

・WSPRモードでのTCI audio問題を修正
・「MSK144/Q65: Tx until 73 is received」を修復
・MSK144の安定性向上

なども行われています。


■ 新機能 TX-Inhibit

これも面白い機能です。

同一バンドで、

WSJT-Xによるデジタル運用
SSB/CW運用

を併用している場合に、PTTが競合して同時送信してしまうような事故を防止するための機能です。

特に複数の無線機やオペレーターを使うクラブ局、マルチオペのコンテスト局などで役立ちそうです。


■ その他

Linux用Debianパッケージの互換性改善。

Hamlibは4.7.2へ更新されています。


■ まとめ

今回のWSJT-X Improved 3.2は、FT8デコーダーそのものを大きく刷新したバージョンというより、

EME/Q65運用環境を一段進化させたバージョン

と見るのが分かりやすいと思います。

特に、

QMAP / MAP65 / WSJT-X / liveCQを連携させ、「誰が聞こえているかを把握し、見つけた局をクリックして、そのままWSJT-Xで交信する」

という方向へかなり進みました。

一方、EMEをやらないFT8/FT4ユーザーにとっても、

・Highlight orange / blueのワイルドカード、除外指定
・ログファイル保存場所の自由化
・ALC表示
・DX Call局だけを表示する機能
・送信中のバンド誤操作防止
・コンテストログ関連修正
・RRRへの国情報・ハイライト
・TX-Inhibit

など、日常運用で便利な改良が多数入っています。

ですので、

「3.2はEME専用アップデートだから、自分には関係ない」

というわけではありません。

なお開発者自身も、大きな変更を含む新バージョンへの更新前には、WSJT-X.iniwsjtx_log.adiをバックアップしておくことを推奨しています。


【高いAIを使えば、難しい問題も一発で解決して、かえって安く済む……はずだった話🤣😭】2026年08月13日 14時00分00秒


開発中のWSJT-X Improved JP1LRT Editionに、限定テスターのJK1BPAさんから、再現性のある不具合報告が届きました。

状況はこうです。

相手局からRレポートを受信
 ↓
こちらがRR73を送信
 ↓
相手に届かなかったため、相手が同じRレポートを再送
 ↓
ところがこちらは、RR73送信直後に交信相手の情報をクリアしてしまい、再送されたRレポートに反応できない

今回は再現確認のため、JK1BPAさんが送信出力を意図的に絞り、最初のRR73を相手へ届かせないという試験まで行い、ALL.TXTも提供してくれました。📡

ログを解析すると、これはAutoSeq2やAutoSeq3ではなく、CQを手動でダブルクリックして呼び出した普通のS&P運用で起きていました。

まずChatGPT側でソースコードを追跡し、原因と修正方針を整理。
次にClaude Sonnet 5へ、先入観を与えすぎない形で独立レビューを依頼しました。

Sonnetの一次解析は概ね妥当でしたが、一部に、

「この大きな処理ブロックも手動運用へ開放した方が安全かもしれない」

という提案がありました。

しかし、そのブロックは約638行。

中には単なるRR73再送処理だけでなく、

・AutoSeq2/3の候補局収集
・Wanted Hunting
・候補局の順位付け
・AS2 late-pick
・Auto Txの自動ON
・別局への自動呼出開始

まで含まれています。

もしここを安易に手動運用へ開放すると、RR73の再送を直した代わりに、操作者が意図していない別局を勝手に呼び始める可能性があります。これは危ない。😱

そこでRound 2。

ClaudeをSonnet 5から最上位のOpus 5へ変更し、エフォートもデフォルトの「高」ではなく「超高」に設定。

さらに、

「前回の自分の結論も、こちらの懸念も、どちらも信用せず、生のソースから実行順序と状態遷移を再導出せよ」

という、かなり厳しいプロンプトを渡しました。

要求したのは、

・最初のRレポート受信
・RR73送信開始
・Terminal Holdのarm
・ログ処理と画面クリア
・物理送信終了
・次の復号処理
・Rレポート再受信
・2回目、3回目のRR73
・相手から73/RR73/RRRを受信した場合
・送信上限とタイムアウト
・AutoSeq2/3やWanted Huntingへの副作用
・最小修正diff
・回帰試験表

まで全部です。

すると、さすがOpus 5・超高。

考える。
ひたすら考える。
そして猛烈に利用枠を食う🤣

現在セッションの消費量が、

52%
 ↓ 5分後
64%
 ↓
ついに100% 🔴

途中で、

「Claudeの応答を最後まで生成できませんでした」

げーーーーー🤣😭

再試行すると、

Claudeの回答が中断されました

またかよ🤣😭

さらにもう一度走らせると、また失敗表示。

これはもう、超高+大規模解析で処理限界に当たっている。分割するしかないか……

と思ったその直後、なぜか突然、完成した長大なレビュー報告書と提案パッチを吐き出しました(笑)。

そして現在セッションは、きれいに100%使用済み。




まさに、燃料を全部使い切って滑走路へ着陸した大型機状態です✈️🤣

追加クレジットの表示も、最後の解析中に$6.42から$7.08へ増加。

「高いAIを使えば、一発で地雷まで見つけて結局安く済む」

という話を書くつもりだったのに、実際には途中で何度も生成に失敗し、セッション枠を完全に食い尽くすという、予想以上に面白い展開になりました。

しかし、出てきた結果はかなり重要でした。

Opus 5は、一次解析で自分が提案した「大きなAutoSeqブロックの開放」を明確に撤回。

ソースを再追跡した結果、

・RR73再送に巨大なAutoSeqブロックを開放する必要はない
・そこを開放するとWanted Huntingや自動選局が手動運用へ流入する
・RR73再送にはprocessMessage()の再実行すら不要
・交信相手、Tx4、Auto Txを保持すれば、既存の周期送信機構がRR73を再送する
・送信は3回のソフトリミットで止まる
・さらに10回上限、300秒上限、無応答タイムアウトも残る
・相手から73/RR73/RRRを受信した場合も既存の安全処理で終了できる

と結論しました。

つまり必要なのは、大きな自動選局機構を触ることではなく、

「Terminal HoldをAutoSeq2/3など特定モードだけの機能にせず、通常の手動S&Pでも利用できるようにする」

という、ずっと小さな修正でした。

さらに、設定値の異常によってCQ応答モードが空欄になり、その状態が設定ファイルへ再保存され続ける別の問題も発見。

こちらも、無効な値を安全な「CQ: None」へ戻す小さな修正案が出ました。

最終的な提案パッチは、

・変更1ファイル
・4関数
・5ハンク
・危険な638行のAutoSeqブロックは変更ゼロ

という、かなり絞り込まれた内容です。

もちろん、AIがそう言ったから採用するわけではありません。

Opusの報告とパッチをChatGPT側でも、正式なP2ソース、生のALL.TXT、実際の関数呼出順序と突き合わせて再確認しました。

結果、技術的な中核は整合。
パッチも正式ソースへcleanに適用可能。
現時点でブロッキング欠陥は見つかっていません。

ただし、作業はまだこれからです。

現在配布中のP2正式パッケージは変更せず、そのまま観察を継続。

今回の修正は別の隔離テスト版として実装し、

・手動S&P
・FT8/FT4
・RR73再送
・相手の73/RR73/RRR
・AutoSeq2/3
・Max Distance
・Wanted Hunting
・意図しない別局への自動送信が起きないこと
・異常設定値の自動修復

などを改めて実機試験します。

今回改めて感じたのは、AI開発で重要なのは「AIにコードを書かせること」ではなく、

・最初の答えを疑う
・別のAIに独立レビューさせる
・同じAIにも自説を撤回できる条件で再検証させる
・大きな修正より、証明できる最小修正を選ぶ
・最後は人間がログ、ソース、実機で確認する

という使い方なのだと思います。

高性能AIは確かに高い。
超高エフォートは燃料も猛烈に食う。
しかも、ときどき離陸中止や生成中断まで起こす🤣😭

それでも、一見もっともらしい危険な修正を事前に排除し、638行の変更候補を5ハンクまで縮められたなら、再ビルド、再配布、テスター全員の再試験、そして新しい不具合を生むコストを考えれば、結果として安かった可能性はあります。

ただし、まだ「可能性」です。

本当に一発で核心へ到達したのか。
本当に副作用なく直るのか。

答えは、これから作る隔離テスト版と実運用ログが教えてくれます。🔧📡

AIは優秀。
でも燃料計と最終進入は、人間が最後まで監視しないといけませんね
🤣👍


WSJT-X Improved JP1LRT版のベースを260522 GAへ更新しました2026年08月10日 23時26分01秒

これまで開発を続けてきたWSJT-X Improved JP1LRT版は、WSJT-X Improved 3.1.0の260228版をベースとしていました。

そこへAutoSeq 2/3、Terminal Hold、RR73/73終了処理、地域指定CQ、Ave/Lag/Sync、デコード表示の拡張、10桁グリッドロケーター対応などを、実際のFT8運用で確認しながら少しずつ追加してきました。

機能そのものはかなり安定し、通常のQSOでも大きな問題は報告されていません。

一方、本家WSJT-X Improvedの開発も進み、2026年5月22日には260522 GA版が公開されました。

今回、JP1LRT版のベースを、この260522 GA版へ移行しました。

単純な差し替えではありません

今回行ったのは、古いソースを新しいソースへ単純に置き換える作業ではありません。

JP1LRT版では、QSOシーケンスの制御や画面表示を含め、すでに多数の変更を加えています。そのため、260522版をそのまま上書きすれば、これまで作ってきた機能の一部が失われたり、新旧の処理が衝突したりする可能性があります。

そこで、従来のJP1LRT版と公式260522版のソースを比較し、双方の変更内容を確認しながら統合しました。

特に注意したのは、次のようなJP1LRT独自機能をそのまま維持することです。

  • AutoSeq 2/3による候補局の自動選択
  • Terminal HoldとRR73/73終了処理
  • 保留候補局への直接ハンドオフ
  • QSO終了後のCQ自動復帰
  • 進行中QSOと手動操作の保護
  • CQ AF/AN/AS/EU/NA/OC/SAへの対応
  • 4/6/8/10桁グリッドロケーター対応
  • LoTW、B4、Worked、Wanted、国/DXCC、米国州などの拡張表示
  • Ave/Lag/Sync機能
  • Standard版とAL版、それぞれの画面構成
今回のリリースでは、これら既存のQSO動作を意図的には変更していません。

利用者から見れば、従来版と基本的に同じようにQSOできることが重要です。しかし内部では、プログラムの土台を新しい260522版へ入れ替えるという、比較的大きな作業を行っています。

Wide Graphにデコード済みコールサインを表示

260522版で追加された、目に見える大きな機能の一つが、Wide Graph上へのデコード済みコールサイン表示です。

Wide Graph右下の「Show Callsigns」を有効にすると、デコードした局のコールサインが、その局の信号周波数に対応する位置へ表示されます。

Even/Odd、CQ、RR73、現在のDX Callなども色分けされます。

VHF/UHF/SHFでは、どの信号がどの局なのかを視覚的に把握しやすくなります。HFの混雑したバンドでは表示がかなり賑やかになるので、好みに応じてON/OFFを切り替えるのが良いと思います。

260522版由来の改善

今回のベース更新では、Wide Graphのコールサイン表示以外にも、260522版で行われた改善を取り込んでいます。

  • callsign_states.tsvを利用した米国州情報処理の効率化
  • 米国州に関するアラート機能
  • 受信メッセージごとにTx5マクロが上書きされる問題の修正
  • その他の安定性改善

米国州アラートに必要な「USState.wav」と「USStateOnBand.wav」も、Standard版とAL版の両方へ追加しました。

10桁グリッドロケーター対応も維持

前バージョンで追加した、設定画面から4/6/8/10桁のグリッドロケーターを入力できる機能も、そのまま維持しています。

例えば、自局ロケーターとして「PM95TQ47GC」を設定した場合、その完全な10桁情報をPSK Reporterへ送信できます。

一方、通常のFT8/FT4でオンエア送信されるCQメッセージは、従来どおり「CQ JP1LRT PM95」のように4桁のままです。

設定画面で保持する詳細な位置情報と、オンエアで使うプロトコル上のロケーター長は、別々に管理されています。

10桁のグリッドロケーターは、次のサイトで確認できます。

https://www.k7fry.com/grid/

PSK Reporter上で10桁を使用すると、自局の表示位置がより細かくなり、近隣局のマーカーと重なりにくくなります。8桁でも十分な効果があります。

Standard版とAL版の両方で確認

今回もStandard版とAL版を同時に作成しました。

両方ともWindows MinGW環境で最後までビルドが完走し、実際に起動して動作を確認しています。

Standard版では、Wide Graphのコールサイン表示、10桁ロケーターの保存、通常FT8での4桁送信、AutoSeq 2、Terminal Hold、次候補局への直接ハンドオフ、CQ復帰を確認しました。

AL版でも、AL固有の画面構成、WSPRボタン、10桁ロケーター、通常FT8での4桁送信、AutoSeq 2、Terminal Hold、直接ハンドオフ、CQ復帰を確認しています。

ソース、実行ファイル、パッケージ構成についても、Standard版とAL版の両方で独立レビューを行い、最終的にPASS判定となりました。

今回はプレリリースです

QSOシーケンスそのものには意図的な変更を加えていませんが、今回はプログラムのベースを260228系から260522 GAへ移行する大きな更新です。

そのため、まずは限定テスター向けのプレリリースとしました。

以前の正常に動作しているバージョンは削除せず、新しいフォルダーへ展開して試していただくことを推奨しています。

ユーザーガイドについては、今回追加された見た目の機能が260522純正版由来であり、JP1LRT独自の操作仕様には変更がないため、v1.3のままとしました。

テスターの皆さんには、通常のFT8/FT4運用、AutoSeq 2/3、Terminal Hold、地域指定CQ、手動操作、Wide Graph表示などを確認していただきます。

以前のバージョンと異なる挙動が見つかった場合は、発生時刻と、その前後を含むALL.TXTを送っていただけると、原因を追いやすくなります。

新しい土台へ移行できたことで、これから追加する機能についても、より新しいWSJT-X Improvedを基準に開発を続けられるようになりました。

さて、次は何をしようかな。(笑)

WSJT-X Improved改造版、CQ DXと大陸指定CQに対応 ― さらにJTDXライクになりました2026年08月07日 07時51分40秒

WSJT-X Improved改造版にCQ DX・大陸指定CQ対応を実装しました

WSJT-X Improvedをベースに、自分のFT8/FT4運用に合うよう少しずつ改造を続けています。

今回、新たに実装したのは、CQ DXと大陸指定CQに対する自動取得制御です。

以前からJTDXには、CQ DXで運用している場合、同じ大陸の局を自動的には相手にしない仕組みがありました。

例えば日本からCQ DXを送信しているとき、中国や韓国など同じアジアの局から応答があっても自動的には応答せず、ヨーロッパや北米など別大陸の局からの応答を対象にします。

また、受信したCQ DXを自動的に呼びに行く場合も、そのCQ局と自局が別大陸であることを確認します。これはDX運用では非常に合理的な動作です。

そこで、JTDXの実際のソースを調べ、その考え方や判定方法を参考にしながら、WSJT-X Improved改造版にも同等の機能を取り入れました。

JTDXのソースをそのまま移植したわけではありません

今回、JTDXのソースは重要な参考資料になりました。ただし、JTDXのコードをそのままWSJT-X Improvedへ移植したわけではありません。

JTDXとWSJT-X Improvedでは、QSO候補の管理構造、CQメッセージの解析方法、自動取得へ進む経路などが異なります。

JTDX側では、候補局の情報を保持する構造体に大陸情報を持たせる設計があります。一方、WSJT-X Improved側の候補構造体には大陸情報がありません。

そのためJP1LRT版では、新たな大陸フィールドを追加せず、判定が必要になった時点で既存の国・エンティティデータベースを参照し、コールサインから大陸を都度算出する方式にしました。

また、CQ DXであるかどうかを単純な部分文字列検索で判断すると、誤判定の可能性があります。

  • CQ DX
  • CQ 074
  • CQ JA
  • CQ USA
  • CQ ASIA
  • CQ POTA
  • CQ TEST

これらは、それぞれ意味が異なります。

そこで、メッセージ中にCQDXという文字が含まれているかを見るのではなく、WSJT-X Improvedに既に存在するDecodedTextの構造的なメッセージ解析を利用しました。

自局が送信しているCQについても、過去に設定されたCQ種別を保持する変数には頼らず、実際の現在のTx6メッセージをその都度解析します。

これにより、以前のCQ DX設定が内部に残っていた場合や、CQ 074 JP1LRT PM95のような数値を伴うCQを使用した場合でも、誤ってCQ DXとして扱うことを防いでいます。

CQ DXの判定

CQ DXでは、自局と相手局の大陸を比較します。

自局がCQ DXを送信している場合は、応答してきた局が自局とは別大陸であると確認できた場合だけ、自動的にQSO相手として取得します。

受信したCQ DXを自動的に呼びに行く場合も、自局とCQ局が別大陸であることを確認します。

  • 自局と相手局の大陸が分かり、異なる大陸なら自動取得を許可
  • 両方の大陸が分かり、同じ大陸なら自動取得をブロック
  • 自局の大陸が不明なら、安全側にブロック
  • 相手局の大陸が不明でも、安全側にブロック

JP1LRT版では、分からない場合は自動取得しない、という安全側の設計にしています。

CQ NA、CQ EUなどにも対応

CQ DXへの対応が完成したあと、次に取り組んだのが大陸指定CQです。

今回対応したのは、次の7種類です。

CQ 対象地域
CQ AFAfrica
CQ ANAntarctica
CQ ASAsia
CQ EUEurope
CQ NANorth America
CQ OCOceania
CQ SASouth America

例えば、自局がCQ EUを送信している場合、ヨーロッパの局からの応答だけを自動取得します。アジアや北米など、指定した大陸以外から応答があっても自動的には応答しません。

反対に、受信したCQ EUを自動的に呼びに行く場合は、自局がヨーロッパに存在すると判定できる場合だけ自動取得を許可します。

ここで重要なのは、CQ DXと大陸指定CQでは判定の意味が異なることです。

CQ DXは、自局と相手局が異なる大陸であることを求めます。一方、CQ EUなどの大陸指定CQは、応答する側が指定された地域に該当するかを判断します。

自局がCQ EUを出している場合に必要なのは、応答局がヨーロッパかどうかです。自局自身がどの大陸にいるかは、その判定には関係ありません。

逆に、受信したCQ EUを呼ぶ場合に必要なのは、自局がヨーロッパかどうかです。CQを出している局自身がどの大陸にいるかは、その判定には使用しません。

この違いも、単純な共通判定ではなく、CQの意味に合わせて別々に設計しています。

CQ JAなどは対象外

今回、大陸指定として認識するのは、先ほど挙げた7種類だけです。したがって、次のようなCQは今回の地域判定対象にはなりません。

  • 通常のCQ
  • CQ 074などの数値を伴うCQ
  • CQ JA
  • CQ VK
  • CQ USA
  • CQ ASIA
  • CQ POTA
  • CQ SOTA
  • CQ IOTA
  • CQ TEST

これらは従来どおりの動作を維持します。特にCQ ASCQ ASIAは文字としては似ていますが、完全一致で判定しているため混同しません。

ブロックされるのは自動取得だけ

この機能で制限されるのは、自動的なQSO相手の取得だけです。

同じ大陸の局や、指定地域に該当しない局であっても、デコード画面から消えることはありません。ALL.TXTへの通常の記録や画面上の表示、色分けなども従来どおりです。

オペレーターが意図的にダブルクリックすれば、手動でその局とQSOできます。

実際、15mでCQ DXを出して試験運用していたところ、ヨーロッパ各局とは自動的にQSOが進みました。一方、カザフスタンはアジアと判定されるため、自動的には応答しませんでした。

しかし画面には普通に表示されているので、こちらの判断で手動選択し、UN7GBXと問題なくQSOしました。QSO完了後は再びCQ DXへ戻っています。

自動処理は運用目的に従って動き、それでも最後の判断はオペレーターができる。個人的には、このバランスが非常に気に入っています。

ローカルシミュレーションでも確認

今回も、JTDXを相手局として起動し、ステレオミキサー経由で実際のFT8信号を受信させるローカルシミュレーションを行いました。

通常版とAL版の両方で、代表的な動作を確認しています。

  • 日本から受信したCQ EUを自動的に呼ばない
  • 日本から受信したCQ ASは自動的に呼ぶ
  • 自局がCQ EUを送信中、アジア局からの応答を自動取得しない
  • ヨーロッパ局からの応答は自動取得する
  • CQ JAは大陸指定CQとして扱わない
  • CQ DXの同一大陸ブロックが引き続き機能する
  • 手動ダブルクリックは制限しない

ブロックした理由は、ALL.TXTへDCQ1_BLOCKまたはRCQ1_BLOCKとして記録します。

単に「呼びに行かなかった」「応答しなかった」という結果だけでなく、どの自動取得経路で、どの大陸判定によってブロックしたかをあとから確認できます。

これまで取り組んできた改造

最初は、自分のFT8運用で感じた小さな不満を解消するところから始まりました。

しかし実際の運用で発生した問題を一つずつ調べ、修正と試験を繰り返しているうちに、かなり大規模な改造になってきました。

現在までに、主に次のような機能を追加・改良しています。

自動運用とQSO制御

  • AutoSeq 2/AutoSeq 3
  • 複数候補局の待機と引き継ぎ
  • 応答がない場合の自動フォールバック
  • RR73/73の再送と取りこぼし対策
  • Terminal HoldによるQSO終端処理
  • 手動操作と自動処理の競合防止
  • 進行中QSOの相手を別局で上書きしない保護
  • CQ DXの異大陸判定
  • CQ AF / AN / AS / EU / NA / OC / SAの地域判定

タイミングと周波数制御

  • 受信したデコード局のDT分布の中心を示すAvg表示
  • デコード完了までのタイミングを示すLag表示
  • Avgを利用した内部タイミングのSync補正
  • ターゲット選択時のRx DF追従
  • CQ復帰時にRx DFをTx DFへ戻す同期処理

内部SyncはWindowsのシステム時計そのものを変更する機能ではありません。正しい外部時刻同期を基本としながら、受信局のDT傾向をWSJT-X Improved内部の論理タイミングへ反映します。

表示と局情報

国/DXCCエンティティ情報などを表示する機能自体は、元のWSJT-X Improvedにもあります。

一方、従来版では、その局がLoTWを利用しているかどうかをデコード画面上で確認することはできませんでした。

JP1LRT版では、JTDXと同様に、LoTW利用局を専用のマーカーで表示する機能を追加しました。デコードされたコールサインを一つずつ別の画面やWebサイトで調べなくても、LoTW利用局かどうかをデコード画面上でひと目で判別できます。

LoTWでのコンファームを重視する運用では、どの局を呼ぶか、あるいはどの局からの応答を優先するかを判断するうえで、非常に便利な表示です。

さらに、CQ行中心だった国/DXCC、LoTW利用者マーカー、B4、グリッド、Worked属性などの表示を、非CQのデコード行にも拡張しました。

これにより、CQを出している局だけでなく、通常のレポート交換やQSO進行中のデコード行でも、その局に関する情報を画面上で確認しやすくなっています。

このほか、

  • Wanted/ハイライト表示の改善
  • 現在のターゲットを分かりやすくする細い強調表示
  • 括弧表示などデコード画面の細部修正
  • Wide Graphの表示レイアウトや表現をJTDXに近づける改良
  • Wide Graphで時刻表示の一部が欠ける問題の修正
  • 大型ALLCALL7データへの対応
  • 各自動処理を追跡するALL.TXT診断ログ

なども加えています。

こうして並べてみると、ずいぶん色々なところをいじりました。

かなりJTDXライクになってきた

私はJTDXのベータテスターでもあり、日常的にJTDXを使ってきました。JTDXには、DX運用や多数局を相手にする運用で便利な機能が数多くあります。

一方、WSJT-X Improvedにも独自の良さがあります。

そこで、JTDXを単純にコピーするのではなく、JTDXで便利だと感じた運用思想や動作を参考にしながら、WSJT-X Improvedの構造と、自分の実際の運用に合わせて作り直してきました。

現在の改造版は、見た目だけでなく、候補局の扱い、QSO終端、CQ復帰、タイミング表示、局情報表示など、使い勝手の面でもかなりJTDXライクになっています。

ただし、中身はJTDXのクローンではありません。

実際の運用で発生した問題を基に、手動操作を最優先しながら、自動処理が勝手なことをしないよう保護を重ねた、独自のWSJT-X Improved派生版になっています。

多くの方に使っていただく段階になれば、WSJT-X Improved JP1LRT Editionと名乗ってもよいところまで来たように思います(笑)。

v20260806A-RCQ1

今回のCQ DX・大陸指定CQ対応版は、限定テスター向けの検証版として用意しました。

通常GUI版とAL GUI版を別パッケージとして用意し、限定テスターとともに動作検証を続けています。現時点では一般公開していません。

現時点での対象モードはFT8とFT4です。MSK144は今回の対象には含めていません。

しばらく日常運用と限定テスターによる検証を続け、動作を見ていく予定です。

さて、次は何をしよう(笑)

ここまで来ると、次は何をしようか……(笑)。

一段落したら、より新しいWSJT-X 3.1 Improvedを土台にして、現在の機能を順番に移植する作業もやってみたいと思っています。

しかし、その前に、せっかく完成した現在の版を実際のバンドで使って楽しむことにします。

次に何を追加するかは、また実運用中に何か思いつくでしょう(笑)。

「50.303MHzが選べない人へ ― 周波数登録、たった4ステップです2026年07月27日 17時39分44秒

以前このブログで周波数の使い分けについて書きました。

周波数の使い分けについて

でも実際、多くの人が標準周波数(50.313MHz)から動こうとしません。

これ、単に周波数を事前にソフトウェアへ登録していないだけなんじゃないでしょうか。

50.303MHz(国内通信用サブ周波数、標準が混雑した時用)の登録方法を、簡単に説明します。

① メニューから「周波数」タブを選択

(JTDXでは「使用周波数」という表記です)

② その枠内を右クリック

③ ポップアップの中から「挿入」をクリック

→「周波数を追加」のコラムが表示されます。

④ そこに 50.303 と入力してOK

→ 周波数リストに追加完了です。

以降はWSJT-XでもJTDXでも、メインUIの周波数横にある「バンドの選択肢」から選べるようになります。

実は登録しなくてもQSYできる

バンド表示(例:6m)を消去して、50.303 と直接入力しEnterを押すだけで、その周波数にQSYできます。

ぜひ一度試してみてください。