As Winlink usage and adoption grows, I’ve been experimenting with setting up nodes to serve our local community. About a year ago, the VE6FAR packet node came to life in Calgary, Alberta. It is on 431.000 MHz and runs AX.25 at 1200 baud.

Why only 1200 baud? It turns out that very few current model radios have data ports that support 9600 baud. I was surprised to discover that. So 1200 baud made the most sense, as it provides the opportunity for more radios that many hams have. It is essentially the lowest common denominator, with the lowest barrier to entry.

I tried several TNC models that the club has in stock. One TNC in particular was a Timewave PK-96 that had been a miserable failure in its role in a digipeater project. Now coupled with an MDS 4310 UHF data radio, this was added to our primary Calgary repeater site. It is multi-coupled into an existing antenna with our UHF Yaesu Fusion repeater, an IRLP node, and our analog voice network linking radio system.

The Timewave TNC became quite problematic after going into production. It would seem to hang, and RMS Packet became unresponsive and had to be restarted. This was happening randomly several times per day. Even those restarts weren’t enough to be reliable. After much frustration, I swapped in a KPC-3, and this achieved the reliability I expected for the node.
I brought the Timewave to my radio lab, and after running for about three days, starting manifesting the same bad behaviour as when it was at the repeater site. It seemed to take longer to fail under a much lesser connection load.
Note that as an end-user TNC, it seems to be quite fine, assuming you turn it on every time you want to use it to connect. It’s available for purchase (very cheap) from the Club if anyone is interested.

I also set up a Winlink node at our High River Hospital repeater site. This node was initially set up to connect to the CMS via the AREDN mesh network. Over time, this proved to be a very unreliable method of reaching the CMS. It relied on various AREDN node owners’ internet connectivity, and it seems that every once in a while something changed on the mesh network that would break the CMS connectivity. The expression ‘too many cooks…’ comes to mind with this network. So to eliminate this lack of reliability, I converted that node into a simple packet digipeater.

Over the next few months, two more digipeaters were added, at our VE6HRA and VE6HRB repeater sites, expanding the coverage area by a significant measure. All three digipeaters have direct access to the Calgary node.

The feedback was positive by club members. But a few members asked about VARA FM. Since the two protocols are not compatible, I said we were committed to packet for the foreseeable future.
“Oh,” they said. “We were hoping for a VARA FM node,” they said.
This lingered in my mind, but didn’t really want to add another radio system, on another frequency, and multi-coupled into our shared antenna. There had to be a better way…

Fast forward a few months, and with experimentation in my radio lab, I started to make some progress. The key was to do everything in software using a sound card interface. And no TNC. Software TNC capabilities can be provided by software like Direwolf, among others.

I tested with my Signalink USB, which worked, but many folks have commented that this board’s design has some limitations inn terms of audio bandwidth that constrain throughput with VARA FM and other high speed digital modes. So after showing that it works in principle, I ordered up a DRA-45 board from Masters Communications, run by Kevin Custer of Repeater-Builder fame. I bought it as a kit, and a short bit later, had it built and running, and interfaced to an MDS 4310 data radio. I set the Tx and Rx levels with a service monitor, and it was good to go.

I reconfigured RMS Packet to work with this interface. Then I recruited a couple of local hams to assist with testing, and had RMS Packet running very well with VARA FM. My VARA FM instance is licensed, so the speeds I observed were very impressive. Also, both these hams live within 4 blocks of me, so all transmissions were full quieting in both directions.

Packet and VARA? Together?

Then I set out to add packet back into the equation. I found a number of pages and videos talking about how to do this, and decided on one method that was demonstrated successfully. I followed their directions and was able to achieve the same results.
I’ll explain my configuration on another page.

I had one buddy connecting with VARA, and another buddy connecting with packet. Both modes worked well and were reliable. Both buddies had set up auto-connect every 15 or 30 minutes in Winlink, so the experimental node got a decent number of connections. At some point, I was able to observe two concurrent connections, one packet and one VARA. That was an unexpected (but pleasant) surprise. So I wanted to push this further and see what it could do. I set up my Kenwood TM-D700 with its internal TNC to also connect to the node using packet. I deliberately waited for the other packet user to connect, then connected mine. To my surprise, both sessions were connected and collecting and sending messages.
So now I had to see if or how it would handle packet and VARA concurrently. Watching for the VARA connection to start, I manually started a packet connection. Again, a pleasant surprise. RMS Packet showed both sessions active at the same time. I turned up the radio volume to hear what this sounded like, and heard interspersed VARA and packet tones. Pushing the envelope, I tested two packet sessions and one VARA session at the same time. That worked too.
Unfortunately, I found that it can only handle one VARA FM session at a time.

Audio Levels are Important

I also determined that setting transmit audio and receive audio levels is very important to establishing reliable connection for the end user stations. The node, of course, was set up with a service monitor, using a slightly hot 3.5kHz deviation level. The node receiver is running with an open squelch, allowing weaker signals to still be heard and decoded, even low down in the noise.

Calgary Node Upgrade

With this success behind me, I upgraded FARS’ Calgary Winlink node to support packet and VARA FM just like the lab system. We swapped in a pre-configured and pre-wired radio and sound card system, and then added the necessary software packages on the node PC to make it work.
Our three packet digipeaters I mentioned earlier are, unfortunately, useless with VARA FM. A different plan is in the works, but unfortunately it seems this requires Windows PCs at these sites to run VARA FM, even just as a digipeater.

Pushing the Envelope

While trying to generate several concurrent connections to stress test the lab node, I added a sound card interface to the D700 using the data port. This interface is attached to a Windows 11 VM running on my MacBook. I still have my station PC connected to the built-in TNC using the serial port.

What’s interesting here is that I can start a packet session on the PC using the TNC, and a VARA session on the VM using the sound card on the data port. Somehow the radio manages the audio and packet transmissions and PTT. The node shows both sessions active. I’m using one of my other callsigns on the VARA session, so as to not trip up the CMS; I don’t know if or how that would work if I used the same call, so I chose to avoid that approach.

VARA FM Digipeaters

I’m exploring what is necessary to digipeat VARA FM.
In the VARA FM configuration screen, there is an a box labelled Digipeater. If you put a callsign in this box, it turns on the built-in digipeater function. Note this this capability is only available with the purchase of a VARA license.

The digipeater function is self-contained in the VARA FM package. It does not require RMS Packet or anything else to run, so a VARA FM digipeater only requires a radio system, a sound card, and a Windows O/S of some sort to run VARA. Since this is a pretty light workload, I’m thinking that a small form factor machine like a NUC or a knock-off, only cheaper, computer might do the job. And that also assumes it doesn’t need network connectivity, but I should probably have a way to reboot it from time to time; it is a Windows machine after all. Maybe a scheduled nightly reboot would take care of that.

And what about a dual mode digipeater? One that can digipeat packet as well as VARA FM. Is this possible? It might possibly work with VARA and DireWolf or SoundModem? Both of these have packet digipeater capability, so it might work.

Challenge Accepted

I tried installing Windows 11 on a Raspberry Pi 4 with 8GB RAM. There are sites on the Internet explaining how to build an image and install Windows with a tool called WoR (Windows on Raspberry). While this was actually successful, the downside was the slow speed of the OS, and the extreme amount of heat generated by the Pi’s CPU running this bloated operating system. There has to be a better solution. I added a bigger cooling fan, which took care of the temperature problem.
I installed VARA FM, and with an external sound card connected, I was able to select the sound card, and perform preliminary transmit and receive tests.
What I observed was that when launching VARA FM, the initial screen comes up, but the CPU runs at 100% for about 10 minutes before I can click on anything within the interface. This is not workable.

A Better Mousetrap

Then it occurred to me that with the Pi running Linux, I could run a simple Windows application like VARA FM under Wine. I installed Wine, downloaded and installed VARA FM, and was able to launch VARA quite easily. The real win here is the simplicity of Wine versus a native Windows installation, and how much cooler the Pi is running.
To set audio levels, I ran the Linux audio mixer and ran the settings for the Signalink device all the way up. A quick set of clicks on the auto-tune button and I have a solid link to the lab Winlink node.
I entered a callsign in the Digipeater box in VARA, and then was able to ping another station through this digipeater.

Next Step

The next step is to try to make DireWolf digipeat Winlink packet data. I know it can be an APRS digipeater, but can it also understand and repeat Winlink data? The first thing I observed is that it decodes APRS beacons, so at least DireWolf works at a basic level.
However, I soon discovered that Winlink packets are not understood by DireWolf and are simply ignored.

I also ran Soundmodem under Wine. That works ok, and the digipeater function works. The secret to digipeating with Soundmodem is to edit the soundmodem.ini file with a text editor, and adding a call sign on the digi call line. This is documented, but not easily found.
As an APRS digipeater, this works as expected.

Running Digis in Wine

Unfortunately VARA FM and Soundmodem both running concurrently under Wine are doing so each in their own instance and in their own ‘bubble.’ That means that each Wine instance will grab system resources for itself, and when the second Wine instance launches, it doesn’t have access to the sound card since the earlier Wine instance has already claimed it.
I’m looking for a way to run both such that they can share the sound card interface.

Further testing to come. Stay tuned.