Quantcast

self.set_min_noutput_items() is not a valid python command in gnuradio ?

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

self.set_min_noutput_items() is not a valid python command in gnuradio ?

activecat
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

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

Tom Rondeau-2
On Thu, Mar 6, 2014 at 2:12 AM, Activecat <[hidden email]> 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 list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

activecat
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.

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 <[hidden email]> wrote:
On Thu, Mar 6, 2014 at 2:12 AM, Activecat <[hidden email]> 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 list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

Marcus Müller
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.

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 <[hidden email]> wrote:
On Thu, Mar 6, 2014 at 2:12 AM, Activecat <[hidden email]> 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 list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

activecat
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).


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.

Regards,
Activecat


On Fri, Mar 7, 2014 at 6:00 PM, Marcus Müller <[hidden email]> 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.

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 <[hidden email]> wrote:
On Thu, Mar 6, 2014 at 2:12 AM, Activecat <[hidden email]> 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 list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

Marcus Müller
-----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 <[hidden email]>
> 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 <[hidden email]>
>> wrote:
>>
>>> On Thu, Mar 6, 2014 at 2:12 AM, Activecat <[hidden email]>
>>> 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
>> [hidden email]://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>>
>>
_______________________________________________

>> Discuss-gnuradio mailing list [hidden email]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list [hidden email]
> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

activecat
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
>> wrote:
>>
>>> On Thu, Mar 6, 2014 at 2:12 AM, Activecat <[hidden email]>
>>> 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
>> [hidden email]://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>>
>>
_______________________________________________
>> Discuss-gnuradio mailing list [hidden email]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list [hidden email]
> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

Marcus Müller
Hi activecat,
The scheduler might be confused if he asked for less than iFactor samples, because then your forecast tells him you need 0 input to produce that... The joys of Integer division
Can you modify it so that it always demands at least 1 input?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

Marcus Müller
In reply to this post by activecat
Hi activecat,
The scheduler might be confused if he asked for less than iFactor samples, because then your forecast tells him you need 0 input to produce that... The joys of Integer division
Can you modify it so that it always demands at least 1 input?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

Marcus Müller
In reply to this post by activecat
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi activecat,
The scheduler might be confused if he asked for less than iFactor samples, because then your forecast tells him you need 0 input to produce that... Integer division


- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.9

iQFABAEBCAAqBQJTGuX2IxxNYXJjdXMgTfxsbGVyIDxtYXJjdXNAaG9zdGFsaWEu
ZGU+AAoJEBKNLRrpJvfolIgH+gIhLw9qsywTNzWsP5cKpbWI6I0o15H8NdjRTQp4
3q1Qar28b5m2S3esFnmk1JuKAqILvJQ+lxECFpnz6uY4cViDfdKHul+HW6YAnskA
PS5M+SI7qhTRYrkbFhF2mrtUeuBrCJm1KQryl2rNk+rYGELk6abLjNi+wzFuS7b5
/x4MM0Gs7EhbHjaxTrC8usARPYrBw68hjfKPmUaZrw1kNwXtAgMCMUBoZ5vUIjzk
DRU68DdjA8sqRMo+P4MBAeCrk9HndQ3Mu6kL+fff+t3vyuaGCBblYqSMPT8MWY5R
0xezgCd0P5KAkl3wlDjL8pa/Il3N+sKq90KFMS+QTr7BBZ8=
=B9Vj
-----END PGP SIGNATURE-----


_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

activecat
In reply to this post by Marcus Müller
Dear Marcus,

Sure, I have changed it, as follows:

    void quadrator_upconverter_impl::forecast (int noutput_items, gr_vector_int &ninput_items_required)
      { ninput_items_required[0] = std::min( 1, noutput_items / d_iFactor );  }

This tested has no effect to the flow graph; the block still doesn't produce correct output when d_iFactor changes on the fly.

BTW I thought it is redundant to do this change, because as long as set_min_noutput_items(d_iFactor) works on the fly, the scheduler will not ask for less than iFactor samples. Correct..?

Regards,
Activecat



On Sat, Mar 8, 2014 at 5:41 PM, Marcus Müller <[hidden email]> wrote:
Hi activecat,
The scheduler might be confused if he asked for less than iFactor samples, because then your forecast tells him you need 0 input to produce that... The joys of Integer division
Can you modify it so that it always demands at least 1 input?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

Marcus Müller
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Activecat,

your std::min should be a std::max :) would you try with that?

On 08.03.2014 12:30, Activecat wrote:

> BTW I thought it is redundant to do this change, because as long
> as set_min_noutput_items(d_iFactor) works on the fly, the scheduler
> will not ask for less than iFactor samples. Correct..?
Yes, in that case the block_executor iteration should return the magic
value "BLKD_OUT", which will tell the thread scheduler to sleep until
there is more output space available. (refer to min_available_space, l.70)
However, what you're seeing is a repeated call of your work, so
*something* goes wrong here :/
What you could try is do some output of the parameters that forecast
and work are called with, and what they returned.
Otherwise, I'm kind of at the end of my ideas how to pinpoint the
problem...

Greetings,
Marcus

>
> Regards, Activecat
>
>
>
> On Sat, Mar 8, 2014 at 5:41 PM, Marcus Müller <[hidden email]>
> wrote:
>
>> Hi activecat, The scheduler might be confused if he asked for
>> less than iFactor samples, because then your forecast tells him
>> you need 0 input to produce that... The joys of Integer division
>> Can you modify it so that it always demands at least 1 input?
>>
>> -- Sent from my Android device with K-9 Mail. Please excuse my
>> brevity.
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTGwJWAAoJEBQ6EdjyzlHtaEUIAIU/xwUUg4dUfzpv3cvCBTyM
gT8u9uMw/9vFRXsDRnj/QZvlgkc2EtW1vwyVrjgh165Jm9Vl8AY9SIKlPryOfFMK
7fg8G5hNuXm8wIIL2iCj15Kom9qp+Gh9YK8ULD/ElHh/z2zkSTftsp647DbNcget
miKrjPfEIkN6JQdz5xpEWUvgblGjHUKclI100A2kGajPAcY7YWZczAZ0LxIy/rKZ
CjOpRsHRgIa/hd1WvC5PiaqtFJxoyGHK3weFgPZAAi6IYL2rH5LSmrFTeGQrYgYH
CvXEq8GjbPLwUEv8ubyUWNv95h0fvDJUhMchVUY17v/ZnHdZqE8Bkd6VNELZO3c=
=GUvF
-----END PGP SIGNATURE-----

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

activecat
Dear Marcus,

Thanks for pointing out, I've corrected it to std::max.
It still doesn't seem to produce correct output when the d_iFactor changes on the fly.

BTW this flow graph consists of other built-in blocks like Low Pass Filter, Signal Source etc, whose outputs also depends on the instantaneous Sample Rate (samp_rate). If one of these built-in blocks doesn't work well when samp_rate changes on the fly, then that could cause the flow graph to produce wrong result too.

My main concern is whether set_output_multiple() and set_min_noutput_items() works on the fly in general.
As your answer is yes to both, then I think that is good enough for this thread.

The general_work() is called repeatedly and problematically only if it return 0 and consume 0.  With the set_min_noutput_items() works on the fly, this problem doesn't happen anymore.  Now the problem is the incorrect output when the d_iFactor changes on the fly.

Meanwhile, as you had advised, I had tried to see the parameters that forecast() and general_work() are called with. Refer below verbose message.
When the flow chart started, the initial values are samp_rate=32k, change_rate=64; hence d_iFactor = 32k/64 = 500.
At line 24 the samp_rate is changed to 64k on the fly by the user. So now d_iFactor = 64k/64 = 1000.
Every parameters and return values seem to be correct, but the flow graph output becomes wrong after line 24.

1  forecast():  ninput_items_required[0] is set to 16   while noutput_items is 8000 ,  d_iFactor is 500
2   general_work():  consumed 16 at port 0,  noutput_items is 8000 ,  d_iFactor is 500
3  forecast():  ninput_items_required[0] is set to 16   while noutput_items is 8000 ,  d_iFactor is 500
4   general_work():  consumed 16 at port 0,  noutput_items is 8000 ,  d_iFactor is 500
5  forecast():  ninput_items_required[0] is set to 16   while noutput_items is 8000 ,  d_iFactor is 500
6   general_work():  consumed 16 at port 0,  noutput_items is 8000 ,  d_iFactor is 500
7  forecast():  ninput_items_required[0] is set to 16   while noutput_items is 8000 ,  d_iFactor is 500
8   general_work():  consumed 16 at port 0,  noutput_items is 8000 ,  d_iFactor is 500
9  forecast():  ninput_items_required[0] is set to 16   while noutput_items is 8000 ,  d_iFactor is 500
10   general_work():  consumed 16 at port 0,  noutput_items is 8000 ,  d_iFactor is 500
11  forecast():  ninput_items_required[0] is set to 16   while noutput_items is 8000 ,  d_iFactor is 500
12   general_work():  consumed 16 at port 0,  noutput_items is 8000 ,  d_iFactor is 500
13  forecast():  ninput_items_required[0] is set to 16   while noutput_items is 8000 ,  d_iFactor is 500
14   general_work():  consumed 16 at port 0,  noutput_items is 8000 ,  d_iFactor is 500
15  forecast():  ninput_items_required[0] is set to 16   while noutput_items is 8000 ,  d_iFactor is 500
16   general_work():  consumed 16 at port 0,  noutput_items is 8000 ,  d_iFactor is 500
17  forecast():  ninput_items_required[0] is set to 16   while noutput_items is 8000 ,  d_iFactor is 500
18   general_work():  consumed 16 at port 0,  noutput_items is 8000 ,  d_iFactor is 500
19  forecast():  ninput_items_required[0] is set to 16   while noutput_items is 8000 ,  d_iFactor is 500
20   general_work():  consumed 16 at port 0,  noutput_items is 8000 ,  d_iFactor is 500
21  forecast():  ninput_items_required[0] is set to 16   while noutput_items is 8000 ,  d_iFactor is 500
22   general_work():  consumed 16 at port 0,  noutput_items is 8000 ,  d_iFactor is 500
23  forecast():  ninput_items_required[0] is set to 16   while noutput_items is 8000 ,  d_iFactor is 500
24   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
25  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
26   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
27  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
28   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
29  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
30   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
31  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
32  forecast():  ninput_items_required[0] is set to 4   while noutput_items is 4000 ,  d_iFactor is 1000
33  forecast():  ninput_items_required[0] is set to 2   while noutput_items is 2000 ,  d_iFactor is 1000
34  forecast():  ninput_items_required[0] is set to 1   while noutput_items is 1000 ,  d_iFactor is 1000
35  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
36  forecast():  ninput_items_required[0] is set to 4   while noutput_items is 4000 ,  d_iFactor is 1000
37  forecast():  ninput_items_required[0] is set to 2   while noutput_items is 2000 ,  d_iFactor is 1000
38  forecast():  ninput_items_required[0] is set to 1   while noutput_items is 1000 ,  d_iFactor is 1000
39  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
40   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
41  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
42   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
43  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
44   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
45  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
46   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
47  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
48   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
49  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
50   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
51  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
52   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
53  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
54   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
55  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
56   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
57  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
58   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
59  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
60   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
61  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
62   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
63  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
64   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
65  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
66   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
67  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
68   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
69  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
70   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
71  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
72   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
73  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
74   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
75  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000
76   general_work():  consumed 8 at port 0,  noutput_items is 8000 ,  d_iFactor is 1000
77  forecast():  ninput_items_required[0] is set to 8   while noutput_items is 8000 ,  d_iFactor is 1000

>>> Done


On Sat, Mar 8, 2014 at 7:43 PM, Marcus Müller <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Activecat,

your std::min should be a std::max :) would you try with that?

On 08.03.2014 12:30, Activecat wrote:

> BTW I thought it is redundant to do this change, because as long
> as set_min_noutput_items(d_iFactor) works on the fly, the scheduler
> will not ask for less than iFactor samples. Correct..?
Yes, in that case the block_executor iteration should return the magic
value "BLKD_OUT", which will tell the thread scheduler to sleep until
there is more output space available. (refer to min_available_space, l.70)
However, what you're seeing is a repeated call of your work, so
*something* goes wrong here :/
What you could try is do some output of the parameters that forecast
and work are called with, and what they returned.
Otherwise, I'm kind of at the end of my ideas how to pinpoint the
problem...

Greetings,
Marcus

>
> Regards, Activecat
>
>
>
> On Sat, Mar 8, 2014 at 5:41 PM, Marcus Müller <[hidden email]>
> wrote:
>
>> Hi activecat, The scheduler might be confused if he asked for
>> less than iFactor samples, because then your forecast tells him
>> you need 0 input to produce that... The joys of Integer division
>> Can you modify it so that it always demands at least 1 input?
>>
>> -- Sent from my Android device with K-9 Mail. Please excuse my
>> brevity.
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTGwJWAAoJEBQ6EdjyzlHtaEUIAIU/xwUUg4dUfzpv3cvCBTyM
gT8u9uMw/9vFRXsDRnj/QZvlgkc2EtW1vwyVrjgh165Jm9Vl8AY9SIKlPryOfFMK
7fg8G5hNuXm8wIIL2iCj15Kom9qp+Gh9YK8ULD/ElHh/z2zkSTftsp647DbNcget
miKrjPfEIkN6JQdz5xpEWUvgblGjHUKclI100A2kGajPAcY7YWZczAZ0LxIy/rKZ
CjOpRsHRgIa/hd1WvC5PiaqtFJxoyGHK3weFgPZAAi6IYL2rH5LSmrFTeGQrYgYH
CvXEq8GjbPLwUEv8ubyUWNv95h0fvDJUhMchVUY17v/ZnHdZqE8Bkd6VNELZO3c=
=GUvF
-----END PGP SIGNATURE-----

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

activecat
In reply to this post by Marcus Müller
Dear Marcus,

> 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?

This problem happens because general_work() is called with noutput_items  equals to a value less than d_iFactor.
So we need to do something to handle the noutput_items, not the ninput_items[].

Hence, the issue is not with the forecast() because forecast() only affects ninput_items[].

Note:
d_iFactor is the instantaneous interpolation factor of this custom block.

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

Marcus Müller
In reply to this post by activecat
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Activecat,

On 08.03.2014 13:54, Activecat wrote:

> Dear Marcus,
>
> Thanks for pointing out, I've corrected it to std::max. It still
> doesn't seem to produce correct output when the d_iFactor changes
> on the fly.
>
> BTW this flow graph consists of other built-in blocks like Low Pass
> Filter, Signal Source etc, whose outputs also depends on the
> instantaneous Sample Rate (samp_rate). If one of these built-in
> blocks doesn't work well when samp_rate changes on the fly, then
> that could cause the flow graph to produce wrong result too.
>
But, well, these blocks don't change output ratios based on sample_rate..

> My main concern is whether set_output_multiple() and
> set_min_noutput_items() works on the fly in general. As your answer
> is yes to both, then I think that is good enough for this thread.
:)

>
> The general_work() is called repeatedly and problematically only if
> it return 0 and consume 0.  With the set_min_noutput_items() works
> on the fly, this problem doesn't happen anymore.  Now the problem
> is the incorrect output when the d_iFactor changes on the fly.
>
> Meanwhile, as you had advised, I had tried to see the parameters
> that forecast() and general_work() are called with. Refer below
> verbose message. When the flow chart started, the initial values
> are samp_rate=32k, change_rate=64; hence d_iFactor = 32k/64 = 500.
> At line 24 the samp_rate is changed to 64k on the fly by the user.
> So now d_iFactor = 64k/64 = 1000. Every parameters and return
> values seem to be correct, but the flow graph output becomes wrong
> after line 24.
Wrong in which way?

Greetings,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTGxZlAAoJEBQ6EdjyzlHtzVkH/2yu6GyvUr2aevwric3ER7iS
kuZ0drhy9C1PweSqPeBBPSRdOxqX0nDsYD9O+f+k03bGLyfidwLQ8jlt0J9wX9Vv
82yvxGkEVf3OShAUB44uPFEUOvbAYef697jjP0YmDSrbGc/XQ7+FpngJmOqhqBpe
AsiqmKpLaYJ9rvKsButGaj6mnT98mnWQt2+GTk5bTzZ0w9O1NVKpo6odaFVMp+hM
+OjW7w+vV5YfyRw3OhhyrjoXCMOtw1oXz4aUbHuKqXfFF12GJYA3mrElKuELK7E+
fnC24SD8rrpytdjTTwj+sAoebJhxDymb8oCJ2UwR7f13CgmWrmat+p0J9KS6aUY=
=FeQj
-----END PGP SIGNATURE-----

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

activecat
Dear Marcus,

> Meanwhile, as you had advised, I had tried to see the parameters
> that forecast() and general_work() are called with. Refer below
> verbose message. When the flow chart started, the initial values
> are samp_rate=32k, change_rate=64; hence d_iFactor = 32k/64 = 500.
> At line 24 the samp_rate is changed to 64k on the fly by the user.
> So now d_iFactor = 64k/64 = 1000. Every parameters and return
> values seem to be correct, but the flow graph output becomes wrong
> after line 24.
Wrong in which way?


Refer below, row_002 to row_010 are correct outputs.
At row_011, the samp_rate was changed from 64k to 32k, by using WX GUI Slider. This were wrong outputs.

Executing: "/home/sgku/gnuradio/flow_graphs/top_block.py"
Using Volk machine: ssse3_32_orc
Integer1   [row_001]  =    3,   22,   33,   44,   55,   211,   222,   233,   244,   255,   0
Integer1   [row_002]  =    11,   22,   33,   44,   55,   211,   222,   233,   244,   255,   0
Integer1   [row_003]  =    11,   22,   33,   44,   55,   211,   222,   233,   244,   255,   0
Integer1   [row_004]  =    11,   22,   33,   44,   55,   211,   222,   233,   244,   255,   0
Integer1   [row_005]  =    11,   22,   33,   44,   55,   211,   222,   233,   244,   255,   0
Integer1   [row_006]  =    11,   22,   33,   44,   55,   211,   222,   233,   244,   255,   0
Integer1   [row_007]  =    11,   22,   33,   44,   55,   211,   222,   233,   244,   255,   0
Integer1   [row_008]  =    11,   22,   33,   44,   55,   211,   222,   233,   244,   255,   0
Integer1   [row_009]  =    11,   22,   33,   44,   55,   211,   222,   233,   244,   255,   0
Integer1   [row_010]  =    11,   22,   33,   44,   55,   211,   222,   233,   244,   255,   0
Integer1   [row_011]  =    11,   22,   33,   700,   23,   863,   15,   1530,   165,   0
Integer1   [row_012]  =    65535,   3,   1,   3,   1646,   145,   73,   71,   124,   82,   85,   170,   173,   131,   184,   182,   145,   73,   71,   124,   82,   85,   170,   173,   131,   184,   182,   145,   73,   71,   124,   82,   85,   170,   173,   131,   184,   182,   145,   73,   71,   124,   82,   85,   170,   173,   131,   184,   182,   145,   73,   71,   124,   82,   85,   170,   173,   131,   184,   182,   145,   73,   71,   124,   82,   85,   170,   173,   131,   184,   182,   145,   73,   71,   124,   82,   85,   170,   173,   131,   184,   182,   145,   73,   71,   124,   82,   85,   170,   173,   131,   184,   182,   145,   73,   71,   124,   82,   85,   170,   173,   131,   184,   182,   145,   73,   71,   124,   82,   85,   170,   173,   131,   184,   182,   145,   73,   71,   124,   82,   85,   170,   173,   131,   184,   182,   145,   73,   71,   124,   82,   85,   170,   173,   131,   184,   182,   145,   73,   71,   124,   82,   85,   170,   173,   131,   184,   182,   145,   73,   71,   124,   82,   85,   170,   173,   131,   184,   182,   145,   73,  
>>> Done

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

Marcus Müller
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Activecat,

sorry, I neither know your application nor what your work does, so the
question was more like "does GNU Radio do something wrong or is it
just the output of your block"; I don't understand any of your output ;)

- From what I see, there is 65535==0b1111111111111111 in your output;
this indicates some arithmetic error in your work.
However, this leaves the scope of this thread, so I suggest we close
the discussion here.

Greetings,
Marcus

On 08.03.2014 15:42, Activecat wrote:

> Dear Marcus,
>
>> Meanwhile, as you had advised, I had tried to see the parameters
>> that forecast() and general_work() are called with. Refer below
>> verbose message. When the flow chart started, the initial values
>> are samp_rate=32k, change_rate=64; hence d_iFactor = 32k/64 =
>> 500. At line 24 the samp_rate is changed to 64k on the fly by the
>> user. So now d_iFactor = 64k/64 = 1000. Every parameters and
>> return values seem to be correct, but the flow graph output
>> becomes wrong after line 24.
>
>> Wrong in which way?
>>
>
>
> Refer below, row_002 to row_010 are correct outputs. At row_011,
> the samp_rate was changed from 64k to 32k, by using WX GUI Slider.
> This were wrong outputs.
>
> Executing: "/home/sgku/gnuradio/flow_graphs/top_block.py" Using
> Volk machine: ssse3_32_orc Integer1   [row_001]  =    3,   22,
> 33,   44,   55,   211,   222, 233,   244,   255,   0 Integer1
> [row_002]  =    11,   22,   33,   44,   55,   211,   222, 233,
> 244,   255,   0 Integer1   [row_003]  =    11,   22,   33,   44,
> 55,   211,   222, 233,   244,   255,   0 Integer1   [row_004]  =
> 11,   22,   33,   44,   55,   211,   222, 233,   244,   255,   0
> Integer1   [row_005]  =    11,   22,   33,   44,   55,   211,
> 222, 233,   244,   255,   0 Integer1   [row_006]  =    11,   22,
> 33,   44,   55,   211,   222, 233,   244,   255,   0 Integer1
> [row_007]  =    11,   22,   33,   44,   55,   211,   222, 233,
> 244,   255,   0 Integer1   [row_008]  =    11,   22,   33,   44,
> 55,   211,   222, 233,   244,   255,   0 Integer1   [row_009]  =
> 11,   22,   33,   44,   55,   211,   222, 233,   244,   255,   0
> Integer1   [row_010]  =    11,   22,   33,   44,   55,   211,
> 222, 233,   244,   255,   0 Integer1   [row_011]  =    11,   22,
> 33,   700,   23,   863,   15, 1530,   165,   0 Integer1   [row_012]
> =    65535,   3,   1,   3,   1646,   145,   73, 71,   124,   82,
> 85,   170,   173,   131,   184,   182,   145,   73, 71,   124,
> 82,   85,   170,   173,   131,   184,   182,   145,   73, 71,
> 124,   82,   85,   170,   173,   131,   184,   182,   145,   73,
> 71,   124,   82,   85,   170,   173,   131,   184,   182,   145,
> 73, 71,   124,   82,   85,   170,   173,   131,   184,   182,
> 145,   73, 71,   124,   82,   85,   170,   173,   131,   184,
> 182,   145,   73, 71,   124,   82,   85,   170,   173,   131,
> 184,   182,   145,   73, 71,   124,   82,   85,   170,   173,
> 131,   184,   182,   145,   73, 71,   124,   82,   85,   170,
> 173,   131,   184,   182,   145,   73, 71,   124,   82,   85,
> 170,   173,   131,   184,   182,   145,   73, 71,   124,   82,
> 85,   170,   173,   131,   184,   182,   145,   73, 71,   124,
> 82,   85,   170,   173,   131,   184,   182,   145,   73, 71,
> 124,   82,   85,   170,   173,   131,   184,   182,   145,   73,
> 71,   124,   82,   85,   170,   173,   131,   184,   182,   145,
> 73,
>>>> Done
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTGy5ZAAoJEBQ6EdjyzlHtdL8IAKtKp+4uw32Y975gbRV+Y+YO
GbC8Jeo8bWoHi3DdyjmlnzLaDCanhxXjNsfU0hwMQcpCQN65Zu0407VYfVYVIXgJ
IRBjOwSleZsTGBkeXS6lFxNQLHn5FkWIHMA8yPZy05jpjdqa6wdShRVmqjl8depe
kLxVPN8Cqfz8wadIV4OcW2l5K/59ZU/O2MqNNL2O5qiMNz8E8TDHmhJXfzCkWjcs
9JePXJ2RDS39o8W7WsPOlXLioNAHwBWy+98oNUClGB07dorkci8TWY6ScEWztKKU
9RJsUj9HUjy70LbXbRuJ88m1qZhBwNYDx4CGjX9PMJAMeM5ehnCQkNjRx3mFm20=
=u8XF
-----END PGP SIGNATURE-----

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: self.set_min_noutput_items() is not a valid python command in gnuradio ?

activecat
Dear Marcus,

sorry, I neither know your application nor what your work does, so the
question was more like "does GNU Radio do something wrong or is it
just the output of your block"; I don't understand any of your output ;)

- From what I see, there is 65535==0b1111111111111111 in your output;
this indicates some arithmetic error in your work.
However, this leaves the scope of this thread, so I suggest we close
the discussion here.

Sure, let's end this thread.
Thanks for the help.
Thank you very much.

Regards,
Activecat

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Loading...