On Mon, Mar 9, 2009 at 3:45 AM, Jens Elsner <jpels...@1c3.de> wrote: > Gives a good practical estimate. Code for GNU Radio is here: > > https://www.cgran.org/wiki/SpecEst
Good to see CGRAN being put to good use! > Integrating the FFT bins is just fine, but you probably loose frequency > resolution that way (if that doesn't matter, just leave it). As per the original question, I am wondering what the reason for taking the time to do a 4M point FFT and then compressing the frequency information? I would think you're just throwing away frequency resolution at that point and, inherently, wasting CPU cycles. So - back to Marcus - what is the overall goal of "compressing" your FFT data? I have a feeling it's for visualization of your data as opposed to actually performing math or computational analysis, right? If that is the case, I think you would want to come up with a clever way of visually compressing the original data without compromising the frequency resolution you're computing. I'm not sure if anyone has done this before, but you could possibly overlay your lines on top of each other - and use colors to determine how many of the bins overlap - this way if you have a spike in one bin, it will be instantly recognizable and "zooming in" could reveal exactly which bin it was. Moreover, if all the bins have a large frequency content to them, that, too, would be instant recognizable as a wider bandwidth signal as opposed to just a single Hz spike. I suppose this would constitute a visual averaging without computationally losing the frequency resolution you've worked so hard to achieve. If it is not the case that you want to visualize the data, and, indeed, you just need to clump your bins together - please disregard this entire e-mail and idea. Brian _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
