That sounds like a reasonable argument to me. I thought perhaps something more subtle was happening. I'll just override it for now. Thanks, Glenn
On Thu, Apr 30, 2009 at 9:02 AM, Aaron Parsons <[email protected] > wrote: > I'm not sure that MaxCoeffNum works even in theory. If you cannot > resolve the coefficients to the scale on which they vary between FFT > bins, it seems to me you fundamentally cannot tell the difference > between 2 frequencies that are separated using this coefficient. > Although there may be other tricks to save resources (like only > storing the LSBs of fine-grain coefficients), I don't believe that > just capping the number of coefficients can work. Unless there is > evidence to the contrary, I'd suggest removing the MaxCoeffNum > functionality. > > On Thu, Apr 30, 2009 at 11:52 AM, G Jones <[email protected]> wrote: > > Hello, > > I am finding that FFTs with sizes <= 2^11 work fine, but >2^11 are > producing > > invalid output. Roughly, a CW complex tone is appearing at two > frequencies > > instead of just at one. I can reproduce this in simulation and in the > lab. > > Andrew suggested this may be due to the MaxCoeffNum, and I now remember I > > ran into this problem before but never got around to solving it. I > > understand the idea behind MaxCoeffNum, that for large FFTs the > differences > > between twiddle factors become small enough that they can be neglected. > > However, as it is currently implemented, it does not seem to work. I am > > using the green 7.1 blocks. Has anyone successfully used this feature > (i.e. > > made a single input biplex FFT of length greater than MaxCoeffNum, 2^11 > by > > default)? > > Thanks, > > Glenn > > > > > > -- > Aaron Parsons > > 510-406-4322 (cell) > 787-878-2612 x329 (arecibo office) > 787-721-3991 (home) >
