rouggyandClaude Opus 5
82cd5c5d0b
HAMLOG.online was added after most profiles were configured, so it had no entry in the shipped defaults and no stored value either: it came back blank, and blank is not a status anybody chose. Every service now starts the same way — the sent side at R, the received side at N — and a blank left by a service that did not exist when the operator last saved is filled in from that. A status they chose themselves is untouched. Two tests hold the line: no sent side may default to Y, and no field may be left without a default. Y means "already sent", so it makes the uploader skip the contact for ever — an operator with eQSL Sent at Y had a logbook that never reached eQSL, and the only trace was one line in the application log. Wiki, both from operator reports: QSL Management opens with Confirmations — what the page actually is (the status stamped on every new QSO, not an action), what each status does, and the warning about Y in the plainest words available, because it fails silently and by design. Digital Modes and GridTracker is new. Unicast and multicast explained from the operating problem rather than the networking: one letterbox that two programs watch, against a broadcast everyone can tune to. It carries the real evidence — two starts of one station an hour apart, decodes in the second and none in the first, the only difference being whether GridTracker or OpsLog reached port 2237 first — then the settings for WSJT-X, JTDX, MSHV, GridTracker and OpsLog, the 127.0.0.1-in-the-group-box mistake, what to do if unicast is unavoidable, and how to check it from the log. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
5.9 KiB
Digital modes: WSJT-X, GridTracker and OpsLog together
Running WSJT-X (or JTDX or MSHV) with GridTracker and OpsLog at the same time is the normal digital station, and it is the setup that most often half-works: the decodes arrive one day and not the next, with nothing changed.
There is one cause and one fix. The cause is unicast; the fix is multicast.
Unicast and multicast, in one minute
WSJT-X does not know about OpsLog. It sends a stream of UDP messages — every decode, the DX call you are working, each QSO you log — to one address and port you give it. Everything else is just listeners.
Unicast is a message addressed to one place: 127.0.0.1:2237.
One letter, one letterbox. If two programs are watching the same letterbox, the operating system decides which one gets the letter — and it decides on the order they started, not on what you want. That is why it works after one restart and not after the next.
Multicast is a message addressed to a group: 239.255.0.1:2237.
A radio broadcast. Every program that has tuned to the group gets its own copy. No competition, no order, no luck.
Multicast is what WSJT-X offers for exactly this reason, and it is what you want as soon as more than one program listens to your decoder.
What it looks like when it goes wrong
Two starts of the same station, an hour apart, nothing changed in any setting:
06:43 autostart: GridTracker2 — already_running
06:43 udp: [Decodium] listening on unicast :2237
… not one decode all morning, though WSJT-X was running and logging QSOs
10:30 udp: [Decodium] listening on unicast :2237
10:30 autostart: GridTracker2 — launched
10:30 udp: emit udp:dx_call "JK2TTP" (mode=FT4 freq=21140000)
… decodes all the way through
In the morning GridTracker was already holding port 2237 when OpsLog started. In the second session OpsLog got there first. Same programs, same settings, and the only difference is who started first.
The setup that works
Pick one group and one port and give the same pair to every program.
239.255.0.1 port 2237 is the usual choice.
WSJT-X
File → Settings → Reporting, UDP Server box:
| Field | Value |
|---|---|
| UDP Server | 239.255.0.1 |
| UDP Server port number | 2237 |
| Outgoing interfaces | tick your LAN/Wi-Fi adapter and loopback |
| Accept UDP requests | ✔ ticked |
Outgoing interfaces matters and is easy to miss: with only the LAN adapter ticked, programs on the same PC may never see the traffic. Tick loopback too.
Accept UDP requests is what lets OpsLog answer a station for you and clear the DX call. Without it OpsLog still hears everything, but can only watch.
JTDX
Same place, same values — JTDX keeps WSJT-X's Reporting tab.
MSHV
Options → Settings → Reporting (WSJT-X protocol), same address and port.
GridTracker
Settings → WSJT-X / UDP: address 239.255.0.1, port 2237, multicast
enabled. GridTracker joins the group like everyone else instead of owning the
port.
OpsLog
Settings → Connections → Add:
| Field | Value |
|---|---|
| Direction | Inbound |
| Service | WSJT-X / JTDX / MSHV |
| Port | 2237 |
| Multicast | ✔ ticked |
| Group | 239.255.0.1 |
Save. The log should say:
udp: [WSJT-X] listening on multicast 239.255.0.1:2237 on 2 interface(s) (service=wsjt)
The mistake to avoid: 127.0.0.1 in the group box
A multicast group is an address between 224.0.0.0 and 239.255.255.255.
Nothing else can be joined.
127.0.0.1 is loopback — an ordinary unicast address — and it is a very
understandable thing to type, because it is what every other field in every
other program wants. But a row ticked Multicast with 127.0.0.1 in the group
box cannot join anything, and used to fail with a Windows message naming
nothing you had typed:
udp: [Wsjtx] join 127.0.0.1 on Wi-Fi 2: setsockopt: the requested address is not
valid in its context
udp: start "Wsjtx" failed: couldn't join multicast 127.0.0.1 on any interface
OpsLog now listens on unicast instead and says so, so the row still works — but if you meant multicast, put a real group in.
Rule of thumb: if the address starts with 127. or 192.168. or 10.,
untick Multicast.
If you have to stay on unicast
Sometimes you cannot use multicast — an old program, a locked-down network. Then only one program may listen on the port, and the others are fed by it:
WSJT-X ──unicast 2237──▶ GridTracker ──forward──▶ OpsLog (another port)
GridTracker can forward what it receives; point it at a different port, add a matching inbound row in OpsLog, and nothing competes. The one arrangement that never works reliably is two programs on one unicast port.
Checking it
- Settings → Connections — the row is enabled and its port matches.
- Help → Application log — one of these two lines appears at startup:
listening on multicast 239.255.0.1:2237 on N interface(s)✔listening on unicast :2237— fine only if nothing else listens there
- Tune to a busy FT8 frequency. Within a minute the log fills with:
udp: emit udp:dx_call "F5ABC" (mode=FT8 freq=14074000) - Nothing at all? In order: is WSJT-X's UDP server address the same group; is Outgoing interfaces including loopback; is another program holding the port; is Windows Firewall blocking OpsLog.
Not the same thing:
rigctld: sharing CAT on port 2237in the log is OpsLog's TCP CAT sharing for Hamlib clients. TCP and UDP ports are separate — it does not conflict with the UDP listener, however alike the numbers look.
Related
- Connections — every inbound and outbound row, and what each service does
- Logging Basics — what happens when a QSO arrives from WSJT-X
- Troubleshooting — where the log lives