# Connections Settings → **Connections** is where OpsLog talks to other programs and to hardware over the network: what it **listens** to, what it **sends**, and messages you write yourself. It was called *UDP* until it grew a second transport — a row can now send an **HTTP GET** instead of a datagram, which is what most home-made antenna switches understand. Each row has a name, a direction, a service type, a port, and an on/off switch. **Everything sent and received is written to the application log**, so a row that does not work can be diagnosed rather than guessed at — see [[Troubleshooting]] for where the log lives. --- ## Inbound — what OpsLog listens to | Service | Sends it | Use | |---|---|---| | **WSJT-X / JTDX / MSHV** | those programs, port 2237 | Log their QSOs automatically, follow the DX call being worked, and show their decodes. Multicast is normal here. | | **ADIF over UDP** | JTAlert, GridTracker, FLDIGI | A text ADIF record per logged QSO. | | **N1MM Logger+** | N1MM | Its XML contact record. | | **Remote callsign** | DXHunter and similar | A callsign — and optionally a frequency and mode — to load into the entry form and tune to. | ### Multicast or unicast? WSJT-X and MSHV normally broadcast to a **multicast group** (usually `239.255.0.1`) so several programs can hear them at once. Tick *Multicast* and give the group. A program sending to one address only needs unicast — leave it unticked. > **Do not put an inbound row and an outbound row on the same port.** OpsLog > then receives its own messages, and something it publishes can come back as a > command. It says so in the log when it spots the arrangement: > *"X sends on port 2241 and Y listens on it — OpsLog will receive its own > messages there; give one of the two another port."* --- ## Outbound — what OpsLog sends | Service | Format | Fires on | |---|---|---| | **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 | | **PstRotator frequency** | `` | frequency change | | **N1MM RadioInfo** | N1MM's RadioInfo XML | frequency or mode change | | **Custom message** | whatever you write | a trigger you pick | ### Which one for another logger? If a logger says it accepts "WSJT-X UDP", it wants the **WSJT-X logged QSO** row — it listens on the WSJT-X interface and silently discards a bare ADIF record. Logger32 is the usual case. A logger that documents a plain ADIF listener wants the **ADIF message** row instead. They are two rows because they are two different things on the wire; enable the one your logger asks for, not both, or the QSO arrives twice. --- ## Custom messages The general case: **you choose when it fires, what it says, and how it leaves.** This is how a home-made antenna switch, a relay box or a home-automation server gets told what the station is doing. ### 1. Pick the trigger | Trigger | Fires when | |---|---| | **QSO logged** | a contact is saved | | **Band change** | the radio changes band — or, on a station with no CAT, the Band selector in the entry strip | | **Rotator command** | the antenna is told to turn (compass, SP/LP buttons, a spot click) | | **Lookup done** | a callbook lookup returns | ### 2. Write the message Anything in `{braces}` is replaced. What is available depends on the trigger: | Trigger | Placeholders | |---|---| | QSO logged | `{call}` `{band}` `{band_m}` `{mode}` `{grid}` `{name}` `{country}` `{rst_s}` `{rst_r}` `{comment}` `{date}` `{time}` `{freq_hz}` `{freq_mhz}` `{dxcc}` | | Band change | `{band}` `{band_m}` `{mode}` `{freq_hz}` `{freq_mhz}` | | Rotator command | `{az}` `{el}` `{path}` (`SP`, `LP` or empty) | | Lookup done | `{call}` `{name}` `{grid}` `{country}` `{qth}` `{state}` `{dxcc}` | `{band}` is `20m`; `{band_m}` is just `20`, because an antenna switch usually wants the number and nothing else. ### 3. Choose the transport - **UDP** — a datagram to an address and port. You choose the line ending. - **URL** — an HTTP GET. Values are URL-encoded automatically. ### Examples **Turn an antenna switch on every band change, over HTTP:** ``` Trigger: Band change Transport: URL URL: http://192.168.1.50/set?band={band_m} ``` 20 m → `http://192.168.1.50/set?band=20` **Tell a rotator display where the antenna is going:** ``` Trigger: Rotator command Transport: UDP → 192.168.1.77:8100 Message: {az}{path} ``` **Announce each QSO to a shack dashboard:** ``` Trigger: QSO logged Transport: URL URL: http://homeassistant.local:8123/api/webhook/qso?call={call}&band={band}&mode={mode} ``` > Credentials in a URL are sent as typed — this is meant for a LAN. Passwords > are **redacted in the log** so a log file can be shared safely. ### When a band change is a band change The Band-change trigger follows **the radio**, because an antenna switch should follow the radio and not what is being typed. Changing band in the entry strip drives the rig, the rig reports the new band, and the trigger fires from that. On a station whose rig OpsLog does not control there is nothing to report back, so the **Band selector itself** counts as the band change. The 🔒 lock on Band or Frequency suppresses it: a lock means the entry is deliberately decoupled from the rig, and nothing should move for a contact logged from last year. --- ## Diagnosing a row that does nothing The log names every message. In order, check: 1. **Is the row enabled?** The list shows it. 2. **`udp: Reload done — N server(s) running`** at startup, and one `cfg id=… name=… dir=… service=… port=…` line per row. A row that failed to start is listed with its error. 3. **Outbound:** `udp: [NAME] sent N bytes to ADDRESS (service)` for a datagram, or the URL for an HTTP row. 4. **A message that renders empty is skipped** and the log says so — usually a placeholder that the trigger does not provide. 5. **`a QSO was logged but no outbound "ADIF message" row is enabled`** — the answer to "why does my other logger get nothing". See also: [[Amplifiers and Switches]] for relay boards and their own automatic control, and [[DX Cluster and Spots]] for spot sources.