Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration

[Sylvain Munaut]

Hi,

> Well, the fosphor waterfall itself isn't of much use at high rates as the
> signals just whizz of the screen before you get a chance to look at them.
> The magic, as you point out, is in the fosphor FFT plot, which is awesome!

It kind of depends what you're looking for.

Personally I use the waterfall to see the repeteative burst structure
of the signals.
And despite the fast speed I can spot the FCCH of tetra and gsm
signals for examples and even see on which 'side' they are to know if
I'm looking at an image.

But I agree it doesn't fit all use case and this is why I want to
implement the aggregation feature I talked about.


> All I would like is for the waterfall to not be jerky at moderate sample
> rates. I find that a waterfall presents a better target than an FFT plot for
> a click-to-tune function, but a jerky one is not good.

As I said, it's due to the 'batch' processing nature of fosphor. When
the sample rate is so low that the batch size is not negligeable,
you'll see jerky movements.

Given a minimum batch size of 16*1024, if you want 30 fps for a smooth
scroll, you'd need 500 ksps at minimum.

Now one way to artificially feed fosphor with more data is to create
overlapping FFTs. You can do this in GRC using standard blocks :

http://i.imgur.com/9F7rYLJ.png

In this setup each input sample will be processing in 4 overlapping
windows, and so if you sample rate is 196 ksps you'd effectively feed
784 kbps to fosphor and should yield a smooth waterfall.


Now of cours there are other options like :

 - Instead of advancing the waterfall display in 1 frame per batch,
you could code it so that the new data of 1 batch is "spread" over
2/3/4 frames, but that will cost you latency. Also you can't do it for
the histogram view.

 - Modify the code to allow for smaller batch sizes. I might implement
batch size of 8 (mostly because some older ATI card can't deal with
16x16 OpenCL workgroup sizes), but I won't go lower than that.

At these sample rates, using the GPU is really not that necessary and
becomes annoying because of some of the limitation it imposes. A full
CPU implementation would probably be more flexible. A lot slower of
course, but for 48 ksps that just doesn't matter.


Cheers,

    Sylvain