2
\$\begingroup\$

I'm writing some Python code which retrieves the FFT data that is generated in my Rigol DS1102E oscilloscope via its USB connection.

My trouble is that no matter what time scale I set, I get no more than 10 FFT results per second.

Are there any fast USB devices which can produce results more frequently? I was hoping to achieve at least 100 FFTs per second.

Currently my scope generates 512 bins, and my input waveforms range from 100hz to 10,000hz.

I was thinking of using a soundcard for this but was actually hoping to find a "co-processor DSP" device and let it do all the work independently of the device which Python is running on.

Due to python not being very fast and the fact that I may want to monitor multiple inputs at once, It would be difficult to use the soundcard for live FFT visualization (especially on something like a Raspberry PI)

Thanks!!

\$\endgroup\$
16
  • 1
    \$\begingroup\$ Processing is probably not the challenge - getting the data to a suitable processor is. But there are various USB scopes a few of which may be capable of continuous (or frequent burst) streaming over USB. At the really high end, an FPGA-based software defined radio may be within reconfiguration of what you want to do. Focus more on the nature of the source data and if you need all of it, or only frequent bursts. \$\endgroup\$ Nov 1, 2016 at 2:18
  • 1
    \$\begingroup\$ In general, if you don't know you need an FPGA, you probably don't actually need an FPGA. And for smaller FFTs, simply adding another raspberry PI is going to be far more expedient (and cheap) then a "dedicated co-processor", which might very well just be the same CPU as the Pi. There is really nothing "breadboardable" that will get you anywhere near the $/MIPS like the Pi. \$\endgroup\$ Nov 1, 2016 at 3:46
  • 1
    \$\begingroup\$ Almost certainly. Use FFTW unless GPL is completely unacceptable. (Edit: FFTW now has first-party ARM support). \$\endgroup\$ Nov 1, 2016 at 4:04
  • 1
    \$\begingroup\$ KISSfft is a reasonable alternative if you can't use GPL, though not as performant (I use FFTW and kissfft at work. They're both quite easy to integrate). \$\endgroup\$ Nov 1, 2016 at 4:08
  • 1
    \$\begingroup\$ Cripes, I used to do 1024-pt complex-in, complex-out FFT in 3 ms on a 1991-date ADSP-2111 and faster still on the ADSP-2181 when I got those a few years later. 16-bit ADC data and the core only running at about 40 MHz. A 4-core ODROID-C2, 2GHz, cost about the same as a Pi and will run rings around it I think. If going that way. \$\endgroup\$
    – jonk
    Nov 1, 2016 at 5:16

1 Answer 1

1
\$\begingroup\$

my input waveforms range from 100hz to 10,000hz.

Seriously, that means (by Nyquist) that a sampling rate of 20 kHz is sufficient – you probably want to oversample a bit, but everything above 40 kHz is luxury.

In other words, this is best soundcard-territory.

Get a cheap (<10$) USB sound card, remove the coupling capacitors from the microphone input, and use some kind of of adjustable opamp-based amplifier to get your input signal into the Soundcard's range. Done.

It would be difficult to use the soundcard for live FFT visualization (especially on something like a Raspberry PI)

You're making wrong assumptions here!

Processing this amount of data is definitely not a problem on anything faster than the cheapest pocket calculators. A raspberry Pi, a laptop, a PC or a smartphone will definitely do. Really, the effort of doing an FFT on this amount of samples is thoroughly ridiculously small. Decoding an MP3 is far more tasking for any computer (fun fact: MP3 requires an operation pretty similar to the FFT).

Don't worry about Python slowing you down: No Python library I know does the FFT in python itself, but rely on FFTpack or FFTw (numpy, for example). You can do such short FFTs (i.e. "less than a hundred thousand bins") at sampling rates of multiple Megasamples per second on a normal PC, so don't worry about the workload posed by the FFT. Seriously, 100+ transforms of length 1024 per second? More like 1 Million transforms per second, in my experience. I can't stop wondering why people even think that's hard, but watch full-screen MPEG4-encoded videos at the same time on all of their devices.

To demonstrate how easy this is: I wrote an answer a while back that demonstrates how to visualize audio data. If you don't do the whole loopback dance, but just select your soundcard as source, you're done and have your FFT'ing visualization:

Visualization using GNU Radio

I also wrote a minimal firmware a while back (can't find it, sorry) that used a 6$ Tiva-C ARM evalboard to convert and send samples to a PC at up to 200kS/s over USB as bulk transfers. You'd have to write your own userland "driver" software to talk to such a device, but it'd work, too. But there's not much winnage in doing so compared to buying a sound card, unless you'll need to use such a microcontroller anyway, e.g. to control something else.

\$\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.