東京UHFコンテスト結果発表 ― 2025年02月28日 00時15分57秒
タイトルの件発表されました。
QSOしていただいた皆さんありがとうございました。
TQSLの編集 ― 2025年02月27日 22時28分58秒
LoTWにデータをアップロードしたが、相手からGrid情報が抜けているので付加して再度アップロードしてほしいというリクエストが来たとします。
どのように編集すればよいかを紹介します。
LoTW へのアップロードは TQSL を使いますのでまずは TQSL を起動します。
次に局の所在地を編集します。
ここをクリックするとTQSLに登録している局のリストが出てきます。
ここでは私の例で説明します。
例えば JP1LRT/1 の Mitaka を編集してみますが、これをご自身が編集したいコールサインの局の所在地だと読み替えて実施してください。
Mitakaを選択して右側の 局の所在地を編集 をクリックします。
すると次の画面が出てきます
グリッドスクエア が空欄であれば そこにグリッドの情報を入力します。
その他の情報も抜けていたらもちろん入力してください。
そして 次へ をクリックします。
今回は Mitaka の情報を編集したので Mitaka を選択します。 これは例ですので皆さんの編集したい局情報を選択します。
完了をクリックします。
この画面に戻ります。
編集した Mitaka を選択して また局の所在地を編集 をクリックしてみると、先へど情報を追加したのであればそれが反映されていることが確認できます。
クリックすると
確認できたら キャンセルを クリックして戻ります。
次に ログの操作に戻ります。
最初の画面に戻りました。
アップロードしたい局の ADIF ファイルを ロギングソフトで出力させます。
例えば AB1CD という局からリクエスが来ていてその局とのQSOデータを ADIF で出力させたとします。 AB1CD.adi といファイルを出力させました。
それをアップロードします。
先ほど編集した JP1LRT/1 Mitaka でアップロードする場合は まず
【ログに署名し、LoTWに自動的にアップロード】 をクリックします。 クリックするとファイルを選ぶ画面に進みます。
ファイルを選択して 開く をクリックします。
所在地の選択画面が出ますので所望の所在地を選択して OKをクリックします。
すると次の画面が出てきます。
所望の局の所在地 であることを確認できたならば OK を押して進めば終了です。
以上です。
WSJT-X 2.7 GA版がリリース ― 2025年02月26日 09時57分50秒
2025年2月17日に WSJT-X 2.7 GA版がリリースされています。
WSJT-X Userの皆さん、最新版を使うようにしましょう。
インストールしたらここを有効化しましょう。
相手からメッセージが飛んでくるかもですよ。
もちろん貴方もメッセージを送ることが可能です。
ここをクリックすると
下記が出てきます。
メッセージ選択の中にある HB9Q Logger は主に EMEで使われている chat です。
https://logger.hb9q.ch/
https://logger.hb9q.ch/
Ping Jockey もチャットです。
ON4KST もメジャーなチャットです。
WSJT-X Foxモードについて おさらい ― 2025年02月22日 11時37分56秒
WSJT-X Foxモードについて
1.F/H , Fox and Hound モードのFOXはWSJT-Xのみの機能
2.F/HのFoxは標準周波数では運用できない
4.標準周波数で分裂している(マルチスレッド、マルチストリーム)はMSHVである
5.MSHVは運用するピリオドに限定はないのでEven, Oddどちらでも分裂(マルチスレッド、マルチストリーム)する事が可能である。
6.MSHVはF/Hではないので 1000Hzより上 という縛りもないし、グリッドロケーター付きで呼ぶ必要もない。
更に付け加えるとすれば、相手側がWSJT-X FOXモードであったとしてもコールバックのあったDFにジャンプする必要性はありません。つまりWSJT-X Foxモードで運用している局をノーマルモードで呼んでもQSOできます。ただしコールするのはDF 1000より上に限ります。要はHoundになるならないに関わらず、1000Hzより上でTx1で呼べば良いのです。
ですので WSJT-X Foxモード局を F/H だと知らずにノーマルモードで呼んでQSOできたから【相手は MSHVだ】と判断することはできません。 要は標準周波数以外で相手局が EVENに出ているときに、 DF 1000 より下で呼んでQSOできた、レポート付きで呼んでQSOできた、という場合は MSHV だと言えるということです。
相手が ODD に出ていて分裂していればもちろん最初から MSHVと言えるでしょう。
F/HやMSHVを呼び方と誤解しているpostも散見します。
F/HはWSJT-Xに搭載されたDXpeditionに特化されたモードで、呼ぶ側はHoundに設定するかしないかに関わらずQSOできますが、必ず1000Hzより上でcallします。一方、MSHVはソフトウェアの名称です。F/Hに似て非なるマルチストリーム運用が可能なソフトウェアです。WSJT-X F/Hのような呼ぶ側の縛りもありませんので、どこで呼んでもOKですし、最初からレポート付で呼んでもOKです。
《MSHVでもOKだった》《MSHVで呼んだ》という表現のポストをたまに見かけますが、理解されてない事が分かってしまうポストです。
まあ、QSOできれば何でも良いんですけどね。
未だにWSJT-X Foxモード運用局をHoundに設定して呼び、コールバックがあったならばその周波数に《引き込まれる》と表現する方がいらっしゃいますが、あれは自分がHoundモードに設定したソフトウェアが《自らそこにjump》しているのであり、相手側が制御しているのではありません。
なおHoundモードに設定できるのはWSJT-Xだけではなく、JTDXも可能です。
WSJT-X Foxモード運用局をコールするためにはHoundに設定しなくても良い事は書きましたが、コールバックがあったときのソフトウェアの動作が違います。Houndに設定すれば相手側のDFにjumpして応答を送信します。Houndに設定してなければ、応答を送信する周波数は変えずに呼んだときのDFのまま応答します。
コールする周波数が1000Hzより上であればHoundでなくてもQSO可能です。相手からRR73が来た場合Houndに設定してあれは73は返しません。Houndに設定してなければもちろんDFそのままで73を返します。
WSJT-X Foxモード運用局に対しては必ず1000Hzより上でTx1、つまりGrid付きで呼ぶ必要があります。相手側のリグの周波数偏差がありますから、自分が1000Hzに極めて近いDFで呼ぶのは非推奨です。相手側で1000Hzよりと上に認識されなければ応答ありませんので。
相手側がSDR機を使用している場合、受信している周波数が3000Hzより広い場合があります。あまりにコールバックが無い場合に3000Hzより上でcallする事も効果的かもしれません。相手側のリグ情報は相手側のWeb siteに記載されている事もあります。これは賭かもしれませんが。
相手側のソフトウェアがMSHVだと確信できたならば、Houndの概念を捨てて1000Hzより下で呼ぶ、相手側より下で呼ぶ等を試してみると良いでしょう。WSJT-X Fox運用と信じて1000より上で団子になって潰し合うよりコールバックの可能性は高くなると私は思います。しかしご自分の判断でよろしく。
### Clarifications on WSJT-X Fox Mode ― 2025年02月22日 11時36分23秒
**Clarifications on WSJT-X Fox Mode**
1. **Fox Mode**: The “Fox” in Fox-and-Hound (F/H) mode is a feature unique to WSJT-X.
2. **Frequency Operation**: A Fox station cannot operate on the standard frequency.
3. **Transmission Timing**: A Fox always transmits at the beginning of even minutes (e.g., 00 and 30).
4. **Multi-Threaded Split (MSHV)**: The MSHV software supports split operation (multi-threaded, multi-stream) on a standard frequency.
5. **Operational Flexibility with MSHV**: Because MSHV has no restriction on the duration of operation, it can split on either even or odd frequencies.
6. **Key Difference from F/H**: Unlike Fox-and-Hound mode, MSHV does not require callers to transmit above 1000 Hz or include a grid locator in their transmission.
To clarify: you don’t need to switch to the callback’s “designated frequency” (DF) even if the other station is running in Fox mode. You can initiate a QSO with a Fox-mode station while calling in standard mode — provided your call is made above 1000 Hz on Tx1 — and still get a callback.
Just because you establish a QSO with a Fox-mode station by calling in standard mode does *not* necessarily mean the other station is using MSHV. You might just not know that they were operating in F/H mode.
Here’s a practical guideline:
- If the other station is transmitting on **even**, and you were able to make contact by calling below 1000 Hz or by including a report, you *could* then assume they are on MSHV.
- Conversely, if they’re on **odd** and you observe split operation, it’s reasonable to suspect MSHV from the start.
Some operators confuse F/H mode with MSHV:
- F/H is essentially a Fox-and-Hound DXpedition mode in WSJT-X, where callers must always call above 1000 Hz, regardless of whether their “Hound” option is enabled.
- MSHV, meanwhile, supports multi-stream operation similar to F/H — but without the same frequency restrictions.
Therefore, you can call from **anywhere** or begin by sending a report.
I frequently see posts like “MSHV worked fine” or “They were called by MSHV,” but in many cases that reflects a misunderstanding. That said, what really matters is whether you were able to make the QSO.
There is also a common misconception that when you receive a callback from a Fox-mode station, you’re being “pulled” into their frequency. In reality, it’s usually your own software (if in Hound mode) that is shifting — **not** the other station controlling your frequency.
**It is not controlled by the Fox station.**
Note: not only WSJT-X but also JTDX can be set to “Hound” mode.
As mentioned earlier, **you do not need** to use Hound mode to call a Fox-mode station. However, how your software behaves upon receiving a callback *does* depend on whether Hound mode is enabled:
- If **Hound mode is ON**, your software will jump to the callback frequency and respond.
- If **Hound mode is OFF**, your software will reply from the same frequency where you made the call.
If you call above 1000 Hz, a QSO is possible even if Hound mode is disabled.
If the other station sends “RR73” and your software is in Hound mode, it will **not** send “73.” But if Hound mode is off, it *will* respond with “73” — without switching frequencies.
When calling Fox-mode stations, always use **Tx1** and call *above 1000 Hz*, and include your grid locator.
To avoid problems due to frequency drift or receiver tolerance on the other side, it’s **best not to call too close to 1000 Hz**. If your call is too near 1000 Hz, the Fox station might not register it as “above 1000 Hz” — and you may receive no callback.
If the Fox station is using SDR equipment, their receive bandwidth may exceed 3000 Hz. In such cases, calling **above 3000 Hz** can help. While you *might* find information about the other station’s setup on their website, it’s not always reliable.
If you suspect that the other party is actually using MSHV, you might increase your chances by abandoning the idea of “Hound mode” and instead call **below 1000 Hz** or from a frequency lower than theirs.
In my opinion, this approach may give you a better shot at a callback — instead of assuming the other is a Fox and clustering just above 1000 Hz, which can lead to interference between stations.
That said, **please apply your own judgment**.
JTAlertのススメ ― 2025年02月17日 11時04分09秒
FT8愛好家の皆さん、JTAlertをお使いでしょうか? 私は以前から使用していますがなくてはならないほど重宝しています。
JTDXユーザーの方、JTDX単体でも相手方が LoTW Userか否かが分かりますね。
● LoTWユーザーの通常デコード
○ LoTWユーザーのHintデコード .
＊ LoTWを使ってないユーザーのHintデコード
無 LoTWを使ってないユーザーの通常デコード
しかし WSJT-X は単体ではそれの判別ができません。
きっと多くの方が日本標準の電子ログと称されてもおかしくない Turbo HAMLOG をお使いでしょう。
Turbo HAMLOG には JT-Get's という機能があり、JTDX、WSJT-Xから QSOデータを Turbo HAMLOGへ転送してくれます。
JA4JOEさんの素晴らしい解説ページ
ログに入力する際に、QSLをどうするかを入力すると思います。 Bureau経由ならば J、 eQSLならば E、 LoTWならば L 等と、各人によって設定は様々かと思います。
どうせならば QSO終了直後のログ記載時に行えれば効率的ですよね。 後から JARL転送か、eQSLかLoTWかと調べるのはちょっと時間を損しているかもしれません。
Turbo HAMLOG には JA の局で JARL経由でQSLを遅れるか否かを表示してくれる機能があります。
JARL会員データ（JARL.mDAT）によるQSL印刷抑制機能について
注意事項があるのでよく読む必要があります。
イ QSLカードの転送ができないコールサイン
ウ JARLに入会したばかりの方のコールサイン
で、いよいよタイトルの件です。 JTAlert をなぜおすすめするかと言うと、デコードした局をリアルタイムに解析・表示してくれます。 eQSL 対応なのか、LoTW対応なのか。
これは便利。
例えばこの画面、マウスのカーソルを当てるとその局のステータスが表示されます。
この局は LoTW ユーザーですがeQSLは使っていない。 JTAlertを使用していることが分かります。
またこの局は LoTW、eQSLともにユーザーでJTAlertも使用しています。
表示の設定は変更することができます。
画面の右したの歯車をクリック。
設定は色々変えられます。
また、JTAlertユーザーとはリアルタイムでチャットが可能です。 日本語も通ります。
それにこの JTAlert には まさに アラート、警告機能が装備されています。 音声で教えてくれるのです。
細かい設定が可能で、バンドごとの New DXCCや New GRID、ZONE 、米国の州まで教えてくれます。
私が気に入っているのは自分が呼ばれたときに教えてくれる機能です。
CALLING YOU!!!
CALLING YOU!!!
と教えてくれます。
その他の機能も盛り沢山。解説されてらっしゃる方もいるのでそちらを参考にしてください。
WSJT-X の方には必須とも言えるツールです。
そんな便利な JTAlert は ここからダウンロードできます。
関東UHFコンテストに参加しました ― 2025年02月17日 10時48分30秒
昨年に引き続き関東UHFコンテストに参加しました。 部門はまたA430 430CW です。
休みを申請し忘れたので、参加は絶望的かと思っていましたが、なんと勤務は「自宅スタンバイ」。であれば自宅にいさえすれば何していても良いので参加という感じです。 (^^)
いつもは静かな 430 CW帯がこの日ばかりは大混雑。 開始ちょっと前から周波数を確保する必要があります。 スーパー強力な局が至近に出てこないことを祈りつつ VVV。
コールサインももちろんアナウンスします。
で開始。
ペースは昨年より良かったです。最初の一時間で 79QSO。 ほぼ目標通り。
しかし13時30分以降は失速・・・ 新局になかなか巡り会えませんでした。
まあ固定から出ていますのでそんなものかとは思いますが。スキマーがあればなぁ・・・とは思いますが。
QSO していただいた皆さんありがとうございました。またQSOには至らなかったけどコールしていただいた皆さん、アンテナの向きが悪かったかもしれません。懲りずに次回も是非よろしくお願いいたします。
見たくない方は決してクリックしないでください。
↓
交信の推移のグラフ
昨年との比較
取れたマルチ
見たくない方は絶対にクリックしないでください。 得点は・・・
今更ですが 関東UHFコンテストの結果発表形式について ― 2025年02月11日 08時09分41秒
本日このあと 関東UHFコンテスト が開催されます。
タイトルの件ですがまずは結果発表を御覧ください。
第40回結果 https://jarl.com/kanto/40kantouhf-result.pdf
第41回結果 https://jarl.com/kanto/41kantouhf-result.pdf
40回は【点数】と【マルチ】が記載されていますが41回は【得点】のみ
となっています。 これですと他局との比較において 【点数】で
差がついたのか【マルチ】で差がついたのか全くわかりません。
コンテストに参加して結果を検討し次回への対応を考えることが
できないのです。
なぜこんな改悪をしたのでしょうか???
今日ご参加の皆さん、コメント欄に結果発表はぜひとも 点数とマルチ の併記をとご記入願います。
第40回1エリアAMコンテスト 結果発表 ― 2025年01月31日 13時17分19秒
第40回1エリアAMコンテスト、現在までのログ受付状況 ― 2025年01月28日 11時05分29秒
未提出の方、締切は2025年1月30日 23:59:59 のタイムスタンプまでです。
最近のコメント