On Thu, Sep 2, 2010 at 08:39, Matt Ettus <m...@ettus.com> wrote: > I think you are missing the point here. There is no need to lie to the > program. If you are sending the FFT sink 25 MS/s, then tell it you are > sending it 25 MS/s. If you give it a different rate you will have all sorts > of other issues, like incorrect frequency scales on the display. If you want > to decrease the processor load then reduce the display update rate.
Just to elaborate a bit on this. The FFT sink in GNU Radio incorporates time domain frame decimation via the "keep one in n" block. The sample stream input to the sink is divided into frames at the configured FFT size (1024 samples by default in GRC). Then, only one frame per "n" is forwarded out to the FFT block, with "n" being calculated as the sample rate divided by the display update rate, then divided by the FFT size. In this way, we only burden the CPU with the windowing/FFT/log power calculation and graphics rendering as many times as is needed to refresh the display at the requested rate (which are still all using fast C++ code, not Python.) The "sample rate" parameter to the FFT sink is *not* a control input. You are simply telling the flowgraph the correct numerical time base of the input sample stream, to be used in the above calculation. The sample rate itself is usually established elsewhere; in this case, by the upstream USRP2 source block's decimation parameter. The "sample rate" parameter is also used to correctly display the units on the x-axis of the FFT window. Thus, the proper way to control the CPU usage of the FFT sink is to vary the update rate, as was mentioned by Matt and others. If in fact you are CPU-bound, then "lying" to the FFT sink by giving it an artificially high, incorrect sample rate will have the side effect of increasing the time frame decimation, thus lowering the CPU load, and appearing to "cure" the problem. But the x-axis units/scale will be incorrect and the update rate won't match the requested rate. (None of this speaks to whether your system's OpenGL/video card combination is properly functioning or whether it results in a performance improvement over the non-GL version of the sink.) Johnathan _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
