Hey there,
A pretty useful test to see what's going on in hardware domain would be
like this:
File source => FIR => FIFO => File sink
In your file source, I'd suggest making a file that's all complex zeros
except for one sample that is set to "1" (or 1+1j). Running an impulse
(Dirac Delta) through a FIR filter will output each FIR tap, one at a time.
Just look at the output of the file sink and confirm all the taps have been
programmed correctly!
Hope this helps,
EJ
On Sat, Apr 21, 2018, 3:57 AM switchlanez via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Oh yeah... I actually knew that! Noticed that line several months ago but
> overlooked it this time because I was so determined to find the culprit for
> something else (Function Probe polling a file of tap values to rewrite taps
> to noc FIR block causes splashing across spectrum). Might post a new topic
> on that with video if we can't figure it out.
>
> That half sample shift doesn't happen when we run noc_block_fir_filter
> against its SystemVerilog testbench. Hoping the shift only happens if
> datastream crosses from hardware to host domain which would be fine since
> our application keeps the datastream on hardware. Just not sure how to
> verify no half sample shift is happening in the hardware domain.
>
> On Fri, Apr 20, 2018 at 3:56 PM, Jon Pendlum via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> 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
>>
>>
> _______________________________________________
> 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
