Requirements

My receiver design follows the well-trod path of sampling I and Q signals in order to perform demodulation in software. Since (a) my initial goal is to receive broadcast FM (which has a bandwidth of around 250 kHz), and (b) I'm using the zero-IF approach, then I'll need to run each ADC at 250 ksps or greater. I'd like to do the DSP on a PC to start with, so I'll need to transfer those samples over e.g. USB. If the sample resolution is 8 bits then the required data transfer rate is 500 kB/s or greater.

Design

The quickest way I could think of to meet these requirements was to build something based around the built-in ADC on a RP2040 microcontroller, since I already own a Raspberry Pi Pico or two. Here's a sketch of what I'm came up with:

I'm using a FT232H (on an Adafruit breakout board) to interface to USB because I couldn't immediately figure out how to achieve the required transfer rate using the microcontroller's built-in USB.

The FT232H is configured to operate in asynchronous FIFO mode. In this mode, a byte can be transferred over USB simply by asserting data on to the 8 data pins and toggling the write pin.

On the RP2040 the ADC is running in round-robin mode, producing interleaved samples from two inputs, each at 250 ksps. DMA is used to transfer 8 bit samples to a PIO block, which waggles the pins on the FT232H as required. The upshot is that the CPU isn't involved in running the ADC or transferring the data, beyond performing the initial hardware set-up.

On the front-end I have a pair of op-amps (MC3317N) to shift the inputs into the 0 to 3.3V input range of the ADC.

Build

I built this design on a solderless breadboard:

Testing

Here's a plot of data captured while driving one of the inputs with my homebrew signal generator:

Potential Problems

I suspect there are a few potential problems with this approach:

• I and Q are not sampled simultaneously. There's an offset of half the sampling period between the channels as a result of multiplexing the two channels onto a single ADC. This is going to lead to degraded performance, though I don't know what form this takes or how significant it is. Perhaps I can compensate for this in software.
• The sample rate is only just sufficient. I'd prefer to perform some amount of over-sampling, if only to make room for an anti-aliasing filter.
• There are known issues with the ADC on the RP2040.
• The Pico provides the RP2040 with a noisy analog supply. See section "4.3. Using the ADC" of the Pico datasheet.

Nevertheless, my hope is that this set-up will be good enough for an initial test of the receiver.