I am excited to announce that I have just released the database configuration and intake code for my APRS mapping project, aprsdb, on Github. It runs on Python 3 and Postgres with the PostGIS extension. So far I have it working on Linux (Debian Stretch), but the tools are all cross-platform so it presumably could be made to work on other operating systems.
APRS, the automatic packet reporting system, is an amateur protocol which exchanges SMS-like messages that often include location data. Because these packets include information about where they came from and how they traveled, analysis of this data can yield insight into propagation conditions. This project was significantly inspired by the work of Jon, NG0E, on the Mountain Lake APRS website, but removes the need for any internet connection. All the data collection and analysis is entirely local, and unlike the APRS Internet Service, no duplicate-filtering is performed.
Work is still underway to create a reasonably portable web front-end for it. I have a proof-of-concept version working that currently displays some static data from mid-July, 2018, when VHF radio propagation was extremely good in the Upper Midwest.
Amateur radio operators maintain a network of digital radio stations that can send position data, text messages, and a few other types of data over a local or regional scale. This network is termed the Automated Packet Reporting System (APRS), and in the US it operates primarily on a frequency of 144.390 MHz at a speed of 1200 baud. While much of the on-air network feels very much like the late 1980s, the stations are increasingly connected to the internet. With the internet, data can be aggregated (e.g. this map) or sent over a longer distance than it would over VHF, enabling stations on opposite ends of the country and around the world to communicate via these text messages.
A few years ago, I found that VHF radio operators were using the APRS network as a beacon system to track propagation. One user created a map showing the lengths of paths that packets were taking in the network, and highlighted areas where the hops were longer than usual. It’s a neat map and a useful tool, but it requires an internet connection and its reliance on the APRS Internet System (APRS-IS) may [probably?] exclude or filter out entirely usable data—APRS-IS was not intended for propagation studies.
For the last few months, I have been working on a project to do a better job analyzing propagation using APRS data. The data that matter are local—packets heard here at my station—and no packets should be filtered out as duplicates because they took a different path through the network. Once the data are collected, they can be analyzed to find general network statistics, identify misconfigured stations, and spatial analysis can be conducted to show propagation.
Although my project is very much a work in progress, the rest of this post outlines the general plan for development and the current status.
Data collection begins with the antenna and radio, with the analog audio being sent to a computer (raspberry pi). Direwolf, an open-source packet decoder, is used to convert the audio signal into text. I use APRS-python (with some modifications that have yet to be incorporated by the main developer) to parse the text into more useful key:value data structures. Once the data are parsed, they are stored in a Postgres database using the Psycopg2 interface.
The storage database uses Postgres with PostGIS extensions for spatial functionality. When I started the project I used a very simple database schema, but it was not very convenient or efficient to query. I am now working on redesigning the database schema to match the different packet types and sub-packet types. Although it will increase the complexity of the code to get data into the database, I believe it will make querying the data far more efficient and convenient. Once I have the schema redesigned and functional, I intend to upload the code to reproduce the database, as well as the custom Python code, to Github under an open-source license.
I have done some preliminary analysis of test datasets using QGIS, and have a view or two created for common queries. One of these analyses is shown in the picture at the top of this post, with paths being drawn more thickly where traffic is higher and redder where the distance between endpoints is longer. Rewriting the database schema will break the query code I have written, so further development of the querying and visualizations will be deferred until the new schema is in place.
Eventually I am hoping to have a web interface (e.g. GeoMoose) for real-time visualization and analysis of the data. I have the GeoMoose test dataset working on my project computer, and look forward to having the radio data to display instead.