rouggy
99599458ff
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.
116 lines
5.3 KiB
Markdown
116 lines
5.3 KiB
Markdown
# Troubleshooting
|
|
|
|
## Where's the log file?
|
|
|
|
OpsLog writes a diagnostic log. The path is shown in Settings (and can be
|
|
opened from there). When reporting a problem, include the relevant lines —
|
|
they're prefixed by subsystem (`cat:`, `Flex:`, `icom net:`, `antgenius:`,
|
|
`cluster:`, `qslmgr:log`, `audio:`…). With an SMTP server configured, **Help →
|
|
Send log to F4BPO** e-mails the logs straight to the developer.
|
|
|
|
A crash no longer leaves a blank window: the error is shown on screen,
|
|
selectable, with a copy button.
|
|
|
|
## CAT
|
|
|
|
- **Radio not connecting** — check the backend fields (COM port + baud for USB;
|
|
IP/credentials for network). The CAT log line carries the error explaining a
|
|
disconnection.
|
|
- **"Serial port busy" in the log** — another program holds the COM port
|
|
(WSJT-X, MSHV, another logger configured for direct CAT). Only one program
|
|
can own the port: let OpsLog hold it and point the others at **Hamlib NET
|
|
rigctl 127.0.0.1:4532** (Settings → CAT → Share CAT). Two masters on one
|
|
CI-V bus also cause garbled frames and erratic behaviour.
|
|
- **The radio transmits as soon as OpsLog connects** — your interface reads DTR
|
|
or RTS as PTT. Xiegu drops the lines automatically; on Yaesu and Kenwood
|
|
enable the *lower DTR/RTS on connect* option. (It is off by default because
|
|
other interfaces stop transmitting with the lines low.)
|
|
- **WSJT-X won't key a Xiegu G90 through OmniRig** — a G90 ignores the CI-V PTT
|
|
command. Use the native Xiegu backend (which keys RTS/DTR) + rigctl sharing,
|
|
or set the PTT line inside OmniRig. See [[Kenwood and Xiegu]].
|
|
- **OmniRig frequency frozen / wrong VFO** — set **VFO to read** (A or B) in
|
|
the OmniRig backend settings; some rig files declare the wrong VFO.
|
|
- **"OmniRig not found" with OmniRig running** — one of the two runs as
|
|
administrator and the other doesn't. Start both the same way.
|
|
- **Icom: no CAT at all over USB** — the CI-V address must match the radio;
|
|
pick your **model** from the dropdown (it sets the address) and set *CI-V USB
|
|
Echo Back* **OFF** on the rig.
|
|
- **A radio that answers oddly** — enable the **protocol trace** (Settings →
|
|
CAT): every frame to and from the rig lands in the log as hex, which turns a
|
|
guess into a diagnosis.
|
|
|
|
## Remote Icom
|
|
|
|
- **Login rejected** → wrong Network User1 name/password.
|
|
- **Can't bind local port** → the Icom **Remote Utility is still running** —
|
|
close it.
|
|
- **Frequency frozen after another program took the CI-V session** — OpsLog
|
|
reconnects on its own; if it doesn't, check the `icom net:` log lines. See
|
|
[[Remote Icom over the Internet]].
|
|
|
|
## FlexRadio
|
|
|
|
- **A control reads 0 / stale at startup** — some SmartSDR status fields use
|
|
short names. If a value never populates, capture the `Flex: … status` log
|
|
line and report it.
|
|
- **SmartSDR CAT keeps disconnecting while OpsLog is open** — fixed: OpsLog now
|
|
binds only to the actual SmartSDR/Maestro GUI client. Update.
|
|
- **"Interlock is preventing transmission" with a SteppIR** — see the tunable
|
|
range setting in [[Maps and Antennas]].
|
|
|
|
## Multi-op live status PHP
|
|
|
|
`Connection refused` from the PHP page is almost always MySQL `bind-address =
|
|
127.0.0.1` or a firewall/grant issue — see [[Multi-Operator Live Status]].
|
|
|
|
## DVK / PTT
|
|
|
|
- **Test PTT does nothing on CAT/OmniRig** — the key is held ~1.5 s so the
|
|
async OmniRig write is actually sent; if it still doesn't key, the rig's
|
|
OmniRig profile may not expose CAT TX keying — use RTS/DTR or VOX.
|
|
- **A voice message transmits almost nothing** — raise the message level
|
|
(Settings → Audio) and check the rig's rear-input setting (FTDX10: SSB MOD
|
|
SOURCE = REAR).
|
|
|
|
## Still stuck?
|
|
|
|
Open an issue (or *Send log to F4BPO*) with: what you did, what happened, your
|
|
radio/model, and the relevant log lines.
|
|
|
|
## The rig disconnects during digital transmissions
|
|
|
|
Symptom: with WSJT-X or JTDX set to **Fake It** split, the CAT link drops on
|
|
every over. Fake It shifts the dial for each transmission instead of using
|
|
split, so it changes the radio state twice per cycle.
|
|
|
|
Check that **no inbound Connections row shares a port with an outbound one**.
|
|
If it does, OpsLog receives what it publishes, and its own frequency broadcast
|
|
can come back as a command to re-tune — a loop that fires on every dial shift.
|
|
The log names the clash at startup. Give one of the two rows another port.
|
|
|
|
## A motorized antenna does not follow the rig
|
|
|
|
Look for this line in the log:
|
|
|
|
antenna: steppir connected, but TRACKING IS OFF in Settings — it will not
|
|
follow the rig, and only moves when you tune it by hand
|
|
|
|
That is not a fault. Tracking is a setting (Settings → Antenna), and with it off
|
|
the antenna only moves when you tune it yourself.
|
|
|
|
If the antenna genuinely stops answering, the log says so and reconnects on its
|
|
own:
|
|
|
|
steppir: status query failed, reconnecting: read status: timed out …
|
|
steppir: reconnected after 2 failed attempt(s)
|
|
|
|
## A rotator turns the wrong way
|
|
|
|
On a **SPID**, check the dialect first: **Rot1Prog** for the azimuth-only
|
|
controllers (RAK, RAU) and **Rot2Prog** for the RAS / BIG-RAS / MD-01 / MD-02.
|
|
They use different frame lengths, and the wrong one is the usual cause of a
|
|
heading that reads correctly while every commanded move goes the long way round.
|
|
|
|
Test with a **small** move first — from 45° to 50°, not to 180° — so a wrong
|
|
result cannot wrap the coax at the top of the tower.
|