WSJT-X派生版の公開配布をいったん休止します ― 名前を変えて、開発はそのまま続けます ― 2026年09月18日 11時52分34秒
今回の理由は、ソフトの不具合や安全上の問題ではありません。
WSJT-X upstream側から、派生版については WSJT-Xとは独立したプロジェクト名を使ってほしい との要請を受けたためです。
その要請を尊重して、これまで使ってきた 「WSJT-X Improved JP1LRT Edition」 という名称は、今後の正式名称としては使わないことにしました。
🔹 開発：継続
🔹 新しい名称：検討中
🔹 最後の公開版：20260901A-REB522-P6 / P6-AL
🔹 GitHub：公開のまま
なので、「公開停止」と書くと少し大げさに見えるかもしれませんが、 実際には いったん看板を外して、作業場に戻った くらいの感覚です（笑）。
これまで実装してきた内容は、AutoSeq 2 / 3、Wanted / Hunting、Terminal Hold、 No-reply fallback、手動操作との競合防止、Best S&P、各種表示改善やdiagnostic機能など、 FT8 / FT4を実際に運用していて「ここをこうしたい」と思ったものが中心です。
✅ Wanted局を待つHunting動作
✅ RR73 / 73終端処理の保護
✅ QSO中の誤った切替や誤発火の抑制
✅ Terminal Hold
✅ Band Activity / Wide Graph表示改善
✅ ALL.TXT / diagnostic情報の強化
このあたりは、名称とはまったく別の話です。 名前が決まっていなくても、コードは書けます（笑）。
むしろ最近は、JTDX_contest 3.0を実際に動かしてみて、 デコーダーや処理構造の考え方そのものにかなり興味が戻ってきています。
「これは面白いな」と思う考え方があれば、 そのまま持ってくるのではなく、 自分の環境ではどういう形で実現できるのか を考えてみたいと思っています。
今回、名前を考えているうちに、少し根本的なことを考えました。
そもそも私は、このソフトを大規模に普及させたいのか？
……たぶん、そこが一番の目的ではありません。
商用ソフトではありませんし、 ユーザー数を競いたいわけでもありません。
もともとは、
それを実際に使って、動きを確認して、 面白ければさらに改良する。
それが出発点でした。
ところが一般公開を続けていくと、 名前、ロゴ、Release管理、User Guide、多言語化、配布ページ、サポートなど、 ソフト開発以外の作業もどんどん増えていきます。
それも必要な仕事ではあるのですが、 今の自分は、そこよりも 実際の動作やアルゴリズムをいじっている方が楽しい ということを改めて感じています。
将来、また普通に一般公開するかもしれません。
限定配布にするかもしれません。
自分と少数のテスター中心で続けるかもしれません。
今のところ、どれかに決めるつもりはありません。
需要が自然に増えたら、その時に考えればいいと思っています。
逆に、技術実験として続けるのが一番面白いなら、それでも十分です。
その方が自分には合っている気がしています。
「WSJT-X Improved JP1LRT Edition」 という名称は、 今後はhistorical nameとして扱います。
過去のRelease、source bundle、User Guide、screenshotなどには当然その名前が残っています。 それらまで無理に書き換えるつもりはありません。
GitHubのP6 / P6-AL Releaseページは現在、 Historical Release Record として残しています。 Win64の実行バイナリは削除し、 source bundle、checksum、documentationは技術記録として残しました。
また、このブログでこれまで掲載してきた 旧名称を前提とした配布案内やRelease紹介記事は、一旦非公開にします。
技術記事として今後も意味のあるものは、 必要に応じて内容を整理して再公開するつもりです。
https://github.com/jp1lrt/wsjtx-avelag
https://github.com/jp1lrt/wsjtx-avelag/releases/tag/20260901A-REB522-P6
そんなわけで、少し整理期間には入りますが、 開発そのものはむしろ今まで通り、いや、 余計なことを考えず技術に戻れる分、こちらの方が気楽かもしれません（笑）。
新しい名前と今後の公開方法が決まったら、また改めてお知らせします。
JTDX派生版「JTDX_contest 3.0.0-rc07」公開 ― FT2を新実装、デコーダー進化はさらに加速 ― 2026年09月17日 22時54分44秒
今回の目玉は、何と言っても FT2の正式実装 です。
しかも、単純に他の実装からFT2デコーダーを持ってきたものではありません。 JTDX_contestで大幅に改良されてきた 独自のFT4デコーダーチェーンをベースにFT2を実装 しており、 FT2にもJTDX_contest独自の仕組みが引き継がれています。
🔹 Ensemble decoding
🔹 TX background decoding
🔹 Decode budget
🔹 FT2専用の4段階プリセット
🔹 Expert menu / Preset lamp
FT2の送受信互換性についても、WSJT-X Improvedとの間で相互確認が行われ、 12種類のメッセージタイプで送受信をクロスチェック。 さらに20mでの実運用テストも行われたとのことです。
rc07はFT2追加だけではありません。GUIや操作性、従来から存在していた問題の修正まで、かなり広い範囲に手が入っています。
✅ 周波数表示上でマウスホイールを使い、100 / 10 / 1 kHz単位でQSY
✅ DX Callボタン／コールサイン欄のダブルクリックでQRZ.comを開く機能
✅ ウィンドウリサイズ時のsplitter比率保持
✅ Waterfallに以前から存在していたbuffer overrunの修正
✅ 新規インストール時の多数の初期設定値を実運用向けに見直し
このうち、ウィンドウを狭くした状態で終了すると、次回起動時にサイズが変わってしまう現象については、 私の環境で気づいてTihomirさんへ報告しました。 すぐに再現確認が行われ、その後すぐRepository側で修正されています。
本当に仕事が速いです（笑）。
rc06では、これまでJTDXの日本語ローカライズを担当してきた経験を活かして、 新しく追加されたUIやメッセージの日本語化について少しお手伝いをさせていただきました。
rc07ではFT2関連の新しい文字列が追加され、 FT8/FT4限定だった表記の一部も「FT*」へ一般化 されています。 現在、FT2関連の日本語訳についても、単に日本語として自然かどうかだけでなく、 decoder内部の意味や既存用語との整合を含めて確認しています。
JTDX_contestは、もはや単に「コンテスト向けに機能を足したJTDX」というだけではなく、 FT8 / FT4 / FT2のデコーダーそのものをかなり積極的に検証・改良するプロジェクト になってきています。
とくに、同じ受信音声を異なる条件で再評価するensemble decoding、 応答判断に必要な処理と、その後のTX background処理を分離する考え方、 hint memoryの拡張など、単なるGUI追加とはまったく違う方向の改良が進んでいます。
JTDXユーザーには、かなり面白い派生版だと思います。
https://ce3tsk.com/
https://github.com/ce3tsk/jtdx_contest
「JTDX_contest 3.0.0-rc06 公開 ― 日本語ローカライズと新機能を確認 ― 2026年09月15日 17時39分06秒
JTDX_contest 3.0.0-rc06 公開 ― 日本語ローカライズと新機能を確認
昨日から今日にかけて、日本語ローカライズの見直しを少しお手伝いした内容が、 早くもrc06へ反映されました。さらに、話題にしていたDXCC名の表示切替や、 cty.dat / LoTW user listのダウンロード機能まで実装されています。
CE3TSK Tihomirさんが開発を進めている JTDX_contest 3.0.0-rc06 が公開されました。
昨日から今日（9月14日～15日）にかけて、 これまでJTDXの日本語ローカライズを担当してきた経験を活かし、 JTDX_contest 3.0で新しく追加されたUIやメッセージの日本語化について、 少しお手伝いをさせていただきました。
日本語化は「単語を置き換えるだけ」ではない
今回の3.0では、新しいデコーダー設定をはじめ、多くの項目が追加されています。 こうした技術系ソフトウェアの翻訳は、単純に英単語を日本語へ置き換えればよいというものではありません。
たとえば budget や knee of the curve といった表現も、
機能や処理の意味を理解せずに直訳すると、日本語UIとしてかなり不自然になります。
「許容処理量」 / 「処理時間枠」 / 「性能向上の折れ点」 / 「ワイドグラフ幅」
実際の機能やソース上の意味を確認しながら、
日本語として自然であることと
技術的な意味を変えないことの両方を意識して整理しました。
今回提出した日本語 .ts ファイルは、早速 rc06 に反映されています。
DXCC名は「英語か日本語か」ではなく、選べる形に
今回、Tihomirさんと話をしていて興味深かったのが、 DXCC country/entity名の表示方法です。
JTDXではCountryDatに含まれるDXCC entity名も各言語へ翻訳できますが、 私はDXCC名については、LoTWやログソフト、CTYデータなどとの比較を考えると、 標準的な英語名称を基本にした方が扱いやすいと考えています。
「DXCC名は英語をデフォルトにして、必要な人だけ各言語表示を選択できる方式が良いのでは」 という考え方でした。
すると rc06 では早くも、 Translate DXCC names（DXCC名を日本語で表示） という設定が追加されました。
必要なら日本語表示を選ぶこともできる。
どちらか一方を強制するのではなく、ユーザーが選べる形です。
cty.dat と LoTW user list も設定画面から更新
さらに、データ更新について意見交換していた cty.dat の最新版ダウンロード と LoTW user list の最新版ダウンロード も、 Settings > General > Data files に実装されています。
このダウンロード機能自体はTihomirさんも以前から考えていたそうですが、 ちょうど話をしていた内容がすぐ rc06 に入ってきたので……
こちらのWindows環境でも、
日本語 .ts の反映、DXCC名の表示切替、cty.dat のダウンロード、
LoTW user list のダウンロード、ダウンロード済みデータの日付表示
まで実際に確認しました。
ダウンロードしたファイルを無条件に使うのではなく、 内蔵データとダウンロード済みデータを比較して、 新しい方を使用する仕組みになっています。
rc06 のそのほかの変更
- Band buttons の追加
- Dark style の改善
- QSO日付形式を
yyyy-MM-ddに統一 - Windows HTTPS download 関連の改善
- AppImage の DST 関連修正
まだ開発途中のJTDX_contest 3.0ですが、改良のスピードがかなり速く、 見ていて面白いです。
日本語についても、これまでのJTDXローカライズの経験を活かしながら、 できる範囲でお手伝いしていこうと思います。
73, Yoshi / JP1LRT
WSJT-X Improved 260908版が英語で起動する理由 ― 日本語で使用するには --language=ja を指定 ― 2026年09月11日 10時18分27秒
WSJT-X Improved 3.2 の 260908版を日本語Windows環境で起動すると、 これまでと違ってデフォルトでは英語GUIで起動することが分かりました。
最初は日本語translationの問題も疑いましたが、調査した結果、 これは翻訳ファイルの不具合ではなく、260908版で意図的に導入された 起動言語の仕様変更であることが分かりました。
DG2YCB Uweにも確認し、変更の経緯について回答をいただきましたので、 これから260908版を使用する日本のユーザー向けにまとめておきます。
■ 実際の動作
同じ日本語Windows PCで260818版と260908版を比較したところ、 次のようになりました。
| Version | 起動オプション | 起動言語 |
|---|---|---|
| 260818 | 指定なし | 日本語 |
| 260908 | 指定なし | 英語 |
| 260908 | --language=ja | 日本語 |
つまり、260818まではWindowsのシステムロケールに従って 日本語環境では自動的に日本語GUIが選択されていましたが、 260908では言語を明示しない場合に英語が選択されるようになっています。
■ ソースコードを比較すると原因は明確
260818と260908の完全なソースツリーを比較したところ、
原因は wsjtx/main.cpp の変更でした。
260818では次のようになっています。
L10nLoader l10n {&a, locale, parser.value (lang_option)};
この場合、--language が指定されていなければ、
通常のsystem localeを使った言語選択処理へ進みます。
そのため日本語Windowsでは日本語translationが自動的に読み込まれます。
一方、260908では次のコードに変更されています。
QString language_override = parser.value(lang_option);
// Default to English unless a language was explicitly requested.
if (language_override.isEmpty()) {
language_override = "en";
}
L10nLoader l10n {&a, locale, language_override};
コメントにも、
Default to English unless a language was explicitly requested.
と明記されています。
つまり260908では、言語オプションが空の場合、
system localeを参照する前に明示的に "en" が設定されます。
その結果、動作は次のようになります。
260818 言語指定なし ↓ system locale ↓ Japanese Windows ↓ Japanese GUI 260908 言語指定なし ↓ "en" を明示的に指定 ↓ English GUI 260908 --language=ja ↓ "ja" を明示的に指定 ↓ Japanese GUI
■ なぜこの変更が入ったのか
この点についてUweに問い合わせたところ、変更の経緯も分かりました。
Uweによると、複数の言語環境をインストールしたmacOSを使用している あるOMからの提案を受けて、
English should be the default everywhere.
という考え方に基づき、 言語を明示指定しなかった場合は英語をデフォルトにする 変更を行ったとのことです。
したがって260908版が日本語Windows上でも英語で起動するのは、 偶発的なregressionではなく、現在のWSJT-X Improvedで意図された動作です。
■ 日本語で使用するには
260908版を日本語GUIで使用したい場合は、起動時に
--language=ja
を指定してください。
Windowsのショートカットから起動している場合は、
ショートカットのプロパティを開き、
「リンク先」の wsjtx.exe の後ろに半角スペースを入れて、
次のようにします。
"C:\...\wsjtx.exe" --language=ja
実際のパスはインストール先によって異なりますので、 現在ショートカットに設定されているパスは変更せず、 その末尾に
--language=ja
を追加すればOKです。
例えば英語を明示的に使用する場合は、
--language=en
となります。
■ 日本語translationが削除されたわけではありません
ここは誤解しやすいところですが、 260908版から日本語translationが無くなったわけではありません。
実際に
--language=ja
を指定すれば、正常に日本語GUIで起動します。
つまり問題はtranslation resourceではなく、 起動時にどの言語を選択するかというselection logicです。
■ Best S&Pの言語依存問題修正とは別件
今回の件については、私が以前Uweへ送った Best S&Pのlanguage-dependent flaw修正との関係も念のため確認しました。
結論として、両者は無関係です。
Best S&Pの修正は、 翻訳された文字列そのものを比較してCQ priorityを判定していた部分を、 typed CQ priority valueによる比較へ変更したものです。
変更対象は主として
displaytext.cpp と mainwindow.cpp であり、
- QLocale
- QTranslator
- L10nLoader
- language command-line option
- translation loading
には触れていません。
Uweからも、
It was not due to your patch, Yoshi.
と明確に回答をいただいています。
■ 将来的にはGUIから言語切替も？
Uweはさらに、各言語のtranslation fileが継続的にきちんとメンテナンスされるのであれば、 将来的には「User Dark Style」のように、 メインプログラムのメニューから言語を切り替えられるようにしたい、 という考えも示しています。
これは実現すればかなり便利だと思います。
■ まとめ
WSJT-X Improved 260908版について、 日本語Windowsで英語GUIが表示されても異常ではありません。
260908版では仕様変更により、 起動時に言語を指定しなかった場合は英語がデフォルト になりました。
日本語で使用する場合は、
--language=ja
を起動オプションとして指定してください。
日本語translation自体は正常に収録されており、 このオプションを指定すれば従来通り日本語で使用できます。
WSJT-X Improved 3.2 / 260908で日本語メニューが英語で起動する場合の対処と原因 ― 2026年09月10日 07時48分31秒
WSJT-X Improved 3.2 / 260908で日本語メニューが英語で起動する場合の対処と原因
WSJT-X Improved 3.2.0 260908 AL PLUSを使用した日本人ユーザーから、 「これまで日本語だったメニューが英語表示になった」という問い合わせがありました。
同様の事象は別の日本人ユーザーでも確認されており、 日本語表示そのものが失われたわけではなく、起動時の言語選択の挙動が変わっていることが分かりました。
先に結論：日本語で起動する方法
260908で日本語GUIを使用したい場合は、起動時に次のオプションを付けます。
--language=ja
たとえばWindowsのショートカットを使用している場合は、「リンク先」の実行ファイル名の後ろに半角スペースを入れて、
"C:\WSJT\wsjtx\bin\wsjtx.exe" --language=ja
のようにします。 実際のインストール先は各自の環境に合わせてください。
この方法で260908でも正常に日本語表示になることを、複数の日本人ユーザーで確認しています。
260818と260908を同じPCで比較
原因を切り分けるため、私自身の日本語Windows環境で260818と260908を同じPC上でA/Bテストしました。
- 260818：言語オプションなし → 日本語で起動
- 260908：言語オプションなし → 英語で起動
- 260908：
--language=ja→ 日本語で起動
少なくとも私の環境では、260818と260908の間で、 「言語を明示指定しなかった場合のデフォルト動作」 が変わっていることが確認できました。
ソースを比較すると原因が見つかりました
そこで260818と260908の完全ソースを比較しました。
直接の違いは wsjtx/main.cpp にありました。
260818では次のようになっています。
L10nLoader l10n {&a, locale, parser.value (lang_option)};
この場合、--language が指定されていなければ空の値がそのまま L10nLoader に渡されます。
そのため通常のsystem localeによる言語選択が働き、日本語Windowsでは日本語GUIが自動的に読み込まれます。
一方、260908では次の処理が追加されています。
QString language_override = parser.value(lang_option);
// Default to English unless a language was explicitly requested.
if (language_override.isEmpty()) {
language_override = "en";
}
L10nLoader l10n {&a, locale, language_override};
つまり260908では、言語指定がない場合に "en" を明示的に設定するよう変更されています。
L10nLoader 側では "en" を明示的な英語指定として扱い、
system localeに基づくtranslationの読み込みをスキップします。
その結果、オプションなしでは英語GUIになります。
逆に --language=ja を付ければ "ja" が明示指定されるため、
日本語translationが正常に読み込まれます。
実際の挙動とソースの処理が一致
整理すると次の通りです。
- 260818：言語指定なし → system localeを使用 → 日本語Windowsでは日本語
- 260908：言語指定なし →
"en"を設定 → 英語 - 260908：
--language=ja→ 日本語
実機で確認した挙動と、ソース上の処理が完全に一致しました。
また、L10nLoader.cpp と L10nLoader.hpp 自体は260818と260908で変更されておらず、
言語・locale・translation周辺を確認した範囲では、今回のデフォルト動作を変える直接の差分はこの main.cpp の変更でした。
Best S&Pの日本語対応patchとは無関係です
260908には、私（JP1LRT）が提供したBest S&Pの言語依存修正patchも取り込まれています。 そのため当初、この変更との関係も念のため確認しました。
しかしこのpatchは、Best S&P内部で翻訳済み文字列を比較していた処理を、 言語に依存しない内部のtyped valueによる比較へ変更したものです。
QLocale、QTranslator、L10nLoader、
translation loading、--language の処理には触れていません。
ソースdiffでも今回の日本語GUI起動問題との直接的な関係がないことを確認しました。
これは「バグ」なのか？
260908のコードには、
// Default to English unless a language was explicitly requested.
というコメントがあるため、コード変更そのものは意図的に書かれたものと考えられます。
ただし、 「すべての非英語環境で、言語指定がなければ英語をデフォルトにする」 ことまで意図したユーザー向け仕様変更だったのか、 またその理由が何だったのかまでは、今回比較したソースだけからは判断できません。
したがって現時点では、これを「バグ」や「regression」と断定するのではなく、 260818と260908の間でデフォルトの言語選択処理が変更された という事実として整理しておくのが適切だと思います。
従来の自動言語選択へ戻す場合
もし260818までのように、言語指定がない場合はsystem localeに従う動作へ戻すのであれば、
main.cpp の処理を260818の形に戻すのが最小の修正です。
L10nLoader l10n {&a, locale, parser.value (lang_option)};
この形に戻しても、英語を明示したい場合の
--language=en
は従来通り機能します。
今回の解析結果についてはDG2YCB / Uweにも共有しています。
とりあえず困っている方へ
260908をインストールして「メニューが英語になってしまった」と困っている方は、 まずはショートカット等に
--language=ja
を追加して起動してみてください。 日本語translationそのものは正常に利用できます。
最初は単純な「日本語メニューが出ない」という問い合わせでしたが、 同一PCでのA/Bテスト、260818と260908のソース比較、 そしてtranslation loaderの処理を追うことで、今回の挙動の直接原因まで確認することができました。
73,
Yoshi / JP1LRT
FT8の「最後の1 decode」を拾うために――Wide GraphとJTDX Filterを理解して使う ― 2026年08月30日 10時09分56秒
FT8の「最後の1 decode」を拾うために――Wide GraphとJTDX Filterを理解して使う
極弱DXで「見えているのにデコードしない」ときに試したい、受信帯域とデコーダ探索範囲の考え方
ハムフェア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の上限周波数が設定され、デコーダ側へ渡されています。
「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して残った信号を再探索する処理など、いくつもの段階があります。
したがって、「探索範囲を狭めれば必ず感度が上がる」とは言えません。 一方で、限界付近の信号に対して不要な範囲を探索対象から外した結果、 広い範囲ではデコードしなかった信号が、狭めた時にはデコードするということは実戦上あり得ます。
リグのフィルターを狭めることとは、作用点が違う
「弱い信号ならリグのフィルターを狭める」という方法は、多くの方が使っていると思います。 しかし、リグのフィルターとWide Graphは同じ「帯域を狭める」操作でも、働く場所が違います。
不要な信号を前段で抑える
ソフトへの入力
探索する周波数範囲を限定
リグ側の帯域を狭めることで、強い近接信号によるAGC動作や受信系への影響を抑えられる場合があります。 一方、Wide Graphを狭めるのは、ソフトウェア側で「どこを探すか」を限定する操作です。
つまり、極弱局に集中したい時は、次の二段構えになります。
- リグ側で不要な受信帯域をできるだけ減らす。
- ソフト側でもWide Graphを目的局周辺へ絞り、デコーダの探索範囲を限定する。
実際には、Wide Graphをどこまで狭められるのか
ここで、実際の画面上ではどこまでWide Graphを狭められるのかも確認してみました。 Bins/Pixelを1にした状態で、私が現在使用しているWindows環境では、 WSJT-Xは約682Hz、JTDXは約572Hzまで狭めることができました。
つまり、「目的局の50Hzだけを残す」といった極端な狭帯域化は、 少なくとも通常のWide GraphのUI操作ではできません。 一方で、通常の数kHz幅から700～1000Hz前後へ狭めるだけでも、 探索対象をかなり限定することはできます。
狭ければ狭いほど良い、ではない
では、目的局が1500Hzにいるなら、可能な限りギリギリまでWide Graphを狭めれば最高なのか。 僕はそうは考えません。
FT8デコーダは、強い信号を先にデコードしてSubtractし、その後に近接した弱い信号を拾えることがあります。 目的局のすぐ近くに強い信号があるのに、それを探索範囲外へ追い出してしまうと、 状況によってはその恩恵を失う可能性があります。
そのため僕なら、目的局だけを極端に囲うのではなく、 まずは目的局を中心に±500Hz程度、つまり合計1000Hzくらいを目安に残して試します。
※ ±500Hz（合計約1000Hz）はWSJT-X/JTDX公式の推奨値ではなく、 極弱局へ集中する際の実戦上の目安として僕が考えている値です。 上記の最小幅まで最初から絞り切るのではなく、まずは1000Hz程度を残し、状況を見ながら調整します。
僕ならこう試す
- 通常運用では、例えば100～3300Hz程度を表示。
- どうしてもデコードしたい極弱DXが現れたら、まずリグの受信フィルターを狭める。
- Wide Graphも目的局周辺1000Hz程度へ縮める。
- 状況を見ながら、必要ならもう少し狭める。
- 近接強信号や呼んでくる他局も考慮し、「狭めすぎ」になっていないか確認する。
では、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の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の世界では、もしかすると「そんなことを皆に教えなくてもいいのに」と思う方もいるかもしれません。 でも僕は逆です。
アマチュア無線は、誰かが見つけた知識や工夫を共有し、他の人が試し、 そこからまた新しい発見へつながっていく趣味だと思っています。
アンテナも、伝搬も、受信技術も、ソフトウェアも同じです。 自分だけの「秘密の技」にするより、 「こうすると少し良くなるかもしれない。みんなも試してみて」と共有する。
そして誰かが実験して、「こういう条件では効いた」「ここでは逆効果だった」とさらに情報を積み重ねる。 そうやって知識が育っていくことこそ、アマチュア無線らしさの一つではないでしょうか。
参考資料
-
WSJT-X User Guide, “Wide Graph” — “Decoding occurs only in the displayed frequency range.”
https://wsjt.sourceforge.io/wsjtx-main_en.html -
JTDX 2.2.159 source,
mainwindow.cpp— Wide Graphの開始周波数・上限周波数を decoder parametersnfa/nfbへ設定。
Debian Sources: JTDX mainwindow.cpp -
JTDX 2.2.159 source,
mainwindow.ui— Filter帯域幅および現在のFilter機能説明。
Debian Sources: JTDX mainwindow.ui -
JTDX 2.2.159 source,
Configuration.ui— decoding passes / attemptsとlow-SNR decoding efficiencyの説明。
Debian Sources: JTDX Configuration.ui -
JTDX User Guide, Version 2018-01-08 — 旧Filter説明。
JTDX User Manual 2018 PDF
※ 本文中の実戦的な運用目安は筆者の考えを含みます。ソフトウェアの動作・仕様については、 上記公式文書またはソースコードの記述と区別して記載しています。
「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できます。
ぜひ一度試してみてください。
杉並から18,669km ― PY5CC受信で実感したPSKRの価値 ― 2026年07月27日 14時00分13秒
昨日、仕事から帰ってきてPSKRを何気なく確認したら、驚くべき記録が残っていました。
ブラジルのPY5CC（GG54RE）を受信していたのです。
260726_224730 50.313 Rx FT8 -18 -0.1 2039 K8SIX PY5CC GG54
PY5CCとは過去にF2伝搬でQSOしたことがあります。ALL.TXTには、彼が北米局を呼んでいた電波が日本まで届いていた記録として残っていました。
自分のグリッド（PM95TQ）とPY5CCのグリッド（GG54RE）の位置関係を計算してみると、方位角37.6度・距離18,669km。当日のアンテナ固定方向は35度――ほぼ正面から入ってきていたことになります。単なるバックローブでの拾いものではなく、ダイレクトパスでした。伝搬がEsとF2の複合だったのか、TEPが絡んだのか、あるいはEsのコーダルホップ連鎖だけだったのかは分かりませんが、地球一周の半分近い距離を受信できたというだけでもワクワクします。
なぜこの受信に気づけたのか
答えはシンプルです。PSKRに情報を送信していたからです。
PSKRによれば、この瞬間PY5CCの信号を受信報告していたのは、僕を含めて3局。青葉区の局（PM95SO）と、白子町の局（QM05EK）でした。もちろんPSKRへの送信をオフにしている局もいるはずなので、実際にはもっと多くの局が受信していた可能性があります。
もし僕がPSKRへの送信をオフにしていたら、この受信記録は自分のALL.TXTの中に埋もれたまま、誰の目にも触れることなく終わっていたでしょう。逆に言えば、送信をオンにしている局が3局いたからこそ、この奇跡的な瞬間がお互いに可視化されました。
Give and Takeの精神
PSKRの設定方法については、以前この記事で詳しく書きました。今回改めて、設定画面を最新のものに差し替えて掲載します。
JTDXの設定画像
WSJT-X
MSHV
JTAlert
JTAlertについては、PSKRとは直接の関係はありませんが、HamSpots（https://hamspots.net/）で情報共有ができます。
設定はどれも数クリックで完了します。それでもなお、自局の情報を一切出さずに、他局が受信報告してくれた「旗が立った」という結果だけを享受している局を見かけることがあります。ネット接続が従量制、あるいはPCがオフライン運用という事情であれば仕方ありませんが、そうでないなら、ぜひオンにしていただきたいと思います。
情報の共有はとても大切なことです。しかしリグがCAT非対応であれば仕方ないですね。CAT非対応だと違うbandの情報を上げてしまうことがあり注意が必要です。
さらにその情報に正確性を出すため、ご自身のGrid Locatorは正確に入れましょう。各ソフトウェアには自局のGrid Locatorを入力する場所があります。少なくとも6桁のデータを入れましょう。4桁だと大雑把な位置表示になり、PSKR地図上で海上になってしまったりします。
JTDXはデフォルトで10桁まで対応しています。一方でWSJT-Xは6桁までですが、iniファイルをいじって10桁まで表示させることも可能となり、多くの方が8桁ないしは10桁のGrid Locatorを表示させています。
10桁のGrid Locatorを調べるには
このサイトでご自身のご自宅を見つけてください。10桁まで入れるのに抵抗のある方は8桁で十分です。
iniファイルの編集は、WSJT-X／JTDXを閉じた状態で行ってください。
"C:\Users\各人の設定\AppData\Local\WSJT-X\WSJT-X.ini"
"C:\Users\各人の設定\AppData\Local\JTDX\JTDX.ini"
をテキストエディタで開き、いずれのiniファイルも
[Configuration]
MyCall=JP1LRT
MyGrid=PM95tq47gc
（私の場合はこのようになっています）
MyGrid= を編集して保存した後に各ソフトウェアを立ち上げれば反映されます。結果はPSKRでも確認できます。
情報はGive and Takeが基本です。今回のPY5CC受信も、複数局が情報を出し合っていたからこそ、お互いに「あの瞬間、あの局も同じ信号を捉えていた」と分かる形になりました。
目覚ましで起きたら、50MHzは北米大オープンだった――杉並区で観測した今季最大の6m Es ― 2026年07月21日 13時46分53秒
2026年7月21日の朝、目覚ましをセットしていた06:30に起きて無線機を見たら、50MHzはすでに北米の大オープン状態だった。
後から聞いたところでは、05:30頃にはもう開いていたらしい。
実は朝5時半にトイレへ行った時、一度起きていた。 あの時スマートフォンを見ておけばよかった……と少し後悔している（笑）
「自分が不在の時に限って6mが開く」というのは、もはや6mあるあるだと思う。
だからこそ、昨日のヨーロッパに続いて、今朝は自宅にいる時にこれほどの北米オープンに巡り会えたことが、素直に嬉しかった。
上の画像はピーク時そのものではないが、北米局が画面を埋めていた当時の雰囲気は伝わると思う。
WSJT-Xの受信ログを解析してみた
今回、僕のWSJT-XのALL.TXTから、06:33～11:53 JSTの北米局を抽出して解析した。
画面には米国、カナダ、メキシコの局が次々と現れていた。集計条件を米国・カナダ・メキシコに絞った結果は次の通りだった。
- ユニークでデコードした米国・カナダ・メキシコ局：430局
- 延べデコード数：8,817回
- 1分間のピーク時刻：06:35 JST
- 1ピリオド、15秒間の最大ユニーク局数：38局
- 1ピリオドのピーク時刻：06:35:45 JST
06:35～06:41頃には、1ピリオド30局を超える状態が何度も続いていた。
僕が起きて無線機の前に座った時には、すでに今シーズンで最も濃い数分間に突入していたことになる。
グラフを見ると、起床直後の06:35頃に最大の山があり、その後いったん落ち込みながらも、08:40頃から10時前後にかけて再び厚い入感が続いていたことが分かる。
一瞬だけのオープンではなく、濃淡を繰り返しながら午前中いっぱい続いた、規模の大きなオープンだった。
西海岸だけではなかった
コールサインとグリッドロケーターのデータベースを照合したところ、430局中380局のグリッドを確認できた。
延べデコード数が多かったグリッドフィールドは、次の通りだった。
- EM：2,527回
- DM：2,365回
- EN：1,835回
- DN：571回
- FN：453回
- FM：352回
DMの米国南西部、EMの中南部、ENの中西部北部が特に強かったが、DNのロッキー山脈北部、FMの南東部、そしてFNの米国北東部・ニューイングランド方面まで届いていた。メキシコからはXE2JS、XE2CQ、XE2Xの3局を確認しており、メキシコ中部・北東部方面までパスが伸びていたことになる。
西海岸や南西部だけが開いていたのではない。
太平洋岸から中部、東海岸方面、そしてメキシコ方面まで、北米大陸の非常に広い範囲が同時に日本へ入感していた。
PSK Reporterの画面を見ても、北米大陸の西側だけではなく、中部から東海岸に至る広い範囲へ伝搬していた様子が分かる。
なお、コールサイン・データベースのグリッド情報は、移動運用や引っ越しなどにより、当日の実際の送信地点と異なる場合がある。
また、PSK Reporterの表示は、受信ログそのものとは性質が異なる。
それでも、今回の伝搬が北米大陸の非常に広い範囲に及んでいたことを示す資料としては、十分に印象的だと思う。
同じ関東でも、見えている北米がまったく違う
今回、特に面白かったのがJR1LZK局との比較だった。
JR1LZK局は水戸市、QM06FI。
僕は東京都杉並区、PM95TQ。
同じ06:48:45 JSTのピリオドを比較しても、画面に現れている局数も、見えている局の顔ぶれも大きく異なっていた。
JR1LZK局の設備は、9.1mブームの7エレ八木を3枚使用した三角形スタック。
水平間隔7.5m、垂直間隔7.0m、最上段は32mという本格的な6m設備で、1ピリオドに北米局を60局以上デコードした場面もあったという。
一方、僕の設備は杉並区の住宅地に設置した、9.8mブームの7エレ一枚。
設備差は当然大きい。
しかし、それだけではない。
50MHzのマルチホップEsでは、最終ホップの着地点や散乱域の位置によって、同じ関東地方でも受信状況が大きく変わる。
さらに、次のような要素がすべて重なる。
- アンテナの利得と高さ
- アンテナのビームパターン
- 周辺のノイズフロア
- 強力なJA局によるマスク
- 受信機やAGCの状態
- WSJT-XとJTDXのデコード特性
したがって、当然ですが今回の430局という数字は全国共通の値ではなく、
「2026年7月21日、東京都杉並区PM95TQのJP1LRT局で観測した北米オープン」
という、一地点での観測記録として見るべきです。
逆に言えば、杉並区の7エレ一枚でも1ピリオド38局、WSJT-X単独のログで430局が確認できたのだから、この日のオープンがどれほど大きかったかが分かる。
WSJT-XとJTDXの二面起動が実戦で役に立った
僕はWSJT-XとJTDXを同時に起動して運用している。
同じ受信音を入力していても、両者のデコード結果は完全には一致しない。
WSJT-Xではデコードできなかった局をJTDXだけが拾うこともあれば、その逆もある。
今回の実際のQSOログにも、WSJT-XのALL.TXTには記録されていない局が含まれている。
それらはJTDX側だけでデコードできた局を見つけ、周波数やメッセージを確認した上で、WSJT-X側から手動で対応してQSOしたものだ。
だから、
「WSJT-Xでデコードした430局の中から交信した」
という単純な包含関係にはならない。
実際の運用では、二つのデコーダーがそれぞれ拾った情報を、人間がリアルタイムで統合している。
こうした運用をしているDXerは少なからずいる。
彼らもやり手だと思う。
二面起動は単に画面を二つ並べているのではない。
片方で取りこぼした弱い局をもう片方で救い、それを実際のQSOへつなげる、実戦的なデコード・ダイバーシティとして機能している。
今回は送信タイミングも特殊だった
50MHz FT8では、通常はJA局が奇数側、
2nd / ODD
15秒・45秒
で送信し、DX局が偶数側、
1st / EVEN
00秒・30秒
を使うという慣習がある。
JAの強力なローカル信号が、JA局が受信したい弱いDX信号を覆い隠さないための考え方だ。
しかし今回は、北米局の多くが奇数側で送信していた。
米国内では東海岸と西海岸の間でも送信タイミングが分かれることがあり、すでに成立していた米国内や他地域との運用の流れを維持したまま、突然JAとのパスが開くことがある。
また、米国とヨーロッパが同時に開いている場合、ヨーロッパ局は通常偶数側で送信するため、米国局は奇数側を使う。
その状態で米国からアジアへのパスまで開けば、アジア側が偶数を使わざるを得ない状況も生じる。
だから重要なのは、
「原則を知った上で、その時の状況を読むこと」
だと思う。
原則を知らずに偶数側でCQを出し続けることと、実際に入感しているDX局のタイミングを確認し、状況判断の結果として偶数を選ぶことは、同じではない。
原則を守ることと、状況を読まないことは違う
今回、北米局の多くが奇数側に並んでいる中で、奇数側からCQを出し続けるJA8エリアの局がいた。
Esに乗った強力なJA信号が、同じタイミングで届いている複数の弱い北米局をマスクしていた。
さらに、偶数側でCQを出していたJA局を、別のJA局が呼ぶ場面も見られた。
北米がこれほど大きく開いている時の50.313MHzでのCQは、実質的には「CQ DX」と同じ意味を持つ。
国内同士でQSOしたいのであれば、50.303MHzのFT8を試すか、FT4へ移るという選択肢がある。
少なくとも、周囲に何が入感しているかを見ずにCQを出すべきではないと思う。
50MHz FT8の基本的な運用目安としては、次のようになる。
- CQは原則として2nd / ODD、15秒・45秒
- ただしDX局が実際にどちら側で送信しているかを必ず確認する
- 50.323MHzは大陸間DX用として扱い、国内QSOには使用しない
- 50.313MHzが混雑している時の国内QSOは50.303MHzを検討する
- 国内QSOではFT4も活用する
このあたりを共有しておくことが、DX局を守り、同時にJA全体の受信機会を守ることにつながると思う。
詳しい考え方は、以前こちらの記事にまとめている。
だから6mは面白い
今回は新しいグリッドロケーターとも数多くQSOできた。
05:30頃から開いていたと聞くと、朝5時半にトイレへ行った時にスマートフォンを確認していれば……とは思う。
しかし、目覚ましで起きた時にはすでに大オープンしていて、そのピーク付近を自分の設備で実際に体験できた。
設備が違えば見える局数が違う。
地域が違えば、同じピリオドでも見えている局そのものが違う。
ソフトが違えば、拾える弱い局も違う。
そして最後は、その情報を見たオペレーターがどう判断し、どう動くかで結果が変わる。
だから6mは面白い。
2026年夏の、忘れられないオープンの一つになった。
最近のコメント