The N6OL Powerline QRM Monitor has certainly been learning some new tricks of late. I started this project back in 2024 when I first started dealing with QRM produced by our electrical utility, PG&E, in the hope that if I could find some pattern to when the intermittent noise was present, it might help their techs know when to look, and by extension, help me to be rid of this QRM. I certainly didn’t suspect at the time that I would still be dealing with this more than two years later.
In its original incarnation, the monitor ran completely headless, woke up once per minute, read some noise off the sound card, ran a cross-correlation analysis against the noise, estimated the intensity of the noise, the noise floor, grabbed some weather data off my personal weather station, and then updated a CSV log file and a set of graphical charts on my web site. It ran this way for two years. I have mountains of data!
This year, after being cajoled by a coworker and fellow ham into volunteering to give a talk at Pacificon 2026, I thought it might be nice to clean up the monitor code, make the code less embarrassing (it was originally meant to be a hack that I figured I’d throw away in a few months), and enable other people to get some use out of it.
I’m pleased to say that not only can others get some use out of it now, I am starting to get some fun and exciting new uses out of it as well.
For new users, there is now a setup program to create your Python virtual environment, download all your dependencies, and get the basics configured: audio device, level calibration, call sign, weather source, publishing location, etc. This saves a lot of time and potential for error and just makes it easier to get started. I’m also working on some written guides to help walk people through what the different options mean and why they’re there.
The code has been considerably refactored to have a continuous audio pipeline with a ring buffer, which feeds both an analysis pipeline, continuous waterfall, and oscilloscope simulation when not running in headless mode. Because the audio pipeline is now continuous, and the signal we’re looking for is so predictable and periodic in nature, a lot of that expensive cross-correlation can be avoided; instead, the analysis pipeline looks a little to the left and a little to the right of where the peaks are predicted to be to see if there’s a better match in one direction or another, indicative of the phase slipping a little. Phase slippage can be tracked over time to estimate a frequency slip, and one fascinating consequence of this is that the frequency of our utility power can in fact be estimated by the QRM that the utility is producing! That is now shown on-screen as well. I was surprised to see just how much our utility power dances around, quite often between 59.99 and 60.01 Hz, but sometimes with even larger deviations.
Another valuable new feature is highly configurable auto-recording. You can specify a minimum duration and a minimum dB threshold before recording starts, so you can avoid recording transient bursts. You can also specify a maximum recording duration so your clips don’t last forever. Additionally, if you don’t care to record every event, you can set a per-time-period (configurable) budget for how many recordings you want to make. Then the monitor automatically produces .wav files in the directory you specify.
By far my favorite new feature is the ability to take a recorded .wav file and to render it directly to an mp4 file, as I’ve done with the file shown at the top of this post. If you should ever need to show someone the real proof that you’re experiencing powerline QRM, this produces a valuable visual aid.
The next step is producing a lot of human-written, human-consumable documentation for everyone who isn’t me. Though I’ve found Claude Code invaluable for producing tedious, boilerplate code that I would otherwise have to type out by hand, I find that the documentation it produces is rubbish, and this requires the finesse of a real human being who knows what to say and how to say it, rather than a large language model producing a giant wall of slop-text. Stay tuned for that; I hope to have it ready well before Pacificon, but it will be a little bit slower to produce because I’m writing it by hand.