Last post I talked about trying to use PAT, and it wasn’t working very well for me. I had set up PAT and Ardop, but I kept getting errors and couldn’t start trying to connect. Essentially, since Ardop couldn’t talk to the radio, it assumed it wasn’t on and couldn’t proceed. But I had a little bit more time this week and finally got it ironed out. Perhaps you are here because you too have a radio without computer controls so you have to manually set your transmit and receive bands, etc.

Eventually, I got it to work by using ardopc, flrig, rigctl, and pat together. I took a lot of information from this post:

But had to edit it for a non-cat, manually controlled radio. Essentially, I had two choices, use a “dummy” radio with hamlib, or have hamlib get input from flrig. I tried both, but went with flrig in the end, as it was much easier to adjust with a gui.

So, I’ll show you my setup and maybe it can help you if you are doing the same sort of thing. First I ran $ pat configure and edited it like so:

  "mycall": "KL4TH",
  "secure_login_password": "<EDITED>",
  "auxiliary_addresses": [],
  "locator": "BP64du",
  "service_codes": [
  "http_addr": "localhost:8080",
  "motd": [
    "Open source Winlink client -"
  "connect_aliases": {
    "telnet": "telnet://{mycall}"
  "listen": [],
  "hamlib_rigs": {"myrig": {"address": "localhost:4532", "network": "tcp"}},
  "ax25": {
    "port": "wl2k",
    "beacon": {
      "every": 3600,
      "message": "Winlink P2P",
      "destination": "IDENT"
    "rig": ""
  "serial-tnc": {
    "path": "/dev/ttyUSB0",
    "baudrate": 9600,
    "type": "Kenwood"
  "winmor": {
    "addr": "localhost:8500",
    "inbound_bandwidth": 1600,
    "drive_level": 0,
    "rig": "",
    "ptt_ctrl": false
  "ardop": {
    "addr": "localhost:8515",
    "arq_bandwidth": {
      "Forced": false,
      "Max": 500
    "rig": "myrig",
    "ptt_ctrl": false,
    "beacon_interval": 0,
    "cwid_enabled": true
  "pactor": {
    "path": "/dev/ttyUSB0",
    "baudrate": 57600,
    "rig": "",
    "custom_init_script": ""
  "telnet": {
    "listen_addr": ":8774",
    "password": ""
  "gpsd": {
    "enable_http": false,
    "use_server_time": false,
    "addr": "localhost:2947"
  "schedule": {},
  "version_reporting_disabled": false,
  "forms_path": "/home/alaskalinuxuser/.wl2k/Standard_Forms"

I don’t actually have a serial TNC, nor did I use GPSD, Pacto, Telnet, Winmor, or the like. I just left those per the defaults. I did edit the “ardop” section, and the hamlibs section to be “myrig”. I then used:

$ aplay -l

To list my sound cards and got the information for ardop to use. After downloading Ardopc from their website, I put it to work with this command:

$ ardopc_64 8515 plughw:1,0 plughw:1,0

Input peaks = -10833, 11449
 Command Trace TO Host INPUTPEAKS -10833 11449
Input peaks = -10274, 9467
 Command Trace TO Host INPUTPEAKS -10274 9467
Input peaks = -11784, 11576
 Command Trace TO Host INPUTPEAKS -11784 11576
Input peaks = -12445, 11873
 Command Trace TO Host INPUTPEAKS -12445 11873
Input peaks = -10387, 10518
 Command Trace TO Host INPUTPEAKS -10387 10518
Input peaks = -11437, 10818
 Command Trace TO Host INPUTPEAKS -11437 10818
Input peaks = -10291, 11485
 Command Trace TO Host INPUTPEAKS -10291 11485
Input peaks = -10508, 10822
 Command Trace TO Host INPUTPEAKS -10508 10822
Input peaks = -10555, 10137
 Command Trace TO Host INPUTPEAKS -10555 10137

In the above, ardopc_64 is the 64 bit version of ardop, the 8515 is the port to use on the local machine, and the plughw:1,0 is for my sound card (output then input I believe, but I may have that backwards). The trailing input peaks are what it was hearing from the radio, which was on.

Now I started flrig from the Ubuntu menu. It has a pretty nice gui and you can just click on the numbers to change them up or down. It of course can’t actually talk to my radio, but ardop doesn’t know that. This is the critical part, because whatever I set flrig to, that is what rigctl, ardop, and pat are going to think the real radio is tuned to.

With flrig running, I then started rigctl like so:

$ rigctl -m 4 -s 4800

Rig command: f
Frequency: 14091000

Rig command: f
Frequency: 7102000

Rig command: f
Frequency: 7102000

Rig command: f
Frequency: 7102000

Rig command:

The -m 4 means the fourth option in it’s numbered radio options, which happens to be flrig input. The -s option is the baud rate speed. The commands I was running after that were the “f” command, to get the currently set frequency. You can see that in flrig, I was set to 14.091, then I changed to 7.102 instead, and rigctl was tracking my changes, which is a good sign.

With all of this set up, I finally was able to start pat with this command:

alaskalinuxuser@alaskalinuxuser-HP-2000-Notebook-PC:~$ pat --listen "ardop" http
2021/09/16 16:49:18 Unable to get frequency from rig myrig: dial tcp connect: connection refused.
2021/09/16 16:49:18 Listening for incoming traffic on ardop...
2021/09/16 16:49:18 Starting HTTP service (localhost:8080)...
2021/09/16 16:49:18 ARDOP TNC (ARDOP TNC_1.0.4.1-BPQ) initialized

Note the “connection refused” bit. I don’t actually have a rig that can be controlled from the computer, so it says that it can’t connect. This is okay if you are using an old radio like mine. You can also see that ardop was set up and initialized, which is also a good sign.

Now I used the web gui of pat like normal. I simply chose to connect, then chose ardop, then chose the RMS listing to get the list of known radio servers and chose one from the list. In this example, I chose VY1WLK at 14.091 MHz. When I did that I then adjusted my physical radio to that frequency, and adjusted flrig to match. Now there was no error in pat about setting rig control manually, since it believed that it had been done automatically, even though I did actually do it manually.

Next I hit connect and this is what I got in the terminal/log:

2021/09/16 16:50:18 Connecting to VY1WLK (ardop)...

And my computer sent out the right “sounds” and that caused the signalink to key the radio to transmit! If you can see the screenshots, you can also see that I tried KL7EDK, and since it was in use, after hitting connect, it gave me a log that it was “waiting for clear channel…” so it knows well enough to listen before it speaks.

I have found though that connecting to these radio servers is rather challenging, often taking numerous tries and with some stations being impossible to connect to. But, to God be the glory, the setup finally works!

Linux – keep it simple.

Leave a Reply

Your email address will not be published. Required fields are marked *