fix(qsl): every confirmation service has a default, and the wiki explains them
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]>
This commit is contained in:
Claude Opus 5
@@ -0,0 +1,175 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user