Thanks. Much appreciated. Rob On Mon, Nov 19, 2018 at 2:54 PM Brian Padalino <bpadal...@gmail.com> wrote:
> 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
