docs(wiki): the WSJT-X relay was missing from the outbound list

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

wiki/Connections.md

@@ -54,10 +54,36 @@ address in the group box listens on unicast instead, and says so in the log.
 |---|---|---|
 | **ADIF message** | a plain ADIF record | each QSO logged |
 | **WSJT-X logged QSO** | the same ADIF wrapped in a WSJT-X datagram | each QSO logged |
+| **Relay the WSJT-X stream** | every datagram received, byte for byte | as it arrives |
 | **PstRotator frequency** | `<PST><FREQUENCY>` | frequency change |
 | **N1MM RadioInfo** | N1MM's RadioInfo XML | frequency or mode change |
 | **Custom message** | whatever you write | a trigger you pick |
 
+### Relay the WSJT-X stream
+
+WSJT-X, JTDX and MSHV each send to **one address**. Without a relay the choice
+is between OpsLog and JTAlert / GridTracker, not both.
+
+This row re-sends every datagram an inbound WSJT-X row receives, **byte for
+byte**, to another program — so OpsLog stops being the reason you cannot run the
+two together:
+
+```
+WSJT-X ──▶ OpsLog (inbound, 2237) ──relay──▶ GridTracker (2238)
+```
+
+Point it at the **other** program's port. Pointing it at one of OpsLog's own
+listening ports would feed the stream back into itself for ever; the relay
+refuses and says so in the log rather than flooding the network.
+
+Nothing is added to the datagrams — no origin header. Some relays in the field
+prepend one (`127.0.0.1:2237|`), which is exactly the kind of thing OpsLog has
+had to write code to survive on the receiving side; passing it on downstream
+would be repeating that mistake.
+
+> If every program involved can do **multicast**, prefer that: each one gets its
+> own copy and no relay is needed. See [[Digital Modes and GridTracker]].
+
 ### Which one for another logger?
 
 If a logger says it accepts "WSJT-X UDP", it wants the **WSJT-X logged QSO**

wiki/Digital-Modes-and-GridTracker.md

@@ -135,15 +135,25 @@ 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:
+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──▶ GridTracker ──forward──▶ OpsLog (another port)
+WSJT-X ──unicast 2237──▶ OpsLog ──relay──▶ GridTracker (2238)
 ```
 
-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.
+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.
 
 ---