On Sun, Oct 27, 2013 at 8:45 PM, Darren Long <darren.l...@mac.com> wrote: > > On 27/10/13 17:46, Sylvain Munaut wrote: >> >> Since the whole idea being fosphor is to never just "drop" data, to slow >> down the waterfall, multiple FFT results must be "aggregated" with either >> min/max/avg functions and that's a bit more tricky to implement. Cheers, >> Sylvain > > > 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? > > I'd like to be able to use this with my KX-3 perhaps as slowly as 48kHz :)
Daren, Do what exactly? The purpose with gr-fosphor is to visualize more data that what is possible with snapshot-type FFT. This ensures that no data is lost between to screen updates. But for such low bandwidth you can just 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
