Attention to detail for multifrequency radio logging
Let's say you're working on a project which involves recording multiple radio signals in parallel. To do this, you need a decent amount of bandwidth from your radio and a computer which can keep up with it. That much is a given. What about the other concerns? Some of them are not as obvious.
I've included an example of what the radio spectrum looked like during some tests a couple of months ago. This particular swath represents the span of the Santa Clara city system. The tallest spike right of center is the always-on control channel, which at that particular moment appears to have been on 852.6875 MHz. There's also some random junk transmission just right of center which is a function of my receiver.
To make this work, you have to identify all of the channels you want to get and determine exactly how much of a spread you're talking about. For this system, their lowest channel is 851.4625 MHz, and their highest channel is 853.8 MHz. If you do the math without thinking about what you're really doing here, you might arrive at a bandwidth of 2.3375 MHz. That's well within the abilities of the "RTLSDR" $20 TV tuner sticks, so that's no trouble. The problem is that you just forgot about the nature of the signals.
Signals are not a point source precisely on a single frequency. Even if they are impossibly perfect transmitters which never drift off-center, the signal itself has some amount of bandwidth. If you drop the fenceposts exactly on 851.4625 and 853.8, you will cut off the bottom half of the lowest one and the upper half of the highest one. This means you actually have to expand your receiver bandwidth to reach beyond them on either side.
Just to be safe, let's go for a nice wide span and use 2.8 MHz. If we center that on 852.5 MHz, we are now receiving signals from 851.1 up to 853.9. That leaves a comfortable amount of padding for our outermost signals. Now we have to check on whether we're stomping on anything with our center.
As you can see from my graph at top, there's a local signal which never really goes away on my device. It's likely a function of whatever it's doing inside the box to bring in the signal. Maybe it's a local oscillator. Whatever it is, it means certain fuzz for any signal which is too close. We put our center on 852.5. Is that safe?
It turns out that it's okay for this system. The nearest channels on the city system to 852.5 MHz are at 852.3 and 852.6875 MHz. That's at least 200 kHz away in either direction, and it just so happens that the noise it emits isn't quite that wide. Appropriate use of filters on the receivers will ensure that something that far away won't get into the demod stage and create noise.
This is why you can't always pick the center channels just by taking the upper and lower and dividing by two to get the middle. It might walk on something important. You have to drop your center at a good distance from any channel you actually want to receive cleanly, and then also adjust your bandwidth outward to make sure you still cover all of your channels despite the center adjustment.
There's another fun problem to worry about. Your receiver probably isn't perfect, either. I have two "RTLSDR" sticks and a USRP with a couple of daughterboards, and among all of them, I can have anywhere from 8 to 60 kHz of tuning variance depending on the center frequency, temperature, and phase of the moon. Awoooo.
This means all of your tuning calculations have to be adjusted up or down by some amount according to whatever the (potentially variable) tuning error might be. There are ways to calibrate this, of course. One interesting method locks on to LTE signals near you, decodes the actual frequency they claim to be on, and then compares it to the apparent frequency seen at your receiver. The difference is the tuning error.
I've been hand-tuning some of my devices by dropping them on a known long-lived transmission (like a control channel) and then adjusting the error up and down until I get a clean signal centered on my display. It should also be possible to do this in software with a bit more work.
So let's say you've handled the center frequency, bandwidth, and tuning error. There's still another piece which isn't immediately obvious, and will vary from one system to the next: signal strength. Look again at the above graph. Notice how the noise floor is around -20 dB in the center but rolls off to nearly -40 on either side. This is important! If you don't adjust your squelch levels to compensate, you may not be able to pull in channels which are near the edges.
Here's the difference in visual terms. First, a signal which was received at 853.425 MHz. Note the green line shows the maximum levels recorded during analysis:
It's centered nicely, and it peaked just above 0 dB. Now compare it to something closer to the edge, at 853.8 MHz:
It's also centered acceptably, but it only peaked at -10 dB.
With a sufficiently high squelch value, it's possible that otherwise perfectly good signals will be missed. It becomes necessary to allow per-channel squelch settings in those situations.
Finally, for comparison, here's a much wider (~3.5 MHz) view of the same spectrum captured by my USRP. I forgot to turn on the averaging mode which smooths out the lines, but you can still see how things work. Notice that the noise floor is down around -60 to -70 while actual signals come booming through at -20 or higher.
The rolloff also looks much less severe. I certainly don't have to do nearly as much per-channel squelch tweaking when running on this kind of equipment. Besides that, it can handle much higher bandwidths, so I can push the edges well past the outer signals I actually care about. It also means far more flexibility in terms of dodging local noise sources caused by the radio itself, however tiny they may be.
This is the kind of stuff I do to pull in a new system. If you're looking for this kind of wide band radio logging with a great web interface on top, get in touch. Thanks!