The acronym stands for “Automatic Packet Reporting System.” In some
respects APRS is ‘old hat’, having
been conceived and developed more than 25 years ago. However, it is
still possible to try novel combinations of hardware and software,
while exploring this interesting ham
radio application. Before
starting the present project I had experimented a little with packet
radio in the Windows environment, using UISS and soundmodem
for transmitting and receiving via the International Space Station (demo
video). For the project described in these paragraphs I
wanted a setup that could be used for position reporting from the car.
choice of platform for the project was happenstance. A couple of years
ago my wife (XYL in ham
radio parlance) contributed to a Kickstarter campaign that aimed to
produce a high-power alternative to the Raspberry Pi. The
effort called Atomic Pi was
a success, and as result I came into possession of a small powerful
Linux board computer. A Raspberry Pi 3B or any Linux notebook or Laptop
would likely have served as well. However, an Atomic Pi it was.
Software: The Atomic Pi runs Ubuntu
18.04, not the OS distribution that came pre-installed, but that
is another story. My first thought was to install the same packet radio
application I had used previously on Windows, but UISS does not run
natively under Linux—It requires something like WINE. That realization led via an
Internet search to an application called direwolf. While not
graphical like UISS, direwolf is an extremely flexible interface for
packet radio. I should interject that it is not necessary to invest in
specialized hardware such as a terminal node controller (TNC) to
experiment with packet radio. Everything can be done in software. Most
modern ham radio transceivers have built-in sound cards or their
equivalent, and both Windows and Linux have USB audio codec drivers.
The only extra hardware purchased for this project was an inexpensive USB GPS stick. Oops, that’s not
true. I also bought a USB-A splitter (The Atomic Pi has only one USB
port), and a 5v regulator. It would have been possible to construct a
12 VDC to 5 VDC power supply, but the Atomic Pi draws significant
(about 2-1/2 amps), so I opted to purchase a Tobsun DC-DC converter, rated at
max 5 amps, and costing just under $10.
On first discovering direwolf I
installed it right away. This was premature, because direwolf had to be
recompiled to recognize gpsd and hamlib after they were installed—I
should have installed those applications first. Hamlib
was needed so that direwolf could request the transceiver
(Icom IC-7100) to start
or stop transmitting.
This function is called PTT
(push to talk). The
other accessory application gpsd is a service that receives serial
messages from the GPS and re-serves the data via TCP, so that
any number of clients can access
GPS time and location, etc. without having to compete for the serial
As I said, a USB audio codec driver is
included in most if not all Linux distributions. Drivers are also
needed for USB serial communications (e.g. GPS or CI-V). The following
serial devices were installed in the Atomic Pi Ubuntu 18.04 environment.
I don’t recall installing the Silicon Labs drivers, but may have
installed them for an earlier project, or some application may have
brought them in.1 —The rig control device is named /dev/ttyUSB0. This is
the device that Hamlib needs for communication with the
transceiver. Based on what I’ve read in various posts, device naming
conventions vary across Linux distributions.
Preliminary Testing: The first problem I encountered was
this message from direwolf:
not open audio device plughw:1,0 for input
or resource busy
to continue without audio device.
In addition to the ‘plughw:1,0’
device name in the quoted
error report, I
had also tried other names for referring to the USB audio codec as the
intended input/output device.
Some names worked at first, and then failed upon
restarting direwolf with the exact same configuration! Internet forum
posts alluded to similar issues with other sound-based applications.
Some of these posts suggested making the audio codec the default
device. That seemed crazy, but I wasn’t using HDMI audio for anything
I edited the sound system configuration file
/etc/modprobe.d/alsa-base.conf, which (prior to editing)
USB audio from being loaded as the first soundcard. After this change,
and configuring direwolf to use the default audio device,
this problem no longer occurred.
I tested both position and object beacon
messages from the bench setup, transmitting
at 40 watts with a
vertical dipole at about porch-roof height. These transmissions were
picked up by digipeaters in Winnsboro and Columbia SC (the nearest to
my QTH). However, on transferring the setup to the car, transmissions
were no longer repeated. I guessed that the signal from the car window
antenna (a small whip) was not strong enough to decode at these
repeater locations. Low VSWR does not imply antenna effectiveness! In
order to test transmission from the car, it would be necessary to drive
toward the nearest repeater. This
should be no problem, in any case, as the eventual goal was
to produce a track overlay on Google Maps or Google Earth.
Road Testing: The Atomic Pi would be headless in the
car—In fact it was headless all along, except that I did use VNC when
testing the GPS, and in some audio troubleshooting.
To keep components and connections from flopping around I secured the
Atomic Pi and 5 volt regulator to a small piece
A short (about 6 inch) Y-splitter with
appropriately sized wire and Anderson power pole connectors conveyed
car battery power to the transceiver and regulator. I also used
a power-pole extension with an in-line SPST switch so as not
to have to plug/unplug connectors.
Execute this file on reboot
It was possible to connect
to the Atomic Pi in the car, via WiFi from the house. However,
connecting in this way was not strictly necessary, as a cron2 job
started direwolf automatically on reboot (after a two-minute delay).
named direwolf test
configurations had been defined. When ready to road test it was only
necessary to copy the desired configuration to the default
direwolf.conf, and power-cycle the Atomic Pi. Nevertheless, it was
reassuring to logon via SSH from the house and confirm that
everything was running normally before setting out for a test drive.
Similarly on return I shut the system down remotely from the house,
Within just a mile or two from the
house, the 7th beacon transmission from the car
was heard and decoded by the Columbia repeater,
which digipeated and i-gated the message. For this test drive
I enabled the ‘smartbeaconing’ feature in direwolf. Smartbeaconing was
set to transmit every two minutes at 45 MPH or faster, every 25 minutes
at 5 MPH or slower, and at proportional times for in-between speeds.
The direwolf smartbeaconing feature also detects a change in direction,
such as turning at an intersection, and enables transmit when
that happens. These extra transmissions are not instantaneous, so if
map is zoomed-in, the track appears to jump the curb. By and
though, the displayed track is true to the actual trip.
The blue tower icon at the right-hand edge of the illustrated
map segment marks the
repeater that I was driving toward. I could sometimes guess
when a transmission was being digipeated,
by the timing and audible level of the possible digipeat. While driving
I also experienced a curious psychological phenomenon, wishing
to transmit at the top of a hill, or to refrain from transmitting as
the car passed under a bridge! Of course the algorithm has no awareness
of hills or bridges.
Why? A GPS watch would record many more points and thus
produce a smoother track. Cellphone location apps do the same. So why
APRS? Of course APRS
is not just about
location data. The technology can be used for any sort of
messaging, even under
circumstances when Internet-dependent or cellular communications are
not viable. Such conditions are perhaps a stretch to imagine in today’s
world, except when a large scale natural disaster strikes. As long as
the public communications infrastructure remains intact, the main
appeal of APRS (to me) is to understand
and exercise how it works.
It is a really neat trick to transmit GPS data at 1200 BAUD on 2 meter
FM to a gateway station that relays the data to the Internet, where it
can be served in a format (KML) suitable for interpretative display by
graphical application such as
1. On another Linux box, the Silicon Labs drivers
appeared as soon as a transceiver was connected via USB and powered-on.
Hamlib had been installed on this system.
2. Linux job scheduler
on this page are intended for entertainment only.
The author makes no claim as to the accuracy or completeness of the
information presented. In no event will the author be liable for any
damages, lost effort, inability to carry out a similar project, or
to reproduce a claimed result, or anything else relating to a decision
use the information on this page.