N6OL

November Six Oscar Lima

N6OL Powerline QRM Monitor 1.5.0 Now Available

August 7, 2026 /

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.

Built an NA6O Mag Loop Antenna

June 16, 2026 /

One of the struggles with RFI hunting using a Yagi antenna on UHF is that I’m monitoring noise on HF – typically on the 80 meter band.  The nature of powerline RFI, at least in my experience, is that the signal is stronger the lower you go in frequency, so there’s a lot more to receive on 80m than 70cm.  It’s not at all practical to walk around the neighborhood hunting QRM using an 80m Yagi of course, and a 70cm Yagi has the advantage of being an off-the-shelf product and very easy to carry.

I came across the NA6O RFI DF Loop Antenna which helps to solve both the low-frequency hunting problem and the size problem in one swoop.  This is a receive-only antenna using a tuned magnetic loop with an inner Faraday coupling loop.  Magnetic loop antennas, as I’ve learned, have a very deep, very narrow null in their reception pattern.   When you’re edge-on to the source, it’s at its greatest intensity, and when you’re flat across it (ie, looking through the loop), you’re in the extremely narrow null.  As you might guess, a very deep, very narrow null is perfect for direction finding.  You just turn the antenna until you hear basically nothing, and then you’re looking through the loop either at the source, or at something 180 degrees away from the source.  As always, you need more than one bearing to get a location.  It’s a little bit more complicated than using a Yagi, because 0 degrees and 180 degrees are equal in intensity, but the process of triangulation is very similar- you just need to be mindful that your source may lie anywhere in the direction your loop is facing, both in front of you and behind you.

I don’t have a very well-stocked junk box, so I sourced some stacked Polyvaricon variable capacitors on Amazon (no financial interest) for the tuning.  I did have a 220pF capacitor in my junk box, and I soldered one leg across the two stators, and the other leg to the rotor.  This gave me an effective range of about 280 – 820 pF.  By the chart in the NA6O doc, this should provide a tuning range of about 3 MHz to about 6 MHz, and that’s exactly what it does.  I also bought some cheap RG174 coax for the coupling loop, and used some AWG 16 primary wire that I already had in my junk box for the magnetic loop.

The form for the magnetic loop is a 12-inch bamboo embroidery hoop from Michaels.  Thought not strictly required, I found it made it easier to keep the magnetic loop neat and well aligned.

Other parts came from Home Depot: a 1-gang stainless steel outlet box with 1/2-inch knockouts and a blank steel cover, a bag of plastic cable push-through plugs, and a bag of aluminum knock-out plugs.   I used the push-through plugs as bushings for the mag loop wires and coax to enter the outlet box.  In one knock-out plug, I drilled a 3/8-inch hole with a stepper bit to hold the BNC connector.  This I plugged into the bottom knock-out.

I had quite a lot of trouble working with the RG174 coax getting it soldered into a nice N4SPP Faraday loop (type 3 from his docs).  The next time I work on the coupling loop (if I need to again) I’ll use the same RG316 used by NA6O.  I found that it was easier to solder the far end to the exposed shield on the near end of the loop by stripping back about half an inch of the outer jacket, also stripping almost half an inch of the inner dielectric, exposing the center conductor for almost the entire length, cutting back the braid to about a quarter inch long, and the first soldering the braid to the center conductor.  Then I soldered just the center conductor to the exposed shield on the near end of the loop.  This required much less heat and much less time to solder than trying to solder braid-to-braid, and works just as well.

I drilled out holes in the cover plate to accommodate the Polyvaricon and its screws, hooked everything up, attached it to the SWR meter and got … nothing.  After some troubleshooting, I found that I’d missed a connection between the resonant loop, Polyvaricon, and the chassis.  Though the document describes connecting the stator to the chassis, I found that in the case of the Polyvaricon I had, I needed to connect the rotor pin to the chassis; the rotor pin is the one that connects to the knob with my Polyvaricon, and otherwise any time the rotor got close enough to the cover plate, I’d lose all sensitivity from the build.  So pay attention to how the connections work on your tuning capacitor, you may need to pick either the stator or the rotor depending on the configuration.

(Speaking of which, there’s no pinout included with the Polyvaricons I got on Amazon, so if you use these, fold out all the pins, then find the side with 5 pins, one of which is in the center halfway up.  With the knob side on the top, the two pins on the top row are your stators, and the pin in the center is the rotor.  You can snip all the other pins.)

I was never able to get anything remotely close to the SWR described in the original document, but I strongly suspect this comes down to two things: coupling loop size, and the super cheap coax that I bought – it may not even be properly 50 ohms.  I do, however, get a nice sharp dip in SWR where the antenna is resonant, and it’s more than good enough for DF work.  Some day when I run out of other things to do, it may be fun to play with the coupling loop size to try to get a better match.

I also sourced a used, inexpensive, battery-operated shortwave radio, a Tecsun PL-330, and a pigtail to convert between BNC and the 3.5mm TS jack the Tecsun uses for an external antenna.  As an unexpected bonus, the Tecsun PL-330 also gives you a dBu reading of the received signal, which is really handy when direction finding.  You don’t need to rely solely on your ears.   I found that it still seems to use the built-in antenna when an external antenna is connected, which can confuse things when hunting, so I removed the screw holding the telescoping whip and removed the whip antenna entirely.

In the first field test of the antenna, I was able to quickly discern one of my “usual suspect” poles, and when turning the antenna null in the direction of the pole, the null was deep enough that I could hear WWV clearly on 5 MHz.  Being only a degree or two off was enough to bring the powerline buzz back.  I also found that because the intensity with some of these poles is so high, going up in frequency some to 5 MHz (rather than my monitor frequency of 3.540 MHz) helped avoid overloading the shortwave receiver — at 3.5 MHz, the signal is so strong that it even gets picked up with the null facing the source, maybe due to some diffraction, maybe just the internal wiring of the radio still receiving such a strong signal regardless of the antenna.

In any case, if you have the time, this is a great device to have in your arsenal for direction-finding powerline RFI.  I think the total cost of the project, excluding some tools I bought myself to make a few things easier, came up well under $50.

N6OL Powerline QRM Monitor Now Publicly Available

June 11, 2026 /

For the last two years, here at N6OL I’ve been running some custom powerline QRM monitoring software.  If you’ve read my old blog posts you’ve probably seen screen shots or references to the monitor or the charts it produces.

I’m pleased to say that with the help of Claude Code, I’ve finally had a chance to sit down and refactor the code into something less hackish, better organized, better documented, and generally possible for someone other than myself to be able to use.  (The original was kind of held together with duct tape and chewing gum, was all just one gigantic hacked-together single class monstrosity that sort of evolved over time into something that basically worked but was inelegant and below my standards.)

The project can be found at https://github.com/spatula75/n6ol-powerline-qrm-monitor

Setting it up requires some command-line work, configuration file editing, and familiarity with Python basics, all of which is covered in the README.md file.  So make sure you follow along in the README if you want to be successful.

And before anyone is tempted to say “HURRR DURRR VIBE CODING SLOP DERP DERP DERP” just don’t.  This code was primarily already written by hand, by me, starting back in 2024, and was originally expected to be just some throwaway script that I’d stop running as soon as PG&E finally fixed their crap.  I wasn’t expecting to still be here, two years later, with PG&E having done next-to-nothing to solve their FCC-regulation-violating behavior.  What Claude Code mostly did for me was a guided refactor into modules and classes, and then I got it to also write two small scripts to help with setup.  Other than that, the code is mostly original, human-produced code, with many hours of trial and error behind it.

The code has been tested and verified on a Windows environment, but conceptually should work on Linux, MacOS, and FreeBSD without much ado. You’re on your own if you want to use it in one of those environments, but I will gratefully accept PRs if you need to tweak something to get it working for one of those operating systems.  Just make sure you add tests where applicable so the code coverage doesn’t drop.

Video Evidence of PG&E’s Irresponsibility

April 30, 2026 /

I’ve been slow to post this update, because for a while, it looked like PG&E might actually have shown an interest in identifying the origin of the RFI that has plagued my neighborhood for the last two years, and I was cautiously optimistic that their intentions were honest and sincere. My optimism was misplaced.

What they were actually doing was making an effort to locate anything they could in my neighborhood that they could blame for the RFI, other than  their own equipment.  They settled on a cable TV amplifier.  I, of course, did my due diligence and pointed a Yagi at the amplifier in question, and while it is putting out a small amount of RFI, it manifests as a high-frequency sine wave, not as a 120-pulse-per-second buzz.

So I set out to do, again, what PG&E has failed to do for the last two years: I located the source for them.  This time, I recorded the entire noise hunt on video so the whole world can see just how easy it is to track down, and how there’s simply no way that PG&E’s inability to find this source could be attributed to simple incompetence.  A child could find a noise source this obvious.  PG&E has much nicer equipment at their disposal than I do.  They could easily find this problem if they wanted to.

Here’s the entire noise hunt, captured on video, for the whole world to see.  This is what PG&E won’t do.  Not out of incompetence- incompetence cannot explain this behavior.  You’d need to be actively trying not to find this noise in order not to find it.

It’s been said both “don’t ascribe to malice that which can be explained with incompetence” and “any sufficiently advanced form of incompetence is indiscernible from malice.”  I propose another adage: any sufficiently advanced form of malice need not be explained by incompetence.

Enjoy:

March 27, 2026 /

No, really, it is you:

Apologies for the rough nature of the video. I plan to make up something a lot nicer aimed at a wider audience. I just put this together over the last couple days to demonstrate, again, where this noise is coming from (I’ve performed this same triangulation many, many times over the last few years.)

In an effort to better track the noise, back in 2024 I wrote some custom monitoring software which cross-correlates the audio from 3.540 MHz with 120pps noise and charts it relative to the noise floor once per minute, 24×7.

The video begins on the evening of March 26, 2026, when the monitoring chart showed a strong 120pps noise. I then set out to a nearby trail with a clear view of the substation with my 70cm Yagi and HT set to 440 MHz, AM mode. I chose two locations near the creek and recorded myself looking for the strongest “buzz” from the HT. I tried to find the strongest buzz from each of these two locations, and did a circle to verify that the signal was not actually coming from behind me or from a side lobe. (Hopefully nobody gets dizzy watching that part.)

It’s not enough to only look when there’s known to be an active noise source, however. It’s also necessary to check that when the monitor is showing no noise that observation with the directional antenna also shows no noise. So early this morning, while the chart showed no noise had started up yet, I set out again, and this is the final location clip in the video. I didn’t bother checking both locations, because there was no noise received (so there’d be nothing to triangulate).

PG&E has been playing games in recent weeks, specifically Occam’s Knife Game, in which they’re stabbing around, trying to blame everything they can possibly dream up except the obvious, glaring answer, which is the same answer it has been for the last two years.  It’s not somebody’s solar panels down the street (it happens at night too).  It’s not spurious emissions from a cable TV amplifier (the wrong kind of noise entirely).  It’s exactly what it appears to be at face value, and exactly the source that PG&E’s own technicians found in March of 2025.  Everyone can see it with their own eyes.

Pacific Gaslighting

March 26, 2026 /

I’ve found that when someone tries to convince you that something is anything except what it appears to be at face value, they’re gaslighting you.  Or as I sometimes call it, “Occam’s Knife Game” in which the player stabs around at every possible explanation except the simplest one, and in so doing reveals that they know what that explanation really is — it’s the one they’re avoiding.

In our latest episode, PG&E actually put forth some minimal effort for a change and sent some techs out to go noise hunting.  Note that we’ve been down this road before, and they affirmatively located a noise source within the Poplar Street substation.  This time their motivation in signal hunting appears to me not to have been for the purposes of actually locating the source of their noise, but rather to find something — anything — else they can blame the interference on.

From their hunting efforts, PG&E believed they’d found the “real” culprit, a cable TV service amplifier giving off spurious emissions on 30 MHz, and I was asked to see if I could confirm whether this was the same noise I was hearing at my station.  There are a few problems here already: I’m not monitoring or trying to use 30 MHz — that’s not even in an Amateur Radio band — and the type of noise I’m receiving is not the kind you’d normally expect to hear from a switching power supply or from spurious emissions from a cable TV amplifier.  I am receiving, and specifically monitoring for, 120 pulse-per-second arc noise, the kind of noise you’d get if the two peaks of a 60 Hz current were arcing to a ground wire or grounded object.  (My monitoring software watches 3.540 MHz and specifically cross-correlates the time-domain signal looking for a 120pps noise.  It will not easily identify other types of signals that don’t match this pattern.)

So I went out, again tonight, this time looking for this cable amplifier.  I was not able to locate it where PG&E asserted it could be found.  I did detect a “birdie” signal in the general vicinity of its supposed location at about 2300 Hz, but again, this is not the noise that’s causing interference at my station and not the noise I’m monitoring.

But while I was out hunting for this mysterious cable box, I did find a utility pole making a hellacious, buzzing racket.  I hadn’t noted this before, but it’s immediately next door to the pole that I reported back in 2024 (and which PG&E actually fixed a few months later).

Then I went to stand in the middle of the street with the cable box’s alleged location to my left and the substation in front of me, 90 degrees to each other.  If the true source of the trouble was the cable box, this would be a perfect location to tell whether the noise was coming from in front of me, or to my left, a vantage point not available from my station location, where the alleged cable box would have been more or less behind me with the substation in front of me.

And guess what: no noise to the left, plenty of noise to my front (and lots of noise to 45 degrees from the aforementioned pole).  Shocking.  Interestingly, the noise I pick up on 220 MHz is more of a very strong “white noise” type of emission now, not so much a buzzing.  More on that later.

For the sake of completeness, I then headed out to the Bay Trail and north to the Poplar Creek pump station.  This is as close as someone can get to the PG&E Poplar Substation while remaining on public land.  I’ve been here before, many times, for the same reason: to reconfirm that I’m not crazy, and that the substation is really where the signal is coming from.  You can probably guess the rest: yep, there’s a strong emission coming from the substation on 220 MHz.  Exactly where I’ve been finding it for the last two years and exactly where I’m likely to find it again tomorrow, and next week, and at this rate, in another two years.  Here I did pick up some buzz along with the white noise.

Much like my effort at the first location, here, too I found another utility pole producing a massive amount of RFI, this time one adjacent to Poplar Creek.  There are actually two poles on opposite sides of the creek here, and because of thick vegetation and this area being known to harbor rattlesnakes, I opted not to get sufficiently close to differentiate the poles at this time.  I had detected some intermittent noise from this pole in the past, but nothing like what I heard tonight.  I suspect that like much of PG&E’s aging infrastructure, this and the other pole I found tonight have just been degrading over time, and until they actually cause an emergency situation, PG&E is happy to simply ignore any maintenance.

I’ve captured my 220 MHz direction-finding and some audio recordings of the noise I observed on an annotated Google Map.  Here’s a preview:

Map showing the locations of two RFI-noisy power poles and multiple observation points and the directions from which noise could be observed from those points.

Gee, where could that 220 MHz emission be coming from?

To be completely scientific about it, I need to take another set of directional readings outside when there isn’t any notable interference, to prove a correlation (which I have also done before, but I’ll do it again for completeness).  The RFI has been extensive and nonstop the entire day today, however, and even as I write this after 9 PM PDT, the noise is still S9+6.  It will be necessary to get up quite early one morning, or to get lucky in the middle of the day for another set of observations.

The following morning, before the noise had started up yet, I ventured out again with my 220 MHz Yagi and, plot twist: there’s still a strong “white noise” emission coming from the substation.  It would seem likely that this emission is not the same emission as the 120 pps emission plaguing 80 meters in my neighborhood, but is in fact something else entirely.  I checked again with my 440 MHz Yagi and did not detect the same “white noise” emission, which suggests that whatever is producing this particular emission is more localized to the 1.25m band, or the 1.25m band is a harmonic of the band in which this noise originates.  (This is why when we do a science, we need a control: it’s not enough to just measure when things are happening- we need to compare with measurements when things are not happening too.)

I’m less concerned about whatever is producing spurious emissions on 220 MHz, as I’m not active on this band, however this noise still doesn’t belong there (and it wouldn’t shock me if it is somehow related to a coworker consistently getting dropped calls on his phone when he runs by the substation).

To better differentiate between this emission of lesser concern, and the emission I’m actually looking for, I’ll be taking future measurements with my 440 MHz Yagi.

In their effort to try to convince me that the problem is everything except PG&E, what they’ve actually done is gotten is my finding found two very loud additional sources that weren’t consistently loud before.

As best as I can tell, something is still producing electrical-arc noise, and it’s not, as far as I can tell, a mysterious cable amplifier box that I’m unable to locate.

PG&E has now been dodging this problem for a few months shy of two years.

More PG&E News

June 21, 2025 /

Despite their assurances they’d keep me in the loop regarding progress isolating interference at the substation, the most recent update I heard from PG&E came via the ARRL, but at least it’s something:

Previously the investigation connected the interference to the substation. Subsequent inspection has been conducted which pinpointed the substation equipment involved. A detailed inspection of the identified equipment is underway to determine a course of correction and next steps.

So now they know they ARE creating interference, and they know precisely WHAT is causing the interference.  All they have to do now is fix it.

It’s worth noting again that I gave them a fairly precise location over a year ago, and then the spent a year gaslighting me about it, misdirecting my trouble ticket, and generally refusing to do anything until I sent a letter to the CEO and woke them up about it.

It should not be this difficult to get a utility to meet its legal and safety obligations.

The problem remains unfixed, of course, but at least it’s some nominal progress.

Finally, a Real Update from PG&E

May 18, 2025 /

Though there’s still no damned excuse for PG&E taking more than ten months to send someone out to investigate the noise source at the PG&E Poplar substation near my QTH, I did get a call last week after my second letter to PG&E’s CEO and my case being escalated to a supervisor in the customer call center, who then raised the issue with a handful of other supervisors.  It shouldn’t be this hard to get someone to react at a public utility, but at least they finally did.

It turned out there had been some activity at the substation in an effort to resolve the problem between March 31 when the source of the trouble was confirmed, and when I finally got a call from someone who knew what was going on.  Evidently PG&E has a fairly terrible communications problem when it comes to information moving between the people who actually work on the issue and the customer-facing call center and ticket tracking system.

The trouble has been isolated to the vicinity of a 230kV bus at the substation, though in the intervening weeks they’ve also power washed and cleaned up some 115kV systems.  Evidently the trouble is that they cannot simply power-wash around the 230kV bus; to do so would risk a catastrophic arc flashover because of the sheer potential difference involved.  (230kV is a LOT of electrical potential.)  From the explanation I was given, it sounds like PG&E does not have a redundant system for this 230kV bus either.  They can’t work on it without shutting it down, and they also can’t just shut it down to work on it– to do so would shut down power at the substation for everyone it serves.

Given the lack of redundancy, I asked how they do routine maintenance on this system just in general, and the answer could be summarized as “rarely, and at considerable expense.”  The systems themselves are designed to have a very long MTBF, but on the occasions that they do need to shut them down, they have to plan it out months in advance, bring in a mobile unit of some kind (presumably either power generation or a busbar on a flatbed maybe?) to keep things working while the 230kV system is shut down for maintenance.  This apparently happens only once every 4-5 years and can be a multi-million-dollar operation.

That said, all hope is not lost: they’re trying to book their infrared team to come out and image the system while it is under load to see if they can spot any “hot spots” which might be addressable without something as inelegant as a power-wash, and they’re also looking to work with their high-tech services team to see if there are other ways they might suppress the RFI and keep it from being a nuisance in our neighborhood.

But lets be very clear about one thing: what PG&E is doing at the substation, though it may be very inconvenient to fix, is still a violation of FCC rules.  And it doesn’t matter if it inconveniences a handful of Ham Radio operators, shortwave listeners, AM broadcast enthusiasts, or a thousand people’s cell phones; the rules are the rules and they don’t distinguish by how many people are affected or how troublesome it may be to correct the root cause.  (That said, I do believe I’ve observed a correlation between noise emanating from the substation and reduced signal quality of KRCB-DT on ATSC channel 5, but I need more data to confirm it.)

The PG&E supervisor promised to keep me better informed going forward as they continue to work on the problem, which is a very different attitude than what I got from the rest of the company between May 16, 2024 and May 16, 2025 (it was in fact one full year to the day between my opening of a case about the substation and receiving a call from a supervisor on Friday).

That’s what I know for now.  More to come, I hope.

Real-World Example of PG&E / Electrical Utility RFI

May 15, 2025 /

In case you ever wondered what PG&E’s (or really an utility company’s) electrical arc noise sounds like on an actual radio, here’s a short video in which you can hear how that awful 120 pulse-per-second racket actually manifests in a real-world scenario:

I start out tuned to 3.560 MHz, which happens to be about where my 80/40/30/20m fan dipole antenna is resonant on 80m.  I’m using AM mode at the request of the folks at the ARRL for the purpose of documentation. Though this would normally be a lower-sideband segment of the band, it helps to hear the noise over the background static to decode as AM.

Toward the end of the video, I tune to WWV on 15 MHz, which is a bit above where my 20m antenna is resonant, so the reception isn’t quite as good.  When PG&E is not partying like it’s 1899 with their unintentional spark-gap transmitter, WWV is still clearly audible…  not so much when they are producing this RFI though.

It’s worth noting that this broadband noise doesn’t affect only the amateur radio spectrum.  I’ve charted it as low as 1600 kHz (AM Broadcast band) and all the way up to 450 MHz (UHF) and everywhere in between.  There’s a reason spark-gap transmitters are forbidden by international treaty, and this is it: electrical arcs produce tremendously wide signals and horrific broadband noise.  This noise affects AM and FM commercial broadcasts, Shortwave radio, government and public safety, VHF and UHF television, and even cellular phones.

My Letter to the FCC Regarding ATSC 3.0 and the Sunsetting of ATSC 1.0

May 4, 2025 /

It’s far from the most elegant thing I’ve ever written, but I think it gets my main points across reasonably well.  The due date for public comment is coming up on May 7!  If you want to leave a public comment:

While I sympathize with content providers’ desire to mitigate copyright infringement, I strongly disagree with their behavior thusfar when it comes to DRM-encrypted ATSC 3.0 broadcasts. The A3SA and NAB appear to be taking advantage of this crossroads in technology to reverse the status quo which has been in place since the advent of the VCR and the decision in Sony Corp. of America v. Universal City Studios, Inc., 464 U.S. 417 (1984), and in the process they’re reducing the utility of broadcast television as a public service over the public airwaves.

As it stands today, despite many channels in the San Francisco Bay Area broadcasting from the ATSC 3.0 “lighthouse” on ATSC channel 7, I cannot tune most of these channels at all– DRM has been taken to its logical conclusion and the content cannot be received, despite my receiver being ATSC 3.0 capable. The reason? I, like countless other consumers, use a home-networked tuner, and the A3SA has failed to work with manufacturers of network tuners to ensure that they can receive their DRM-protected content.

So not only can I not record broadcasts for time-shifted viewing, like I’ve been able to do since the 1980’s, I can’t even watch them live via the more-reliable ATSC 3.0 signal.

The courts have already ruled that time shifting for one’s personal viewing qualifies as “fair use” and now the NAB & A3SA are trying to use new technologies to eliminate fair use for their own benefit with no regard for the viewing public, who own the airwaves.

Many claims have been made about the necessity of DRM-protecting these signals, and yet, the recording of live television, both on analog and digital media, has been a common practice for more than 40 years. What’s changed is an opportunity arising for content providers to wrestle back control from the viewing public. But in placing so many restrictions on protected content, they’ve rendered their own broadcasts unviewable by a large percentage of the public.

I have additional concerns about their plans to disseminate encryption keys over the Internet. There are many reasonable privacy concerns for why consumers may not wish to have their televisions or tuners connected to the Internet 24×7 or even temporarily to retrieve an encryption key (which reveals the intent of the requester to watch a particular stream); moreover, in the face of an Internet outage, this could render it impossible for consumers to watch television at all. In an emergency situation, where broadcast television might be the only way for the public to be informed, for example in the face of a natural disaster, terrorist attack, or regional power disruption, losing the ability to decrypt an encrypted signal could expose consumers to unnecessary risk of harm or loss of life.

Lastly, on a technical note, the methodology for streaming ATSC 3.0 video causes it to take several seconds to either tune a channel or to recover in the event of transient interference. The strange choice of ISOBMFF fMP4, a reliable delivery and storage format, over MPEG-TS, an unreliable delivery streaming format, means that synchronization can take several seconds in the event of even transient interference and upon every channel change, leading to a very poor user experience, especially for those living in areas of challenging reception conditions (as we do, living less than 5 miles from a major airport).

These decisions taken in aggregate give the impression that A3SA and NAB are entirely concerned about protecting their own interests and not at all concerned about serving the public over the public airwaves. To sunset ATSC 1.0 without addressing issues which affect the viewing public in ways unseen before in broadcast history would do them a great disservice.

« Older posts

© 2026 N6OL

Theme by Anders Noren — Up ↑