[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] ninput_items size problem
From: |
N. Benes |
Subject: |
Re: [Discuss-gnuradio] ninput_items size problem |
Date: |
Tue, 23 Jul 2019 09:07:00 +0000 |
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!