A Visual Introduction to DSP for SDR now includes some slides on digital modulation.

I wrote these a long time ago but the wording was targeted at an amateur radio audience. I finally got around to tweaking it to be slightly more general and publishing the result.

Background

In software-defined radio, there are well-established ways of visually representing the signal(s) in the entire bandwidth available from the hardware; we create a plot where the horizontal axis is frequency (using the Fourier transform to obtain the data). Then either the vertical axis is amplitude (creating an ordinary graph, sometimes called panorama) or the vertical axis is time and color is amplitude (creating a waterfall plot).

Here is an example of ShinySDR's spectrum display which includes both types (y=amplitude above and y=time below):

A further refinement is to display in the graph not just the most recent data but average or overlay many. In the above image, the blue fill color in the upper section is an overlay (both color and height correspond to amplitude), the green line is the average, and the red line is the peak amplitude over the same time interval.

We can see signals across an immensely wide spectrum (subject to hardware limitations), but is there a way to hear them meaningfully? Yes, there is, with caveats.

What's pictured above is a small portion of the band assigned to aviation use — they are used primarily for communication between aircraft in flight and air traffic control ground stations. The most significant thing about these communications is that there are a lot of different frequencies for different purposes, so if you're trying to hear “what's in the area”, you have to monitor all of them.

The conventional solution to this problem is a scanner, which is a radio receiver programmed to rapidly step through a range of frequencies and stop if a signal is detected. Scanners have disadvantages: they will miss the beginning of a signal, and they require a threshold set to trade off between missing weak signals and false-triggering on noise.

An alternative, specific to AM modulation (which is used by aircraft), is to make a receiver with very poor selectivity: the ability to receive only a specific channel and ignore other signals. (Historically, when RF electronic design was less well understood and components had worse characteristics, selectivity was a specification one would care about, but only if one lived in an area with closely-spaced radio stations — today, every receiver has good selectivity.)

I'm going to explain how to build an unselective receiver in software, and then refine this to create spatial audio — that is, the frequency of the signal shall correspond to the stereo panning of the output audio. This is the analogue of the spectrum display in audio.

Of course, this is an AM receiver and so it will only make intelligible sound for amplitude-modulated signals. However, many signals will produce some sound in an AM receiver. The exception is that a clean frequency-modulated (FM) or phase-modulated signal will produce silence, because its amplitude is theoretically constant, but this silence is still audibly distinct from background noise (if the signal is intermittent), and transmitted signals often do not have perfect constant amplitude.

Implementation

A normal software AM demodulator has a structure like the following block diagram (some irrelevant details omitted). The RF signal is low-pass filtered to select the desired signal, then demodulated by taking the magnitude (which produces an audio signal with a DC offset corresponding to the carrier).

In order to produce an unselective receiver, we omit the RF filter step, and therefore also the downsampling — therefore demodulating at the RF sample rate. The resulting real signal must be low-pass filtered and downsampled to produce a usable audio sample rate (and because the high-frequency content is not interesting; see below), so we have now “just” swapped the two main components of the receiver.

This simple change works quite well. Two or more simultaneous AM signals can be received with clear stereo separation.

One interesting outcome is that, unlike the normal AM receiver, the audio noise when there is no signal is quieter (assuming AGC is present before the demodulator block in both cases) — this conveniently means that no squelch function is needed.

The reason for this is obvious-in-hindsight: loosely speaking, most of the noise power will be at RF frequencies and outside of the audio passband. In order to have a strong output signal, the input signal must contain a significant amount of power in a narrow band to serve as the AM carrier and sideband. (I haven't put any math to this theory, so it could be nonsense.)

Adding stereo

In order to produce the spatial audio, we want the audio signal amplitude, in a single stereo channel, to vary with frequency. And that is simply a filter with a sawtooth frequency response. The signal path is split for the two stereo channels, with opposite-slope filters. (AGC must be applied before the split.)

An undesired effect is that near the band edges, since the filter has a steep but not perfectly sharp transition from full-left to full-right, there is a lot of slope detection (output from frequency-modulated signals) that does not occur anywhere else. Of course,

This design can of course be applied to more than two audio channels; using surround sound would avoid the need for steepness of the filter at the edges and map the inherently circular digitized spectrum to a circular space, so it's worth trying.

Notes

I've implemented this in ShinySDR (and it is perhaps the first novel DSP feature I've put in). Just click the “AM unselective” mode button.

Some “directions for future research”:

As I mentioned above, this is useless for listening to FM signals. Is some technique which can do the same for FM? Naïvely creating an “unselective FM receiver” seems like it would be a recipe for horrible noise, because to a FM demodulator, noise looks like a very loud signal (because the apparent frequency is jumping randomly within the band, and frequency maps to amplitude of the output).

If we declare that the output need not be intelligible at all, is there a way to make a receiver that will respond to localized signal power independent of modulation? Can we make an unmodulated carrier act like an AM signal? (CW receivers do this using the BFO but that is dependent on input frequency.)

My interactive presentation on digital signal processing (previous post with video) is now available on the web, at visual-dsp.switchb.org! More details, source code, etc. at the site.

(P.S. I'll also be at the next meetup, which is tomorrow, January 21, but I don’t have another talk planned. (Why yes, I did procrastinate getting this site set up until a convenient semi-deadline.))

I have really failed to get around to blogging what I've been doing lately, which is all software-defined radio. Let's start fixing that, in reverse order.

Yesterday, I went to a Bay Area SDR meetup, “Cyberspectrum” organized by Balint Seeber and gave a presentation of visual representations of digital signals and DSP operations. It was very well received. This video is a recording of the entire event, with my talk starting at 12:30.

A couple weekends ago, I was musing that among my electronic devices there was no radio — as in AM/FM, not WiFi and Bluetooth and NFC and etc. Of course, radio is not exactly the most generally useful of information or entertainment sources, but it still has some things to be said for it, such as being independent of Internet connections.

Another thing that came to mind was my idle curiosity about software-defined radio. So, having read that Wikipedia article, it led me to an article with a neat list of radio hardware, including frequency range, sampling rate (≈ bandwidth) and price. Sort by price, and — $20, eh? Maybe I’ll play around with this.

What that price was for was RTL-SDR — not a specific product, but any of several USB digital TV receivers built around the Realtek RTL2832U chip, which happens to have a mode where it sends raw downshifted samples to the host computer — intended to be used to provide FM radio receiving without requiring additional hardware for the task. But there's plenty of room to do other things with it.

I specifically bought the “ezTV”/“ezcap” device, from this Amazon listing by seller NooElec (who also sells on eBay, I hear) (note: not actually $20). One of the complications in this story is that different (later?) models of the same device have slightly different hardware which cannot tune as wide a frequency range. (Side note: when buying from Amazon, what you actually get depends on the “seller” you choose, not just the product listing, and as far as I know, any seller can claim to sell any product. If you see a product with mixed “this is a fake!” and “no it's not!” reviews, you're probably seeing different sellers for the same product listing.)

Of course, the point of SDR is to turn hardware problems into software problems — so I then had a software problem. Specifically, my favorite source for unixy software is MacPorts, but they have an obsolete version of GNU Radio. GNU Radio is a library for building software radios, and it is what is used by the first-thing-to-try recommendation on the Osmocom RTL-SDR page (linked above), multimode.py. The MacPorts version of GNU Radio, 3.3.0, is too old for the RTL-SDR component, which requires 3.5.3 or later. So I ended up building it from source, which took a bit of tinkering. (I'm working on contributing an updated port for MacPorts, however.)

I've had plenty of fun just using it “scanner” style, seeing what I can pick up. A coworker and friend who is into aviation posed a problem — receive and decode VOR navigation signals — which has led to several evenings of fiddling with GNU Radio Companion, and reading up on digital signal processing while I wait for compiles and test results at work. (It sort-of works!)

This is also notable as the one time in my life where a ferrite bead on a cable actually did something — putting one on the computer end of the USB extension cord noticeably reduced the noise level. (And, of course, there remains a large, metallic hardware problem: antennas!)

(I could say more, such as the detailed fiddling to build GNU Radio, and various useful links, but it's taken me long enough to get around to writing this much. Let me know if you'd like me to expand on any particular technical details.)