August 2026 – N4MI Ham Radio

The Propagation Monitor I wrote about last time has been sitting on my desk running in daily use ever since, and it’s held up well enough that I went looking for the next question worth answering the same way. PropMon tells me whether I can make the contact. What it doesn’t tell me is what’s actually happening in my local operating area right now — who’s mobile nearby, what the weather’s doing a few miles out, whether anything needs my attention. That’s a different question, and it turned out to need a genuinely different instrument.

Overview screen, condensed weather and last-heard mobile station

So this is APRS Monitor (APRSMon), the second instrument in what I’m now calling the N4MI Desktop Instrument Series — same LilyGO T-Encoder Pro hardware, same round display and knob, same one-glance philosophy. Enough of a pattern now that I’ve settled on a naming convention for the whole series: n4mi-[instrument]-monitor. This one lives at n4mi-aprs-monitor, and unlike PropMon — where the firmware and its backend service live in separate repos — this one keeps firmware and backend together in one place. Small structural decision, but worth mentioning if you go looking for the code.

A wrong assumption, caught early

My original plan was straightforward: reuse PropMon’s whole approach and pull local APRS data from aprs.fi’s API, the same way PropMon pulls solar data from HamQSL. Query a station, get JSON back, done.

That assumption turned out to be wrong in an important way. aprs.fi’s API is explicitly built for querying specific, known stations — it intentionally doesn’t support “show me everything within X miles.” Which is fine for a screen like Weather, where I already know which two stations I care about. It’s not fine for a screen that’s supposed to answer “what’s moving nearby,” where the whole point is that I don’t know in advance who that’s going to be.

The actual answer was APRS-IS itself — the raw network the amateur radio community runs this whole system on top of. It supports real radius filtering, but it’s a persistent TCP connection streaming raw packets, not a REST API. That’s not something to run directly on the ESP32, so Mobile Activity ended up needing its own small always-on backend service, structurally identical to PropMon: a persistent connection, a radius filter, an in-memory summary, a flat JSON endpoint the firmware polls. Same pattern, applied a second time, once I understood what it actually needed to do.

Four screens, two backends

Weather queries two known local stations directly through aprs.fi’s API — a quick, simple periodic poll, no different in shape from PropMon’s own HamQSL fetch. Mobile Activity is the one running against the direct APRS-IS connection, filtered to a 20-mile radius around home, showing how many stations have been active in the last hour and the most recently heard one. Overview is the front door, a condensed glance at both. And Alerts pulls it together — currently watching wind gust and rain-rate thresholds on both weather stations, plus whether my own home weather station has gone quiet for longer than it should.

Weather screen, full stat grid for both stations

Mobile Activity screen, 1-hour count and last-heard detail

Config screen, Wi-Fi and per-backend status

Rotating the knob cycles through all four; a long press pulls up a Config screen showing Wi-Fi status and whether each backend is actually alive, the same “is my stuff working” screen PropMon has. Short press does something different depending on which screen you’re on — on Weather it swaps which of the two stations is shown large, and on Mobile Activity it switches to a Recent Stations list, the last three heard instead of just the latest one. PropMon’s short press has one global meaning everywhere; here it didn’t map as cleanly, so each screen got whatever made sense for it instead.

I also just finished an ambient version of the Alerts screen — a small badge and a brief on-screen banner that show up on whatever screen you’re already looking at when something changes, so you don’t have to be on the Alerts screen specifically to notice. It’s built and deployed, but as of this writing I haven’t actually seen it fire against a real condition yet — that’s still on the list to confirm properly rather than just assume.

A real bug worth telling

My own home weather station showing up as a source of local APRS activity was a nice surprise I hadn’t planned for. A separate project on my NAS relays it to APRS-IS, and once I noticed, adding a liveness check to Config took almost no work — that same station’s packets were already flowing through Mobile Activity’s existing connection, just quietly ignored because a stationary station never registers as moving.

Except once, briefly, it did. My own home station showed up in the mobile count as “active,” reporting itself half a mile away from its own fixed location. It never happened again, and I couldn’t fully pin down why — most likely a moment of GPS jitter in the relay, or a stray value in one packet.

The interesting part wasn’t chasing down the exact cause. It’s that I didn’t need to. I already know this specific station doesn’t move, by definition — that’s the entire reason it’s useful as a liveness check in the first place. So instead of trying to fully diagnose one weird packet, I just excluded that callsign from movement detection entirely, permanently, regardless of what any future packet ever claims. Sometimes the right fix isn’t explaining the anomaly, it’s recognizing you already know something the code didn’t.

Wi-Fi setup, the easy way this time

PropMon’s Wi-Fi setup — the phone-based captive portal, join a temporary network, pick from a scanned list, type a password — took real work to get right the first time, including two genuine bugs I only found by deliberately trying to break it. This time I built the same thing for APRSMon by porting that proven code directly rather than starting over, bugs and all the lessons from finding them included from day one.

It worked correctly the first time I flashed it. Every case I’d had to hunt down by hand on PropMon — a wrong password getting rejected, the scan and the hotspot not fighting each other — just worked. That’s the whole value of building a series instead of one-off projects: the second instrument gets to start from what the first one already learned the hard way.

Where it stands

APRSMon is at v1.0 now — every screen built and running on real hardware, the same real Wi-Fi setup flow as PropMon, and the ambient alert system described above. I’m treating that ambient piece as built-but-not-yet-proven until I actually see it trigger against a real condition, which is next on my list — probably by deliberately taking my own home station offline long enough to force its own silence alert.

My two weather stations both happen to sit roughly east of home, which got me thinking about the gaps. There’s a station further out to the west I’m planning to add as an early-warning sentinel, since weather here typically approaches from that direction. North and south are open questions for later — no candidate stations picked yet, just an idea worth not losing.

APRSMon, PropMon, and the original FlightScnr that inspired my projects, side by side on the desk

Three of these on the desk now. Whatever the next one ends up answering, I’ll write about it here.

If you want to build this one yourself, the code is public: N4MI APRS Monitor. The README covers the build, both backend services, and the Wi-Fi setup flow. Same caveat as last time — you’ll want to already be comfortable running a Docker/Portainer stack before you dive in.

I’ve had a WeatherFlow Tempest weather station running at the shack for a while now, feeding data into a few of my own projects. But it never had a public presence — no way for anyone outside my own dashboards to see what conditions look like here in Grovetown. CWOP (the Citizen Weather Observer Program) and APRS solve that: report your station’s conditions, and it shows up on APRS.fi and in the CWOP network alongside thousands of other stations, hams and non-hams alike, all over the world.

This post walks through how I got my Tempest onto CWOP/APRS-IS as N4MI-13, what the pieces actually do, and a few real problems I ran into along the way. I’m deliberately leaving code out of this one — there are a lot of different weather stations out there, and just as many ways to bridge them onto CWOP, so a wall of my specific config wouldn’t do most readers much good. What I’m hoping to hand you instead is the shape of the problem: the pieces involved, the decisions worth making deliberately, and the mistakes worth knowing about ahead of time. If you’re planning to build this with your own AI assistant’s help, this should be enough to get a real conversation started.

Why there isn’t one “correct” way to do this

Every weather station brand has its own way of talking — some publish to their own cloud service, some broadcast locally over your home network, some connect over a serial cable to a dedicated console. And there isn’t one blessed path to CWOP/APRS either: some people run dedicated hardware IGates, some use software that ships specifically for their station brand, and some — like me — bridge it themselves with general-purpose weather station software. None of these is “the” right answer. The right one depends on what station you have, what’s already running on your network, and how much you want to maintain yourself.

I went with WeeWX, an open-source weather station engine that’s been around for years and supports an enormous range of hardware through community-maintained “drivers” — small pieces of glue software that translate whatever format your specific station speaks into something WeeWX understands. If WeeWX doesn’t already have a driver for your station, there’s a good chance someone in the community has written one. That’s really the whole appeal: instead of hand-rolling a translator for CWOP myself, I got to reuse a mature project that already knows how to talk to CWOP correctly, and just needed to plug my station into it.

The shape of the pipeline

Conceptually, it’s a short chain:

My Tempest’s hub broadcasts live readings on my home network every few seconds.
A small always-on program (WeeWX, with the right driver for my station) listens for those broadcasts, makes sense of them, and keeps a running record.
That same program calculates a couple of values CWOP specifically requires but my station doesn’t hand over directly — most notably something called the “altimeter setting,” a sea-level-adjusted pressure reading that depends on your station’s exact elevation.
Every ten minutes, it packages the latest reading up in the format CWOP/APRS-IS expects and sends it out over the internet.

I run this as a small Docker container on my home NAS, since that’s the one machine in the house that’s genuinely always on. That part’s a personal infrastructure choice, not a requirement — this same software runs perfectly well directly on a Raspberry Pi, a spare laptop, or almost anything that stays powered on.

What actually went sideways (and what I’d tell someone else to watch for)

None of this went in one smooth pass, and I think the bumps are more useful to share than a clean success story would be.

Check your network before you assume anything about it. My weather station’s broadcasts and my NAS looked, at a glance, like they were on two different address ranges. Turns out they weren’t — my home network’s actual subnet was wider than I assumed, and everything was on one flat network the whole time. A two-minute check with a basic network command settled it. Worth doing that check first, rather than assuming you need to reconfigure your router.

Local broadcasts and containers don’t always mix by default. Docker normally isolates a container’s network from the host machine’s, which is usually exactly what you want — except when the whole point is listening for broadcast traffic on your real home network. That took a specific networking mode, and I made a point of testing it in isolation with a throwaway container before building the real thing on top of it, so I’d know for certain it would work before investing more time.

Community drivers sometimes lag behind the software they’re plugging into. The driver for my specific station hadn’t fully kept pace with the current version of WeeWX, so its usual automatic setup step quietly didn’t do its job. Nothing was broken, exactly — it just meant configuring that piece by hand instead of trusting the installer. If you hit something similar, it’s a very normal thing to run into with actively-maintained-but-not-official community software, not a sign you did something wrong.

“Batteries included” software images aren’t always fully included. The Docker image I used was missing one small dependency my station’s driver needed for an optional feature I wasn’t even using. An easy fix once identified, but a good reminder to actually watch your service’s own logs after first startup rather than assuming a clean deploy means it’s working.

A stray leftover test container caused a real, confusing failure later — it had quietly grabbed the same network port my real service needed, from a test I’d run earlier and forgotten to clean up. Worth being disciplined about tearing down anything temporary once you’re done with it.

And yes, an actual typo caused an actual crash — a stray character where a `False` should have been. Easy to fix once I saw the exact error, but a good example of why I tested this in stages instead of going live all at once.

Test locally before you publish anything

That staged approach is probably the single most useful thing to carry over if you build something like this yourself. I ran the whole pipeline for a good while with publishing turned off — watching real data flow in, checking that the numbers made sense, comparing my station’s readings against a couple of independent sources (the National Weather Service’s nearest station, and my station’s own companion app) before I ever let a single packet go out to the internet. Once everything checked out and matched, flipping the switch to actually publish was almost anticlimactic — it worked cleanly on the very first attempt, because everything underneath it had already been proven.

Where it ended up

N4MI-13 is now live and reporting every ten minutes, fully over the internet — no radio transmission involved, which APRS.fi correctly shows in how the station’s reports are marked. You can find it on APRS.fi like any other station.

I also added a monitor afterward that watches the uploader’s health directly, and separately, a completely different project of mine that already listens to APRS traffic near home will soon flag me if N4MI-13 ever goes quiet for too long — a nice example of two unrelated projects ending up able to keep an eye on each other.

If you want to try this yourself

If you’re thinking about doing something similar — whether with WeeWX or something else entirely — here’s roughly what you’ll want to have answers to before you start, and honestly, a good enough starting point to describe to your own AI assistant if you want help working through it:

What weather station or console do you have, and does it talk over your local network, a serial/USB connection, or only through its own cloud service?
What existing software already knows how to talk to your specific station — and does it also know how to talk to CWOP/APRS-IS, or will you need something extra for that part?
Where will this run, and is that device genuinely always on?
Do you actually understand your home network’s layout, or are you assuming things about it that are worth double-checking first?
Do you have a way to test the whole pipeline locally, with nothing actually being published, before you turn on the real upload?
What’s your callsign-plus-SSID going to be, and do you have your APRS-IS passcode ready?

That’s genuinely most of it. The specific software and commands will differ depending on your hardware, but the shape of the problem — and the shape of a sensible, careful way to solve it — stays pretty much the same.

My next post will be about my APRS Monitor (APRSMon).

Month: August 2026

A Second Desktop Instrument: APRSMon