Ham Radio With K0PIR

Setting up RumLogNG with Elecraft K3S is a breeze with these helpful tips and tricks. From configuring the software to optimizing the radio settings, this guide ensures a smooth operation. Whether you're a beginner or an experienced operator, get ready to enhance your logging experience and make the most out of your Elecraft K3S.

The post Setting Up RUMLogNG with The Elecraft K3S: Tips and Tricks for Smooth Operation appeared first on Ham Radio with K0PIR - Icom 7300 and 7610 SDR Transceivers and now Elecraft!.

The availability and performance of Software Defined Radios (SDRs) today is incredible. Equally incredible is how poorly us Hams make use of the capabilities at our disposal.

A single HackRF One can simultaneously receive a 20MHz wide slice of spectrum anywhere from 1MHz to 6GHz. That means that a single device can simultaneously receive every amateur band from 20 meters to 10 meters or from 160 meters all the way to 15 meters!

In this post I’ll show you how to receive and decode FT8 on multiple bands simultaneously. These techniques can be expanded to receive WSPR, JT9, and every other digital mode in the received bands. Your CPU is the limit.

Hardware

HackRF One or another SDR with a high sample rate and the capability to receive HF.

Any old PC or Single Board Computer (SBC) – I’m using an old laptop with a quad-core i7 running at 3.5GHz. Nearly anything with a CPU is acceptable. My recommendation for SBCs is currently the Orange Pi 5 Pro, it’s a good balance of cost vs performance but it might not get you all 5 bands like my old i7 will.

Multi-Band Antenna – I’m using a PAC-12 from QRP Labs. It is not the best choice for this application since it needs to be tuned for each individual band, but it is a great POTA antenna and I already had it hooked up. A good fan dipole or trapped EFHW would be better.

Software

Linux Mint – Most of this will work on any OS that can run the rest of the software but the audio routing bits are specific to Linux & PulseAudio.

PulseAudio – This is already installed with most modern Linux distributions, including Mint. If you’re running another audio server, or an OS without PulseAudio, you get to figure out routing audio between GNU Radio and WSJT-X.

GNU Radio – Manages the SDR, tuning, and demodulating SSB.

WSJT-X – Decodes FT8 from the audio produced by GNU Radio.

Source

All of the code and configuration I used is on GitHub. Please feel free to adapt or build on this work (see the LICENSE file for details).

References & Gratitude

Many thanks to Mark Smith, N6MTS – Mark’s March 2021 QSO Today presentation provided the guiding light for this work. I’m especially grateful that he included links to source material.

Additional inspiration was taken from Corey Koval, K3CPK – Corey’s Automate FT8 GitHub project showed me the way through some interesting bugs.

Thanks to Tushar Jain for uploading an SSB signal capture to their EE304P GitHub repo. All other sources for that file seem to have been scrubbed from the internet.

Problem Outline

The process of extracting useful data from a 20MHz wide chunk of raw RF is a bit daunting but it can be broken down into small steps.

1. Tune to a Target Signal – 20MHz is too much data to process, the target signals are ~3kHz.
2. Demodulate SSB – FT8 (and most digital modes) are decoded from audio which has been demodulated from a Single Side Band (SSB) signal.
3. Decode FT8 – Our demodulated audio stream has to make it to something that can decode FT8.
4. Multiband Operation – We need multiple parallel instances of the decoding software playing nicely together. Multiple audio streams need to be routed correctly, labelled, and ideally we should have the ability to listen in to each band.

Tuning to a Target Signal

I chose to split tuning into two steps. First, tuning to a specific Amateur band (or at least, a good part of it) and second, tuning in to the specific frequency used for FT8 on that band. The workload to filter and decimate the 20MHz sample of raw RF is very high so splitting this work up allows decoding other digital modes in the future without adding a lot of load to the CPU.

Band Tuning

My goal here is to reduce the massive 20MHz sample rate to something more manageable for each amateur band, center the target band in the output, and filter out neighboring signals. I chose to take every band to a 400kHz slice. That slice is large enough to cover the entire CW, digital, and beacon ranges of each HF band. Using the same slice for each band also makes the math easier downstream.

This hier block calculates and executes the filter necessary from a few inputs. The most important bits are the input center frequency, the output center frequency, and the output bandwidth.

This filter was a frequent source of bugs; signals being shifted incorrectly, aliasing, massive energy loss, and more. Configuring the taps incorrectly was usually the problem (the documentation explains essentially NOTHING about that function) but the C++ reference for the firdes class cleared things up.

For a bandpass filter, which is what we need for isolating an Amateur band, firdes.complex_band_pass takes the gain, input sample rate, the low cutoff relative to the center frequency, the high cutoff relative to the center frequency, and the transition bandwidth. Let’s go over each of those.

• gain is the 1. No need to amplify or reduce the target signals.
• input sample rate is just the sample rate coming into the block.
• low cutoff is negative, half of the bandwidth in Hz desired from the bandpass filter.
• high cutoff is positive, also half the bandwidth desired.
• transition bandwidth is up to you, smaller values make for greater rejection of signals adjacent to your bandpass but that comes at a high CPU cost. My block defaults to 2kHz but my CPU struggled to keep up, even on a single band. More on that later.

The result is exactly as described, the large chunk of raw RF is taken down to a manageable slice covering the target band.

SSB Tuning

With an amateur band isolated into a manageable chunk it’s time to select a single SSB signal. This is just another Frequency Xlating FIR Filter but on a much more manageable quantity of data. The logic is wrapped up in another hier block for easy reuse.

The center frequency here is calculated based on the tuning frequency and whether the target signal is USB or LSB. The bandpass filter limits the signal to the desired audio bandwidth. The transition bandwidth of the filter is a compromise at 800Hz, if I was using this for voice signals I’d probably want a tighter filter.

The waterfall below shows an SSB signal on an FT8 frequency after tuning. The content is centered, adjacent signals are strongly attenuated but there is still some out of band leakage.

SSB Demodulation

If you’re expecting a detailed explanation of SSB demodulation mathematics you’re about to be disappointed.

This hier block implements the weaver method for SSB demodulation. I went on a deep dive to understand how it works; I ended up with a headache and a renewed appreciation for people that study advanced mathematics. It’s an interesting subject if you enjoy studying such things.

There’s not much to say about this block. It takes in a tuned, filtered RF signal and it outputs an audio signal at the same sample rate. I chose to sample at 8kHz to allow a bit of head room over the roughly 3kHz audio being demodulated. Remember audio bandwidth is half of the input RF sample rate.

The waterfall below shows the audio content extracted from the FT8 signal shown previously.

Testing

I had to test this demodulation with a known signal, something I could listen to and hear any off-center tuning or inversion (making the wrong LSB / USB choice). Digital signals and the weak audio I could find on the band aren’t great for that. The official GNU Radio documentation provides a captured signal for testing but the link is broken. I eventually found the file and it’s included in my GitHub repo.

The test file is centered at 50.247MHz (that took a while to figure out) and sampled at 256kHz. I built this simple flow to resample it for compatibility with my blocks, tune and demodulate the 50.3MHz LSB signal, and route the audio for playback.

I’m going to make this look easy by showing you the end result and not the hours of debugging my own idiocy. Getting these waterfalls was frustrating and it required a lot of time. If you’re struggling with an SDR problem remember that we take a lot of what our radios do for granted, you’re looking at my result NOT my process.

FT8 Workflow & Decoding

Let’s put these pieces together for a real signal. It’s not much different from the demodulation test workflow. Receiving from the HackRF is one simple block, all I’ve done is make the amplifiers and gain variables accessible from the QT GUI.

That’s RF reception, band tuning, ssb tuning & demodulation, and audio playback. That’s a radio, maybe not a great one, but it’s a radio. If this was a rig sitting in the shack we would connect the audio input and output to our PC, open up WSJT-X, and we’d have FT8 monitoring.

So let’s do just that! PulseAudio has a concept of null sinks and monitors. A null sink is just a virtual audio device any application can play out audio to. A monitor is virtual audio device any application can record audio from, one is automatically created for every real or virtual sink.

$ pactl load-module module-null-sink sink_name=vsink0

Start the workflow on your band of choice (I tuned in 20m, because there was a lot of activity) and you’ve got signals.

It would be nice to be able to listen in for debugging and tuning purposes. For that we need a loopback.

$ pactl load-module module-loopback source='vsink0.monitor'

Multiband FT8 Workflow

One band down, how much harder could five be?

All the concepts here are the same. We’re receiving a wider sample of RF (20MHz), and tuning into 5 separate bands, routing each band to an SSB Tune & Demod block, and then resampling the audio for consumption by WSJT-X.

Audio Routing

By putting this configuration in the PulseAudio config directory (/etc/pulse/default.pa.d) the configuration will persist through reboots and service restarts. My full config file is in the GitHub repo.

WSJT-X

WSJT-X expects to be a singleton, i.e. it will only allow one instance of itself to be running at a time. For most users that’s a good thing but for us it’s a problem.

We can create additional “Rigs”, separate config files for WSJT-X, and spawn multiple instances from the command line.

$ wsjtx --rig-name=20mFT8

Each one needs to be individually configured to use the audio device intended for the band it is monitoring. Once configured they can all be started in parallel. My, mostly correct, configuration files are in the GitHub repo. These are stored in ~/.config on Linux systems.

Only 17m and 20m show any decodes because my antenna was tuned for 20m for this screenshot. One day I’ll build a better multi-band antenna.

Obviously this is not a low intensity task for the PC. I’m running this on a 7 year old laptop with a quad-core i7 processor and it’s barely hanging on with all the waterfalls disabled. I managed to squeeze in room for one WSJT-X waterfall at a time.

Wrap Up

That’s it for now. Five parallel FT8 monitors from a single SDR, running on a single machine. There’s some room for improvement and I still need to get transmitting functional.

73, AI6YM

Ham Radio With K0PIR

In this comprehensive guide, we delve into the intricacies of optimizing power settings for the Elecraft K3S and WSJT-X. From understanding the impact of power levels on signal quality to fine-tuning your setup for maximum efficiency, this guide provides invaluable insights and step-by-step instructions to enhance your digital communication experience.

The post Optimizing Power Settings for Elecraft K3S and WSJT-X: A Comprehensive Guide appeared first on Ham Radio with K0PIR - Icom 7300 and 7610 SDR Transceivers and now Elecraft!.

This Again?

I have twisted and worked my way around this problem for some time now and this probably isn’t the last time that I will revisit this topic. However, my station is evolving and as a result, I’m going to make some notes here and share what I know so that other folks can make use of it. Honestly? It’s more so that I will remember how I got here when I inevitably screw something up and have to back it out.

Why Are We Doing This Again?

My solution for the home setup, was to run Win11 on a stick PC that I could interface with the IC-7100 for Winlink email and Other Stuff. Now, what is Other Stuff? In ham radio, we have an unhealthy relationship to old and busted Windows-Only software. It’s changing slowly, but there are still weird packages that find their way into my hands that I “need” to use for This or That.

With the shift from the barely usable Win10 to the What Is This Nightmare Of Constant Advertising Win11, MS pushed me too far. Every time I touch what used to be the Start Menu, I get an advertisement or some unwanted tidbit of news with a picture of a politician or other pop culture nuisance. On top of that, they’d now like me to have an “AI” that follows me around and trains itself using my hardware?

We’re done here.

CrossOver

I don’t know how the link came to me, but I found my way to WG1V’s site and encountered a very different approach to solving the Winlink/Vara/All That Stuff conundrum.

https://www.wg1v.org/posts/2023-12-27-Winlink-and-Pat-on-M1-Mac

The author simply runs CrossOver on their Mac and all of the stuff works.

Now, back in the day, as a Frothy Linux Zealot, I was a reluctant user of Wine to address some needs I had in my day job. I wrestled with it and made it work. Over time, running VMs to handle this stuff seemed to become the new hotness and I didn’t even think about CrossOver for the Mac. The trouble with a VM is that it’s still a full install of Windows and still antagonistic to my desired mental state. Would CrossOver really do the trick?

In a word: Yes.

Following the instructions at the above link, I got VARA HF and ARDOP up and running on my Mac which is what I attach to my shiny new IC-7300 in my shack. It worked out of the box with no fiddling. Full disclosure: I hadn’t updated brew in some time so that took a minute, but with that done, everything else fell into place.

What about the Other Stuff? Most of the radio software out there that might be used for programming an HT for example, is built on ancient frameworks that happen to run reliably under CrossOver. I even pulled up some piece of software that I used to program my DMR HT and it worked out of the box. That outcome was unexpected, but most welcome.

Now What?

To send Winlink mail, I kick off rigctrl and pat with its HTTP UI from a command line and launch either ARDOP or VARA from CrossOver and send my Winlink mail. This gets me two big wins: No Windows and No Winlink Express. This is called Winning.

I have been noodling with my Surface Go to make sure that I can use the 7300 under my Ubuntu setup as well. I want my two main computing devices to be fully ready to run any rig I’ve got that can do a digital mode. On Ubuntu, it will be ARDOP and pat as well. For me, that’s a well-oiled setup with the IC-705. I need to take a minute to add the IC-7300 to the configuration. No big deal, just 10 minutes or so when I get it.

The outcome of all of this is that I now have a single shack computing device that is my Mac and I can do all of the things that I do in one place. Simplifying things is good. And I’ve even got this little stick PC that I can throw something on for an internal fileserver or something.

The Future

In an ideal world, someone (maybe me someday?) will get ARDOP running on a Mac. ARDOP is under active development again and these are exciting times for that modem. I can’t wait to see where it goes! But for now, I will leverage it in this new ecosystem with CrossOver. It works and that’s what matters.

Final

It’s probably pretty clear that I’m willing to work with all flavors of software in different evironments. I’m not opposed to paying for useful software, though my first stop will always be Free/Open solutions. The sticking point here is that I don’t have a lot of time to mess around with some of this stuff and this approach gets me from A to B rather quickly. Again, Winning.

Thanks for reading along!

For last year’s Field Day, I took a stab at networking a couple of computers together with an ethernet cable so that our N1MM+ logging software could be synced up. It was both surprisingly easy to do, but equally daunting due to the curious lack of reasonably digestible tutorials tackling the topic on the interwebs. So now that Field Day is again upon us, I felt that same sort of dread that comes from staring up at a steep learning curve. Because quite frankly, I could not remember at all how to create a N1MM+ computer network. I checked back at my blog page on the topic, and was dismayed at how little of the process I documented. So, I am here to rectify that.

Here is my use case. I want to have three computers with Windows 10 operating systems host logging software (N1MM Logger Plus) for a multiple station ARRL Field Day event. All of the computers need to be synchronized with each other in order to avoid such dreaded contesting faux pas as “dupes”, i.e., getting the same person twice. I also do not want to have to rely on an internet in order to maintain communication between these computers.

As far as hardware goes, I already was in possession of three (quite aged) computers. I splurged on three new 25′ ethernet (CAT 6) cables (one for each computer), and a Linksys 8-Port Gigabit Ethernet Switch. I set up the computers simply by plugging one end of an ethernet cable into its ethernet port, and the other end of the cable into the switch. Remember the gigabit switch does need power to operate!

Before I began networking the computers, I had updated all of the necessary software, including Windows and N1MM+. All of the computers need to have the exact same version of N1MM+, as well as exactly the same inputted contest information, before N1MM+ is able to synchronize between multiple stations.

Once the hardware was gathered and the software was up-to-date, I followed the step-by-step procedure documented below.

Step 1: Go to internet icon, click, and “Open Network & Internet Settings”.

Step 2: Select “Ethernet” on left, and then “Network and Sharing Center” on right.

Step 3: The “Unidentified Network” is set to “private” which is what I want it to be. For contrast, my wifi network is set to “Public” (see arrow on the left). Click on the “Ethernet” hyperlink.

Step 4: Click on “Properties” of the first box that pops up. Then click on “Internet Protocol Version 4 (TCP/IPv4)”.

Step 5: Click “Use the following IP address” and add in “192.168.1.200” for “IP address”. The “Subnet mask” should just show up as 255.255.255.0. While I am no expert by any means in networking computers, I do think you can choose the last three digits of your IP address from 1 to 255 254 [Correction sent to me by my favorite critic, AC1JR!] I picked “200” rather arbitrarily. Once you are done, click “ok”, “ok”, and “close” on the multiple windows.

Step 6: If you need to make your network private because it is showing as public (see Step 3 above), you need type “secpol.msc” into the search bar and press enter.

Step 7: In the pop-up window, click on the “Network List Manager Policies” under the “Security Settings” tab. Then click “Unidentified Networks”. In the next pop-up, choose “Private”. Hit “Apply” and then “Ok”. Your “Unidentified Network” settings should now say “Private”.

Step 8: Open the file manager and click on “Network”. Your computer’s name should be listed there. My computer is named “PC-1”.

Step 9: Now it is time to network your second computer. Go back through Steps 1-8, but this time on the new computer. Below shows all of the steps ordered numerically. Don’t forget to change the ethernet connection to “Private” as shown above. The only difference is that you want to assign this computer a different IP address than the first one. I chose 192.168.1.201.

Step 10: Check the “Network” tab in the file manager to make sure the second computer (in my case, “PC-2”) shows up.

Step 11: Repeat these steps as many times as you need to in order to connect all of your computers to the network. Just change the last digits of the newly assigned static IP address, as they all have to be something different. I have three computers that are now linked together.

Step 12: Once your computers are all networked, open N1MM. Under the “Window” menu, find and click “Network Status”.

Step 13: Make sure that the most recent version of N1MM is installed or else you will get an error message when attempting to connect to the other networked computers (in red below). You also need to make sure that everything else about N1MM is identical, in particular that the contest information for the log is the same.

Step 14: When all of the computers are identically set-up, with the same software versions and contest information, open up the “Network Status” window. A bubble will show that gives you an option to turn on “Networked Computer Mode”. Click it!

Step 15: If you see all of your computers listed with no red error messages, your networking efforts are a success! Make sure you have designated one of the computers as the “Master” by checking the appropriate box.

There you have it! N1MM Logger Plus synchronized across multiple stations for Field Day! I hope to catch you on the air!

Forever,

KM1NDY

Carsten, OZ9AAR added many new features. The best in this release is:

When a station with "/" in the callsign (/P, /R etc) is called, UHM will retry a number of times to get "DX heard me" status (if the DX is using UHM). This helps when the DX/Rover has bad internet connection. Terminal will retry 4 times with 5 seconds delay to get an answer. This means that it can take more than 20 seconds before you get a UHM confirmation on a "/P" etc station ! If the DX has good internet, the confirmation will happen instantly (after the delay configured in "UHM settings"), if internet is not optimal, it will allow 20 seconds delays from the DX to the UHM server.

The latest versions can be downloaded on his Website.

Release Date: June 15, 2024 Here is a summary of the news trending This Week...

💾

💾

This is a 1-hour version of the weekly podcast for This Week in Amateur Radio....

💾

💾

OpenSource.radio is a new wiki started by DK1MI which aims to highlight all things open source...

Release Date: May 25, 2024 Here is a summary of the news trending This Week...

💾

💾

This is a 1-hour version of the weekly podcast for This Week in Amateur Radio....

💾

💾

The 5th annual Amateur Radio Software Award was recently granted to Jakob Ketterl (DD5JFK) and Marat Fayzullin...

Release Date: May 18, 2024 Here is a summary of the news trending This Week...

💾

💾

This is a 1-hour version of the weekly podcast for This Week in Amateur Radio....

💾

💾

The Amateur Radio Software Award (ARSA) committee is pleased to announce that they have selected OpenWebRX, a project led by Jakob Ketterl DD5JFK, and OpenWebRX+, a project led by Marat Fayzullin KC1TXE, as the winners of the 5th annual Amateur Radio Software Award. The award recognizes software projects that enhance amateur radio and promote innovation, freedom, and openness in amateur radio software development.

These projects allow access to radio reception from around the world, whether they are ham operators, shortwave listeners or somebody curious about radio waves. The committee is impressed with the ease of installation, simplicity of use, and overall features that are provided.

The history of these projects showcase the benefit of open source software. OpenWebRX was originally created by András Retzler but due to the demands of his career he decided to discontinue its development. Jakob Ketterl took over the OpenWebRX project and continues to maintain and improve OpenWebRX. Marat Fayzullin’s OpenWebRX+ builds on top of Jakob Ketterl’s OpenWebRX adding support for additional communication modes and advanced features. Both projects are currently separate, allowing implementers of hosting sites to choose between the simple core version or the enhanced version, while allowing the developers to focus on their projects goals.

Jakob Ketterl plans to use the award money to purchase new hardware for the build system of the OpenWebRX project. Recently he added a number of avionics related modes (ADS-B, VDL2, HFDL), a new decoder for DAB (European digital broadcast standard), the ability to decode RDS / RBDS, and a new experimental data interface in the form of MQTT that is intended to allow third-party processing of the information that is received via OpenWebRX.

Marat Fayzullin’s goal for OpenWebRX+ is to support as many communication modes as possible without the need of tweaking multiple pieces of software. In his own words: “In a way, I view OpenWebRX+ as a real-life ‘tricorder’ for the radio spectrum.”

The ARSA committee is already looking forward to next year’s award and welcomes input and nominations for future awards.

Altium Designer‘s Constraint Manager acts as a central hub for managing all your PCB design rules, electrical properties like trace width, physical dimensions, and clearances. It simplifies organization by offering a table format for...

The post Disable the Altium Designer Constraints Manager appeared first on Nuclearrambo.

"Discover the secret to reigniting your passion for FT8 with GridTracker. Dive into a world of real-time data visualization, interactive maps, and comprehensive call rosters, transforming mundane operations into thrilling adventures. Follow expert advice, explore step-by-step instructions, and uncover valuable resources to elevate your ham radio journey. It's time to make FT8 fun again!"

What Are We Doing?

This blog exists for me to catalog sucesses and failures. The other thing it does is provide me with a place to put things so that I can get to them no matter where I am assuming – an internet connection. The topic for today is a refresher on my setup for my portable digital operations.

The Gear and Software

This discussion centers around the use of the IC-705 and the Microsoft Surface GO 2. I have no reason to believe that changing the computer will make any difference as I have gotten this working on other laptops, but the operating system will require some attention.

I’m running Ubuntu as my Linux distro on this device. There is pre-reading required to make this all work and we’ll get to that in a second.

Software includes the following from the Ubuntu repository:

• wfview
• fldigi
• WSJT-X
• Pat

I am currently using the fork of ardop known as – ardopcf from pflarue on GitHub. New and exciting things are happening here in the world of ardop.

The Pre-Work – wfview

There is a great set of instructions on how to get ALSA loopback devices set up appropriately for wfview in their well-written user manual. Start here:

Audio Configuration

With all of that done and in place, there are a few things to look at in wfview for rig control to make life a little easier. At the bottom of this page of the wfview manual there is some good information on setting up wfview to do what flrig would do. That’s what I do. Why? Because it’s working and keeps things simple. The important thing, in my experience, is to set the port number to something other than 4532 which is the flrig default. I set it to 4533 because that’s a safe port number.

Here is what my wfview External Control tab looks like:

It should be noted that I’m using the Virtual Serial Port. This is a mapping to /dev/pty/NUMBER and it takes care of itself once set up.

fldigi

With wfview up and running, setting up fldigi is relatively simple. The following configurations for audio and rig control are currently working.

The rig control settings are set on the HamLib segment of the Rig Control section in the configuration dialogue.

Use hamlib is selected.
Rig is set to Hamlib NET rigctl (stable)
Device is set to 127.0.0.1:4553 (as found in wfview)
Baud rate is set to 115200

All other settings are defaults.

With this complete, save and initialize the connection and then go to the main fldigi window to tune or send a station ID. Rig control and audio should function as expected.

WSJT-X

WSJT-X is the odd duck. My dad and I have the rig control configured differently, but it still works for both of us. What does that mean? There might be more than one successful configuration so maybe find what works and don’t touch it after that. What I use is listed here.

The Radio settings tab is configured as follows.

Rig: Icom IC-705
Serial Port: /home/jcw/rig-pty-1
Baud Rate: 115200
PTT Method: CAT
Data Bits: Default
Stop Bits: Default
Handshake: Default
Mode: Data/Pkt
Split Operation: None

The Audio setup matches the devices that are set in wfview but in reverse.

Note: I find the labeling in wfview to be counterintuitive. It’s probably just my broken brain, but I have to remind myself to flip things around and think about it as source/destination pairs. It’s probably just me.

The Audio tab is configured as follows.

Input: plughw:CARD=Loopback,DEV=1
Output: plughw:CARD=Loopback_1,DEV=1

With this configuration in place, one can test the rig control on the Radio tab or by going to the main window and changing frequencies. Running a tuning cycle briefly will test audio output.

ARDOP – ardopcf

ardopcf is available on GitHub as a binary. Simply download it and put it in /usr/local/bin, run a quick chmod+x on it, and it should be good to go. That’s all that it required of me.

With ardopcf in place, lauching ardop is fairly simple. I put it in a little script so that I don’t have to type out the arguments each time. I named the script “startardop.sh” and dumped it in my home directory. Creative, huh? Here’s what it looks like:

ardopcf 8515 plughw:CARD=Loopback,DEV=1 plughw:CARD=Loopback_1,DEV=1

When you start ardopcf, you should start to see pairs of numbers in the terminal showing you audio input levels. If you’re getting a lot of 0,0 then you might have a problem or wfview might not be running. Maybe your rig is off? Check your signal chain. If, on the other hand, you’re seeing numbers pop up every 4 seconds or so, then you’re in good shape.

Pat

Pat requires some homework and I’m just going to dump some output here. There are instructions for configuration here: https://github.com/la5nta/pat/wiki/The-command-line-interface

The crux of the matter is configuring ~/.config/pat/config.json. Your mileage is going to vary here, but my config looks like this:

{
"mycall": "KC8JC",
"secure_login_password": "NOTPUTTINGTHATONTHEBLOG-HAHAHA!",
"auxiliary_addresses": [],
"locator": "EN91hd",
"service_codes": [
"PUBLIC"
],
"http_addr": "localhost:8080",
"motd": [
"Open source Winlink client - getpat.io"
],
"connect_aliases": {
"telnet": "telnet://{mycall}:CMSTelnet@cms.winlink.org:8772/wl2k"
},
"listen": [],
"hamlib_rigs": {
"my_ic705": {"address": "localhost:4533", "network": "tcp"}
},
"ax25": {
"port": "wl2k",
"beacon": {
"every": 3600,
"message": "Winlink P2P",
"destination": "IDENT"
},
"rig": "my_ic705",
"ptt_ctrl": true,
"beacon_interval": 0,
"cwid_enabled": true
},
"serial-tnc": {
"path": "/dev/ttyUSB0",
"serial_baud": 9600,
"hbaud": 1200,
"type": "Kenwood"
},
"ardop": {
"addr": "localhost:8515",
"arq_bandwidth": {
"Forced": false,
"Max": 2000
},
"rig": "my_ic705",
"ptt_ctrl": true,
"beacon_interval": 0,
"cwid_enabled": true
},
"pactor": {
"path": "/dev/ttyUSB0",
"baudrate": 57600,
"rig": "",
"custom_init_script": ""
},
"telnet": {
"listen_addr": ":8774",
"password": ""
},
"varahf": {
"host": "localhost",
"cmdPort": 8300,
"dataPort": 8301,
"bandwidth": 2300,
"rig": "",
"ptt_ctrl": false
},
"varafm": {
"host": "localhost",
"cmdPort": 8300,
"dataPort": 8301,
"bandwidth": 0,
"rig": "",
"ptt_ctrl": false
},
"gpsd": {
"enable_http": false,
"allow_forms": false,
"use_server_time": false,
"addr": "localhost:2947"
},
"schedule": {},
"version_reporting_disabled": false
}

Wow. That’s a lot of stuff. That is the configuration that is currently working for me for sending Winlink email using ARDOP or telnet.

What a lot of people seem to miss is that Pat has a web gui that will run on localhost:8080. It makes using Pat a lot easier and gives a fresh, modern GUI to Winlink email. And yes, it handles forms and everything. It’s pretty darned cool!

To get that up and running, I use yet another creatively named script: startpat.sh. The contents of that are:

pat-winlink --listen "ardop,ax25,telnet" http

What does that do? It starts up Pat listening for connections on ardop, ax25, or telnet. I didn’t detail ax25 here because, well, I’m not done playing with that just yet. And telnet should always be there so that you can use Pat if you have a good internet connection and NEED to check your Winlink email. The http argument starts the application listening on 8080 for the web UI. With Pat running, all you have to do is go to https://localhost:8080/ui and you’ll see the web UI. You’re now free to explore Pat and send/receive Winlink email.

Final

This is the setup that is currently working for me. I will update this as I add other modes, etc.

Interested in becoming an Amateur Radio operator or need to upgrade your ticket? Check out the N3FJP Study Buddy.