Hey Andrew,

The next line in fir_block_ctrl_impl.cpp sends the final tap:
sr_write(SR_RELOAD_TLAST, uint32_t(taps.back()));

The half a sample shift is odd though.

On Sat, Apr 21, 2018, 6:23 AM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

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

Reply via email to