Wideband FFT analyzers? SDR?

buy or make?

a XC6SLX150T is ~200$

-Lasse

Most definitely "buy" :-)

I know how it's done, what I am looking for is some company that's already dunnit. A brief email chat with an engineer at Signalhound a few minutes ago turned out that they should very soon have a glove-fit USB-pod for this task. A device that can stream large swaths of RF blazingly fast into the PC. Can't wait.

Can Windows do anything 2000 times per second?

Streaming? Yes. At one client we were pumping over 400Bbits/sec into the computation machine, via USB. But their system was full custom and I really want to avoid that.

If it doesn't need to be portable I'd put the digitizer (after a down converter) onto a PCI express card and let the CPU do the number crunching.

Crash? It can't do stuff 200x a second reliably IME (Ethernet comms with custom instrumentation).

Best regards, Spehro Pefhany

Yes. Even if you add a few zeroes. Need more computational power? No problem. By adding (headless) CUDA graphics cards you can get hundreds of gigaflops from a standard PC. IOW nothing beats the PC platform when it comes to number crunching on a tight budget.

You can if it's a waterfall FFT. It updates only one line (or columns if running it horizontally) of the waterfall display per finished FFT and then scrolls all the previous ones one pixel position up (or to the left). So if you have 1920 pixels available you'd see a smidgen more than one frame per second scrolling along the screen. On my netbook it would be about 2frames/sec because that has 1024 pixels. No a big deal, really.

Possible if we have to. But ideally it should be able to work with an off-the-shelf PC without opening it or even a laptop. A modern processor can crunch FFTs really fast.

When you don't need the full spectrum, I thought chirp-z was the way to go. That is how the audio DSA's work. The idea is the algorithm is more complex, but you don't need as many points since you can limit the analysis to the desired bandwidth.

I'm sure Vladimir the DSP guru will comment.

On a sunny day (Mon, 17 Dec 2012 17:05:55 -0800) it happened Joerg wrote in :

It so happens I am working on a FFT Linux GUI for the DVB-T USB sticks used as spectrum analyzer / software radio. As usual as the stick has not arrived yet, I spend a whole weekend coding 'in advance'. with simulated data. I am building on the rtl_sdr and rtl_fm code. Here is some test screenshot:

I decided not to use gnu radio, as I cannot get it working, and I do not like and understand python. So this uses the fftw library.

As to your required specs I have no idea at this point without practical tests if that is possible. I may replace fftw by some other smaller fft code I have.

But this coding is a lot of fun. I can see a years long evolving project.

I have spend about 21 dollars so far (ebay stick) :-)

Spehro Pefhany a écrit :

Not even once a day...

ed as

'in advance'.

like and understand python.

tests

but it is only 3.2MHz sample rate, that doesn't quite cut it for 20MHz BW

-Lasse

On a sunny day (Tue, 18 Dec 2012 02:28:10 -0800 (PST)) it happened " snipped-for-privacy@fonz.dk" wrote in :

Only if you look at one tuning position. So say you want 100MHz, and 50 MHz bandwidth FFT, and have 2 MHz bandwidth, Tune to 100 - 28, grab data, tune to 100 - 26, grab data, .... tune to 100 + 28, grab data

all together now do the FFT. Do Hamming (for example) window over data. display fft from 75 to 125 MHz

time is on your side, if not, then you are out of luck, but Maya calendar ends December 21 2012, so you can calijugaliate how many MHz you can get given acquisition time for this unit I think you can shorten acquisition time considerable by using less samples, but I need some practical tests to see how fast the tuner PLL locks.. Less samples means less resolution. That is no problem, as when you want details on a part of the spectrum you can zoom in, you are always limited by screen resolution for display anyways.

The Bluestein method would still require a wideband receiver. I have thought about doing it all analog (again ...) and finding the response in the demodulated signal. Then I only need the sound card or something to display. Considering the SW- and HW-obstacles that still seem to be in the way of contemporary SDR I might just do that.

Annoy?

-- "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." (Richard Feynman)

Just some numbers to work with. FFT has O=n*log2(n) butterflies. for

That is about 230 million butterflies per second or about 1 GFLOP.

Next, I/O bandwidth 8196 points times 2000 times a second is 16,392,000 samples per second. That will overrun most PC's I/O capability. You may have to drive the display yourself.

Looks like FPGA + a fast ARM is the most reasonable solution, unless you can find what you want otherwise.

I think i saw something once that could receive either half or the whole FM band all at once, but that may be a happy dream. It was armature radio related.

?-)

OK i had neglected that option. Plenty of GFLOPS to be had there. Still, shoving 16 MBytes/s to 32 MBytes/s into a PC is no joke.

?-)

Amateur radio :-)

The widest BW direct digital RX I found has 4MHz. Not a whole lot. But meantime I have decided to do it all analog in hardware as usual, no FFT. I just ordered the stuff at Digikey. SDR just ain't ready yet.