If you run JTAlert, GridTracker, a logger and Hamilton Auto FT8 at the same time, you have probably met this: everything is configured correctly, nothing reports an error, and yet one program simply never sees a decode. From version 1.0.82 Hamilton can join a multicast group, and all of them can listen to WSJT-X at once. This guide explains why the old way failed, sets it up step by step, and covers what to check when it does not work.
Why a plain port could never be shared
A plain UDP port belongs to one program. When two programs bind the same port, Windows hands each arriving packet to exactly one of them — with no error and no warning. One program receives traffic, the other goes quiet and looks broken.
This is easy to prove: put two listeners on 127.0.0.1:2237, send ten packets, and you will find one received all ten and the other received none. Nothing was misconfigured. That is simply how a unicast port behaves.
A multicast group behaves the opposite way. It is not an interface, it is a group that programs join, and every socket that has joined receives every packet sent to it. That one difference is what lets Hamilton sit alongside JTAlert and GridTracker instead of competing with them for the port.
What you need
- Hamilton Auto FT8 1.0.82 or newer — earlier versions cannot join a group, and 1.0.80 and 1.0.81 could join one but sent their replies to the group itself, where WSJT-X is not listening, so it received every decode and never transmitted. Get it at autoft8.com/downloads
- WSJT-X 2.5 or newer, already working with your radio
- Any other programs you want to run alongside — JTAlert, GridTracker, your logger
You do not need to change anything on your router, and you do not need to open any firewall port. The traffic never leaves your computer unless you want it to.
Step 1 — Point Hamilton at a group
- Open Hamilton Auto FT8
- Go to Settings → Advanced
- In the Address box, type
224.0.0.123 - Leave Port at
2237 - Save, and restart Hamilton
The hint next to the Address box is worth remembering: 127.0.0.1 is local only, 0.0.0.0 is all interfaces, and 224.0.0.123 is multicast, to share WSJT-X with JTAlert or GridTracker.
Step 2 — Point WSJT-X at the same group
- In WSJT-X, go to File → Settings → Reporting
- Under UDP Server, set the server to
224.0.0.123 - Set UDP Server port number to
2237 - In Outgoing interfaces, tick Loopback — see the next section, this is the one that catches people
- Click OK
The Loopback tick box — read this one twice
WSJT-X sends multicast only on the interfaces you tick under Outgoing interfaces. If Loopback is not ticked, the packets go out to your network card and never reach the programs running on the same computer — which is every program in this guide. Everything then looks broken for no visible reason: no error, no warning, just silence.
If you take one thing from this page, take this: tick Loopback. If you are also feeding a program on another PC in the shack, tick that network interface as well — you can tick more than one.
Step 3 — Point everything else at the same group
Set every other program that listens to WSJT-X to the same address and port. There is no limit to how many can join.
- JTAlert — Settings → Applications / WSJT-X, set the UDP address to
224.0.0.123and port2237 - GridTracker — Settings → WSJT-X / UDP, same address and port
- Your logger — wherever it asks for the WSJT-X UDP server, same address and port
Step 4 — Confirm it worked
Start Hamilton and read its status line. In multicast mode it names the group and every interface it joined:
UDP proxy joined multicast 224.0.0.123:2237 on 127.0.0.1, 192.168.1.20; replies go straight back to the address WSJT-X sends from → FT8 engine inside Hamilton on 127.0.0.1:2238 (internal, nothing to set in WSJT-X)
The 2238 at the end is Hamilton talking to its own FT8 engine. It is internal, it is not the WSJT-X port, and nothing in WSJT-X refers to it.
If you are still on a plain address it says so instead, and you know at a glance which mode you are in:
UDP proxy listening on 127.0.0.1:2237 → FT8 engine inside Hamilton on 127.0.0.1:2238 (internal, nothing to set in WSJT-X)
Hamilton joins the group on every IPv4 address this machine answers on, loopback included. That is deliberate. Group license is per interface, and letting the operating system pick one means it picks the default route — on a laptop, Wi-Fi — so a WSJT-X sending on loopback would never be heard. Joining all of them costs nothing and removes an entire class of “it works on his machine” problem.
The other direction is worth knowing, because it is the opposite of what most people assume. WSJT-X never joins the group. It sends to the group from a port of its own and waits for answers at that port, so Hamilton replies to WSJT-X directly, at the address each packet came from — not to the group. That is why nothing on the WSJT-X side needs to “listen” to anything: ticking Loopback is about where WSJT-X sends, and that is the whole of its job.
The one rule: only one program may command WSJT-X
This matters more than anything else on this page.
Any number of programs can safely listen. Only one should command. If a second program also sends Reply packets to WSJT-X, it and Hamilton will compete for the transmitter and you will get behaviour neither of them intends — calls started and abandoned, the wrong station answered, transmissions cut off mid-sequence.
Receiving is free. Controlling is not. Let Hamilton do the commanding, and set the others to monitor only.
Which address should you use?
Anything from 224.0.0.0 to 239.255.255.255 is a multicast group, and Hamilton treats any address in that range as one. 224.0.0.123 is the address the FT8 community has settled on, so use it unless you have a reason not to — other software’s documentation will assume it too.
Hamilton sets the multicast TTL to 1, which means the packets stay on your local network and are never forwarded by a router. Your decodes are not going anywhere they should not.
Troubleshooting
“Port 2237 is already in use”
Something else already owns the plain port — usually JTAlert, GridTracker, or another copy of Hamilton. You no longer have to close it: this is exactly the problem multicast solves. Put every one of those programs on the same group and they can all have it. Changing Hamilton’s port also works, but then the programs are separated rather than sharing.
“Cannot bind to address — this PC has no such interface”
The address you typed is not one this computer answers on. Use 127.0.0.1 for local only, 0.0.0.0 for all interfaces, or a group such as 224.0.0.123 to share. On older versions this was the error you got for typing a group address at all — if you see it after typing 224.0.0.123, you are not yet on 1.0.82.
Hamilton says it joined, but no decodes arrive
- Is Loopback ticked in WSJT-X under Reporting → Outgoing interfaces? This is the cause the great majority of the time
- Is WSJT-X’s UDP Server set to the same group and the same port, with no typo?
- Did you restart WSJT-X after changing Reporting? Some builds only apply it on restart
- Is WSJT-X actually decoding? If its own band activity window is empty, the problem is upstream of all of this
Hamilton receives everything, but WSJT-X never transmits
If Hamilton logs decodes, says it is calling a station, and WSJT-X never goes into transmit, you are on 1.0.80 or 1.0.81. Update to 1.0.82.
Those two versions sent their replies to the multicast group. That sounds right and is not: WSJT-X does not listen to the group, it listens at its own address for answers to what it sent. The only program that heard those replies was Hamilton itself, which is why its log showed a “Reply packet received” line that was really its own packet coming back. Everything looked healthy at both ends, which is what made it hard to spot. 1.0.82 answers WSJT-X at the address it sends from, the same way it always has on a plain 127.0.0.1 setup. The explanation given for 1.0.81 — that it was a matter of which network interface the reply left by — was wrong, and this page said so; it has been corrected.
There is no workaround inside WSJT-X for this one; update.
A yellow “not sending UDP packets to Hamilton” notice, while the log fills with decodes
Before 1.0.82 Hamilton waited ten seconds after Start for the first packet, and WSJT-X only sends a heartbeat every fifteen — so if Start landed in a quiet moment the notice appeared, and it never went away on its own. From 1.0.82 the check waits twenty seconds, names the address you actually configured, and clears itself the moment packets arrive. If it stays up on 1.0.82, WSJT-X really is not reaching Hamilton: check the address and port in both programs, and the Loopback tick.
It works, but another program stopped working
That program is probably still on the plain port. Every program has to be moved to the group — a mixture of the two is exactly the situation multicast is there to avoid.
Going back
Put 127.0.0.1 back in the Address box, or use the Reset UDP to defaults button under Settings → Advanced. Nothing about multicast is permanent, and nothing changes unless you set that address — a normal 127.0.0.1 setup works exactly as it always did.
With thanks
This feature exists because Lonnie, N5DRG, wrote in describing the problem clearly and had already worked out most of the cause before he did. He then reported that 1.0.80 received everything and never transmitted, came back when 1.0.81 still did not, and sent the screenshot that showed the real cause. Three good catches in one week. Thank you, Lonnie.
You’re done
One group, one port, Loopback ticked, and only one program in command. Everything else can listen all it likes.
Download Hamilton Auto FT8 at autoft8.com/downloads. Stuck? Email support@autoft8.com.
73 and good DX.