FFT runs slow if input sample rate is dropped to 300 kHz

[darrenfreeman]

I dropped the input sample rate from 2.5 MHz to 300 kHz. This should speed everything up. Fewer samples to process in order to decode a 150 kHz wide FM signal. And it does speed up the FM decoder and stop audio drop-outs.

But the FFT updates only a couple of times a second. It doesn't matter if I drop the number of FFT samples to 512. The waterfall continues to fall at, say, 60 lines per second. But many of those lines are repeated, say 30 lines have one pattern, then 30 have another, with the pattern changing when the FFT updates.

I think there must be something hard-coded that requires a certain number of samples to be acquired between FFTs. Maybe 128k samples? Does a block length need to be reduced, in order to allow real-time visualisation of low sample rate acquisitions? At 300 kHz sample rate and 60 Hz FFT rate, there should still be 5000 samples available per FFT. Running a 4096-point FFT should be reasonable without the FFT source windows overlapping.

In fact, if the user really wants, you could run a 32768-point FFT by reusing samples that have already been transformed. But I'd forgive you if that happens to be a pain to implement ;)

[darrenfreeman]

Actually the noise is much worse when I drop the sample rate with RTL-SDR, so I fear it is not filtering the signal prior to sampling it at the lower rate. It's as if the whole 2.5 MHz spectrum is just aliasing into the 300 kHz piece that I'm acquiring. Maybe.

[csete]

The rtl-sdr driver (or device itself) prefers to transfer large buffers so if you drop the sample rate it will only update few times per second. With other devices (e.g. funcube dongles) it runs smoothly even at 96 ksps rate.

[darrenfreeman]

That still sounds like a bug in gqrs. It should be able to display more than one FFT per buffer. If you get 100 ms of data, that's 6 FFTs worth at 60 FPS.

[csete]

Yes, of course it is possible, but now it happens that it is not the way the FFT in gqrx has been implemented. You can call it a bug if you wish, from my point of view it was a deliberate choice.

[csete]

You can add buflen=16384 to the device string to reduce the transfer sizes and this will give smooth FFT. Other values may also work but buffer length must be multiple of 512 and preferably multiple of 16384 (URB size).

For other possible options, see http://sdr.osmocom.org/trac/wiki/GrOsmoSDR#RTL-SDRSource

[darrenfreeman]

I just added buflen=16384 and set the sample rate to 300kHz. Then I hit the "power" button on the top left, to start the radio, and boom:

Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there.

terminate called after throwing an instance of 'std::runtime_error' what(): In hierarchical block source_impl, output 1 is not connected internally

[darrenfreeman]

This happens for lengths of 32768, 65536, 131072. I stopped here because I thought 128k was the value that it defaults to. It seems use of the buflen string is a problem.