Dynamically Mapping Amateur Radio Packet Stations


After getting involved in packet radio a couple years ago, I quickly though to myself how useful it would be if there were a map of network nodes so that operators could have a visualization of the nodes they could connect to. One could determine how many hops it would take to reach their intended destination.

Recently, I set up a BPQ node and was able to connect to other node stations via the AX25 over IP, or AXIP, protocol. This gave me access to a wealth of information from other stations – most notably their node list and their MHeard list, which is a list of stations that can be heard via radio.

Because my node is accessible via telnet, I realized that I could write a Python script to log into it and retrieve my node and MHeard list. Easy enough. However, I then realized that I could take it a step further and log into my node, and then connect to another node to get their node and MHeard lists.

So, I got to work.

I decided to use a PostGIS (GIS extension for PostgreSQL) backend for the data storage. Working with PostGIS is a breeze and nicely integrates with the technology stack I used. On top of PostGIS, I utilized GeoServer, a Java server application that converts PostGIS data into Web Feature Services (WFS) and Web Map Service (WMS), ways of allowing retrieval of GIS data over the internet. The next step was the frontend. For creating the map, I used JavaScript with the OpenLayers API. This allowed me to feature several map layers, including:

  • Local operators (Those my radio can hear over the air)
  • Local Digipeaters (Stations that repeat signals, that I can hear over the air)
  • Nodes that I’m connected to via AXIP
  • Remote digipeaters ( Those that I detected from logging into remote nodes)
  • Remote operators (Those that I detected from logging into remote notes)
  • Network map

The network map shows the links between stations who share a common node. This is intended to show the extent of connectivity of an area.

My MHeard list is checked every 15 minutes, ensuring that stations aren’t missed. Packet is busy here in Aurora, so frequent checks are necessary. My node list is checked every three hours for new NET/ROM nodes which may have appeared. Lastly, remote MH lists are checked at random once every half hour.

Currently, the plan is to hide nodes, digipeaters, and operators which haven’t been heard in the past three months in order to keep the map relevant.

I’m happy with the finished product after having put a lot of work into it. I hope others find it useful. If you have any ideas or comments, please leave a comment, or send me an email at kd5lpb at arrl.org

2 thoughts to “Dynamically Mapping Amateur Radio Packet Stations”

  1. Bravo! Automation is always nice and you came up with a great method. As author of the Nationwide Amateur Radio Packet Directory http://www.ww2bsa.org and being extremely intimate with active packet stations in the USA, I’ve noticed a lot of “holes” on your map and am wondering why those active stations aren’t showing up. Otherwise, nice job.

  2. Hi Dr. Lance,

    I saw your page a while back and noticed the same.

    I assume you’re collecting data by hand? My method connects to remote BPQ nodes and parses their MHeard lists, so there will be missing data where I don’t have a connection. I’ve also noticed that there are a number of nodes with empty MH lists (?), so I don’t get anything from them. I hope that, over time, the holes will be more filled in. Relying on other node’s lists isn’t ideal, but I couldn’t think of any other method.

    I do drop points (via a SQL view) if they haven’t been heard in three months in an attempt to keep it up to date.

    Thanks for the comment!

Leave a Reply