In my previous post, I told the story of getting Winlink, Pat, ARDOP and my Yaesu FTDX10 working reliably on an Apple Silicon Mac.
That post was about the journey: the false starts, the serial-port detective work, the PTT problem, the ARDOP audio problem, the first successful RMS connection, and the eventual realization that the cleanest architecture was much simpler than the one I started with.
This post is the practical companion.
If you want to build something similar, this is where I’m putting the pieces together in one place: the launcher, the shell scripts, the Core Location/GPS bridge, and the configuration details that made the whole thing work.
A quick warning before we start: do not blindly copy my device names and assume they will match yours. The FTdx10 serial ports on your Mac will almost certainly have different names. Treat the files here as a working template, not a universal drop-in installer.
What this setup does
My finished launcher brings up the entire Winlink station in one go.
The architecture looks like this:
macOS Core Location
↓
CoreLocationCLI
↓
NMEA generator
↓
socat pseudo-terminal
↓
gpsd
↓
Pat
│
├── rigctld ── CAT ── FTDX10 Enhanced COM
│
└── ardopcf ── RTS ── FTDX10 Standard COM
│
└── USB AUDIO CODECThe FTdx10’s USB interface exposes two virtual COM ports, and that is what makes this arrangement so clean. Yaesu assigns the Enhanced COM Port to CAT communications and the Standard COM Port to transmit control, such as PTT and digital operation.
In my installation:
/dev/cu.usbserial-00F490390is the Enhanced CAT port, while:
/dev/cu.usbserial-00F490391is the Standard TX-control port.
Your names will be different.
Required software
The setup assumes the following are installed:
Pat
Hamlib
ardopcf
CoreLocationCLI
gpsd
socatOn my machine, Homebrew handles most of the supporting utilities:
brew install hamlib
brew install corelocationcli
brew install gpsd
brew install socatPat and ardopcf need to be installed separately according to their respective project instructions.
You can confirm that Hamlib recognizes the FTdx10 with:
rigctl -l | grep -i FTDX10My installation reports:
1042 Yaesu FTDX-10 StableFinding your FTdx10 serial ports
Start with:
ls /dev/cu.* /dev/tty.* | grep -Ei 'usb|serial'You should see two serial devices associated with the FTdx10.
To identify the Enhanced CAT port, test each candidate with:
rigctl \
-m 1042 \
-r /dev/cu.YOURPORT \
-s 38400At the Rig command: prompt, enter:
fIf Hamlib returns the radio’s current frequency, you have found the CAT port.
On my Mac, that test returned:
Frequency: 14009914which matched the frequency displayed on the radio and confirmed that /dev/cu.usbserial-00F490390 was the correct CAT device.
The remaining FTdx10 USB serial device is then the Standard TX‑control port.
The radio setting that matters
On the FTdx10, PTT must be configured so that the USB virtual COM port can control transmit.
The relevant setting is:
RPTT SELECTand for my installation it is set to:
RTSYaesu documents RTS/DTR as the USB virtual-COM transmit-control option for digital operation.
Pat configuration
Pat uses rigctld for tuning and ardopcf for the modem.
The important Hamlib section of my Pat configuration is:
"hamlib_rigs": {
"FTdx10": {
"network": "tcp",
"address": "127.0.0.1:4532",
"VFO": ""
}
}The ARDOP section is:
"ardop": {
"addr": "127.0.0.1:8515",
"arq_bandwidth": {
"Forced": false,
"Max": 2000
},
"connect_requests": 10,
"rig": "FTdx10",
"ptt_ctrl": false,
"beacon_interval": 0,
"cwid_enabled": true
}The important detail is:
"ptt_ctrl": falsePat is not responsible for PTT in this setup.
ardopcf owns the Standard USB serial port and uses RTS directly.
That division of labour is what finally made the setup reliable.
Starting rigctld
The working Hamlib command is:
rigctld \
-m 1042 \
-r /dev/cu.usbserial-00F490390 \
-s 38400 \
-T 127.0.0.1 \
-t 4532That gives Pat a network-accessible CAT interface at:
127.0.0.1:4532Starting ARDOP
This is the working ardopcf command on my station:
build/macos/ardopcf \
-p /dev/cu.usbserial-00F490391 \
--hostcommands "MYCALL VE3ZDN;DRIVELEVEL 2" \
8515 \
"USB AUDIO CODEC" \
"USB AUDIO CODEC"A few notes are worth calling out.
First, -p assigns the Standard serial port to PTT using RTS.
Second, I explicitly set:
MYCALL VE3ZDNand:
DRIVELEVEL 2at startup.
Third, the FTdx10 USB audio device on my Mac appears as:
USB AUDIO CODECwith two spaces between AUDIO and CODEC.
That detail caused more head-scratching than it deserved.
Your audio device name may differ.
The Core Location to GPSd bridge
Pat can use GPSd to update its locator automatically.
The Mac does not expose Core Location as a conventional serial GPS receiver, so I added a small bridge.
The flow is:
CoreLocationCLI
↓
Python NMEA generator
↓
socat PTY pair
↓
gpsd
↓
PatThe Python script is called:
~/bin/corelocation-nmeaand looks like this:
#!/usr/bin/env python3
import json
import subprocess
import time
import datetime
import sys
def checksum(sentence):
c = 0
for ch in sentence:
c ^= ord(ch)
return f"{c:02X}"
def dd_to_nmea(value, is_lat):
value = float(value)
hemi = (
("N" if value >= 0 else "S")
if is_lat
else ("E" if value >= 0 else "W")
)
value = abs(value)
deg = int(value)
minutes = (value - deg) * 60
if is_lat:
field = f"{deg:02d}{minutes:07.4f}"
else:
field = f"{deg:03d}{minutes:07.4f}"
return field, hemi
def emit(sentence):
full = f"${sentence}*{checksum(sentence)}"
print(full, flush=True)
while True:
try:
result = subprocess.run(
["CoreLocationCLI", "--json"],
capture_output=True,
text=True,
check=True,
timeout=10
)
data = json.loads(result.stdout)
lat, ns = dd_to_nmea(data["latitude"], True)
lon, ew = dd_to_nmea(data["longitude"], False)
now = datetime.datetime.now(datetime.timezone.utc)
hhmmss = now.strftime("%H%M%S")
ddmmyy = now.strftime("%d%m%y")
rmc = (
f"GPRMC,{hhmmss}.00,A,"
f"{lat},{ns},{lon},{ew},"
f"0.0,0.0,{ddmmyy},,,A"
)
emit(rmc)
gga = (
f"GPGGA,{hhmmss}.00,"
f"{lat},{ns},{lon},{ew},"
f"1,08,1.0,0.0,M,0.0,M,,"
)
emit(gga)
except Exception as e:
print(
f"# CoreLocation error: {e}",
file=sys.stderr,
flush=True
)
time.sleep(2)I create the pseudo-terminal pair with socat, feed the NMEA output into one side, and give the other side to real gpsd.
Pat is configured with:
"gpsd": {
"enable_http": false,
"allow_forms": false,
"use_server_time": false,
"update_locator": true,
"addr": "127.0.0.1:2947"
}When everything is working, Pat logs something like:
Locator changed from EN93tj to EN93TJwhich confirms that it has accepted the live position from GPSd.
The one-click launcher
I wrapped everything in a small AppleScript application called:
Winlink ARDOP.appThe AppleScript itself is intentionally simple:
set choice to button returned of (display dialog ¬
"Winlink ARDOP station control" buttons {"Cancel", "Stop", "Start"} ¬
default button "Start" with title "Winlink ARDOP")
if choice is "Start" then
display notification "Starting Winlink ARDOP station…" ¬
with title "Winlink ARDOP"
do shell script "/bin/zsh -lc '$HOME/bin/start-winlink-ardop' 2>&1"
display dialog "Winlink ARDOP startup completed." ¬
buttons {"OK"} default button "OK" ¬
with title "Winlink ARDOP"
else if choice is "Stop" then
display notification "Stopping Winlink ARDOP station…" ¬
with title "Winlink ARDOP"
do shell script "/bin/zsh -lc '$HOME/bin/stop-winlink-ardop' 2>&1"
display dialog "Winlink ARDOP station shut down." ¬
buttons {"OK"} default button "OK" ¬
with title "Winlink ARDOP"
end ifThe application is really just a friendly wrapper around:
~/bin/start-winlink-ardopand:
~/bin/stop-winlink-ardopThat means the logic stays in ordinary shell scripts where it is easy to inspect and troubleshoot.
What the startup script does
The startup script:
- verifies the required programs are installed;
- verifies both FTDX10 serial devices exist;
- creates the GPS pseudo-terminal pair;
- starts the Core Location NMEA generator;
- starts GPSd;
- starts
rigctld; - checks that CAT can actually read the FTDX10 frequency;
- starts
ardopcf; - opens both USB audio channels;
- enables RTS PTT;
- sets my callsign and TX drive level;
- starts Pat;
- waits for the required TCP ports to come up;
- opens the ARDOP and Pat browser interfaces;
- writes logs for troubleshooting.
The shutdown script stops everything in reverse order and cleans up the GPS pseudo-terminal links.
That last point is important.
During development, I discovered that stale Pat or ARDOP processes could leave things in a strange state. A clean shutdown and restart usually restored normal operation immediately.
For that reason, I prefer the launcher to own the whole stack rather than casually reusing old processes.
Logging
The launcher writes its logs to:
~/winlink-launcher-logsincluding:
pat.log
ardopcf.log
rigctld.log
gpsd.log
corelocation-nmea.log
socat-gps.logThese logs are extremely useful.
For example, this:
Mod4FSKDataAndPlay() called when not TXEnabled. Ignoring.tells a very different story from:
Sending Frame Type ConReq2000Mand once you start seeing things such as:
DataACK
BREAK
4FSK...you are looking at real two-way ARDOP traffic.
Download files
I’m making the following files available with this post:
start-winlink-ardop
stop-winlink-ardop
corelocation-nmea
Winlink ARDOP AppleScript source
sample Pat configurationI recommend reading through every script before running it.
At minimum, you will need to change:
callsign
CAT serial device
PTT serial device
audio device nameand possibly:
CAT baud rate
ARDOP drive level
paths to Pat and ardopcfdepending on your installation.
A few final cautions
This setup works on my FTdx10 and my Apple Silicon Mac.
It is not a turnkey universal installer.
In particular, do not assume my:
DRIVELEVEL 2is correct for your radio.
Set transmit audio conservatively and verify that you are not overdriving the transmitter.
Also remember that successful software configuration does not guarantee a successful RMS connection.
My first confirmed connection was to K5RAV, about 2,500 km away.
A later successful connection was to N0DAJ, about 3,000 km away.
Several much closer stations failed simply because 20-metre propagation favoured the longer paths at the time.
Once you know the radio is really transmitting valid ARDOP frames, start considering propagation before tearing your software apart again.
That lesson would have saved me several hours.
Final result
At this point, I can click one icon, press Start, and end up with:
live Mac location
GPSd
Pat
rigctld
ARDOP
FTDX10 CAT control
FTDX10 RTS PTT
USB modem audioall running together.
And most importantly, I’ve connected successfully to multiple Winlink RMS stations over HF.
If this collection of scripts saves another Mac user even half the time I spent figuring it out, publishing them will have been worthwhile.
73,
Doug Nix, VE3ZDN
Kitchener, Ontario
EN93tj
