# 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

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.

---

## 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