2026年 第56回 6m AND DOWN コンテストの結果が発表されました ― 2026年10月06日 19時53分18秒
そして「意見・感想」欄について思うこと
スコアを見るのはもちろん楽しいのですが、個人的にはもうひとつ、 ぜひ多くの参加局に意識してほしい欄があります。
それが、サマリーシートの「意見・感想」欄です。
2026年 第56回 6m AND DOWN コンテストの結果が発表されました。
参加された各局、お疲れさまでした。
今年も、50MHzを中心に各部門で熱い戦いがありました。
50MHzは、やはり「場所」と「腕」と「執念」の勝負
50MHz関係で見ると、 X50、つまり電信電話部門シングルオペ50MHzバンド は JM1TDG/6 が全国1位。
宮古島からの参加で、見事に2連覇とのことです。
もちろん、場所が良いだけで勝てるわけではありません。
その場所を生かし切る運用力があってこそ、全国1位になるわけです。
一方、 C50、つまり電信部門シングルオペ50MHzバンド は JI1ACI が全国1位。
こちらはもう、 「不動の位置」 という感じです。
毎年のように安定して強い局というのは、本当にすごいと思います。
結果ページを見ていて、少し気になったこと
さて、今回の結果ページを見ていて、ひとつ気になったことがあります。
それは、 「意見・感想」の提出が、書類提出局数に比べてかなり少ない ということです。
もちろん、ログを提出するだけでも十分です。
コンテストに参加して、ログを整理して、期限内に提出する。
これだけでも、立派な参加記録です。
でも、せっかく参加したなら、サマリーシートの 「意見・感想」欄 にも、ぜひ何か一言残してほしいなと思います。
・今年はコンディションが良かったです。
・短時間でしたが参加できました。
・移動運用で参加しました。
・交信いただいた各局ありがとうございました。
・次回も参加したいと思います。
・集計ありがとうございます。
本当に、この程度で良いと思います。
長文である必要はありません。
名文である必要もありません。
技術的考察である必要もありません。
その年、その時、そのコンテストに参加した人の一言が残るだけで、 あとから見返した時の面白さがかなり変わります。
ただし、ログソフトの表示が少し分かりにくい
ここで少しややこしいのが、ログソフト側の表示です。
たとえば、zLogではこの欄が 「意見」 と表示されています。
CTESTWINでも、やはり 「意見」 と表示されています。
この「意見」という表記、少し構えてしまう人もいるかもしれません。
「何か要望を書かなければいけないのかな？」
「規約への意見を書かないといけないのかな？」
「苦情や改善提案を書く欄なのかな？」
そう思って、空欄のまま提出している人もいるのではないでしょうか。
つまり、ここには 「意見」ではなく「感想」を書いて良い のです。
「感想」で良い。むしろ感想が読みたい。
たとえば、
- 今年はEスポに助けられました。
- 移動地は雨でした。
- 暑くて大変でした。
- 短時間参加でしたが楽しめました。
- 初めて6Dに参加しました。
- 久しぶりに50MHzで楽しめました。
- アンテナの調子が悪くて伸びませんでした。
- 来年はもう少し準備して参加したいです。
こういう一言で良いのです。
結果表には、QSO数、マルチ、得点、順位が残ります。
でも、それだけでは分からないことがあります。
その年の空気。
コンディションの印象。
移動運用地の様子。
参加者の疲労感。
初参加のうれしさ。
伸びなかった悔しさ。
それでも参加した楽しさ。
そういうものは、各局の「感想」によって残ります。
数年後に結果ページを見返した時、 「ああ、この年は50MHzが長時間開けたのか」 とか、 「この年は移動運用が雨で大変だったのか」 とか、 「この頃はこういう局が頑張っていたのか」 ということが分かる。
これは、単なるスコア表とは別の価値だと思います。
ログ提出時に、ぜひ一言
というわけで、次回以降コンテストログを提出する時は、 ぜひ「意見・感想」欄にも一言書いてみてはいかがでしょうか。
交信いただいた各局ありがとうございました。
次回も参加したいと思います。
これだけで良いと思います。
コメント欄が増えれば、結果ページはもっと面白くなります。
コンテストの記録は、スコアだけでなく、参加者の声も含めて残っていくものだと思います。
参加した記録を、数字だけでなく、言葉でも少し残していきましょう。
X50は JM1TDG/6 が宮古島からの参加で2連覇。
C50は JI1ACI が不動の強さ。
そして、ログ提出時の「意見」欄には、 意見だけでなく感想を書いて良いのです。
ぜひ、次回は一言。
スコアと一緒に、その年の思い出も残しましょう。
73
WSJT-X FreqCalの較正点を検証する ― 594 / 1422 kHzを除外するとStdDev 0.08 Hz ― 2026年09月29日 14時53分24秒
StdDev 0.08 Hzになった
そこで594 kHzと1422 kHzを 「残す／除外する」の4条件で実際に較正パラメータを比較してみました。
昨日から、 WSJT-XのFreqCalを使って、 IC-7300の基準周波数を改めて調整しています。
リグ本体のREF Adjust調整から、 FreqCalを使った最終的なSlope / Interceptの算出までの手順は、 こちらの記事にまとめました。
今回の測定では、
リグ本体のREF Adjustを確定した後、
それ以前に取得したfmt.allを一度削除。
その後はREF Adjustを固定したまま、 FreqCalを数巡させて測定データを蓄積しました。
また、
低S/Nのため行末に*が付いた測定値は除外しています。
そこで、 この2局を較正データに含めるかどうかで 結果がどの程度変化するのか、 4条件で比較してみることにしました。
その前に ― Slope / Intercept / StdDevとは？
WSJT-Xで 「ツール」→「較正パラメータ計算」 を実行すると、 次のような値が表示されます。
- Slope
- Intercept
- N
- StdDev
何を意味しているのかを簡単に整理します。
f = 周波数 [MHz]
Slope（スロープ）
周波数が高くなるにつれて増減する誤差成分を表します。 単位はppmです。
例えば、
Slopeが
+0.004 ppm
なら、
周波数依存成分だけを見ると、
50 MHzでは、
となります。
Slopeが0に近いほど、 受信周波数が高くなるにつれて誤差が増えていく傾向が小さい ことを意味します。
今回のように、 まずリグ本体のREF Adjustを調整する場合は、 このSlopeに相当する周波数依存の誤差を リグ側でできるだけ小さくしてから、 残差をWSJT-Xで補正することになります。
Intercept（インターセプト）
Interceptは、 直線近似した時の 0 MHzでの切片で、 単位はHzです。
分かりやすく言えば、 Slopeだけでは説明できない 固定的なオフセット成分です。
ただし、 実際に0 MHzを受信して測定しているわけではありません。
複数の周波数で得られた測定値から求めた直線を 0 MHzまで延長した時の値です。
N
Nは、 直線近似に使用された平均化済みの周波数測定値の数 です。
単純なfmt.allの行数ではありません。
同じ周波数で連続して得られた測定値はまとめて平均され、 その平均値が直線近似に使われます。
StdDev
今回、 比較のために特に注目したのが StdDevです。
名前だけを見ると、 一般的な意味での「標準偏差」と思ってしまいますが、 FreqCalで表示されるStdDevは、 もう少し具体的な意味を持っています。
“the root mean square deviation of averaged measurements from the fitted straight line”
と説明しています。
つまり、 平均化された各測定点が、 SlopeとInterceptから求められた近似直線から どの程度外れているかを示すRMS値です。
簡単に言えば、
| StdDev | 意味 |
|---|---|
| 大きい | 測定点が近似直線から大きく散らばっている |
| 小さい | 測定点が近似直線によく揃っている |
StdDevが小さいからといって、 それだけで 「絶対周波数が正しい」 ことを保証するわけではありません。
誤った基準信号だけがきれいに一直線に並んでいても、 数学的には小さなStdDevが出る可能性があります。
したがって、 基準信号そのものが信頼できるかという確認も重要です。
「±」の数字
SlopeとInterceptの後ろに表示される
±の値は、
それぞれの推定不確かさです。
例えば、
なら、 今回の直線近似から求められたSlopeが +0.004 ppmで、 その推定不確かさが0.001 ppmという意味です。
① 全周波数を使用
Intercept: -0.33 ±0.03 Hz
N: 170
StdDev: 0.32 Hz
まず、 594 kHzと1422 kHzを含めた、 すべての有効測定点を使用しました。
WSJT-Xの判定そのものは 「較正良好」です。
しかし、 StdDevは 0.32 Hz となりました。
② 1422 kHzだけを除外
Intercept: -0.18 ±0.03 Hz
N: 146
StdDev: 0.25 Hz
1422 kHzだけを除外すると、 StdDevは、
へ改善しました。
1422 kHzの測定点が 今回の近似直線との整合性をかなり悪化させていることが分かります。
③ 594 kHzだけを除外
Intercept: -0.22 ±0.04 Hz
N: 147
StdDev: 0.30 Hz
今度は逆に、 594 kHzだけを除外しました。
StdDevは、
です。
594 kHzも影響していますが、 今回のデータでは 1422 kHzの方がより強く近似結果を崩しているようです。
④ 594 / 1422 kHzを両方除外
Intercept: +0.05 ±0.01 Hz
N: 123
StdDev: 0.08 Hz
最後に、 594 kHzと1422 kHzを 両方とも除外しました。
すると、 StdDevが一気に、
まで低下しました。
さらにSlopeも、
となり、 ほぼゼロに近づきました。
4条件を比較
| 条件 | Slope | Intercept | StdDev |
|---|---|---|---|
| 全周波数 | +0.029 | -0.33 | 0.32 Hz |
| 1422除外 | +0.019 | -0.18 | 0.25 Hz |
| 594除外 | +0.021 | -0.22 | 0.30 Hz |
| 594 / 1422除外 | +0.004 | +0.05 | 0.08 Hz |
この結果から何が分かるか
今回の測定条件では、 594 kHzと1422 kHzの測定値が、 他の較正点が作る直線から系統的に外れていました。
594 kHzだけを残すと StdDev 0.25 Hz。
1422 kHzだけを残すと StdDev 0.30 Hz。
両方とも除外すると 0.08 Hzまで改善しました。
送信側の周波数偏差、 伝搬経路による周波数変動、 受信条件、 その他の要因が含まれる可能性があります。
今回確認できた事実は、 この測定条件では、 594 kHzと1422 kHzを較正点として含めない方が、 他の測定点との整合性が大幅に向上した ということです。
AM放送局をFreqCalに使う時の注意
WSJT-XのUser Guideでも、 大都市圏のAM放送局は 低い周波数側のFreqCal用基準として利用できると紹介されています。
実際、 AM局は強力かつ常時受信できることが多く、 非常に便利です。
ただし今回の測定からも分かるように、
全体の傾向から明らかに外れていないか を見ることが重要です。
特に今回のように、 0.1 Hz単位まで見始めると、 「無線機の誤差」だけではなく、 基準として使っている信号側の差まで 見えてくる可能性があります。
今回採用した最終値
以上の比較から、 今回は594 kHzと1422 kHzを 較正点から除外した結果を採用しました。
Intercept +0.05 ±0.01 Hz
N 123
StdDev 0.08 Hz
この較正式を50 MHzに当てはめると、
= 約0.25 Hz
となります。
もちろん、 これはGPSDOや高精度周波数カウンターを使用した 研究所レベルの絶対周波数校正ではありません。
電離層伝搬、 フェージング、 Doppler、 受信機内部温度などの影響も存在します。
それでも、 通常のアマチュア無線局で、 特別な測定器を使わず、 この程度まで追い込めれば、 FT8などの実運用上は十分だと思います。
*付きの低S/Nデータだけを見ればよいわけではない。
・測定値が正常に見えても、 較正点そのものが他の周波数と整合しているか確認する。
・Slopeは周波数依存の誤差。
・Interceptは直線近似の固定オフセット成分。
・StdDevは、 各測定点が近似直線からどの程度散らばっているかを見る指標。
・今回の測定では、 594 / 1422 kHzを除外することで StdDevが0.32 Hzから0.08 Hzへ改善。
・最終的に Slope +0.004 ppm、 Intercept +0.05 Hz を採用した。
FreqCalは、 単に 「無線機の周波数を合わせる機能」 として使うだけでも便利ですが、
こうして測定値を比較していくと、 リグ、 伝搬、 基準信号、 直線近似の関係まで見えてくる ので、 なかなか面白いツールです。
Frequency Calibration
https://wsjt.sourceforge.io/wsjtx-main_en.html
WSJT-X Frequency Measurement Tools
https://wsjt.sourceforge.io/FMT_User.pdf
関連記事
WSJT-X FreqCalでリグの周波数を正確に合わせる
2026年9月29日
WSJT-X FreqCalでリグの周波数を本気で合わせる ― IC-7300 / FT-991Aの基準周波数調整からJTDXまで【2026年版】 ― 2026年09月28日 19時47分05秒
さらにIC-7300やFT-991 / FT-991Aのように 基準周波数を調整できるリグなら、 まずリグ本体をできるだけ正しく合わせ、 その後に残ったわずかな誤差だけを WSJT-X / JTDXで補正することができます。
FT8などを運用していると、 「○○局はDF 850付近に出ています」 といった情報交換をすることがあります。
ところが同じ局を受信しているはずなのに、 局によって表示されるDFが数Hz、 場合によってはそれ以上違っていることがあります。
原因の一つが、 無線機の基準周波数の誤差です。
HFではあまり気にならなかったわずかなppm誤差も、 6mではかなり目立ってきます。
私はこれまで、
という記事を書いてきました。
今回は2026年9月にもう一度実際に測定し直しながら、 現在のWSJT-Xの仕様と実測で分かった点を含めて、 手順を最初から整理し直します。
今回の考え方 ― FreqCalを二段階で使う
その後で、残ったわずかな誤差だけを ソフトウェアで補正する。
最初に重要 ― 十分にウォームアップする
周波数調整は、 電源を入れてすぐに行ってはいけません。
リグ内部の基準発振器は温度の影響を受けます。 電源投入直後は内部温度が変化しているため、 その状態でぴったり合わせても、 温まった後には再びずれてしまう可能性があります。
ただし、本当の判断基準は時間ではありません。 FreqCalで同じ基準信号をしばらく観測し、 ワイドグラフ上の位置が時間とともに 一方向へ動き続けなくなったことを確認します。
私は以前の記事では2時間程度ウォームアップしてから行った例も紹介していますが、 今回の再測定では約30分観測し、 基準信号の位置がほぼ安定したことを確認してから調整を開始しました。
どの周波数を使うか
FreqCalには、 周波数が分かっている安定したキャリア信号を使います。
日本であれば、 地元の中波AM放送局や、 5 MHz、10 MHz、15 MHz、20 MHzなどを利用できます。
例えば20 MHzが良好なら20 MHz、 20 MHzが使えず15 MHzが良好なら15 MHz。
その時点で安定して測定できる周波数だけを使えばよい ということです。
今回の測定でも、 ある時間帯の15 MHzはS/Nが低く、 測定値が大きくばらついていました。 一方で20 MHzは非常に安定して受信できていました。
逆のことが起きる日も当然あります。
STEP 1 ― まずリグ本体を合わせる
1．FreqCalにする
WSJT-Xのメニューから、
を選びます。
2．使用する周波数を確認する
へ進み、 「運用周波数」の中からFreqCal用の周波数を確認します。
必要に応じて、 受信可能な地元AM放送局などを追加します。
3．「測定」をONにする
メイン画面の「測定」にチェックを入れます。
したがって、 以前の記事で行っていたように、 測定前にスロープ／インターセプトを 手作業で0へ戻す必要はありません。
4．安定して測定可能な最高周波数でまず粗調整
ここは今回の再測定で、 以前よりも分かりやすい手順だと感じた部分です。
まず、 その時点で安定して受信できる基準信号のうち、 最も高い周波数を受信します。
基準発振器のppm誤差は、 周波数が高いほどHz換算で大きく現れます。
| 周波数 | 0.1 ppmの誤差 |
|---|---|
| 5 MHz | 0.5 Hz |
| 10 MHz | 1 Hz |
| 20 MHz | 2 Hz |
| 50 MHz | 5 Hz |
したがって、 高い周波数の方がREF Adjustを動かした時の変化を確認しやすくなります。
今回私は20 MHzが良好に受信できていたので、 まず20 MHzだけを見ながら IC-7300のREF Adjustを少しずつ動かしました。
1500 Hzに最も近くなった値は、 今回の私のIC-7300では 39.2%でした。
2021年の記事を書いた時は34.5%でした。 今回39.2%だったからといって、 他のIC-7300を39.2%にすればよいという意味ではありません。
必ず自分のリグを実測して決めてください。
また、 20 MHzを1500.000 Hzへ完全一致させること自体が目的ではありません。
ここではあくまで、 FreqCalを始める前の粗調整です。
5．FreqCalを一巡させて全体を見る
粗調整ができたら、
を選びます。
WSJT-Xは、 設定したFreqCal用周波数を 30秒ずつ順番に受信していきます。
正しく較正されたリグなら、 基準信号はワイドグラフ上の 1500 Hz付近に現れます。
調整前 ― 周波数が高くなるほどズレる
2021年の測定例。 受信周波数が高くなるにつれ、 1500 Hzからのズレが大きくなっています。
この状態は非常に分かりやすい例です。
低い周波数では1500 Hz付近に見えていても、 周波数を上げるにつれて 中央からのズレが大きくなっています。
基準発振器そのものにppm単位の誤差があると、 このように誤差が周波数に比例して大きくなります。
複数の周波数を見て、 周波数が高くなるにつれて 一方向へズレが増えていく傾向 を確認することが重要です。
6．リグ本体の基準周波数を微調整する
IC-7300なら、 REF Adjustを少しずつ動かします。
IC-7300のREF Adjust。 画像は2021年当時のものです。
ここでの目標は、 一つの周波数だけを1500 Hzへ合わせることではありません。
後でWSJT-Xが数値として求める 「スロープ」を、 この段階ではREF Adjustによって リグ本体側でできるだけ小さくしている、 と考えると分かりやすいでしょう。
7．周波数を変えても1500 Hz付近に集まることを確認
基準周波数調整後。 各周波数で基準信号が概ね1500 Hz付近へ集まっています。
このように、 周波数を切り替えても 基準信号が概ね1500 Hz付近へ集まるようになれば、 リグ本体の調整はほぼ終了です。
完全に一本の線へ重なる必要はありません。
実際の受信信号には、 電離層伝搬による周波数変動、 フェージング、 マルチパス、 S/N、 リグ内部温度の微小変化なども影響します。
基準信号側も盲信しない
地元のAM放送局は、 低い周波数側の測定点として非常に便利です。
ただし、 公称周波数に対して すべての送信局がサブHzまで完全一致している、 と最初から決めつけるのもよくありません。
今回の実測では、 594 kHz、954 kHz、1242 kHzと比較して、 1422 kHzだけが異なる方向の安定した偏差を示しました。
これだけで 「1422 kHzの送信局がずれている」 と断定することはできません。
しかし、 一つの測定点だけが全体の傾向から外れている場合、 その一点に合わせてREF Adjustを動かさない ことが重要です。
FreqCalは 「一つの正しそうな信号へ無線機を無理に合わせる」 ためのものではありません。
ここが非常に重要 ― REF Adjust確定後にfmt.allを捨てる
つまり、 REF Adjust変更前、 調整途中、 調整後の測定値は、 同じ条件で測定したデータではありません。
REF Adjustが確定した時点で、 それまでの測定データを一度捨て、 固定したREF Adjustの状態から 改めてFreqCalを取り直します。
今回の再測定で、 まさにこれを実際に経験しました。
低S/Nを示す「*」付きデータを削除したにもかかわらず、 「較正パラメータ計算」を実行すると、
Check fmt.all for possible bad data.
というエラーになりました。
原因は、
REF Adjustを変更する前と変更した後のデータが
同じfmt.allに残っていたことでした。
異なる基準周波数状態の測定値を一緒に直線近似すれば、 当然ばらつきは大きくなります。
REF Adjustを確定した後のデータだけにしたところ、 正常に「較正良好」となりました。
↓
それまでのfmt.allを削除
↓
REF Adjustを固定
↓
本番のFreqCalを最初から取り直す
STEP 2 ― 調整済みリグで本番のFreqCal
1．fmt.allを削除
からログディレクトリを開き、
それまでのfmt.allを削除します。
2．REF Adjustはもう触らない
ここから先は、 決定したREF Adjustを固定します。
今回の私のIC-7300では 39.2%で固定しました。
3．「周波数較正実行」を改めて開始
を実行し、 「測定」をONにします。
今度はREF Adjustを一切変更せず、 同一条件のまま数巡測定します。
4．fmt.allを確認する
測定後、
fmt.allをテキストエディタで確認します。
明らかに外れた測定値や、 受信状態が悪かった測定値は除外します。
以前の記事では 「*付きデータを削除」 と簡単に書きましたが、 正確には 低S/Nのため信頼性を確認すべき測定値 という意味です。
*があるから数学的に必ず無効、 *が無いから必ず正しい、 という意味ではありません。
*の有無だけではなく、 周囲の値から大きく外れた測定値も確認します。
5．「較正パラメータ計算」
を実行します。
WSJT-Xは、 複数の周波数で得られた誤差から、 次の直線を求めます。
B = スロープ [ppm]
f = 周波数 [MHz]
大まかには、
- インターセプト： 周波数に依存しない固定的な誤差成分
- スロープ： 周波数が高くなるほど増える比例誤差成分
calibrate.f90では、
fmt.allの測定値を周波数ごとに平均し、
その後スロープとインターセプトを直線近似します。
さらに現在のGUI側では、 そのfitのRMSが1 Hzを超えると 「Check fmt.all for possible bad data.」 というCalibration Errorになります。
今回、REF Adjust変更前後のデータを混在させた時に このエラーが出た理由もこれです。
今回の実測結果
REF Adjustを39.2%に固定し、 それ以前の測定データを除外した上で FreqCalを取り直した結果、 次の「較正良好」が得られました。
| Slope | +0.046 ±0.008 ppm |
| Intercept | -0.39 ±0.07 Hz |
| N | 58 |
| StdDev | 0.39 Hz |
この結果を20 MHzへ当てはめると、
となります。
実際に20 MHzで観測していた偏差も およそ+0.52～+0.54 Hz程度でしたので、 計算結果ともよく一致しています。
6．「較正良好」ならApply
計算結果が正常なら、 「較正良好」のダイアログが表示されます。
結果を確認して Applyを押します。
すると、
の スロープ／インターセプト へ値が反映されます。
7．最後に「測定」をOFFにして確認
FreqCalモードのまま、 「測定」のチェックを外します。
「測定」を外すと、 設定された周波数較正値が有効になります。
再度「周波数較正実行」を行い、 各基準信号が1500 Hz付近に現れることを確認します。
JTDXにも同じ値を設定
JTDXにも、 周波数較正用の スロープ／インターセプトを設定する項目があります。
同じリグを使用するのであれば、 WSJT-Xで求めた値をJTDXにも設定します。
これによって、 リグ側にわずかな残留誤差があっても、 WSJT-X / JTDXで正しいDF表示に近づけることができます。
IC-7300だけの方法ではありません
この方法はIC-7300だけに限定したものではありません。
ユーザーが基準周波数を調整できるリグなら、 基本的には同じ考え方が使えます。
| リグ | 基準周波数調整 |
|---|---|
| ICOM IC-7300 | REF Adjust |
| YAESU FT-991 / FT-991A | REF FREQ ADJ |
FT-991 / FT-991Aなら、 IC-7300のREF Adjustを動かした段階で REF FREQ ADJを調整すればよいわけです。
スマートフォンのAF発振器などを使う方法との違い
スマートフォンの音声発振器などを使って、 受信音との周波数差を見ながら 基準周波数を調整する方法もあります。
簡便な方法としては十分意味があります。
ただ、 PCとWSJT-Xを使える環境であれば、 私はFreqCalを利用する方法を勧めます。
周波数が高くなるほど誤差が増える傾向を ワイドグラフで視覚的に確認でき、 さらに最終的には スロープ／インターセプトとして 定量的に評価できます。
これは「絶対周波数標準器による校正」ではありません
ここで紹介している方法は、 GPSDOや高精度周波数カウンターなどを使用した 研究所レベルの絶対周波数校正ではありません。
受信する信号には、 電離層伝搬によるDoppler、 フェージング、 マルチパス、 S/Nの変化なども含まれます。
したがって、 1 Hz以下の数字を見て 意味なく追い込み続けるものではありません。
まとめ
- リグを十分にウォームアップする
- FreqCalでドリフトが落ち着いたことを確認する
- その時点で安定して測定できる最高周波数で REF Adjustを粗調整する
- 「周波数較正実行」で複数周波数を見て、 高い周波数ほどズレる傾向を確認する
- REF Adjust / REF FREQ ADJを微調整し、 その傾向を最小にする
- REF Adjustを確定する
- ここで、それまでのfmt.allを必ず削除する
- REF Adjustを固定したまま、 改めてFreqCalを数巡実行する
- 低S/Nや外れ値をfmt.allから確認・除外する
- 「較正パラメータ計算」を実行する
- 「較正良好」ならApplyする
- 必要なら同じスロープ／インターセプトを JTDXにも設定する
そして最後に残ったわずかな誤差だけを ソフトウェアで補正する。
そのためにFreqCalを 「測定器」と「補正値計算」の 二つの用途で使います。
特に50 MHzのように、 わずかなppm誤差が数Hz～数十Hzの差として見えるバンドでは、 一度確認してみる価値はあると思います。
リグ本体の基準周波数調整を変更する場合は、 必ず各リグの取扱説明書を確認してください。 設定変更はご自身の責任で行ってください。
この記事で示したREF Adjustの数値は 私の個体での測定例であり、 他の個体にそのまま適用するための値ではありません。
https://wsjt.sourceforge.io/wsjtx-main_en.html
WSJT-X Frequency Measurement Tools
https://wsjt.sourceforge.io/FMT_User.pdf
WSJT-X source ― calibrate.f90
calibrate.f90
WSJT-X source ― freqcal.f90
freqcal.f90
旧記事：JTDX WSJT-X の周波数較正
https://jp1lrt.asablo.jp/blog/2020/10/28/9310527
旧記事：IC-7300 基準周波数調整
https://jp1lrt.asablo.jp/blog/2021/03/02/9352207
旧記事：Rig frequency calibration
https://jp1lrt.asablo.jp/blog/2024/08/31/9713282
WS – Digital Mode Suite 日本語User Guideを本気でレビューしてみた ― 69箇所修正、その日のうちに正式公開 ― 2026年09月27日 22時48分47秒
今日、DG2YCB/Uweから、
という連絡をもらいました。
せっかくなので、単なる誤字脱字のチェックで終わらせるのではなく、 英語版と日本語版のHTMLを比較しながら、かなり本気でレビューしてみることにしました。
対象は WS – Digital Mode Suite の日本語User Guide。
単なる「日本語の校正」ではありません
今回は英語版と日本語版を比べるだけではなく、 実際の WS 3.2.1のGUI、source code、日本語translation（.ts） とも照合しました。
確認したのは、例えばこんなところです。
- 英語原文との意味の一致
- 実際のGUI表示との用語統一
- 未翻訳の英語が残っていないか
- 日本語表記の揺れ
- 不自然な日本語や誤訳
- 現在のsource codeとの食い違い
- HTML構造を壊していないか
最終的に、69箇所を修正しました。
例えばこんなところを修正
| 修正前 | 修正後 |
|---|---|
| Falseデコードを軽減 | 誤デコードを低減 |
| WS-MAPを占有 | WS-MAP操作権を取得 |
| ダイアル周波数 | ダイヤル周波数 |
| フィルター（software機能） | フィルタ |
「全部日本語にすればいい」のか？
ここは今回、ちょっと考えさせられたところです。
個人的には、 「Falseデコード」 の方が、なんとなくデジタルモードっぽくて格好いいと思っています（笑）。
同じように、
Early / Normal / Late
のような短い技術用語も、英語のままで十分意味が通りますし、 技術系softwareではむしろその方が分かりやすい場合もあります。
しかも、今回User Guide側を合わせた日本語UIは、 その少し前に自分もレビューを手伝ったものです。
↓
User Guideを確認
↓
「GuideとUIの表記が違う」
↓
GuideをUIに合わせる
……ある意味、自分で自分の首を絞めました（笑）
UIをレビューした時点で、 「これは英語のまま残す方がいいのでは？」 と、もう少し細かく考えておけばよかったかな、とも思いました。
でも、日本語UIを必要としている人の立場で考えると……
そこで、もう一度考えてみました。
自分には英語のままで分かったとしても、 日本語UIを使う人すべてがそうとは限りません。
むしろ、
という方も当然たくさんいるはずです。
| 英語UI | 日本語UI |
|---|---|
| Low / Medium / High | 低 / 中 / 高 |
| Early / Normal / Late | 早め / 標準 / 遅め |
| False decode | 誤デコード |
そう考えると、日本語化する意味は十分にあります。
「自分ならどちらが格好いいか」ではなく、
「その言語のUIを必要としている人にとって、どちらが分かりやすいか」。
もちろん、CQ、FT8、DXCC、LoTWのように、 無理に日本語へ置き換えない方がいい言葉もあります。
「訳せるものは全部訳す」でもなければ、 「技術用語だから全部英語のままでいい」でもない。
その境界を考えるのも、localizationの面白いところだと思います。
日本語を見ていたら、英語Guide側の問題まで見つかった
User Guideを詳しく調べていくと、 日本語訳とは別に、英語Guideやsource側の古い記述と思われる部分もいくつか見つかりました。
例えば、現在のmain windowには以前のような 「Call 1st」checkbox はありません。
現在は、
CQ: First
CQ: Max Dist
CQ: Max dB
CQ: Min dB
というCQ selectorを使う実装になっています。
ところが、一部の設定説明やkeyboard shortcut helpには、 まだ「Call 1st checkbox」という以前の表現が残っていました。
また、3.2.1で動作が変更された “Highlight all messages” についても、User Guide側には旧仕様と思われる説明が残っていることを確認。
こういうところは、日本語だけ勝手に書き換えるべきではありません。
そこで今回は、
2. applicationの日本語translation側の問題
3. 英語Guide / source側の問題
と分けてUweへ報告しました。
AIにも独立チェックさせてみた
修正版については、自分の判断だけで完結させず、 AIにも独立してチェックを依頼しました。
「こちらの判断に合わせてくれ」ではなく、 誤訳、過剰修正、見落としがないかを疑って調べてもらう形です。
実際にこちら側の見落としも見つかり、再確認・修正したうえで最終版を作成。
HTMLについても、ID、anchor、link、table、 そして埋め込み画像40枚が壊れていないことを確認しました。
そして、その日のうちに公開
最終版をUweへ送ったところ……
73 de DG2YCB,
Uwe
仕事が速い（笑）。
今日のうちに、そのまま公開されました。
念のため、公開後のHTMLを自分でもダウンロードして、 こちらから送った最終版と比較しました。
SHA-256も完全一致
つまり、こちらでレビューした日本語版が、 そのまま正式公開されたことを確認できました。
今日一日で
↓
英語版／日本語版比較
↓
GUI・source・translationとの照合
↓
修正
↓
独立チェック
↓
Uweへ送付
↓
正式公開
まで全部終了。
なかなかのスピード感でした（笑）。
翻訳というより「整合性を取る仕事」
こういう作業は、単純に英文を日本語へ置き換えるだけではありません。
↓
日本語
↓
実際のGUI
↓
source code
↓
User Guide
を行ったり来たりしながら、 全体の整合性を取っていく作業なのだと思います。
そして今回、改めて感じたのは、
「日本語版を必要としている人に分かりやすい」ことは別。
ということでした。
地味ですが、こういう作業は結構好きです（笑）。
あとはどこかに、
Japanese review: JP1LRT
くらいクレジットが入ったら、もっと嬉しかったんだけどなあ（笑）。
まあ、それは次の機会に。
JTDX_CONTEST v3.0.0-rc09 ― macOS対応だけじゃない、“中身”が大きく変わったリリース ― 2026年09月27日 11時14分29秒
JTDX_CONTEST v3.0.0-rc09 ― macOS対応だけじゃない、“中身”が大きく変わったリリース
CE3TSK / Tihomir が開発している JTDX_CONTEST v3.0.0-rc09 が公開されました。📡
今回は本人から直接リリースの連絡をもらったこともあり、 単にリリースノートを眺めるだけではなく、 実際にrc09のソースコードも読んでみました。
今回のrc09は、 「macOS版が追加された」 というだけのリリースではありません。
FT2切替時のクラッシュ、Fortran decoder内部のrace condition、 終了処理、PTT、Band Scheduler、Mode lock、 main programとdecoderの整合性確認など、
内部の安定性をかなりまとめて改善したリリース になっています。
🍎 Apple Silicon / Intel Mac に対応
rc09最大の見た目上のトピックは、やはりmacOS対応でしょう。
- Apple Silicon（M1以降）向け
- Intel Mac向け
の2系統が用意されています。
Tihomirによると、Apple Silicon版の確認用には新しいMacを、 Intel版ではできるだけ古い環境まで対応させるため、 2012年のMacBook Airまで実際に用意したとのこと。
Intel版はmacOS Catalina 10.15以降を広く対象とする考え方で、 Apple Silicon側はmacOS Tahoe環境で開発・確認されています。
またJTDX系では比較的大きなshared memoryを使います。 macOS標準設定では不足する場合がありますが、 rc09では必要なshared memory量を確認し、 不足している場合の設定変更まで考慮されています。
🎛 Mode buttons を追加
View → Mode buttons を有効にすると、FT8 / FT4 / FT2などのModeを メニューを開かず直接ボタンから選択できるようになりました。
ここで面白いのは、単に「Modeを変える別のボタン」を作ったわけではないこと。
既存のMode QActionと連動しているため、 Contest Modeなどによって使用禁止になっているModeは、 ボタン側も自動的に無効になります。
そんな状態を避けるよう、Mode操作のgateそのものも整理されています。
🖱 Bandボタンを右クリックすると、別周波数を直接選べる
これは実運用でかなり便利そうです。
Bandボタンを普通に左クリックすると、従来どおりdefault frequencyへ。
一方、右クリックすると、 そのBandに登録されているdefault以外の周波数 をメニューから直接選択できます。
例えば同じ50MHzの中に、 FT8、FT4、FT2、その他の運用周波数を登録している場合でも、 Frequency設定画面を開かずに選択できます。
候補がない場合には “No other frequencies” と表示されます。
「右クリックしたけど何も起きなかった？」 とならないところまで考えられています（笑）
⚠ FT2切替時のクラッシュを修正
これは単なるGUI上の小修正ではありません。
受信audio blockを途中まで処理している状態でFT2へ切り替えると、 FT2ではaudio block sizeが小さくなります。
旧処理では、このとき buffer位置と新しいblock sizeの計算が崩れ、 unsigned underflowからbuffer外へ書き込む可能性 がありました。
rc09ではblock sizeが途中で小さくなった場合、 すでに蓄積されているaudioを新しいblock単位へ正しく組み直して処理するよう変更。
通常のaudio inputだけでなく、 TCI audio側にも同様の修正が入っています。
🧵 decoder内部のrace conditionを修正
こちらは、ソースを読んでいてかなり興味深かった部分です。
macOSでIW5DNZから報告されたクラッシュを調べたところ、 原因はmacOS固有ではなく、 他platformにも潜在的に存在していたFortran decoder内部のrace condition でした。
Fortranのmodule-scope initializerで使用されたloop counterが、 gfortranによってmodule variableとして生成され、 複数のdecoder threadから共有されるケースがあったとのこと。
FT4では実際にarray index異常によるクラッシュが発生。 bounds checkがなければ、 クラッシュせずにloop elementを飛ばしたり繰り返したりする可能性もあります。
rc09では問題になった箇所だけを直して終わりではなく、 同じ種類の「漏れたloop counter」を build時に検出して止める仕組み まで追加されています。
🔐 main program と decoder の組み合わせを確認
JTDXではmain programとは別にdecoder executableが動作します。
ここで古いdecoderや、 別のFT8系softwareから残ったdecoderが混在すると、 main program側とdecoder側のshared-memory interfaceが一致せず、 非常に分かりにくいトラブルになる可能性があります。
rc09では、
- program version
- interface fingerprint
- shared-memory構造サイズ
などをmain programとdecoderの間で照合。
組み合わせが正しくなければ、 decodeを始める前に検出します。
「一応起動はするけれど、なぜかdecodeがおかしい」 という最悪に分かりにくい故障モードを防ぐ仕組みです。
🛑 終了時のhang対策 ＋ PTT OFFを優先
Rig controlやaudio deviceが応答しなくなった場合、 これまで終了処理がhangする可能性がありました。
rc09では終了処理にtimeoutを持たせ、 無期限に待ち続けないよう改善されています。
しかも無線softwareとして重要なのが、 まずPTT OFFを送ってから終了処理へ入る よう考えられていること。
TCIでもPTT OFFが送信bufferに残らないようflushまで考慮されています。
これは絶対に避けたいところなので、地味ですが重要な改善です。
⏰ Band Schedulerの「5番目」が実は動かなかった（笑）
設定上、Band Schedulerには5個のentryがあります。
ところが旧コードでは、 5番目を判定する部分で4番目の時刻を比較しており、 さらに4番目のelse側に入っていました。
つまり……
構造上、5番目は発火できませんでした 🤣
rc09ではscheduler判定部分を整理して、この問題を修正。
さらに先頭entryが空の場合にfrequency 0へQSYしかねない挙動も整理されています。
🖥 Wide Graphも扱いやすく
Wide Graph / waterfall windowは、
- 前回終了時のサイズ
- 画面上の位置
を保持して再表示するようになりました。
さらにmain windowの手前に居続けるのではなく、 自然にbackgroundへ戻るよう改善されています。
✅ Decode presetの選択表示も改善
FT8 / FT4 / FT2のdecoder preset menuでは、 現在選択中のpresetが分かりやすくなるよう表示が変更されています。
macOSとLinux / WindowsではQtのmenu描画方法が異なるため、 platformごとの差まで考慮した実装になっています。
🔭 将来用のDXCC / WAS geodataもすでに準備中
これはリリースノートにはほとんど出ていない部分。
rc09のソースには新しく geodata 関連のコードとデータが追加されています。
DXCC entity、grid square、US Stateなどを扱うためのデータで、 ソース側には
“Preparing geodata for future DXCC checks and WAS priorization”
という開発意図が見えます。
現時点ではまだ実際の機能から呼ばれていませんが、 今後のDXCC判定やWAS prioritizationなどに使う準備と思われます。
📝 rc09をソースまで読んでみた感想
表面だけを見ると、
「Mac版が追加されたrc09」
なのですが、ソースを読むと印象はかなり違います。
- FT2 audio buffer処理
- Fortran decoder race condition
- main program / decoder整合性確認
- shutdown / PTT OFF
- Band Scheduler
- Contest ModeのMode lock
- Mode buttons
- Band内の代替周波数選択
- Wide Graph
- macOS対応
なので個人的には、
「macOS対応版」ではなく
“robustness release”
と見る方が実態に近いと思っています。
rc08でExperimental SuperFox decodingが入り、 FT2、multi-thread decoder、decoder presetなども含めて、 JTDX 2.2.159をベースにしながらかなり大きく進化しています。
📥 ダウンロード / Source
JTDX_CONTEST Download
https://ce3tsk.com/download/index.html
GitHub / Source
https://github.com/ce3tsk/jtdx_contest
CE3TSK JTDX_CONTEST
https://ce3tsk.com/
なお、rc09はRelease Candidateです。 その点を理解した上で試してみるのがよいと思います。
73 de JP1LRT
JTDX_contest v3.0.0-rc08登場 ― SuperFoxデコーダーが大幅進化、僕もこのプロジェクトを応援したい ― 2026年09月22日 16時59分21秒
JTDX_contest v3.0.0-rc08 がリリースされました。
今回の最大の注目点は、何といっても Experimental SuperFox decoding support です。
Tihomirから送られてきた説明を読むと、単純に 「WSJT-X 3.0.2のSuperFox receiverを移植しました」 というレベルではありません。
WSJT-X 3.0.2のreceiverを出発点としながら、 JTDX_contest独自のデコード処理をかなり積極的に追加 しています。
🦊 SuperFox decoder の何が変わったのか
SuperFoxの帯域内に通常のFT8信号などが存在しても、 interferenceを受けているtoneだけが突出しないよう補正してから decodeを行います。
候補を絞りながらlist decodingを行い、 messageのCRCを使って候補を確認します。
特に面白いのは、odd periodで実際に受信できたHoundを使って、 Foxが誰に応答している可能性が高いかを絞り込むところです。
一度decodeしたFoxや、DX Call boxに指定されたFox、 受信したHoundなどの既知情報を利用して、 decoderの探索を助けます。
これも非常に興味深いところです。
↓
FT8 signals subtraction
↓
cleaner audio
↓
SuperFox decode
つまり、同じband内の通常FT8を先に見つけて取り除き、 その後にSuperFoxをdecodeするという考え方です。
Fox探索をthread化し、 難しいFoxの探索が他の処理を必要以上に遅らせない構成になっています。
最終段では3つのsync windowを使用し、 Foxにfrequency offsetやtime offsetがある場合にも対応します。 これはデフォルトで有効とのことです。
⚙ Experimental だからこそ面白い
現在、このSuperFox decoderは experimental とされています。
またTihomirによると、 SuperFox関連のconstantは 再buildすることなく変更可能 になっています。
今後、実際のSuperFoxのrecordingを集めながら、 各parameterを調整していくことを想定しているとのことです。
Tihomirは、実際のSuperFox DXpeditionを受信した WAV file を募集しています。
理想は約1時間分とのこと。 実際の信号を使ってdecoderを改善するための資料になります。
📡 SuperFox以外のrc08の変更
✅ 周波数の Mark as default / Unmark default
✅ band buttonはdefault frequencyとIARU regionに合うものを表示
✅ Check for updates 機能を追加
✅ stock JTDXが「ALL」にしてしまったFT2 frequencyを自動修復
✅ main windowを狭くした場合のlayout改善
✅ menu translation、tooltip、keyboard shortcutの修正
📖 SuperFox receiverの解説ページ
新しいSuperFox receiverがどのように動作するのかについて、 Tihomir自身が詳しい解説ページを公開しています。
8言語で用意されています。
🤝 僕はこのプロジェクトを積極的に応援したい
僕自身、JTDXには以前から深く関わってきましたが、 今回のJTDX_contestを見ていて特に面白いと思うのは、 既存のものを単に維持するだけではなく、新しいアイデアを実際に実装して試している ところです。
Decoderは、「理屈では良さそう」だけでは完成しません。
実際のsignal、QRM、frequency offset、time offset、 様々な受信環境で試し、 そこで得られたevidenceを元に改良していく必要があります。
僕は、こういう開発を積極的に応援したいと思っています。
日本のJTDXユーザーにも、 このプロジェクトをぜひ知ってもらいたいと思います。
また、SuperFoxの実録WAVを提供できる機会があれば、 decoder developmentへの非常に良い協力になると思います。
WSJT-X Improved は「WS Digital Mode Suite」へ ― v3.2.0公開に向け準備進行中 ― 2026年09月22日 09時41分32秒
「WS Digital Mode Suite」へ 🚀
長く親しまれてきた「Improved」という名前が、まもなく大きく変わりそうです。
WSJT-X Improved を使っている方なら、最近の動きを見て 「何か始まっているな」と感じているかもしれません。
2026年9月22日現在、SourceForge の Activity には、 新しい WS v3.2.0 のファイルが次々と登録されています。
- Windows 64-bit
- AL版
- Widescreen版
- Windows 32-bit
- Linux
- macOS
- Raspberry Pi
- Source code
これらが ws-3.2.0_260924... という名称で準備されています。
ただし、今日9月22日の時点では、 Activity上に登録状況は見えていても、 通常のダウンロードページからまだ取得できないものがあります。
SourceForge側で最終準備中
という状態と見るのが自然でしょう。
最初は単純に
↓
WS
という名称変更なのかと思っていました。
しかし、JTAlert側の対応を見ると、 もう少し正確な姿が見えてきます。
Support for the new WS Digital Mode Suite (previously known as WSJT-X Improved).
Dedicated JTAlert operating mode for WS with a green colored icon for the "JTAlertV2 for WS Suite" shortcut.
If you want to create your own shortcut use the /wsdms command-line parameter to start JTAlert in WS operation mode.
ここまで明記されているので、 今後の呼び方としては
と考えるのが一番分かりやすそうです。
興味深いのは、 JTAlertが単に実行ファイル名を読み替えただけではない点です。
専用ショートカットとして
が用意され、さらに起動オプションとして
まで用意されています。
つまり周辺ソフト側でも、 WS Digital Mode Suite を独立したアプリケーション環境として扱う準備が進んでいる ということです。
僕も WSJT-X をベースにした派生版を開発しています。
そして先日、K1JT Joe から直接、
“WSJT-X” を含めないでほしい
という要請を受けました。
そのため僕自身の版についても、 現在はいったん一般公開を停止し、 re-name / re-brand を進めています。🔧
僕自身は Joe から直接、名称についての要請を受けた。
Uweさんの WSJT-X Improved は WS Digital Mode Suite への移行を進めている。
Uweさんが Joe から同じ要請を受けた結果として 今回の名称変更を行ったのかどうか。
タイミングだけを見ると、 「同じ話なのでは？」と思いたくなります。
ただ、Uweさん本人からその経緯を聞いたわけではありません。
なので、そこは勝手に結び付けず、 分けて考えておきたいと思います。
WS Digital Mode Suite v3.2.0 の正式公開へ
Windows / Linux / macOS / Raspberry Pi など
JTAlertなどが「WS Suite」を独立した対象として扱う
徐々に WS Digital Mode Suite / WS Suite という呼び方へ移行
僕自身、長い間 WSJT-X Improved を追いかけてきました。
JTDXやWSJT-X Improvedの開発の流れをずっと見てきただけに、 「WSJT-X Improved」という名前そのものが消えていく のは、少し不思議な感じがします。
でも、これは単なる名前変更というより、
「WSJT-X ○○」ではなく、
自分自身の名前を持つソフトウェアへ
という大きな転換点なのかもしれません。
- 従来版からの設定引き継ぎ
- 旧 WSJT-X Improved との共存
- フォルダ名や設定保存先の変更
- JTAlert の WS Suite モード
- PSK Reporter へ送られる program identity
- 旧版ユーザーがそのまま移行できるのか
9月24日に正式公開されたら、 実際にインストールしてこのあたりも確認してみたいと思います。
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
JTDX_CONTEST を試す ― 6m激混みWAVで見えたデコーダーの実力 ― 2026年09月13日 16時02分25秒
JTDX_CONTESTを試す ― 6m激混みWAVで見えたデコーダーの実力
JTDXにコンテスト機能を加えただけのForkではありません。FT8 / FT4のデコーダーにかなり手が入り、Ensemble、Alternate pass、Hint memory、さらに送信中の空きCPU時間を利用するBackground decodingまで実装されています。
最近、なかなか興味深いJTDXのForkを見つけました。
JTDX_CONTEST by CE3TSK
名前だけを見ると「JTDXにコンテスト機能を追加した版かな？」と思うのですが、実際に調べ、動かしてみると、それだけではありませんでした。
長年JTDXを使っていて、「1局でもデコード漏れを減らしたい」という人には、一度試してみる価値がかなりあると思います。実際の送受信に使うも良し、既存のJTDXの横で受信専用decoderとして走らせるも良しです。
JTDXユーザーにはかなり気になるFork
私はJTDXのベータテスターとして、一般公開版の2.2.159だけでなく、2.2.160 RC版も使用しています。
今回は、次のソフトを同じWAVファイルで比較してみました。
- WSJT-X 3.0.2
- JP1LRT Edition（WSJT-X 3.1 Improvedベース）
- JTDX 2.2.159
- JTDX 2.2.160 RC版
- JTDX_CONTEST v3.0.0-rc05
JP1LRT Editionではデコーダー部分には一切手を加えていません。基本的にWSJT-X本流由来のデコーダーをそのまま使用しています。
ところが、そのBenchmark WAVに見覚えが……
JTDX_CONTESTのサイトには、作者CE3TSKが性能評価に使用しているBenchmark WAVが公開されています。
FT8 / FT4それぞれ1時間分、240 periodの実受信データに加え、信号数が既知のcrowded-band用WAVも公開されており、Pythonのbenchmark scriptまで用意されています。
そのcrowded-band用FT8 WAVのファイル名を見て、
となりました（笑）。
元のファイル名は、
210615_071015.wav
2021年6月15日 07:10:15 UTC。
これは、このBlogでも以前公開したWAVです。
録音したのは、6m仲間のJR1LZK 田崎さん。茨城県水戸市で50MHzを受信した際の、非常に混雑したFT8の1 periodです。
当時、田崎さんの了解をいただいて、このBlogでBenchmark用として公開しました。
2021年の記事「FT8 decoding benchmark」
今回、JTDX_CONTEST側の ft8_full_band_16.wav と、元の 210615_071015.wav を実際に比較したところ、バイト単位で完全一致していました。
もちろん、有効に使っていただいているのは大歓迎です。
CE3TSK側では、このWAVについて104信号のtruth setを作成しており、そのうち101局がJA局だったと説明しています。6mの大オープンらしい、かなり過酷なデコーダー試験素材です。
同じWAVで比較してみた
今回の手元での比較結果は次の通りでした。
| Software | Decode数 | WSJT-X 3.0.2比 |
|---|---|---|
| WSJT-X 3.0.2 | 73 | 基準 |
| JP1LRT Edition / WSJT-X 3.1 Improved | 73 | ±0 |
| JTDX 2.2.159 | 75 | +2 |
| JTDX 2.2.160 RC版 | 83 | +10 |
| JTDX_CONTEST v3.0.0-rc05 | 93 | +20 |
73 → 75 → 83 → 93。
このWAVのような、極端に多くの信号が重なった状況では、かなり大きな差です。
まず、WSJT-X 3.0.2とJP1LRT Editionはともに73 decodeでした。
JP1LRT Editionではデコーダー部分に手を加えていないため、この結果はある意味当然ですが、少なくとも今回の試験では、JP1LRT Edition独自改造によってデコード性能が低下しているわけではないことも確認できました。
JTDX 2.2.159では75、2.2.160 RC版では83、そしてJTDX_CONTESTでは93でした。
この1本のWAVだけでソフト全体のデコード性能を断定するつもりはありません。極端に混雑した6mの1 periodに対する一つの比較結果です。ただし、この条件での差としては無視できないと思います。
JTDX_CONTESTは何をしているのか
JTDX_CONTESTの面白いところは、単純にデコード閾値を下げただけではないところです。
Ensemble decoding
同じ音声にわずかなdelay、dither、frequency shiftなどを与え、複数の条件でdecodeし、その結果を統合します。
Alternate pass
通常のdecode後に残ったresidual audioに対して、別のdecode recipeでもう一度探索します。
Hint memory
一度decodeした局やメッセージの情報を複数periodにわたって保持し、次のdecodeに利用します。
Background decoding / Pipeline
そして個人的に最も面白いと思ったのが、Background decoding / Pipelineです。
「送信中にもdecodeする」
通常のFT8ソフトでは、受信periodが終わるとdecodeを実行し、その結果で次の送信内容を決めます。
JTDX_CONTESTは、ここを二段階に分けています。
まず短時間のRX phaseで、次の送信を決めるために必要なdecodeを済ませます。
その後、こちらが送信を開始してからも、直前に受信した音声を保持したままBackground decodingを続けます。Alternate pass、Ensemble、Residual decodeなどを、従来ならCPUが遊んでいた時間に実行します。
送信が始まってから見つかったメッセージを、その最中の送信内容へ反映することはできません。しかし、その結果は次のperiod以降に使えます。
例えば、Background decodingで次のようなものを見つけたとします。
- 自局宛てのメッセージ
- New DXCC
- New Call on Band
- 強力な局の下に埋もれていたDX
現在の送信には間に合わなくても、その情報をHint memoryなどへ引き継いでおけば、次の受信periodでは既知候補として扱える。
つまり送信中の追加decodeは「今の送信を変えるため」ではなく、次の送信判断に使う情報を先に掘っておくための処理と考えると分かりやすいと思います。
6m DXでは、これはかなり価値があると思います。
一瞬のオープンでNew DXCCが出てくる6mでは、これが一番悔しいパターンです（笑）。
送受信に使うも良し、受信専用でも良し
JTDX_CONTESTは、普通に送受信ソフトとして使うこともできます。
一方で、
という使い方も面白いと思います。
JTDXユーザーの中には、取りこぼしを嫌って複数のdecoderを同時に動かしている方も少なくないでしょう。
そういう人にとっては、かなり興味深い選択肢になるはずです。
Contest機能も搭載
名前の通り、JTDX_CONTESTにはコンテスト機能も組み込まれています。
現在は特にWW Digi DX Contestを意識した実装となっており、exchange、points、multipliers、contest logなどが統合されています。
単なる「JTDXのdecoder実験版」ではなく、実戦運用までかなり意識して作られている印象です。
Benchmark環境も公開されている
もう一つ評価したいのは、作者が性能を主張するだけでなく、検証用のWAVとscriptを公開していることです。
- FT8：実受信1時間、240 period
- FT4：実受信1時間、240 period
- crowded-band WAV
- truth set
- benchmark script
crowded-band用WAVにはtruth setがあるため、単に「何局decodeしたか」だけでなく、false decodeまで評価できます。
という形で再現素材まで公開している姿勢は、とても好感が持てます。
JTDXユーザーなら一度試してみる価値あり
JTDX_CONTESTは現在、v3.0.0-rc05です。
したがって、完成したGA版として評価する段階ではありません。
しかし、長年JTDXを使っていて、
という人には、一度試してみる価値がかなりあると思います。
特にFT8 / FT4でDXを追いかけている人、6mのような一瞬のオープンを狙っている人には面白いでしょう。
実際の送受信に使うも良し。受信専用のサブdecoderとして使うも良し。
Webサイトは日本語表示にも対応しています。
最後にちょっとだけ
今回、
WSJT-X 3.0.2 = 73
JP1LRT Edition = 73
JTDX 2.2.160 RC版 = 83
JTDX_CONTEST = 93
という結果を目の前で見てしまいました。
でも、JP1LRT Editionではデコーダーには手を付けていません。
これはむしろ、次に何を研究すべきかが見えてきた、と考えることにします。
73, Yoshi / JP1LRT
最近のコメント