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の明示についても案内しています。

🔗 ARRL公式資料(PDF・21ページ)

🇪🇸 URE(スペイン)

スペインのURE公式サイト掲載のQSL解説「Tráfico de QSL」では、片面に写真やイラストを使用できるとしたうえで、もう一方の面に必要な情報をまとめるよう説明しています。

Nuestro indicativo: de forma visible y clara

「自局のコールサインは、明瞭で分かりやすく。」

しかも、受け取った相手が「誰からのカードなのか探し回らなくて済むように」という趣旨まで説明しています。今回の問題意識と、ほとんど同じです。😊

🔗 URE公式サイト掲載「Tráfico de QSL」

🇦🇹 ÖVSV(オーストリア)

オーストリアのÖVSV公式Wikiにある「QSL Karten Design」は、さらにストレートです。

Die QSL-Karte muss auf der Datenseite enthalten:
• Rufzeichen des Absenders

「QSLカードのデータ面には、発行者のコールサインを記載しなければならない。」

一方で、冒頭にはカードのデザインは基本的に各自の自由とも書かれています。これは同Wikiの記載指針であり、日本の局に適用される義務ではありません。

🔗 ÖVSV公式Wiki「QSL Karten Design」

🇯🇵 JARL(日本)

JARLの「QSLカードの書き方」では、自局のコールサインを目立つように表示することや、QTH欄へのJCC/JCG番号・グリッドロケーター、OP欄への名前の記載などが案内されています。

ただし、この記載例は発行局のコールサインと交信データを同一面に集めたスタイルです。写真のデザイン面と交信データ面を分けた両面式カードに対し、同じ情報を重複記載する義務を定めたものではありません。

🔗 JARL公式「QSLカードの書き方」

※上記は資料の内容を紹介したものです。ARRLの推奨文、URE掲載の解説、ÖVSVのWiki、JARLの記載例は、それぞれ文書の性格が異なります。海外で紹介されている方法が、そのままJA局への義務になるわけではありません。

💬 議論がすれ違っているのかも?

Xでの反応を読んでいると、「表でも裏でも、カード全体で確認できれば十分」という意見があります。もちろん、その通りです。私も、発行局のコールサインがデータ面にないだけで、QSLカードとして駄目だなどとは思いません。

一方で、「一度に大量のカードを受領して照合するので、データ面だけで確認できると助かる」という声もあります。こちらにも実務上の理由があります。

発行する人にとっては不便がなくても、受け取って整理する人には小さな手間が生じるかもしれない。「今まで問題にならなかった」ことと「もっと照合しやすくできる」ことは、矛盾しないんですよね。😊

⚠️ ここが一番大事。「強制」する話ではありません

受領者に対する配慮を提案することは、
書式の強制ではない。

私はデータ面に発行局のコールサインなどを記載することを、良い方法だと思っています。 でも、だからといって、他人のQSLカードの書式を強制的に変えさせるべきだとは思いません。

JARLの「交信証及び受信証の転送取扱規程」第2条は、交信証明欄に必要な交信データを記載するよう定めています。しかし、発行局のコールサインをデータ面にも重複して表示することまでは明記していません。

🔗 JARL「交信証及び受信証の転送取扱規程」(PDF)

もちろん、交信日時や運用場所などの事実関係に誤りがあれば訂正すべきです。けれども、必要な情報がカード全体に正しく載っているのに、自分と違うレイアウトだからといって「矯正」しようとするのは、別の話でしょう。相手のカードを「直させる」ためではなく、こんな工夫もありますよ、と紹介するための記事です。

「義務ではない」≠「意味がない」

そして、「推奨する」≠「強制する」です。

発行する側が一度だけレイアウトを工夫することで、受け取る側の確認作業が少し楽になる。これは私だけの独自の思いつきではなく、海外の資料にも通じる考え方です。ただし、採用するかどうかは、それぞれの発行者の判断でよいと思います。

海外の資料は「こうすると良い」という考え方を説明する根拠にはなります。でも、それによって他人に守らせる権利が生まれるわけではありません。

📮 受け取る人の顔を思い浮かべて

紙QSLカードは、デザインを楽しむものでもあり、交信の記念として残すものでもあります。そこは自由でいいし、私もそう思います。

でも、カードは自分の手元に飾るためだけのものではなく、交信してくださった相手に届けるものでもあるんですよね。

だから私はこれからも、デザイン面は好きなように楽しみながら、データ面には自局コールサインのJP1LRT、交信時の運用地情報、オペレーター名を記載します。

誰かに義務付けたいわけではありません。ただ、こういう小さな工夫も、相手への配慮のひとつではないでしょうか。😊

強制ではなく、配慮。

QSLカードを受け取る相手のことを、少しだけ考えてみませんか?

73 de JP1LRT

※リンク先の資料は2026年10月14日に確認。引用の日本語訳は本記事によるものです。

言ってみるものですね(笑)――JARLコンテスト電子ログの「意見」が「意見・感想」に ― 2026年10月08日 22時03分43秒

JARL CONTEST / ELECTRONIC LOG
「意見」から
「意見・感想」へ 📡
ちょっとした提案でしたが、実際にJARLの電子ログサマリー作成ページが変更されました。

ちょっと嬉しい話です 😊

先日、JARLコンテストの電子ログサマリー作成ページにある 「意見」という欄について、 ひとつ提案をしてみました。

💡 私が気になったこと
結果発表ページではすでに 「意見・感想」 と表示されています。

それなら、入力する側の電子ログサマリー作成ページも 「意見・感想」 にした方が、 「ここには感想を書いてもいいんだ」 と分かりやすいのではないか?

コンテスト終了後に書くことは、別に要望や苦情だけではありません。

😊 「楽しかった」
☀️ 「コンディションが良かった」
📻 「久しぶりに参加しました」
😴 「さすがに眠かった(笑)」
💪 「来年はもっと頑張ります」
😭 「あと少し届かなかった、悔しい!」

そんな短い一言でも、後から結果を見る人にとっては、 その年のコンテストの雰囲気を伝える記録 になると思っています。

ところが入力欄に単に「意見」とだけ書かれていると、

「何か要望を書くところなのかな?」
「問題点や苦情を書く欄?」

と受け取る人もいるのではないか、と感じました。

📩 そこで、実際に提案してみました

今回、同じ趣旨で、

● JARLコンテスト委員会
● CTESTWIN 作者
● zLog 作者

それぞれに提案を送ってみました。

✅ CTESTWIN

作者の堀内さんから、

「次のバージョンにてご提案通り修正いたします。」

との回答をいただきました。

✅ zLog

zLogでは、電子ログ形式がJARL推奨形式に準拠していることから、 欄名そのものを独自に変更することは見送る、という判断になりました。

ただし、提案の趣旨を受けて、

「感想や意見を入力してください」

というガイド文を追加していただけることになりました 👍

🎉 そしてJARL本体も変更

JARLコンテスト係から連絡をいただきました。

電子ログサマリー作成ページ

「意見」
↓
「意見・感想」

VERSION=R2.1 で変更したとのことでした。

👻 いやー、言ってみるものですね(笑)

もちろん、これはものすごく大きな制度変更という話ではありません。

でも、こういうちょっとした改善によって、

「あ、ここには感想を書いていいんだ」

と思う人が少しでも増えて、 結果発表ページに参加者の声がもっと残るようになれば、 それはそれで意味があると思います。

🏆 コンテストは、得点と順位だけではない

コンテストって、順位や得点だけではないんですよね。

その時のコンディション。
うまくいったこと。
悔しかったこと。
楽しかったこと。
そして、疲れたこと(笑)

そういうものも含めて、 その年のコンテストの記録 だと思っています。

今後、コンテスト結果を見るときには、 「意見・感想」欄を読む楽しみが少し増えそうです 📡😊

🙏 ご対応ありがとうございました
今回の提案を受け止めて対応してくださった、

JARLコンテスト係の皆様、
CTESTWIN作者の堀内さん、
zLogの皆様、

ありがとうございました。
JP1LRT

2026年 第56回 6m AND DOWN コンテストの結果が発表されました ― 2026年10月06日 19時53分18秒

JARL CONTEST / 6m AND DOWN / COMMENTS MATTER
2026 6m AND DOWN コンテスト結果発表
そして「意見・感想」欄について思うこと
第56回 6m AND DOWN コンテストの結果が発表されました。
スコアを見るのはもちろん楽しいのですが、個人的にはもうひとつ、 ぜひ多くの参加局に意識してほしい欄があります。

それが、サマリーシートの「意見・感想」欄です。

2026年 第56回 6m AND DOWN コンテストの結果が発表されました。

参加された各局、お疲れさまでした。

今年も、50MHzを中心に各部門で熱い戦いがありました。

50MHzは、やはり「場所」と「腕」と「執念」の勝負

50MHz関係で見ると、 X50、つまり電信電話部門シングルオペ50MHzバンド は JM1TDG/6 が全国1位。

宮古島からの参加で、見事に2連覇とのことです。

宮古島からの50MHz。
南西諸島から参加する50MHzは、やはり強いです。
もちろん、場所が良いだけで勝てるわけではありません。
その場所を生かし切る運用力があってこそ、全国1位になるわけです。

一方、 C50、つまり電信部門シングルオペ50MHzバンド は JI1ACI が全国1位。

こちらはもう、 「不動の位置」 という感じです。

毎年のように安定して強い局というのは、本当にすごいと思います。

結果ページを見ていて、少し気になったこと

さて、今回の結果ページを見ていて、ひとつ気になったことがあります。

それは、 「意見・感想」の提出が、書類提出局数に比べてかなり少ない ということです。

もちろん、ログを提出するだけでも十分です。
コンテストに参加して、ログを整理して、期限内に提出する。
これだけでも、立派な参加記録です。

でも、せっかく参加したなら、サマリーシートの 「意見・感想」欄 にも、ぜひ何か一言残してほしいなと思います。

たとえば、こんな一言で十分です
・楽しかったです。
・今年はコンディションが良かったです。
・短時間でしたが参加できました。
・移動運用で参加しました。
・交信いただいた各局ありがとうございました。
・次回も参加したいと思います。
・集計ありがとうございます。

本当に、この程度で良いと思います。

長文である必要はありません。
名文である必要もありません。
技術的考察である必要もありません。

その年、その時、そのコンテストに参加した人の一言が残るだけで、 あとから見返した時の面白さがかなり変わります。

ただし、ログソフトの表示が少し分かりにくい

ここで少しややこしいのが、ログソフト側の表示です。

たとえば、zLogではこの欄が 「意見」 と表示されています。

zLog

CTESTWINでも、やはり 「意見」 と表示されています。

CTESTWIN

この「意見」という表記、少し構えてしまう人もいるかもしれません。

「何か要望を書かなければいけないのかな?」
「規約への意見を書かないといけないのかな?」
「苦情や改善提案を書く欄なのかな?」

そう思って、空欄のまま提出している人もいるのではないでしょうか。

ここ、もっと気楽に考えて良いと思います。
JARLの結果ページでは、この欄は 「意見、感想」 として掲載されています。

つまり、ここには 「意見」ではなく「感想」を書いて良い のです。

「感想」で良い。むしろ感想が読みたい。

たとえば、

  • 今年はEスポに助けられました。
  • 移動地は雨でした。
  • 暑くて大変でした。
  • 短時間参加でしたが楽しめました。
  • 初めて6Dに参加しました。
  • 久しぶりに50MHzで楽しめました。
  • アンテナの調子が悪くて伸びませんでした。
  • 来年はもう少し準備して参加したいです。

こういう一言で良いのです。

結果表には、QSO数、マルチ、得点、順位が残ります。
でも、それだけでは分からないことがあります。

スコア表には出ない情報。

その年の空気。
コンディションの印象。
移動運用地の様子。
参加者の疲労感。
初参加のうれしさ。
伸びなかった悔しさ。
それでも参加した楽しさ。

そういうものは、各局の「感想」によって残ります。

数年後に結果ページを見返した時、 「ああ、この年は50MHzが長時間開けたのか」 とか、 「この年は移動運用が雨で大変だったのか」 とか、 「この頃はこういう局が頑張っていたのか」 ということが分かる。

これは、単なるスコア表とは別の価値だと思います。

ログ提出時に、ぜひ一言

というわけで、次回以降コンテストログを提出する時は、 ぜひ「意見・感想」欄にも一言書いてみてはいかがでしょうか。

SUMMARY SHEET COMMENT
今年も楽しめました。
交信いただいた各局ありがとうございました。
次回も参加したいと思います。

これだけで良いと思います。

コメント欄が増えれば、結果ページはもっと面白くなります。
コンテストの記録は、スコアだけでなく、参加者の声も含めて残っていくものだと思います。

参加した記録を、数字だけでなく、言葉でも少し残していきましょう。

まとめ
6m AND DOWN コンテストの結果が発表されました。

X50は JM1TDG/6 が宮古島からの参加で2連覇。
C50は JI1ACI が不動の強さ。

そして、ログ提出時の「意見」欄には、 意見だけでなく感想を書いて良いのです。

ぜひ、次回は一言。
スコアと一緒に、その年の思い出も残しましょう。

73

WSJT-X FreqCal: From Rig Frequency Adjustment to Final Calibration ― 2026年09月29日 19時43分58秒

WSJT-X / FreqCal / PRACTICAL FREQUENCY CALIBRATION
From Rig Frequency Adjustment
to Final Calibration
FreqCal is not only a tool for calculating Slope and Intercept. It can also be used as a very useful measurement tool when adjusting the reference frequency of the radio itself.

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:

Measure several known frequencies → calculate Slope and Intercept → Apply.

That works, but I think FreqCal is even more useful if we use it one step earlier.

My preferred sequence is:

1. Warm up the radio.

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.

The important criterion is stability, not the clock.

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.

Why the highest reliable frequency?

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.

Dial error = Intercept + Slope × f
f = frequency in MHz

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.

Important: delete the old fmt.all after changing REF Adjust
Measurements made with different hardware reference settings must not be mixed in the final calibration fit.

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:

fmt.all

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.

Use your own local AM stations
The AM frequencies discussed below are examples from my location in Tokyo, Japan.

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.

WSJT-X FreqCal measurement example

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.

Do not immediately assume the station is wrong.

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:

1. Start with all reliable local AM stations included.

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
A small StdDev does not, by itself, prove absolute frequency accuracy.

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
StdDev: 0.32 Hz → 0.08 Hz

Removing both AM frequencies produced a much tighter fit to the remaining calibration data.

The final solution I adopted was:

FINAL CALIBRATION
Slope      +0.004 ±0.001 ppm
Intercept  +0.05 ±0.01 Hz
N         123
StdDev     0.08 Hz
What this does NOT mean
This result does not prove that the transmitters on 594 kHz or 1422 kHz were improperly adjusted.

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.

Summary
Use FreqCal first as a measurement instrument, not merely as a software correction calculator.

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.

References
WSJT-X User Guide — Frequency Calibration
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
JP1LRT
Tokyo, Japan
September 29, 2026

WSJT-X FreqCalの較正点を検証する ― 594 / 1422 kHzを除外するとStdDev 0.08 Hz ― 2026年09月29日 14時53分24秒

WSJT-X / FreqCal / ACTUAL MEASUREMENT
594 / 1422 kHzを除外すると
StdDev 0.08 Hzになった
WSJT-XのFreqCalで周波数較正を実施していたところ、 中波AM放送局の一部が他の較正点と整合しないことに気付きました。

そこで594 kHzと1422 kHzを 「残す/除外する」の4条件で実際に較正パラメータを比較してみました。

昨日から、 WSJT-XのFreqCalを使って、 IC-7300の基準周波数を改めて調整しています。

リグ本体のREF Adjust調整から、 FreqCalを使った最終的なSlope / Interceptの算出までの手順は、 こちらの記事にまとめました。

今回の測定では、 リグ本体のREF Adjustを確定した後、 それ以前に取得したfmt.allを一度削除。

その後はREF Adjustを固定したまま、 FreqCalを数巡させて測定データを蓄積しました。

また、 低S/Nのため行末に*が付いた測定値は除外しています。

ところが、中波帯を見ていて気になる点が
954 kHz、1242 kHzなどは、 全体の周波数依存の傾向に比較的きれいに乗っているのに対し、 594 kHzと1422 kHzは別方向へ外れているように見えました。

そこで、 この2局を較正データに含めるかどうかで 結果がどの程度変化するのか、 4条件で比較してみることにしました。

その前に ― Slope / Intercept / StdDevとは?

WSJT-Xで 「ツール」→「較正パラメータ計算」 を実行すると、 次のような値が表示されます。

  • Slope
  • Intercept
  • N
  • StdDev

何を意味しているのかを簡単に整理します。

Dial error = Intercept + Slope × f
Dial error = 周波数誤差 [Hz]
f = 周波数 [MHz]

Slope(スロープ)

周波数が高くなるにつれて増減する誤差成分を表します。 単位はppmです。

例えば、 Slopeが +0.004 ppm なら、 周波数依存成分だけを見ると、 50 MHzでは、

0.004 × 50 = 0.20 Hz

となります。

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は、 もう少し具体的な意味を持っています。

WSJT-X User Guideでは、 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 ±0.001 ppm

なら、 今回の直線近似から求められたSlopeが +0.004 ppmで、 その推定不確かさが0.001 ppmという意味です。

① 全周波数を使用

全周波数
Slope: +0.029 ±0.003 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だけを除外

1422削除
Slope: +0.019 ±0.003 ppm
Intercept: -0.18 ±0.03 Hz
N: 146
StdDev: 0.25 Hz

1422 kHzだけを除外すると、 StdDevは、

0.32 Hz → 0.25 Hz

へ改善しました。

1422 kHzの測定点が 今回の近似直線との整合性をかなり悪化させていることが分かります。

③ 594 kHzだけを除外

594削除
Slope: +0.021 ±0.003 ppm
Intercept: -0.22 ±0.04 Hz
N: 147
StdDev: 0.30 Hz

今度は逆に、 594 kHzだけを除外しました。

StdDevは、

0.32 Hz → 0.30 Hz

です。

594 kHzも影響していますが、 今回のデータでは 1422 kHzの方がより強く近似結果を崩しているようです。

④ 594 / 1422 kHzを両方除外

594/1422削除
Slope: +0.004 ±0.001 ppm
Intercept: +0.05 ±0.01 Hz
N: 123
StdDev: 0.08 Hz

最後に、 594 kHzと1422 kHzを 両方とも除外しました。

すると、 StdDevが一気に、

0.32 Hz → 0.08 Hz

まで低下しました。

さらにSlopeも、

+0.029 ppm → +0.004 ppm

となり、 ほぼゼロに近づきました。

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局の送信周波数がずれている」 と断定することはできません。

送信側の周波数偏差、 伝搬経路による周波数変動、 受信条件、 その他の要因が含まれる可能性があります。

今回確認できた事実は、 この測定条件では、 594 kHzと1422 kHzを較正点として含めない方が、 他の測定点との整合性が大幅に向上した ということです。

AM放送局をFreqCalに使う時の注意

WSJT-XのUser Guideでも、 大都市圏のAM放送局は 低い周波数側のFreqCal用基準として利用できると紹介されています。

実際、 AM局は強力かつ常時受信できることが多く、 非常に便利です。

ただし今回の測定からも分かるように、

公称周波数だからといって、 サブHz精度の絶対基準として無条件に採用しない
複数のAM放送局と、 5 / 10 / 15 / 20 MHzなどの 他の基準信号を比較し、

全体の傾向から明らかに外れていないか を見ることが重要です。

特に今回のように、 0.1 Hz単位まで見始めると、 「無線機の誤差」だけではなく、 基準として使っている信号側の差まで 見えてくる可能性があります。

今回採用した最終値

以上の比較から、 今回は594 kHzと1422 kHzを 較正点から除外した結果を採用しました。

FINAL CALIBRATION
Slope      +0.004 ±0.001 ppm
Intercept  +0.05 ±0.01 Hz
N         123
StdDev     0.08 Hz

この較正式を50 MHzに当てはめると、

0.05 + 0.004 × 50
= 約0.25 Hz

となります。

もちろん、 これはGPSDOや高精度周波数カウンターを使用した 研究所レベルの絶対周波数校正ではありません。

電離層伝搬、 フェージング、 Doppler、 受信機内部温度などの影響も存在します。

それでも、 通常のアマチュア無線局で、 特別な測定器を使わず、 この程度まで追い込めれば、 FT8などの実運用上は十分だと思います。

今回の教訓
・FreqCalでは、 *付きの低S/Nデータだけを見ればよいわけではない。

・測定値が正常に見えても、 較正点そのものが他の周波数と整合しているか確認する。

・Slopeは周波数依存の誤差。

・Interceptは直線近似の固定オフセット成分。

・StdDevは、 各測定点が近似直線からどの程度散らばっているかを見る指標。

・今回の測定では、 594 / 1422 kHzを除外することで StdDevが0.32 Hzから0.08 Hzへ改善。

・最終的に Slope +0.004 ppm、 Intercept +0.05 Hz を採用した。

FreqCalは、 単に 「無線機の周波数を合わせる機能」 として使うだけでも便利ですが、

こうして測定値を比較していくと、 リグ、 伝搬、 基準信号、 直線近似の関係まで見えてくる ので、 なかなか面白いツールです。

JP1LRT
2026年9月29日

WSJT-X FreqCalでリグの周波数を本気で合わせる ― IC-7300 / FT-991Aの基準周波数調整からJTDXまで【2026年版】 ― 2026年09月28日 19時47分05秒

WSJT-X FreqCal / FREQUENCY CALIBRATION / 2026 UPDATE
FT8のDF、本当に同じ周波数を見ていますか?
WSJT-XのFreqCalを使えば、 周波数の正確な基準信号を利用して、 リグの周波数誤差をかなり細かく確認できます。

さらにIC-7300やFT-991 / FT-991Aのように 基準周波数を調整できるリグなら、 まずリグ本体をできるだけ正しく合わせ、 その後に残ったわずかな誤差だけを WSJT-X / JTDXで補正することができます。

FT8などを運用していると、 「○○局はDF 850付近に出ています」 といった情報交換をすることがあります。

ところが同じ局を受信しているはずなのに、 局によって表示されるDFが数Hz、 場合によってはそれ以上違っていることがあります。

原因の一つが、 無線機の基準周波数の誤差です。

特に50 MHzでは無視しにくい
基準発振器が1 ppmずれていれば、 10 MHzでは約10 Hz、 20 MHzでは約20 Hz、 50 MHzでは約50 Hzの誤差になります。

HFではあまり気にならなかったわずかなppm誤差も、 6mではかなり目立ってきます。

私はこれまで、

という記事を書いてきました。

今回は2026年9月にもう一度実際に測定し直しながら、 現在のWSJT-Xの仕様と実測で分かった点を含めて、 手順を最初から整理し直します。

今回の考え方 ― FreqCalを二段階で使う

STEP 1
リグ本体を調整
FreqCalとワイドグラフを、 リグの周波数誤差を見る測定器 として使います。
STEP 2
残った誤差をソフトで補正
本体調整後にFreqCalを改めて取り直し、 スロープ/インターセプト を求めます。
まずリグそのものをできるだけ正しくする。
その後で、残ったわずかな誤差だけを ソフトウェアで補正する。

最初に重要 ― 十分にウォームアップする

周波数調整は、 電源を入れてすぐに行ってはいけません。

リグ内部の基準発振器は温度の影響を受けます。 電源投入直後は内部温度が変化しているため、 その状態でぴったり合わせても、 温まった後には再びずれてしまう可能性があります。

「30分」「1時間」という数字そのものより、 ドリフトが落ち着いたことが重要
実用上は少なくとも30分程度、 できれば1時間程度動作させてから始めるのがよいと思います。

ただし、本当の判断基準は時間ではありません。 FreqCalで同じ基準信号をしばらく観測し、 ワイドグラフ上の位置が時間とともに 一方向へ動き続けなくなったことを確認します。

私は以前の記事では2時間程度ウォームアップしてから行った例も紹介していますが、 今回の再測定では約30分観測し、 基準信号の位置がほぼ安定したことを確認してから調整を開始しました。

どの周波数を使うか

FreqCalには、 周波数が分かっている安定したキャリア信号を使います。

日本であれば、 地元の中波AM放送局や、 5 MHz、10 MHz、15 MHz、20 MHzなどを利用できます。

全部受信できる必要はありません
15 MHzや20 MHzは時間帯や電離層の状態によって、 十分なS/Nで受信できないことがあります。

例えば20 MHzが良好なら20 MHz、 20 MHzが使えず15 MHzが良好なら15 MHz。

その時点で安定して測定できる周波数だけを使えばよい ということです。

今回の測定でも、 ある時間帯の15 MHzはS/Nが低く、 測定値が大きくばらついていました。 一方で20 MHzは非常に安定して受信できていました。

逆のことが起きる日も当然あります。

STEP 1 ― まずリグ本体を合わせる

1.FreqCalにする

WSJT-Xのメニューから、

「モード」→ FreqCal

を選びます。

2.使用する周波数を確認する

「ファイル」→「設定」→「周波数」

へ進み、 「運用周波数」の中からFreqCal用の周波数を確認します。

必要に応じて、 受信可能な地元AM放送局などを追加します。

3.「測定」をONにする

メイン画面の「測定」にチェックを入れます。

旧記事からの重要な変更点
現行WSJT-Xでは、 「測定」中は設定済みの周波数較正補正が無効になります。

したがって、 以前の記事で行っていたように、 測定前にスロープ/インターセプトを 手作業で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付近に現れます。

調整前 ― 周波数が高くなるほどズレる

FreqCal 調整前

2021年の測定例。 受信周波数が高くなるにつれ、 1500 Hzからのズレが大きくなっています。

この状態は非常に分かりやすい例です。

低い周波数では1500 Hz付近に見えていても、 周波数を上げるにつれて 中央からのズレが大きくなっています。

基準発振器そのものにppm単位の誤差があると、 このように誤差が周波数に比例して大きくなります。

一つの周波数だけを見て 「合った」と判断しないこと。

複数の周波数を見て、 周波数が高くなるにつれて 一方向へズレが増えていく傾向 を確認することが重要です。

6.リグ本体の基準周波数を微調整する

IC-7300なら、 REF Adjustを少しずつ動かします。

IC-7300 REF Adjust

IC-7300のREF Adjust。 画像は2021年当時のものです。

ここでの目標は、 一つの周波数だけを1500 Hzへ合わせることではありません。

調整の目標
5 MHz、10 MHz、15 MHz、20 MHzなどを見た時に、 周波数が高くなるほど 1500 Hzからのズレが増える傾向を できるだけ小さくすることです。

後でWSJT-Xが数値として求める 「スロープ」を、 この段階ではREF Adjustによって リグ本体側でできるだけ小さくしている、 と考えると分かりやすいでしょう。

7.周波数を変えても1500 Hz付近に集まることを確認

FreqCal 基準周波数調整後

基準周波数調整後。 各周波数で基準信号が概ね1500 Hz付近へ集まっています。

このように、 周波数を切り替えても 基準信号が概ね1500 Hz付近へ集まるようになれば、 リグ本体の調整はほぼ終了です。

完全に一本の線へ重なる必要はありません。

実際の受信信号には、 電離層伝搬による周波数変動、 フェージング、 マルチパス、 S/N、 リグ内部温度の微小変化なども影響します。

基準信号側も盲信しない

地元のAM放送局は、 低い周波数側の測定点として非常に便利です。

ただし、 公称周波数に対して すべての送信局がサブHzまで完全一致している、 と最初から決めつけるのもよくありません。

今回の実測では、 594 kHz、954 kHz、1242 kHzと比較して、 1422 kHzだけが異なる方向の安定した偏差を示しました。

これだけで 「1422 kHzの送信局がずれている」 と断定することはできません。

しかし、 一つの測定点だけが全体の傾向から外れている場合、 その一点に合わせてREF Adjustを動かさない ことが重要です。

複数のAM局、 5 / 10 / 15 / 20 MHzなどを見て、 全体として整合しているかを判断します。

FreqCalは 「一つの正しそうな信号へ無線機を無理に合わせる」 ためのものではありません。

ここが非常に重要 ― REF Adjust確定後にfmt.allを捨てる

REF Adjustを変更しながら取得した fmt.allは、最終較正には絶対に混ぜない
REF Adjustを動かすたびに、 リグの基準周波数そのものが変化します。

つまり、 REF Adjust変更前、 調整途中、 調整後の測定値は、 同じ条件で測定したデータではありません。

REF Adjustが確定した時点で、 それまでの測定データを一度捨て、 固定したREF Adjustの状態から 改めてFreqCalを取り直します。

今回の再測定で、 まさにこれを実際に経験しました。

低S/Nを示す「*」付きデータを削除したにもかかわらず、 「較正パラメータ計算」を実行すると、

Calibration Error
Check fmt.all for possible bad data.

というエラーになりました。

原因は、 REF Adjustを変更する前と変更した後のデータが 同じfmt.allに残っていたことでした。

異なる基準周波数状態の測定値を一緒に直線近似すれば、 当然ばらつきは大きくなります。

REF Adjustを確定した後のデータだけにしたところ、 正常に「較正良好」となりました。

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をテキストエディタで確認します。

明らかに外れた測定値や、 受信状態が悪かった測定値は除外します。

「*」の意味
FreqCalでは、 S/Nが20 dB未満の測定値に 行末の*が付きます。

以前の記事では 「*付きデータを削除」 と簡単に書きましたが、 正確には 低S/Nのため信頼性を確認すべき測定値 という意味です。

*があるから数学的に必ず無効、 *が無いから必ず正しい、 という意味ではありません。

*の有無だけではなく、 周囲の値から大きく外れた測定値も確認します。

5.「較正パラメータ計算」

「ツール」→「較正パラメータ計算」

を実行します。

WSJT-Xは、 複数の周波数で得られた誤差から、 次の直線を求めます。

Dial error = A + B × f
A = インターセプト [Hz]
B = スロープ [ppm]
f = 周波数 [MHz]

大まかには、

  • インターセプト: 周波数に依存しない固定的な誤差成分
  • スロープ: 周波数が高くなるほど増える比例誤差成分
少し技術的な話
現行WSJT-Xの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を取り直した結果、 次の「較正良好」が得られました。

2026年9月28日 実測
Slope +0.046 ±0.008 ppm
Intercept -0.39 ±0.07 Hz
N 58
StdDev 0.39 Hz

この結果を20 MHzへ当てはめると、

-0.39 + 0.046 × 20 ≒ +0.53 Hz

となります。

実際に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を利用する方法を勧めます。

FreqCalの大きな利点は、 一つの周波数だけを合わせるのではなく、 複数の既知RF周波数を比較できることです。

周波数が高くなるほど誤差が増える傾向を ワイドグラフで視覚的に確認でき、 さらに最終的には スロープ/インターセプトとして 定量的に評価できます。

これは「絶対周波数標準器による校正」ではありません

ここで紹介している方法は、 GPSDOや高精度周波数カウンターなどを使用した 研究所レベルの絶対周波数校正ではありません。

受信する信号には、 電離層伝搬によるDoppler、 フェージング、 マルチパス、 S/Nの変化なども含まれます。

したがって、 1 Hz以下の数字を見て 意味なく追い込み続けるものではありません。

この方法の目的は、 特別な測定器を使わず、 アマチュア無線の実運用に十分な範囲まで リグの周波数誤差を小さくすること です。

まとめ

  1. リグを十分にウォームアップする
  2. FreqCalでドリフトが落ち着いたことを確認する
  3. その時点で安定して測定できる最高周波数で REF Adjustを粗調整する
  4. 「周波数較正実行」で複数周波数を見て、 高い周波数ほどズレる傾向を確認する
  5. REF Adjust / REF FREQ ADJを微調整し、 その傾向を最小にする
  6. REF Adjustを確定する
  7. ここで、それまでのfmt.allを必ず削除する
  8. REF Adjustを固定したまま、 改めてFreqCalを数巡実行する
  9. 低S/Nや外れ値をfmt.allから確認・除外する
  10. 「較正パラメータ計算」を実行する
  11. 「較正良好」ならApplyする
  12. 必要なら同じスロープ/インターセプトを JTDXにも設定する
まずリグそのものをできるだけ正しくする。
そして最後に残ったわずかな誤差だけを ソフトウェアで補正する。

そのためにFreqCalを 「測定器」と「補正値計算」の 二つの用途で使います。

特に50 MHzのように、 わずかなppm誤差が数Hz~数十Hzの差として見えるバンドでは、 一度確認してみる価値はあると思います。

ご注意

リグ本体の基準周波数調整を変更する場合は、 必ず各リグの取扱説明書を確認してください。 設定変更はご自身の責任で行ってください。

この記事で示したREF Adjustの数値は 私の個体での測定例であり、 他の個体にそのまま適用するための値ではありません。
参考資料
WSJT-X User Guide
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
JP1LRT / 2026年9月

WS – Digital Mode Suite 日本語User Guideを本気でレビューしてみた ― 69箇所修正、その日のうちに正式公開 ― 2026年09月27日 22時48分47秒

2026年9月27日
WS – Digital Mode Suite 日本語User Guideを本気でレビューしてみた
― 69箇所修正、その日のうちに正式公開

今日、DG2YCB/Uweから、

「日本語版のWS User Guideも見てもらえる?」

という連絡をもらいました。

せっかくなので、単なる誤字脱字のチェックで終わらせるのではなく、 英語版と日本語版の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デコード」 の方が、なんとなくデジタルモードっぽくて格好いいと思っています(笑)。

同じように、

Low / Medium / High
Early / Normal / Late

のような短い技術用語も、英語のままで十分意味が通りますし、 技術系softwareではむしろその方が分かりやすい場合もあります。

しかも、今回User Guide側を合わせた日本語UIは、 その少し前に自分もレビューを手伝ったものです。

日本語UIをレビュー
↓
User Guideを確認
↓
「GuideとUIの表記が違う」
↓
GuideをUIに合わせる

……ある意味、自分で自分の首を絞めました(笑)

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: None
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側には旧仕様と思われる説明が残っていることを確認。

こういうところは、日本語だけ勝手に書き換えるべきではありません。

そこで今回は、

1. 日本語User Guideそのものの問題
2. applicationの日本語translation側の問題
3. 英語Guide / source側の問題

と分けてUweへ報告しました。

AIにも独立チェックさせてみた

修正版については、自分の判断だけで完結させず、 AIにも独立してチェックを依頼しました。

「こちらの判断に合わせてくれ」ではなく、 誤訳、過剰修正、見落としがないかを疑って調べてもらう形です。

実際にこちら側の見落としも見つかり、再確認・修正したうえで最終版を作成。

HTMLについても、ID、anchor、link、table、 そして埋め込み画像40枚が壊れていないことを確認しました。

そして、その日のうちに公開

最終版をUweへ送ったところ……

“Thanks, Yoshi! It should now be online”

73 de DG2YCB,
Uwe

仕事が速い(笑)。

今日のうちに、そのまま公開されました。

念のため、公開後のHTMLを自分でもダウンロードして、 こちらから送った最終版と比較しました。

byte-for-byte identical
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は、 ボタン側も自動的に無効になります。

GUIでは押せないのに、内部からは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」

なのですが、ソースを読むと印象はかなり違います。

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

なお、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 の 3.2 系がいよいよ公開RC段階へ。
そしてもうひとつは、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 が公開されたとの正式アナウンスがありました。

👉 WSJT-X GitHub Releases

今回の大きな目玉は、新しいデジタルモード

JTTY

の追加です。

そのほかにも、 Q65、MAP65、QMAP に新機能が加えられ、多数の改善やバグ修正が行われています。

新しい WSJT-X 3.2 User Guide はこちら。

📖 WSJT-X 3.2 User Guide

新機能の概要はこちら。

✨ WSJT-X 3.2 New Features

3.0.2以降の詳しい変更履歴はこちらです。

📝 WSJT-X Release Notes

🎧 JTTY の暫定運用周波数

Joeたちは、まず20mで

14.090 MHz

を最初の共通集合場所として提案しています。

さらに、現時点での非常に暫定的な候補として、次の周波数が示されています。

Band JTTY Dial Frequency
160m1838 kHz
80m3575 kHz
40m7090 kHz
30m10140 kHz
20m14090 kHz
17m18100 kHz
15m21090 kHz
12m24920 kHz
10m28090 kHz
6m50160 kHz
2m144160 kHz
⚠️ ここは注意。

Joe自身がこれらを “very preliminary!” と強調しています。
JTTYが普及していけば、今後一部または全部の周波数が変更される可能性があります。

⚙ Frequencies の「Reset」にも注意

Settings | Frequencies の周波数テーブルを右クリックして Reset を選ぶと、多くのJTTY周波数がデフォルト周波数リストへ追加されます。

ただしJoeからも注意があります。

自分で追加した周波数を失いたくない場合は、Resetするのではなく、必要なJTTY周波数だけを手動で追加した方がよいでしょう。

そして開発チームは、

“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 - Digital Mode Suite
通称 WS / WS Suite

としてスタートします。

Uweによれば、WSJT-X本家との混同を避けることに加え、この新しい名称によって 開発チームとしてより自由に活動できるという意味もあるとのこと。

これは単なるロゴや名前の変更というより、これまでのImproved系をひとつの独自ソフトウェア・スイートとして整理していく動きと見てよさそうです。

📥 WS Suite 3.2.0 Download Page

🧩 WS Suite は3つのプログラムで構成

📻 WS
メインプログラム。
FT8 / FT4 / FT2 / JT4 / JT9 / JT65 / Q65 / FST4 / MSK144 / WSPR / FST4W / Echo に対応。
📡 WS-MAP
従来の QMAP Improved PLUS。
現在は主としてEME向けのwideband Q65 monitorですが、将来的にはSDRを利用した、より一般的なwideband receiverへの発展も計画されています。
🌙 EME65
従来の 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は次のように明記しています。

“Our new WS Suite picks up right where WSJT-X Improved 3.2 left off.”

つまり、新しくゼロから作られた別ソフトという意味ではなく、

WSJT-X Improved 3.2 → WS Suite

と、その開発系譜をそのまま引き継いでいく形です。

🌐 多言語対応も強化

WS 3.2では言語関係も大きく変わりました。

  • German / Frenchなど対応言語を追加
  • GUIのLanguageメニューから直接言語切替可能
  • 従来の --language=XY 起動オプションが不要
  • 選択した言語に応じたUser Guideを表示

興味深いのは、今回不足していた翻訳文字列を AIを使って補完した とUweが明記していることです。

そして、

翻訳品質はユーザーの手に委ねられているので、必要なら修正した .ts ファイルを送ってほしい

との呼びかけもされています。

💾 移行についてもかなり配慮

初回起動時には従来の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が公開されています。

🔔 JTAlert - HamApps


🤔 同じ「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 Improvedをベースにしたソフトウェア開発を行っているので、これは非常に興味深い変化です。

ただ、今すぐどちらかへ飛びつくというより、WSJT-X本家3.2系と、新しくスタートしたWS Suite 3.2系、それぞれが今後どう発展していくのかをじっくり追っていきたいと思っています。

🔗 関連リンク

📻✨ アマチュア無線のデジタルモード界隈、また面白くなってきました。

73
JP1LRT

JTDX_contest v3.0.0-rc08登場 ― SuperFoxデコーダーが大幅進化、僕もこのプロジェクトを応援したい ― 2026年09月22日 16時59分21秒

JTDX_contest UPDATE
v3.0.0-rc08 登場
Experimental SuperFox decoder が大幅に進化
2026年9月22日 — CE3TSK Tihomir から、新しい rc08 の内容について直接連絡をいただきました。

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独自のデコード処理をかなり積極的に追加 しています。

🔥 rc08の中心は SuperFox receiver
QRM除去、list decoding、a priori情報、multi-threading、 さらに通常FT8のdecode/subtractionまで組み合わせて SuperFoxを探しにいく構成になっています。

🦊 SuperFox decoder の何が変わったのか

① QRMを受けたtone binをnormalise

SuperFoxの帯域内に通常のFT8信号などが存在しても、 interferenceを受けているtoneだけが突出しないよう補正してから decodeを行います。

② CRC-aided successive-cancellation list decoding

候補を絞りながらlist decodingを行い、 messageのCRCを使って候補を確認します。

特に面白いのは、odd periodで実際に受信できたHoundを使って、 Foxが誰に応答している可能性が高いかを絞り込むところです。

③ a priori ― 4 levels

一度decodeしたFoxや、DX Call boxに指定されたFox、 受信したHoundなどの既知情報を利用して、 decoderの探索を助けます。

④ SuperFoxの前に通常FT8をdecodeして除去

これも非常に興味深いところです。

FT8 decode
↓
FT8 signals subtraction
↓
cleaner audio
↓
SuperFox decode

つまり、同じband内の通常FT8を先に見つけて取り除き、 その後にSuperFoxをdecodeするという考え方です。

⑤ Multi-threaded search

Fox探索をthread化し、 難しいFoxの探索が他の処理を必要以上に遅らせない構成になっています。

⑥ MSHV由来の3 sync windows

最終段では3つのsync windowを使用し、 Foxにfrequency offsetやtime offsetがある場合にも対応します。 これはデフォルトで有効とのことです。

💡 要するに……
単純に「SuperFox信号を探す」のではなく、 周囲のFT8を除去し、Foxについて既に分かっている情報や、 実際に受信したHoundの情報を使って探索空間を絞り込み、 最後にCRCで確認する というreceiverです。

⚙ Experimental だからこそ面白い

現在、このSuperFox decoderは experimental とされています。

またTihomirによると、 SuperFox関連のconstantは 再buildすることなく変更可能 になっています。

今後、実際のSuperFoxのrecordingを集めながら、 各parameterを調整していくことを想定しているとのことです。

🎙 SuperFoxのWAV recordingを募集中

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を元に改良していく必要があります。

“
新しいdecoderのアイデアを実際にコードにして、 real-world signalで検証しながら前へ進める。

僕は、こういう開発を積極的に応援したいと思っています。

日本のJTDXユーザーにも、 このプロジェクトをぜひ知ってもらいたいと思います。

また、SuperFoxの実録WAVを提供できる機会があれば、 decoder developmentへの非常に良い協力になると思います。

Thanks Tihomir CE3TSK 👍
JTDX_contest v3.0.0-rc08、今後の進化も楽しみにしています。
#JTDX #JTDX_contest #FT8 #SuperFox #HamRadio #AmateurRadio