QSLカード、裏返さなくても分かりますか? ――「マイルール」ではなく、受け取る側への小さな配慮 ― 2026年10月14日 12時03分50秒
PAPER QSL CARD & A LITTLE COURTESY
📮 QSLカード、
裏返さなくても分かりますか?
「マイルール」なのか、それとも受け取る側への配慮なのか。
先日、Xで「届いたQSLカードのデータ面に、発行局自身のコールサインが書かれていない」という投稿が話題になっていました。
これに対して「そんなのマイルールだ」「他人に押し付けるな」といった批判もあるようです。
でも、この話。ちょっと面白いんですよね。😊
私は「他人に強制してはいけない」という点には賛成です。一方で、「義務ではないから、書く意味もない」わけでは決してないと思っています。
📻 そもそも、何が不便なの?
例えば、紙QSLカードの表面が写真やイラストを使ったデザイン面、裏面が交信データ面になっている場合を考えてみましょう。
📷 表面(デザイン面)
大きな発行局コールサイン、写真、イラストなど
↕ ひっくり返す ↕
📝 裏面(交信データ面)
交信相手のコールサイン、日時、周波数、モード、RSTなど
ところが、発行局自身のコールサインがない……。
これでも、表面に発行局のコールサインが明確に表示されていれば、それだけでQSLカードとして成立しなくなるわけではありません。 問題はそこではないんです。
受領者が交信データをログと照合するとき、「これ、誰からのカードだっけ?」と表面へひっくり返して確認する必要がある。1枚なら数秒。でも、何百枚、何千枚となったらどうでしょう。😅
発行する側が一度レイアウトを工夫すれば、受け取る側の繰り返しの手間を減らせる。 そういう話です。
✅ 私のQSLカードでは
私は、交信データ面にも、いつも次の情報を記載しています。
自局コールサインの JP1LRT
📍 自局の運用地 ― JCC/JCG番号、Grid Locator
👤 オペレーター名
📋 交信データ ― 相手局、日時、周波数、モード、RSTなど
これならデータ面だけで、誰が・どこから・いつ・どのように交信したかを確認できます。
もちろん、JCC/JCG番号やGrid Locatorは実際にその交信を行った運用場所の情報を記載することが大切。移動運用なら、固定局の所在地と混同しないようにしたいですね。
名前の表示も含め、ここで挙げた項目すべてが一律に義務という意味ではありません。私自身が、受領者にとって便利だと考えて採用しているデザインです。
🌏 これって本当に「マイルール」?
そこで、海外のアマチュア無線団体の資料も調べてみました。すると、交信データと発行局情報を同じ面で確認できるようにするという考え方が、きちんと紹介されていたんです。
🇺🇸 ARRL(米国)
ARRLの公式資料 Sending and Receiving Paper Gems の「Essential Information」には、こう書かれています。
Your call sign should be printed or written on the report side of the card.
「自局のコールサインは、交信レポート面に印刷または記入すべきです。」
今回の話題に、まさに直接答えている一文ですね。運用場所やPortable/Mobileの明示についても案内しています。
🇪🇸 URE(スペイン)
スペインのURE公式サイト掲載のQSL解説「Tráfico de QSL」では、片面に写真やイラストを使用できるとしたうえで、もう一方の面に必要な情報をまとめるよう説明しています。
Nuestro indicativo: de forma visible y clara
「自局のコールサインは、明瞭で分かりやすく。」
しかも、受け取った相手が「誰からのカードなのか探し回らなくて済むように」という趣旨まで説明しています。今回の問題意識と、ほとんど同じです。😊
🇦🇹 ÖVSV(オーストリア)
オーストリアのÖVSV公式Wikiにある「QSL Karten Design」は、さらにストレートです。
Die QSL-Karte muss auf der Datenseite enthalten:
• Rufzeichen des Absenders
「QSLカードのデータ面には、発行者のコールサインを記載しなければならない。」
一方で、冒頭にはカードのデザインは基本的に各自の自由とも書かれています。これは同Wikiの記載指針であり、日本の局に適用される義務ではありません。
🇯🇵 JARL(日本)
JARLの「QSLカードの書き方」では、自局のコールサインを目立つように表示することや、QTH欄へのJCC/JCG番号・グリッドロケーター、OP欄への名前の記載などが案内されています。
ただし、この記載例は発行局のコールサインと交信データを同一面に集めたスタイルです。写真のデザイン面と交信データ面を分けた両面式カードに対し、同じ情報を重複記載する義務を定めたものではありません。
※上記は資料の内容を紹介したものです。ARRLの推奨文、URE掲載の解説、ÖVSVのWiki、JARLの記載例は、それぞれ文書の性格が異なります。海外で紹介されている方法が、そのままJA局への義務になるわけではありません。
💬 議論がすれ違っているのかも?
Xでの反応を読んでいると、「表でも裏でも、カード全体で確認できれば十分」という意見があります。もちろん、その通りです。私も、発行局のコールサインがデータ面にないだけで、QSLカードとして駄目だなどとは思いません。
一方で、「一度に大量のカードを受領して照合するので、データ面だけで確認できると助かる」という声もあります。こちらにも実務上の理由があります。
発行する人にとっては不便がなくても、受け取って整理する人には小さな手間が生じるかもしれない。「今まで問題にならなかった」ことと「もっと照合しやすくできる」ことは、矛盾しないんですよね。😊
⚠️ ここが一番大事。「強制」する話ではありません
受領者に対する配慮を提案することは、
書式の強制ではない。
私はデータ面に発行局のコールサインなどを記載することを、良い方法だと思っています。 でも、だからといって、他人のQSLカードの書式を強制的に変えさせるべきだとは思いません。
JARLの「交信証及び受信証の転送取扱規程」第2条は、交信証明欄に必要な交信データを記載するよう定めています。しかし、発行局のコールサインをデータ面にも重複して表示することまでは明記していません。
もちろん、交信日時や運用場所などの事実関係に誤りがあれば訂正すべきです。けれども、必要な情報がカード全体に正しく載っているのに、自分と違うレイアウトだからといって「矯正」しようとするのは、別の話でしょう。相手のカードを「直させる」ためではなく、こんな工夫もありますよ、と紹介するための記事です。
「義務ではない」≠「意味がない」
そして、「推奨する」≠「強制する」です。
発行する側が一度だけレイアウトを工夫することで、受け取る側の確認作業が少し楽になる。これは私だけの独自の思いつきではなく、海外の資料にも通じる考え方です。ただし、採用するかどうかは、それぞれの発行者の判断でよいと思います。
海外の資料は「こうすると良い」という考え方を説明する根拠にはなります。でも、それによって他人に守らせる権利が生まれるわけではありません。
📮 受け取る人の顔を思い浮かべて
紙QSLカードは、デザインを楽しむものでもあり、交信の記念として残すものでもあります。そこは自由でいいし、私もそう思います。
でも、カードは自分の手元に飾るためだけのものではなく、交信してくださった相手に届けるものでもあるんですよね。
だから私はこれからも、デザイン面は好きなように楽しみながら、データ面には自局コールサインのJP1LRT、交信時の運用地情報、オペレーター名を記載します。
誰かに義務付けたいわけではありません。ただ、こういう小さな工夫も、相手への配慮のひとつではないでしょうか。😊
強制ではなく、配慮。
QSLカードを受け取る相手のことを、少しだけ考えてみませんか?
73 de JP1LRT
※リンク先の資料は2026年10月14日に確認。引用の日本語訳は本記事によるものです。
言ってみるものですね(笑)――JARLコンテスト電子ログの「意見」が「意見・感想」に ― 2026年10月08日 22時03分43秒
「意見・感想」へ 📡
ちょっと嬉しい話です 😊
先日、JARLコンテストの電子ログサマリー作成ページにある 「意見」という欄について、 ひとつ提案をしてみました。
それなら、入力する側の電子ログサマリー作成ページも 「意見・感想」 にした方が、 「ここには感想を書いてもいいんだ」 と分かりやすいのではないか?
コンテスト終了後に書くことは、別に要望や苦情だけではありません。
☀️ 「コンディションが良かった」
📻 「久しぶりに参加しました」
😴 「さすがに眠かった(笑)」
💪 「来年はもっと頑張ります」
😭 「あと少し届かなかった、悔しい!」
そんな短い一言でも、後から結果を見る人にとっては、 その年のコンテストの雰囲気を伝える記録 になると思っています。
ところが入力欄に単に「意見」とだけ書かれていると、
「何か要望を書くところなのかな?」
「問題点や苦情を書く欄?」
と受け取る人もいるのではないか、と感じました。
📩 そこで、実際に提案してみました
今回、同じ趣旨で、
● CTESTWIN 作者
● zLog 作者
それぞれに提案を送ってみました。
作者の堀内さんから、
との回答をいただきました。
zLogでは、電子ログ形式がJARL推奨形式に準拠していることから、 欄名そのものを独自に変更することは見送る、という判断になりました。
ただし、提案の趣旨を受けて、
というガイド文を追加していただけることになりました 👍
JARLコンテスト係から連絡をいただきました。
「意見」
↓
「意見・感想」
VERSION=R2.1 で変更したとのことでした。
もちろん、これはものすごく大きな制度変更という話ではありません。
でも、こういうちょっとした改善によって、
と思う人が少しでも増えて、 結果発表ページに参加者の声がもっと残るようになれば、 それはそれで意味があると思います。
🏆 コンテストは、得点と順位だけではない
コンテストって、順位や得点だけではないんですよね。
うまくいったこと。
悔しかったこと。
楽しかったこと。
そして、疲れたこと(笑)
そういうものも含めて、 その年のコンテストの記録 だと思っています。
今後、コンテスト結果を見るときには、 「意見・感想」欄を読む楽しみが少し増えそうです 📡😊
JARLコンテスト係の皆様、
CTESTWIN作者の堀内さん、
zLogの皆様、
ありがとうございました。
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: From Rig Frequency Adjustment to Final Calibration ― 2026年09月29日 19時43分58秒
to Final Calibration
This article describes the complete workflow I currently use, including the practical use — and evaluation — of local AM broadcast carriers.
Accurate frequency calibration is particularly important for digital modes such as FT8, and even more so when operating on 50 MHz and above.
WSJT-X includes a very useful tool for this purpose: FreqCal.
A common way to think about FreqCal is:
That works, but I think FreqCal is even more useful if we use it one step earlier.
My preferred sequence is:
2. Use FreqCal to observe the current frequency error.
3. Adjust the radio's hardware reference frequency first, if the radio provides such an adjustment.
4. Once the hardware adjustment is finalized, start a fresh FreqCal measurement session.
5. Use several reliable calibration frequencies, including suitable local AM broadcast stations if available.
6. Inspect the collected data before calculating the final correction.
7. Solve for Slope and Intercept and apply the final software correction.
1. Let the radio stabilize first
Do not begin precision adjustment immediately after power-on.
The reference oscillator will normally drift as the radio warms up. In practical amateur use, 30 to 60 minutes may often be sufficient, but I do not consider a fixed number of minutes to be the real criterion.
A better approach is to use FreqCal itself: watch a stable reference signal and confirm that the measured offset has stopped moving consistently in one direction.
2. Use FreqCal to adjust the radio itself first
If your transceiver has an internal reference-frequency adjustment, I recommend correcting the radio itself before relying on software compensation.
On the IC-7300, for example, this is the REF Adjust setting. Other transceivers may use a different name.
Switch WSJT-X to FreqCal mode and receive a reliable reference signal.
During FreqCal operation, WSJT-X tunes the radio so that the reference carrier should appear at approximately 1500 Hz in the audio passband.
For the initial coarse adjustment, I prefer to use the highest reference frequency that can be received reliably at that time.
A reference-oscillator error expressed in ppm produces a larger absolute error in Hz as frequency increases.
Therefore, the higher-frequency reference usually gives greater sensitivity when making a coarse hardware adjustment.
Adjust the radio's reference until the measured carrier is as close as practical to the expected 1500 Hz position.
This is only the first step. Do not assume that a single frequency proves the radio is perfectly calibrated.
3. Check several frequencies
Once the rough REF adjustment is close, let FreqCal cycle through several reference frequencies.
With a modern synthesized transceiver, the remaining frequency error should approximately follow a straight-line relationship with frequency.
This multi-frequency check is important.
A radio may appear almost perfect at one frequency while still showing a residual frequency-dependent error across the band.
If necessary, make a final small adjustment to the radio's hardware reference, then leave it alone.
Changing REF Adjust changes the radio's actual frequency calibration state. Data measured before and after that adjustment therefore represent different radios, mathematically speaking.
Once the hardware adjustment is finalized:
Delete the previous
fmt.all and begin a completely new
FreqCal measurement session.
4. Start the final FreqCal measurement
Now the radio's hardware reference is fixed.
Enable Measure and let FreqCal run through the chosen calibration frequencies several times.
In current WSJT-X versions, existing Slope and Intercept correction values are automatically disabled while Measure is active.
Therefore, you do not need to manually set Slope and Intercept to zero before collecting new measurement data.
The measurement results are stored in:
5. Use suitable reference signals
Use only signals that are reliably receivable at your location.
It is not necessary to force every nominal calibration frequency into the measurement. Propagation conditions change, and some frequencies may be weak or unusable at a particular time.
The WSJT-X User Guide also notes that major-city AM broadcast stations can serve well as calibration signals at the low-frequency end of the spectrum.
I agree — they are very useful.
But there is an important practical point.
Do not copy my frequency list simply because it appears here.
Use strong, stable AM broadcast carriers available in your own area.
If you have several suitable AM stations, I think it is perfectly reasonable to include all of them initially.
Then collect several FreqCal cycles and look at the results.
Example from my station in Tokyo. The AM frequencies shown here are local examples only.
6. Before solving, inspect DF
This is the additional step I now recommend.
Before simply accepting all collected measurements, look at the reported DF values in frequency order.
After the radio's hardware reference has already been reasonably adjusted, the remaining frequency error should normally follow an approximately linear trend with frequency.
For example, if the residual error is increasing with frequency, a higher-frequency reference would generally be expected to continue along that same trend.
If one station at a higher frequency suddenly shows a distinctly smaller deviation than the lower-frequency stations, or otherwise reverses the overall trend, that point deserves closer examination.
Instead, treat it as a candidate for a sensitivity test: remove that station temporarily, recalculate the calibration parameters, and compare the result.
7. Recalculate with suspicious AM points removed
A practical procedure is:
2. Run several FreqCal cycles.
3. Remove obviously unreliable low-SNR measurements and other clear outliers.
4. Solve once using the complete data set.
5. Examine DF in frequency order.
6. If one AM station breaks the overall frequency-dependent trend, temporarily remove it from
fmt.all.7. Solve again.
8. Compare Slope, Intercept and StdDev.
9. If several stations appear questionable, test them individually and in combination.
8. What do Slope, Intercept and StdDev mean?
Slope
Slope is the frequency-dependent part of the error, expressed in ppm.
A smaller absolute Slope means that less residual error grows with frequency.
Intercept
Intercept is the fitted error at 0 MHz, expressed in Hz.
It is not an actual measurement at 0 MHz. It is the intercept obtained by extending the fitted straight line.
StdDev
WSJT-X defines StdDev here as the root mean square deviation of the averaged measurements from the fitted straight line.
In practical terms:
| StdDev | Meaning |
|---|---|
| Larger | The measured points are more widely scattered around the fitted line |
| Smaller | The measured points agree more closely with a single straight-line model |
It tells us how well the selected measurements agree with the fitted model. The reference signals themselves must still be credible.
9. What happened in my Tokyo measurement
At my location, two AM frequencies appeared inconsistent with the overall trend:
- 594 kHz
- 1422 kHz
I therefore compared four calibration data sets.
| Data set | Slope | Intercept | StdDev |
|---|---|---|---|
| All data | +0.029 ppm | -0.33 Hz | 0.32 Hz |
| 1422 kHz removed | +0.019 ppm | -0.18 Hz | 0.25 Hz |
| 594 kHz removed | +0.021 ppm | -0.22 Hz | 0.30 Hz |
| 594 + 1422 kHz removed | +0.004 ppm | +0.05 Hz | 0.08 Hz |
Removing both AM frequencies produced a much tighter fit to the remaining calibration data.
The final solution I adopted was:
Intercept +0.05 ±0.01 Hz
N 123
StdDev 0.08 Hz
Possible causes include the actual carrier offset, propagation effects, short-term variation, S/N, fading, receiver effects, and measurement uncertainty.
The justified conclusion is simply:
under my measurement conditions, those two signals were less consistent with the overall calibration trend than the other reference signals.
10. Apply and verify
Once you are satisfied with the data selection and the calculated fit, use Apply to set the resulting Slope and Intercept in WSJT-X.
Then clear Measure and run FreqCal again.
With Measure off, the calibration correction is active, so this gives a useful visual check of the final result.
If you use JTDX with the same radio and the same CAT frequency reference, the same calibration parameters can also be used there.
Adjust the radio's hardware reference first if possible.
After the hardware adjustment is finalized, delete the old
fmt.all and start fresh.
Use several reliable reference frequencies.
As recommended in the WSJT-X User Guide, local AM broadcast carriers can be useful at the low-frequency end.
If several local AM stations are available, it is reasonable to include them all initially.
Then inspect DF and look for stations that do not follow the overall frequency-dependent trend.
Temporarily remove suspicious points, solve again, and compare Slope, Intercept and StdDev.
Do not remove data simply to make the numbers look better — use the recalculation as a consistency test.
FreqCal is much more interesting when used this way.
It is not only a frequency-correction function. It is also a useful tool for understanding the complete frequency behavior of the radio and the reference signals being used to calibrate it.
https://wsjt.sourceforge.io/wsjtx-main_en.html
WSJT-X Frequency Measurement Tools
https://wsjt.sourceforge.io/FMT_User.pdf
Related Japanese article
https://jp1lrt.asablo.jp/blog/2026/09/29/9879123
Tokyo, Japan
September 29, 2026
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
WSJT-X 3.2.0-rc1公開、そしてWSJT-X Improvedは「WS Suite」へ ― デジタルモード界隈の大きな転換点 ― 2026年09月25日 01時03分42秒
アマチュア無線のデジタルモード界隈で、ほぼ同じタイミングに大きなニュースが2つ続きました。📻
そしてもうひとつは、WSJT-X Improved がその名前を終え、「WS - Digital Mode Suite」へ移行したことです。
同じ「3.2」というタイミングで、それぞれの開発方向がかなりはっきり見えるようになってきました。
📘 WSJT-X v3.2.0-rc1 公開
Joe K1JT から、Release Candidate WSJT-X v3.2.0-rc1 が公開されたとの正式アナウンスがありました。
今回の大きな目玉は、新しいデジタルモード
JTTY
の追加です。
そのほかにも、 Q65、MAP65、QMAP に新機能が加えられ、多数の改善やバグ修正が行われています。
新しい WSJT-X 3.2 User Guide はこちら。
新機能の概要はこちら。
3.0.2以降の詳しい変更履歴はこちらです。
🎧 JTTY の暫定運用周波数
Joeたちは、まず20mで
14.090 MHz
を最初の共通集合場所として提案しています。
さらに、現時点での非常に暫定的な候補として、次の周波数が示されています。
| Band | JTTY Dial Frequency |
|---|---|
| 160m | 1838 kHz |
| 80m | 3575 kHz |
| 40m | 7090 kHz |
| 30m | 10140 kHz |
| 20m | 14090 kHz |
| 17m | 18100 kHz |
| 15m | 21090 kHz |
| 12m | 24920 kHz |
| 10m | 28090 kHz |
| 6m | 50160 kHz |
| 2m | 144160 kHz |
Joe自身がこれらを “very preliminary!” と強調しています。
JTTYが普及していけば、今後一部または全部の周波数が変更される可能性があります。
⚙ Frequencies の「Reset」にも注意
Settings | Frequencies の周波数テーブルを右クリックして Reset を選ぶと、多くのJTTY周波数がデフォルト周波数リストへ追加されます。
ただしJoeからも注意があります。
そして開発チームは、
“We will be working toward an early GA release of WSJT-X 3.2.0.”
としており、比較的早い時期のGA版リリースを目指しているようです。
WSJT-Xの公開ソースコードはこちら。
💻 https://github.com/WSJTX/wsjtx
🚀 WSJT-X Improved は「WS Suite」へ
一方、Uwe DG2YCB からも非常に大きな発表がありました。
これまで長く使われてきた
WSJT-X Improved
という名称を終了し、新たに
通称 WS / WS Suite
としてスタートします。
Uweによれば、WSJT-X本家との混同を避けることに加え、この新しい名称によって 開発チームとしてより自由に活動できるという意味もあるとのこと。
これは単なるロゴや名前の変更というより、これまでのImproved系をひとつの独自ソフトウェア・スイートとして整理していく動きと見てよさそうです。
📥 WS Suite 3.2.0 Download Page
🧩 WS Suite は3つのプログラムで構成
メインプログラム。
FT8 / FT4 / FT2 / JT4 / JT9 / JT65 / Q65 / FST4 / MSK144 / WSPR / FST4W / Echo に対応。
従来の QMAP Improved PLUS。
現在は主としてEME向けのwideband Q65 monitorですが、将来的にはSDRを利用した、より一般的なwideband receiverへの発展も計画されています。
従来の MAP65 Improved PLUS。
JT65/Q65を使ったEME向けwideband softwareです。
🎥 Uweによる解説動画
Uwe自身が、今回のWS SuiteについてYouTubeで解説しています。
🇬🇧 WS Suite Introduction - English
🇩🇪 WS Suite Introduction - German
英語版についてはYouTube側で、German / French / Hindi / Indonesian / Italian / Portuguese / Spanishなどの追加音声トラックも用意されています。
🔑 「Improvedの続き」であることが重要
Uweは次のように明記しています。
つまり、新しくゼロから作られた別ソフトという意味ではなく、
WSJT-X Improved 3.2 → WS Suite
と、その開発系譜をそのまま引き継いでいく形です。
🌐 多言語対応も強化
WS 3.2では言語関係も大きく変わりました。
- German / Frenchなど対応言語を追加
- GUIのLanguageメニューから直接言語切替可能
- 従来の
--language=XY起動オプションが不要 - 選択した言語に応じたUser Guideを表示
興味深いのは、今回不足していた翻訳文字列を AIを使って補完した とUweが明記していることです。
そして、
との呼びかけもされています。
💾 移行についてもかなり配慮
初回起動時には従来のWSJT-X / WSJT-X Improvedから、
- ログブック
- 各種設定
- CALL3.TXT
- comments.txt
- ignore.list
などが新環境へ自動的に引き継がれます。
さらに、
WS Suite と本家 WSJT-X は並行インストール・並行運用可能
とされています。
UDPについても WSJT-X Compatibility Mode が用意され、 GridTracker、JTSync、各種loggerなどでテスト済みとのこと。
さらにLaurie VK3AMAからは、早くもWS Suite対応版 JTAlertが公開されています。
🤔 同じ「3.2」で見えてきた2つの方向
個人的に非常に興味深く感じるのは、ほぼ同じ時期に両者が「3.2」へ進んだことです。
| WSJT-X | WS Suite |
|---|---|
|
WSJT-X 3.2.0-rc1 Joe K1JTらによる本家。 JTTYを新たに導入し、Q65 / MAP65 / QMAPなども発展。 |
WS Suite 3.2.0 Uwe DG2YCBらによるImproved系の後継。 独自ブランドとして新しい段階へ。 |
もちろんルーツをたどれば同じWSJT-X系ですが、今後はそれぞれの開発思想や方向性の違いも、これまで以上に分かりやすくなっていくのかもしれません。
ただ、今すぐどちらかへ飛びつくというより、WSJT-X本家3.2系と、新しくスタートしたWS Suite 3.2系、それぞれが今後どう発展していくのかをじっくり追っていきたいと思っています。
🔗 関連リンク
- WSJT-X Releases
- WSJT-X GitHub Repository
- WSJT-X 3.2 User Guide
- WSJT-X 3.2 New Features
- WSJT-X Release Notes
- WS Suite 3.2.0 Download Page
- WS Suite - Uwe DG2YCB English Video
- WS Suite - Uwe DG2YCB German Video
- JTAlert / HamApps
📻✨ アマチュア無線のデジタルモード界隈、また面白くなってきました。
73
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への非常に良い協力になると思います。







最近のコメント