A packet-radio signal can sound healthy through a loudspeaker and still fail to produce a readable message. Dire Wolf puts the work of recovering those messages into software: a computer takes audio from a radio, decodes packet frames, and makes them available to other programs. Following that path reveals why a working sound input, a working modem and a working application connection are three separate achievements. The code and configuration discussed here are from release 1.7.[1]

The radio hands over sound

Dire Wolf describes itself as a software sound-card modem and terminal node controller, or TNC. That last name traditionally belongs to a separate box between a computer and a radio. Here, the computer performs the modem work. Dire Wolf can also perform application functions itself, including APRS decoding, beaconing and packet relaying; operating as another program's modem is one of its roles.[1]

Consider the familiar 1,200-bit-per-second AFSK mode. AFSK means audio frequency-shift keying: information travels through changes between two audio tones, at 1,200 and 2,200 hertz. The radio's receive audio reaches a sound input; the software must recover the changing signal from those samples. John Langner's demodulator paper explains why this is harder than recognizing a loud whistle. Voice-radio audio circuits can alter the balance between the tones, so a strong signal need not be an easy signal to decode.[2]

This is a useful distinction at the workbench. Turning up the speaker establishes that there is something to hear. It does not establish that the sampled waveform still contains everything the decoder needs.

Several readings, one packet

Langner's paper explores ways to accommodate unequal tone levels. The implementation makes room for several attempts to interpret the same incoming audio. In release 1.7, multi_modem_process_sample() feeds the configured decoding paths; the source distinguishes demodulators from multiple decision thresholds, called slicers. Different thresholds give a distorted signal more than one opportunity to become a recognizable frame.[2][3]

That creates another job: deciding which result should leave the modem. The multi_modem_process_rec_frame() interface receives candidate frames, and pick_best_candidate() selects one for delivery while discarding the competing candidates. Its documented preference is for a frame received without bit corrections over one recovered through correction. Multiple internal attempts should therefore produce a useful packet for the application, rather than a burst of redundant reports merely because several decoding paths succeeded.[3]

The architectural lesson is modest but valuable: diversity inside a receiver requires a point of selection before the application. The extra interpretations belong to the work of recovering a transmission; they are not evidence that several stations sent it.

KISS begins after the audio

Once a frame is available, a client needs a way to receive its bytes. KISS supplies that interface. Mike Chepponis and Phil Karn's original protocol paper, presented in 1987, describes a deliberately small computer-to-TNC protocol. Special boundary and escape bytes separate frames on the host connection. The radio-facing machinery can then be changed without requiring every application to implement an audio modem.[4]

KISS is consequently a different layer from the signal heard through the radio. It describes the exchange with the TNC; it is not the pair of tones transmitted over the air. Dire Wolf's configuration template exposes KISS over TCP on port 8001 and the separate AGW interface on port 8000. Those are application connection settings, distinct from MODEM 1200, which selects the radio modem mode.[5]

There is a limit to what a successful handoff proves. The original KISS protocol supplies no acknowledgment of data frames submitted to the TNC. A client handing over bytes therefore cannot treat that action as confirmation that a distant station received them. Any required end-to-end acknowledgment must come from an appropriate higher-level exchange.[4]

Sending also needs transmitter control

The return path introduces a physical action that receive-only experiments can hide: the transmitter has to switch on at the right moment. Dire Wolf's user guide identifies three jobs for the interface: carrying receive audio, carrying transmit audio and activating push-to-talk control. A radio with built-in USB audio can combine these in one cable; other interfaces use different arrangements. PTT tells the radio to transmit; audio carries the modulated data. The guide also warns that excessive transmit audio can distort the signal and reduce decoding success.[6]

The configuration reflects those separate responsibilities. ADEVICE selects the audio interface. MODEM sets the modulation choice. PTT specifies transmitter control, with options for suitable serial-control lines, GPIO or supported USB audio hardware. A working KISS socket proves none of those physical connections by itself.[5]

Receive timing matters as well. The user guide recommends leaving squelch open because the delay in opening it can remove the beginning of a packet. This explains a frustrating failure: an operator may hear most of a transmission while the decoder has already lost its start.[6]

A small build makes the boundaries visible

Patryk Hatka's October 2025 account supplies a concrete example outside the project documentation. His station combines a Raspberry Pi Zero W, an expansion board, a modified CM108 USB sound card and a Baofeng UV-82 handheld. He reports running Dire Wolf as a KISS server and receiving local APRS packets and sending test beacons after checking PTT wiring and adjusting audio levels. This is evidence from one build, rather than a performance guarantee for those components.[7]

Read alongside the interfaces, that report suggests a practical order for understanding failures. First establish what audio reaches the computer. Then establish whether Dire Wolf decodes it. Then inspect the client connection. On transmission, add the separate questions of keying and audio quality. Each step answers a narrower question than “does packet radio work?”

The software modem makes those questions inspectable. A message on screen is the result of several successful handoffs, and Dire Wolf leaves enough of those handoffs visible to investigate where the next missing message went.

Sources

1. Dire Wolf, release 1.7 repository — project scope, software TNC role and supported applications.
2. John Langner, “Building a Better Demodulator for APRS / AX.25 Packet Radio, Part 1: 1200 Baud AFSK,” April 2015 — tones, voice-radio distortion and demodulation strategies.
3. Dire Wolf 1.7, src/multi_modem.c — sample distribution, decoding candidates and selection for application delivery.
4. Mike Chepponis and Phil Karn, “The KISS TNC: A Simple Host-to-TNC Communications Protocol,” 1987 — host framing, division of responsibilities and acknowledgment limits.
5. Dire Wolf 1.7, conf/generic.conf — configuration template covering audio devices, modem mode, PTT and client ports.
6. Dire Wolf 1.7 User Guide, sections 3 and 3.1 — radio connections, squelch and transmit audio level.
7. Patryk Hatka, “Building an APRS Setup with a Raspberry Pi Zero W,” October 9, 2025 — independent station build, operating observations and photograph.