Digital Modes and GridTracker

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, in both directions: with only the LAN adapter ticked, programs on the same PC may never see the traffic — and with only loopback ticked, nothing ever leaves the machine. Tick both.

On another PC on the network

This is what multicast is for, and it works: point OpsLog on the second machine at the same group and the same port, and its inbound row receives the same decodes. OpsLog binds to 0.0.0.0 and joins the group on every interface that is up and multicast-capable, and the log says how many it managed:

udp: [WSJT-X] listening on multicast 239.255.0.1:2237 on 2 interface(s)

Four things decide whether it arrives:

• The sender's outgoing interfaces must include the LAN adapter, per above. Loopback alone never leaves the PC running WSJT-X.
• The same subnet. Multicast does not cross a router unless the router is configured to carry it, which a domestic one is not.
• The firewall on the receiving PC has to let OpsLog receive UDP on that port.
• Wired beats Wi-Fi. Access points handle multicast unevenly, and that is the usual reason it works on one machine and not another with identical settings.

What crosses is the decodes and the logging. Anything that acts on the radio does not travel with them: the second OpsLog has no rig unless you give it one — the shared CAT port is 127.0.0.1, local by definition. For a station where the radio is on the other machine, see Remote Station.

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.

OpsLog can be the one that feeds them. Add an outbound Relay the WSJT-X stream row (Settings → Connections) and it re-sends every datagram it receives, byte for byte, to wherever you point it:

WSJT-X ──unicast 2237──▶ OpsLog ──relay──▶ GridTracker (2238)

Set GridTracker to listen on 2238 instead of 2237 and nothing competes for anything. Point the relay at the other program's port, never at one of OpsLog's own — that would feed the stream back into itself, and the relay refuses rather than let it.

It works the other way round too, if you prefer GridTracker to own the port: GridTracker forwards to a different port and OpsLog takes an inbound row there. Either order is fine. The one arrangement that never works reliably is two programs on one unicast port.

---

Checking it

1. Settings → Connections — the row is enabled and its port matches.
2. 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
3. Tune to a busy FT8 frequency. Within a minute the log fills with:

   udp: emit udp:dx_call "F5ABC" (mode=FT8 freq=14074000)
   

4. 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 2237 in 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.

---

Auto-call

Settings → DXHunter → Auto-call. OpsLog answers the best station on the air by itself, without you clicking it. This keys your transmitter without asking.

It answers one station at a time, never over a QSO already in progress, and it gives up on its own:

Brake	Default
Calls before giving up	7
… if the callsign is on your watch list	15
Its own transmit periods with no decode of it	3
Series per station	3
Rest between series, in the station's own overs	1
Held on one station, whatever the counters say	4 minutes

Every decision is written to the application log with its reason, and Halt stops it immediately.

Call only these: one or more callsigns, or one per line with wildcards (4S7*, */P), and nothing else is answered. A watched station is answered ahead of the criteria below. Leave it empty to call whatever the log needs.

Answering mid-exchange works on MSHV only — WSJT-X and JTDX drop that reply unsent. It puts you in the station's list of callers instead of waiting for a CQ, which is how a pile-up is worked by hand.

Which station it picks

In order of priority:

1. Any callsign on your watch list — and among those, the same ladder as below.
2. A new DXCC entity
3. A new band for the entity
4. A new mode for the entity
5. A new slot (band + mode never worked together)

A real need comes before one that exists only because a QSL never came. A station calling you is answered whatever the log makes of it. A station in the middle of a QSO with somebody else is never called — it cannot answer.

The filters steer the transmitter

With Call only what the decodes list is showing ticked — it is, by default — the filters above the FT decodes list apply to auto-call too: CQ only, LoTW only, the new-category chips, continents, the report threshold and the search box. A station filtered off the screen is not called. With the decodes list closed, auto-call is disarmed altogether.

When nothing is being called

Tick Log every decision. It writes one line per period to the application log: what was on the air, why each station was refused, and what was decided. That is a line every fifteen seconds, so leave it off the rest of the time.

"Can he hear me?" — the PSK Reporter panel

Beside the FT decodes, a panel answers the question you actually have while calling a station: is he decoding me at all?

Switch on PSK Reporter analysis in Settings → DXHunter. The panel then follows whichever station you are working — a click on a decode, or the DX call the digital program reports — and shows:

• reports about you received in the last ten minutes. The feed is alive even when the counters are zero, which is how you tell "nobody hears me" from "nothing is connected".
• his pile-up: the unique stations he decoded in the last two minutes. That is as close as you can get to the queue you are calling into — stations he decoded earlier have probably moved on.
• who near you he is hearing, so you can tell a dead path from a crowded one.
• the callers: stations in your own decodes calling him, with, in brackets, how many of them he has decoded — those are the ones actually reaching him.
• where his passband is free, for choosing an offset that is not on top of somebody else.

Each row reads decoded by him N seconds ago at D dB, and its offset is where the signal landed in his passband, not necessarily where the station was calling.

On the FT map, the same feed marks the stations reporting your own transmissions with diamonds, alongside what you decode. It watches a single topic — your callsign — so it costs almost nothing.

Only the band you are on: change band and the marks for the one you have left go, because they answer a question about a band the radio is no longer on. Come back to it and the reports still inside the fifteen-minute window are there again. With no CAT, and so no band to compare against, every report is shown.

Chase New — what is on the air near you

A panel listing the stations being decoded near you that are new against your log: a new entity, band, mode, slot, prefix or square. Digital modes only, since it is built from the PSK Reporter feed.

Bands here decides only what the panel lists — not what your station can work, which stays Modes & bands and still applies underneath. A band switched off here is dropped as it arrives, so it stops taking up a place in the list.

When is a square still NEW?

The grid-square scope decides when a square stops counting as new, and narrower means more squares to chase:

Scope	Demand
per band and exact mode	the most demanding
per band, any digital mode	in between
any band, any digital mode	the least

Chasing unconfirmed as well keeps a square wanted until a QSL, LoTW or eQSL confirmation arrives — until then it is still missing from the award, whatever the log says.

---

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