Remote Station

Complete operating environment — main window, rig control, rotator, DX cluster, waterfall, and audio decoder

Remote Station window

How It Works

Two instances of DL2CC-REMOTE-CW connect through the host's Station-ID (its callsign) plus a shared secret that you choose. The secret is processed locally on both sides and is never sent in the clear; together with the Station-ID it selects a private signaling channel. Because the Station-ID is part of that, a club can run several stations behind one secret and they still stay separate — and a caller needs to know both the host's callsign and the secret. Once both sides join the channel, WebRTC negotiates a direct or relayed media connection. Traffic then flows through that connection. On a known, well-connected network you can skip the relay and require a direct path — see Force Direct P2P on the Advanced tab.

Both roles use the same window. Select Host or Client with the radio buttons at the top before connecting. You cannot switch roles while signaling is active.

Setting Up a Connection

The home tab is where you set the shared secret that controls who can connect, plus your on-air callsign. It is labelled Stations when you run as Client — a live dashboard of the remote stations you can reach — and My Station when you run as Host, where you publish your own station's secret. Your callsign is required: it is your Station-ID in Host role (clients use it together with the secret to find you) and your Operator-ID in Client role (the identity the host sees). The top half changes with the role; the bottom half — your callsign and Note — is the same in both.

Windows Firewall Warning

⚠️ Windows Firewall prompt on first connect

The first time you click Connect on a PC, Windows may show a Windows Security dialog asking whether to allow the app to access public and private networks. This is normal — DL2CC-REMOTE-CW needs network access to reach the signaling server and establish the WebRTC media connection. Click Allow so the connection can be set up. If you click Cancel, remote operation will be blocked until you allow the app through the firewall.

The same prompt can appear again after you install a new version — Windows treats the updated program as a new app. On the host especially, expect it on the first connect after each update and simply click Allow again. See Updating DL2CC-REMOTE-CW.

Click Allow when Windows asks to grant network access on the first connect.

My Station tab — Host role

The My Station tab in Host role — your station's secret (masked) and a live status panel

A host station has exactly one identity. The top of the My Station tab shows your station's Secret as a row of dots — never the value itself — with an Edit secret (✎) button next to it. Together with your Station-ID (your callsign, in the identity area below) the secret defines the channel clients connect to. If no secret is set yet, the field reads "no secret set — click ✎ to set one" and the editor opens automatically the first time you visit the tab.

Click Edit secret to open a small dialog where you set or change the value:

• Secret — the passphrase that defines your station. Clients have to type the exact same value to reach you, including upper/lower case. Minimum eight characters. The value never leaves your machine — only a hash of it is used to derive the channel name. Allowed characters: letters (A–Z, a–z), digits (0–9) and the punctuation $ & % { } [ ] + - . , : ; _ # @ ! ? * = ~ ^; spaces and quotes are rejected, so a pasted secret can never pick up stray whitespace.
• Show — reveals the value while you check it; otherwise it stays masked.
• Generate — picks a random secret for you, using uppercase letters and digits only (skipping look-alikes like I, O, 0, 1) so it is easy to read aloud and to type. Copy it once and share it (through any out-of-band channel) with the people who should be able to connect.

There is deliberately no Delete in this dialog: you cannot delete your own station identity, only change its secret.

Below the secret, the My Station panel shows your station's live state, derived from who is present on your channel:

• Status — Offline (you are not hosting / not advertising), Online (reachable, nobody operating) or Busy (a client is connected and operating).
• Operating — the callsign of the operator currently on the air, or — when the station is free.
• Online — co-operators who are watching your station but are not on the air.

Release current operator ends the active operator's session and frees the station for the next client. Your station stays online the whole time — only that operator is dropped — so there is no gap in availability. The released operator is told their session was ended by the host: their client disconnects and shows Released by host in its window title. It is enabled only while the station is Busy.

Stations tab — Client role

The Stations tab in Client role — a live dashboard of the remote hosts you can reach

As a client you save the remote stations you use in one place and see their live state at a glance — before you even try to connect. Each row in the Remote hosts table is one station:

• Active (radio) — marks the station the Connect button on the Session tab will use. Click any row to move it. While you are connected the radios are greyed out — you cannot switch station in the middle of a session.
• Station-ID — the callsign of the host you want to reach (for example DL0AA or DL0AA/P). Required, and must match the host's Station-ID exactly — it selects which station you reach, so a typo lands you on a different (empty) channel. Entered in upper case; allowed characters are letters, digits and # - /. Click the cell to edit.
• Status — the station's live reachability, shown without connecting: Online (reachable and free), Busy (someone is operating it) or Offline (not currently hosting). A blank Status means the Station-ID or secret does not yet match a real station.
• Operator — when a station is Busy, the callsign of the operator currently on the air.
• Online — the other co-operators watching that station (their Operator-IDs). You appear here on the stations you watch, so everyone holding the secret can see who else is around.
• ✎ (Edit secret) — opens the secret dialog for that row: set or change the secret (the same passphrase as the host, with identical casing — the match is case-sensitive), with the same Show and Generate helpers as the host side, plus a Delete station button to remove the row. The secret appears only inside this dialog, never in the table.
• ▶ (Connect) — connects straight to that station; see Connecting to a station below.

Add a new host by typing the host's Station-ID into the blank row at the bottom of the table — a new entry is created and selected automatically; open its ✎ dialog to set the secret. Each entry also remembers which side windows (Keyer, DX Cluster, Aux Devices …) were open the last time you were connected to it, so reconnecting restores the same layout. Your callsign, Note and audio preferences are shared across all stations — only each station's Station-ID, secret and remembered-window list are per-station.

Reorder the list by dragging. Grab any row and drag it up or down to a new position — a blue line shows where it will drop, and the new order is remembered, so you can keep your most-used stations at the top. The pointer shows a move cursor over a row you can drag. Reordering is locked while you are connected. (Picking up a row also selects it, so it becomes the active station — the same as clicking it.)

Connecting to a station

There are two ways to connect from the Stations dashboard:

• One click from the dashboard — press the ▶ button on the station's row. It becomes the active station and the connection starts immediately. This is the quickest way to jump onto a station you can see is Online.
• Active radio, then Connect — select the station's Active radio, then press Connect on the Session tab. Use this when you want to review or change settings before connecting.

Either way, before the link is built the app checks that the station has a Station-ID and a valid secret (at least eight characters) and that your own Operator-ID is filled in; if anything is missing it opens the right editor so you can fix it, then press connect again. Connecting to a station whose Status is Busy is refused by the host (see Station already in use?) — wait until it shows Online. The first connect on a PC may also raise a Windows Firewall prompt (above); click Allow.

Your callsign and Note (both roles)

Below the secret area you find your own callsign and a note. The callsign field is the same control in both roles, but it is labelled to match what it does:

• Station-ID (Host role) / Operator-ID (Client role), required — your own callsign. Entered in upper case; allowed characters are letters, digits and # - /. In Host role it is your Station-ID, the callsign clients type to reach you. In Client role it is your Operator-ID, shown to the host once a beacon is exchanged. You cannot connect until it is filled in.
• Note (optional, multi-line) — a short message your partner sees alongside your callsign. Useful for things like "20m CW until 18:00" or "QRT after this QSO." Empty entries are fine — nothing is shown if you leave it blank.

Whatever you enter here and in Note is sent in the periodic beacon and shown on the other side at the top of the Operation tab next to the Connect button. Changes appear after a few seconds; no reconnect is needed. Your callsign, note, audio devices and other personal preferences are shared across all hosts — only each host's Station-ID, secret and remembered-window list are per-host.

Host side — at the radio

1. Open Operate → Remote Station from the dashboard.
2. Select the Host role. Your local-station identity is created automatically the first time you do this.
3. On the My Station tab, click Edit secret (✎) and type a secret (or press Generate in the dialog for a random one) — this is the passphrase clients will need to reach you. It never leaves your machine.
4. Fill in your Station-ID (required) — your callsign. Clients enter it together with the secret to reach you. Add a Note if you want to show a short status message.
5. Select which services to provide (Audio, CAT, rigctld, CW/PTT). Start with Audio at minimum.
6. Click Connect. DL2CC-REMOTE-CW joins the signaling channel and waits for the client.

The Settings → Host tab holds the cards that tell DL2CC-REMOTE-CW how to reach your radio and station hardware. They are described below in the order they appear, top to bottom.

RIG Connection Path — rigctld (Hamlib)

rigctld (Hamlib) is the main way DL2CC-REMOTE-CW reaches your radio, and it is needed for most functions — the Remote Control panel, frequency and mode readback, the client-side rigctld proxy that loggers connect to, click-to-QSY from the DX cluster, and waterfall retuning. Set this up first.

This card lets DL2CC-REMOTE-CW start Hamlib's rigctld.exe for you. Choose your radio model and port; the command line is built automatically and shown for reference.

Host settings — Local rigctld.exe launcher

Native CAT & existing rigctld — optional

The next two cards sit below the launcher and are optional — most stations run rigctld alone and can ignore them.

Use external rigctld service on the network — rather than have DL2CC-REMOTE-CW launch rigctld, attach to one that is already running (e.g. started by another program) at a given IP and port. Leave it off to let DL2CC-REMOTE-CW manage rigctld itself.

Host settings — use an external rigctld already running on the network (IP and port)

Connect optional additional CAT port (native CAT) — exposes the radio's native CAT protocol in addition to rigctld. Useful only if you have a second path to the radio and want a program to speak the rig's own CAT directly. If in doubt, leave it alone.

Host settings — optional native CAT path: COM or TCP

Rotator Control

Bridges the host to PSTROTATORAZ so the client can steer the antenna. DL2CC-REMOTE-CW never talks to rotor hardware directly — see Antenna Rotator Control for the full picture and the client view.

Host settings — Rotator Control (PSTROTATORAZ bridge)

Hardware PTT for Audio Modes

For voice and digital (audio) modes, the host decides how the radio is keyed, so the client never has to choose. The Hardware PTT for Audio Modes card on the host's rig settings tab selects the keying path and a safety timeout.

Host settings — Hardware PTT for Audio Modes: keying path and safety timeout

When you transmit in an audio mode, DL2CC-REMOTE-CW keeps the radio keyed until the buffered audio has actually played out on the host before releasing — so the end of every transmission is no longer clipped (important for SSB tails and FT8 decodes at the far end). The title bar shows a PTT countdown in the last 15 seconds before the safety timeout.

On the client, the Mic control on the Operation tab chooses when your microphone is streamed: Auto (only while you are transmitting), Open (always — needed for VOX), or Muted. Auto is the default and avoids sending audio when you are not transmitting.

Aux Devices — amplifiers, tuners & antennas

Each row connects one auxiliary device so the client can monitor and control it. Tick the device, set its port (and, where shown, its model or antenna); the status square turns green once connected. Every device is off until you enable it. See Aux Devices for what the client sees.

Host settings — Aux Devices: one row per amplifier, tuner or antenna controller

Waterfall sources

Three independent cards — ICOM, Kenwood and FlexRadio — choose where the panadapter data comes from. Enable the one that matches your radio (normally just one). Full details and the client view are under Waterfall Display.

Host settings — waterfall sources (ICOM / Kenwood / FlexRadio)

URL Switcher

Up to ten labelled buttons that fire an HTTP request when pressed — handy for web-controlled relays, antenna switches or smart plugs. Each row carries three visibility tick-boxes plus a label and a URL. See URL Switcher for how the buttons appear to the client.

Host settings — URL Switcher: ten rows, each a labelled button with its own URL

Enable remote PC shutdown

When ticked, the client may shut down the host PC remotely — useful for an unattended station so you can power it down at the end of a session. Leave it off if the host PC should not be shutdownable from the client. The square turns green when the feature is armed.

Host settings — Enable remote PC shutdown

Client side — your remote location

1. Open Operate → Remote Station from the dashboard.
2. Select the Client role.
3. On the Stations tab, look at the Remote hosts table. Either click the blank row at the bottom to add a new host, or pick an existing row by clicking anywhere on it.
4. Type the host's Station-ID (its callsign, for example DL0AA), then click the row's ✎ button and enter the same secret as the host you want to reach in the dialog (both must match the host exactly). The secret is shown only inside that dialog, never in the table. Watch the Status column — once it shows Online, the station is reachable.
5. Make sure the row for the host you want to connect to is the selected (Active) one — that is the host the Session tab's Connect will use. (Or skip straight to the connect by pressing that row's ▶ button.)
6. Fill in your own Operator-ID (required) and an optional short Note — the host will see them next to the Connect button once the session is up.
7. Click Connect. DL2CC-REMOTE-CW discovers the host through the signaling server and starts WebRTC negotiation.
8. Once connected, enable the services you want (Audio, CAT, rigctld, CW/PTT).

Next time you want to reach a different remote station, just pick its row in the table — there is no need to retype a secret. Each row keeps its own remembered side windows, so switching between hosts also restores each host's preferred window layout.

The Settings → Client tab collects the client-side endpoints that other programs on your remote PC connect to. The cards are described below, top to bottom.

Hamlib rigctld proxy

The main client endpoint: a local rigctld listener that Hamlib-aware programs (loggers such as N1MM+, Win-Test, fldigi …) connect to exactly as they would to a local rigctld. See rigctld / Hamlib.

Client settings — Hamlib rigctld proxy (top) and Client TS2000 emulator (bottom)

Client TS2000 emulator

A Kenwood TS-2000 CAT port for loggers that don't speak Hamlib (bottom card in the screenshot above). Reachable over a COM port or TCP. See TRX Emulator.

Client RIG CAT (1:1 CAT) — optional

An optional raw CAT byte tunnel straight to the host's rig, with no rigctld in between. Use it only for a program that must speak the radio's native CAT protocol directly; most loggers use the rigctld proxy above instead. See CAT Proxy.

Client settings — Client RIG CAT (1:1 CAT)

Wavelog Integration

Live frequency/mode sync to WaveLog plus automatic QSO upload from digimode programs. Full details under WaveLog Gateway.

Client settings — Wavelog Integration

Winkey Emulator & Winkey Proxy

A virtual Winkey COM port for any contest logger that speaks the Winkey protocol. With a DL2CC Box the Proxy relays Winkey to the Box; without one the Emulator keys the remote rig over WebRTC — the mode switches automatically. Full setup under Winkey Emulator & Winkey Proxy.

Client settings — Winkey Emulator & Winkey Proxy

The Client tab also has an advanced area for the jitter buffer and timing compensation — see Latency and Codec Selection.

Remote Station status panel — connection state, P2P/Relay indicator and active services

Reopen the Same Windows on Connect

Client side only. Whatever Remote-Connect child windows you have open at the moment you click Disconnect — Keyer, DX Cluster, Audio Decoder, Rotator, one or several Aux Device panels, Waterfall, Remote Control — are remembered and reopened automatically the next time you click Connect with the same secret. The list is stored on disk, so it survives an app restart: come back tomorrow, hit Connect, and your usual window layout returns by itself.

Some windows have prerequisites and reopen as soon as those are satisfied — Audio Decoder waits for the audio session to start, Rotator and Aux Device panels wait for the host to announce the corresponding service, Waterfall waits for the host's CI-V announcement. You don't have to do anything; they just appear once the host is ready.

Changing the secret clears the memory. A new secret usually means a different host, where the old window set no longer makes sense, so DL2CC-REMOTE-CW starts with a clean slate.

Start Directly into Remote Station

Normally you start DL2CC-REMOTE-CW from its usual icon and open Remote Station from the dashboard. If you run a fixed remote station, you can instead create shortcuts that open Remote Connect and connect automatically — reusing the host or client role, secret and settings from the last time you used it, and switching on always stay connected so the link keeps re-trying through network drops until it is up.

Open Remote Station → Advanced. Under Start into Remote Station shortcuts you'll find three checkboxes — tick the ones you want, untick to remove them again:

• Start menu entry — adds a normal DL2CC-REMOTE-CW (Remote Station) entry to the Start menu, next to the regular one.
• Desktop shortcut — puts an icon on the desktop for a one-click start straight into a connected station.
• Start automatically with Windows (auto-connect) — the station comes up and connects by itself every time you sign in to Windows. Ideal for an unattended host PC at the radio or a fixed client console.

Advanced tab — the Start into Remote Station shortcut checkboxes (Start menu, Desktop, auto-start with Windows).

Set the role, secret and the services you want once the normal way; these shortcuts then reuse them every time. Hardware detection still runs first, so the Box is ready before the connection starts. These shortcuts are optional — if you never tick a box, nothing extra is added, and you can remove any of them at any time by unticking it here.

Startup delay before auto-connect (s) — on the same Advanced tab you can set a delay of up to 120 seconds (0 = off). It applies only to the auto-connect launch: when the PC starts the station this way, the app first fires any URL Switcher On URLs (to switch your gear on), then waits the chosen time before opening Remote Connect — so USB COM ports, rig interfaces and any relay-switched equipment have time to come up after a fresh boot. A short countdown is shown while it waits. Normal (manual) launches ignore this setting; the On URLs still fire, but without a wait.

Optional: Windows Auto Logon for Unattended PCs

The DL2CC-REMOTE-CW Windows auto-start shortcut runs after a user has signed in to Windows. If a remote host PC should recover by itself after a reboot or power failure, Windows also needs to sign in to the station user automatically.

The most reliable way is Microsoft's Sysinternals Autologon tool:

1. Download Autologon from Microsoft Sysinternals.
2. Run Autologon64.exe as administrator.
3. Enter the Windows user name, domain or computer name, and password for the account that should run DL2CC-REMOTE-CW.
4. Click Enable and restart the PC to test it.

If you use a Microsoft account and Windows Hello, use the real account password, not the PIN. If auto logon fails, check the exact Windows user and computer name with whoami, and disable the setting that allows only Windows Hello sign-in for Microsoft accounts before enabling Autologon again.

WaveLog Gateway

When Sync to Wavelog is enabled on the Client tab of Remote Connect, DL2CC-REMOTE-CW starts a local WaveLogGate-compatible gateway on your PC. Any application that supports the WaveLogGate protocol (including the official WaveLog browser extension) can connect to it and receive live rig data — no server URL or API key needs to be entered in DL2CC-REMOTE-CW itself.

Gateway Endpoints

Data Format

All endpoints use the standard WaveLogGate JSON format:

{"freq": 14195000, "mode": "USB", "rig": "DTM Remote"}

freq is in Hz. mode reflects the current operating mode reported by the rig (e.g. CW, USB, LSB, FM). The gateway broadcasts an update every two seconds while a rigctld connection is active.

QSY from WaveLog

The WaveLog browser extension can send QSY commands back to the gateway. DL2CC-REMOTE-CW forwards these to the rig automatically via the active rig control channel — clicking a spot in WaveLog tunes the remote radio instantly.

Gateway Status

The Status tab in Remote Connect shows the gateway state next to Wavelog GW: Stopped when the gateway is not running, Running when active with no WebSocket clients connected, and Running (N client(s)) when one or more applications are connected via WebSocket.

Upload QSOs from MSHV / WSJT-X

DL2CC-REMOTE-CW can also push your logged contacts straight into WaveLog. When you finish a QSO in a digimode program — MSHV, WSJT-X, JTDX or FLDigi — the program broadcasts the contact on the local network, DL2CC-REMOTE-CW picks it up and uploads it to your WaveLog logbook automatically. Duplicate contacts are filtered out by WaveLog itself.

Enable UDP Listener for Wavelog on the Client tab of Remote Connect, underneath Sync to Wavelog. A small group of fields appears — the WaveLog Base URL and API Key (shared with the sync feature, shown just below the Sync to Wavelog switch), and the listener's own Listen IP, UDP Port and Station Profile:

• Base URL and API Key — your WaveLog address (e.g. https://log.example.com) and a personal API key from WaveLog (Account → API Keys).
• Listen IP — which local address the listener binds to. Leave it on localhost when the digimode program runs on this same PC; pick this computer's LAN address if the program runs on another computer in your network.
• UDP Port — the port the digimode program broadcasts to. The default is 4575; only change it if that port is already in use.
• Station Profile — click Refresh to load your station profiles from WaveLog, then pick the one your contacts should be logged against.

Upload activity (and any errors, such as a wrong URL or missing station profile) is shown on the Status tab and written to the debug log.

Service Overview

DL2CC-REMOTE-CW splits remote operation into six independent service layers. Each can be started and stopped while connected, without interrupting the others. The host automatically mirrors the client's active service set — if the client enables audio, the host's audio capture starts automatically. If the client disables it, the host stops.

Audio

DL2CC-REMOTE-CW uses WASAPI (Windows Audio Session API) for low-latency audio capture and playback on both sides. Audio is compressed with the OPUS codec before transmission — a codec designed for real-time voice over IP that handles varying network conditions gracefully.

The Audio settings tab adapts to the instance role. On the host the codec/preset controls are read-only (the client dictates the codec for each session); a source mode selector defaults to a single capture device but optionally lets a host operator pack two audio sources into one stereo stream. On the client the codec/preset controls are editable, a Mono blend slider lets the operator soften the L/R separation on receive, and a Binaural CW spatializer can pan each tone left or right by its pitch so close-spaced CW signals are easier to separate by ear.

Audio settings on the Client — device selection, audio mode, OPUS preset and mono blend are editable. The source mode row is hidden because the client always uses a single capture device.

Audio Source Mode — Single or Dual Host

By default the host captures a single audio device and sends it as the remote audio stream. This is the normal setup for one radio at the host site and needs no extra configuration.

As an optional extra feature, the host can capture two audio sources at the same time — typically two different radios — and pack them into a single stereo stream: source A goes to the Left channel, source B to the Right. The remote operator hears the first source in one ear and the second in the other. This is the standard SO2R-over-internet workflow, but it works equally well for any two mono inputs you want to keep separate (a radio plus a scanner, two receivers, etc.).

Switch the Audio source mode drop-down to Dual mono combine (two radios). A second device picker appears for source B and the first picker is relabelled Radio A (Left). Leave it at Single device for normal one-radio operation.

Audio settings on the Host with Dual mono combine active — Radio A (Left) and Radio B (Right) device pickers visible. Audio mode, OPUS preset and mono blend rows are disabled on the host because the client controls them.

• Pick a different physical capture device for A and B — the same device cannot be used twice.
• Dual-mono combine requires a stereo transport. If the client has selected a mono OPUS preset or Compatibility Mono (PCMU), the host will fall back to single-device mode for that session. Ask the client to switch to a stereo OPUS preset.
• The two audio devices have independent clocks, but source A drives the timing and source B is realigned on every 20 ms WASAPI callback. Typical USB sound cards drift by less than one sample per callback, so the correction adds no perceptible latency and no audible artefacts.
• Status events log a periodic drift summary (sample inserts and drops per 10-second window) for support diagnostics.

Mono Blend — Soften L/R Separation Client

When the host sends stereo (especially in dual-mono combine mode, where the two ears carry different sources), some operators want to blend the two channels toward mono — for example to listen on a single speaker, or to keep both sources audible in both ears with a softened directional cue.

The Mono blend slider on the client's Audio tab does exactly that. It applies a simple cross-mix to every inbound stereo frame:

• 0 % — original L/R untouched. Each ear hears only its own channel.
• 50 % — diffuse mix: each ear hears 75 % of its own channel and 25 % of the opposite channel. Both sources audible in both ears, directional cue preserved.
• 100 % — full mono mix. Both ears hear (L + R) / 2.

The setting is purely on the client side — the host is unaffected and need not know. The slider is disabled when the negotiated audio is mono (PCMU mono or OPUS mono preset) and when the local instance is the host, because both cases have no second channel to blend.

Binaural CW — Frequency-Positioned Stereo Client

CW signals close together in frequency are easier to copy when each one sits at a distinct point in the stereo field. Binaural CW takes the inbound audio and pans each tone left or right based on its pitch — lower tones move to the left ear, higher tones to the right, with the centre pitch staying in the middle.

Binaural CW controls on the Client — enable checkbox, stereo width slider, centre pitch and pan range, and a Swap L/R toggle for reversed-channel headphones.

Switch the effect on with the Binaural CW checkbox. The remaining controls fine-tune how it sounds:

• Centre pitch (Hz) — the frequency that stays exactly in the middle. Default 620 Hz, matching the DL2CC Box default sidetone, so signals you've tuned to zero-beat remain centred. Range 300–1200 Hz.
• Pan range (Hz) — the offset from the centre pitch that maps to the full left or right edge. Default 150 Hz: with a 620 Hz centre, a 470 Hz tone is fully left, a 770 Hz tone is fully right, and anything in between is panned proportionally. A smaller range concentrates the spread into a tighter pitch window; a larger range needs a bigger pitch difference to reach the extremes.
• Stereo width — scales the maximum pan magnitude. 0 % = pure mono (no spread); 100 % = full L↔R spread within the pan range. Useful to soften the effect without changing the centre or range.
• Swap L/R — flips low ↔ high so lower tones land on the right and higher tones on the left. Provided for listeners whose headphones, cable or audio routing are wired with reversed channels.

Binaural CW works on any inbound audio — both mono modes (PCMU, OPUS mono) and stereo modes (OPUS stereo, L16). On a mono inbound the spatializer expands the playback chain to stereo automatically. On a stereo inbound the channels are first folded to mono and then re-spatialised by frequency, which replaces the original L/R separation; that combination is offered as a user-choice rather than a recommendation. The effect adds about 22 ms of extra latency at 44.1/48 kHz (one FFT block) on top of the network jitter buffer.

All four binaural settings are persisted in the client settings file and restored on the next session. The controls are disabled in host role.

Audio Modes

Two transport modes are available. The mode is selected on the client side and pushed to the host automatically before the session opens.

Latency and Codec Selection

When Opus mode is selected, the Audio Preset dropdown offers 40 presets that combine a bitrate (8–48 kbps), channel count (mono or stereo), and one of four latency tiers. The tier controls the OPUS frame duration and jitter buffer depth — together these form the codec contribution to end-to-end audio delay. Your actual perceived latency will be this figure plus your one-way network propagation time (roughly half the round-trip time shown by a ping to the host).

Choose the tier based on the stability of your network path, not just its speed. A stable fibre or cable connection can use Low or Medium. Mobile data, VPN tunnels, satellite, or any path with variable packet timing benefit from High or Very High — the larger jitter buffer absorbs burst losses without audible dropouts, at the cost of extra codec delay.

Within any latency tier, a higher bitrate improves receive audio quality at the cost of more bandwidth. For typical HF receive audio, 12–16 kbps (mono or stereo) is a good choice. For SSB/AM monitoring where audio fidelity matters, step up to 24–32 kbps. The 40–48 kbps stereo presets are for wideband listening on a fast link.

If audio is choppy or breaking up, increase the tier one step at a time and allow 10–15 seconds for the connection to stabilise after each change. If latency is already acceptable but audio sounds thin or compressed, try a higher bitrate within the same tier.

Recommended Audio Workflow — DL2CC Box as Monitor

For the best CW operating experience on the client side, route the PC audio output into the DL2CC Box rather than listening through PC speakers:

1. With the client-side DL2CC Box connected to DL2CC-REMOTE-CW, open Hardware Settings → Audio / Codec and make sure Mix Enabled is On (default). Pick a Mix Mode — Digital gives you the Line In filter and a software volume slider, Analog uses the codec's hardware bypass path. Set Line-In Mix Volume and, in Digital mode, the Mix Filter band to taste. Without this, the Box won't pass the PC audio to your headphones.
2. Connect a 3.5 mm stereo cable from the PC headphone or line out to the Box's Line In Mix jack. Alternatively, pair the PC to the Box via Bluetooth Audio (requires WiFi off on the Box).
3. On the client PC, open the Remote Station Settings → Audio tab and set the playback device to the sound card output that physically feeds the Box — i.e. the device whose headphone or line-out jack the cable from the previous step is plugged into.
   Tip: Some sound cards expose the headphone output as a separate device that only appears in the Windows playback device list once a cable is plugged in — which is exactly why we connect the cable first. If the expected entry still isn't there, close the Remote Station window and reopen it so DL2CC-REMOTE-CW re-enumerates the playback devices.
4. Plug your headphones into the Box's headphone jack.
5. The Box now mixes the remote receive audio with its own hardware-generated sidetone in analogue or digital mode — you hear both in your headphones simultaneously.

This is the key advantage: the sidetone is generated entirely in the Box hardware with no audible latency, even though the remote audio travels over the internet. The operating feel is almost identical to sitting at the radio.

Set the receive audio level and the sidetone mix in the Box itself — see Hardware → Audio / Codec Tab for the relevant level controls. We recommend a PC headset with its own inline volume control and the following approach: drive the Box at a high output level and use the headset's volume knob as an attenuator. That way the noise floor of the headset amplifier sits well below the signal, and you can dial back the overall level to a comfortable listening volume without losing dynamic range.

Rig Control

DL2CC-REMOTE-CW offers two independent, parallel approaches to rig control. Choose one or both depending on what your station software expects:

CAT Proxy

The CAT Proxy is a transparent byte tunnel: every byte the rig sends is forwarded to the client, and every byte the client sends goes back to the rig. DL2CC-REMOTE-CW has no knowledge of the rig protocol — it simply moves bytes in both directions over the WebRTC "cat" data channel. No Hamlib, no rigctld.exe needed.

Both the host and client endpoints can be either a COM port or a TCP port, independently. Examples: host COM3 → client TCP 4573 (logging software connects via TCP localhost). Or host TCP 4572 (existing CAT server) → client COM5 (legacy app).

Host setup

1. Connect the rig's CAT cable to the host PC and note the COM port (or TCP address of an existing CAT server).
2. In the Remote Station window (Host), expand the CAT section.
3. Select COM or TCP, enter the port/address and baud rate.
4. Enable the CAT service.

Client setup

1. In the Remote Station window (Client), expand the CAT section.
2. Select whether to expose the rig as a COM port or TCP port locally.
3. Enable the CAT service. DL2CC-REMOTE-CW starts listening on the selected port.
4. Point your logging or CAT software at that local COM or TCP port.

rigctld / Hamlib

Hamlib is an open-source library that speaks the native CAT dialect of over 300 different transceivers. Its network daemon, rigctld, connects to the rig via COM port on the host PC and exposes a simple text-based TCP server (default localhost:4532). Clients send universal commands like \set_freq 14195000 and rigctld translates them for the specific rig model.

All three rigctld-based features in DL2CC-REMOTE-CW require rigctld.exe to be running on the host PC before enabling the rigctld service. They all share the same WebRTC "rigctld" data channel, multiplexed by an internal command hub that queues requests and routes responses exclusively back to the originating consumer.

1. Go to Remote Control - Settings - Host
   
2. Select your transceiver model, COM Port, Baud rate (leave default listen port at 4532 if you don't have another rigctld.exe running on your PC).
   
3. For ICOM Transceivers: Check "VFO" mode and enter the CIV address for your transceiver in 0x form like 0xB2. You can check the address in the menu of your ICOM transceiver
4. Check "Start rigctld.exe with this command line" to let DL2CC-REMOTE-CW automatically launch the bundled rigctld.exe when the rig proxy starts. The generated command line always binds rigctld to localhost (-T 127.0.0.1) so it is not accessible from the network.
   

Using an already-running rigctld: If you already have rigctld running as a service or started manually, check "Use external rigctld service" instead. Enter the IP address and port of that service. The two options are mutually exclusive — enabling one automatically disables the other.

MANUAL Host setup

1. Install Hamlib on the host PC.
2. Start rigctld for your transceiver model, e.g.:
   rigctld -m 229 -r COM3 -s 9600  (Kenwood TS-2000 on COM3)
3. In the Remote Station window (Host), enable the rigctld service and confirm the port (default 4532).

Virtual COM Ports

Some logging or CAT software only supports a physical COM port and has no TCP client option. If your client application cannot connect directly via TCP, you can bridge the gap with a virtual COM port pair: two COM ports that appear as real serial ports to Windows, with data written on one side arriving on the other.

Two common scenarios where this is useful:

• CAT forwarding — the client-side CAT Proxy exposes a TCP port, but your logging software only speaks COM. The bundled com0com pair connects the logger's COM port to DL2CC-REMOTE-CW's COM port.
• WinKey Proxy — the bundled COM25/COM26 com0com pair lets logger software talk Winkey while DL2CC-REMOTE-CW keeps full control of the Box over USB.

DL2CC-REMOTE-CW setup can install com0com and create the port pairs for you. No separate VSPE purchase or manual virtual-COM setup is needed for the standard configuration.

Port pairs created by setup

DL2CC-REMOTE-CW Remote Control Panel

The Remote Control window is DL2CC-REMOTE-CW's own virtual radio front panel, built on top of the rigctld service. Open it from the Remote Station window while connected. It works identically in both Host and Client roles — the connection wiring is handled internally and is transparent to the user.

DL2CC-REMOTE-CW Remote Control panel — VFO, mode, levels, and CW memories

What you can control

How VFO A, VFO B and Split work

The panel follows the classic receive on A, transmit on A or B model. A few points are worth knowing before you tune:

• You always listen on VFO A. The large amber display is your receive frequency. The knob, mouse wheel, +/− buttons, band buttons and direct entry all move VFO A.
• VFO B is a second frequency store, not a second receiver. Pressing VFO B does not switch your receiver to B — it simply points the tuning controls at the VFO B value so you can set it. Press VFO A again to return to normal tuning.
• SPLIT uses VFO B as your transmit frequency. With split on you receive on VFO A and transmit on VFO B — the classic setup for working a DX station that listens up. Turn split off to transmit on VFO A again.
• The RX / TX tags under the VFO labels show this at a glance: RX always sits under VFO A; TX sits under VFO A when split is off and moves under VFO B when split is on. These tags reflect the actual state read back from the radio, not just your button press — so the TX tag moves under VFO B a moment later, once the rig confirms the change.

Frequency Tuning

Several input methods are available for changing the VFO A frequency. All of them go through the same tuning pipeline, so the step size set with the STEP buttons applies to the mouse wheel and the +/− buttons alike.

RIT / XIT and Frequency Offset

The RIT and XIT buttons enable receive or transmit incremental tuning. Once active, use the offset row (−500 … +500 Hz buttons) to shift the receive or transmit frequency relative to the displayed VFO. The current offset is shown between the buttons. Click CLR to zero the offset without disabling RIT/XIT.

Rig Monitor

All commands sent and responses received by the Remote Control panel are logged to the Rig Monitor tab in the Remote Station window. This is useful for diagnosing unexpected rig behaviour or verifying that a command was actually received.

Remote Control — TX & CW tab with PTT SOURCE selector and CW keying controls

Remote Control — CW memory macros

Remote Control — audio filter settings

Remote Control — antenna tuner controls (with the X-VERTER transverter switch, shown on supported Icom models)

Spacebar PTT

While the Remote Control window is focused, press and hold Space to assert PTT — release to drop it (hold-to-talk). Enable Hold Mode to change this behaviour: each press of Space then toggles PTT on and off instead of requiring the key to be held down.

PTT Source

How the radio is keyed for audio (voice/digital) modes is now chosen once on the host, under Hardware PTT for Audio Modes — the Remote Control panel no longer has a per-panel PTT SOURCE button. The host applies the selected path automatically and keeps the radio keyed until the audio tail has drained before releasing, so transmissions are never clipped.

TRX Emulator

The TRX Emulator is a client-side Kenwood TS-2000 CAT emulator. It runs inside DL2CC-REMOTE-CW and exposes a TS-2000-compatible interface on a local COM port or TCP port. Your contest logger or logging software connects to it exactly as if a real TS-2000 were plugged into that port. Frequency and mode data are fed from the host rigctld via the WebRTC channel.

TRX Emulator vs. rigctld Proxy

Setting Up for N1MM+

1. On the client, enable the TRX Emulator (TCP) in the Remote Station window. Note the TCP port.
2. In N1MM+, open Config → Configure Ports → Radio.
3. Set the radio type to Kenwood TS-2000.
4. Set the address to localhost and the port to the TRX Emulator TCP port.
5. N1MM+ now reads frequency and mode directly from DL2CC-REMOTE-CW over TCP — no virtual COM port software required.

Setting Up for Win-Test / other loggers (COM mode)

1. Enable the TRX Emulator (COM) in the Remote Station window and select a virtual COM port from the drop-down. With the bundled com0com setup, select the DL2CC side of the TRX Emulator / TSEMU pair, normally COM23.
   
2. In your logger, configure a TS-2000 rig on the other port, normally COM24, at the matching baud rate.

CW Keying & PTT

When the CW/PTT service is active, DL2CC-REMOTE-CW captures your keying from the local DL2CC Box on the client side and transports microsecond-precision timing edge timestamps to the host's DL2CC Box, which keys the radio. This is not a decode-then-re-encode process — your exact timing, including every nuance of your fist, travels to the radio.

Advanced tab — minimum jitter buffer, connection routing (Force direct P2P), and the Start into Remote Station shortcuts. Available on host and client.

Input Sources

Footswitch PTT (SSB Mode)

Connect a footswitch to the DL2CC Box footswitch input. Pressing the footswitch asserts PTT at the remote radio — ideal for SSB operation with a PC headset and microphone. The footswitch signal is debounced in the Box firmware before forwarding.

Jitter Buffer & Latency Compensation

When you key CW remotely, the precise timing of each dit and dah travels over the internet from the client DL2CC Box to the host DL2CC Box. Network connections are never perfectly steady — packets may arrive a few milliseconds early or late compared to each other. Without compensation, this jitter would distort your CW timing and make your sending sound choppy on the air.

The DL2CC Box firmware solves this with a jitter buffer: when the first keying data arrives from the remote side, the Box waits for a short time (the buffer duration) to collect a small batch of timing edges before it starts playing them back to the radio. This initial pause absorbs the variation in network delivery, and a virtual clock inside the firmware then plays the edges back at exactly the right intervals — reproducing your original timing faithfully, without drift, even during long transmissions.

Automatic Latency Measurement (PING / PONG)

The host automatically measures the round-trip time (RTT) between the host and client DL2CC Boxes using a PING/PONG mechanism. Only the host sends measurements and sets its device's jitter buffer; the client displays the values in the Status tab and title bar.

1. When the CW/PTT service starts and the connection is established, the host sends a STARTPING:NOW command to its local DL2CC Box.
2. The Box sends a PING message (containing a timestamp) through the WebRTC connection to the remote Box.
3. The remote Box immediately echoes the timestamp back as a PONG response.
4. The originating Box measures how long the round trip took (e.g. 45 ms) and reports the result. The host application then computes the optimal jitter buffer using its sliding-average algorithm (see below) and sets it explicitly via TX:CACHE.

Adaptive Tuning

A single measurement can be misleading — the internet is not always equally fast. The host therefore repeats the PING measurement every 30 seconds and keeps a rolling window of the last 5 measurements. Instead of reacting to any single reading, the buffer is set from the typical value of that window plus a safety margin, so a brief blip does not disturb a healthy connection.

Spikes are checked before they count. Some connections — Starlink in particular — occasionally produce a single very slow ping (for example a jump from 60 ms to over 1000 ms) when the satellite link briefly reconfigures. When the host sees a reading that is far above the recent norm, it does not trust it straight away: it immediately re-measures with one or two extra pings. If those come back normal, the odd reading is thrown away and the buffer is left untouched. Only if the high latency is confirmed does the buffer react — and even then it rises gradually rather than jumping to the maximum, so one bad moment can no longer leave you with a large buffer for minutes afterwards.

The host sends the computed jitter buffer value to the client automatically via the signaling channel. On connect, the current value is pushed immediately so the client title bar is up to date right away — no need to wait for the next measurement cycle. In addition, every time a new PING result arrives, the host forwards its full RTT statistics to the client, so both sides always display the same live roundtrip information in their Status tab.

To avoid interference with active CW keying, the automatic PING measurement is skipped whenever CW traffic was detected within the last 5 seconds. This ensures the measurement reflects idle network conditions rather than a loaded data channel.

Optimize Jitter Buffer

The Optimize Jitter Buffer dropdown on the Advanced tab lets you choose how the automatic tuning balances low latency against protection from dropouts. The buffer itself is always calculated on the host (the station with the rig and the DL2CC Box), but both sides can express a preference: the client's choice is sent to the host, and the host then uses the more protective of the two. In other words either side may ask for a bigger safety margin, but neither can force a smaller one on the other — the same idea as the Minimum Jitter Buffer below. There are three settings:

• Low-Latency — keeps the buffer as small as possible and rejects spikes most aggressively. Best for good, stable connections, or for links like Starlink where the occasional huge ping is almost always a brief glitch and you want the shortest possible keying delay.
• Balanced (default) — a sensible middle ground that suits most connections.
• Robust — keeps a more generous buffer and lets it grow faster when latency really does climb. Best for genuinely poor or highly variable connections where you would rather have a little extra delay than risk choppy CW.

Minimum Jitter Buffer

The Minimum Jitter Buffer dropdown in the CW/PTT settings section lets you set a floor that the adaptive algorithm will never go below. Values range from 20 ms to 1000 ms in 10 ms steps. The automatic measurement still runs in the background, but the computed value will always be at least as high as your minimum setting.

Both the host and client have their own independent minimum setting. If the client changes their minimum, it is sent to the host automatically. The host then uses the higher of its own minimum and the client's minimum as the effective floor — neither side can lower the other's preference.

Force Direct P2P (No TURN Relay)

By default, when DL2CC-REMOTE-CW cannot establish a direct link between the two stations, it automatically falls back to a TURN relay server so the connection still succeeds (see How P2P Works Behind NAT Routers). The relay always works, but it adds latency because all traffic is routed through a third server instead of travelling directly between host and client.

The Force direct P2P (no TURN relay) checkbox on the Advanced tab removes the relay from the connection. With it enabled, only direct paths are used — your local network addresses plus the public address discovered through STUN (NAT hole-punching). STUN itself is still used, so the connection can still traverse typical home routers; only the relay fallback is removed.

CW Keyer & Digital Voice Keyer (DVK)

The CW Keyer provides 10 programmable memory buttons (F1–F10) for sending CW macros — CQ calls, 5NN, your callsign, contest exchanges, and more. The Digital Voice Keyer (DVK) adds 10 voice message slots for SSB operation. Open it from Operate → Keyer on the dashboard.

CW Keyer & DVK window — F1–F10 memory buttons and voice slot controls

CW Memory Buttons (F1–F10)

• Each button stores a free-text CW macro. Edit by clicking the label next to the button.
• Common variables are supported — use your callsign, contest serial number, etc.
• WPM and sidetone frequency are adjustable directly in the Keyer window.
• During remote operation, macros are transmitted through the active CW/PTT service over WebRTC to the host Box, which keys the radio.
• Locally (no remote connection), macros play through the DL2CC Box sidetone or PC audio.

Digital Voice Keyer (DVK)

• 10 audio message slots — record voice messages for CQ, 5NN, exchange, QSL, 73, etc.
• Press a slot button to play the recorded message. PTT is asserted automatically for the duration of playback.
• Space key = PTT — while the Voice Keyer tab is focused, hold Space to assert PTT and release to drop it (hold-to-talk). Enable Hold Mode to toggle PTT on and off with each press of Space instead of holding it down.
• During remote operation, DVK audio is routed through the WebRTC audio service to the remote station.
• Recording length is configurable in File → Settings.

Keyboard Shortcuts from Other Windows

During remote operation, focus often sits on the Waterfall or Remote Control window rather than the Keyer. DL2CC-REMOTE-CW routes the most important keyboard shortcuts automatically, so you never have to click back to the Keyer in the middle of operating:

PTT for the Voice Keyer

The Voice Keyer no longer has its own PTT-path toggle. Voice and digital playback key the radio through the same path chosen on the host under Hardware PTT for Audio Modes, so the keyer, live voice and the footswitch always key the radio the same way — and the keyer's tail is held until the audio has drained, so the end of each message is not clipped.

Keyer Settings — speed and Command Receiver toggle

DVK Voice Slots — record and label up to 10 SSB voice messages

Command Receiver (N1MM+ Integration)

The Command Receiver lets external logging software such as N1MM+ trigger DL2CC-REMOTE-CW voice messages directly from F-key macros — without touching the mouse. During a contest, your logging macros play the correct voice message at the right moment while you focus entirely on the keyboard and keyer.

Step 1 — Enable the Command Receiver in DL2CC-REMOTE-CW

1. Open the Keyer form in DL2CC-REMOTE-CW.
2. Go to the Settings tab.
3. Switch the Command Receiver (UDP 50444) toggle to ON.
4. The status line confirms: Command Receiver: enabled (UDP :50444).

This setting is saved automatically. DL2CC-REMOTE-CW will start the listener automatically on next launch as long as the toggle remains on.

Step 2 — Copy the companion tool

The companion executable is included in the DL2CC-REMOTE-CW installation folder at:

Resources\DL2CC-REMOTE-CW-COMMANDRECEIVER\DL2CC-REMOTE-CW-COMMANDRECEIVER.exe

Copy DL2CC-REMOTE-CW-COMMANDRECEIVER.exe to a permanent location that N1MM+ can reach — for example:

C:\N1MM+\DL2CC-REMOTE-CW-COMMANDRECEIVER.exe

Step 3 — Configure N1MM+ function key macros

In N1MM+, open Config → Config Ports, Mode Control, Winkey, etc. and select the Function Keys tab, or open the Function Key Messages editor directly. For each F-key that should trigger a voice message, add a macro using the {RUNPROGRAM} tag:

A typical N1MM+ F-key entry looks like this — you can mix the {RUNPROGRAM …} tag with normal CW message text in the same macro:

5NN {RUNPROGRAM C:\N1MM+\DL2CC-REMOTE-CW-COMMANDRECEIVER.exe VOICE 1}

Voice message slots

Record your voice messages inside DL2CC-REMOTE-CW on the Voice tab of the Keyer form. Enable Record Mode, then press any F-key button (F1–F10) to record a message for that slot. The same slots map directly to the VOICE 1–VOICE 10 commands sent by N1MM+.

Give each slot a short label in the Name field (e.g. CQ, 5NN, TU) so you can identify them at a glance during a contest.

PTT during voice playback

When a voice message is triggered by the Command Receiver, DL2CC-REMOTE-CW follows the same PTT logic as when you press the button manually:

• If a DL2CC Remote CW Box is connected, PTT is asserted via the box before playback and released when the file finishes.
• If rigctld PTT is enabled on the Settings tab, PTT goes through the rigctld channel instead.
• A safety timeout of 60 seconds prevents transmitter lock-up if something goes wrong.

Troubleshooting

For more detail when something doesn't work, see the Log tab further down this page — its Debug view shows the verbose internal log including every Command Receiver event.

Winkey Emulator & Winkey Proxy

DL2CC-REMOTE-CW provides a Winkey-compatible virtual COM port so any contest logger that speaks the Winkey protocol can key CW during a remote session. The mode — Proxy or Emulator — is chosen automatically based on whether a DL2CC Box is connected; you only need to enable the feature and pick a COM port.

Setup

1. During setup, select the com0com virtual COM port option, or rerun setup and add it later.
2. In DL2CC-REMOTE-CW, open Operate → Remote Station and select the Client role.
3. Go to the Settings → Client tab and scroll to the Winkey Proxy card.
4. Select the DL2CC side of the Winkey pair (normally COM25) from the dropdown, then tick Enable Winkey.
5. In your logging software, set its Winkey port to the external side (normally COM26). In N1MM+ this is under Config → Config Ports, Mode Control, Winkey, etc.

DL2CC-REMOTE-CW detects whether a Box is connected and activates the appropriate mode automatically. The two modes are mutually exclusive — enabling one stops the other.

Winkey Proxy — Box connected via USB

When a DL2CC Box is connected via USB serial, DL2CC-REMOTE-CW takes over that serial port to run the full DL2CC protocol at 115200 baud. Your logger can no longer use that port directly for Winkey. The Winkey Proxy solves this: it listens on the virtual COM port, translates Winkey binary to DL2CC commands, and forwards them to the Box — so your logger gets Winkey, and DL2CC-REMOTE-CW keeps full control of all other Box features (sidetone, PTT, macros, remote CW transport).

Winkey Emulator — no box at client

When operating remotely without a DL2CC Box at the client location, the Winkey Emulator provides a software Winkey device at the same virtual COM port. Your logger connects as usual, and the emulator translates Winkey commands into TX keying edges that are transmitted to the remote host over WebRTC. The host's DL2CC Box then physically keys the rig.

Status Monitoring

The Status tab in Remote Connect shows the current state:

The status panel also shows byte counters (bytes received from the logger and responses sent back) so you can verify data is flowing in both directions.

Audio Decoder

DL2CC-REMOTE-CW includes a software CW decoder that can receive audio directly from the Remote Station audio stream or from any Soundcard audio stream which exists on your PC (when opened standalone in the main menu). When the remote station connection is active, enable use remote audio in the Audio Decoder and it will automatically feed from the incoming WebRTC audio — no additional cables or sound card routing required.

Audio Decoder — FFT spectrum display with adaptive CW signal detection

How the Decoder Works

The decoder performs a 4096-point FFT on every 10 ms audio window and analyses the spectrum around the selected centre frequency. It measures the signal-to-noise ratio (SNR) and applies hysteresis thresholds to classify each window as signal-on or signal-off, building a sequence of timing elements that are then decoded by the same engine used for hardware input.

Using the Audio Decoder with SDR / WebSDR

1. In Windows Sound settings, enable Stereo Mix or use the bundled VB-Audio VB-CABLE to route your SDR output to a recording device.
2. In the Audio Decoder, select that device as the input source.
3. The decoder picks up and decodes any CW present in the audio stream.

Waterfall Display

For compatible transceivers DL2CC-REMOTE-CW can display a live spectrum waterfall directly inside the application. Three vendor families are supported today: ICOM (CI-V scope stream over USB or LAN), Kenwood TS-890S / TS-990S (KNS scope stream over LAN), and FlexRadio 6000-, 8000- and Aurora AU-series (SmartSDR API over LAN — TCP control plus a VITA-49 UDP panadapter stream).

Waterfall Display — live spectrum with click-to-QSY

Features

• Live spectrum display — see the band activity in real time, just like on the rig's own screen.
• Click to QSY — click anywhere on the waterfall to immediately tune the remote radio to that frequency via the active CAT or rigctld service.
• DX Cluster spot overlay — when the DX Cluster window is open, live spots are drawn directly on the spectrum as labeled markers. Click any marker to QSY instantly. See DX Cluster Spot Overlay below.
• ICOM scope Mode & Edge dropdowns — for ICOM rigs only, switch the scope display mode (Center / Fixed / Scroll-C / Scroll-F) and the fixed-mode edge straight from the waterfall toolbar. See Host — ICOM.

Setup

Waterfall configuration is a host-only setting. Once the host has configured the rig connection, any client that connects will automatically be able to open the waterfall window — no additional configuration required on the client side.

The Host settings page contains three waterfall cards — ICOM Waterfall, Kenwood Waterfall and FlexRadio Waterfall — and they are mutually exclusive: only one vendor can be announced at a time. Enabling one automatically disables the others.

Host — ICOM

1. Connect the ICOM transceiver to the host PC via USB or Ethernet (depending on model).
2. Ensure the rig's CI-V LAN or USB interface is enabled in the rig's menu.
3. In the Remote Station window, open Settings → Host and scroll to the ICOM Waterfall card.
4. Tick ICOM Waterfall Support, select the correct ICOM Model, and enter the rig's CI-V Address.
5. The waterfall becomes available to all connected clients automatically once the session is active.

Host — Kenwood TS-890S / TS-990S

The Kenwood adapter uses the KNS (Kenwood Network Service) interface built into the radio. KNS carries both rig control and the scope stream over a single TCP connection, so no extra serial cabling is needed for the waterfall itself.

1. On the radio, enable KNS and create an admin-level KNS account (the radio's menu calls these User Profiles). Note the account name and password.
2. Make sure the radio is reachable on your LAN — the host PC must be able to open a TCP connection to the radio. Default KNS port is 60000.
3. In the Remote Station window, open Settings → Host and scroll to the Kenwood Waterfall card.
4. Tick Kenwood Waterfall Support, select the Model (TS-890S or TS-990S), and enter the radio's IP address, the KNS port, and the account / password you configured on the radio.
5. The host runs the KNS session as a background service. It starts as soon as you click Connect and is torn down cleanly on disconnect or when you change any of the Kenwood waterfall settings.

Host — FlexRadio (6000-, 8000- and Aurora AU-series)

The FlexRadio adapter uses the SmartSDR API built into the radio. SmartSDR is a multi-client network protocol — DTM connects directly to the radio on the LAN and creates its own panadapter, so it coexists peacefully with the SmartSDR client (or any other SmartSDR-aware software) running at the same time.

1. Make sure the Flex is reachable on your LAN — the host PC must be able to open a TCP connection to the radio. Default SmartSDR port is 4992.
2. The radio's SmartSDR API does not require login on the LAN, so there are no credentials to enter.
3. In the Remote Station window, open Settings → Host and scroll to the FlexRadio Waterfall card.
4. Tick FlexRadio Waterfall Support, select the Model (any FLEX-6xxx, FLEX-8xxx, or Aurora AU-series — they all share the same SmartSDR API, so the dropdown is for display only), enter the radio's Host IP and the Port (default 4992).
5. The host runs the SmartSDR session as a background service. It starts as soon as you click Connect and is torn down cleanly on disconnect — the panadapter is removed from the radio so no slot is left dangling.

Client

No setup needed. Connect to the host as normal and open Operate → Waterfall from the Remote Station window. The waterfall stream is provided automatically by the host, regardless of which vendor adapter the host is running.

DX Cluster Spot Overlay

When the DX Cluster window is open and receiving spots, those spots are drawn as live markers directly on the spectrum. Each marker shows the callsign and a colored frequency tick at the exact spot frequency. No setup is required — the overlay activates automatically whenever both windows are open at the same time.

• Show all vs. filtered — the Spots button in the waterfall toolbar switches the overlay between two modes. Spots: All draws every spot received from the cluster, independent of the column, band, mode, and age filters set in the DX Cluster window. Spots: Filtered mirrors the DX Cluster list, so only spots passing those filters appear. Switching the button refills the overlay immediately — backfilling the extra spots or dropping them — and your choice is remembered between sessions.
• Click to QSY — click anywhere on a spot's label — first letter to last — and the radio tunes straight to that spot's exact frequency, via the active CAT or rigctld service. Clicking open spectrum away from any label still tunes to the point under the cursor.
• Cursor change — as the mouse pointer enters a spot label, the crosshair cursor changes to a hand pointer to indicate a clickable target.
• Hover tooltip — hovering over a label shows a tooltip with the full spot detail: callsign, frequency, date & time, spotter, and comment.
• Last seen (age expiry) — the Seen: button next to Spots sets how old a spot may be before it is removed from the overlay. Click it to cycle through Off, 5, 15, 30, and 60 minutes. This is the waterfall's own age limit and applies in both Spots: All and Spots: Filtered modes, independent of the Max Age set in the DX Cluster window; your choice is remembered between sessions. With Seen: Off the waterfall applies no age limit of its own — in Spots: Filtered mode the cluster still pre-filters spots, so the overlay never shows more than the DX Cluster list, while in Spots: All mode the overlay keeps every received spot.
• Band deduplication — if the same callsign is re-spotted on the same band, the earlier spot is replaced by the new one. Spots for the same callsign on different bands coexist independently.
• Staggered labels — labels that would overlap on adjacent frequencies are placed in offset tiers so no callsign obscures another.
• Edge clamping — when a spot falls near the left or right edge of the display, the callsign label is shifted inward so it remains fully readable, while the frequency tick stays at its exact spectral position.

DX Cluster

DL2CC-REMOTE-CW includes a built-in Telnet DX Cluster client. During remote operation, open it from Operate → DX Cluster alongside the Remote Station window. Both windows can be open simultaneously with no interference.

DX Cluster window — live spots with click-to-QSY to the remote radio

Connecting to a Cluster

1. Open Operate → DX Cluster from the dashboard.
2. On first use, open the Settings tab and enter your callsign. If you skip this step and click Connect without a callsign, DL2CC-REMOTE-CW will take you there automatically.
3. Select a server from the drop-down list at the top of the window. DL2CC-REMOTE-CW comes with a built-in list of well-known cluster nodes (DB0BCC, OH8X, GB7DXC, K0XM, VE7CC, VK2IO).
4. Click Connect. DL2CC-REMOTE-CW logs in automatically using your callsign.
5. DX spots should appear soon.

Filtering Spots

Filters are available in both the Spots tab (quick, live) and the Settings tab (persistent).

Spots tab — live filters

• Band filter — when checked, only spots on the same amateur band as the current rig VFO are shown (e.g. with the rig on 14.025 MHz, only 20 m spots remain visible; 40 m or 15 m spots are hidden). The current rig frequency is displayed in the label next to the checkboxes. When the rig frequency is unknown (no rig connected), the filter has no effect.
• Mode range filter — tightens the band filter to the specific sub-range (CW, Digital, or SSB window) the rig is currently tuned to, based on the IARU Region 1 band plan. With the rig on 14.025 MHz (CW window), SSB spots at 14.250 MHz are hidden even though both are on 20 m. Can be combined with the Band filter or used on its own.
• Column filter input fields — the four text boxes directly above the spot list (Filter Freq, Filter DX Call, Filter Spotter, Filter Comment) act on the column below them. Each one is a case-insensitive substring match by default — typing EA in the DX Call box keeps every spot whose call contains EA (so EA1ABC, K1EA, and W3EAX all stay visible). Wildcards * (any characters) and ? (single character) are supported and switch the field to glob matching against the whole value: EA* matches only calls starting with EA; ??1* matches any two-character prefix followed by a 1. The four boxes are AND-combined — a spot must pass every non-empty field. Clearing a box (or clearing all of them) restores the unfiltered list. Changes apply with a short ~300 ms debounce. These fields are not persisted across restarts.

Sorting the spot list

Click any column header (Freq, DX Call, Spotter, Comment, Time) to sort the list by that column. Click the same header again to toggle between ascending and descending order. The QSY column is not sortable. The chosen column and direction are saved automatically and restored the next time you open the DX Cluster window — so if you prefer the list sorted by frequency, you only need to set it once.

Settings tab — persistent filters

DX Cluster — Settings tab with continent and skimmer filters

The Settings tab also lets you manage the server list. To add your own cluster server, fill in the Name, Host, and Port fields and click Add. Your server then appears in the list and in the drop-down on the Spots tab. The built-in servers cannot be deleted — only servers you add yourself can be removed.

• Spotter continent — select one or more continents (AF, AN, AS, EU, NA, OC, SA). DL2CC-REMOTE-CW sends an accept/spots by_cont command to the cluster node after each login. Leaving all boxes unchecked restores all continents.
• Include skimmer spots — sends set/skimmer to the node so RBN/Skimmer spots are included in the stream. Unchecking sends unset/skimmer.
• Skimmer only — pre-fills the spotter filter field with -# so that only skimmer-sourced callsigns (those ending in -#) are displayed. This also enables skimmer spots automatically.
• Max age — spots older than the chosen number of minutes are hidden. The age check runs every ~15 s, so expired spots are pruned in the background as well as on every new spot.

{
  "lowKHz":  14000,
  "highKHz": 14070,
  "bandName": "20m",
  "mode":    "CW"
}

Click to QSY

Clicking any spot in the DX Cluster list sends a QSY command to the remote radio through whichever rig control service is currently active (CAT or rigctld proxy). The radio tunes to the spotted frequency instantly, without touching a dial.

Antenna Rotator Control

When the host has a rotator controller running PSTROTATORAZ, the client can see the live antenna heading on a compass rose and steer the antenna by clicking the desired bearing — all over the existing WebRTC signaling channel, with no extra network configuration required.

DL2CC-REMOTE-CW does not talk to your rotor hardware directly. Instead it interfaces with PSTROTATORAZ on the host over local UDP, and PSTROTATORAZ does the actual driving. That single design choice means DL2CC-REMOTE-CW supports every rotator and rotator-controller PSTROTATORAZ supports — which, in practice, is everything on the market.

Rotator Control window — live compass rose with click-to-steer

Host Setup

1. Start PSTROTATORAZ on the host machine and configure it for your rotator hardware.
2. In PSTROTATORAZ, open Communication → UDP Control Setup and configure it:
   • Set IP to 127.0.0.1.
   • Leave the port at the default 12000.
   • Tick Automatically positions reporting when the rotor is moving, so PSTROTATORAZ pushes azimuth updates to DL2CC-REMOTE-CW while the antenna turns.
3. Then tick Setup → UDP Control to actually switch the UDP interface on. The setup dialog above only configures the parameters — this menu item is the on/off toggle. Without it, PSTROTATORAZ stays silent on the network and DL2CC-REMOTE-CW can neither send steer commands nor read the azimuth.
4. In Remote Connect → Settings → Host, scroll to the Rotator Control section and tick Use PSTROTATORAZ.
5. Set the IP address and UDP port to match the values configured in PSTROTATORAZ (default: 127.0.0.1 : 12000). DL2CC-REMOTE-CW sends commands to this port and listens for azimuth updates on port + 1 (e.g. 12001).
6. The Status tab shows the current azimuth next to Azimuth: once the first reading is received.

Client Usage

1. Once connected to the host, click the Rotator button on the Status tab to open the compass window.
2. The compass needle updates in real time as the antenna turns. PSTROTATORAZ pushes azimuth readings continuously during rotation; when the antenna is stationary the display is refreshed every 5 seconds from a keep-alive poll.
3. To steer, click anywhere on the compass rose. The bearing under the cursor is computed and sent to the host, which forwards it to PSTROTATORAZ as a steer command.

How It Works Internally

Aux Devices — Amplifier & Tuner Control

DL2CC-REMOTE-CW can monitor and control external amplifiers and tuners connected to the host station via serial port or network. Live status (power, SWR, band, temperature, faults) is pushed to the client in real time, and the client can send commands (Operate, Standby, Tune, Antenna select) back to the host.
As DL2CC-REMOTE-CW can handled different devices, the user interface might look simple for individual devices, but functional. And that's what we need.
Your device is not supported?

Let the author know, make a post to request the feature in our discourse forum. Include links to documents, ideally there already is a programmers reference documentation for the device that you seek to be implemented.
We can't promise it will be implemented, that really depends on how easy it is and whether there are more people out there wanting the same thing.

Supported devices

Host Setup

1. Open Remote Station settings on the host.
2. Scroll to the Aux Devices section (tab 3).
3. Tick Enable for the amplifier and/or tuner slot you want to use.
4. Select the device type from the dropdown.
5. Choose the COM port and verify the baud rate (auto-filled for known devices).
6. Click Connect. DL2CC-REMOTE-CW opens the serial port and starts polling the device at ~1 Hz.

Host settings — Aux Devices serial port configuration

While DL2CC-REMOTE-CW is using a device's serial port on the host, that device's own program (for example the Ultrabeam or SPE Expert software) cannot open the same port at the same time. So that you don't lose access to it, the host now shows the same Aux Devices windows locally. They open automatically as soon as the device has been read — the same way they do on the remote client — so you do not need a client connected. A window you close yourself stays closed; use the Aux Devices button on the host's Remote Station window to reopen it (or to bring an open window to the front). Each window's position and size are remembered.

Client Display

Once connected, the client automatically receives live device status. The Aux Devices window shows the appropriate tab for the detected device combination.

Only the relevant tab is shown — unused tabs are hidden automatically. The active operating state is highlighted on the Operate/Standby buttons: the currently active mode appears with a filled (blue) button while the other is outlined (light).

The following screenshots are examples of two specific integrations to give you an idea of what the Aux Devices window looks like for different device types. The actual layout adapts automatically to the connected device.

Example: SPE Expert — Amplifier & Tuner

This screenshot shows the integration of an SPE Expert amplifier with built-in tuner. The upper amplifier card displays power output, SWR, band, heatsink temperature, power level (L/M/H), and the current RX/TX state together with the active input channel. The Operate, Standby, Input (toggles between input 1 and 2) and Power buttons are available directly. The lower tuner card shows the tuner SWR, active antenna, bypass and tuning state, and provides Tune and Ant Next buttons.

Example: SPE Expert — amplifier card with RX/TX indicator, input channel, and power level; tuner card below

Ultrabeam — RCU-06 Antenna Controller

DL2CC-REMOTE-CW talks to the Ultrabeam RCU-06 controller over its native binary protocol (STX/ETX framing with DLE escaping and an XOR-plus-one checksum). The host opens the controller's serial port and continuously polls the device at about 1 Hz for frequency, band, orientation, motor state and progress; the client UI mirrors that state live and can send frequency, orientation and retract commands back to the controller.

1. Connect the RCU-06 to the host PC via its USB / serial port. The controller's USB interface presents itself as a standard COM port — no extra driver beyond the manufacturer's USB-serial driver is needed.
2. In the Remote Station window, open Settings → Host and scroll to the Aux Devices section.
3. Tick the Ultrabeam checkbox and pick the COM port the controller is connected to. The baud rate is fixed at 19200, 8N1, no hardware handshaking — DL2CC-REMOTE-CW sets this automatically and explicitly disables DTR and RTS, as required by the controller.
4. Click Connect. The host immediately starts polling and reports the supported bands to the client. If the controller is powered off or sleeping, DL2CC-REMOTE-CW still announces the device so the client can show the Ultrabeam tab — status fields stay empty until the controller answers.

Supported bands on the client band panel (fixed by the RCU-06 firmware):

The client side reuses the standard antenna-controller panel: a status card with current frequency, band, orientation and motor state (including a live progress indicator while the elements are moving), a row of direction buttons (Normal, 180°, Bidirectional, Retract), and the shared band panel for direct frequency steering. Unlike SteppIR, Retract on the Ultrabeam is a dedicated controller command — it parks all elements at the home position without the host having to send a fake frequency of 0.

When motors are moving, the host additionally polls the controller's progress endpoint and forwards the current and total motor travel to the client, so the UI can show how far the tuning has progressed. As soon as the motors stop, the progress indicator disappears.

Ultrabeam — live orientation and motor status with frequency steering band panel

SteppIR — SDA 100 / SDA 2000 Antenna Controller

DL2CC-REMOTE-CW talks to the SteppIR SDA 100 and SDA 2000 controllers over their published Reference Protocol (the same wire format used by N1MM, DXLab Commander, HRD and similar rig-control software). The host opens the COM port that is connected to the controller and forwards element-tune and orientation commands; the client UI looks and feels exactly like the Ultrabeam panel.

1. Connect the SteppIR controller to the host PC via its serial port (USB-to-serial works fine). Default baud rate is 9600; 1200 / 2400 / 4800 / 19200 are also supported if you have changed it on the controller.
2. In the Remote Station window, open Settings → Host and scroll to the Aux Devices section.
3. Tick the SteppIR checkbox, pick the COM port the controller is connected to, and choose the matching antenna model from the dropdown next to it.
4. Click Connect. The supported bands reported to the client are derived automatically from the selected model.

Supported models and the bands they enable on the client band panel:

The client side reuses the existing antenna-controller panel: a status card with current frequency, band and motor state, a row of direction buttons (Normal, 180°, Bidirectional, Retract; vertical models show only Normal and Retract), and the shared band panel for direct frequency steering. Retract parks the elements at the home position; under the hood DL2CC-REMOTE-CW simply sets the target frequency to 0, since the SteppIR protocol has no dedicated retract command.

URL Switcher — Generic HTTP Relays

The URL Switcher is a generic adapter for HTTP-controlled switches and relays such as the remote relay boxes sold by hamparts.shop (qro.cz). Each button on the client sends a GET request to a URL you configure on the host. The device's JSON response ({"Status":"OK"}) is relayed back to the client and shown as a brief status line that fades after a few seconds.

1. In the Remote Station window, open Settings → Host and scroll to the URL Switcher card at the bottom of the host settings tab. Tick the URL Switcher checkbox to enable the adapter.
2. Optionally change the device Name (e.g. QRO Switch) — it appears in the client window title.
3. For each of the ten rows, enter a short Label (shown on the client button) and the full URL the host should call.
4. Use the three checkboxes on each row to control what the row does:
   • Show — when ticked (the default), the row appears as a button on the client (as long as it has a Label). Untick it to hide the row from the client while still using it for automatic on/off switching below.
   • On — the URL is called once, automatically, when you open the Remote Station window. Use this to switch equipment on when you sit down to operate.
   • Off — the URL is called once, automatically, when you close the Remote Station window (or exit the app). Use this to switch equipment off when you are done.
   On/Off are tied to opening and closing the Remote Station window — not to connecting and disconnecting. While the window stays open you can connect to and disconnect from the host as often as you like (including dropped connections that reconnect) and the equipment is left alone; it is switched off only when you actually close the window. (On/Off also do not fire when you change other settings.) The responses go to the debug log only.
5. For most relays a plain web address in the URL field is all you need. If your relay expects a POST request with a small piece of text (for example the Shelly Cloud service — see the example below), click the small … button at the end of the row. A little window opens where you can edit the URL, tick Use POST with a JSON body, and type the body to send. The … button is highlighted for any row set up this way. Leave it untouched for ordinary relays — they keep working as a simple web request.
6. If any row has On ticked and the station is started automatically (via a Startup or Desktop shortcut), the On URL(s) are fired first and then the app waits the Startup delay set on the Advanced tab before it starts talking to your other equipment. This gives a device that was just switched on (for example an amplifier powered through a relay) time to boot up and have its COM port appear, so set that delay to cover your slowest device. When you start the app by hand, the On URL(s) still fire to switch your gear on, but there is no wait.

Sample URL formats used by hamparts.shop / qro.cz controllers (consult your device manual for the exact parameters):

http://192.168.124.59:59/Set0/514
http://192.168.124.59:59/Set1/0

On  : http://<shelly-ip>/relay/0?turn=on
Off : http://<shelly-ip>/relay/0?turn=off

URL  : https://<server>.shelly.cloud/v2/devices/api/set/switch?auth_key=<KEY>
Body : {"id":"<deviceid>","channel":0,"on":false}

Host settings — URL Switcher card with ten rows (Show / On / Off / Label / URL)

The client form shows only the rows that have Show ticked and a Label filled in. After clicking a button, the device's response is displayed briefly below the buttons and fades after a few seconds. Both host and client log every click and every result line to the Remote Station debug log under %LocalAppData%\DL2CC-REMOTE-CW\DEBUG\.

Client view — only rows with Show ticked and a Label filled in appear, and the latest response fades in under the buttons

Shutdown Host PC — Remote Power-Off

This device lets the remote operator shut the host PC down at the end of a session. It has no hardware — it simply runs a Windows shutdown on the host. Because it is destructive and one-way, it is disabled by default and protected by two safeguards: a confirmation dialog and a countdown you can still abort.

1. On the host, open Settings → Host and scroll to the Enable remote PC shutdown checkbox at the bottom of the Aux Devices area. Tick it to offer the control to connected clients.
2. On the client, open the Aux Devices window. The Shutdown Host PC panel shows a single Shutdown Host PC button.
3. Click it. A confirmation dialog appears — confirm only if you really want the host to power off.
4. The button is replaced by an Abort pending shutdown button and a live countdown (“Shutting down in 23 s…”). Click Abort any time before the countdown ends to cancel the shutdown.

Host settings — tick Enable remote PC shutdown to offer the control to clients

Client view (idle) — a single Shutdown Host PC button. Clicking it asks for confirmation first.

Client view (counting down) — the button becomes Abort pending shutdown and a live countdown is shown. Click Abort before it reaches zero to cancel.

If a client connects while a shutdown is already counting down, its window opens straight into the Abort state showing the remaining seconds, so the shutdown can still be cancelled from a fresh connection.

Log Tab — Session History & Debug

The Log tab is the last tab in the Remote Station window. It combines two views in one place: a tidy session history (who connected, when, and what note they sent) and a verbose debug log for troubleshooting. A single button at the top right of the tab flips between them.

Session view

Session view — one row per remote connection, newest on top. The current connection shows active in the End column until it ends.

Each remote session adds one row to the table the moment the remote operator's callsign arrives. The row stays as active in the End column while the session is live, and gets its End time stamped the instant you click Disconnect (or when the remote side leaves). Columns:

• Start / End — local date and time, minute precision.
• Callsign — the callsign the remote operator set as their Operator-ID (Station-ID when hosting).
• Comment — the optional Note the remote operator entered (free text).

The session history is kept in %LocalAppData%\DL2CC-REMOTE-CW\Remote\session_history.json and is reloaded automatically the next time you open the Remote Station window — so the list survives restarts. If DL2CC-REMOTE-CW is closed or crashes while a session is still running, that row is marked (interrupted) in the Comment column on the next load so the table never falsely shows a session as still live.

Debug view

Debug view — the same tab with the Debug button clicked. The verbose internal log replaces the session table; the button is now labelled Log so you can flip back.

The Debug button switches the tab to a line-by-line internal log of everything the form is doing: signaling state, peer connection events, rig proxy traffic, aux device messages, etc. This view is mostly useful when something is not working and you want to understand what the app is doing under the hood, or when you are sending a log to support. The button caption flips to Log while the debug view is shown — a single click takes you back to the session table.

Clear button

The Clear button on the right side of the header always clears whichever view is currently visible:

• In the Session view, Clear asks for confirmation and then empties the table and wipes session_history.json on disk. If a session is in progress at the time, that row is kept so its disconnect still closes it cleanly.
• In the Debug view, Clear empties the text panel only. The on-disk log file from this run (remote_connect_YYYYMMDD_HHmmss.log) is not touched — your trail to send to support stays intact.

Where the files live

Both per-run log files are written to %LocalAppData%\DL2CC-REMOTE-CW\DEBUG\ while the app is running:

• remote_connect_YYYYMMDD_HHmmss.log — full debug log for this app run.
• session_YYYYMMDD_HHmmss.log — short human-readable START/END lines for the session table.
• session_history.json — the persistent session table itself. This file is always written, even if internal file logging is disabled, so your history never disappears.

How P2P Works Behind NAT Routers

DL2CC-REMOTE-CW uses WebRTC ICE (Interactive Connectivity Establishment) to find the best path between host and client, even when both are behind home NAT routers with no port forwarding configured:

1. STUN discovery — each side contacts a public STUN server and discovers its external IP address and the NAT-assigned port for that outbound connection.
2. Candidate exchange — both sides send their discovered candidate addresses (local, STUN-mapped, relay) through the Supabase signaling channel.
3. NAT hole-punching — both sides simultaneously send UDP test packets to each other's STUN-discovered public address. Each NAT router sees the outbound packet and allows the inbound reply through. The connection is established without any router configuration.
4. P2P-first relay hold-off — DL2CC-REMOTE-CW deliberately delays relay (TURN) candidates by 3 seconds on both sides. This gives the direct P2P path (host and STUN-mapped candidates) an uncontested window to win the ICE race. If P2P connects within that window, relay candidates are never entered into the race at all. During the hold-off the status panel shows connecting P2P (relay held).
5. TURN relay fallback — if both NATs use symmetric mapping (common in some corporate, mobile carrier, and satellite networks), hole-punching cannot succeed. After the 3-second hold-off expires without a P2P connection, relay candidates are released and all traffic routes through the included TURN relay server. The relay adds latency but the connection always works. You can disable this fallback with Force Direct P2P on the Advanced tab if you want to require a direct path.

In practice, most home broadband connections use endpoint-independent NAT, so a direct P2P connection is established with typical latencies under 200 ms on domestic routes. The status panel shows P2P or Relay so you always know the active path.

How to Improve Your Latency

The default configuration works out of the box for most setups. However, using a relay makes your connection unnecessarily slower — you should try to improve the connection route so it becomes a direct P2P path. The following steps can each make a measurable difference. Apply any combination that fits your setup. On a network where a direct path already works, you can also enforce it with Force Direct P2P on the Advanced tab.

UDP Port Range

All WebRTC audio, CAT, rigctld, and CW timing data travel over a single UDP socket. DL2CC-REMOTE-CW always picks that socket from a fixed block of 10 ports: 57198–57207.

Knowing the exact port range means you can write precise firewall and router rules instead of opening a wide range. It also means every ICE candidate you see in the Status log will have a port number within this range — making it easy to verify that traffic is flowing on the expected port.

Port Forwarding (IPv4)

NAT hole-punching usually works without any router configuration, but if your router uses symmetric NAT (common in some ISP-supplied routers and mobile carrier gateways), hole-punching will fail and DL2CC-REMOTE-CW falls back to the TURN relay. Opening the 10 ports on the host router gives ICE a guaranteed direct inbound path and eliminates the relay penalty.

You only need to do this on the host side (the machine at the radio site). The client benefits from the host's open port without needing its own forwarding rule.

1. Log in to your router's admin page (typically 192.168.1.1, 192.168.0.1, or 192.168.178.1 for FRITZ!Box).
2. Navigate to Port Forwarding (also called Virtual Servers, NAT, or Applications & Gaming depending on the router brand).
3. Create a new rule:

   Field	Value
   Protocol	UDP
   External port range	57198 – 57207
   Internal IP	The host PC's LAN address (e.g. 192.168.1.50) — assign it a static lease in your router's DHCP settings
   Internal port range	57198 – 57207

4. Save and apply. Most routers activate the rule immediately.
5. Reconnect from the client and confirm the Status panel shows P2P.

New-NetFirewallRule -DisplayName "DL2CC-REMOTE-CW WebRTC" -Direction Inbound -Protocol UDP -LocalPort 57198-57207 -Action Allow

IPv6 — Direct P2P Without NAT

If both the host and client have IPv6 connectivity (most modern ISPs provide it), DL2CC-REMOTE-CW will often establish a direct IPv6 P2P path with no router configuration at all. IPv6 global unicast addresses are publicly routable — there is no NAT to traverse — so the ICE host candidates connect directly between the two machines.

No router port-forwarding rule is needed for IPv6. If you already ran the Windows Firewall command from the Port Forwarding step above, no second rule is required — that rule already covers both IPv4 and IPv6 on ports 57198–57207.

Stable IPv6 Address (advanced)

This is only relevant if your operating partner's firewall allowlists your host by its IPv6 address. Windows Privacy Extensions (RFC 4941) rotate that address every few hours or after a reboot, which would silently break such a rule.

If that applies to your setup, run these two commands once in an elevated PowerShell on the host PC:

# Disable random temporary addresses
netsh interface ipv6 set privacy state=disabled store=persistent

# Force stable EUI-64 suffix (derived from the MAC address)
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent

Then reboot. Afterwards, ipconfig will show a single Preferred address without the Temporary label — stable across reboots and safe to put in a firewall rule.

Starlink — Enable IPv6 for Direct P2P

Starlink uses Carrier-Grade NAT (CGNAT) on IPv4. Your router's public IPv4 address is shared among many Starlink subscribers, so ICE hole-punching cannot succeed and DL2CC-REMOTE-CW always falls back to the TURN relay — giving you the slowest possible route by default.

The remedy is to enable IPv6 in the Starlink app or web interface:

1. Open the Starlink app → Settings → Advanced → Local Network and switch IPv6 to On. (On the web UI at 192.168.100.1 the same toggle is under Settings → Advanced → Network.)
2. After the setting saves, reboot the Starlink router so that it requests a fresh IPv6 prefix from the satellite network.
3. Reconnect from the client and confirm the status panel shows P2P.

How Starlink IPv6 addressing works

Starlink uses DHCPv6 prefix delegation to assign your router a block of globally routable IPv6 addresses — typically a /56 prefix (256 possible sub-networks). The router then hands out individual /64 sub-prefixes to each interface on the local LAN. Every device on your network receives a real, publicly routable IPv6 address. There is no NAT layer between the device and the internet, so ICE host candidates connect directly — the same way they would on a native IPv6 broadband link.

If the Stable IPv6 Address commands above were already applied on the host PC, the address suffix remains constant even after a prefix change; only the first four groups of the address change.

VPN — Fallback and Site Access

A VPN can guarantee connectivity when NAT hole-punching fails and neither port forwarding nor IPv6 is available. However, it comes with trade-offs that make it a fallback option rather than a first choice.

Option A — Dial-In Site VPN (Preferred)

A traditional dial-in VPN runs a server directly on the remote site's router or host PC (WireGuard, OpenVPN, or similar). The client connects to that server and is placed logically on the site's own LAN. There is no intermediate relay server — the encrypted tunnel goes from your client straight to the radio site. DL2CC-REMOTE-CW then connects to the host's LAN address as if both machines were in the same room.

This is the preferred VPN approach because:

• The only overhead is the VPN encryption — no cloud relay in the path.
• You know the connection terminates at the site, not at a proxy server.
• DL2CC-REMOTE-CW's P2P report is accurate — traffic genuinely goes directly to the host machine.

Many modern home routers include a built-in WireGuard or OpenVPN server. Alternatively, run WireGuard directly on the host PC. This requires opening the VPN port on the site router — straightforward if you have already set up port forwarding as described above.

Option B — Mesh VPN (Last Resort)

Mesh VPN tools such as Tailscale and ZeroTier create a virtual network between two machines with minimal configuration. They are easy to set up but have two significant caveats for radio remote work:

• Hidden relay: When a direct VPN tunnel cannot be established (e.g., both peers are behind very restrictive NATs), Tailscale uses its own DERP relay servers and ZeroTier uses its planet/moon servers. DL2CC-REMOTE-CW still reports P2P — because it reached the peer via the VPN address — but the physical path passes through a cloud relay. You must check the Tailscale or ZeroTier admin panel separately to know whether the VPN tunnel itself is direct.
• Encryption overhead: Even on a genuinely direct VPN tunnel, all traffic is wrapped in an additional encryption layer, adding CPU load and a small but measurable latency penalty compared to a raw direct connection.

Use a mesh VPN only when port forwarding, IPv6, and a dial-in site VPN are all unavailable. It is a reliable fallback — the connection will work — but with the relay and overhead caveats described above.