Re: [Discuss-gnuradio] Should return the number of input or the number of output?
Hi Activecat, it's a sink. As Martin said, keep it a sync block. Overriding forecast doesn't even make sense; why should the scheduler ask the block I'd like to have 2000 output items from you, how much input do you need if it's guaranteed to never produce output. Maybe I'm getting something wrong, so why would you want to costumize the forecast function? Greetings, Marcus On Sun, May 4, 2014 at 3:49 AM, Activecat active...@gmail.com wrote: Part of this question has been partially discussed, as below. On Mon, Mar 10, 2014 at 9:18 PM, Martin Braun martin.br...@ettus.comwrote: OK, I admit I was unclear. Let's try from scratch: - The return function from work() or general_work() is the amount of items that were *produced*. Says, now I need to create a sink block, and I need to highly customize its built-in forecast() function. Hence I have two choices:- (i). Create this as a sink block, then explicitly overwrite its forecast() function in the body of the custom block. (ii). Create this as a general block. Question 1: Will option (i) above work? Question 2: If a sink block is implemented as a general block, does it still need to return noutput_items, or just return 0, or doesn't matter at all ? (I guess it should return 0 because the sink block doesn't produce any output) - In a sync block, the number of items produced is the number of items consumed, so we can use that to save the developer from manually consuming(). In other words, in a sync block, the return value is *both* the number of produced and consumed items. - Sinks and sources are syncs, therefore the mechanic is always the same. - Sinks are a special case because they don't produce anything. However, the scheduler knows the block's io signature, and knows what to do. The consume/produce mechanic stays the same, for consistency's sake, as with all other sync blocks. Hope this clears things up! M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Should return the number of input or the number of output?
On Sun, May 4, 2014 at 4:39 PM, Marcus Müller marcus.muel...@ettus.comwrote: Hi Activecat, it's a sink. As Martin said, keep it a sync block. Overriding forecast doesn't even make sense; why should the scheduler ask the block I'd like to have 2000 output items from you, how much input do you need if it's guaranteed to never produce output. Maybe I'm getting something wrong, so why would you want to costumize the forecast function? Greetings, Marcus This sink block needs to produce an 8-bit integer from every 9 elements it receives. The below two commands will be useful, but unfortunately not currently being supported on python sink block: self.set_min_ninput_items(9) self.set_input_multiple(9) One workaround, if it works, will be using forecast(): def forecast(self, noutput_items, ninput_items_required): ninput_items_required[0] = 9 * noutput_items This elaborates why I try to customize the forecast() of a sink block. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Should return the number of input or the number of output?
On Mon, May 5, 2014 at 3:45 AM, Marcus Müller marcus.muel...@ettus.comwrote: Hi Activecat, On 04.05.2014 12:32, Activecat wrote: This sink block needs to produce an 8-bit integer from every 9 elements it receives. Ok, this explains where the mutual confusion stems from: A sink block is a block that is a sample sink. Items go in, nothing comes out. This block calculates 8-bit integers and show it on console, not to any output port. There is no output port. Hence this is a sink block. What you're describing is a decimator. Nothing special about that, just use the decimator block type, set the decimation to 9 and you're set. Greetings, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Should return the number of input or the number of output?
Part of this question has been partially discussed, as below. On Mon, Mar 10, 2014 at 9:18 PM, Martin Braun martin.br...@ettus.comwrote: OK, I admit I was unclear. Let's try from scratch: - The return function from work() or general_work() is the amount of items that were *produced*. Says, now I need to create a sink block, and I need to highly customize its built-in forecast() function. Hence I have two choices:- (i). Create this as a sink block, then explicitly overwrite its forecast() function in the body of the custom block. (ii). Create this as a general block. Question 1: Will option (i) above work? Question 2: If a sink block is implemented as a general block, does it still need to return noutput_items, or just return 0, or doesn't matter at all ? (I guess it should return 0 because the sink block doesn't produce any output) - In a sync block, the number of items produced is the number of items consumed, so we can use that to save the developer from manually consuming(). In other words, in a sync block, the return value is *both* the number of produced and consumed items. - Sinks and sources are syncs, therefore the mechanic is always the same. - Sinks are a special case because they don't produce anything. However, the scheduler knows the block's io signature, and knows what to do. The consume/produce mechanic stays the same, for consistency's sake, as with all other sync blocks. Hope this clears things up! M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Should return the number of input or the number of output?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, it's basically the idea of not writing a special case for a single type of block; and if you are aware that sync blocks are only subclasses of normal blocks that implement a general_work which consumes *and* produces the return value of work, than everything is clear and readable :) Greetings, Marcus On 11.03.2014 01:34, Activecat wrote: Dear Martin, Apparently the consistency of code across different source files is more emphasized than its clarity in individual file. Nevertheless that is clear now, thanks. Regards, Activecat On Mon, Mar 10, 2014 at 9:18 PM, Martin Braun martin.br...@ettus.comwrote: OK, I admit I was unclear. Let's try from scratch: - The return function from work() or general_work() is the amount of items that were *produced*. - In a sync block, the number of items produced is the number of items consumed, so we can use that to save the developer from manually consuming(). In other words, in a sync block, the return value is *both* the number of produced and consumed items. - Sinks and sources are syncs, therefore the mechanic is always the same. - Sinks are a special case because they don't produce anything. However, the scheduler knows the block's io signature, and knows what to do. The consume/produce mechanic stays the same, for consistency's sake, as with all other sync blocks. Hope this clears things up! M On 03/10/2014 02:09 PM, Activecat wrote: If the return value of work() is used to tell the scheduler how much we have consumed, than it is very clear! In general_work() of new templates generated by gr_modtool, we always see this, even for sink blocks: // Tell runtime system how many output items we produced. return noutput_items; The comment sounds like the return value of general_work() is to tell the scheduler how many output items have produced. If this is true, for sink block, we should actually returned zero because sink block doesn't produce any output item. To avoid confusion, and to be more consistent, I suggest to put this instead into work() of new templates of sink block: // Tell runtime system how many input items have been consumed. return noutput_items; Because when I look into sync_block.cc, the return value of work() is actually used for consume_each(r). Just a silly suggestion. Thanks. Regards, Activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHtKDAAoJEBQ6EdjyzlHtKhsIAJaKRWiOkmZ8/icO07FjTDCP M7DFTEvaWXl/WFRSVfGYkccE513iXU/wTmud4gF8ywYHK+YWJbEOmPV3aEKNNTU5 8C1GNa6a0yPfGz7l4+WK0oKt8vIklViSKqt+sOJ3G/FGu/bllSoStbOvGnzw2ubI mJDfE4BzAuBIGSRr6Ar11UJ7xRNwLg9pcGsDYEAy12HUKpuJSqKP9rrb1wb1Kwco t/Ov+KvmgPiNnP8w6V2VZ5FIWtE77BsdALtDZy4dKsQaSCiOPb+AxZyOZUP1XDYD rV0POlRWuQ4kPqRH8MhzxUn6h7yKs31q+9GSkWOCO8YiCC9EvYDYvi3Jm/oZndY= =4uZc -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Should return the number of input or the number of output?
Yes I agree with you all. Everything are now clear and readable. Thank you very much. Regards, Activecat On Tue, Mar 11, 2014 at 5:08 PM, Marcus Müller mar...@hostalia.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, it's basically the idea of not writing a special case for a single type of block; and if you are aware that sync blocks are only subclasses of normal blocks that implement a general_work which consumes *and* produces the return value of work, than everything is clear and readable :) Greetings, Marcus On 11.03.2014 01:34, Activecat wrote: Dear Martin, Apparently the consistency of code across different source files is more emphasized than its clarity in individual file. Nevertheless that is clear now, thanks. Regards, Activecat On Mon, Mar 10, 2014 at 9:18 PM, Martin Braun martin.br...@ettus.comwrote: OK, I admit I was unclear. Let's try from scratch: - The return function from work() or general_work() is the amount of items that were *produced*. - In a sync block, the number of items produced is the number of items consumed, so we can use that to save the developer from manually consuming(). In other words, in a sync block, the return value is *both* the number of produced and consumed items. - Sinks and sources are syncs, therefore the mechanic is always the same. - Sinks are a special case because they don't produce anything. However, the scheduler knows the block's io signature, and knows what to do. The consume/produce mechanic stays the same, for consistency's sake, as with all other sync blocks. Hope this clears things up! M On 03/10/2014 02:09 PM, Activecat wrote: If the return value of work() is used to tell the scheduler how much we have consumed, than it is very clear! In general_work() of new templates generated by gr_modtool, we always see this, even for sink blocks: // Tell runtime system how many output items we produced. return noutput_items; The comment sounds like the return value of general_work() is to tell the scheduler how many output items have produced. If this is true, for sink block, we should actually returned zero because sink block doesn't produce any output item. To avoid confusion, and to be more consistent, I suggest to put this instead into work() of new templates of sink block: // Tell runtime system how many input items have been consumed. return noutput_items; Because when I look into sync_block.cc, the return value of work() is actually used for consume_each(r). Just a silly suggestion. Thanks. Regards, Activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHtKDAAoJEBQ6EdjyzlHtKhsIAJaKRWiOkmZ8/icO07FjTDCP M7DFTEvaWXl/WFRSVfGYkccE513iXU/wTmud4gF8ywYHK+YWJbEOmPV3aEKNNTU5 8C1GNa6a0yPfGz7l4+WK0oKt8vIklViSKqt+sOJ3G/FGu/bllSoStbOvGnzw2ubI mJDfE4BzAuBIGSRr6Ar11UJ7xRNwLg9pcGsDYEAy12HUKpuJSqKP9rrb1wb1Kwco t/Ov+KvmgPiNnP8w6V2VZ5FIWtE77BsdALtDZy4dKsQaSCiOPb+AxZyOZUP1XDYD rV0POlRWuQ4kPqRH8MhzxUn6h7yKs31q+9GSkWOCO8YiCC9EvYDYvi3Jm/oZndY= =4uZc -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Should return the number of input or the number of output?
On 03/09/2014 04:58 AM, Activecat wrote: Dear Sir, A python sink block created by gr_modtool has below work() function, it returns the number of input items. def work(self, input_items, output_items): in0 = input_items[0] # +signal processing here+ return len(input_items[0]) But a c++ sink block created by gr_modtool has the work() function return the number of output items (noutput_items). It sounds contradict. Is there any error happening? No contradiction. Sinks are always syncs (haha), so noutput_items == the number of input items (by definition). The actual output buffer, however, is empty -- so we can't use the length of the output buffer to tell the scheduler how much we consumed. In a sync block, there is no argument ninput_items, so we can't use that, either. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Should return the number of input or the number of output?
On 03/09/2014 04:58 AM, Activecat wrote: Dear Sir, A python sink block created by gr_modtool has below work() function, it returns the number of input items. def work(self, input_items, output_items): in0 = input_items[0] # +signal processing here+ return len(input_items[0]) But a c++ sink block created by gr_modtool has the work() function return the number of output items (noutput_items). It sounds contradict. Is there any error happening? On Mon, Mar 10, 2014 at 5:42 PM, Martin Braun martin.br...@ettus.comwrote: No contradiction. Sinks are always syncs (haha), so noutput_items == the number of input items (by definition). The actual output buffer, however, is empty -- so we can't use the length of the output buffer to tell the scheduler how much we consumed. In a sync block, there is no argument ninput_items, so we can't use that, either. M Dear Sir, If the return value of work() is used to tell the scheduler how much we have consumed, than it is very clear! In general_work() of new templates generated by gr_modtool, we always see this, even for sink blocks: // Tell runtime system how many output items we produced. return noutput_items; The comment sounds like the return value of general_work() is to tell the scheduler how many output items have produced. If this is true, for sink block, we should actually returned zero because sink block doesn't produce any output item. To avoid confusion, and to be more consistent, I suggest to put this instead into work() of new templates of sink block: // Tell runtime system how many input items have been consumed. return noutput_items; Because when I look into sync_block.cc, the return value of work() is actually used for consume_each(r). Just a silly suggestion. Thanks. Regards, Activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Should return the number of input or the number of output?
OK, I admit I was unclear. Let's try from scratch: - The return function from work() or general_work() is the amount of items that were *produced*. - In a sync block, the number of items produced is the number of items consumed, so we can use that to save the developer from manually consuming(). In other words, in a sync block, the return value is *both* the number of produced and consumed items. - Sinks and sources are syncs, therefore the mechanic is always the same. - Sinks are a special case because they don't produce anything. However, the scheduler knows the block's io signature, and knows what to do. The consume/produce mechanic stays the same, for consistency's sake, as with all other sync blocks. Hope this clears things up! M On 03/10/2014 02:09 PM, Activecat wrote: If the return value of work() is used to tell the scheduler how much we have consumed, than it is very clear! In general_work() of new templates generated by gr_modtool, we always see this, even for sink blocks: // Tell runtime system how many output items we produced. return noutput_items; The comment sounds like the return value of general_work() is to tell the scheduler how many output items have produced. If this is true, for sink block, we should actually returned zero because sink block doesn't produce any output item. To avoid confusion, and to be more consistent, I suggest to put this instead into work() of new templates of sink block: // Tell runtime system how many input items have been consumed. return noutput_items; Because when I look into sync_block.cc, the return value of work() is actually used for consume_each(r). Just a silly suggestion. Thanks. Regards, Activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Should return the number of input or the number of output?
Dear Martin, Apparently the consistency of code across different source files is more emphasized than its clarity in individual file. Nevertheless that is clear now, thanks. Regards, Activecat On Mon, Mar 10, 2014 at 9:18 PM, Martin Braun martin.br...@ettus.comwrote: OK, I admit I was unclear. Let's try from scratch: - The return function from work() or general_work() is the amount of items that were *produced*. - In a sync block, the number of items produced is the number of items consumed, so we can use that to save the developer from manually consuming(). In other words, in a sync block, the return value is *both* the number of produced and consumed items. - Sinks and sources are syncs, therefore the mechanic is always the same. - Sinks are a special case because they don't produce anything. However, the scheduler knows the block's io signature, and knows what to do. The consume/produce mechanic stays the same, for consistency's sake, as with all other sync blocks. Hope this clears things up! M On 03/10/2014 02:09 PM, Activecat wrote: If the return value of work() is used to tell the scheduler how much we have consumed, than it is very clear! In general_work() of new templates generated by gr_modtool, we always see this, even for sink blocks: // Tell runtime system how many output items we produced. return noutput_items; The comment sounds like the return value of general_work() is to tell the scheduler how many output items have produced. If this is true, for sink block, we should actually returned zero because sink block doesn't produce any output item. To avoid confusion, and to be more consistent, I suggest to put this instead into work() of new templates of sink block: // Tell runtime system how many input items have been consumed. return noutput_items; Because when I look into sync_block.cc, the return value of work() is actually used for consume_each(r). Just a silly suggestion. Thanks. Regards, Activecat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
