Hello guys again! Based on Martins suggestion and Marucs' explanation I copied some principles from sync_interpolator and situation looks much better. I used function set_output_multiple and set_relative rate and now the outcome of calling forecast function is much better. For example, for symbol rate of 10k and sampling rate of 500k i get following:
ninput_items_required 8, noutput_items 4000
ninput_items_required 4, noutput_items 2000
ninput_items_required 2, noutput_items 1000
ninput_items_required 1, noutput_items 500
ninput_items_required 8, noutput_items 4000
And as u can see it always offers integer multiple of samp_rate/sym_rate.
The problem comes now when i run the flowgraph with vector source that
repeats the pattern. After calling forecast program executes work function
but it provides me 32768 input samples which is of course silly:
work function, ninput: 32768, noutput: 4000
I don't really get what might be a problem, cause when vecotr source
doesn't repeat the patern everything is fine.
Thank you and best
Nemanja
On Mon, Oct 21, 2013 at 4:36 PM, Marcus Müller <mar...@hostalia.de> wrote:
> Hm, I don't know why this should really happen before your source's work
> function is called.
> But basically, maybe this is part of GNU Radio trying to figure out how to
> assign buffers; I haven't dived very deep into that aspect of the runtime.
> However, since your forecast told GR that you're able to produce samples
> without input, I could imagine that your work gets scheduled simultaneously
> with those of your sources.
> To circumvent that, just don't lie ;) and tell the scheduler that you need
> input to produce output.
>
> Greetings,
> Marcus
>
> On 20.10.2013 13:11, Nemanja Savic wrote:
>
> Thank you Marcus very much. I would like to ask some more questions.
> For me it looks like the problem is at very begining when source has not
> produced any output, and it looks like forecast of my block is called
> before the work functino of the source? How should one cope with this? By
> checking if required number of input samples is zero and solving that case?
> How is that ensured for interpolator.
>
> Thanks and kind regards,
> Nemanja
>
>
> On Sat, Oct 19, 2013 at 10:35 AM, Marcus Müller <mar...@hostalia.de>wrote:
>
>> Hi Nemanja,
>>
>> Considering following flowgraph, assume your block is A, and assume all
>> blocks work with the same itemsize.
>> [image: $\fbox{\textrm C}\rightarrow\fbox{\textrm
>> B}\rightarrow\fbox{\text{\textbf{A}}}\rightarrow\fbox{\textrm D}$]
>>
>> good question, but basically, when running, when A is done with a run of
>> work, it's thread notifies blocks "upstream" (B in this case) that it has
>> consumed [image: N] input items, making that space available for new
>> output; GNU radio then calls forecast of B with a noutput_items [image:
>> M_i = floor( 2 ** ( floor(log_2 N) - i) <= N, i in {0,1,...,floor(log_2 N)
>> +1}] to fill that space. However, if the upstream block B needs more
>> input items than C has provided, GNU Radio will repeatedly reduce the
>> number of samples it asks for until B needs less or equal samples as C has
>> produced.
>>
>> In your case, this only happens for 0 output items; thus your
>> general_work gets called with 0 input items, as Martin already stated.
>> So what happens then? Since A has not provided any more output items for
>> the blocks downstream, D can't do anything that it has not already been
>> doing. The downstream part of the flowgraph stalls. Upstream part: Since
>> GNU Radio has not been able to supply you with more than 0 input items, we
>> can assume that the upstream part of the flowgraph is stuck, or done.
>> Therefore, execution ends here.
>>
>> Greetings,
>> Marcus
>>
>>
>>
>> On 10/18/2013 03:19 PM, Nemanja Savic wrote:
>>
>> Thank you Martin, I will try with the sync_decimator, but it is also
>> important for me to unterstand what's happening here.
>> So, I have vector source -> throttle -> fsk_modulator -> scope sink.
>> Vector source generates 8 symbols. From where scheduler starts, from
>> source or from the sink? And why it didn't stop for any value before 0?
>> What should I add into general block to avoid this?
>>
>> Thank you
>>
>>
>> On Fri, Oct 18, 2013 at 2:59 PM, Martin Braun (CEL) <martin.br...@kit.edu
>> > wrote:
>>
>>> On Fri, Oct 18, 2013 at 02:32:48PM +0200, Nemanja Savic wrote:
>>> > The body of my forecast function is:
>>> >
>>> > ninput_items_required[0] = noutput_items * d_sym_rate /
>>> d_sampling_freq;
>>> > printf("ninput_items_required %d, noutput_items %d\n",
>>> ninput_items_required
>>> > [0], noutput_items);
>>>
>>> If d_sym_rate and d_sampling_freq are integers, integer division will
>>> cause ninput_items_required to be zero for small values of
>>> noutput_items.
>>>
>>> > when i run execution, the output is following:
>>> >
>>> > ninput_items_required 8, noutput_items 4096
>>> > ninput_items_required 4, noutput_items 2048
>>> > ninput_items_required 2, noutput_items 1024
>>> > ninput_items_required 1, noutput_items 512
>>> > ninput_items_required 0, noutput_items 256
>>> > ninput: 0, produced: 0
>>> >
>>> > The last line of the output comes from general_work function and
>>> prints number
>>> > of input items and number of produced output samples.
>>> >
>>> > Can somebody explain me why forecast is called 5 times, till number of
>>> input
>>> > items reach 0, and after that nothing is possible in work function,
>>> cause it
>>> > won't enter the loop since ninput_items = 0;
>>>
>>> Depending on the state of the buffers, the scheduler calls forecast()
>>> until it finds a value of ninput_items_required that works (it tries to
>>> process as much as possible). In your case, there is probably some
>>> situation where the input buffer is not full.
>>> The way you've set up forecast(), the scheduler will eventually find out
>>> that it doesn't need any items to produce at least 256 output items. So
>>> it calls work() with no input data, expecting 256 output items.
>>> But since you can't produce anything without input, nothing happens.
>>>
>>> It seems like what you want is a sync_decimator, got a gr::block. This
>>> means you set relative_rate in the ctor and don't need to handle all of
>>> this
>>> yourself. Make sure you don't set relative_rate to zero, again!
>>> In a sync_decimator, you won't need forecast() at all and your work
>>> function is much simpler. The scheduler will also never try to call a
>>> sycn_decimator w/o input.
>>>
>>> MB
>>>
>>> --
>>> Karlsruhe Institute of Technology (KIT)
>>> Communications Engineering Lab (CEL)
>>>
>>> Dipl.-Ing. Martin Braun
>>> Research Associate
>>>
>>> Kaiserstraße 12
>>> Building 05.01
>>> 76131 Karlsruhe
>>>
>>> Phone: +49 721 608-43790 <%2B49%20721%20608-43790>
>>> Fax: +49 721 608-46071 <%2B49%20721%20608-46071>
>>> www.cel.kit.edu
>>>
>>> KIT -- University of the State of Baden-Württemberg and
>>> National Laboratory of the Helmholtz Association
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>> --
>> Nemanja Savić
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Nemanja Savić
>
>
> _______________________________________________
> Discuss-gnuradio mailing
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
Nemanja Savić
<<image/png>>
<<image/png>>
<<image/png>>
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
