rouggyandClaude Opus 5
d185b10559
Six outbound services, five documented. The missing one is the answer to the problem the digital-modes page had just finished describing: WSJT-X sends to one address, so without a relay the choice is between OpsLog and GridTracker rather than both — and OpsLog has been able to be that relay all along. Connections now lists it and explains the loop guard (pointing it at one of OpsLog's own ports would feed the stream back into itself, and it refuses) and that datagrams are passed on verbatim, with no origin header of the kind the receiving side has had to write code to survive. Digital Modes and GridTracker gains it as the unicast answer, which is better than the one it gave: OpsLog relaying to GridTracker on 2238 needs nothing from GridTracker and no multicast anywhere. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
186 lines
6.3 KiB
Markdown
186 lines
6.3 KiB
Markdown
# 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.
|
|
|
|
**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.
|
|
|
|
---
|
|
|
|
## 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
|