Remote Station

Remote Station — operating your radio from anywhere

BETA. This is new and has not yet been used on the air by anybody. It keys a transmitter over the internet, so read the safety section before you leave the house. Please report what you find.

One OpsLog sits next to the radio. Another one — a laptop in a hotel, a PC at work, a shack across town — connects to it and operates it. The rig control and the audio both ways travel over a single link, on a single port.

It is not a screen-sharing trick and not a second program: the far end is a complete OpsLog, with its own logbook, its own cluster, its own band map. It simply has its radio somewhere else.

What you need

The station	the PC the radio is connected to (USB, serial, network — it makes no difference)
The operating position	any other PC running the same version of OpsLog
One port	forwarded on the station's router — TCP and UDP, same number. Or none at all, see Without opening a port
A shared secret	at least 12 characters, the same on both machines

Both ends must run the same OpsLog version. The link refuses a mismatch and says which side is older.

---

Setting up the station (where the radio is)

1. The radio, as usual. Settings ▸ CAT — pick your rig and confirm the frequency follows. If CAT does not work locally it will not work remotely.

2. Share it. Same page, tick Share CAT and choose the protocol “OpsLog remote station (CAT + audio)”. Set the port — 8300 is the suggested default.

3. The secret. Type a shared secret of at least 12 characters. OpsLog refuses to start the link without one, and this is not a formality: that port keys a transmitter from the public internet, and what is at stake is not your data but somebody else transmitting under your licence.

If you have set a vault passphrase (Settings ▸ Security), the secret is encrypted at rest with your other passwords.

4. The audio. Settings ▸ Audio — the two devices that face the radio:

• From radio — the rig's receive audio (its USB codec, or your interface)
• To radio — the input the rig transmits from (the same USB codec, its output side)

These are the devices the voice keyer and the QSO recorder already use. If they work for those, they work for this.

5. The router. Forward your chosen port to the station PC, TCP and UDP. They are two different sockets on the same number: the commands go over TCP and the audio over UDP, so one forwarding rule covers both.

---

Setting up the operating position (where you are)

1. Pick the radio. Settings ▸ CAT ▸ Radio → “OpsLog Master (remote station)”. That is the answer to “which radio do I have”: the one on the station's cable.

2. Where it is. Fill in:

• Station address — a public address (dyn.example.org), a LAN address, or an overlay one. All the same to OpsLog.
• Port — what you set on the station
• Shared secret — the same string

3. The audio. Settings ▸ Audio — the two devices that face you:

• Listening device — your headphones or speakers
• Recording device — your microphone

4. That is all. The band shows, the frequency follows, and the link panel under the settings says LINKED with the round-trip time.

---

How you transmit

There is no separate “remote transmit” mode. Every way you already transmit in OpsLog works, and each takes the right path on its own.

Phone (SSB, AM, FM)

Use the PTT key — Settings ▸ CAT ▸ PTT hotkey. Assign a keyboard key, and tick toggle so one press keys and the next unkeys. Toggle is the better choice on a remote: holding a key down for a long call is tiring, and a toggle is unaffected by key-repeat.

Configure it on the OPERATING POSITION, not on the station. The hotkey is a key press on the keyboard of the PC you are sitting at, captured by the OpsLog window in front of you. That instance then sends the command over the link.

A hotkey configured on the station responds only to its own keyboard — it is there for whoever is sitting in the shack, and it does nothing for you. You can set both; they are independent.

The key only works while the OpsLog window has focus. If you switch to a browser or to WSJT-X, the key does nothing — there is no system-wide keyboard hook.

Focus and the two modes behave differently, on purpose.

• Hold-to-talk: losing focus while holding unkeys the station. A keyup is never delivered to a window that no longer has focus, so without this the transmitter would stay up with nothing left to release it.
• Toggle: losing focus changes nothing. You stay on the air, you can go and look at something else, and you come back and press the key to unkey. That is what toggle is for — but remember the ten-minute cap below, and that your microphone is live the whole time.

Press it and three things happen: the station keys the radio, your microphone opens, and your voice goes over the link into the rig's transmit input. Release and all three stop.

You do not need to configure anything else. In particular you do not need a serial PTT line at your end — the hotkey uses CAT when a radio is connected, and on a remote link CAT is what reaches the station.

Your microphone is held open while the link is up, and Windows will show the microphone-in-use indicator. Nothing is sent until you press PTT — that is tested, and it is deliberate: opening the device at the moment you key would clip the first fifth of a second off every call.

CW

Type in the CW window or press your F-keys as usual.

The text travels, not the tone. The station has your keyer — WinKeyer, the serial keyer, or the Flex's CWX — and it is the station that keys the radio. So there is no latency in your CW at all: what goes over the internet is the message, and the timing happens next to the rig.

Keying by hand from the far end is not possible and never will be: your paddle's timing would arrive across the internet, and that is unusable.

Digital (FT8, FT4, RTTY, JS8…)

Run WSJT-X (or your program) on the operating position, exactly as if the radio were on your desk:

1. On the position, tick Settings ▸ CAT ▸ Share CAT with the Hamlib NET rigctl protocol. Yes — the position shares the radio it does not have. That is the point: it passes the commands on to the station.
2. In WSJT-X: Hamlib NET rigctl, 127.0.0.1:4532.
3. Route WSJT-X's transmit audio into a virtual cable (VB-CABLE and friends), and set that cable as Digital input in Settings ▸ Audio.
4. WSJT-X's receive audio: set its input to your Listening device, or route it through the cable's other side.

When WSJT-X keys, the station keys and OpsLog streams the cable to it. Your microphone stands down automatically for the duration — the two never mix, which matters, because a microphone mixed into an FT8 transmission puts your room on the air underneath the tones.

The voice keyer

Recorded messages are played by the station, from the station's own recordings. Press the message and the station plays it into the radio: nothing crosses the internet, so a called CQ is never chopped by a bad connection.

---

The four audio devices

There is no separate audio setup for the remote link: it uses the devices Settings ▸ Audio already names, the same ones the voice keyer and the QSO recorder use.

Where	Field	What it is
Station	From Radio	what the operating position hears
Station	To Radio	where the position's microphone is played
Position	Listening	your headphones
Position	Recording	your microphone

On a FlexRadio, From Radio is DAX RX 1 and To Radio is DAX TX, with SmartSDR running on the station. At the position a USB headset is Recording (its microphone) and Listening (its earpieces).

You do not need to press ▶ Listen to radio. That button is a local monitor — it plays From Radio through the Listening device of the same machine — and has nothing to do with the link. The audio flows as soon as the link is up and the four fields are set.

A radio with no sound card

An IC-7610 over Ethernet or a SunSDR over TCI hands OpsLog its audio directly, with no sound card anywhere in the path. For those, set From Radio to Radio (network audio) — the same choice the QSO recorder uses. No virtual cable is needed.

Transmit audio to such a radio is not carried yet: To Radio still wants a real output device. On an Icom that means the USB codec or a cable into the rear input.

When there is no sound at all

The audio goes over UDP, on the same port number as the control link, which is TCP. So the CAT can work perfectly while there is no sound — if you forwarded the port for TCP only, that is exactly what you get. There is no fallback onto the control link.

The log names the ordinary causes:

remote: no From-radio device set (Settings ▸ Audio) — the position will hear nothing
remote: no Listening device set (Settings ▸ Audio) — no receive audio
remote: the operating position is at 192.168.1.20:52104 — receive audio can flow

That last line is the one to look for: until the position has announced itself the station does not know where to send, and says so only once. If it never appears, no datagram is reaching the station.

---

The remote console

A Remote Console tab appears at the operating position once you are connected. It is the station's radio: signal, power out, SWR, band, transmit power, NR, NB, monitor and AGC.

It is one console for every radio, not the station's own panel sent down the wire. The station reduces whatever it has — Icom, FlexRadio, Yaesu, Elecraft/Kenwood or SunSDR — to the same set of controls, and converts each one back to its own radio when you move it. So it looks the same and works the same whichever radio is at the far end.

You can also dock it in the Main view like the other consoles: Preferences ▸ General ▸ Main view.

Controls your radio has not got are greyed, not hidden

The radios do not all do the same things, and the station says which its one can do. A control it cannot is still drawn, greyed, with the reason in the tooltip — a missing button would read as OpsLog being broken, where a greyed one tells you it is the radio.

What is actually missing, per radio:

	monitor	NB level	NR level
Icom	yes	yes	yes
FlexRadio	yes	yes	yes
Yaesu	—	—	yes
Elecraft / Kenwood	—	—	—
SunSDR (TCI)	—	—	—

Those are the commands OpsLog has for each radio today, not what the radio can do from its own front panel. The ones marked — are on the list.

The S-meter reads what the station's own console reads

It shows S-units, and it is not a guess made at your end. The radios report signal on scales that genuinely disagree: S9 is 47 on an Icom's scale, 50 on a Yaesu's, 6.5 raw on a K3 — and a SunSDR or a FlexRadio reports real dBm. The station sends the raw reading together with its own scale, so what you see is what the console next to the radio would show on the same signal.

The transmit meters follow the same rule: watts and a true SWR ratio where the radio reports them, and a 0-100 bar where that is all it has — an Icom answers only a bar, and it never says how many watts that bar means.

Band buttons

On an Icom or a Yaesu a band button recalls the radio's own band stacking register: you land on the frequency and mode you last used on that band, exactly as pressing the button on the front panel would. The other three have no band command, so OpsLog sends a frequency in the part of the band that matches the mode you are in.

Sliders on a slow link

Dragging a slider does not send a command per pixel. The panel holds the last value for a tenth of a second and sends that one, so the radio does not work through a queue behind your hand and land where you were a second ago. The control shows where you put it straight away; if the radio refuses the value it drops back within a second or so.

---

What the link panel tells you

It is under the settings on both ends, and it answers the questions that matter when something sounds wrong.

LINKED / NO LINK	is the far end there at all
… ms away	round trip. Under 60 ms feels like a local radio; 300 ms is workable on phone and will annoy you on a fast exchange
up 12m 30s	on the station: how long this position has been connected, and from what address
audio buffer	frames waiting to play. It should sit around 3. Climbing steadily means the two sound cards' clocks have drifted apart, not a network fault
lost / late	datagrams the network dropped or delivered too late. A handful an hour is nothing; a steady trickle is your connection

That split is the useful part: a buffer that grows is a clock problem and losses are a network problem, and knowing which stops you chasing the wrong one.

---

Safety: what happens when things go wrong

A transmitter keyed from somewhere else, with nobody in the room, is the one thing that can genuinely cause harm here. Three things guard it, and they do not depend on each other.

The link dies → the radio unkeys. Within about seven seconds of the last packet, the station gives up on the position and drops PTT unconditionally. It does not wait for a command, because a laptop that has lost its wifi cannot send one — the whole point is that the absence of traffic is what triggers it. A closed lid, a dropped connection, OpsLog killed at the far end: all the same.

One transmission cannot exceed ten minutes. That covers the other way of getting stuck, the one no link watchdog can see: a perfectly healthy link where you keyed and walked away. In toggle mode that is one keystroke away at any moment, and it does not merely leave a carrier up — your microphone keeps streaming, so it puts your room on the air.

Ten minutes is longer than any real over and short enough to bound an accident. If it ever cuts you off mid-sentence, that is the cap and not a fault — tell me and it becomes a setting.

Stopping the sharing unkeys too. Unticking Share CAT, or changing the port, drops PTT first.

Beyond that:

• One position at a time. A second connection is refused and logged with the address it came from. Two remote operators on one radio is two people turning the same dial.
• A remote position cannot touch the station's logbook or settings. The list of things it may ask for is explicit and short — frequency, mode, PTT, split, a spot, a CW message, a voice message — and anything else is refused.
• Every refused connection is logged with its address. A port that controls a radio will be probed; you are entitled to see it happening.

Check your licence. Remote operation is regulated differently from one country to another, and several require that you be able to stop the transmitter at any time. The guards above exist for that reason, but the obligation is yours.

---

Without opening a port on your router

You may not want to, and you may not be able to — many connections are behind carrier NAT, where port forwarding simply does not exist.

Install an overlay network such as Tailscale or ZeroTier on both machines and put the overlay address in the Station address field instead of a public one. Nothing else changes: OpsLog neither knows nor cares whether the address it dials is public, local or virtual.

This also gets you encryption twice over and removes the open port entirely, which is the better answer for most people.

---

Sound quality, and why

The audio is 8 kHz, mono, compressed about four to one — roughly 32 kbit/s each way. That works on a phone hotspot.

8 kHz is not a compromise: single-sideband speech lives inside 4 kHz, so this captures everything the radio can pass and nothing it cannot. Measured over the link, speech comes through at 21–26 dB signal to noise across the range where it has its energy, falling off towards 3 kHz.

Latency is roughly 200–300 ms one way: a little capture, a little buffer, a little network. Comfortable on phone, and the reason CW sends text rather than tone.

Do not monitor yourself through the radio. Your own voice would come back a third of a second late and be unusable. Listen to your own sidetone locally.

---

When it does not work

What you see	What it usually is
NO LINK, and the log says cannot reach the station	the port is not forwarded, the address is wrong, or the station's OpsLog is not sharing. Check TCP and UDP
NO LINK, log says wrong shared secret	the two secrets differ. Retype both
Log says protocol version mismatch	one side is an older OpsLog. Update it
LINKED, frequency follows, no sound	the station's From radio device is not set, or the position's Listening device is not. The log names whichever is missing at startup
LINKED, you transmit, the station shows TX, nobody hears you	the station's To radio device is not set, or your Recording device is not
Sound arrives chopped	look at lost on the link panel. If it is climbing, the connection is the problem, not OpsLog
Sound drifts later and later	look at audio buffer. If it climbs to the cap, the two sound cards disagree about what a second is — the buffer will trim itself, with a click
The rig console tabs do nothing	expected, see below
An operating position is already connected	somebody else is on the link, or a previous session has not timed out yet. Wait a few seconds

The station's log records every connection, every refusal and the address it came from. That file is the first place to look.

---

What is not there yet

The station's own rig console tabs — the full Icom, FlexRadio, Yaesu and Elecraft panels, with their scopes, notches, filter widths and every DSP setting the radio has — do not appear at the operating position. Use the Remote Console above instead: it carries the controls you reach for while operating, on any of the five radios. The rest stays at the station, where the radio is.

Not carried at all: the panadapter and waterfall. Spots you click still appear on the station's, but the picture does not come back.

Everything else works: the entry strip, the frequency and mode, PTT, split, the DX cluster, double-clicking a spot, the band map, the awards, the logbook, the decoders following the mode, and spots you click appearing on the station's panadapter.

Also not there: a relay service, so the two ends must be able to reach each other directly or through an overlay network.

---

See also

CAT Control · Audio and Keyers · Digital Modes and GridTracker · Security · Remote Icom over the Internet (a different thing: an Icom with its own Ethernet port, no second PC)