BeaconStack – Tinkering with APRS Beyond the Shack

Like many amateur radio operators, I enjoy building things that are not strictly necessary—but interesting, useful, and slightly educational. My shack is full of radios and small computers, and somewhere between antennas, soldering irons, and configuration files, I started asking myself a simple question:

What can APRS do today that it could not do easily twenty years ago?

BeaconStack grew out of that question.

APRS: Old Protocol, New Possibilities

APRS was designed in a time when bandwidth was precious and computers were slow. And yet, it has survived remarkably well. One reason is that APRS never tried to do everything. It focused on a few core ideas:

• Short messages
• Simple position and status reports
• Human-readable information
• A mix of RF and Internet gateways

Today, almost every APRS user benefits from APRS-IS, even if they never think about it. That global backbone quietly enables things that pure RF could not easily handle.

BeaconStack lives exactly at that boundary: RF stays RF, and complexity moves to the Internet side.

How This Project Started

Initially, I just wanted a small APRS service that could answer simple queries—weather information, for example. That quickly led to familiar problems:

• APRS messages need ACK handling
• Connections to APRS-IS drop
• External APIs are slow or unreliable
• State needs to be remembered over time

Instead of piling everything into one growing program, I took a step back and treated it like a tinkering project worth doing properly.

That is where the idea of small services, loosely coupled, came in.

The Setup: Simple Tools, Clear Roles

BeaconStack runs on a small VPS. Nothing exotic:

• A Linux server
• Docker and Docker Compose
• Redis for message queues
• Postgres for persistent data
• Go for the services themselves

The most important design decision was this:

Only one component talks APRS. Everything else does not.

The Core Idea

The aprs-connector handles all the annoying APRS details:
connections, parsing, message IDs, ACKs, retries.

Everything else simply processes requests and produces replies.

This keeps things understandable—and replaceable.

Why This Is Fun (and Not Pointless)

It is easy to dismiss server-side APRS projects as “cloud toys”. But once you try to build something slightly more advanced, the usefulness becomes obvious.

Some things are simply better handled on a server:

• Polling official weather feeds
• Remembering subscriptions for months
• Making sure alerts are sent once—not ten times
• Filtering by severity
• Running unattended for weeks

Trying to do this on a microcontroller or a monolithic script quickly turns into a maintenance nightmare.

A VPS, on the other hand, is boring—and boring is good.

A Real Use Case: Weather Warnings via APRS

One service in BeaconStack handles German DWD severe weather warnings.

From the user’s perspective, it looks like this:

WARN SUB 10115

That is it.

From then on, if the German Weather Service issues a severe warning for that ZIP code, the user receives a short APRS message like:

WARN 10115: Heavy rain (severe) until 18:00

No apps.
No accounts.
No push notifications.

Just APRS, delivered over RF if possible.

Behind the scenes, the system:

• Polls official DWD feeds
• Matches warning regions to ZIP codes
• Tracks which callsigns are subscribed
• Ensures each alert is sent exactly once
• Cleans up old subscriptions automatically

This is not flashy—but it is useful.

Easy to Extend by Design

One thing I wanted from the beginning was the ability to experiment without breaking existing functionality.

Adding a new APRS command works like this:

1. Create a small service
2. Listen on a Redis queue like service:FOO
3. Do the work
4. Push a reply

The APRS connector does not change.

That means I can tinker safely. If an experiment fails, APRS traffic keeps flowing.

Why Go Instead of Python?

This question comes up often.

Python is great. I use it elsewhere. But for this project, Go has some advantages that matter on a VPS:

• Single static binaries
• Predictable memory usage
• Excellent concurrency for network tasks
• Fast startup and clean restarts
• Very boring long-term behavior

BeaconStack services are meant to run quietly for months.
Go is very good at that.

Why This Fits Amateur Radio

BeaconStack does not replace RF.
It does not depend on special clients.
It does not break APRS etiquette.

If it goes offline, nothing collapses.

That is important.

It is simply an example of how modern tools can support classic amateur radio ideas, without turning them into something else.

System is Live and Available for Testing

BeaconStack is now up and running and connected to APRS-IS. Operators are welcome to test the services and try them out in real-world conditions.

The system is reachable via DF8VX-15.

Usage Notes

• The WX (METAR) command relies on external APIs. Please avoid stressing the system with mass or automated requests, as excessive queries per minute may result in the upstream API being rate-limited or blocked.
• The WARN service can be used freely. Weather warnings are ingested centrally and do not trigger external API calls per user request.

Data Protection / DSGVO Note

For operational reasons, the system logs the callsign of users sending commands.
If a user subscribes to weather warnings, the callsign and subscription data are stored in the database.

• Subscription data is automatically deleted after 365 days
• Data is removed immediately upon unsubscribe
• Regular cleanup tasks run to enforce this behavior

No additional personal data is collected or stored.

As always, feedback is welcome. If something behaves unexpectedly—or if you have ideas for improvements—feel free to get in touch.

Final Thoughts

BeaconStack started as a personal tinkering project, driven by curiosity and the simple desire to see what APRS can still do when combined with modern tools. It remains exactly that—but it has also grown into something that is genuinely useful.

What matters to me is not a specific service or command, but the idea behind it:
keeping RF clean and simple, while using Internet-side resources responsibly to add value for operators.

This project is not finished, and it is not meant to be. If you have an idea for a service, a recurring need you see on APRS, or a use case that could benefit from this architecture, I am genuinely interested in hearing about it. Expanding existing services or adding new ones is very much part of the plan.

If you are an APRS operator with a concrete requirement—or simply a fellow tinkerer with an idea—do not hesitate to contact me. BeaconStack is meant to grow with real operator needs, not in isolation.

Amateur radio has always thrived on shared ideas and experimentation. This is just my contribution to that tradition.