discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] self.set_min_noutput_items() is not a valid pytho


From: Activecat
Subject: Re: [Discuss-gnuradio] self.set_min_noutput_items() is not a valid python command in gnuradio ?
Date: Sat, 8 Mar 2014 11:50:06 +0800

Dear Marcus,

This is the forecast, I believe it is correct.
    void quadrator_upconverter_impl::forecast (int noutput_items, gr_vector_int &ninput_items_required)
     {  ninput_items_required[0] = noutput_items / d_iFactor;  }

Note: d_iFactor is the instantaneous interpolation factor.

Currently this custom block often doesn't produce correct output when the instantaneous interpolation factor changes on the fly.  But it doesn't hange, thanks to the set_min_noutput_items().
Nevertheless this block produce correct output if the interpolation factor doesn't change on the fly.
Below is the set_samp_rate():

    void
    quadrator_upconverter_impl::set_samp_rate( float samp_rate )
    {
        d_samp_rate = samp_rate;
        if ( d_change_rate > 0.0 )
        {
            d_iFactor = d_samp_rate / d_change_rate;
            set_output_multiple( d_iFactor );
            set_min_noutput_items( d_iFactor );
        }
    }

Regards,
Activecat


On Sat, Mar 8, 2014 at 10:50 AM, Marcus Müller <address@hidden> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Activecat,

On 08.03.2014 03:34, Activecat wrote:
> Dear Marcus,
>
> 1). The line 299 of gnuradio-runtime/lib/block_executor.cc is:
> noutput_items = min_available_space(d, m->output_multiple(),
> m->min_noutput_items());
>
> If this line shows that set_min_output_items() works on the fly,
> does this also shows set_out_multiple() works on the fly? (just to
> confirm because I do not fully understand the source code).
>
If set_output_multiple just sets the gr::block's field that
gr::block::output_multiple() returns, then yes, it works for the next
iteration.

>
> 2). Regarding the returning 0 issue, let me share my experience of
> experiments. I am creating a custom interpolation block with its
> interpolation factor can be changed on the fly.  Hence it is
> inherited from gr::block.  It has one input port and one output
> port. During runtime, there will be no problem if the
> general_work() return 0, provided it consume a non-zero value. The
> flow graph may become unresponsive when the general_work() return 0
> and consume zero.
>
> My explanation: Says, the instantaneous interpolation factor is
> 800. The general_work() is now called with noutput_items=699 and
> ninput_items[0]=3. In this case the only correct thing that
> general_work() should do is to consume 0 and return 0.
>
> But later the general_work() will be repeatedly called again with
> the same arguments, i.e. noutput_items=699 and ninput_items[0]=3.
> In this case again the general_work() has to consume 0 and return
> 0.  This may repeat few thousand rounds, or infinite rounds. When
> this happens the flow graph becomes unresponsive (hang).
>
> That's why it is important to set_min_output_items() to the
> instantaneous interpolation factor (which is 800), if the
> set_output_multiple() doesn't work on the fly.
>
> If there is no better workaround, we have to stick to this trick at
> the moment.
>
Hm, I'd call this a bug, iff (!) your forecast does everything right.
Can you confirm?

> Regards, Activecat
>
Greetings,
Marcus
>
> On Fri, Mar 7, 2014 at 6:00 PM, Marcus Müller <address@hidden>
> wrote:
>
>> Hi Activecat,
>>
>> to answer question 1): grepping for "min_noutput_items" instantly
>> shows that in gnuradio-runtime/lib/block_executor.cc line 299,
>> your block's min_noutput_items() is called every iteration. If
>> there isn't enough space, the block thread sleeps until there is
>> more. So yes, it works on the fly.
>>
>> I remember there was something with returning 0, and I know that
>> producing 0 items used to mark a source as done, but this
>> mechanism was commented out about a year ago (l. 483ff, I think
>> for some good reason), but I can't remember that being an issue
>> for a non-source block; have you tried it and did you run into
>> problems?
>>
>> Greetings, Marcus
>>
>>
>>
>> On 03/07/2014 02:26 AM, Activecat wrote:
>>
>> Dear Sir,
>>
>> Let me explain the reason of why to use the function:
>> set_min_noutput_items().
>>
>> I am creating a custom interpolator block. Says, the
>> interpolation factor is 1000.  Hence it is important to call
>> set_output_multiple(1000).
>>
>> Meanwhile, for this block the interpolation factor depends on
>> Sample Rate (samp_rate). In this flow-graph the samp_rate could
>> be changed by the user during runtime. This means the
>> interpolation factor may change during runtime, and hence we need
>> to call set_output_multile() with different values during runtime
>> !
>>
>> The problem arisen when there is no guarantee that
>> set_output_multiple() will work if you change it on the fly.
>> (Refer
>> http://lists.gnu.org/archive/html/discuss-gnuradio/2010-11/msg00504.html)
>>
>>
>>
The workaround is to use set_min_noutput_items() if it work on the fly.
>> Says, after changing samp_rate, the new interpolation factor is
>> recalculated as 800. If the set_output_multiple(800) doesn't
>> work, the general_work() can still consume 1 input and produce
>> 800 output if the noutput_items is at least 800. This enables the
>> flow graph continue to work.
>>
>> If the noutput_items is less than 800, the only correct thing
>> the general_work() can do is to consume_each(0) and return 0.
>> This may be problematic and can cause unforeseen behavior. So it
>> is important to make sure the noutput_items is at least 800.
>> Hence I call: set_min_noutput_items(800)
>>
>> This means we can make use of set_min_noutput_items() as a
>> workaround, if set_output_multiple() doesn't change on the fly.
>>
>> The questions are: 1).  Can we use this to change setting on the
>> fly: set_min_noutput_items() 2).  Is there any better workaround
>> for this?
>>
>> Regards, Activecat
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Mar 6, 2014 at 11:36 PM, Tom Rondeau <address@hidden>
>> wrote:
>>
>>> On Thu, Mar 6, 2014 at 2:12 AM, Activecat <address@hidden>
>>> wrote:
>>>> Dear Sir,
>>>>
>>>> In c++ we have:  set_min_noutput_items() What is it
>>>> equivalent syntax in python ?
>>>>
>>>> I try this: self.set_min_noutput_items()
>>>>
>>>> Error message: AttributeError:
>>>> 'quadrator_upconverter_python1' object has no
>>> attribute
>>>> 'set_min_noutput_items'
>>>>
>>>> Note: The self.set_output_multiple() in python seems
>>>> accepted, is it
>>> functional
>>>> ..?
>>>>
>>>> Regards, Activecat
>>>
>>> Looks like when this feature was added, it didn't make it into
>>> the block.i swig file. I'll push a patch for this soon.
>>>
>>> But before you try and use this, be very careful. This is an
>>> advanced issue that's really only meant to be used if you a)
>>> really really need it and b) really really know what you are
>>> doing and why.
>>>
>>> Tom
>>>
>>
>>
>>
>> _______________________________________________ Discuss-gnuradio
>> mailing
>> address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>>
>>
_______________________________________________
>> Discuss-gnuradio mailing list address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTGoVpAAoJEBQ6EdjyzlHtXpAH/3rMFjvBQxTzxwPuwb7Vfr2s
afzIB7c0SR16EmbQ7XXwGRc413vJrYz9HSP+mHW+d14EId0tJgbD70M0NjA2rIfO
4qJA+OyKxgG/kchpeqH8thHzS5eE8jQxPhAYuE7dgYOK8pD9XW/z6Tnj7xOr7UVP
Xh8nWoM9HXJXq4xagjkXOqsIW8hxAe7JRNuAx7Jrtbe1g1cyjTfROa2KNRyZbxoa
V8V4UeYBt0ab3LGqCwUGB1uMefoGn2Walnb9rcW38jEaLEQ+l33ZgvD3kDte/Jju
78aglgn15tXU0VMbX5ON9ZkLm4lZCx1TQ2Wyf/PxnNhKow9kSfSaoJYnSZ77U0U=
=638A
-----END PGP SIGNATURE-----

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


reply via email to

[Prev in Thread] Current Thread [Next in Thread]