rouggyandClaude Opus 5
82cd5c5d0b
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]>
166 lines
6.6 KiB
Markdown
166 lines
6.6 KiB
Markdown
# 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.
|
|
|
|
If you also run **GridTracker**, or anything else that listens to your decoder,
|
|
read [[Digital Modes and GridTracker]] first: two programs on one unicast port
|
|
work or not depending on which started first, which is the usual cause of
|
|
"the decodes arrived yesterday and not today".
|
|
|
|
A multicast group is an address between `224.0.0.0` and `239.255.255.255`.
|
|
`127.0.0.1` is not one — a row ticked *Multicast* with a loopback or LAN
|
|
address in the group box listens on unicast instead, and says so in the log.
|
|
|
|
> **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** | `<PST><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: <AZIMUT>{az}</AZIMUT><PATH>{path}</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.
|