2
\$\begingroup\$

Most software defined radio peripherals involve a FPGA. In designing a SDR peripheral, I would like to know whether its possible to design a GNU Radio Compatible SDR hardware peripheral without any FPGAs. i.e. Directly sending the output from the ADCs to a PC via USB. If possible, I think enter image description here My interest to eliminate FPGAs (at some other cost) is because FPGA soldering, design is a difficult process that is not properly explained by most vendors. If there is a way I could eliminate them from my design it will be great. My interest is to design something similar to this.

In the above image I found from TI, is it possible that we directly connect the output of the ADC to the to the PC via some sort of a USB connection? Perhaps, transmission is possible this way as well.

I would also like to know the exact purpose(s) of using FPGAs in SDR peripheral designs. Im sure there may be many. But I would like to know the most imperative ones.

UPDATE:

As suggested by Neil_UK in the answers section, if the limitation is not being able to transmit the raw ADC samples via a USB interface to the PC due to slowness in USB speed, What would be the highest practical bandwidth that we could have in a system that directly connects the ADC to a USB? perhaps a USB 3.0? is it only the bandwidth that will be limited by this decision? What other fundamental features would go missing if SDRs were desiged this way? (provided its not required to operate on signals e.g. demodulate them)

\$\endgroup\$
1
  • 3
    \$\begingroup\$ You can't directly connect the ADC to USB unless you can find an ADC with a USB interface; you'll need to find something that can act as a USB endpoint and speak to the ADC. \$\endgroup\$
    – pjc50
    Commented Dec 25, 2016 at 12:06

5 Answers 5

Reset to default
3
\$\begingroup\$

Note: we're going to oversimplify SDR hardware for illustration in this answer

ADC --> PC is (one of) the functions of the FPGA

The FPGA serves different functions in different SDR designs, but one of its primary purposes is to "just connect the ADC to the PC". I think you don't fully appreciate the process of moving data through the Universal Serial Bus (USB) and the process of capturing the radio signal.

SDR's typically require at least two ADC streams (quadrature capture after down conversion) and usually have multiple quadrature channels to do advanced things like MIMO, RADAR/Beam-forming, etc...

The FPGA is required to multiplex the digital data streams coming off the various ADC's, to format the data in a manner compatible with USB (and ultimately gnuRadio), and to receive control information from the PC/gnuRadio and effect the various changes to the ADC's and down-conversion components.

Without the FPGA you would have to implement these functions with other hardware and your design would end up much more complex, rather than the simplicity you seek. SDR designs have evolved to their current state and they are much lower cost/simpler today than they have been in years past.

Examples

Some common SDR products from Ettus and Pervices Devices illustrate the central glue-logic nature of the FPGA in these architectures. Note the placement of the FPGA between the high-speed analog converters and the relevant external data interfaces.

enter image description here

enter image description here

\$\endgroup\$
5
  • \$\begingroup\$ This is mistaken. Typical FPGA-based SDR's use a USB interface chip capable of taking data directly from an ADC, possibly with a hardware FIFO in between. The point of having an FPGA is to do some pre-processing in hardware to better use the bandwidth of the older USB standards to represent the information that is of most interest, vs. just taking raw samples at the highest rate that will fit down the pipe. \$\endgroup\$
    – Chris Stratton
    Commented Feb 5, 2017 at 21:02
  • 1
    \$\begingroup\$ @Chris -- I've expanded the answer, perhaps you might reconsider? (1) I've never seen an ADC, without an MCU/CPU embedded, that had a USB interface. What would be the application space for those chips? Modern FPGA based systems are architected as I've described and I've included a few product references to illustrate this point. (2) While some systems do front-end processing in the FPGA, this is an implementation liability and not the design goal of Software Defined Radio. Finally, as originally noted in the answer, this is one of the functions of the FPGA, not it's only function. \$\endgroup\$
    – DrFriedParts
    Commented Feb 6, 2017 at 22:20
  • \$\begingroup\$ Read the comment again. No one said there were ADCs with USB interfaces, rather that ADC data can flow directly to a USB interface chip - you only need the FPGA in between if you feel that it would be more optimal to put something other than the raw ADC samples down that pipe. You know the simple USB logic analyzers based on Cypress USB chips? A simple SDR can be an ADC feeding one of those, a more complex one puts an FPGA in between to permit hardware decimation and filtering. \$\endgroup\$
    – Chris Stratton
    Commented Feb 7, 2017 at 0:15
  • 2
    \$\begingroup\$ I know you know what you're doing. We're splitting hairs at this point. Cypress EZUSB is not fast enough for high-end SDR, that's why you see FPGA's (yes, it does other stuff too). Decimation is only necessary if your hardware or pipe isn't fast enough. If you're going to do filtering in the SDR hardware, by extension, you could just do all the filtering/processing in the FPGA and you have a conventional radio. The purpose of SDR is to (try to) do all the processing in software where it's flexible and exposed and where multiple signal chains could be executed in parallel. \$\endgroup\$
    – DrFriedParts
    Commented Feb 7, 2017 at 0:32
  • \$\begingroup\$ Either the USB pipe in use can accommodate the sampler bandwidth, or it can't - if it can, you don't need an FPGA unless there are implementation quirks you need it to work around. But since you mentioned splitting hairs, most would not consider reconfigurable operations in an FPGA (if utilized) to fall outside of the "software" in "software defined radio" - rather they are just an example of optimizing the architecture of computation to the task at hand. Perhaps we might more accurately call it "computationally implemented radio" \$\endgroup\$
    – Chris Stratton
    Commented Feb 7, 2017 at 1:06
6
\$\begingroup\$

Data rate => bandwidth.

USB will handle only a limited data rate, and the entire digitised bandwidth would have to fit into this channel.

With an FPGA at the remote end, it can crunch the digitised bandwidth down to the actual channel bandwidth, which could be one or two orders of magnitude smaller, and send that down the USB. It could go further and demodulate the data, for another order or two of data rate reduction.

\$\endgroup\$
4
  • \$\begingroup\$ I think the PC communicates with the SDR and tells the PLL to tune to the required frequency requested by the GNU Radio. So only the bandwitdh of the ADC is finally captured by the system. I mean to say that the data rate is a direct dependancy of the speed of the ADC. for e.g.The popular hakrf has a bandwidth of 20MHz. Meaning the ADC will have to run atleast at 40MHz. At 40M samples per sec, the data produced is 40M * 8 bytes per sec if the ADC has 8 bit accuracy. I believe this many bits can be transferred via USB, atleast via USB3.0. So COuld you please tell me? \$\endgroup\$
    – Denis
    Commented Dec 25, 2016 at 11:21
  • 1
    \$\begingroup\$ @qwertylicious : you're assuming the sampling the hackrf does is real if you think that f_sample must be twice the bandwidth. That's not the case here - hackrf, like other direct-conversion devices, use complex baseband, which means the Nyquist bandwidth equals the sampling rare \$\endgroup\$
    – Marcus Müller
    Commented Dec 26, 2016 at 6:26
  • 1
    \$\begingroup\$ But you're right, each sample then actually consists of a real and an imaginary part, hence your bandwidth calculation still is right. USB2 hi speed does up to 480Mb/s minus overhead (which is substantial) \$\endgroup\$
    – Marcus Müller
    Commented Dec 26, 2016 at 6:28
  • \$\begingroup\$ USB2 has been seen, in practice, to do about 310Mbps. Assuming 8-bit samples (cheap RTLSDR) and 2 channels (I and Q signals) that limits you to 20MSamplles/sec. Many good SDRs have higher sample resolutions, speed - and use the FPGA to downsample / channel select etc. To reduce the data throughput to something USB2 can handle. \$\endgroup\$
    – Alan Campbell
    Commented May 21, 2018 at 3:44
3
\$\begingroup\$

Yes, it's possible, this is what the DVB receivers do. You could also do an USB 3.0 design, e.g. based on the EZ-USB FX3, these can be connected to ADCs and DACs easily, and the firmware just sets up a pipe between a bulk endpoint and the peripherals.

The downside of this is that the data is completely unprocessed then. You need at least DC offset correction per ADC, and compensation for the shape of the aliasing filter. Implementing this in software will eat quite a lot of CPU time. At the same time, the extra cost of the FPGA is not that large compared to the analog parts.

\$\endgroup\$
2
  • 2
    \$\begingroup\$ Fun fact: I do work for Ettus, the b2xx series uses the fx3, and in reality, the handling of complicated ADC/DAC hardware tends to be so complex that FPGAs as glue turn out to be necessary. Not claiming it's impossible to do without an FPGA, just much harder, functionally, as you say, restricted and mostly "not worth it" \$\endgroup\$
    – Marcus Müller
    Commented Dec 26, 2016 at 0:19
  • \$\begingroup\$ Hey Marcus, nice to hear from u again. Thank u for acting on my previous comments. i.e. the deletion of identity related comnts. The point of this question ws for me to clear some doubts I had been having whn I was searching for various SDR hardware. I wanted to design a breadboard SDR (I know im crazy). I dnt want it to be in flashy GHz range. Proof of concept is fine. I.e. Receive something from air! If I can do that, I can make all my students make an SDR for an assignment! and force them into the world of SDR by means of an assignment. I think I should. Bt unfortunately life is not simple. \$\endgroup\$
    – Denis
    Commented Dec 27, 2016 at 2:35
1
\$\begingroup\$

Your proposal of a software-defined-radio consisting of an analog-to-digital converter front-end, feeding a (slow) PC is possible, but not practical.
The rate at which the PC can process samples sets the ADC sampling rate. For much radio work, this rate would be relatively low, requiring the ADC to under-sample its input voltage.
To prevent aliasing, an analog narrow-bandwidth bandpass filter must precede the ADC. Furthermore, the ADC would require a rather high-performance sampler at its front-end. These two requirements make the scheme somewhat impractical.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ I do agree on the "let the FPGA do the heavy high rate lifting", but keep in mind that even laptops these days easily deal with solidly upwards of 20MS/s \$\endgroup\$
    – Marcus Müller
    Commented Dec 26, 2016 at 0:21
  • \$\begingroup\$ You are not wrong conceptually, but you are quite wrong practically. Things like a commutating mixer feeding an op-amp lowpass filter make it possible to build great receivers using relatively low sampler bandwidth - classically, high end audio ADCs. You can use the same technique with an ADC corresponding to the maximum data rate you can shove down a given USB standard. \$\endgroup\$
    – Chris Stratton
    Commented Feb 5, 2017 at 21:06
1
\$\begingroup\$

Look up the "soft rock" SDR kits.

Limited to HF, these program an oscillator (si570) to mix the desired channel down to the audio range. Then they capture the data using a computer sound card.

Quality depends on the sound card you use. There are USB-based external sound cards you can use with the kit, which may give better results than the built-in soundcard of [for example] a cheap laptop.

Links:

http://fivedash.com/

http://www.wb5rvz.com/sdr/

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.