Re: [Discuss-gnuradio] ninput_items size problem

[N. Benes]

Hi,

Ramazan Çetin:
> I have digged some more.  This is how the connection is . OFDM MOD ->
> RATIONAL_RESAMPLER -> MY_BLOCK
> 
> Everytime, 64 items remains inside of rational_resampler block. When my
> block is called by scheduler, i have logged the below. I am waiting 1950
> sized input for consuming. But resampler sends output up to 1886 = 1950
> - 64. This is always same, i  have tried for different sized tagged
> streams. It always sends up to "packet_len" - 64.

<snip>

> Why rational_resampler behaves like this? Please, help.

I think it is the history property of the rational_resampler block:

>     void                                                                    
>     @IMPL_NAME@::forecast(int noutput_items, gr_vector_int 
> &ninput_items_required)
>     {                                                                       
>       int nreqd = std::max((unsigned)1, (int)((double) (noutput_items+1) * \
>                                         decimation() / interpolation()) + 
> history() - 1);
>       unsigned ninputs = ninput_items_required.size();                      
>       for(unsigned i = 0; i < ninputs; i++)                                 
>         ninput_items_required[i] = nreqd;                                   
>     } 

history depends on the number of filter taps:

>     void                                                                    
>     @IMPL_NAME@::install_taps(const std::vector<@TAP_TYPE@> &taps)          
>     {                                                                       
>       int nfilters = interpolation();                                       
>       int nt = taps.size() / nfilters;                                      
>                                                                             
>       assert(nt * nfilters == (int) taps.size());                           
>                                                                             
>       std::vector< std::vector <@TAP_TYPE@> > xtaps(nfilters);              
>                                                                             
>       for(int n = 0; n < nfilters; n++)                                     
>         xtaps[n].resize (nt);                                               
>                                                                             
>       for(int i = 0; i < (int)taps.size(); i++)                             
>         xtaps[i % nfilters][i / nfilters] = taps[i];                        
>                                                                             
>       for(int n = 0; n < nfilters; n++)                                     
>         d_firs[n]->set_taps(xtaps[n]);                                      
>                                                                             
>       set_history(nt);                                                      
>       d_updated = false;                                                    
>     } 

Documentation of the history property:
https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#a71548fe7804c9b932f9bb9d770931af1

> Assume block computes y_i = f(x_i, x_i-1, x_i-2, x_i-3...). History is the 
> number of x_i's that are examined to produce one y_i. This comes in handy for 
> FIR filters, where we use history to ensure that our input contains the 
> appropriate "history" for the filter. History should be equal to the number 
> of filter taps. First history samples (when there are no previous samples) 
> are initialized with zeroes. 

Cheers!