On 04/20/2018 12:01 PM, switchlanez via USRP-users wrote:
Hello,
An oddity regarding the RFNoC FIR Filter
block. fir_block_ctrl_impl.cpp writes tap values to the settings
registers with:
for (size_t i = 0; i < taps.size() - 1; i++) {
sr_write(SR_RELOAD, uint32_t(taps[i]));
}
which loops from 0 to taps.size() - 1. So if I define 41 taps from
GRC, it only takes taps indexed from 0 to 39 and never writes tap
index 40 (the 41st tap) to the settings register.
I sort of confirmed this by comparing the RFNoC FIR Filter output
against the GNU Radio Decimating FIR Filter (with Decimation=1) output
with the same 41 taps and same input fed to both. Output gets shifted
by half of a complex sample:
GR FIR:
1 + .997j
.994 + .991j
.988 + ...
RFNoC FIR:
0 + 1j
.997 +.994j
.991 + .988j
Which is an effect of a FIR filter that has an even number of taps (40
instead of 41).
So I modified the condition in the FIR driver file to write from 0
to taps.size() instead of taps.size()-1. Defined the 1st tap value to
be 1000 with all remaining 40 taps as 0s. Viewed output on a spec an
and saw nothing on output. Then moved the non-zero tap to the middle
(21st index) with leading 20 and trailing 20 taps being 0s and saw
the input fed to output. Now if I didn't modify the FIR driver file so
it stops at taps.size()-1 and writes only 40 of my 41 taps and set the
first tap to 1000 with 40 trailing zeros, I see input fed to output.
Was the taps.size()-1 check intentional?
Andrew
This definitely looks to me like a subtle bug in the "off by one" error
category.
One of our RFNoC devs will probably chime in at this point, and provide
an opinion....
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
