分组无线电信号从扬声器里传出来，听着一切正常，屏幕上却仍然没有可读的消息。Dire Wolf 用软件完成消息还原：计算机接收电台送来的音频，解码其中的数据帧，再交给其他程序。沿着这个过程看下去，就能理解音频输入正常、调制解调器正常、应用程序连接正常为何是三件各自需要验证的事。本文讨论的代码和配置均来自 1.7 版本。[1]

电台送来音频

Dire Wolf 将自己描述为软件声卡调制解调器和终端节点控制器，即 TNC。传统的 TNC 是接在计算机与电台之间的一台独立设备，在这里，计算机承担了调制解调工作。Dire Wolf 自身也能执行应用层功能，包括 APRS 解码、信标发送和数据包中继；为其他程序充当调制解调器，是它的用途之一。[1]

以常见的每秒 1,200 比特 AFSK 模式为例。AFSK 即音频频移键控，信息由 1,200 赫兹和 2,200 赫兹两种音调之间的切换传递。电台接收到的音频送入声卡输入端，软件需要从这些采样中还原变化的信号。John Langner 的解调器论文解释了这项工作为何比辨认一声响亮的哨音更复杂：语音电台的音频电路会改变两种音调的相对电平，因此即使信号很强，解码也未必容易。[2]

调试设备时，分清这两件事很有帮助。调高扬声器音量，只能确认有声音可听；采样后的波形是否仍然保留了解码器需要的全部信息，还要另行验证。

多路解读，选出一个数据包

Langner 的论文探讨了如何适应两种音调电平不等的情况。实际实现允许多路解码尝试处理同一份输入音频。在 1.7 版本中，multi_modem_process_sample() 把采样送入配置好的各条解码通道；源码将解调器与采用不同判决阈值的 slicer（判决器）区分开来。不同阈值让失真的信号有了多次被识别为有效帧的机会。[2][3]

接着还要决定把哪个结果送出调制解调器。multi_modem_process_rec_frame() 接口接收候选帧，pick_best_candidate() 从中选出一个交付，并丢弃其余竞争候选。源码说明了选择时的优先次序：直接接收到、未经过比特纠错的帧，优先于经过纠错恢复的帧。这样，即使多条解码通道都成功了，内部的多次尝试也会归并为交给应用程序的一个可用数据包，避免接连上报重复结果。[3]

这里有一条朴素而有用的架构经验：接收端内部采用多种解读方式，就需要在结果到达应用程序之前设一道筛选环节。这些额外的解读属于恢复同一次传输的过程，不能据此认定有多个台站发送了它。

KISS 从音频处理之后开始

数据帧就绪后，客户端还需要一种接收其字节内容的方式，KISS 正是这样的接口。Mike Chepponis 和 Phil Karn 于 1987 年发表的原始协议论文，描述了一种刻意保持精简的计算机与 TNC 通信协议。主机连接上使用专门的边界字节和转义字节来分隔数据帧。面向电台的一侧可以据此调整实现，各个应用程序则可借助这套接口使用音频调制解调器。[4]

因此，KISS 与电台里听到的信号分属不同层次：前者规定应用程序如何与 TNC 交换数据，后者是在空中传输的两种音调。Dire Wolf 的配置模板将基于 TCP 的 KISS 服务设在端口 8001，另将 AGW 接口设在端口 8000。这些设置决定应用程序如何连接，而 MODEM 1200 选择的是无线电调制解调模式。[5]

一次成功交付能够证明的事情也有范围。原始 KISS 协议对提交给 TNC 的数据帧不提供确认。因此，客户端把字节交出去，并不能据此确认远端台站已经收到。如果需要端到端的接收确认，就要由适当的上层通信完成。[4]

发送还需要控制发射机

发送方向多了一项物理动作，单做接收实验时容易忽略：发射机必须在正确的时刻启动。Dire Wolf 用户指南列出了接口的三项工作：传递接收音频、传递发送音频，以及启动 PTT（按键发射）控制。内置 USB 音频功能的电台可以用一根线缆完成这三项工作，其他接口则采用不同的连接方式。PTT 让电台进入发射状态，音频传递调制后的数据。指南还提醒，发送音频电平过高会使信号失真，降低解码成功率。[6]

配置项也体现了这些分工。ADEVICE 选择音频接口，MODEM 设置调制方式，PTT 指定发射控制方式，可选用合适的串口控制线、GPIO 或受支持的 USB 音频硬件。仅凭 KISS 套接字工作正常，无法确认这些物理连接是否正常。[5]

接收时序同样重要。用户指南建议关闭静噪、让音频通路保持开放，因为静噪开启音频通路时的延迟会截掉数据包的开头。这也解释了一种令人困扰的故障：操作者听到了传输的大部分声音，解码器却已错过起始部分。[6]

一次小型搭建，让各个环节清晰可见

项目文档之外，Patryk Hatka 在 2025 年 10 月发表的搭建记录给出了一个具体实例。他的台站由 Raspberry Pi Zero W、一块扩展板、一张经过改装的 CM108 USB 声卡和一部宝锋 UV-82 手持电台组成。据他记录，在检查 PTT 接线并调整音频电平后，他将 Dire Wolf 作为 KISS 服务器运行，接收到了本地 APRS 数据包，也发出了测试信标。这份记录提供的是一次搭建的实测经验，其结论范围限于该实例，不能作为这些组件的性能保证。[7]

结合前文的接口分工来看，这份记录提示了一套排查故障的实际顺序。先确认计算机收到什么音频，再确认 Dire Wolf 能否将其解码，然后检查客户端连接。排查发送问题时，还要分别检查发射控制和音频质量。与笼统地问“分组无线电能用吗”相比，每一步都把问题缩小到了一个具体环节。

软件调制解调器让这些问题有迹可查。屏幕上出现一条消息，依靠的是数次成功的交接。Dire Wolf 将其中足够多的交接过程呈现出来，下一次消息缺失时，便能沿着它们追查消息丢在了哪里。

来源

1. Dire Wolf 1.7 版本代码仓库——项目范围、软件 TNC 的作用及支持的应用。
2. John Langner，《为 APRS / AX.25 分组无线电设计更好的解调器，第 1 部分：1200 波特 AFSK》，2015 年 4 月——音调、语音电台引入的失真与解调策略。
3. Dire Wolf 1.7，src/multi_modem.c——采样分发、解码候选及交付应用程序前的筛选。
4. Mike Chepponis 和 Phil Karn，《KISS TNC：一种简单的主机与 TNC 通信协议》，1987 年——主机端组帧、职责划分与确认能力的限制。
5. Dire Wolf 1.7，conf/generic.conf——涵盖音频设备、调制解调模式、PTT 与客户端端口的配置模板。
6. Dire Wolf 1.7 用户指南，第 3 节及第 3.1 节——电台连接、静噪与发送音频电平。
7. Patryk Hatka，《用 Raspberry Pi Zero W 搭建 APRS 台站》，2025 年 10 月 9 日——独立台站搭建、运行观察及照片。