N4MI Ham Radio – My Adventures in Amateur Radio

PropMon – a Desktop Propagation Monitor

I’ve had a LilyGO T-Encoder Pro sitting on my desk for a while now, running FlightScnr — a slick little project by Yash Mulgaonkar that turns this small round display and knob into a flight tracker. It’s genuinely useful as a desk instrument, and it got me thinking: this hardware — a round AMOLED screen, a rotary encoder, Wi-Fi, all in a compact desk-friendly form factor — is a good general-purpose platform. Not just for flight tracking. I bought a second unit intending to build another FlightScnr, and then realized I really wanted something else on my desk: live HF propagation conditions, at a glance, without opening a laptop or pulling up a dashboard.

PropMon device in 3d printed stand (thanks to FlightScnr for the 3d model)

So I started what I’m calling the N4MI Desktop Instrument Series — a family of small purpose-built instruments on this same hardware. The first one is a Propagation Monitor, and as of this week I’m calling it done enough to call “v1.” The PropMon code was created with Claude, with design assistance from ChatGPT.

Where the data comes from

The interesting design decision here wasn’t really the display — it was figuring out where the propagation data should actually come from. I already had a propagation dashboard running on my ham computer, and the easy answer would have been to just add a small API endpoint to that existing server.

The problem is I stop that dashboard server all the time — there’s a Stream Deck button that kills it whenever I’m not actively using the shack computer for something. A desk instrument that goes dark every time I turn off an unrelated program isn’t really a desk instrument. The whole point is that it’s always there.

That ruled out the shack computer, and pointed me at the one machine in the house that’s genuinely always on: my NAS. So I built a small, dedicated backend service — I’m calling it PropMon — that runs there in Docker via Portainer, fetches propagation and weather data on a timer from HamQSL, NOAA, my WeatherFlow Tempest station, and NWS alerts, applies some rating logic, and serves it up as flat JSON. No UI, no database, just a small always-on service whose only job is to answer “how are the bands right now?” It’s a bit of duplicated logic between it and my existing dashboard, but decoupling the desk instrument from a machine I turn on and off all the time was worth that trade.

The instrument itself

The firmware cycles through four screens with a turn of the knob — an Overview with the headline band conditions, a full Bands screen showing all ten bands individually, a Solar screen with the full SFI/K-index/sunspot/X-ray picture, and an Alerts screen for anything from PropMon worth knowing about (a geomagnetic storm, a tower wind warning, that kind of thing). A short press forces a refresh, a longer hold pulls up a config screen showing connection status, and holding even longer than that drops you into Wi-Fi setup — more on that in a second.

I also added an ambient alert system on top of all four screens: if something changes — a new alert, or an existing one getting worse — a banner pops up for a few seconds regardless of which screen you’re looking at, and a small badge sticks around as long as the condition is active. I wanted the thing to actually catch my eye if 40 mph wind gusts show up in the forecast, not just quietly update a number I’d have to notice on my own.

Alert for Special Weather Statement from NWS

A real bug worth telling

One of the more satisfying moments in this project happened once I finally had live data flowing end to end. I glanced at the Bands screen mid-evening and 160 meters was showing GOOD — during full daylight, when 160m should be essentially dead from D-layer absorption.

I pulled up the real HamQSL reference page at the same exact moment to rule out stale data — same solar flux, same K-index, everything matched, so it wasn’t a caching problem on my end. That sent the bug report over to the PropMon side of the project, and it turned into a nice bit of detective work: the time-of-day logic PropMon uses was built on a fixed year-round UTC clock — dusk was hard-coded as roughly 6 to 9 PM Eastern, no matter the season. For most bands that’s a forgivable approximation. But 160m and 80m are basically all-or-nothing — fully shut down by day, wide open once it’s genuinely dark — so a few hours of seasonal drift on a fixed clock was enough to produce a rating that was flatly impossible rather than just a little off.

The fix computes real civil dusk and dawn for my actual location instead of guessing from a fixed clock, and only for those two bands specifically. I checked the computed dusk times against my own years of on-air experience — 160m opening around 6 PM in winter, more like 9 PM in summer — and they lined up within about ten minutes at both extremes. A nice moment where the math and the years of just being on the radio agreed with each other.

Getting Wi-Fi credentials onto the thing without a laptop

The last big piece was making this something I could actually hand to another ham without them needing to edit source code and reflash it just to get on their own Wi-Fi. The device now opens its own temporary network for a few minutes when you hold the knob down — connect your phone, a page pops up automatically, pick your network from a scanned list, type your password, done. Credentials get stored on the device itself, and the setup network disappears once it’s connected.

Getting there took a couple of real, honest bugs — one where the device could report “connected!” without actually testing the password you’d just typed (found because I deliberately tried a wrong one and it worked anyway, which is exactly the kind of thing worth testing on purpose), and one where scanning for networks and running the setup hotspot at the same time turned out to be a genuine limitation of the ESP32’s radio, not something to just retry harder against. Both are fixed now and confirmed working end to end, wrong passwords included.

Where it stands

As of this week, it’s running live on my desk — real Wi-Fi, real data, correctly-rated bands, day or night. I’m calling this v1 and I’m going to let it run for a while in actual daily use before deciding what’s next. There’s a whole list of other instruments I want to build on this same platform — an APRS activity monitor, a DX cluster monitor, satellite pass alerts — but that’s future work for another post.

If you want to build one of these yourself, both halves of the project are public:

N4MI Propagation Monitor — https://github.com/N4MI73/n4mi-propagation-monitor — the firmware, plus build/flash instructions and the Wi-Fi setup walkthrough
PropMon — github.com/N4MI73/streamdeck-hamradio/tree/main/propmon — the backend service, deployable via Docker/Portainer

The firmware and backend service are in different repositories due to a shift in planning mid-project (my rookie mistake). Future instruments will have the firmware and backend service in the same repository. Both READMEs point at each other, so you can start from either one. Fair warning: you’ll want to already be comfortable standing up a Portainer stack before you dive in — that part’s on you.

What’s Next?

Now that the Propagation Monitor is running day-to-day, I’m turning my attention to the next instrument in the series: APRSMon, a desk display for local APRS activity — nearby stations, weather, and alerts. Same hardware, same one-glance philosophy, different question to answer. More on this as it takes shape.

73,
Dan — N4MI

ManualShelf – A Personal Manual Catalog for the Ham Shack

If you’ve been following this blog, you know I’ve been building out a suite of automation tools for my ham shack — a Stream Deck-based launcher system, a propagation dashboard, a storm alert system, and a ham radio content aggregator called HamShackFeed Pro. Each of these tools scratches a specific itch, and this one is no different.

This post introduces ManualShelf, a locally-hosted manual catalog I built to solve a problem that probably sounds familiar: I have a lot of PDF manuals, and I can never find the one I need.

The Problem

Over the years I’ve accumulated manuals for radios, antennas, accessories, logging software, digital mode programs, and more. They live in a few folders on my ham computer, organized well enough, but “well enough” stops working the moment you’re in the middle of a QSO and need to find a specific setting buried somewhere in a 180-page Icom manual.

Windows Explorer is fine for managing files, but it’s not a library. There are no thumbnails, no descriptions, no tags, and no way to search inside documents. I knew a manual existed — I just couldn’t find it fast enough.

I looked at full-featured document management systems like Paperless-NGX, which runs on my NAS and is excellent for what it does. But it’s heavyweight — it requires Docker, a database server, and a full processing pipeline. For a folder of radio manuals, that’s more infrastructure than the problem deserves.

What I wanted was something simpler: show me my manuals, let me search them, and open the right one. That’s ManualShelf.

What It Is

ManualShelf is a lightweight web application that runs on your own computer. You point it at your folders, it scans for supported files, generates thumbnails, and builds a searchable catalog. From then on you can browse, filter, search, and open any document in a few clicks — all from a clean browser interface at http://localhost:8075.

Everything runs locally. No cloud, no account, no subscription. Your files stay exactly where they are — ManualShelf only stores metadata (title, tags, descriptions) and thumbnails in its own small database.

How It Works

Adding Files to the Catalog

Click Add Manuals, paste in a folder path, and hit Scan. ManualShelf recursively searches the folder and everything inside it, then shows you a list of what it found. Files already in the catalog are grayed out so you don’t add duplicates. New files are pre-checked and ready to add.

Click Add Selected and ManualShelf does the rest — generating a thumbnail from the first page of each PDF, recording the file size and page count, and adding it to the catalog. You can save frequently scanned folder paths in Settings so you don’t have to retype them each time.

Finding What You Need

The search box works across title, filename, make, model, description, and tags simultaneously. But the more useful feature for a manual-heavy catalog is full-text PDF search — ManualShelf can look inside the text of your PDFs, not just their filenames. Run Re-index PDFs from the Settings menu once, and from then on a search for “AGC” or “menu 5-7” will surface the right manual even if those words aren’t in the filename.

Results that matched on text content (rather than metadata) show a small purple PDF TEXT badge so you know why they surfaced.

The sidebar lets you filter by file type, category, tags, or favorites. A tag cloud makes one-click filtering easy once you’ve tagged your files.

The Detail Panel

Click any card to open the detail panel. This is where you edit the title, add make and model information, assign a category, write a short description, and add tags. The file path, page count, and file size are shown at the top, and an Open File button launches it in your default application — Adobe Reader for PDFs, Excel for spreadsheets, and so on.

The detail panel also tracks how many times you’ve opened a file, which turns out to be a handy “most used” indicator over time.

Supported File Types

ManualShelf handles more than just PDFs. The full list:

PDF — thumbnail from first page, full-text search indexing
Images (PNG, JPG, GIF, BMP, WEBP) — useful for settings screenshots
Word documents (DOCX, DOC)
Spreadsheets (XLSX, XLS, CSV)
PowerPoint presentations (PPTX, PPT)
Markdown files (MD) — rendered and displayed in-app
Plain text (TXT) — displayed in-app
HTML files

Bulk Editing

Once you have a catalog going, you’ll want to tag and categorize things. The Select mode lets you click multiple cards and apply tags or a category to all of them at once — either replacing existing tags or merging with them. Much faster than editing each file individually.

Update Detection

When a manufacturer releases a revised manual and you drop the new version into your folder with the same filename, ManualShelf notices. Re-scanning the folder flags the changed file with an amber UPDATE badge, pre-checked for you to select. Updating it refreshes the thumbnail and file data while keeping all your metadata — title, tags, category — intact.

Settings and Cross-Computer Visibility

The Settings panel is where you configure a few important things. The Computer Name identifies this machine in the catalog. The NAS Exchange Folder is where ManualShelf publishes a summary of your catalog — if you run ManualShelf on a second computer pointing at the same network folder, each machine can see the other’s catalog under a Remote Manuals filter. You can browse titles, descriptions, tags, and metadata for manuals on the other computer, which is useful for knowing a document exists somewhere on your network.

I run ManualShelf on both my ham computer and my admin computer. The ham computer has radio and antenna manuals; the admin computer has more general reference documents. Both can see each other’s catalogs.

The Help System

Since I wanted ManualShelf to be useful to others beyond my own shack, I built a help modal into the app — accessible via the ? button in the top right corner or from the Settings panel. It covers the full workflow, all supported file types, how full-text search works, how to use bulk editing, and the cross-computer setup process.

How It Was Built

ManualShelf is built in Python using Flask — a lightweight framework for running web applications locally. The catalog is stored in SQLite, which is a simple database format that requires no server setup; it’s just a file on disk. PDF thumbnails are generated using a library called PyMuPDF, which can read PDF files and render individual pages as images. The web interface is a single HTML file with straightforward JavaScript — no frameworks, no build process.

The whole thing is designed to be simple to install and run. If you have Python on your computer, it’s a few commands to get started.

Part of a Larger Project

ManualShelf is part of my ongoing ham shack automation project, which started with a five-part blog series about using an Elgato Stream Deck to launch radio software, control my antenna rotator, and display a propagation dashboard. Since then I’ve added a storm alert system that monitors my WeatherFlow Tempest weather station, a ham radio content aggregator called HamShackFeed Pro, and now ManualShelf.

All of these tools share the same design philosophy: run locally, no cloud dependencies, open the right thing with one button press.

Everything is available free on GitHub at github.com/N4MI73/streamdeck-hamradio, with full setup instructions in the README.

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.

What’s Next

A few things are already on the backlog for ManualShelf — a notes field for each entry, related file linking, and a broken file detector that flags catalog entries whose files have been moved or deleted. Nothing scheduled yet, but the foundation is solid and extending it is straightforward.

If you give it a try, I’d be curious what you think. The ham radio context is just where it was born — the app is general-purpose and works just as well for any collection of documents you want to keep organized.

73, Dan — N4MI

HamShackFeed Pro — Upgrading My Newsroom

When I wrapped up the HamShackFeed post a few days ago, I called it version 1 and listed a few things on the future ideas list — podcast audio playback and a mobile-friendly layout. The podcast player made it into the HTML file shortly after that post went up. The other two are still in progress.

What I didn’t anticipate was a completely different set of problems surfacing through daily use — problems that the original “no server, no installation, just a file” approach couldn’t solve without a fundamental rethink. That rethink is HamShackFeed Pro.

HamShackFeed Pro dashboard showing 200 items across blog, podcast, and YouTube sources in a three-column card layout with source sidebar and filter buttons — HamShackFeed Pro loaded with 200 items across blogs, podcasts, and YouTube channels. The sidebar shows sources grouped by type with unread counts, and the card grid displays mixed content sorted newest-first.

What Broke in Daily Use

Part 4 presented HamShackFeed’s single-file design as a feature, and it is one — you can email it to another ham and they’re up and running immediately. But that same simplicity creates real friction once you’re actually relying on it every day.

The API key situation. HamShackFeed fetches RSS feeds through a free proxy service called rss2json.com, which handles a browser security restriction that prevents web pages from pulling in content from other domains. What the Part 4 post didn’t cover — because it wasn’t an issue at the time — is that the free tier of rss2json.com throttles unauthenticated requests to one every ten seconds. In practice, that means sources load in slow motion and the Add Source button fails almost every time. The fix is a free API key from rss2json.com, which raises the limit to 10,000 requests per day. But it’s a setup step that isn’t obvious, and it became the number one question after that post.

localStorage is fragile. Every source you add, every article you mark as read — all of it lives in your browser’s localStorage, which I mentioned in Part 4 as where “state” is stored. What I glossed over is that localStorage is tied to one specific browser on one specific machine. Clear your browser history and it’s gone. Open the file on a different computer and it doesn’t know who you are. That’s fine for a quick-access tool but not great for something you’re checking multiple times a day.

One computer only. I have a ham computer in the shack and an admin computer at my desk. Every time I moved between them, I was looking at a different feed with different read state. Keeping them in sync manually wasn’t going to happen.

The Upgrade: Adding a Server (on Purpose)

Part 4 made a point of saying HamShackFeed needed no server. HamShackFeed Pro adds one — and that’s a deliberate trade-off, not a regression.

The server is small, runs locally on your ham computer, and you start it the same way you start the propagation dashboard: one PowerShell script, one Stream Deck button. In exchange for that setup step, you get three things that a standalone file simply cannot provide.

No API key needed. When a server fetches RSS feeds, the browser security restriction that made rss2json.com necessary doesn’t apply. The server talks directly to DX World, Ham Radio Workbench, the ARRL — wherever — and delivers the content to your browser clean. No proxy, no rate limits, no account to create. The ARRL feed, which rss2json.com occasionally struggled with because it uses HTTP instead of HTTPS, just works.

Persistence that actually persists. Everything in HamShackFeed Pro is stored in a SQLite database on your ham computer — sources, read state, favorites. Clear your browser history, reboot the machine, use a different browser entirely. When you come back, your feed looks exactly the same. The database file lives in your Ham Scripts folder alongside everything else.

Any device, same feed. The server binds to your local network, not just localhost. Any device on your WiFi — phone, tablet, laptop at the other desk — can open http://192.168.x.x:8074 and see the same feed with the same read state. Mark something read on your phone and it’s read on the shack computer too. Everything lives in one place.

HamShackFeed Pro help modal showing the About Pro section with a callout stating No API key required — Pro fetches RSS feeds directly on the server with no rss2json.com proxy needed — The built-in help modal spells out what’s different about Pro — no API key required, read state stored server-side, accessible from any device on the network.

HamShackFeed vs HamShackFeed Pro

Feature	HamShackFeed	HamShackFeed Pro
RSS proxy API key	Required	Not needed
Source persistence	Browser localStorage	SQLite database
Read state persistence	Browser localStorage	SQLite database
Cross-device access	No	Yes — local network
Background refresh	No	Every 30 minutes
Installation required	None — open a file	Python + 4 packages
Portable / shareable	Yes — email it to anyone	Local server only

What Stayed the Same

Intentionally, a lot. The visual design is identical — same dark navy theme, same card layout, same color coding for blogs (cyan), podcasts (gold), and YouTube (red). The sidebar, the favorites panel, the podcast player, the search bar, the filter buttons — all there, all working the same way.

The default source list, for the most part, carries over from Part 4. Two of the podcasts did not seem to be recently active and were replaced with Ham Radio Workbench and the ICQ Podcast, both active and worth following.

If you’ve been using HamShackFeed and have added your own sources, there’s a migration path. A short browser console command exports your custom sources as JSON, and a Python script imports them into Pro via the API. The whole process takes about two minutes.

Running Both

HamShackFeed and HamShackFeed Pro coexist without any conflict. The HTML version doesn’t use a port at all — it’s just a file. Pro runs on port 8074. If you want to keep the HTML version as a portable option to share with another ham, nothing changes. Pro is just the better daily driver when you’re at your own station.

My propagation dashboard runs on port 8073. Both it and HamShackFeed Pro can be open at the same time — I usually have both up when I’m in the shack.

The Stream Deck Button

Same setup as the other shack tools — Advanced Launcher plugin, pointed at PowerShell 7, with the Start In directory set to the hamshackfeed_pro folder so Flask can find its templates:

Executable:  pwsh.exe
Arguments:   -ExecutionPolicy Bypass -Command "cd 'C:\Ham Scripts\hamshackfeed_pro'; python server.py"
Start In:    C:\Ham Scripts\hamshackfeed_pro

The server opens in a minimized window and launches the browser automatically.

On the Future Ideas List From Part 4

The closing section of the HamShackFeed post listed three things: podcast audio playback, DXCC expedition alert integration, and a mobile-friendly layout.

The podcast player landed in the HTML version shortly after that post. HamShackFeed Pro carries it forward — podcast cards with audio links show a Play button, and a persistent player bar appears at the bottom of the screen with full controls.

HamShackFeed Pro podcast player bar at the bottom of the screen showing episode title, Ham Radio 2.0 source label, play/pause button, skip back 15 seconds, skip forward 30 seconds, and a seek bar — The persistent podcast player bar — clicking Play on any podcast card opens this at the bottom of the screen. It stays visible as you browse the rest of the feed.

The mobile layout question is partly answered by Pro’s cross-device access — any phone or tablet on the local network can open the feed in a browser and it renders fine. A purpose-built mobile layout is still a future idea, but day-to-day it works well enough as is.

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.

Get It

All the files are in the GitHub repo at github.com/N4MI73/streamdeck-hamradio under the hamshackfeed_pro/ folder. Full setup instructions are in the README, including how to install the Python dependencies, configure the Stream Deck button, open the Windows Firewall port for cross-device access, and migrate your sources from the HTML version.

If you’ve been using HamShackFeed and running into the API key or localStorage issues, Pro is a straightforward upgrade. If you’re coming to this fresh, Pro is the version to start with.

Stream Deck for Ham Radio — Part 5: Custom Icons, Getting Started & Closing Thoughts

This is the final post in the Stream Deck for Ham Radio series. We’ve covered mode launchers, a live propagation dashboard with storm alerts, rotator control, and a ham radio content aggregator. This post ties it all together — how the custom icons were created, how to get started building your own setup from scratch, and some closing thoughts on how this project evolved.

Everything built in this series is available for download at the project’s GitHub repository: github.com/N4MI73/streamdeck-hamradio. A complete step-by-step setup guide is also available as a PDF download — more on that at the end of this post.

Stream Deck main button layout for ham radio showing FT8, SSB, CW, rotator control, dashboard, and utility buttons — The main Stream Deck layout as it stands today — mode launchers across the top row, utility and control buttons below, with folder buttons opening dedicated pages for rotator control and radio programming.

Custom Icons

The Stream Deck’s physical buttons are small — about 15mm square — so icons need to communicate their function at a glance without any reading required. The built-in Stream Deck software includes a basic icon editor and access to a marketplace, but I wanted something more cohesive — a consistent visual language across every button that made the whole layout feel like a purpose-built tool rather than a collection of random images.

All of the custom icons in this project were generated using Python with the Pillow imaging library, with Claude helping design and write the generation scripts. Each icon is a 144×144 PNG with a dark background, rounded corners to match the physical button shape, and color coding by function — cyan for digital modes and web tools, warm tones for voice modes, red for shutdown, and compass-themed designs for the rotator controls.

Here’s a sample of the icon set:

The radio programming folder contains icons for each radio in the shack — actual photos of each model used as button images, making it immediately obvious which button opens which programming software. This folder was added after the rest of the project was built, which is a good example of how the setup grows naturally over time.

Stream Deck radio programming folder showing RT Systems and other programming software buttons — The radio programming folder — each button opens the programming software for a specific radio. The RT Systems subfolder was added later as the shack’s radio collection grew.

Stream Deck RT Systems subfolder showing radio icons for each programmable radio — The RT Systems subfolder — a nested folder within radio programming, added organically as the project evolved. Each button shows the actual radio model for instant recognition.

The complete icon set — all 39 icons including compass directions, DX region presets, mode launchers, utility buttons, and radio programming icons — is available in the icons/ folder of the GitHub repository.

Getting Started

If this series has you interested in building your own setup, here’s the honest starting point: you don’t need to build everything at once. The most useful place to start is a single button that launches one app you open every operating session. Get that working, then add another. The full setup shown in this series grew one button at a time over several weeks.

The minimum requirements to get started:

An Elgato Stream Deck (any model — the 15-key MK.2 is a good starting point)
The free Stream Deck software from Elgato
The free Advanced Launcher plugin by BarRaider from the Stream Deck Plugin Store
Python 3.x installed with “Add to PATH” checked — only needed for the dashboard
The scripts and files from the GitHub repository saved to C:\Ham Scripts\

The scripts are plain text files that can be opened and edited in Notepad. The paths to your applications are set at the top of each script — update those to match your installation and everything else works as written. Claude at claude.ai can write or troubleshoot PowerShell scripts if you describe what you want — that’s exactly how all of the scripts in this project were built.

A complete step-by-step guide covering everything from finding app paths to configuring Stream Deck buttons, writing PowerShell scripts, setting up the dashboard server, and creating custom icons is available as a free PDF download:

📄 Download the Stream Deck Setup Guide (PDF)

Closing Thoughts

This project started with a simple goal — stop manually opening the same five apps every time I sat down to operate. It grew from there into something I use every day: mode launchers, a propagation portal, storm alerts, rotator control, a content aggregator, and a full set of custom icons. None of it was planned from the start. Each piece was added because something in the workflow felt like it could be smoother.

That’s the thing about a setup like this — it’s never really finished, and it doesn’t need to be. The Stream Deck is just a tool for running scripts, and PowerShell scripts are just text files. Adding a new button takes a few minutes. Changing how something works takes editing a few lines in Notepad. The barrier to customization is low enough that the setup can evolve naturally with your operating habits.

I’m sharing all of this as a fellow hobbyist — not for any commercial purpose, and not because my particular setup is the right one for anyone else’s shack. The scripts, dashboard, icons, and setup guide are all free to download, modify, and build upon. If you improve something, add a feature that would be useful to others, or adapt this for a different logging program or rotator controller, please share it. That’s how the ham radio community has always worked, and it’s how this kind of project gets better over time.

Thanks for following along with the series. The complete project is at github.com/N4MI73/streamdeck-hamradio. 73 de N4MI!

Stream Deck for Ham Radio — Part 4: HamShackFeed — My Personal Ham Radio Newsroom

Ham radio has a surprisingly rich content ecosystem. There are blogs covering DX expeditions and technical topics, podcasts perfect for the commute, and YouTube channels with tutorials, reviews, and operating demonstrations. The problem isn’t that the content isn’t out there — it’s that it’s scattered across a dozen different sites, and keeping up with all of it means either spending half your operating time clicking through bookmarks or missing things entirely.

I’ve had the experience of finding out about a DX expedition after it was already over, or discovering a podcast episode that would have been useful before a contest two weeks after it aired. A folder of bookmarks you mean to check regularly is not the same as actually checking them regularly. What I wanted was one place where everything shows up automatically — blogs, podcasts, and videos — without any clicking around.

The result is HamShackFeed — a single HTML file that aggregates RSS feeds from ham radio blogs, podcasts, and YouTube channels into one clean, searchable dashboard. No installation. No server. No account. No subscription fee. Just open the file in Chrome and your content is there.

HamShackFeed dashboard showing ham radio blog, podcast, and YouTube content cards in a three-column layout with source sidebar and filter buttons — HamShackFeed loaded with 104 items across 17 sources — blogs, podcasts, and YouTube channels all in one view. The ZD8KX Ascension Island DX expedition announcement and a new WSJT-X 3.0 release notice are visible alongside YouTube thumbnails from Ham Radio Crash Course.

What Is RSS?

RSS (Really Simple Syndication) has been around since the early days of the internet and remains the most reliable, algorithm-free way to follow content. Almost every blog, podcast, and YouTube channel publishes an RSS feed — a structured list of their latest content that any reader can consume. There’s no feed curation, no promoted posts, no engagement-based sorting. Just the actual content from the sources you choose, in chronological order. Most people don’t know it’s there, but it’s been quietly powering podcast apps and news readers for decades.

The Sources

HamShackFeed comes pre-configured with 17 sources across three content types, all color coded — cyan for blogs, gold for podcasts, red for YouTube.

Blogs — DX World, On All Bands, KB6NU’s Ham Radio Blog, DX Zone, DX News, AR Newsline, and This Week in Amateur Radio. Between them these cover DX expedition announcements, operating tips, propagation news, technical articles, and the weekly ham radio news cycle.

Podcasts — Ham Radio Crash Course (Josh KD9FRQ), ARRL Roundtable, 100 Watts and a Wire, and Ham Radio 2.0 (Jason KC5HWB). All fetched directly via RSS — no podcast app required.

YouTube — Ham Radio Crash Course, Ham Radio Concepts, Ham Radio 2.0, KM4ACK, Dave Casler (KE0OG), and Ham Nation. YouTube publishes an RSS feed for every channel, so new video titles, descriptions, and thumbnails appear in the dashboard automatically — no YouTube API key needed.

Features

Each piece of content appears as a card showing the source, content type, publication date in human-readable form (Today, Yesterday, 3d ago), title, description excerpt, and thumbnail when available. Four filter buttons at the top — All, Blog, Podcast, Video — narrow the view instantly. The source sidebar on the left lists all sources grouped by type, each with an unread count badge, and clicking any source filters the feed to show only that source’s content.

Read tracking is built in — each card has a Mark Read button, and once marked, cards dim but stay visible. An Unread Only toggle hides everything already read so you can focus on fresh content. Mark All Read clears the queue in one click. All read state is stored in your browser’s local storage and persists between sessions.

The search bar at the top filters feed items in real time as you type. Longer queries also trigger a DuckDuckGo web search filtered to ham radio content, with results appearing below the main feed — a quick way to find content beyond what’s in your current source list.

Adding a new source is straightforward — paste any blog URL, podcast URL, or YouTube channel URL into the Add Source modal and the dashboard detects the feed automatically. Paste a YouTube channel URL and it extracts the channel ID and constructs the RSS feed URL without any manual steps. Added sources persist in local storage and survive page refreshes.

HamShackFeed Add Content Source modal showing URL field, optional label field, and auto-detect type dropdown — The Add Content Source modal — paste any blog, podcast, or YouTube channel URL and the dashboard auto-detects the feed type and label. No manual RSS URL hunting required.

HamShackFeed showing YouTube video thumbnail cards from Ham Radio Concepts and Ham Radio 2.0 alongside DX World blog cards for active DX expeditions — YouTube cards display full thumbnails alongside blog content — three active DX expeditions (A52EA Bhutan, 3G0Z Juan Fernández Islands, ZL7IO Chatham Islands) visible alongside EME and digital mode video content from Ham Radio Concepts and Ham Radio 2.0.

How It Works

HamShackFeed is a completely self-contained HTML file. Unlike the propagation dashboard from Part 2 of this series, it doesn’t need a local Python server — it works by opening the file directly in Chrome. Feed fetching uses the free rss2json.com API, which handles the browser’s cross-origin restrictions (CORS) by fetching feeds server-side and returning them as clean JSON. All state — read items, added sources, removed sources — is stored in browser localStorage. Nothing is sent to any server except the feed fetch requests themselves.

Getting Started

Requirements: Google Chrome (or any modern browser) and an internet connection. That’s it — no Python, no PowerShell, no installation of any kind.

Download HamShackFeed.html from the project’s GitHub repository: github.com/N4MI73/streamdeck-hamradio
Save it anywhere on your PC — C:\Ham Scripts\ works well if you have the Stream Deck setup from the rest of this series
Open it in Chrome — double-click it in File Explorer or drag it into a Chrome window
Feeds load automatically — give it 10–20 seconds for all sources to fetch
Click Unread Only to focus on fresh content, use the filter buttons to narrow by type, and add or remove sources to match your interests

Bookmark the local file path in Chrome for easy access: file:///C:/Ham%20Scripts/HamShackFeed.html

Adding It to Your Stream Deck

If you’re following this series and already have a Stream Deck set up, adding HamShackFeed takes about 30 seconds. Use the Advanced Launcher plugin with Chrome as the application and the file path as the argument:

--profile-directory="Profile 1" "C:\Ham Scripts\HamShackFeed.html"

A matching Stream Deck icon is available in the icons folder of the GitHub repository.

Sharing With Other Hams

Because HamShackFeed is a single self-contained file with no dependencies, sharing it is as simple as sharing any file — email it, put it on a club website, or link it from GitHub. Anyone can download and use it immediately. The default source list is pre-configured with all 17 sources, and each operator’s customizations (added sources, read state) are stored locally in their own browser — sharing the file with another ham gives them a clean slate with the default sources, not your personal configuration.

There’s also an interesting club application here. A club could maintain a version pre-configured with their own newsletter RSS feed, local repeater club news, and regional content alongside the general ham radio sources — then share it at a club meeting as a single-file download.

Closing Thoughts

The ham radio content community is larger and more active than many operators realize. HamShackFeed makes it practical to follow all of it without spending time hunting for updates. RSS is older than most social media platforms but remains the best way to follow content on your own terms — no algorithm deciding what you see, no promoted posts, just the content from the sources you choose in the order it was published.

This is version 1. Future ideas on the list include audio playback for podcasts directly in the dashboard, DXCC expedition alert integration to cross-reference DX World announcements with your most wanted list, and a mobile-friendly layout for tablet use at the operating position.

Download HamShackFeed from the project repository at github.com/N4MI73/streamdeck-hamradio.

Stream Deck for Ham Radio — Part 3: Rotator Control

One of the more satisfying parts of this whole project was getting rotator control working directly from the Stream Deck. Before this, pointing the beam meant switching to PSTRotatorAz, clicking a bearing, and waiting. Now I press one button and the rotator starts moving. For DX region presets, I press the Europe button and the beam swings to 50 degrees automatically — no manual entry required.

This post covers Part 3 of the Stream Deck series — controlling a Yaesu antenna rotator directly from the Stream Deck using PowerShell scripts that send UDP commands to PSTRotatorAz.

Stream Deck rotator control page showing compass direction buttons, DX region presets, stop button, and bearing query button — The rotator control page — compass directions across the top two rows, DX region presets along the bottom, with Stop and Bearing query buttons in the center.

How It Works

PSTRotatorAz supports remote control via UDP on port 12000. A PowerShell script can send an azimuth command directly to the running software using a simple XML-formatted UDP packet — no third-party plugin required, just PowerShell’s built-in networking. The command format is straightforward:

<PST><AZIMUTH>270</AZIMUTH></PST>

That’s it. PSTRotatorAz receives the packet and starts rotating to the specified bearing. The script validates the azimuth value (0–360), sends the command, confirms it in the console, and exits. The whole thing runs in under a second.

Enabling UDP Control in PSTRotatorAz

Before the scripts will work, UDP control needs to be enabled in PSTRotatorAz:

Open PSTRotatorAz
Go to Communication → UDP Control → Enable
Set the port to 12000 (default)
Click OK and confirm the UDP indicator is active

To verify the port is available before enabling: open a PowerShell window and run netstat -ano | findstr ":12000" — no output means the port is free.

The Two Scripts

RotatorAzimuth.ps1 is the workhorse. It accepts a single -az argument and sends the corresponding azimuth command to PSTRotatorAz. Every compass direction button and every DX region preset calls the same script with a different azimuth value:

-ExecutionPolicy Bypass -File "C:\Ham Scripts\RotatorAzimuth.ps1" -az 50

RotatorStop.ps1 sends an immediate stop command to PSTRotatorAz, halting rotation wherever the antenna currently is. This is useful if you press the wrong direction button or want to stop mid-swing.

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

Button Layout

The rotator control page is organized as a folder within the main Stream Deck layout — pressing the Rotator Control button on the main page opens this dedicated page with an automatic back button in the top left corner.

The layout is arranged in three rows:

Row 1 — Back button, NW (315°), N (0°), NE (45°), Europe (50°)
Row 2 — Asia (342°), W (270°), STOP, E (90°), West Africa (80°)
Row 3 — Pacific (290°), SW (225°), S (180°), SE (135°), S. America (145°)

The compass directions are arranged spatially so they mirror an actual compass rose — N at the top center, S at the bottom center, and the intercardinal points in their correct positions. The DX region presets are placed on the outer edges next to the compass direction they’re closest to, making it intuitive to find the right button at a glance.

DX Region Presets

The five DX region buttons use approximate great-circle headings from my grid square EM83 in central Georgia:

Europe — 50°
West Africa — 80°
S. America — 145°
Pacific — 290°
Asia — 342°

These are starting points rather than exact headings — propagation paths vary by band and conditions. For a quick DX pileup, pressing Europe and being within a few degrees is close enough. For precision work, PSTRotatorAz’s built-in DXCC lookup or an online great-circle calculator will give you the exact bearing. Operators in other grid squares should calculate their own headings and update the -az values in their Stream Deck button configurations accordingly.

The Custom Icons

Each rotator button has a custom icon showing a compass rose with the beam arrow pointing in the correct direction, color coded by type — cyan/blue for compass directions, earth-tone colors for DX regions, and red for the Stop button. At a glance I can tell exactly where each button will point the beam without reading the label. The Bearing button shows a compass with a query indicator — pressing it displays the current azimuth reported by PSTRotatorAz.

The next and final post in this series covers how the custom icons were created, a getting started guide for operators who want to build their own setup from scratch, and some closing thoughts on how this project evolved over time.

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.

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.

Stream Deck for Ham Radio — Part 1: Mode Launchers & PowerShell Scripts

Why Use a Stream Deck?

The Elgato Stream Deck is best known in the gaming and streaming world, but its one-press button triggering makes it a natural fit for ham radio operating workflows. With some assistance from AI (Claude), I was able to create buttons that open all of the apps I use across my different operating modes — with a single press.

Every time I sit down to operate, I was opening the same combination of apps — logger, digital mode software, cluster, rig control. The Stream Deck eliminates that repetitive clicking and lets me focus on what matters: operating.

The real power comes from pairing the Stream Deck with PowerShell scripts on Windows, which gives far more control than simple app launching — I added sequenced delays, popup reminders, conditional logic, and even send commands directly to running software. Since I operate multiple modes (FT8, CW, SSB), switching between software stacks used to be one of the most error-prone parts of my workflow — wrong rig interface settings, apps launched in the wrong order, forgetting to reset something between modes. The Stream Deck removes that friction entirely.

Elgato Stream Deck sitting on the operating desk at N4MI, showing custom ham radio mode buttons — The Stream Deck lives right on the operating desk — one press launches the complete software stack for any mode.

The Foundation — PowerShell Scripts

The Stream Deck’s built-in “System > Open” action can launch any application, but it lacks the ability to pass arguments or introduce delays between launches. The Advanced Launcher plugin (BarRaider) solves this by adding an Arguments field and a Run as Administrator option.

PowerShell is built into every Windows installation and is the perfect tool for writing multi-step launch sequences. Scripts are plain text files (.ps1) that anyone can read, edit, and customize in Notepad — no programming background required.

The key PowerShell concepts used in these scripts are straightforward:

Start-Process — launches an application
Start-Sleep — introduces a delay between launches
param() — lets one script serve multiple modes via a -mode argument
switch — routes execution to the right mode block
MessageBox — displays a popup reminder before launching
System.Net.Sockets.UdpClient — sends UDP commands directly to running software

Scripts are stored in a dedicated folder (C:\Ham Scripts) and called from Stream Deck buttons with the -ExecutionPolicy Bypass flag to allow unsigned local scripts to run. Claude generated all of the scripts I used, and also produced a step-by-step PDF guide for building your own from scratch.

All scripts are available for download on the project’s GitHub repository: github.com/N4MI73/streamdeck-hamradio

Custom Workflow Launchers

Different operating modes require different software combinations. Rather than memorizing which apps to open for each mode, each Stream Deck button launches the complete stack for that mode with one press.

App launch order matters. For my FT8 workflow, JTAlert depends on WSJT-X being fully loaded, and Amateur Contact Log (ACLog) needs to be ready before either. A short delay (typically 3–4 seconds) between each app gives the previous one time to initialize before the next tries to connect. For apps that require administrator privileges — like MRP40 in my CW workflow — the Advanced Launcher plugin handles elevation automatically.

Stream Deck software showing custom ham radio button layout for N4MI including FT8, SSB, CW, rotator control, and dashboard buttons — The main Stream Deck profile — FT8, SSB, and CW each launch their complete software stack with one press. The second row handles the web portal, rotator control, SDR, and logging tools.

My Three Workflows

FT8/FT4
Launch sequence: ACLog → PSTRotatorAz → WSJT-X → JTAlert

ACLog must be configured with Rig Interface OFF and TCP Server ON for WSJT-X to connect
A popup reminder appears before launch prompting me to verify the ACLog settings
JTAlert receives spot data from WSJT-X and requires it to be fully loaded first
Delay before JTAlert: 4 seconds (adjustable based on PC speed)

CW
Launch sequence: ACLog → PSTRotatorAz → MRP40

ACLog switches to Rig Interface ON (COM 6 for my IC-7610) and TCP Server OFF
MRP40 (Morse decoder) must run as Administrator — handled automatically by Advanced Launcher
MRP40 must be launched from its own working directory to find its supporting files — a known quirk, fixed with -WorkingDirectory in the PowerShell Start-Process call
The popup reminds me to verify MRP40’s COM port and sound card settings, which it doesn’t always save reliably between sessions

SSB
Launch sequence: ACLog → PSTRotatorAz

Simplest workflow — rig interface active, no digital mode software needed
Popup confirms ACLog has Rig Interface enabled before launching

ACLog Multi-Rig Tip
ACLog supports saving multiple rig configurations and switching between them instantly with Ctrl+X. Rather than manually changing settings each time, I have one profile configured for FT8 (TCP Server ON, Rig Interface OFF) and one for CW/SSB (Rig Interface ON). The popup reminder in each launcher script tells me which profile to select before clicking OK — a small thing that has saved me from a lot of head-scratching.

Clean Shutdown Script
A dedicated “Close All Apps” (73) button handles the shutdown sequence in reverse dependency order:

A confirmation prompt before doing anything
A rotator reminder to return to North (0°) before closing PSTRotatorAz
JTAlert closed before WSJT-X, WSJT-X before ACLog — proper dependency order
A prompt asking whether to stop the dashboard Python server or leave it running

On another Stream Deck screen, I still have dedicated icons to launch the programs individually, in case I have a need to open one without the others.

Future posts in this series will cover a tailored propagation and information portal for my location and callsign, and controlling my rotator directly from the Stream Deck.

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.

📁 Downloads: All scripts, the propagation dashboard, and the complete icon set are available at the project repository: github.com/N4MI73/streamdeck-hamradio

Possibly My Last DXCC Endorsement (But I Sure Hope Not)

This week I finally achieved a DXCC milestone I have been chasing for several years. I finally got 275 countries confirmed in LoTW. When I reached 25o a few years ago, I figured that I would not go much higher. The station upgrades are paying off. I have been mostly focused on making SSB and CW contacts, but will certainly still work FT8 for ATNOs and band-slot fillers!

As all DXCC award chasers know, once you reach 200 the ATNOs become more difficult and less frequent. This makes each one more exciting and meaningful. With the current solar cycle on the decline, I don’t know whether I will reach 300 or higher, but I will certainly keep trying!

LoTW DXCC Credit Analyzer Updated

I have continued to work on this app. This was a labor of love, really, to help me in my pursuit of ATNOs and band/slots for DXCC awards and endorsements. I have shared it in several venues hoping that other hams with similar pursuits would find it helpful. I have also received some excellent feedback to add features and improvements.

LoTW DXCC Credit Analyzer