docs(wiki): cover the recent work, with worked examples
Asked for the wiki to catch up, and to be explicit — examples rather than
descriptions. New page and six rewritten sections.
Recent QSOs and Filters, the page named in the request: the right-click menu is
now a table of what every entry does, and the filter builder has five worked
multi-criteria filters written out field by field, each ending in what you then
do with the result. Including the distinction that prompted it — "export
selected" takes the highlighted rows, "export filtered view" takes every QSO the
filter matched, and after building a filter it is the second one you want. Plus
the traps: ADIF date format, and "is empty" not being "equals N".
Connections (new): the page for a settings section that had none. What OpsLog
listens to and sends, which outbound row another logger actually wants — a
logger asking for "WSJT-X UDP" discards a bare ADIF record — the custom-message
triggers with their placeholder lists, three worked examples, and the port-clash
warning that produced this week's CAT-drop report.
Amplifiers and Switches: the generic HTTP relay in full — per-relay URLs, the
pattern form, {relay}, {relay-1} and {value} with what each one sends — relay
automatic control with a four-relay antenna-switch example, and the bench power
supply including why OpsLog writes only its output.
Rotators: the two new native types (SPID with the Rot1Prog/Rot2Prog choice,
DCU-1), two-rotor setups, and that Test only reads the heading on the types
where it does.
Awards: the US county database, and the difference between the automatic fill
(blanks only) and the right-click re-derive (replaces) — with the Connecticut
planning regions, which is the case that needs it.
QSL Management: QSL_VIA against QSL_SENT_VIA/QSL_RCVD_VIA, why an import shows E
on every Log4OM record, and that V counts as confirmed.
Troubleshooting: the three field reports of the last few days, by symptom.
Every [[link]] checked to resolve.
This commit is contained in:
@@ -0,0 +1,156 @@
|
||||
# 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** | `<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.
|
||||
Reference in New Issue
Block a user