ChrisSmolinski

A few suggestions, you may have already tried some of them, but here goes... (I assume you have one of those integrated routers/modems)

Disconnect the coax cable and ethernet cables from the cable company router/modem, unplug the power supply from the AC, make sure the RFI completely goes away, this may sound redundant, but double checking this is really the problem.

Plug the AC power supply into the wall, but leave it disconnected from the router/modem. Does the RFI re-appear? Is it the same as before? This checks just the PSU for RFI issues.

Plug the PSU into the router/modem, leave other cables disconnected. What's the RFI like?

Plug in the coax cable for the router/modem. Again... what's the RFI like?

Start plugging in ethernet cables (not sure how many computers you have connected). Maybe plug in just one end at a time, first the router end, then the computer end. Note RFI levels. Repeat for any additional cables.

The point of all this step by step stuff is to figure out what is producing the RFI and (maybe) how it is radiating.

It is quite possible there is not one step that produces the RFI problems you see, but it is the summation of multiple sources/problems, this lets you figure out what is what.

At some point in these steps, you may even want to try something as silly as wrapping the PSU and/or modem in a giant sheet of aluminum foil (possibly connected to ground say via a piece of wire with alligator clips). Not permanently of course, but as a test. If that solves the issue, the you can think of a creative way to do that permanently while still providing enough ventilation, etc.

You can also try grounding various parts of the equipment, such as the router. And also try using shielded ethernet cables, but that only works if the stuff you're plugging the cables into actually has metallic ports. Lots of cheap stuff is all plastic, so there's nothing for the shield to connect to, it just floats, and is useless. If it's at least grounded on one end, that may help.

Another suggestion... you (generally) do not need to use the cable company's garbage (there are lots of reasons why you SHOULD NOT, beyond RFI). I use my own modem and my own routers. You may want to do the same. It's probably cheaper to buy them yourself than trying to fix an RFI issue with lots of expensive ferrite and other stuff. Plus you won't be paying a monthly rental fee for their junky equipment that is full of security risks

I second the multipath suggestion, when I had the hockey puck antenna in the shack, I found moving it by an inch produced substantial differences in GPS performance. With three cats, this was a problem.

I finally got a "Lucent GPS 40dB High Gain Timing Antenna" from ebay for $46 and mounted it outside and never looked back. 11 or 12 satellites all the time now.

It's quite difficult to come up with an automated way to measure SDR performance. Been there, got the t-shirt

I looked at the characteristics of known "good" KiwiSDRs vs "bad" ones. And wow, there are a lot of bad ones. Good SDRs have a few strong bins, and lots of low noise bins. Bad SDRs have a lot of high noise bins. This is one of those cases where you can look at the histogram plot and immediately determine if an SDR is good or bad, but it's tricker to do it in code. It boils down to distinguishing signal from noise.

It was a few months ago that I wrote my code, so I would have to look over it again to remember all the details. Basically I built a histogram of signal levels over the spectrum, and find the amplitude of the 98th percentile bin. Then I find which bin is equal to 0.4 of that value. I call that the quality factor. Larger is better. These numbers were all empirically derived of course, not based on any theory. Just what seems to work. As with all things software, it could certainly be improved, I got it to the "good enough" stage. I mostly use it to test my own setup and various antennas, and a few others privately use it to evaluate their own KiwiSDR.

This is what a "good" one looks like:




And a bad one (some are even worse than this, this one is still bad enough to be effectively unusable IMHO):



A smarter improvement might be to look at the frequency when examining the signal level to decide if it is real or noise. High signal levels are OK in the MW and SWBC bands. Maybe the ham bands Not good if all over the spectrum. Of course the time of day is going to affect what signal levels you expect on a given band. And of course the antenna type which may favor certain bands. And.... See, it's complicated

I released a new version of my python KiwiSDR sound client. This update adds an --echo option to also echo the sound to the default sound output device, in addition to the specified sound device.

Based on the kiwiclient python script, this script will connect to a local or remote KiwiSDR, and stream the audio to a virtual audio device on your computer in real time, so you can route it to a decoding program, such as for SSTV, FAX, RTTY, and so on.

Downloads and more info: https://www.blackcatsystems.com/software/kiwiSdr-sound-client-virtual-audio-device.html

The s meter extension is a great tool, I use it frequently. One thing I do is take two readings, first a baseline on a nearby "empty" frequency to get an estimate of my overall background noise level, then one on the station of interest.

When I change frequency, the graph clears, which is probably useful to many users. Is there a way to prevent this? Sometimes it would be nice to see both signals on the same graph.