Or maybe the question should be like this: on which parameter to rely when making general work function, number of iput items or number of output items?
On Tue, Oct 22, 2013 at 2:20 PM, Nemanja Savic <vlasi...@gmail.com> wrote:
> 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ć
>
--
Nemanja Savić
<<image/png>>
<<image/png>>
<<image/png>>
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
