Building and Hacking – 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.

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

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

I Vibe-Coded a Web App!

LoTW DXCC Credit Analyzer

I’ve been reading a lot about vibe-coding, and thought I would give it a try. I have been off-and-on trying to learn Python. Maybe someday I will get it.

I have always wanted an app that would perform analysis of the DXCC Award Credit Matrix from Logbook of the World. There is no option to download the table as a spreadsheet. So, I thought I would try to cook something up myself using AI coding.

I used Lovable, which is an AI-powered, no-code app builder designed to create web applications and websites from simple text prompts. It enables users to rapidly build functional, production-ready apps—such as project management tools, calculators, or landing pages—by generating code and UI through conversational AI.

I create a web app called “LoTW DXCC Credit Analyzer” for DXCC entity, band-slot and mode analysis. The analysis does not include deleted entities. Also, I could not completely automate the process because of the way LoTW displays the DXCC Award Credit Table (no option to download the table as a spreadsheet or CSV file). I included instructions in the app for creating a spreadsheet from LoTW’s DXCC Award Credit Table, which can then be loaded into the app. Feel free to give it a try!

Learning About Meshtastic

At Orlando HamCation, I ran across the booth for Spec5. They sell some very cool Meshtastic devices. I briefly experimented with Meshtastic a couple of years ago, but it had not really taken off in my area, so I didn’t get very far. More recently, several people in the area have installed nodes, so it is more interesting and useful now. In fact, there is a group working to install nodes to connect communities across the region. This will make Meshtastic more useful as an option for grid-down communication.

One of the devices I bought at HamCation is the Spec5 Ranger. It is a cool Meshtastic device with a keyboard, so messages can be sent directly through the device. You do need a phone, tablet or computer to configure it initially, but once it is set up it can be used alone.

I had this homebuilt Meshtastic device from my earlier experimentation, so I flashed it with the most recent firmware and configured it with my phone. This one does require a bluetooth connection to a phone or tablet to send messages. It is a LILYGO T-Beam ESP32 LoRa board with OLED display and 18650 battery.

I knew I would have limited range with the handheld devices and small 915 MHz antennas, so I wanted something that could extend the range. I ended up getting another Spec5 device, the Spec5 Relay to set up outside. It was very easy to assemble, and also easy to configure using the Meshtastic application on my phone. I have it mounted on a 15 foot mast at the edge of my property. It transmits and receives over a greater distance due to the better antenna, and placement outside. It has a solar panel to keep the 18650 batteries charged. I will be putting it on a 25 foot mast soon to extend the range even further. While the Relay can be set up in a repeater mode, I have it set up in client mode, which is the best setting for this location.

This is a screenshot from the Meshtastic Android app on my Google Pixel phone It is connected to my S5 Ranger by bluetooth. This is a view of all of the different configuration settings.

This is a view of the most recently connected nodes that my device can see. You can see my other two device on there (they are very close), but through the S5 Relay it is connected to several other nodes that are further away.

This is the map view from the Meshtastic application, showing several nodes that my S5 has seen from my house and while traveling around the area.

This view shows messages that have been received by and sent from my nodes.

I have one of my nodes connected to an old iPhone. The iPhone Meshtastic app seems to be functionally the same as the Android app, but it looks different.

So, what’s next. I will continue to learn more about the functions and utility of Meshtastic, and will try to help local users extend the mesh to reach more communities.

LoRA 433 MHz APRS iGate and Tracker

It has been a year since I posted a new item! Time to get back to it! My last post was about a project for my IC-705 using an M5Stack microcontroller. I became interested in learning about other ham radio related projects using microcontrollers.

Searching online, I found two related projects to build an APRS iGate and a tracker. Both of these projects use inexpensive LoRa32 microcontroller boards. I chose TTGO T-Beam v1.1 boards that operate on 433 MHz. Make sure you buy the 433 MHz version of the board for the APRS projects. The board includes a small OLED screen, and has onboard WiFi, GPS and SMA connector for the antenna. You will probably have to solder the OLED screen to the board, but there are only four pins to solder.

On the back of the board, there is a battery holder for an 18650 3.7 V lithium ion battery to power the board. The board can also be powered through the microUSB port, which also recharges the battery. There are other similar LoRa32 boards that you can use for these projects, and they are readily available on Amazon, eBay, and other online retailers.

Front and back of TTGO T-Beam v1.1 ESP32 433MHz LoRa32 board

Programming the board is fairly easy. The iGate and tracker project pages on GitHub include links to quick start guides. The quick start guides are in German and French, but you can right-click in Chrome and choose “Translate to English”. Even better, there is an excellent video by Tech Minds on YouTube that will take you step-by-step through the process of configuring and programming the iGate and tracker modules using Visual Studio Code with the PlatformIO plugin. This process will load the firmware onto the module, as well as a json configuration file that includes your callsign, wifi info (for the iGate), etc. I highly recommend viewing the Tech Minds video before you start these projects!

Lora APRS iGate json configuration file in Visual Studio Code

After programming the iGate and tracker, I was ready to test! I missed a step in my initial configuration of the iGate, so it did not connect to my home wifi on the first attempt. Once that was fixed, it connected to the internate and I was able to see the LoRa iGate symbol for my ssid N4MI-10 appear on the aprs.fi live APRS map. The iGate is operating on 433.775 MHz.

OLED screen showing LoRa APRS iGate configuration

N4MI-10 LoRa APRS iGate, operating on 433.775 MHz, displayed on aprs.fi

Once the iGate was operational, it was time to test the tracker. I chose N4MI-1 as the ssid for testing the tracker. I have some other APRS capable radios, so I will have to come up with a plan for assigning a ssid for each of them. The tracker powered up and initialized. Once it acquired enough satellites for a fix, I saw it transmit the first beacon, which was immediately picked up by the iGate. Awesome!

You can configure the tracker for smart beaconing in the json configuration file. You can also manually transmit a beacon using the middle button on the LoRa module.

OLED screen on LoRa 433 MHz APRS tracker

I took the tracker out for a short walk, and transmitted a beacon from several locations, all of which were received by the iGate and displayed on aprs.fi.

Positions from N4MI-1 LoRa 433 MHz APRS tracker displayed on aprs.fi

The transmitter in the LoRa board is very low power, about 200 mW, so the range with the small SMA antenna is limited. The range can be extended by using a better antenna at a higher elevation. Additionally, a small RF amplifier could be used to increase the power.

This was a very fun and relatively easy project. I am planning to attach a 70cm antenna at a higher elevation to the iGate in case other hams in this area would like to build and use LoRa 433 MHz APRS trackers.

M5Stack Remote Multimeter & iPad SDR-Control App with IC-705

The Icom IC-705 is an amazing QRP transceiver with lots of advanced features. Those features include built-in Bluetooth and wireless LAN, creating opportunity for display and control the IC-705 remotely. Some excellent free software recently became available to take advantage of the Bluetooth capability for a remote display using an inexpensive IoT development board. Also, an incredible iPad app was recently released that allows full remote display and control of the IC-705 via WiFi or LAN.

Remote S Meter and MultiMeter Projects with M5Stack

There are two very easy projects using code available on GitHub and an inexpensive M5Stack Core Development Kit: one to create a remote S Meter and another to create a more advanced and very useful remote MultiMeter.

The M5Stack is an ESP32 development system for IoT applications. This extremely powerful yet low-cost chip includes Wi-Fi and Bluetooth and has quickly become popular over the past year or so. The M5Stack Core Devel o pment Kit is currently available on Amazon for about $50.

The first project I completed using the M5Stack was the IC705SMeter, created by Armel, F4HWN. Once the code is installed and the M5Stack is connected by Bluetooth to the IC-705, it has a selectable display of the received signal strength, output power, and SWR. It also displays the current frequency, mode and filter. It was very easy to install the software and connect to the IC-705 by following step by step instructions in a YouTube video by Ham Radio Dude.

Remote S-Meter connected to IC-705 via Bluetooth

There is also another more advanced remote meter project, also created by Armel, called the ICMultiMeter. This project allows you to display the equivalent of the meter screen of the IC-705 on the M5Stack screen, which allows you to dedicate the IC-705’s screen to the waterfall while seeing all the signal measurements simultaneously on the M5Stack screen. The installation process is very similar to the S Meter project. A YouTube video by Tech Minds has easy-to-follow instructions to build and install the remote MultiMeter.

IC MultiMeter connected to the IC-705 via Bluetooth

SDR Control Software for iPad

Having a remote meter is wonderful, but what if you’d like to have a full remote display and control of the IC-705? An application recently released for iPad will do just that. SDR-Control for Icom, available on the App Store, allows remote operation of the IC-705 without additional hardware or software. The app costs $50, but has tons of features, to include an integrated logbook, CW keyer and FT8/FT4 tool. An important caveat is that the IC-705 and iPad must be connected to the same WiFi network. The app will also control IC-7610 and IC-9700 transceivers connected to the same network via LAN. A YouTube video by Tech Minds provides an excellent overview of the SDR-Control app.

Once installed on the iPad, the app includes an integrated instruction manual explaining all of the functions, to include connecting the app to the IC-705. There is also an online version of the instruction manual. Following the instructions in the manual, I was able to connect to the IC-705 in just a few minutes. I found the app to be very easy to understand and use. When using the integrated FT8/FT4 tool, I did have to consult the manual to adjust the signal levels. Once that was done, it worked very well. The FT8/FT4 tool does not have all of the functionality of WSJT-X (no DXpedition mode), but it works well for casual operating. So far I have only used the app with the IC-705. I don’t yet have my IC-7610 or IC-9700 connected to my home network, but I plan to do that soon so that I can control the transceivers from anywhere in the house.

SDR-Control app connected to the IC-705 via WiFi

I made several FT8 contacts using the integrated FT8/FT4 functions in the app

Waterfall screen on the SDR-Control app showing stations sending FT8 signals

Veritium HFClock 9 (aka HamClock)

I purchased a Veritium HFClock as an impulse buy when I saw it on sale in an email from Gigaparts. I tried to build a HamClock using a Raspberry Pi and 7″ touchscreen, but I could never quite get it to work correctly. The Veritium HFClock is far more expensive, but it has a 9″ touchscreen in an attractive hardwood frame, and was easy to configure right out of the box. It’s definitely an attractive and informative station accessory. I may try again to build a HFClock with a Raspberry Pi someday.

Installed New 6M and 2M/70cm Antennas

From the time I became licensed, just a little over 5 years ago, I have been using a trusty Diamond X50A antenna mounted on one 5-foot galvanized steel mast on an eave mount, putting the antenna about 4 feet above the roofline. The apex of the roof is approximately 30 feet from the ground. This antenna has served me very well, and with it I could reliably hit most of the repeaters in the area, as well as work stations on simplex up to about 15 miles away. Last year, I added a Cushcraft AR-6 Ringo for 6 meters. When there is a 6M opening, this antenna works OK and I worked quite a few distant stations (see previous posts under the category 6 Meters). However, because of the vertical polarization, I had difficulty working some stations in nearby grids who have horizontally polarized antennas. Also, the Ringo would frequently detune for mysterious reasons. Even though it was mounted on a telescoping mast, it became tiresome to frequently lower and retune it.

When my friend Rusty inquired about renting a 50-foot articulating boom lift to do some antenna work at his house, I thought now might be a good time to upgrade both antennas. I got a Diamond X300A for 2M/70cm, and a M2 HO Loop for 6M. I also got some new 5-foot galvanized masts and 55-feet of new RG-213 coax. My ham friends came over this morning to remove the existing antennas and install the two new antennas. Special thanks to KG4HIR Rusty, KG4HIQ Earl, W4EFS Walter, and KK4ZHT Eric for working all day on this project in the heat and humidity! Eric and Walter did all of the work in the bucket, and Rusty and Earl did the majority of assembly and adjustment of the antennas on the ground.

For this installation, we used three sections of 5-foot galvanized mast (for a total of 15 feet). Approximately 2 feet of the first section sits below the roof apex in the bottom of the eave mount, so about 13 feet of mast is above the rooftop. The X300A, which is a 10-foot antenna, is mounted on top, and the 6M horizontal loop is mounted about 5 feet below that. We used the existing LMR400 coax for 2M/70cm, and the new RG-213 coax for 6M. We tested the SWR and impedance on both antennas on temporary masts at about 15 feet above ground, and both antennas had great readings as assembled – no need for adjustments. I thought we might have to adjust the 6M antenna once it was in place above the roof, but the SWR stayed about the same at 1.2:1.

Eric and Walter preparing to remove the existing Diamond X50A and mast from the eave mount. You can also see the 6M Ringo vertical on the left side of this picture.

The X50A and the old mast have been removed. Installing the first new mast section into the eave mount.

Both new antennas were assembled and mounted to two mast sections on the ground. Eric and Walter preparing to place the two mast sections with the new antennas into the first mast section.

All three masts and the two antennas are in place. Walter and Eric are adjusting and tightening all of the mounting hardware.

Looking up from the roof at the shiny new antennas.

With the lift bucket extended, Eric took some photos that give an “antenna-eye” view from the rooftop.

Since we already had the lift, I took advantage of the opportunity to place a couple of ropes and pulleys for future use. The first about 40-45 feet up in a hickory tree, and the other on an old utility pole beside the driveway.

Installing a pulley and rope on a tall hickory tree in my yard.

Removing some old wires and installing a rope and pulley at the top of this utility beside my driveway.

We had to take a short break for rain and thunderstorms. (The new antennas survived their first thunderstorm.) Even though there were a few adjustments made along the way, overall the project went as planned and was successful. Unfortunately, we did not have the same luck earlier in the day at Rusty’s house, because we could not get the lift into a position where the bucket would reach his antenna mast. I sure wish that had gone better.

I have not yet had a chance to fully test the performance of the new antennas. The new 2M/70cm has higher gain and is mounted 10 feet higher than the previous antenna. The 6M HO Loop is very narrow-band, but the SWR is nearly perfect at 50.3 MHz, so it will be great for digital and CW work. I did tune to 50.313 MHz and could hear and decode lots of FT8 from stations participating in the ARRL June VHF Contest. I’ll make some additional posts with my observations about the performance as I operate more with these antennas.