# Determining the features of the DSP

I need to sample a signal of 40MHz with a sampling frequency of 120MHz at least with a 8/12 bits ADC and send them through the USB serial port of a PC. That means the serial communication bandwith should be at least 960/1440 megabits per second.

What kind of DSP should I use to satisfy this bit-rate, and what signal-processing-methods should I learn to optimize this bit-stream to use the same data simultaneously with a mainstream PC. (The bitrate seemed a bit huge for me.)

I have no experience with DSPs before. I was seeking for answers for a while but not even my teachers, or their assistants could help me for a little long period of time.

I just need a beacon to find the answers of the questions, thanks in advance.

Edit: I wrote 40Hz instead 40MHz, I am really sorry.

• Why do you need to sample 40 Hz of bandwidth with 120 MS/s? That's and oversampling by one and a half million! (My guess is you're missing a M there?) – Marcus Müller Feb 19 '18 at 9:07
• Can you please check the edit reason and answer again, I must have been distracted so I mistyped the original BW of the signal – My name is name Feb 19 '18 at 12:13
• What is the content of the signal? – A_A Feb 19 '18 at 12:57
• The content of the signal is unknown. It's all for developing a basic RF-Spectrum Analyzer that'll be used as a peripheral for a PC, my final project. – My name is name Feb 19 '18 at 13:27
• no, it's not unknown. You have to know it's bandlimited, otherwise you can't ever sample it. – Marcus Müller Feb 20 '18 at 10:10

This doesn't sound like you need a DSP at all.

You'll need something that does USB3 towards your computer. Typical solution to that is the fx3 chip from cypress. I'm not aware of DSPs that integrate a USB 3 phy or even just the logic to speak to one - not a typical interconnect in their world.

Then you need something that orchestrates the ADC, keeps timing correct, and hands over the data to the usb3 chip, but doesn't do much of actual signal processing.

The whole "glueing one high speed digital thing to another" aspect screams for an FPGA. So, what I'd recommend: pick an FX3 development board and design an FPGA/ADC add-on board to that.

May I also interest you in other interconnects? Maybe gigabit Ethernet is sufficient for your use case; in that case, you could basically use the Ettus N200 as reference design (schematics are public). Or buy one - it comes with a dual-100MS/s ADC, and with the BasicRX daughterboard, you can directly interface with that ADC in baseband.

Full disclosure: I'm affiliated with Ettus, but to be honest, I'd like to see you succeed in building your DAQ device :)

• Can you please check the edit reason and answer again, I must have been distracted so I mistyped the original BW of the signal. – My name is name Feb 19 '18 at 12:13
• I was assuming you meant 40 MHz analog BW all along. So, this changes nothing. – Marcus Müller Feb 19 '18 at 12:14
• Thanks for all so far! Would you mind if I asked you a bit of further, more specific question? Assuming that everything works like a charm from the front-end to the point where the serial data is being received continuously; I still can't be sure whether if a mainstream PC-CPU could perform complex mathematical processes (like fourier transform etc) simultaneously. Do you have any idea of a method to estimate the resources needed from a computer too? That was the main reason to consider for me to use a DSP instead of using an FPGA. – My name is name Feb 19 '18 at 13:23
• well, try exisiting DSP frameworks. Another disclosure: I'm head maintainer of GNU Radio, but that is a framework meant for exactly that kind of processing – and in my experience, one can easily process 50 MS/s complex (which is actually 100 MS/s real-valued) coming from a USB3 device (in my case, a Ettus B210) through FFTs, given sufficiently beefy CPU – and these are totally affordable these days. In your case, I'd go ahead and do the following: Get GNU Radio – if you have a modern Linux distro, you can probably just dnf install gnuradio (or apt-get, or whatever). … – Marcus Müller Feb 19 '18 at 14:13
• then set up a mock flowgraph – one that feeds in pseudodata from e.g. a "null source", and observe its operating rate through a "probe rate->message debug" combo. If that rate is sufficiently higher than what you need, your PC still has enough headroom to do the USB handling whilst doing the signal processing. For example, the slow PC I'm sitting at right now: – Marcus Müller Feb 19 '18 at 14:16