# 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.
