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
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
