Gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration

Hi,

Actually, with the chunk size hack, the waterfall is just about OK at 192kHz
sample rate, but it is still a little jerky. Could we have a buffering
option to buffer the waterfall for some time before scrolling?

That wouldn’t really change anything.
The issue here is that fosphor processes things in batches. The
minimum size is 16 FFTs, which make 16 * 1024 samples.

One upcoming feature that would help here is the overlap. Basically
instead of advancing of 1024 samples in the input for each FFT, it
advances by a bit less so that each sample is processed in several
FFTs. But that’s just an idea for now, no implementation …

I’d like to be able to use this with my KX-3 perhaps as slowly as 48kHz :slight_smile:

Well fosphor was kind of designed for wideband signals :stuck_out_tongue:
Anything under 1 Msps may have some issues.

Cheers,

Sylvain

Hi Sylvain,

Nice work, I just gave it a spin here are my results;-

I hit the ‘clCreateFromGLTexture’ issue when compiling the benchmark
tool,
not only did I need to comment out the #define but I also needed to turn
off -Werror in the makefile.

I get 61msps with a GT9800 on a i7-950 @ 3.06G
Interestingly I find that the benchmark results are erratic for a while
and
then stabilise as shown below.

Mike

Selected device: GeForce 9800 GT
100 Frames time: 917843 us
BW estimated: 57.121752 Msps
100 Frames time: 1271217 us
BW estimated: 41.242998 Msps
100 Frames time: 3517962 us
BW estimated: 14.903174 Msps
100 Frames time: 2363734 us
BW estimated: 22.180499 Msps
100 Frames time: 2536602 us
BW estimated: 20.668911 Msps
100 Frames time: 861079 us
BW estimated: 60.887329 Msps
100 Frames time: 2259326 us
BW estimated: 23.205505 Msps
100 Frames time: 3436555 us
BW estimated: 15.256209 Msps
100 Frames time: 2754773 us
BW estimated: 19.031986 Msps
100 Frames time: 1651273 us
BW estimated: 31.750534 Msps
100 Frames time: 1034269 us
BW estimated: 50.691648 Msps
100 Frames time: 3286238 us
BW estimated: 15.954048 Msps
100 Frames time: 2911666 us
BW estimated: 18.006461 Msps
100 Frames time: 2699627 us
BW estimated: 19.420757 Msps
100 Frames time: 1940623 us
BW estimated: 27.016479 Msps
100 Frames time: 2265683 us
BW estimated: 23.140395 Msps
100 Frames time: 3601188 us
BW estimated: 14.558751 Msps
100 Frames time: 2266194 us
BW estimated: 23.135177 Msps
100 Frames time: 1710148 us
BW estimated: 30.657464 Msps
100 Frames time: 2172665 us
BW estimated: 24.131102 Msps
100 Frames time: 2452539 us
BW estimated: 21.377356 Msps
100 Frames time: 3127293 us
BW estimated: 16.764915 Msps
100 Frames time: 1545986 us
BW estimated: 33.912856 Msps
100 Frames time: 858462 us
BW estimated: 61.072942 Msps
100 Frames time: 859063 us
BW estimated: 61.030215 Msps
100 Frames time: 864266 us
BW estimated: 60.662805 Msps
100 Frames time: 863003 us
BW estimated: 60.751585 Msps
100 Frames time: 850487 us
BW estimated: 61.645622 Msps
100 Frames time: 854783 us
BW estimated: 61.335801 Msps
100 Frames time: 852875 us
BW estimated: 61.473018 Msps
100 Frames time: 858433 us
BW estimated: 61.075005 Msps
100 Frames time: 859781 us
BW estimated: 60.979249 Msps
100 Frames time: 850237 us
BW estimated: 61.663748 Msps
100 Frames time: 857009 us
BW estimated: 61.176487 Msps
100 Frames time: 854203 us
BW estimated: 61.377448 Msps
100 Frames time: 856246 us
BW estimated: 61.231001 Msps
100 Frames time: 854021 us
BW estimated: 61.390528 Msps
100 Frames time: 853289 us
BW estimated: 61.443192 Msps
100 Frames time: 858114 us
BW estimated: 61.097710 Msps
100 Frames time: 853439 us
BW estimated: 61.432393 Msps
100 Frames time: 857709 us
BW estimated: 61.126559 Msps
100 Frames time: 856152 us
BW estimated: 61.237724 Msps
100 Frames time: 856003 us
BW estimated: 61.248383 Msps

On 27/10/13 21:02, Alexandru C. wrote:

plot everything without loosing any information. You could do some
history buffering and averaging to get the look and feel of gr-fosphor
but it will not give you the same real time effect. It will be the
plain old “FFT averaging” concept that we know and you don’t even
need a GPU to do that.

Alex

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! 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.

Cheers,

Darren

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

Hi Sylvain,

I had a chance to try it ‘for real’ this afternoon displaying live
signals
from a BladeRF source.
Let me just say WOW that’s seriously impressive !!!

On my PC gr-fosphor handled the full 28MHz BladeRF BW beautifully.

I’ve used R&S’s FSVR and dare I say it, I reckon gr-phosphor is
possibly
better than the FSVR’s visualizer, and MUCH more affordable.

Once again nice work.

Mike

Hi Mike,

I hit the ‘clCreateFromGLTexture’ issue when compiling the benchmark tool,
not only did I need to comment out the #define but I also needed to turn off
-Werror in the makefile.

Yes. I have a potential fix, just need to test it doesn’t break OSX …

I get 61msps with a GT9800 on a i7-950 @ 3.06G
Interestingly I find that the benchmark results are erratic for a while and
then stabilise as shown below.

It might be the disk read. The software reads from a file and it might
take a couple of iterations before the OS realizes it should cache the
file and pre-fetch it.

Cheers,

Sylvain

Hi Mike,

On my PC gr-fosphor handled the full 28MHz BladeRF BW beautifully.

Happy to hear it works nicely for you :slight_smile:

I’ve used R&S’s FSVR and dare I say it, I reckon gr-phosphor is possibly
better than the FSVR’s visualizer, and MUCH more affordable.

Thanks !

I never had the chance to use those myself, but it’s nice to hear :slight_smile:

Cheers,

Sylvain

As of mid-day today, gr-fosphor is available via MacPorts for OSX < 10.9
users. It looks quite nice! Thanks Sylvain! - MLD