Weather – N4MI Ham Radio

A Second Desktop Instrument: APRSMon

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.

Putting My Weather Station on the Map: N4MI-13 and CWOP/APRS

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).

Stream Deck for Ham Radio — Part 2: A Live Propagation Dashboard

One of the first things I do before every operating session is check propagation. What are the solar indices? Which bands are open? Are there any DX stations spotted that I want to work? Before this project, that meant opening six or seven browser tabs manually every time I sat down at the radio. Now I press one button on the Stream Deck and everything is already up and refreshing by the time the radio is warmed up.

This post covers the second major piece of the Stream Deck project — a locally-hosted propagation and operating portal that I call the N4MI Dashboard. It’s tailored specifically to my callsign, my grid square (EM83), and the way I operate.

There’s no shortage of ham radio dashboard options out there. Dedicated display apps like GeoChron Atlas Pro and HamClock are excellent — I actually run both of those on dedicated screens at my operating position. There are also several web-based dashboards with maps, propagation data, and cluster feeds. I could have used any of these as my operating portal, but what I was really looking for was a balance — enough information to make good operating decisions without the screen becoming overwhelming. Building my own meant I could include exactly what I use, organized exactly the way I want it, with my callsign and grid square baked in from the start.

N4MI Propagation Dashboard showing solar indices, HamQSL data, band conditions panel, and KC2G MUF propagation map — The upper half of the dashboard — solar indices across the top, HamQSL widget data, band conditions for EM83, and the KC2G real-time MUF propagation map.

Why a Local Web Server?

The dashboard is an HTML file, but it can’t just be opened as a file directly from the hard drive. Browsers block cross-origin data requests from local files — a security feature called CORS. To fetch live data from external APIs like NOAA and HamQSL, the page needs to be served from a local web server instead.

The solution is a one-line Python web server. Python is already installed on most ham radio PCs, and starting the server takes a single command. A dedicated Stream Deck button runs a PowerShell script that checks whether the server is already running, starts it if it isn’t, and then opens the dashboard in Chrome — all with one press. If the server is already running from a previous session, it skips straight to opening Chrome.

What the Dashboard Shows

The dashboard is organized into several sections, each pulling live data from a different source.

Solar Indices Bar
Across the very top is a live readout of current solar conditions pulled from NOAA and HamQSL: Solar Flux Index (SFI), Sunspot Number (SSN), A-Index, K-Index, X-Ray class, Solar Wind speed, Geomagnetic field status, and an overall conditions summary. The K-Index is color coded — green for quiet, yellow for unsettled, red for active — so I can see at a glance whether geomagnetic conditions are going to affect a DX session.

HamQSL Widget Bar
Three embedded HamQSL visual widgets display HF band conditions, VHF/Aurora/Es status, and a solar data summary — updated every three hours directly from hamqsl.com.

Band Conditions Panel
This panel shows current conditions for 80m through 6m, rated Good / Fair / Poor for both day and night. One detail I was careful about here: the model accounts for D-layer absorption on 80m and 40m during daylight hours. A lot of simpler tools don’t get this right — 80m is not good in the middle of the day regardless of what the solar flux says, and the dashboard reflects that correctly. Each band also shows the expected frequency range for good propagation and what conditions will look like in the opposite period.

Propagation Map
The KC2G real-time MUF map is embedded directly in the dashboard and updates automatically. A one-click button also opens the DXView EM83VK link in a new tab — this shows actual real-time propagation based on WSPRnet, Reverse Beacon Network, and DX Cluster signals, updated every minute. Between the two, I have a very complete picture of what’s actually happening on the bands right now.

N4MI Propagation Dashboard lower half showing Holy Cluster live DX spot feed with map and spot list — The lower half of the dashboard — the Holy Cluster embedded live with a real-time spot map and filterable spot list. DXSummit and DXWatch are available as one-click new-tab buttons.

DX Cluster Spots
The Holy Cluster is embedded as a live iframe directly in the dashboard, with the full interactive map and spot list visible without leaving the page. DXSummit and DXWatch are available as one-click buttons that open in a new tab — those sites block iframe embedding due to browser security restrictions, which is a limitation of how they’re configured rather than a flaw in the dashboard.

Quick Links Panel
The right side of the dashboard has an organized set of one-click links grouped by category: Propagation, DX Cluster, Logging and Awards, DX Expeditions, and Alerts. PSKReporter is filtered directly to N4MI spots. Everything I need is one click away without hunting through bookmarks.

Storm Alert System
This feature came out of a real-world wake-up call. A popup thunderstorm with high winds and lightning arrived faster than expected one afternoon, and I realized I needed a proactive warning system built into my operating workflow — not a separate weather app I might not have open. The result is an integrated storm alert system that monitors two data sources simultaneously: my WeatherFlow Tempest personal weather station for hyperlocal lightning detection and wind data, and the NOAA National Weather Service alerts API for official watches and warnings affecting Columbia County.

The system uses three alert levels — Caution (yellow), Warning (orange), and Critical (red, flashing) — based on lightning distance, wind speed, and NWS alert type. When an alert is active, a full-width banner appears at the very top of the dashboard regardless of scroll position, showing lightning distance in miles, time since the last strike, strikes per hour, wind gust speed, and the full NWS alert text. The Critical level triggers on a Tornado Warning or Severe Thunderstorm Warning and displays a hard-to-ignore message: SEVERE STORM WARNING — LOWER TOWER NOW!

Even when conditions are clear, a persistent Storm Status indicator in the solar indices bar shows ALL CLEAR in green so I always know the system is active and current. During testing, the system correctly triggered a WARNING when the Tempest detected lightning 9 miles away with 356 strikes per hour — well before I would have noticed anything outside. For anyone running a tower, this kind of real-time situational awareness is worth having right in your operating portal.

N4MI Propagation Dashboard showing active Storm Warning banner with lightning distance, NWS Special Weather Statement, and WARNING status pill — The storm alert system in action — a real WARNING triggered by lightning 11 miles away with an active NWS Special Weather Statement. The orange banner stays visible regardless of scroll position, and the WARNING pill appears in the solar indices bar at top right.

How It’s Built

The dashboard runs on two files stored in C:\Ham Scripts\:

dashboard_server.py — a Python web server that serves the HTML file and acts as a proxy for fetching HamQSL XML data and DX cluster spots via telnet, bypassing browser CORS restrictions
N4MI_PropagationDashboard.html — the dashboard itself, which fetches live data from NOAA and through the local Python proxy on startup and on each manual refresh

The Python server connects to US-based telnet DX cluster nodes to fetch the latest spots, parses them by band, and serves them to the dashboard as JSON. It tries three nodes in order and falls back gracefully if one is unavailable.

Claude generated both files based on my description of what I wanted the dashboard to display. The iterative process of describing a feature, seeing the result, and refining it worked very well for something this visual — I could describe exactly what I wanted each section to look like and Claude would implement it.

Adapting It for Your Station

To use this dashboard for your own station, two things need to change:

Update CALLSIGN = "N4MI" in dashboard_server.py to your own callsign
Update the callsign and grid square references in N4MI_PropagationDashboard.html — the DXView link and band conditions model both use the EM83 grid square, so those should be updated to your own grid for accurate local propagation ratings

Adapting This Project

This project was built specifically for my station, equipment, and workflows.

If you decide to try it yourself, you will likely need to adjust file locations, hardware settings, network addresses, APIs, or other configuration details to match your own environment.

Rather than viewing the project as a finished product, think of it as an example of what can be created and adapted for your own shack.

Modern AI tools can often help make those changes quickly, even if you have little or no programming experience.

Both files are available for download in the project’s GitHub repository: github.com/N4MI73/streamdeck-hamradio

The next post in this series covers rotator control directly from the Stream Deck — sending azimuth commands to PSTRotatorAz via UDP with one button press, including preset headings for common DX regions from EM83.

Balloon Launch with APRS & WSPR Tracker

On May 5th, I had the opportunity to participate as part of a team that launched and tracked two high-altitude balloons. This was part of an educational outreach with Savannah River Academy, a school in my community. Members from my club, the Amateur Radio Club of Columbia County (ARCCC), and two meteorologists from the National Weather Service assisted the school with the balloon launch. This was part of a series of activities with the school to teach students about radio, weather and space, in preparation for a ham radio contact later this year with an astronaut aboard the International Space Station! Savannah River Academy was one of only a handful of schools in the U.S. selected to contact the ISS through the Amateur Radio on the International Space Station (ARISS) program.

The balloon launches were covered by two local TV stations and the local newspaper:
Columbia County students launch weather balloon
Students at Savannah River Academy participate in weather balloon launch
Sky is NOT the limit: Radio club partners with Grovetown students for weather balloon launch
Weather balloon camera captures breathtaking views above CSRA

The first balloon, which carried a payload with a SPOT Trace GPS tracker and a GoPro camera, was designed climb to an altitude of 70,000 – 100, 000 feet before bursting and falling back to earth. A parachute was attached to the payload so it could return to ground intact for retrieval by a chase crew. We expected the payload to land approximately 50 miles east of the launch site, but the balloon traveled much farther than anticipated. The chase teams scrambled and the payload was successfully retrieved approximately 150 miles from the launch site. The camera captured some amazing images while the balloon was in the stratosphere. Some of the best pictures are featured in the linked news stories.

Photo captured from the high altitude weather balloon shortly after launch. This camera captured lots of amazing images during this balloon flight.

One of the many spectacular views captures by the camera on the high-altitude weather balloon.

This post focuses primarily on the second “pico” balloon, which carried only a LightAPRS-W APRS and WSPR tracker as the payload, and was designed to reach an altitude of approximately 50,000 – 60,000 feet and achieve neutral buoyancy to travel for a much longer period of time. The LightAPRS-W, which is very small, was powered by two small PowerFilm 4.8V solar panels with two 5F 3V supercapacitors. With this power source, the tracker transmits APRS on VHF at .5 to 1 Watt, and WSPR on HF at 10 mW (1/100th of a Watt!).

We spent several days configuring and testing the tracker, using the configuration and programming instructions provided by QRP Labs on GitHub, and following some helpful suggestions in the Tips & Tricks for Pico Balloons wiki. The tracker also had two light wire antennas for APRS (19.4 inches) and 20 meter WSPR (16.6 feet), and a counterpoise (16.6 feet) attached.

Assembled LightAPRS-W tracker with two PowerFilm solar panels and super capacitors. It’s really small and light!

Once assembled, the tracker was easy to configure with an Arduino IDE to load the APRS callsign (K4KNS-11), WSPR callsign (K4KNS), and a few other settings. It’s best to pay very close attention to the instructions and comments in the configuration file! After the loading the configuration, we placed the tracker in the sun to test and listen for APRS and WSPR signals. We were able to confirm that the tracker was transmitting good APRS and WSPR signals. Due to the very low power of the VHF and HF transmitters, we could only confirm local reception. With the tracker stationary and in full sunlight, we noted that the LightAPRS-W transmitted an APRS packet approximately every 5 minutes, and a WSPR signal every 4-6 minutes.

Assembled and configured LightAPRS-W in the sun to test the solar panels and monitor APRS and WSPR signals.

APRS received from the LightAPRS-W during testing.

It’s one thing to have a good test under controlled conditions, but quite another to achieve success under field conditions. On the day of the launch, the weather was marginal, but within acceptable parameters for a launch. We double checked to ensure the tracker was powered up and transmitting, and tied it to the balloon.

Good test of the APRS signal on launch day!

We had a good launch. The balloon, with the tracker hanging 16.6 feet below the balloon (to accommodate the counterpoise) and trailing a 16.6 foot HF antenna, quickly rose to an altitude above any potential obstructions and began its journey. Within moments, we saw the first APRS positions appear on aprs.fi. A few moments later, using the WSPR Watch iPad app, we saw that the WSPR signal was being received across the U.S.!

The first APRS track for balloon K4KNS-11!

The 10 mW WSPR signal was received as far west as Oregon!

It was all going so well! We continued to watch the balloon tracking eastward and climbing, following the same track as the high-altitude balloon that had been launched about a half hour earlier. Then, after about an hour of flight, both the APRS and WSPR signal went off the air. At that time the balloon was 55 miles east of the launch site at an altitude of 37,500 feet.

The track and final position received from K4KNS-11.

Location, speed, course, speed, altitude, temperature, pressure and solar cell voltage data from K4KNS-11 exported from aprs.fi.

We’re not sure exactly why the signals were lost, but we do not believe the balloon went down in that location. We are speculating that the tracker may have been damaged due to the high wind speeds on lost power. It is unknown how much farther the balloon might have traveled. Despite the relatively short flight, we did collect some good data for the students at Savannah River Academy to evaluate. We also proved to ourselves that we could successfully launch a balloon and track it with APRS, and that a very weak WSPR signal transmitted from high altitude could be received by stations thousands of miles away!

Map on WSPRnet.org showing stations that received the K4KNS WSPR signal on May 5, 2021.

Spot Database for K4KNS on on May 5, 2021 from WSPRnet.org.

Using aprs.fi’s data export tool, we were able to export a KMZ file with the balloon’s tracking data, and use Google Earth to view the full track and altitude changes.

Google Earth map of the track and altitude changes for pico balloon K4KNS-11 on May 5, 2021.

This was an amazing experience! We captured many lessons learned, and we intend to build another more hardened version of the tracker so we can launch another balloon and hopefully track it over a much longer distance and time.

Additional information about both balloon launches is posted to the Amateur Radio Club of Columbia County Facebook page.

A New Weather Station For My QTH

Weather is a topic that comes up frequently in ham radio QSOs. Like most other hams, I’m interested in weather. For several years, I’ve used an AcuRite personal weather station that records basic weather measurements and feeds data to Weather Underground. ~~The WU page for my AcuRite Station is KGAGROVE14.~~ Update: The wind direction vane on the Acurite station broke, so I took the station offline in October 2020.

Earlier this week, I received a new Tempest Weatherflow station. I supported the project on Kickstarter, and waited anxiously for several months for the team to produce and ship the product. This station uses different technology, with electronic rather than mechanical sensors for wind speed/direction and precipitation. It also has sensors for lightning detection, ambient light, solar radiation and UV. I have it mounted on top of a 15-foot push-up fiberglass mast that I got from DX engineering. Setting up the weather station and getting it online was a very easy project.

The Tempest station sends current data to a phone/tablet app and a public web page, as well as feeding the weather widget in the right menu bar of this web site. It also sends data to Weather Underground. The WU page for my Tempest station is KGAGROVE47. ~~I am planning to leave both feeds running for a while to compare the results. I’m especially interested to compare the results for rain measurements.~~ Update: The Weather Underground feed for the Acurite station is no longer online as of October 2020, but the Tempest station is still up!