Direwolf APRS Setup for the Raspberry Pi

Written with the Grok engine from xAI. A beginner’s walk-through of building a fill-in APRS digipeater and IGate on a Raspberry Pi, with the AURSINC VHF node and Direwolf. Each step says what to do and why it matters.

This is a recount of the build that worked, rewritten for doing it the first time. I asked Grok to write down everything I did on the path to successfully building this node. It certainly took a lot of trial and error, so this summary boils that lengthy process down.

Start with the basic information: Callsign, location, and the APRS-IS passcode are placeholders. Put your own in.

• YOURCALL — your amateur callsign
• YOURCALL-10 — the SSID used for this node. I used the suffix -10 here
• YOURPASSCODE — the APRS-IS passcode for your base callsign
• The latitude and longitude of the beacon — your location

What you are building, and why

APRS is a system that sends short position and status packets over a radio, usually on 144.390 MHz in North America. A digipeater hears a packet and retransmits it, so it can travel farther. An IGate hears a packet on the radio and uploads it to the internet, where sites like aprs.fi show it on a map.

A “fill-in” is the small, local version of that. It answers one hop, for stations that cannot quite reach a big digipeater, and it uploads what it hears. It does not take packets from the internet and put them back on the air. That matters on a 1 watt node. A wide digipeater is supposed to be high, loud, and carefully filtered. This one is meant to fill a gap, not cover a county.

The computer is a Raspberry Pi. The radio is the AURSINC VHF APRS RF node, which is a small 136–174 MHz module of about 1 watt, with a USB sound chip for the audio and a way to program the radio over serial. Direwolf is the software that turns audio into APRS packets and back again. It is a sound-card TNC. There is no separate TNC box.

The AURSINC node itself is the board this article was built around. It combines the CM108 sound and PTT path with a serial path for the SR110v radio. Product page: AURSINC VHF APRS RF Node on Amazon. Also listed at aursinc.com. Note: Although advertised as 1W, it rarely produced more than a few hundred milliwatts.

Why the USB cable has two positions

The board has two chips on one plug. One is a CM108 sound chip. That is what Direwolf uses for audio, and one of its GPIO pins keys the transmitter. The other is a serial chip, used only to program the radio’s frequency and settings.

The USB-C connector is wired so that rotating it 180 degrees selects which chip the Pi talks to. The LEDs tell you which one you have.

If you start Direwolf and it cannot find an audio device, the cable is almost certainly in serial mode-you want this for programming. If you are not in serial mode, unplug it, rotate the plug, and plug it back in. You will use serial mode once, then leave it in sound mode for good.

You can check the availability of sounds devices with arecord and aplay. You should not see them in serial mode. You should see the ttyUSB device, however.

arecord -l
aplay -l
ls /dev/ttyUSB*

arecord -l lists recording devices. In sound mode you should see a USB audio card. ls /dev/ttyUSB* lists serial ports. In serial mode you should see /dev/ttyUSB0.

Why you program the radio before anything else

The SR110v does not know it is an APRS radio. Out of the box it may be on some other frequency, with VOX on, in low power. Direwolf cannot fix that. It only sends audio. The radio has to already be on 144.390, simplex, with VOX off, before Direwolf is useful.

Orient the cable so only the green LED is on and your tty device responds. Then install the python serial library.

ls /dev/ttyUSB*
sudo apt-get install -y python3-serial

python3-serial is the library that lets a short Python script talk to the radio. The radio speaks a simple text protocol at 9600 baud. Each command starts with AT+ and ends with a return. A reply ending in :0 means the radio accepted it.

python3 - <<'PY'
import serial, time
s = serial.Serial('/dev/ttyUSB0', 9600, timeout=2)

def cmd(c):
    s.reset_input_buffer()
    s.write((c + '\r\n').encode())
    time.sleep(1)
    print(c, '->', repr(s.read(200)))

cmd('AT+DMOCONNECT')
cmd('AT+DMOSETGROUP=1,144.3900,144.3900,00,0,00,0')
cmd('AT+DMOSETVOLUME=5')
cmd('AT+DMOSETVOX=0')
cmd('AT+DMOAUTOPOWCONTR=1')
PY

What each line is for:

• DMOCONNECT — wake the radio up and confirm the serial link works.
• DMOSETGROUP — set receive and transmit to 144.390, no CTCSS tone, squelch open, and the final 0 is the high-power flag. Both frequencies are the same because APRS is simplex. Everyone transmits and receives on one frequency.
• DMOSETVOLUME=5 — set the audio level the radio sends to the sound chip. Too high and Direwolf sees distortion. Too low and it misses packets. Five is a starting point.
• DMOSETVOX=0 — turn VOX off. VOX keys the transmitter when it hears audio. Direwolf keys it with a GPIO pin instead. If both are on, the radio keys at the wrong time.
• DMOAUTOPOWCONTR=1 — leave automatic power control on.

The seven fields in the group command, in order:

AT+DMOSETGROUP = 1 , 144.3900 , 144.3900 , 00 , 0 , 00 , 0

APRS wants all of those: one frequency, no PL tone, squelch open so Direwolf hears everything, and high power if you are going to transmit. A reply of +DMOSETGROUP:0 means the radio stored it. :1 means a field was out of range or the wrong shape. Newer manuals call a similar command AT+DMOGRP and number the fields differently. This 7-field form is the one this firmware accepted.

The high-power flag is stored in the radio. It survives unplugging it. The shorter form of the group command failed on this firmware. The 7-field form is the one that returned :0.

When the replies look right, unplug the cable, rotate it, and plug it back in so both LEDs are on.

Why Direwolf has to be compiled, not just installed

The packaged Direwolf in some distributions is built without CM108 push-to-talk. PTT is how the software tells the radio to transmit. On this board that signal is a pin on the CM108 sound chip. If the program was built without the library that talks to that pin, it can decode packets all day and never key the transmitter. The instructions below detail how to build Direwolf with CM108 PTT support.

The library is libudev. Install the development package before you build.

sudo apt-get update
sudo apt-get install -y \
  git gcc g++ make cmake \
  libasound2-dev \
  libudev-dev \
  libavahi-client-dev \
  pkg-config

libasound2-dev is the sound system. libudev-dev is the one that enables CM108 PTT. The rest are ordinary build tools.

Then build from source, in a separate directory. CMake is a build helper. It has to be run from a build folder, looking up at the source. Running it in the source folder is what produces “does not appear to contain CMakeLists.txt.”

cd ~
git clone https://github.com/wb2osz/direwolf
cd direwolf
mkdir build
cd build
cmake ..
make -j4
sudo make install
make install-conf

cmake .. means “the source is one directory up.” make -j4 compiles using four jobs. sudo make install copies the program into /usr/local/bin. make install-conf drops a sample config in your home directory.

Start it once and read the first lines. You want cm108-ptt in the banner. If it is missing, the udev package was not installed before the build, and you have to install it and rebuild. Validate success with the following commands:

cm108
arecord -l

cm108 is a small tool that comes with Direwolf. It lists CM108 sound cards and the PTT device that goes with each one. Write down the plughw:N,0 name and the /dev/hidraw device. On this build they were plughw:2,0 and /dev/hidraw0. The number changes if another USB sound device is plugged in. Use what your Pi reports.

plughw is an ALSA name. ALSA is the Linux sound system. plughw:2,0 means card 2, device 0, with a plugin layer that converts sample rates. Direwolf wants that form, not the raw hw: form.

Why the config looks the way it does

Direwolf’s config is a text file, usually ~/direwolf.conf. Most of the sample file can stay as it is. These are the lines that make it a fill-in.

Audio, identity, modem, and PTT:

ADEVICE plughw:2,0
ACHANNELS 1

CHANNEL 0
MYCALL YOURCALL-10
MODEM 1200
PTT CM108

ADEVICE is the sound card from the previous step. One channel, because this is a mono radio. MYCALL is how the node identifies itself. The -10 SSID is the usual convention for an IGate. MODEM 1200 is the standard VHF APRS speed, 1200 baud AFSK. PTT CM108 tells Direwolf to key the transmitter through the sound chip’s GPIO instead of a serial port. At startup it should print Using /dev/hidraw0 GPIO 3 for channel 0 PTT control.

The digipeater rules:

DIGIPEAT 0 0 ^TEST$ ^WIDE[12]-[12]$ TRACE
FILTER 0 0 t/p

A packet can ask to be repeated by putting aliases in its path, such as WIDE1-1 or WIDE2-1. A fill-in answers those. It does not answer WIDE3-3 or a packet aliased to TEST.

• DIGIPEAT 0 0 — hear on channel 0, transmit on channel 0. There is only one radio.
• ^TEST$ — never repeat a packet whose alias is TEST. That is a debugging alias, not a real path.
• ^WIDE[12]-[12]$ — only repeat a packet that still has an unused WIDE1 or WIDE2 hop. The brackets are a pattern, not something you type on the air.
• TRACE — when you hop a packet, put your own call in the path with a star, so the path shows YOURCALL-10*. That is how other stations know you handled it.
• FILTER 0 0 t/p — only digipeat position packets. Messages, status, and weather are still uploaded to the internet. They are not retransmitted on the radio. That keeps a small node from repeating everything it hears.

The IGate:

IGSERVER noam.aprs2.net
IGLOGIN YOURCALL-10 YOURPASSCODE
IGTXLIMIT 6 10

APRS-IS is the internet side of APRS. noam.aprs2.net is a rotating name for the North American Tier 2 servers. You do not pick a server. The name hands you one, and the log shows which one after logresp … verified.

The passcode is a number derived from your callsign. It is how the server knows you are allowed to send. Generate it from your base callsign. Do not share it, and do not invent one.

IGTXVIA is left commented out on purpose. That line is what would let the node transmit packets that arrived from the internet. Leaving it off means the node is receive-only toward the internet and transmit-only for what it heard on the radio, plus its own beacon. IGTXLIMIT is a safety cap, in case that line is enabled later.

The beacon:

PBEACON delay=0:20 every=05:00 symbol="igate" lat=39^26.74N long=123^53.93W comment="SR110v fill-in" via=WIDE1-1

A beacon is how the node tells the network where it is. Without one, aprs.fi may show the packets you gate and never show the node itself.

• delay=0:20 — wait 20 seconds after start, so the IGate login can finish first.
• every=05:00 — then every 5 minutes. Often enough to be seen, not often enough to be rude.
• symbol="igate" — the icon. A digipeater can use symbol="digi" instead.
• lat and long — your location, in degrees and decimal minutes. Replace the example.
• via=WIDE1-1 — ask for one hop, so a nearby digipeater can hear you. Remove it if you only care that your own IGate uploads the beacon.

Do not add a second beacon with sendto=IG and the same position. Your own IGate already uploads the RF beacon. Two copies look like duplicates on aprs.fi.

Why the first run is done by hand

Run it in a terminal the first time, so you can see the banner and the login.

direwolf -t 0 -c ~/direwolf.conf

-t 0 turns on color. -c points at the config. You want, in order:

1. The banner includes cm108-ptt. The PTT support was compiled in.
2. The audio device is the plughw you wrote down.
3. A line about /dev/hidraw0 GPIO 3. The PTT pin was found.
4. logresp YOURCALL-10 verified. The IGate server accepted you.

Then the tags on each packet tell you what the node did with it.

• [0L] — something you transmitted, such as your beacon.
• [0H] — something you digipeated. The path will contain YOURCALL-10*.
• [0.n] — something you received. The number is how many bits Direwolf corrected.

Direwolf also prints an audio level for each station. Most of them should be around 50. If it says the level is too high, the radio is sending too much audio into the sound chip. Drop AT+DMOSETVOLUME by one and try again. Distorted audio decodes worse, not better.

How you know it is actually working

Three different checks, because each one proves a different thing.

• A second radio on 144.390 hears your beacon when the PTT LED lights. That proves the transmitter, the frequency, and the PTT pin.
• aprs.fi shows your beacon. That proves the IGate login and the upload. The path will be TCPIP* or qAC, because your own IGate uploaded it.
• A station you heard shows qAR,YOURCALL-10 or qAO,YOURCALL-10 on aprs.fi. That proves you gated someone else’s packet. Your call with a star appears only if some other IGate heard your retransmission. Your own IGate uploads the original, before the hop stamp.

Why it should run as a service

A program started in a terminal dies when you log out. A systemd service starts at boot and restarts if it crashes. Change the user and the path if yours are different.

sudo tee /etc/systemd/system/direwolf.service >/dev/null <<'EOF'
[Unit]
Description=Direwolf APRS fill-in IGate
After=network-online.target sound.target
Wants=network-online.target

[Service]
Type=simple
User=pi
ExecStart=/usr/local/bin/direwolf -t 0 -c /home/pi/direwolf.conf
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now direwolf

After=network-online.target waits for the network, because the IGate has nowhere to go without it. Restart=on-failure brings it back if it exits.

What might go wrong the first time, and why

Appendix: harmonics, and why the antenna needs a filter

After the node was on the air, a wattmeter on the antenna jack with a dummy load did not show 144.390. It showed about 288.781 MHz. That is the second harmonic:

144.390 × 2 = 288.780

The radio was transmitting on 144.390. A strong copy of that signal was also leaving on 288.78 MHz. A nearby radio on 144.390 could hear the APRS audio, so the fundamental was there. The meter locked onto the harmonic because, on this module, the harmonic was strong enough to dominate the reading.

Why it happens: a clean transmitter produces a sine wave at the frequency you asked for, and very little else. A cheap single-chip module does not. Its output is closer to a distorted square wave, and a distorted wave is the fundamental plus a series of harmonics. The second is at twice the frequency, the third at three times. Turning the high-power flag on made it worse. More drive, more distortion, more harmonic. Both units we tried did this. It is the module, not a bad sample.

Why it matters: 288 MHz is not a 2 meter frequency. Energy there is outside the amateur band, and it has to be suppressed. The usual expectation is harmonics at least 40 dB down. A watt of harmonic is still a watt in the wrong place, and it steals power from the signal you meant to send.

The fix is a low-pass filter between the radio and the antenna. A low-pass filter lets the 144 MHz signal through and cuts everything above it. For a 1 watt node it does not need to be large.

• A commercial 2 meter low-pass filter rated for a few watts is enough. Radio, then filter, then antenna.
• A 7-pole 144 MHz low-pass filter, the classic design for the band, puts the second harmonic down about 40 dB when it is built carefully.
• Do not skip it because the node is “only 1 watt.” That is exactly the power level where a harmonic is still loud and easy to ignore.

Check it the same way it was found. Dummy load, and a meter that can read past 300 MHz, or a receiver on 288.78. With the filter in line the 288 MHz reading should collapse. Until that filter is in the antenna line, the node is not finished.

That is the whole path. A running Pi, the cable in the right orientation, a radio programmed for 144.390, Direwolf built with the PTT support this board needs, and a short config that makes it a fill-in instead of a wide.