2026年東京CWコンテスト参戦記 ― 寝坊と中抜け、そして家庭内SWR無限大の危機!? 🤣 ― 2026年10月25日 14時11分45秒
それでも234 QSO!
家庭内SWR無限大の回避!? 🤣👻
2026年の東京CWコンテストに参加しました!📡
このコンテストは06:00から12:00までの6時間勝負。
今回は最初から優勝を狙っていたわけではなく、気楽に楽しむつもりでした。
とはいえ、まさかこんな参加の仕方になるとは……(笑)
😴 開幕早々、寝坊で遅刻!
まず、開始時刻の06:00には起床できませんでした🤣
最初のQSOは06:13。
いきなり13分遅れでのスタートです。
まあ、今日は勝負を狙う日ではないので、気を取り直して3.5MHzから430MHzまで、各バンドを回りながら交信を重ねていきます。
ところが、ここで次なる問題が発生!
👻 最大の難関は《かみさん事由》
09:17頃、運用を中断しました。
理由は……
生活そのものが成り立たなくなります(笑)
無線機には高性能なアンテナチューナーがありますが、家庭内のインピーダンス整合については、そう簡単にはいきません。
場合によっては、いかなる整合回路を投入しても解決できない可能性があります🤣
したがって、こちらの対応を最優先!
何しろコンテストは次回もありますが、家庭内の平和が失われると、今後の無線活動そのものが危うくなりますからね👻
運用再開は11:39頃。
コンテスト終了まで残り約20分!
それでも最後の11:59まで交信を楽しみました。📡
📊 さて、肝心の結果は?
参加部門は都内電信オールバンド(1CA)。
3.5MHzから430MHzまで、全8バンドで交信できました。

最もQSOが多かったのは7MHzの66局。
次いで3.5MHzが50局、14MHzが32局。
いつも主戦場にしている50MHzでは24局でした。
今回の得点は309点 × 147マルチ = 45,423点。
寝坊と中抜けがあったことを考えれば、十分楽しめた結果です👍
📈 グラフに刻まれた《かみさん事由》(笑)
時間帯別QSOグラフをご覧ください。
ご覧の通り、09:17頃から11:39頃までQSOがありません。
リグの故障でも、アンテナのトラブルでも、停電でもありません。
コンテストの時間帯別グラフに、家庭内の事情がこれほど鮮明に記録されることも、そうそうないでしょう(笑)
🏆 強豪のJK1JHU、JK1QAY両局とも交信
東京CWコンテストの都内電信オールバンド部門といえば、やはりこのお二人。
昨年2025年の結果は、
| 🥇 JK1JHU | 142,038点 |
| 🥈 JK1QAY | 138,836点 |
このお二人、昨年は3,202点差という大接戦でした。
今回の私のログを確認すると……
| 📡 JK1JHU | 8 QSO |
| 📡 JK1QAY | 7 QSO |
お二人とも、たくさんの交信ありがとうございました!😊
もっとも、このお二人がいるので、私は最初から優勝を狙っていたわけではありません(笑)
今回は勝負にこだわらず、無線そのものを楽しむ参加でした。
😊 こういうコンテストも、また楽しい
開始早々の寝坊。
そして、約2時間22分の《かみさん事由》による中抜け。
それでも最後の20分に復帰して、最終的には234 QSO。
いつも勝ちを狙って全力で走るのもコンテストの楽しみですが、こうして自分のペースで参加するのも悪くありません。
何より、家庭内の平和を維持しながら無線を楽しめたことが、今回の最大の成果かもしれません🤣
交信いただいた皆さん、ありがとうございました!
またコンテストでお会いしましょう。📡
2026年10月25日
📡 JTDX Contest 3.0.0-rc11 公開!――自動呼び出し・単局同期・バンドホッピングなど新機能が続々 ― 2026年10月25日 13時04分47秒
3.0.0-rc11
チリの CE3TSK(Tihomir)さんが開発している JTDX Contest Edition の新しいリリース候補版、v3.0.0-rc11 が公開されました。🎉
今回の更新は、日々のFT8・FT4・FT2運用に便利な機能の追加と、オートシーケンスやデコード時の安定性改善が中心です。特に気になったところを、運用者目線で紹介します。
🆕 注目の新機能
DX Call欄に設定した相手局の信号を受信すると、自動で呼び出します。最大6回まで試行。DXpeditionメニュー、Ctrl+W、またはEnable Txの右クリックから利用できます。
DX Call欄の相手局から自局宛ての送信を受信すると、Enable Txが自動的にオンになります。相手の応答を待つ場面で便利な機能です。
Tab 3から、FT8・FT4・FT2を1~2分間隔で順番に切り替える機能が追加されました。複数モードの受信状況を見て回る際に役立ちそうです。
DX Call欄に相手局を設定し、SyncをCtrl+クリックすると、その局のDTを基準にJTDXの時刻補正を行います。
💡 個人的にも注目していた機能です。これはWindowsのシステム時計を変更する操作ではありません。
Band Activityに、国名に続いて相手局までの距離と方位を表示できるようになりました。伝搬状況を確認するときにも嬉しい改善です。
JTDX ImprovedのALレイアウト風の表示を選べるようになりました。画面の好みや運用スタイルに合わせた選択肢が増えています。
SWRが2.5を超えると送信を停止する機能を追加。また、Tuneを右クリックすると、対応する無線機のアンテナチューナーを起動できます。
※動作は無線機やCAT接続などの構成に依存します。SWR保護機能は無線機・アンプ側の保護機能に代わるものではありません。
🔧 修正・改善されたところ
- 自動シーケンサー:RR73付近の動作を改善。
- クラッシュ修正:混雑したFT8バンド、100局を超えるFT4/FT2デコード、PTTポートを開けない場合の計3件を修正。
- 送信メッセージ:送信できないメッセージは送らないよう改善。FT系モードではTx欄をピンク色で表示。
- バンド変更:無線機側で周波数帯を切り替えた場合の扱いを改善。
- その他:FT2、PSK ReporterへのQO-100周波数通知、WSPR、グリッド表記などを修正。
- データ更新:2026年版のCALL3.TXTを同梱。
- 日本語表示:翻訳を再レビューし、表示文言を見直し。🇯🇵
rc11ではALLCALL7.TXTが初期状態で無効になり、有効化には JTDX_ALLCALL7=1 の設定が必要と案内されています。Windowsでの具体的な設定方法と読み込み確認手順は開発者に確認中です。
⬇️ ダウンロード
Windows、Linux、macOS向けの配布ファイルは、開発者の公式ダウンロードページから入手できます。
実運用のメイン環境へ上書き導入する前に、設定ファイルやログのバックアップを取り、可能なら別環境で動作を確認することをおすすめします。
✍️ ひとこと
今回のRC11は、派手な新モードを追加するというよりも、実際の運用で「ここがもう少し便利なら」と感じる部分に手が入った更新という印象です。
特にSingle Station Syncは、私からも要望していた機能の一つ。開発者のTihomirさんが反映してくださったことに感謝しています。日本語訳についても、引き続き気付いた点をフィードバックしていきたいと思います。
新しい機能を試すのは楽しいもの。でも、まずは安全な環境で確認してから。みなさんも良いデジタルモード運用を! 📡✨
第1回 JARL WW RTTYコンテストに「ちょっとだけ」参加(笑)― CTESTWIN・FSK・マクロ・RITの話 ― 2026年10月19日 10時58分36秒
「ちょっとだけ」参加しました(笑)📡
USBケーブル1本でFSK。マクロは少し長め、RITはいつもON。
10月17日(土)から19日(月)まで開催された第1回 JARL World Wide RTTYコンテスト。長年のJARTS WW RTTY ContestをJARLが引き継いで開催する、最初の大会です。
先週は全市全郡コンテストに出たばかり。今回は特に気合を入れるつもりもなく、空いた時間にCQを出して「ちょっとだけ」遊びました。😁
| Band | QSO | Mult. |
|---|---|---|
| 3.5MHz | 19 | 6 |
| 7MHz | 158 | 14 |
| 14MHz | 5 | 4 |
| TOTAL | 182 | 24 |
シングルオペ/オールバンド/ローパワー。申告スコアは369 QSOポイント × 24マルチ=8,856点。7MHzが158 QSOで、ほぼ7MHzでのCQ RUNでした。
運用は日曜の昼頃から月曜の終了直前まで断続的に。海外との交信はWB6JJJ、CX2AQ、9A1A、LZ5R、I4JEDの5局。私がQRVした時間帯では海外局がとても少ないという印象でした。第1回ということで、これから海外にももっと広まってくれるといいですね。
私が使ったのはCTESTWIN 4.64 + MMTTY 1.68 + EXTFSK 1.06。リグはIC-7300のRTTYモードです。デコードやログ管理はPCで、送信はAFSKではなくFSK。
普段FT8をやっているのでUSB接続環境はできています。FSKのキーイングとPTTを設定すれば、余計な外付けインターフェースを増やす必要もありません。CTESTWINの受信文字列をクリックしてコールサインやナンバーを取り込み、マクロでテンポよくRUNできるのも実に快適です。
送信時にPCからRTTYのマーク/スペース音を流してSSBを変調するのではなく、リグ側でFSKを生成する方式。送信音声レベルやAFSKの過大入力を気にして調整する必要がありません。 これが大きい。
FSKではPC側の「送信用サウンドカード」の指定は、FSK信号の生成には関係しません。一方、受信側の音声入力とデコーダーの調整は必要です。また、最初のCOMポート、FSK極性、PTTなどの設定は当然必要。そこが完了してしまえば、送信オーディオレベルをその都度追い込む作業から解放される、という意味です。
もちろん、適切に調整したAFSKでも良好なRTTY信号は出せますし、FSKなら自動的に綺麗な電波になるわけでもありません。ただ、FSKを使えるリグで、あえて送信音声系を経由する理由は私にはあまりないですね。RTTYモード専用の受信フィルターや、Mark周波数の明確な表示も便利です。
※USBケーブル1本で何を同時制御できるか、またCATとFSKのCOMポートをどう共用するかは、機種・ドライバー・ソフト構成によって異なります。「同じCOMポートを複数のソフトが無条件で同時に開ける」という意味ではありません。利用する機種の取扱説明書に従ってください。
JARLが公開している「RTTYコンテスト入門」(JS1OYN 高橋勝さん著)には、初心者にも分かりやすい交信例が掲載されています。基本がよくまとまった資料です。
その記事にも書かれているように、RTTYは文字化けがあるため、コンディション次第でコールサインやナンバーを3回送ることも有効です。私は、その考え方を普段のCQ RUN用マクロに少し強めに反映しています。記事の例を否定したいのではなく、運用方針の違いのお話です。😄
実際に使ったF5〜F14のマクロ設定画面。以下では、そのうちF6(UR)・F7(TU)・F12(ANS)の考え方を紹介します。
写真をクリックするとasabloの拡大画像を表示します。
JP1LRT JP1LRT
CQを出している局が知りたいのは「誰が呼んでいるか」。呼ばれている側は、自分のコールサインなんて知っていますからね(笑)。
「JA1RL DE JP1LRT JP1LRT」と相手のコールを付けるより、必要なら「JP1LRT」をもう1回繰り返すほうが、相手のコピーの助けになる、というのが私の考えです。
相手のコールサインを最初と最後に。最初が文字化けしても、最後で自分が呼ばれたと確認できるかもしれません。年齢「60」は3回。少し送信時間が増えても、NR? や CALL? で往復するより、最初から一度でコピーしてもらいたいのです。
こちらがコールバックしたあと、QSL UR 599 74 74 とだけ返してくる局もいます。これでも通じるときは通じます。
私は呼び回り側でも、相手のコールサイン、ナンバーの反復、最後に自局コールを入れています。相手が複数局を相手にしていたり、QRM・QRN・QSBがあったりする場面では、誰からの返答か、ナンバーは何かを少ない手戻りで伝えたいからです。何回も送り直すより、RTTYらしい文字化け対策を最初からしておいてもいいでしょう。
最後にも相手のコールサインを入れれば、誰とのQSOが完了したのかが明確です。末尾は次の局を募集する「CQ」。TEST でも意味は通るので、そこは好みですね。
冗長に送れば常に速くなるわけではありません。コンディションが良ければ短い電文も有利。それでも私は、RTTY特有の文字化けで NR? / CALL? / AGN? を何往復もすることを、できるだけ減らしたいのです。
今回のCQ RUNでは、少し周波数がずれたまま呼んでくる局が結構いました。 送信の音質が悪いという話とは別で、相手のRTTY信号の周波数が、こちらの受信の中心と一致していないという話です。
私のIC-7300はRTTYモード。RITは常にON、基準は0.00にしています。CQを出す側の送信周波数は固定したまま、呼んできた相手に合わせて受信側だけをRITで動かすためです。
そして、IC-7300のウォーターフォールのSPANは0.5kHz、または1kHzに設定。広いバンド全体を見るのではなく、目の前のRTTY信号を大きく、細かく見るためです。
SPANを狭くするのは、2本線の位置を見やすくするため。受信フィルターの帯域幅を狭くするのとは別の操作です。QRMが強ければRTTY用の受信フィルターも適切に使います。
もちろん、周波数を合わせたからといって、深いQSBやQRNによる文字化けがなくなるわけではありません。だから、前述のコールサインやナンバーの反復が効いてくるわけです。
呼んでいる信号は分かる。でも、コールサインが一文字もデコードできないことがあります。そこでフリーメッセージで QRZ? QRZ? や AGN AGN と送るのですが……。
いやいや、だからさっきからもう一回呼んでくださいって言っているんだけど!🤣
こういうことはCWコンテストでもあります。相手がこちらの再送要求をコピーできていない可能性もあるので一概には言えませんが、長く無線をやっていても不思議に感じる現象の一つです。
参加してみると、RTTYはやっぱり面白い。FT8とは違って、チューニング、文字化けの見極め、マクロの使い方、テンポの良いRUNなど、オペレーターの腕が出るところがあります。
今回は海外局が少なかったのが少し残念。来年はもっと多くの局が参加してくれると嬉しいですね。
・JARL「RTTYコンテスト入門」(JS1OYN 高橋勝氏)
・第1回 JARL World Wide RTTYコンテスト規約
・CTESTWIN公式ヘルプ:MMTTY
・CTESTWIN公式ヘルプ:PTT設定
※本文の交信例は、比較のための例示です。RTTYマクロの動作・画面構成は、私が今回使用した設定に基づきます。
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
くらいクレジットが入ったら、もっと嬉しかったんだけどなあ(笑)。
まあ、それは次の機会に。










最近のコメント