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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
