Direwolf: A Soundcard Packet Radio TNC for Linux, Windows and Pi

Packet radio used to mean a box on the desk called a terminal node controller, or TNC, with its own processor, modem chip and firmware. Today most of that work can be done by a program running on an ordinary computer, using the sound interface to listen and to transmit. The best-known example is Direwolf, written as Dire Wolf by its author, a stand-alone software TNC for Windows, Linux, macOS and the Raspberry Pi. This guide explains what a soundcard TNC is, what Direwolf can do for APRS and for connected AX.25 packet, which modems it supports, what hardware you need, how to get a station running and how to solve the problems most newcomers meet.

If you have wondered how those small APRS trackers, digipeaters and internet gateways work, this is the software behind many of them. It is also a good way to revive packet radio for local messaging, emergency practice or email over VHF.

What a Software TNC Does

A TNC turns audio tones from a radio into digital packets and the other way round. The classic hardware version did this with a dedicated modem chip. A soundcard TNC lets the computer do it with digital signal processing: the radio’s audio output goes into a sound input, the program decodes the packets, and for transmission the program generates audio tones that go back through the sound output to the radio’s microphone input, with a signal to key the transmitter.

The project’s own description is blunt about the history: in the early days it was necessary to use an expensive terminal node controller with specialised hardware, and those days are gone. The author reports that the software decodes over 1000 error-free frames from Track 2 of a well-known TNC test CD, which is a benchmark for packet decoders, and that it leaves hardware TNCs and first-generation soundcard modems behind. Whatever you think of such claims, the practical result is that a computer, a radio and a cheap interface can outperform an old hardware TNC.

What Direwolf Can Do

According to the project’s page on GitHub, the program can work on its own as:

• An APRS GPS tracker, sending position beacons from a GPS receiver.
• A digipeater, extending the range of other stations by retransmitting their packets, with flexible filtering and cross-band repeating.
• An internet gateway (IGate), passing selected traffic between the radio network and the internet.
• An APRStt gateway, which lets a user with only a DTMF-capable handheld enter information into the APRS network.

It can also act as a virtual TNC for other applications. It offers a KISS interface over TCP/IP, a serial port or Bluetooth, and an AGW network interface over TCP/IP. The list of applications named by the project includes APRS clients, Winlink Express, BPQ32 and the Linux AX.25 stack. It also implements the AX.25 version 2.2 link layer, which is the traditional connected mode of packet radio where the TNC retries transmissions and delivers data in the right order. For background on what APRS is and how it works, see our article on APRS, igates and digipeaters.

How AX.25 Fits In

AX.25 is the data link protocol used by amateur packet radio. The encyclopedia entry on the protocol describes how it addresses stations: each frame carries the sender and destination call signs plus a four-bit secondary station identifier, or SSID, with a value from 0 to 15. The entry also notes a limit that surprises newcomers: AX.25 has a built-in maximum of six characters for the call sign, so a seven-character call sign cannot be used in an AX.25 network.

AX.25 does not define the radio modulation. In practice, 1200 baud Bell 202 tones and 9600 baud G3RUH modulation are used almost exclusively on VHF and UHF, and 300 baud tones are the standard on HF. Simple source routing through digipeaters allows multi-hop connections between stations that cannot reach each other directly. APRS uses the connectionless mode of the protocol, which is why it works well for broadcasts of position and short messages.

Modems and Speeds

The project also lists reception of AIS ship signals and EAS SAME alerts, DTMF decoding and encoding, and a speech synthesiser and Morse generator for human-readable messages. It works with software defined radios, and a single installation can use up to three sound cards and six radios.

Two error correction schemes deserve a mention. FX.25 adds forward error correction in a way that stays compatible with existing AX.25 systems, so a link between two stations that both support it keeps working in conditions where plain AX.25 fails. Version 1.7 added IL2P, a different method with less overhead, but it is not compatible with AX.25, so both ends must use it.

What You Need

1. A computer. A Raspberry Pi, an old laptop or a desktop will do. Our article on Raspberry Pi projects for the ham shack shows what a Pi can handle, and a Pi with an audio interface is a popular choice for a permanent digipeater or IGate.
2. A radio. A VHF or UHF FM transceiver with a data or microphone connector. For 9600 bps work you need one with a flat audio path or a dedicated data port.
3. An audio interface. The project lists compatible interfaces such as the DRAWS and UDRC boards for the Pi, and external units such as the SignaLink USB, the DMK URI and the RB-USB RIM. A simple USB sound card with a transformer-isolated cable also works.
4. A way to key the transmitter. Push-to-talk can come from a serial port line, a GPIO pin on a Pi, a USB interface that keys from audio, or a rig control command. Our article on rig control and Hamlib explains one of the ways to do it.
5. A call sign and a licence. Digipeaters and IGates operate unattended in many places, and the rules for that differ between countries, so check your national regulations before transmitting automatically.

Getting a Station Running

The documentation is in the project’s doc folder and includes a User Guide, a guide to running APRS on a Raspberry Pi and a paper on successful IGate operation. Use them rather than copying a configuration from a forum, because the settings depend on your hardware. The general sequence is:

1. Install the program. Download a build for your system, or compile from source on Linux or the Pi.
2. List your audio devices. Find the name of the sound input and output of your interface, and write them in the configuration file.
3. Set your call sign. Use your own call sign with an SSID, and remember the six-character limit of AX.25.
4. Choose the modem. For most local APRS work, 1200 bps is correct.
5. Configure the PTT. Select the method that matches your interface and test it without a transmitter, or into a dummy load.
6. Start with receive only. Run the program, tune the radio to your local APRS frequency and watch the packets scroll by. Our guide to using a dummy load explains how to test your transmit chain safely.
7. Set audio levels. The program reports the level of each decoded frame, and the User Guide explains the target range. Adjust the radio’s volume or the interface gain until the numbers are healthy, and reduce the transmit audio so the signal is not over-deviated.
8. Add features gradually. Enable a beacon, then a digipeater or IGate once reception is clean.

Typical Station Layouts

The same software supports several kinds of station, and it helps to decide which one you are building before you configure anything.

• Receive-only IGate. The simplest and kindest to the channel. The program decodes local packets and passes them to the internet without transmitting. It is a useful first project, and it teaches you what your local network sounds like.
• Digipeater with an IGate. A Raspberry Pi, an interface and a radio at a good location can serve a wide area. This is a bigger responsibility, because a badly configured digipeater harms everyone nearby.
• Virtual TNC for another program. The software provides the modem, and an application on the same computer or another one on the network provides the user interface. This is how many operators use it for messaging, tracking or email. Our article on Winlink explains one of the applications that can use such a link.
• Mobile tracker. A small computer, a GPS receiver and a handheld or mobile radio can send position reports as you travel.

Troubleshooting

Most problems fall into a few groups, and a calm, step-by-step approach finds them quickly:

• No packets decoded. The usual causes are an audio level that is too low or too high, or the wrong sound device. Check the device name, adjust the radio volume and the input gain.
• Packets decode, but the transmitter does not key. The PTT method or its permissions are the usual suspects. Test PTT on its own, and on Linux check that your user can access the serial port or GPIO.
• Transmitted packets are not heard by others. Over-deviation or too little drive is common. Adjust the transmit audio level while monitoring with a second receiver.
• Many duplicate packets. Overlapping digipeaters or poorly chosen paths are typical. Review the digipeater settings and the path used in beacons.
• A client cannot connect. Check the KISS or AGW port number in both the configuration and the client, and look for a firewall.

Making an Unattended Station Reliable

A tracker in the car is forgiving. A digipeater or IGate on a hilltop is not, because nobody is there when it stops. A few habits make a big difference to reliability. Use a decent power supply with enough margin for the computer, the interface and the radio, because brown-outs corrupt memory cards and cause strange faults. Keep the equipment cool and dry, and protect the antenna feed line with a good connector seal and a lightning arrestor. Configure the program to start automatically after a power cut, and test that by pulling the plug. Keep a backup copy of the working configuration file and of the memory card image, so that a replacement computer can be brought up quickly.

Finally, check the station from time to time. Look at the received packet rate, the audio level and the logs. A drifting level or a sudden silence is an early warning that something has changed: a cable, a radio setting or a noise source near the antenna.

Good Practice on the Air

• Keep beacons modest. Frequent beacons clog a shared 1200 baud channel. Use a sensible interval and a short path.
• Do not digipeat everything. Filter and limit hops, so that your station helps the network rather than flooding it.
• Listen first. Check the local activity before starting a digipeater or IGate.
• Secure your gateway. If the station is connected to the internet, protect the computer, use strong passwords and keep the system updated.

Common Mistakes

• Setting the transmit level too high. Over-deviation makes packets undecodable.
• Using a seven-character call sign. AX.25 supports six characters.
• Copying a configuration unchanged. Device names, PTT methods and call signs differ.
• Skipping the receive-only phase. It reveals problems before you transmit.
• Running an IGate without checking the rules. Automatic operation has legal conditions.

The Bottom Line

Direwolf shows how far software has replaced hardware in amateur radio. A computer, a modest audio interface and a radio you already own can become a tracker, a digipeater, an IGate or a modem for Winlink and other packet applications. The key is to read the official documentation, begin with receive only, set your audio levels carefully and respect the shared channel. Once you have a clean decoder running, the rest of the packet and APRS world opens up.

Frequently Asked Questions

What is Direwolf?

Direwolf, written Dire Wolf by its author, is a software TNC that uses a computer’s sound interface to decode and generate packet radio signals. It runs on Windows, Linux, macOS and the Raspberry Pi.

Can Direwolf work as an APRS IGate?

Yes. According to the project page it can be a tracker, a digipeater and an internet gateway without additional software, as well as a virtual TNC for other applications.

Which speeds does Direwolf support?

The modems include 300 bps AFSK for HF, 1200 bps AFSK for VHF and UHF, 2400 and 4800 bps PSK and 9600 bps GMSK in the G3RUH style.

Do I need a hardware TNC?

No. A sound interface between the radio and the computer is enough, and the software handles the modem functions. You also need a way to key the transmitter.

What is FX.25?

FX.25 adds forward error correction to AX.25 frames in a way that remains compatible with existing equipment. If both stations support it, packets can get through in conditions where plain AX.25 would fail.

Why does my call sign not work in AX.25?

AX.25 has a hard limit of six characters for the call sign, plus an SSID. A seven-character call sign cannot be used in an AX.25 network.