430MHz FMの変な人2026年01月06日 15時22分23秒

430MHz FMも変な人いるなぁ・・・・

ある局とQSOが終わった直後、いきなり

「周波数ズレてますよ」

だってさ。
……いや誰だよ。誰向けだよ。まず名乗れ😂

こちら向けかわからなかったので、

「私向けですか? JP1LRT」

と聞くと、

「はい、そうです。周波数がズレてて聞きづらいですよ」

とのこと。

私「そういう指摘をするなら、まずコールサインを名乗ってから言うのが筋ですよね。こちらJP1LRT」

……沈黙。

私「ちなみにこちらはIC-9700で、10MHzの基準信号も入れてます。大きくズレてる可能性は低いと思います。もし聞きづらいなら、そちらの周波数ズレか、マルチパス等の影響かもしれませんよ」

……沈黙。

はい終了。
“注意してやった”感だけ出して、名乗りも根拠も無しでフェードアウト。
こういうの、430FMではたまに湧く(失礼)


430FMでよくいる「変な人」分類(経験則)

1️⃣ 周波数警察型
   2️⃣ 変調警察型(音がデカい/小さい)
   3️⃣ マナー説教型(でも自分は名乗らない)
   4️⃣ 俺様基準型(自分のリグが絶対)

今回の相手は複合タイプっぽい。

  • 自分のコールは名乗らない

  • 技術的な話になると黙る

  • でも「指導」だけはしたい

……典型的な“FM説教おじさん(失敗型)”ですね😂


今思うと、こう聞いてみればよかった。

「ありがとうございます。念のため、測定はどんな方法でされましたか?」

……答えられるわけがない😂😂😂

※補足:そもそも「周波数ズレっぽく聞こえる」のは、送信側だけの問題じゃなくて、相手側の受信条件(マルチパス、受信機の特性、フィルタや復調状態など)でも普通に起きます。



FT8 のちょっとした話題2026年01月04日 12時26分17秒

この話はもう耳タコだとは思うんだけど、FT8でたまに見かける「オンフレ呼び→そのまま同じDFに居座って別QSO開始」について、改めて共有します。 FT8の「オンフレ呼び」自体は成立するし、絶対悪ではありません。 でも問題になるのは、QSO後に同じDFに居座って、そのまま別の相手と送信を始めることです。 アナログに例えると分かりやすいです。 SSBである局がCQ → QSO終了 → そのまま同じ周波数でまたCQを出した。 その直後に、さっき交信した局が同じ周波数に居座って別の局とQSOを始めたら…… 普通にえ、そこ今CQ出してるじゃん。邪魔なんだけどってなりますよね。 FT8も本質は同じで、仕組み上こうなります: ・CQ局が同じDFでCQを継続している ・そこへ、直前に交信した相手が同じDFで別QSOを始めて送信する → そのCQ局を次に呼びたい局の応答が同じDFでぶつかり、デコードできなくなる(実害) 「同じDFで重なってもデコードできるでしょ?」という反論もありますが、現実にはそう都合よくいかないことが多いです。 SNR差が大きいと強い信号にマスクされて弱い信号がデコードできない(できにくい)ケースが普通に起きます。結果として、次にオンフレで呼んでくる局にとってはQRM(妨害)でしかなくなります。 ここで大事なのが「相手が全員スプリットなら実害は小さい」という点です。 もし呼ぶ側が全員SPLIT(別DF)で呼んでくる文化なら、応答は別DFに出るので衝突しにくく、被害は限定的です。 でも現実には、一定数「オンフレ(同じDF)」で呼んでくる局が必ずいます。 だから、CQが継続されているDFに居座って送信を始める行為は、次にオンフレで呼ぶ局にとってはQRM(妨害)でしかなくなり、結果としてCQ局のラン運用も成立しにくくなります。
結論:オンフレで呼んだ後は、その後の運用はDFを少しずらして行ってほしい(居座りは避けてほしい) ほんの数十Hz〜数百Hzずらすだけで、次の呼び出しが成立しやすくなって皆が快適になります。


明けましておめでとうございます2026年01月01日 15時28分40秒

明けましておめでとうございます。
旧年中は交信・情報交換など、たくさんお世話になりました。

本年も無線を楽しみつつ、コンディションや運用の気づき、ちょっとした工夫などをこのブログに残していきます。
引き続きどうぞよろしくお願いいたします。

皆さまにとって穏やかで良い一年になりますように。


📣【コンテスト勢のみなさんへ】2025年12月29日 22時45分56秒

CTESTWIN / zLog を使ってる方、**スーパーチェック(パーシャルチェック)**使ってますか?
これ、地味だけど めちゃ効く仕込み です

既に使ってる方には耳タコですからごめんなさい
■ スーパーチェックって何?
 事前に用意した「局リスト(常連局・最近QSOした局など)」を
CTESTWIN / zLog に読み込ませておく機能です。
 コールを打ってる途中から
「候補局がズラッと出てくる」あれです!
■ 実戦メリット(これが効く)
 誤記・呼び間違いが減る
似たコールが多い時間帯ほど効果大!
「それじゃない!」に早めに気づけます
 S&P が速くなる=拾いが増える
数文字で候補が出るので、判断が早い
結果的に取りこぼしが減ってスコアが伸びやすい
 テンポが崩れにくい(レート維持)
確認・迷い・打ち直しが減る=運用がスムーズ
長時間運用ほど差が出ます
 “出てきそうな局”が見える
常連局・復活局・最近交信した局が候補に出ると
「今いるかも?」が見えて探しやすい
 後処理もラク
誤記が減る=ログ修正が減る
提出前の整理も楽になります
■ 国内コンテストだとどうする?
国内向けは、基本的に
 自分で作る or  友人からもらう
って感じになりがち(JCC/JCG と相性◎)ですよね。
 ちなみに海外コンテストなら…
 supercheckpartial.com から
Super Check Partial Database Files が入手できます!
 https://www.supercheckpartial.com/
 そこで配布されている master.scp などの “.scp系” は、配布側の説明では Win-Test / N1MM+ 向け とされていることが多いです。CTESTWINでは読み込めて使用できました。きっとzLogでも?
■ 今回:国内向けを作るのが面倒だったのでツール作りました(笑)
Turbo HAMLOGから出力させる CSV から
 国内局(JCC/JCG が入ってる行)だけ拾って
 既存リストとマージ → ソート → 重複削除
して、チェックリストを作れる簡易ツールです
補足:
 .spc で出力したものは拡張子を .pck に変えるだけで CTESTWIN で使えます(逆も同様に運用可)
■ まとめ
スーパーチェックは派手じゃないけど
 ミス減
 拾い増
 テンポ維持
に直結するので、コンテストではかなり効きます
まだ使ってない方は、一度入れてみると体感できると思います


1エリアAMコンテスト(1AM)】開催日アンケート(2026年)2025年12月29日 09時36分05秒


【1エリアAMコンテスト(1AM)】開催日アンケート(2026年) — 2026年の開催日、どちらが参加しやすいですか? — ※アンケート締切:2026/1/3(土)23:59(JST) 1エリアAMコンテスト(1AM)は、皆さんのおかげで 41回連続で開催できています。本当にありがとうございます。 そして 2023年から私が主催を引き継いで以降、ありがたいことに「結果発表が劇的に早くなった!」という評価も多くいただいています。 ※なお 2025年分は、まだ結果発表前ですが、並行して「来年以降さらに良くする」ための改善も進めたいと思っています。 主催者として次に目指したいのは、 さらに参加しやすく、皆が楽しめるコンテストにすること。 そして「年内最後にこれに出て締めくくる」――そんな印象を持ってもらえる恒例行事に育てたいと思っています。 その第一歩として、2026年の開催日について皆さんの実感を教えてください。 第4日曜(12/27)に寄せると「年末で忙しくて出られない」方が増えるかもしれません。 一方で「年末休みに入っていて、逆に参加しやすい」という方もいるはずで、主催者の想像だけでは決めきれません。 さらに運営面では、来年以降 ログ提出期限を少し早めることも検討しています(集計〜結果発表をよりスムーズにするため)。この点についてもご意見があればぜひお寄せください。 投票だけでも大歓迎ですし、理由や事情は この投稿へのコメントでも、または コンテストログ提出先メール(1am_test(あっとまーく)6mnet.jp)宛に送っていただいてもOKです(短文でも大丈夫です) ※メールの場合、件名に「開催日アンケート」と入れていただけると助かります。 【投票】2026年、参加しやすい開催日は? A:12/20(第3日曜・年末前) B:12/27(第4日曜・年末寄り) C:どちらでもOK D:年によって調整が良い(例:年末に近い年は前倒し 等) 最後にひとこと: ぜひ“年末の挨拶代わり”に、1局でも交信したら参加してみてください!

第41回1エリアAMコンテスト2025年12月22日 16時17分02秒

第41回 1エリアAMコンテストにご参加いただき、誠にありがとうございました。
現在、ログの集計作業を進めております。

規約には

【提出書類】 JARL推奨旧フォーマット R1.0
【提出先】 1am_test(あっとまーく)6mnet.jp
※2023年度より電子メールのみの受付となっております。
添付ファイルではなく、メール本文に貼り付けてお送りください。

と明記しておりますが、今年も R1.0 以外の形式 で提出された方、添付ファイルで送付された方 が数名いらっしゃいました。
また、
「1. 移動局は移動場所・使用電源を明記してください」
という規定についても、記載漏れが見受けられました。
今年については、主催者側で確認のうえ、必要事項を補足・訂正させていただきました。
ただし、スムーズな集計のためにも、来年度以降は規約に沿った形式でのご提出にご協力いただけますと幸いです。
引き続き、結果発表まで今しばらくお待ちください。

また随時ログの受付状況についても公開しています。

第41回1エリアAMコンテスト 現在までのログ受付状況



📻 WSJT Log Utility v0.13 公開のお知らせ2025年12月18日 16時48分58秒

今日は休みで時間があったので、あれこれ試しているうちに……
気がついたら WSJT Log Utility v0.13 まで進んでしまいました 😊

このツールは、主に次のような方を想定して作った Windows 用 GUI アプリです。

  • wsjtx_log.adi を失ってしまった

  • 手元に wsjtx.log(WSJT-X / JTDX のテキストログ)しか残っていない

  • 複数のグリッド・ロケーター、移動運用、特別運用などで
    ログを正しく分割・整理したい

主な機能

  • wsjtx.log(CSV形式テキストログ)を ADIF に変換

  • 既存の ADIF ファイルを日時指定で分割

  • バンド指定フィルタ(最大 23cm まで対応)

  • 日付・グリッド・/P /M /MM /AM・POTA / SOTA / IOTA / WWFF などを
    含めた 安全な出力ファイル名生成

  • LoTW 向けとして設計していますが、
    複数アカウントを使う eQSL ユーザーにも十分対応できます

  • 完全ローカル動作(ログのアップロードなし/元ファイルは変更しません)

開発のきっかけ

古い WSJT ログとグリッド移動に関する技術的なやり取りがきっかけでした。
この用途にピッタリ合う「実用的で簡単なツール」は、これまでほとんど無かったため、
思い切って形にしてみました。

ご注意

  • 完全フリーソフトです

  • 無保証・サポートはできない場合があります

  • 実行ファイルには SHA-256 チェックサムを付けています

  • 将来的なアップデートは、時間が許せば行うかもしれません

何年分もの WSJT/JTDX ログを前にして
「もっと楽に整理できたら……」と思ったことがある方には、
きっと役に立つと思います。

🔗 ダウンロード(GitHub Releases)
https://github.com/jp1lrt/wsjt-log-utility/releases

73 & Enjoy!


How to Add a New Station Location in TQSL2025年12月15日 08時02分35秒


Focusing on Correct Grid Locator Registration

To properly confirm QSOs in LoTW, it is essential that your Station Location includes a correctly defined Grid Locator.

This is especially important for:

  • Grid-based awards (VUCC, Grid awards, etc.)

  • Rare grid confirmations

  • Stations operating from multiple locations under the same callsign

In this article, we intentionally step away from mobile operation examples and focus solely on how to add a new Station Location in TQSL, with particular emphasis on Grid Locator accuracy.


Why Grid Locator Matters

LoTW supports many awards that depend on Grid information, such as:

  • VUCC

  • Grid-based endorsements

  • Regional and experimental awards

If your uploaded QSO data does not include Grid information, the other station may:

  • See the QSO in LoTW

  • Fail to receive a confirmation (CFM)

In many cases, “CFM problems” are caused simply by a missing or incorrect Grid Locator in the Station Location.


1. Start TQSL

Launch TQSL.
All LoTW uploads are processed through TQSL.


2. Open the “Station Locations” Tab

Select the Station Locations tab.

This screen shows all Station Locations currently registered in TQSL.


3. Create a New Station Location

Click “Create a New Station Location”.

⚠️ Important rule
Even if the callsign is the same, a different Grid Locator requires a separate Station Location.


4. Enter the Grid Locator (Critical Step)

On the Station Location input screen, enter the Grid Square.

🔴 This is the most important field

  • Grid Square: Mandatory

  • IOTA reference: Optional

IOTA can be left blank if not applicable,
but Grid Square should always be entered.


5. Select Administrative Location

Next, select:

  • Prefecture / State

  • Administrative region

Choose the location that accurately matches the operating site.


6. Assign a Clear Station Location Name

Enter a descriptive Station Location Name.

Recommended format examples:

  • HOME_PM95

  • MIYAKOJIMA_PM74

  • YORON_PQ00

Including the Grid Locator in the name makes future uploads much easier to manage.


7. Finish and Save

Click Finish to save the new Station Location.

The Station Location is now ready for use.


8. Uploading Logs – Important Reminder

When signing and uploading an ADIF file:

  • Always select the correct Station Location

Selecting the wrong location can result in:

  • Incorrect Grid uploaded

  • QSOs confirmed under the wrong location

  • Lost award credit


Summary

  • Create one Station Location per Grid Locator

  • Always enter the Grid Square

  • Use clear, descriptive location names

  • Verify the Station Location before every upload

Following these steps prevents nearly all Grid-related LoTW problems.


Final Note

If you operate from a rare Grid, please take the time to register it correctly and upload your QSOs to LoTW.
Many operators are waiting for those confirmations.


WSPR ガードバンドについて — すべての FT8/FT4 運用者への注意喚起2025年12月10日 07時15分27秒

近年、FT8/FT4 の利用者が増えたことで、WSPR との周波数衝突が世界中で問題になるケースが増えています。特に、FT8/FT4 の約3kHzの運用帯に WSPR の周波数が入り込むバンドでは、意図せず WSPR を妨害してしまう可能性があります。

WSPR は非常に狭い帯域を使っており、ほんのわずかな干渉でも多数のデコードが失われます。そのため、デジタルモード間の無用な衝突を避けるには、ユーザーの注意が欠かせません。

■ JTDXのWSPR保護機能

JTDX には、WSPRを保護するための仕組みが実装されています。

  • WSPRサブバンドに送信できないよう 送信ブロック

  • ワイドグラフの該当領域を オレンジ色で表示

このため、JTDXでは誤ってWSPR上に送信してしまうリスクが大きく低減されています。

■ 17m FT4の画面は「例」にすぎない

今回掲載したスクリーンショットは 17m FT4 のものですが、これはあくまで一例です。

実際には、すべてのバンドで同じ問題が起こり得ます。

FT8/FT4 の運用帯の中に、バンド割り当て上 WSPR が存在するケースがあるためです。

■ WSJT-Xユーザーは特に注意が必要

WSJT-X には以下の保護機能がありません。

  • WSPRサブバンドへの送信ブロック

  • 視覚的な警告表示(オレンジ帯)

そのため、WSJT-Xではオペレーターが自分で周波数をチェックしなければ、知らないうちに WSPR に被せて送信してしまうことがあります。これは「バンドポリス」ではなく、単なる運用上の注意喚起です。

■ まとめ

FT8/FT4 と WSPR は隣接した周波数帯に存在することが多く、注意して運用しないと互いに干渉してしまいます。

  • JTDXは強力な保護機能を搭載

  • WSJT-Xはユーザーの注意力に依存

  • これらの違いを理解し、特にWSJT-Xユーザーは 送信前に周波数を確認する習慣 を持つことが重要です。

少しの注意で、FT8/FT4もWSPRもより快適に運用できます。

スペクトラムを共有するすべてのユーザーが気持ちよく運用できるよう、ご協力をお願いします。

ご近所に新築物件ができそうなとき2025年12月07日 11時53分46秒

家庭用太陽光発電装置から発せられるノイズは、我々アマチュア無線の通信を妨害する可能性があります。自宅から半径100m以内に新築物件が立つ場合、太陽光発電装置の設置の有無は特に気になります。 半径100m以内の新築物件を発見した際に、調査先への問い合わせのフォームを作ってみました。

含まれている内容 文書タイトル 差出人情報(名前・コールサイン) 半径100m以内の新築物件に伴う確認依頼 アマチュア無線の特性(微弱電波・ノイズ脆弱性) 電波法82条・101条 パワコン(PCS)によるノイズ発生の説明 ご協力依頼(CISPR 11、施工相談可) 計画なしの場合の回答依頼 今後に役立つ知識である旨の一文 総務省 / JPEA / 住宅協議会 / NEDO へのリンク一覧 各人でアレンジしてご活用ください。 https://t.co/8DCsLxXyRm