APRS with the Atomic Pi

APRS: 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. The 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 current (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 device.

tcp 0 0 localhost:gpsd 0.0.0.0:* LISTEN

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.

usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_IC-7100_02012002_A-if00-port0
usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_IC-7100_02012002_B-if00-port0
usb-u-blox_AG_-_www.u-blox.com_u-blox_7_-_GPS_GNSS_Receiver-if00

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.¹ —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:

Could not open audio device plughw:1,0 for input
Device or resource busy
Pointless 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 Car window whip antenna data

default device. That seemed crazy, but I wasn’t using HDMI audio for anything so I edited the sound system configuration file /etc/modprobe.d/alsa-base.conf, which (prior to editing) explicitly prevents 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 of thin plywood with Velcro.^® 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.

#!/bin/bash
# Execute this file on reboot
sleep 2m
/usr/local/bin/direwolf >>Logs/direwolf_$(date +%Y%m%d_%H%M%S).txt 2>&1 &

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 cron² job started direwolf automatically on reboot (after a two-minute delay). Multiple mnemonically 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, before powering-down.

Within just a mile or two from the house, the 7^th 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 the real-time map is zoomed-in, the track appears to jump the curb. By and large, though, the displayed track is true to the actual trip.

WA4EFS

    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 the algorithm 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 a graphical application such as Google Earth.

    Demo video: [forthcoming]

Projects Home

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

Project descriptions 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 to use the information on this page.