# Self.set\_min\_noutput\_items() is not a valid python command in gnuradio? **URL:** \ **Category:** GNU Radio\ **Created:** [March 6, 2014, 8:14am UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596 "2014-03-06T08:14:06Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [March 6, 2014, 8:14am UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/1 "2014-03-06T08:14:06Z")
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 ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 6, 2014, 4:38pm UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/2 "2014-03-06T16:38:26Z")
On Thu, Mar 6, 2014 at 2:12 AM, Activecat [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > ‘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 ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 7, 2014, 11:01am UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/3 "2014-03-07T11:01:58Z")
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 ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 7, 2014, 2:28am UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/4 "2014-03-07T02:28:40Z")
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 [Re: [Discuss-gnuradio] call set\_output\_multiple() on the fly](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 ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 8, 2014, 3:36am UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/5 "2014-03-08T03:36:35Z")
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 ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 8, 2014, 4:51am UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/6 "2014-03-08T04:51:48Z")
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 ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 8, 2014, 3:51am UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/7 "2014-03-08T03:51:45Z")
-----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. > My explanation: Says, the instantaneous interpolation factor is > 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 > > more. So yes, it works on the fly. > > > > set\_output\_multiple(1000). > > (Refer > > [Re: [Discuss-gnuradio] call set\_output\_multiple() on the fly](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. > > Hence I call: set\_min\_noutput\_items(800) > > > > > > Dear Sir, > > > > > > But before you try and use this, be very careful. This is an > > > mailing [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > * * * > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - [http://www.enigmail.net/](http://www.enigmail.net/) iQEcBAEBAgAGBQJTGoVpAAoJEBQ6EdjyzlHtXpAH/3rMFjvBQxTzxwPuwb7Vfr2s afzIB7c0SR16EmbQ7XXwGRc413vJrYz9HSP+mHW+d14EId0tJgbD70M0NjA2rIfO 4qJA+OyKxgG/kchpeqH8thHzS5eE8jQxPhAYuE7dgYOK8pD9XW/z6Tnj7xOr7UVP Xh8nWoM9HXJXq4xagjkXOqsIW8hxAe7JRNuAx7Jrtbe1g1cyjTfROa2KNRyZbxoa V8V4UeYBt0ab3LGqCwUGB1uMefoGn2Walnb9rcW38jEaLEQ+l33ZgvD3kDte/Jju 78aglgn15tXU0VMbX5ON9ZkLm4lZCx1TQ2Wyf/PxnNhKow9kSfSaoJYnSZ77U0U= =638A -----END PGP SIGNATURE----- ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 8, 2014, 10:43am UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/8 "2014-03-08T10:43:06Z")
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? ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 8, 2014, 10:43am UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/9 "2014-03-08T10:43:43Z")
-----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----- ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 8, 2014, 12:31pm UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/10 "2014-03-08T12:31:45Z")
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 ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 8, 2014, 12:44pm UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/11 "2014-03-08T12:44:30Z")
-----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 > > you need 0 input to produce that… The joys of Integer division -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - [http://www.enigmail.net/](http://www.enigmail.net/) iQEcBAEBAgAGBQJTGwJWAAoJEBQ6EdjyzlHtaEUIAIU/xwUUg4dUfzpv3cvCBTyM gT8u9uMw/9vFRXsDRnj/QZvlgkc2EtW1vwyVrjgh165Jm9Vl8AY9SIKlPryOfFMK 7fg8G5hNuXm8wIIL2iCj15Kom9qp+Gh9YK8ULD/ElHh/z2zkSTftsp647DbNcget miKrjPfEIkN6JQdz5xpEWUvgblGjHUKclI100A2kGajPAcY7YWZczAZ0LxIy/rKZ CjOpRsHRgIa/hd1WvC5PiaqtFJxoyGHK3weFgPZAAi6IYL2rH5LSmrFTeGQrYgYH CvXEq8GjbPLwUEv8ubyUWNv95h0fvDJUhMchVUY17v/ZnHdZqE8Bkd6VNELZO3c= =GUvF -----END PGP SIGNATURE----- ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 8, 2014, 2:08pm UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/12 "2014-03-08T14:08:15Z")
Dear Marcus, > 2). Regarding the returning 0 issue, let me share my experience of > > > ninput\_items[0]=3. In this case the only correct thing that > > 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. ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 8, 2014, 2:10pm UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/13 "2014-03-08T14:10:05Z")
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Activecat, On 08.03.2014 13:54, Activecat wrote: > 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. > 🙂 > 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/](http://www.enigmail.net/) iQEcBAEBAgAGBQJTGxZlAAoJEBQ6EdjyzlHtzVkH/2yu6GyvUr2aevwric3ER7iS kuZ0drhy9C1PweSqPeBBPSRdOxqX0nDsYD9O+f+k03bGLyfidwLQ8jlt0J9wX9Vv 82yvxGkEVf3OShAUB44uPFEUOvbAYef697jjP0YmDSrbGc/XQ7+FpngJmOqhqBpe AsiqmKpLaYJ9rvKsButGaj6mnT98mnWQt2+GTk5bTzZ0w9O1NVKpo6odaFVMp+hM +OjW7w+vV5YfyRw3OhhyrjoXCMOtw1oXz4aUbHuKqXfFF12GJYA3mrElKuELK7E+ fnC24SD8rrpytdjTTwj+sAoebJhxDymb8oCJ2UwR7f13CgmWrmat+p0J9KS6aUY= =FeQj -----END PGP SIGNATURE----- ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 8, 2014, 1:56pm UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/14 "2014-03-08T13:56:43Z")
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 ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 8, 2014, 3:52pm UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/15 "2014-03-08T15:52:03Z")
-----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: > 33, 44, 55, 211, 222, 233, 244, 255, 0 Integer1 > 11, 22, 33, 44, 55, 211, 222, 233, 244, 255, 0 > 182, 145, 73, 71, 124, 82, 85, 170, 173, 131, > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Discuss-gnuradio > mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - [http://www.enigmail.net/](http://www.enigmail.net/) iQEcBAEBAgAGBQJTGy5ZAAoJEBQ6EdjyzlHtdL8IAKtKp+4uw32Y975gbRV+Y+YO GbC8Jeo8bWoHi3DdyjmlnzLaDCanhxXjNsfU0hwMQcpCQN65Zu0407VYfVYVIXgJ IRBjOwSleZsTGBkeXS6lFxNQLHn5FkWIHMA8yPZy05jpjdqa6wdShRVmqjl8depe kLxVPN8Cqfz8wadIV4OcW2l5K/59ZU/O2MqNNL2O5qiMNz8E8TDHmhJXfzCkWjcs 9JePXJ2RDS39o8W7WsPOlXLioNAHwBWy+98oNUClGB07dorkci8TWY6ScEWztKKU 9RJsUj9HUjy70LbXbRuJ88m1qZhBwNYDx4CGjX9PMJAMeM5ehnCQkNjRx3mFm20= =u8XF -----END PGP SIGNATURE----- ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 8, 2014, 4:09pm UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/16 "2014-03-08T16:09:39Z")
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 ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [March 8, 2014, 3:44pm UTC](https://www.ruby-forum.com/t/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio/239596/17 "2014-03-08T15:44:46Z")
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,