WSJT-X improved 3.1、かなりお勧めです。📡 ― 2026年05月16日 09時28分12秒
WSJT-X improved 3.1、かなりお勧めです。
私の実感では、デコード性能はすでに JTDX 2.2.159 と同等、場合によってはそれ以上と感じています。
FT8は、デコードできてなんぼの世界です。
デコードできなければ、そもそもQSOはできません。
見えなかった信号が見える。
拾えなかった局が拾える。
これはFT8運用ではとても大きいです。
デコード性能については、こちらの記事にまとめています。
asahi-net.or.jp/~vj5y-tkur/ft8
WSJT-X improved 3.1 は、20260228版からさらに進化し、現在は20260418版が公開されています。
さらに 20260516版もテスト版として出ており、開発は継続中です。
こちらには 20260228版と20260418版がありますが、今から使うなら 20260418版をお勧めします。
sourceforge.net/projects/wsjt-
20260516テスト版を試したい方は、こちらからダウンロードできます。
QMAP v0.7 関連のテスト版です。
sourceforge.net/projects/wsjt-
公開されている WSJT-X improved 3.1 がここまで進化している今、ベータテスター以外には非公開の JTDX rc版を無理に追いかけたり、こっそり使ったりする必要性は、少なくとも私には感じられません。
JTDX のUIに馴染みがある方は、まず AL_PLUS版を選ぶと入りやすいと思います。
最初は「少し使いづらいかな？」と感じるかもしれません。
でも、それはたいてい慣れの問題です。
使っているうちに、違和感はすぐ過去のものになります。
古いバージョンを使い続けている方も、ぜひ WSJT-X improved 3.1 へのアップデートを検討してみてください。
なお、私は現在、JTDX の AutoSeq や Wanted 機能に近い使い勝手を WSJT-X 3.1 improved 上で実現する JP1LRT版を作成中です。
まだ限定テスト段階ですが、かなり良いところまで来ています。
そのうち皆さんにもお試しいただけると思います。
どうぞお楽しみに。。
🚨 TQSLが突然でかくなった！そんな経験ありませんか？🚨 ― 2026年04月01日 12時16分40秒
ALL.TXT Is Not a Log. Until It's All You Have. ― 2026年03月05日 09時02分37秒
# Recovering Logs, Reclaiming Memories — Releasing ALLTXT2ADIF
Someone reached out to me once with a message that stuck with me.
*"My PC crashed. Lost everything. wsjtx_log.adi, gone. wsjtx.log, gone. All I have left is ALL.TXT. Is there anything I can do?"*
If you operate FT8 or FT4, you know what ALL.TXT is. That quiet file WSJT-X and JTDX keep writing to in the background. A raw decode history. Not an official log.
**ALL.TXT is not a log. But when you lose your log, it becomes the last piece of evidence you have.**
ALLTXT2ADIF was built to reconstruct QSOs from that evidence — and export them as a standard ADIF file.
This situation is more common than most operators realize.
---
## Before Writing a Single Line of Code
The first decision I made wasn't about code. It was about what *not* to build.
A tool that blindly converts ALL.TXT to ADIF is technically straightforward. But it would be wrong.
ALL.TXT is a record of *received signals*, not *completed QSOs*. Third-party decodes are in there. Multiple QSOs overlap on the same frequency. RR73 gets sent multiple times — that's just normal FT8. In a pileup, you can't always tell which station a 73 was even intended for.
Anyone who's spent serious time operating FT8 knows: careless recovery means a log full of errors.
So from the very beginning, this tool had one guiding principle:
**Every recovered QSO must be explainable. Not just output — explained.**
---
## The Night We Argued About Philosophy Instead of Code
The most memorable part of this project wasn't solving a technical problem.
It was a night when I told the AIs:
**"Stop. Don't write any code. I want to talk about approach."**
Where exactly does *strict* end and *lenient* begin? Under what conditions does an RR73 count as a completed QSO? What does *high confidence* actually mean? How far should the sanitize option go?
These weren't engineering questions. They were questions about operating philosophy.
And here's where things got interesting.
I couldn't put ChatGPT and Copilot in the same room. So I became the messenger. ChatGPT would propose a boundary. I'd copy it over to Copilot. Copilot would push back — *"that threshold is dangerous, here's an edge case you're missing."* I'd carry that back to ChatGPT. A revised proposal would come. Back to Copilot. And so on.
Round after round. I was the only hallway connecting two rooms full of very opinionated engineers.
The AIs were impressive — sharp, thorough, creative. But there was something they couldn't provide: the *feel* of actually operating FT8. The quiet satisfaction of a late-night DX contact finally going through. The frustration of watching RR73 after RR73 disappear into the noise. The instinct that says *"this doesn't look right"* when a decoded message seems off.
That experience doesn't live in a dataset. It lives in hours of operating time. And in the end, *that* was what settled every disputed boundary.
Once the philosophy was locked down, we moved to implementation: ChatGPT building, Copilot verifying and proposing patches. The cycle ran deep into the night.
---
## "Stop. This Is Good Enough." — What Claude Said in the Morning
Then I went to sleep.
The AIs don't sleep. But they do have context limits. Claude had quietly dropped out of the session somewhere around midnight — context window exhausted, silently gone. This happened more than once. (There's something almost poetic about that.)
In the morning, I brought Claude back up to speed and asked for a review.
After going through everything, Claude said:
**"If you keep going, you'll end up in a loop. The current implementation is sufficient. Stop here."**
That might have been the single most important piece of advice in the entire project.
There's a trap in software development: the feeling that there's always something more to improve. And if you follow that feeling indefinitely, you end up with something too complex to trust. Knowing *when to stop* is part of good design.
ChatGPT and Copilot had been pushing forward with real momentum. Claude was the one who put a hand up and said: *this is the finish line.*
That balance — the drive to build, and the wisdom to stop — is what made this project work.
---
## A Small Development Team
Looking back, the roles broke down something like this:
- **ChatGPT** — Architecture, design discussions, primary implementation. Opinionated, tireless, always willing to go another round. The project's architect and de facto PM.
- **GitHub Copilot** — Implementation verification, patch proposals, edge case hunting. The engineer who finds the holes you didn't know were there.
- **Claude** — Code review, safety checks, and knowing when enough is enough. The QA lead with a philosophical streak. *Also known for vanishing silently when the context window runs out.* (laughs)
- **Gemini** — External perspective, expression review. The outside voice that keeps things honest.
And my role was to be the one in the hallway — carrying ideas between rooms, adding the operating experience the AIs couldn't have, and making the calls that only a human with skin in the game could make.
---
## What Grok Said
After the release, I asked Grok to review the repository independently.
One line from that review stayed with me:
> *The design directly confronts the risk that ALL.TXT is not an official log, and the confidence + review CSV architecture — which makes every recovery decision explainable — is outstanding.*
The philosophy we'd argued about through the night had come through clearly, even to an outside AI reading it cold.
5 out of 5. "Essential tool for amateur radio operators" was the verdict.
---
## What This Tool Can Recover
ALLTXT2ADIF will probably sit unused on most operators' machines.
But the day a drive fails, or a file gets overwritten, or a system just dies — and ALL.TXT is the only thing left —
What's in that file isn't just data.
- The morning you worked your first European DX
- The contact you called for an hour before someone finally came back to you
- The contest run that went better than you expected
- The exchange with a station you'll never hear again
A log is more than a record. It's a history of time spent at the radio.
---
## One Last Thing
ALLTXT2ADIF was built where an operator's judgment and AI assistance found each other.
AI isn't a replacement. It's a collaborator — one that argues, proposes, builds, and occasionally tells you to stop. Working with these tools as genuine partners, not just utilities, changed how I think about what's possible.
One request: **always check the review CSV**. The final call is yours.
If this tool recovers even one log that would otherwise have been lost — that's a win for the whole team.
Download and source code:
**https://github.com/jp1lrt/alltxt2adif**
Stars, issues, and feedback are always welcome.
And perhaps this is the most important thing of all:
The best version of this story is one where you never need ALLTXT2ADIF. Back up your
The best version of this story is one where you never need ALLTXT2ADIF. Back up your
wsjtx_log.adi. Do it regularly. Do it now.73
JP1LRT / Yoshiharu Tsukuura
救えるログ、取り戻す"思い出" — ALLTXT2ADIF をリリースしました ― 2026年03月05日 08時47分34秒
# 救えるログ、取り戻す"思い出" — ALLTXT2ADIF をリリースしました
あるとき、こんな相談を受けたことがあります。
「PCがクラッシュして、ログが全部消えた。ALL.TXTだけ残ってる。何かできないか」
FT8をやっている人なら、ALL.TXTの存在はご存じだと思います。WSJT-XやJTDXが静かに書き続けるデコード履歴のファイル。
**ALL.TXTはログではない。しかし、ログを失ったとき最後に残る"証拠"になる。**
このツールは、その"証拠"から交信の形を推定し、ADIFとして復元するためのものです。
すべてを失った夜に、それだけが残っていた。そういうケースは、実は珍しくないんです。
---
## ツールを作ろうと思ったとき、最初にやったこと
コードを書き始める前に、まず「作らないこと」を決めました。
ALL.TXTをそのままADIFに変換するツールは、原理的には簡単に作れます。でもそれをやると、必ず問題が起きる。
ALL.TXTは「受信した信号の記録」であって、「交信の記録」ではないからです。第三者デコードが混ざる。同じ周波数に複数のQSOが重なる。RR73が再送されることなんて日常茶飯事。pileupのさなかでは、「誰に向けて送った73なのか」が判然としないことさえある。
FT8の現場を知っている人ほど、「雑に復元すると危ない」ことが分かります。
だからこのツールの根本にある設計思想は、最初からひとつだけでした。
**「なぜそれをQSOとみなしたのか、説明できること」**
---
## コードより先に、方針を議論した夜
今回の開発で、いちばん印象的だったのは技術的な難しさではありませんでした。
ある夜、私はAIたちにこう言いました。
**「今は何も作らなくていい。方針について話し合ってほしい」**
strict と lenient の境界をどこに引くか。RR73をどの条件で「完了」とみなすか。high / medium / lowの定義を何に置くか。sanitizeオプションはどこまで許容するか。
これらは「コードの問題」ではなく、「運用の哲学の問題」でした。
ここで私がやったのは、少し変わったことです。
ChatGPTに提案を出してもらい、それをコピペしてCopilotに見せる。Copilotが「その境界値は危ない、こういうエッジケースが抜ける」と返してくる。それをまたChatGPTに持ち帰る。ChatGPTが修正案を出す。またCopilotへ。
私はその**橋渡し役**でした。
AIどうしは直接話せない。だから私が間に立って、意見を運ぶ。まるで二人の優秀なエンジニアが別々の部屋にいて、私だけが行き来できる廊下にいるような感覚でした。
提案が来る。「それは運用現場ではこういうケースが起きる」と私が文脈を加えて返す。また提案が来る。「そのロジックだと、pileup時にこう誤爆する」と返す。完全なネゴシエーションが成立するまで、何往復も続けました。
AIたちは驚くほど提案力が高い。でもFT8の「現場感」——深夜に静かに積み上げてきたQSOの感触、あの周波数のにぎわい、RR73が返ってこない焦り——それはデータではなく経験です。最終的に「これを運用でどう扱うか」を決めるのは、やはり人間でした。
方針が固まったところで、ChatGPTに実装させる。Copilotが検証してパッチを提案する。そのサイクルを回しながら、深夜は更けていきました。
---
## 「もうここで止めていい」——朝、Claudeが言ったこと
そうして夜が明けて、私は眠りました。
AIたちは眠りません。でも文脈には上限があります。Claudeは深夜のセッションの途中でいつの間にか「離脱」していました。コンテキストウィンドウの上限に達して、静かにチームを抜けていく。これが何度かありました（笑）。
翌朝、改めてClaudeを呼び戻して、夜のやり取りをまとめて共有しました。
レビューを依頼すると、Claudeはしばらく考えてから言いました。
**「これ以上続けるとループに入ります。今の実装で十分です。ここで止めていい」**
これは、開発の中でいちばん重要なアドバイスだったかもしれません。
ソフトウェア開発には「やりすぎる」という罠があります。改善できそうなところは無限にある。でも、それを全部やると複雑になりすぎて、かえって壊れやすくなる。「何を入れないか」を決めることも、設計のうちです。
ChatGPTとCopilotが熱心に議論し続けている横で、Claudeが「もうここが完成点だ」とブレーキをかける。このバランスが、今回うまく機能したと思っています。
---
## AIたちとの"小さな開発チーム"
あらためて整理すると、今回の開発はこういう役割分担でした。
- **ChatGPT** — 設計整理、方針議論、実装の主担当。「こうすべき」という強い意見を持ち、何往復でも付き合ってくれるアーキテクト兼PM補佐。
- **GitHub Copilot** — 実装検証、パッチ提案、エッジケース指摘。黙々と手を動かしながら、穴を見つけてくる現場の開発担当。
- **Claude** — レビュー、安全性チェック、そして「やりすぎ警告」。職人気質のQA担当。*ただし文脈の上限に達すると静かにチームから離脱する*（笑）
- **Gemini** — 第三者視点での確認と表現整理。少し距離を置いた外部レビュー担当。
そして私の役割は、AIたちの橋渡しをしながら**方針を決めること**でした。
- 何を大切にするか（安全性と説明可能性）
- どこまでを「成立」とみなすか
- 不確実なものをどう扱うか
- いつ「止める」か
AIは提案できます。議論もできます。コードも書ける。でも「責任ある判断」を下すのは人間です。そこを最後まで握り続けることが、今回の自分の仕事でした。
---
## Grokが言った一言
完成後、Grokにもレビューを依頼しました。外部の目として。
返ってきた評価の中で、ひとつ刺さった言葉がありました。趣旨はこうです。
> 「ALL.TXTは公式ログではない」というリスクを正面から扱い、
> "なぜ成立とみなしたか"を説明可能な設計（confidence + review CSV）が秀逸。
狙っていた思想が、第三者のAIにも伝わった。これは素直に嬉しかったです。
評価は5/5。「アマチュア無線家必携レベル」という言葉もいただきました。
---
## このツールが救えるもの
ALLTXT2ADIFは、普段は使わないかもしれません。
でも、たった一度のクラッシュでログが消えたとき。そして**ALL.TXTだけが残っていたとき**。
そこに記録されているのは、単なるデータではありません。
- 初めてヨーロッパ局と繋がった朝
- 深夜にずっと呼び続けてようやく取ってもらえたDX
- コンテストで積み上げた足跡
- 誰かとの、もう二度と繰り返せない交信
ログは運用の積み重ねであり、思い出の集合体です。
---
## 最後に
ALLTXT2ADIFは、**実運用者の判断**と**AIたちの支援**が噛み合って生まれたツールです。
AIは「代わりに作る存在」ではなく、一緒に考えて、議論して、ときにブレーキを踏んで、磨き上げる仲間になり得る。今回それを強く感じました。
使うときのお願いがひとつ。
必ず **review CSV を確認してください**。最終判断は、あなた自身の目で。
もしこのツールが、誰かのログを救うことがあれば——
それはこの"小さな開発チーム"全員の成果です。
ダウンロードとソースはこちら：
スター、Issue、フィードバック、大歓迎です。
最後に、これがいちばん大事かもしれません。
このツールが不要で済むように、`wsjtx_log.adi` は普段からバックアップを取っておきましょう。
このツールが不要で済むように、`wsjtx_log.adi` は普段からバックアップを取っておきましょう。
73
JP1LRT / Yoshiharu Tsukuura
3Y0K Bouvet Island ― 2026年03月02日 13時12分14秒
How to Add a New Station Location in TQSL ― 2025年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.
LoTW復旧予定のお知らせが来ました ― 2025年07月02日 08時50分25秒
私は ARRL の会員ですのでメールが届きます
それによりますと
Eastern Daylight Time (EDT) で 7月2日の10時とあるので、日本時間では 本日、7月2日23時に復活ということですね。
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 を押して進めば終了です。
以上です。
NP2X からの依頼 ― 2024年10月27日 07時21分02秒
６ｍ Long Pathで入感するカリブの NP2X・Fredさんからの依頼です。
《JAの6mマンの皆さん、Gridなしで呼んでください》
とのことです。
ロングパスで開いたときはTx2 グリッド無しで呼んでください👍️
お願いいたします。
RK9UT 50MHz QSL ― 2024年06月07日 10時07分11秒
今年のRK9UT 50MHz QSO の紙製QSLカードも JA1BK 溝口氏がマネージャーで発行されるとの事です。
紙製カードが必要な方は JA1BK 溝口氏まで SASE + 2USD を早目にお願いいたします。
最近のコメント