On Mon, Nov 19, 2018 at 2:47 PM Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote:
> Hi, > Can anyone offer advice regarding the RFNoC FFT scaling argument? It is > not clear to me if this argument should always be left alone or if it > should be adjusted as needed by the user for various signal types and FFT > lengths. I was expecting the latter, but my experimentation today gives me > no confidence in doing so. > > The default value is 1706. I have been trying other values with bizarre > results. Using the example "rfnoc_fft" that comes in the gr-ettus/examples > folder, I get seemingly normal results with this set to 1706. But, if I > change it to 1705, I get very strange behavior. And, look out if you > choose 2048. See attached. In all cases, the signal source was a 125kHz > exponential with Gaussian noise (which is the default behavior of this GR > flowgraph). > Look at the value in hex not decimal. It's telling the FFT algorithm which stages to prune back the output. 1706 = 0x6aa = 0b011010101010. If you run with all 0's, you risk overflowing internally. An overflow error comes out, but I am not sure it's captured really well with the FFT. If you want to be ultra conservative, then scale back every stage and you won't get the integration gain that the FFT provides on the block size. It definitely does depend on the FFT length, but it seems like every other stage with a radix-4 works decently well? It's the SCALE_SCH parameter in the IP block: https://www.xilinx.com/support/documentation/ip_documentation/xfft/v9_0/pg109-xfft.pdf Hope this helps. Good luck! Brian
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
